14 – Active Directory Organisational Unit Administration Fundamentals: PowerShell-Based OU Management and Object Placement

Focus: Microsoft Infrastructure Administration, Active Directory, PowerShell, Organisational Units, Object Administration, Identity Infrastructure

Technology: Windows Server 2025 Standard Evaluation | Oracle VirtualBox | Windows PowerShell 5.1 | Active Directory Domain Services (AD DS)

Domain: Microsoft Infrastructure Administration | Identity and Access Management | Enterprise Security Foundations

Objective

Following the Active Directory group-administration work from the previous laboratory, this exercise extended identity and infrastructure administration into Active Directory Organisational Unit management and controlled object placement.

Organisational Units provide a hierarchical structure within Active Directory for organising directory objects and supporting administrative boundaries.

The laboratory focused on creating and validating an OU hierarchy, moving an existing user object into the appropriate OU, creating a controlled computer object, testing accidental-deletion protection, and using PowerShell to validate the resulting directory state.

The objectives were to:

• Administer Active Directory Organisational Units with PowerShell.
• Establish a reusable domain Distinguished Name.
• Create a dedicated parent OU and child OUs.
• Design and validate a basic OU hierarchy.
• Configure accidental-deletion protection.
• Inspect an existing Active Directory user object.
• Move a user between Active Directory containers.
• Create and validate an Active Directory computer object.
• Safely test OU deletion protection.
• Perform a controlled destructive operation.
• Implement state validation through PowerShell.
• Demonstrate basic administrative automation.
• Troubleshoot an environmental Windows Server timezone configuration issue.
• Independently verify the final Active Directory state.

This laboratory therefore extends the previous progression from user administration and group-based access control into directory structure and object administration.

Environment Overview

Platform: Oracle VirtualBox

Operating System: Windows Server 2025 Standard Evaluation

Administration Method: Windows PowerShell 5.1

Active Directory Domain: corp.lab

Domain Distinguished Name: DC=corp,DC=lab

Phase: Phase 2 — Microsoft Infrastructure Administration Foundations

Establishing the Domain Distinguished Name

The laboratory began by retrieving the Active Directory domain Distinguished Name directly from the domain.

The resulting value was:

DC=corp,DC=lab

This value was stored in:

$DomainDN

Using the domain DN dynamically provided a reusable basis for constructing Active Directory paths throughout the exercise.

Rather than repeatedly hard-coding the domain structure, subsequent commands could reference the established variable.

This reinforced a basic PowerShell administration principle:

Retrieve environmental information dynamically where practical rather than assuming it.

Creating the OU Hierarchy

A dedicated parent OU was created:

Lab-IT

Two child OUs were then created beneath it:

Lab-Users
Lab-Computers

The intended structure was:

corp.lab

↓

Lab-IT

├── Lab-Users

└── Lab-Computers

This provided separate administrative locations for user and computer objects.

The structure was deliberately simple because the purpose of the laboratory was to understand OU administration and object placement rather than reproduce a large enterprise directory.

Organisational Units Versus Groups

An important concept reinforced during this exercise was the distinction between Organisational Units and Active Directory groups.

An OU primarily provides:

• directory structure
• object organisation
• an administrative boundary
• a potential scope for delegated administration and Group Policy

A group primarily represents:

• membership
• access relationships
• administrative or security roles

For example, the laboratory user:

labauto01

can be located within:

Lab-Users

while also belonging to one or more groups.

Therefore:

OU placement ≠ group membership

This distinction is fundamental to understanding Active Directory administration and becomes increasingly important when progressing towards identity and access-management work.

Validating the OU Structure

After creating the OUs, the resulting directory structure was queried directly.

The validation confirmed the existence of:

• Lab-IT
• Lab-Users
• Lab-Computers

and their expected Distinguished Names.

The resulting structure was:

corp.lab
└── Lab-IT
    ├── Lab-Users
    └── Lab-Computers

This followed the same state-based methodology established during the previous laboratory:

Change → Query → Verify

Successful execution of New-ADOrganizationalUnit was not treated as sufficient evidence that the desired structure existed.

The resulting Active Directory state was queried directly.

Accidental-Deletion Protection

The permanent OUs were created with:

ProtectedFromAccidentalDeletion = True

The protection state of each OU was subsequently queried independently.

The resulting state confirmed that:

• Lab-IT was protected.
• Lab-Users was protected.
• Lab-Computers was protected.

This introduced an important administrative safeguard against unintended OU deletion.

Accidental-deletion protection does not replace appropriate permissions or administrative discipline, but it provides an additional control against destructive mistakes.

The laboratory therefore treated OU protection as part of the desired configuration rather than as an optional cosmetic property.

Inspecting the Existing Automation User

The existing laboratory account:

labauto01

was inspected before changing its location.

Its initial Distinguished Name showed that the account was located in the default Active Directory Users container:

CN=Lab Automation User01,CN=Users,DC=corp,DC=lab

