14 – Microsoft Active Directory Organisational Unit Administration: PowerShell-Based Structure, Object Placement and Validation

Overview

Following the Active Directory group-administration work in the previous laboratory, this exercise moved to another fundamental component of Windows identity and infrastructure administration: Organisational Units (OUs).

Organisational Units provide a logical structure within Active Directory for organising objects and applying administrative controls.

Unlike groups, which primarily represent membership and access relationships, OUs provide a location within the directory hierarchy.

This distinction is important:

→ organisational and administrative structure

Group

→ membership and access-control relationship

This laboratory therefore focused on administering Active Directory Organisational Units and directory objects with Windows PowerShell 5.1, while continuing the verification-driven methodology established in the previous exercises.

The work covered:

Active Directory OU creation
OU hierarchy design
Distinguished Names (DNs)
OU object placement
user-object administration
computer-object administration
accidental-deletion protection
controlled deletion
state validation
PowerShell automation
configuration troubleshooting
independent verification
controlled cleanup

The complete commands, PowerShell output and validation evidence are maintained in the accompanying GitHub repository.

Objectives

The laboratory objectives were to:

Establish the Active Directory domain Distinguished Name.
Create a dedicated parent OU for laboratory infrastructure.
Create separate user and computer OUs.
Establish and validate the resulting OU hierarchy.
Enable accidental-deletion protection on permanent OUs.
Inspect an existing Active Directory user object.
Move the user from the default Users container into the dedicated Lab-Users OU.
Create a disabled Active Directory computer object.
Place the computer object in the dedicated Lab-Computers OU.
Safely test accidental-deletion protection using a disposable OU.
Deliberately remove protection before controlled deletion.
Independently verify the deletion.
Re-validate the permanent OU structure.
Develop a basic PowerShell validation and automation workflow.
Troubleshoot an incorrect Windows Server timezone configuration.
Verify the final Active Directory state.

The complete implementation and command-level evidence are maintained in GitHub rather than reproduced throughout this article.

Environment

The laboratory continued using the Windows Server infrastructure established during the previous Active Directory exercises.

Component	Configuration
Guest Operating System	Windows Server 2025 VM
Administration Method	Windows PowerShell 5.1
Active Directory Module	Active Directory PowerShell module
Active Directory Domain	`corp.lab`
Domain Distinguished Name	`DC=corp,DC=lab`

The Active Directory PowerShell module and domain environment were available before administration began.

The domain Distinguished Name was retrieved programmatically rather than manually assumed.

Establishing the Domain Distinguished Name

The first step was to obtain the domain Distinguished Name:

DC=corp,DC=lab

PowerShell was used to retrieve this directly from Active Directory.

This provided a reusable foundation for constructing subsequent OU paths.

Rather than hard-coding the domain structure throughout every command, the domain DN was stored in:

$DomainDN

This made the subsequent administration more consistent and reduced the possibility of constructing incorrect directory paths.

Designing the OU Structure

A dedicated parent OU was created:

Lab-IT

Two child OUs were then created beneath it:

Lab-Users

and

Lab-Computers

The intended structure was:

corp.lab

↓

Lab-IT

├── Lab-Users

└── Lab-Computers

This created a simple separation between user and computer objects.

The structure is intentionally small because the purpose of the exercise was to understand the mechanics of OU administration rather than reproduce a large enterprise directory.

Organisational Units Versus Groups

An important concept reinforced during the exercise was the distinction between an OU and an Active Directory group.

An OU provides a location and administrative boundary within the directory hierarchy.

A group represents membership and, depending on its use, access or administrative relationships.

For example:

Lab Automation User01

can reside inside:

Lab-Users

while simultaneously being a member of one or more Active Directory groups.

Therefore:

OU placement

does not mean:

group membership

Understanding this distinction is important when progressing towards identity and access-management work.

Validating the OU Hierarchy

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 hierarchy was:

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

This followed the same administrative principle used throughout the previous laboratory:

Change → Query → Verify

Successful command execution was not treated as sufficient evidence that the desired state existed.

Accidental-Deletion Protection

The permanent OUs were created with:

ProtectedFromAccidentalDeletion = True

The protection state was then independently queried for each OU.

The result confirmed that:

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

This introduced an important administrative safeguard.

An OU containing important directory objects should not normally be treated as an object that can simply be deleted without deliberate consideration.

Accidental-deletion protection therefore provides an additional control against unintended administrative actions.

It does not replace proper permissions or administrative discipline, but it can reduce the likelihood of destructive mistakes.

Inspecting the Existing Automation User

The existing laboratory account:

labauto01

was inspected before changing its location.

The initial Distinguished Name showed that the user 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 moved into it.

This provided a useful real administration scenario:

Existing object

↓

New organisational structure

↓

Controlled object relocation

Moving the User into `Lab-Users`

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

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

The object was moved using:

Move-ADObject

The target location became:

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

The user object was then queried again.

The resulting state confirmed that:

labauto01 still existed.
The account remained enabled.
The Distinguished Name had changed.
The user was now located within Lab-Users.

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

Creating an Active Directory Computer Object

A computer object was then created:

LAB-TEST-PC01

This represented an Active Directory computer account 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:

AD computer-object administration

rather than:

domain joining a real 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:

the computer object existed;
LAB-TEST-PC01 was disabled;
the object was located in Lab-Computers.

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