The new OU structure therefore existed, but the existing user had not yet been placed within the dedicated Lab-Users OU.

This created a practical administration scenario:

Existing directory object

↓

New organisational structure

↓

Controlled object relocation

Moving the User into Lab-Users

The Lab-Users OU was retrieved from Active Directory and its Distinguished Name stored for reuse.

The user’s current Distinguished Name was then retrieved dynamically.

The object was moved using:

Move-ADObject

The resulting location became:

OU=Lab-Users,OU=Lab-IT,DC=corp,DC=lab

The user was then queried again.

The resulting state confirmed that:

• labauto01 still existed.
• The account remained enabled.
• The user’s Distinguished Name had changed.
• The user was now located in Lab-Users.

The important point is that moving an Active Directory object changes its location within the directory hierarchy without changing the underlying identity.

Creating an Active Directory Computer Object

A controlled computer object was then created:

LAB-TEST-PC01

This represented an Active Directory computer object, rather than a physical or virtual machine being joined to the domain.

The object was deliberately created in a disabled state.

This was intentional because the exercise concerned:

Active Directory computer-object administration

rather than:

Domain joining a physical or virtual computer

The object was placed directly into:

Lab-Computers

The resulting Distinguished Name confirmed the intended location.

Verifying the Computer Object

The newly created computer object was queried independently.

The resulting state confirmed that:

• LAB-TEST-PC01 existed.
• The object was disabled.
• The object was located in Lab-Computers.

This reinforced the distinction between an Active Directory computer account and an actual operating system instance.

The directory can contain a computer object representing a device even when the exercise does not involve joining a real computer to the domain.

Controlled Accidental-Deletion Test

A separate temporary OU was created:

Lab-Temporary

This OU existed specifically to test accidental-deletion protection without risking the permanent laboratory structure.

The temporary OU was initially created with:

ProtectedFromAccidentalDeletion = True

Its protection state was then independently verified.

This established the expected precondition before performing the deletion workflow.

Deliberately Removing Protection

Because Lab-Temporary was specifically created as a disposable test object, its protection was deliberately disabled.

The resulting state was queried again.

The output confirmed:

ProtectedFromAccidentalDeletion = False

Only after explicitly confirming that protection had been removed was the OU deleted.

The complete controlled workflow was therefore:

Create

↓

Protect

↓

Verify protection

↓

Remove protection deliberately

↓

Verify removal of protection

↓

Delete

↓

Verify deletion

This provided a safe way to test a potentially destructive administrative operation.

Verifying the Deletion

The deleted OU was queried directly.

Active Directory returned an object-not-found condition.

An independent filter query was then used to determine whether another object named:

Lab-Temporary

remained in the directory.

No result was returned.

The deletion was therefore independently verified rather than inferred solely from the successful completion of the deletion command.

The permanent OU structure was subsequently queried again.

Only the intended permanent structure remained:

corp.lab
└── Lab-IT
    ├── Lab-Users
    └── Lab-Computers

Final Active Directory State

The final directory state was independently validated.

The user:

labauto01

was:

• enabled
• located in Lab-Users

The computer object:

LAB-TEST-PC01

was:

• disabled
• located in Lab-Computers

The three permanent OUs remained protected against accidental deletion.

The temporary OU had been deleted and independently verified as absent.

The resulting structure was:

corp.lab
└── Lab-IT
    ├── Lab-Users
    │   └── Lab Automation User01
    │       └── labauto01
    │
    └── Lab-Computers
        └── LAB-TEST-PC01

This represented the intended final state of the laboratory.

PowerShell Automation

After the administration had been performed manually, PowerShell logic was used to demonstrate repeatability and state validation.

The automation:

• retrieved the domain DN;
• retrieved the expected OUs;
• retrieved the existing user;
• checked the user’s location;
• moved the user if the expected OU placement was not present;
• retrieved the computer object;
• reported the resulting directory state.

This introduced a distinction between:

Executing an administrative command

and:

Checking the current state → changing it only when required → validating the resulting state

The automation was deliberately introduced after the manual administration had been understood.

This avoided treating automation as a substitute for understanding the underlying Active Directory operations.

The workflow therefore demonstrated a basic transition from interactive administration towards state-aware automation.

Verification and State Management

A recurring principle throughout the laboratory was that successful command execution does not necessarily prove that the intended configuration exists.

The distinction can be summarised as:

Command succeeded
        ≠
Desired state confirmed

For example, successfully moving a user does not eliminate the need to query the user’s Distinguished Name afterwards.

Similarly, successfully deleting an OU does not by itself establish that the intended object has disappeared from the directory.

The laboratory therefore repeatedly used Active Directory queries to establish the resulting state.

This methodology is applicable well beyond Active Directory administration.

Environmental Troubleshooting

During the laboratory, an unrelated but relevant Windows Server configuration issue was identified.

The Windows Server VM was using:

Pacific Standard Time

instead of the appropriate timezone for Spain.

The configuration was investigated using PowerShell.

The timezone was then corrected to:

Romance Standard Time

The system time was subsequently checked again.

The final recorded timestamp after the correction was:

2026-08-25 17:14:57

This provided an example of an infrastructure issue being detected and corrected while performing an otherwise unrelated administrative task.

The workflow remained:

Detect → Investigate → Correct → Verify

This is representative of practical infrastructure administration, where environmental issues can surface during routine work.

Automation Safety

The laboratory incorporated several administrative safeguards:

• Dynamic domain DN retrieval.
• Explicit OU hierarchy.
• Accidental-deletion protection.
• Controlled temporary objects.
• Explicit verification before destructive operations.
• Error handling with -ErrorAction Stop.
• Post-operation object validation.
• Independent deletion verification.
• Final-state validation.
• Conditional object movement in the automation workflow.

The resulting control model was:

Establish expected state

↓

Perform controlled change

↓

Validate resulting state

↓

Clean up temporary objects

↓

Independently verify final state

This is particularly relevant when administration begins to move from interactive commands towards repeatable automation.

Security and Infrastructure Perspective

Although this laboratory focused on Organisational Units rather than direct permissions, OU structure forms an important part of Active Directory administration.

OU placement can influence:

• Group Policy application
• delegated administration
• object management
• organisational separation
• administrative boundaries

Therefore, moving an object between OUs is not necessarily a purely organisational action.

In a larger environment, changing an object’s location can potentially change which policies apply to it or which administrators can manage it.

The laboratory therefore reinforced the importance of understanding the consequences of directory structure changes before automating them.

From User and Group Administration to Directory Structure

The progression through the Active Directory laboratories can now be viewed as:

Active Directory infrastructure

↓

User administration

↓

Group administration

↓

Organisational Unit administration

↓

Object placement

↓

PowerShell automation

↓

Identity lifecycle management

↓

Hybrid Identity

↓

Microsoft Entra ID

↓

Identity Security

↓

Detection Engineering

The technical mechanisms differ between on-premises Active Directory and cloud identity platforms, but the underlying concepts remain related.

Identities exist as directory objects.

Groups establish membership and access relationships.

OUs provide organisational and administrative structure.

Changes to these relationships and structures can therefore become relevant security signals.

Key Takeaway

The main lesson from this laboratory was that Active Directory administration is fundamentally a state-management problem within a hierarchical directory.

A robust administrative workflow should establish:

• What environment is being modified.
• What objects should exist.
• Where those objects should be located.
• What protections should be enabled.
• What change should be performed.
• What should happen if an unexpected condition occurs.
• How the resulting state will be verified.
• How temporary objects will be safely removed.

The resulting methodology can be summarised as:

Establish expected state

↓

Perform controlled change

↓

Verify post-condition

↓

Clean up

↓

Independently confirm final state

This provides a practical foundation for broader Windows infrastructure administration, cloud administration and identity-security work.

Evidence

The complete PowerShell commands, output, validation logic and final-state evidence are documented in the laboratory repository.

GitHub laboratory documentation:

2.6 Active Directory Organisational Units

The repository contains the technical implementation and evidence demonstrating OU creation, hierarchy validation, object placement, accidental-deletion protection, controlled deletion, automation and independent final-state verification.

Skills Demonstrated

• Active Directory OU administration
• Windows PowerShell 5.1
• Organisational Unit creation
• OU hierarchy design
• Distinguished Name analysis
• Active Directory user administration
• Active Directory computer-object administration
• Object relocation
• Accidental-deletion protection
• Controlled destructive testing
• State validation
• PowerShell automation
• Conditional logic
• Error handling
• Independent verification
• Infrastructure troubleshooting
• Administrative cleanup
• Identity and access-management fundamentals
• Evidence-based technical documentation

Portfolio Context

This laboratory forms part of:

Phase 2 — Microsoft Infrastructure Administration Foundations

Learning progression:

2.1 Windows Server Administration Foundations

↓

2.2 Windows Server Administration Fundamentals

↓

2.3 Active Directory Administration Fundamentals

↓

2.4 Active Directory User Administration Fundamentals

↓

2.5 Active Directory Group Administration Fundamentals

↓

2.6 Active Directory Organisational Unit Administration Fundamentals

↓

Hybrid Identity

↓

Microsoft Entra ID

↓

Azure Administration

↓

Identity Security

↓

Detection Engineering

This phase progressively develops the infrastructure and identity knowledge required for:

• Windows Server administration
• Active Directory administration
• User and group lifecycle management
• Organisational Unit and object administration
• Role and access management
• Hybrid identity
• Microsoft Entra ID
• Azure administration
• Identity security
• Detection Engineering

Laboratory 2.6 therefore extends the practical identity-administration layer from individual user objects and group-based access management into directory structure, administrative boundaries and object placement.