The directory can contain a computer account representing a device even when the exercise does not involve physically or virtually joining that device to the domain.

Controlled Accidental-Deletion Test

A separate temporary OU was created:

Lab-Temporary

This OU existed specifically to test the accidental-deletion protection mechanism 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 attempting the deletion workflow.

Deliberately Removing Protection

Because Lab-Temporary was disposable, its protection was deliberately disabled.

The resulting state was queried again.

The output confirmed:

ProtectedFromAccidentalDeletion = False

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

This created a controlled destructive test:

Create

↓

Protect

↓

Verify protection

↓

Remove protection deliberately

↓

Verify removal of protection

↓

Delete

↓

Verify deletion

This is preferable to testing destructive operations against important directory objects.

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 check whether another object named:

Lab-Temporary

remained in the directory.

No result was returned.

The deletion was therefore independently verified rather than inferred from the absence of a PowerShell error during the deletion command.

The permanent OUs were subsequently queried again.

Only the intended permanent structure remained:

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

Final Object State

The final Active 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 removed and independently verified as absent.

The resulting state was therefore:

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

PowerShell Automation and State Validation

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.

The workflow therefore moved beyond simple command execution towards state-aware administration.

The important distinction is:

Run a command

versus:

Check the current state → make a change only if required → verify the resulting state

This is a fundamental concept when progressing from interactive administration towards automation.

The automation was intentionally introduced after the manual work had been understood.

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

Why Verification Matters

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

The principle can be expressed simply:

Command succeeded
        ≠
Desired state confirmed

For example, moving an object successfully does not remove the need to query its Distinguished Name afterwards.

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

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

This verification-driven approach is applicable well beyond Active Directory.

Troubleshooting an Environmental Configuration Issue

During the laboratory, an unrelated but relevant infrastructure issue was identified.

The Windows Server VM was using:

Pacific Standard Time

instead of the appropriate timezone for Spain.

The configuration was investigated with 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 was a useful reminder that infrastructure administration does not always occur in perfectly isolated exercises.

An administrator may encounter environmental configuration problems while performing an otherwise unrelated task.

The important workflow remained:

Detect → investigate → correct → verify

Evidence-Based Infrastructure Administration

As with the previous laboratory, the work was documented primarily through PowerShell commands and their resulting output.

The repository records:

the command used;
the resulting state;
the interpretation of the output;
the validation performed;
the final configuration.

This avoids relying on screenshots as the primary form of evidence.

For command-line infrastructure administration, the PowerShell output itself provides reproducible evidence of what was queried and what state was returned.

The documentation then explains why that evidence matters.

Infrastructure and Identity Perspective

Although the laboratory focused on Organisational Units, the exercise also reinforced broader identity-management concepts.

Active Directory administration can be viewed as managing relationships between:

Directory Objects

↓

Organisational Structure

↓

Group Membership

↓

Permissions

↓

Access

An OU does not directly grant access merely because an object is placed inside it.

However, OU placement can influence administration through mechanisms such as:

Group Policy application
delegated administration
object management
organisational separation
administrative boundaries

This makes OU design an important component of broader identity and infrastructure administration.

From OU Administration to Identity Security

The progression through these laboratories is becoming increasingly relevant to identity-focused security work.

The sequence is now:

User Administration

↓

Group Administration

↓

Organisational Unit Administration

↓

Object Placement and Administrative Boundaries

↓

PowerShell Automation

↓

Identity Lifecycle

↓

Privileged Access

↓

Microsoft Entra ID

↓

Identity Security

↓

Detection Engineering

Understanding where identities and devices exist within the directory is useful when investigating identity-related events.

For example, an investigation may eventually require questions such as:

Which OU contains this account?
When was the object moved?
Was the movement expected?
Which administrative boundary does the object now fall under?
Which policies apply to the object’s location?
Was the change performed manually or through automation?

These questions build upon the underlying directory-management concepts practised in this laboratory.

Key Learning Outcome

The most important lesson from this laboratory was:

Active Directory administration is fundamentally state management within a hierarchical directory.

The workflow repeatedly followed:

Establish the expected state

↓

Perform the controlled action

↓

Query the resulting state

↓

Compare it with the expected state

↓

Independently verify where appropriate

↓

Clean up temporary objects

↓

Verify the final environment

This approach is more valuable than simply memorising Active Directory cmdlets because the same methodology can be applied to broader Windows administration, cloud administration and identity-security tasks.

Conclusion

This laboratory extended the Active Directory work from users and groups into directory structure and object placement.

The work demonstrated practical administration of:

Organisational Units
OU hierarchy
Distinguished Names
user-object placement
computer-object placement
accidental-deletion protection
controlled deletion
PowerShell Active Directory cmdlets
state validation
basic automation
environmental troubleshooting
independent verification
controlled cleanup

More importantly, the exercise reinforced the difference between performing an administrative action and proving that the resulting state is correct.

That distinction becomes increasingly important when moving from traditional Windows infrastructure administration towards hybrid identity, Microsoft Entra ID, Azure administration and identity security.

The core principle remains:

Do not assume that an administrative command produced the intended state. Query it, validate it and verify it.

Repository Context

This laboratory forms part of:

Phase 2 — Microsoft Infrastructure Administration Foundations

Portfolio progression:

Windows Infrastructure

↓

Windows Administration

↓

Active Directory

↓