15 – Microsoft Active Directory Group Policy Administration: GPO Scope, Processing and PowerShell Validation

Active Directory | Group Policy | PowerShell | Windows Server | GPO Administration | Infrastructure Administration | Policy Scope | Configuration Validation

Overview

Following the Active Directory Organisational Unit administration work in the previous laboratory, this exercise moved into another important part of Windows infrastructure administration: Group Policy.

Group Policy provides a mechanism for centrally managing Windows configuration through Active Directory.

The main focus of this laboratory was not simply creating a Group Policy Object (GPO), but understanding the relationship between:

GPO

→ GPO Link

→ OU Scope

→ Policy Processing

→ Resulting Configuration

The laboratory was therefore built around a small disposable test GPO and a harmless registry setting.

The work covered:

• GPO inspection
• GPO creation and discovery
• GPO linking
• OU targeting
• Computer Configuration
• registry-based policy configuration
• GPO reporting
• Group Policy inheritance
• gpresult
• policy-scope validation
• independent registry verification
• GPO unlinking
• GPO deletion
• final-state verification

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

Objectives

The objectives were to:

• Identify the existing domain and laboratory OU structure.
• Confirm the GroupPolicy PowerShell module.
• Inspect the existing GPOs.
• Work with a disposable test GPO.
• Link the GPO to Lab-Computers.
• Configure a harmless computer-level registry setting.
• Verify the setting inside the GPO.
• Examine Group Policy inheritance.
• Identify a live domain-joined machine.
• Determine the machine’s Active Directory location.
• Verify which GPOs were actually processed.
• Confirm that the test policy was outside the live machine’s scope.
• Independently verify the registry state.
• Remove the GPO link.
• Delete the temporary GPO.
• Verify the final Active Directory state.

Environment

The laboratory continued using the Windows Server environment from the previous Active Directory exercises.

The domain was queried directly rather than assumed:

$Domain = Get-ADDomain
$Domain | Select-Object DNSRoot, DistinguishedName

The result was:

DNSRoot  DistinguishedName
-------  -----------------
corp.lab DC=corp,DC=lab

Existing Active Directory Structure

The existing laboratory structure contained:

corp.lab

↓

Lab-IT

├── Lab-Users

└── Lab-Computers

The target OU for the exercise was:

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

The GroupPolicy module was also confirmed before beginning the administration:

Get-Module -ListAvailable -Name GroupPolicy |
    Select-Object Name, Version, Path

The installed module was:

GroupPolicy 1.0.0.0
C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\GroupPolicy\GroupPolicy.psd1

Inspecting the Existing GPOs

Before creating anything, the existing GPOs were queried.

Get-GPO -All |
    Select-Object DisplayName, Id, GpoStatus |
    Sort-Object DisplayName

The initial environment contained:

Default Domain Controllers Policy
Default Domain Policy

Both were left unchanged.

This was deliberate. The test work was performed using a separate GPO rather than modifying the default domain policies.

The Test GPO Already Existed

The original intention was to create:

Lab-IT-Test-Policy

However, when the creation command was executed, Active Directory reported that the GPO already existed.

New-GPO : The command cannot be completed because a "Lab-IT-Test-Policy" GPO already exists in the corp.lab domain.
FullyQualifiedErrorId : GpoWithNameAlreadyExists

Instead of deleting or recreating it, the existing object was inspected.

Get-GPO -Name "Lab-IT-Test-Policy" |
    Select-Object DisplayName, Id, GpoStatus

The existing GPO was:

DisplayName        : Lab-IT-Test-Policy
Id                 : 7d84da3d-02f9-40db-adb5-a9e24670ea9f
GpoStatus          : AllSettingsEnabled

Its creation time was also inspected.

The GPO had been created earlier on the same day. The original creator was not established during the exercise, so no assumption was made about who created it.

This was a useful real-world administration scenario: the expected object may already exist, so its current state should be inspected before making further changes.

Checking the GPO Before Configuration

The GPO was exported as an XML report before configuration.

The report showed:

• the expected GPO name;
• its GUID;
• the corp.lab domain;
• CORP\Domain Admins as owner;
• Computer Configuration enabled;
• no substantive test configuration yet.

The initial Computer Configuration version was:

0

This provided a baseline before making the configuration change.

Checking GPO Inheritance

Before linking the test GPO, the inheritance of Lab-Computers was checked.

Get-GPInheritance -Target $LabComputersOU.DistinguishedName

The relevant result was:

GpoInheritanceBlocked : No
GpoLinks              : {}
InheritedGpoLinks     : {Default Domain Policy}

At this point, the test GPO existed but was not linked to the target OU.

Linking the GPO

The test GPO was then linked directly to:

Lab-Computers

using:

New-GPLink `
    -Name "Lab-IT-Test-Policy" `
    -Target "OU=Lab-Computers,OU=Lab-IT,DC=corp,DC=lab" `
    -LinkEnabled Yes

The result confirmed:

DisplayName : Lab-IT-Test-Policy
Enabled     : True
Enforced    : False
Target      : OU=Lab-Computers,OU=Lab-IT,DC=corp,DC=lab
Order       : 1

The link was then independently checked with Get-GPInheritance.

The result showed:

GpoLinks              : {Lab-IT-Test-Policy}
InheritedGpoLinks     : {Lab-IT-Test-Policy, Default Domain Policy}
GpoInheritanceBlocked : No

The GPO now existed and had a direct link to the target OU.

Configuring a Harmless Test Setting

Rather than modifying an actual Windows security policy, a simple registry value was used to provide an observable test result.

The setting was:

HKLM\Software\Lab-IT

with the value:

PolicyTest = Lab-IT-Test-Policy Applied

It was configured using:

Set-GPRegistryValue `
    -Name "Lab-IT-Test-Policy" `
    -Key "HKLM\Software\Lab-IT" `
    -ValueName "PolicyTest" `
    -Type String `
    -Value "Lab-IT-Test-Policy Applied"

The Computer Configuration version changed from:

0

to:

1

for both the directory and SYSVOL versions.

Verifying the GPO Configuration

The setting was queried directly from the GPO:

Get-GPRegistryValue `
    -Name "Lab-IT-Test-Policy" `
    -Key "HKLM\Software\Lab-IT"

The result showed:

KeyPath     : Software\Lab-IT
FullKeyPath : HKEY_LOCAL_MACHINE\Software\Lab-IT
Hive        : LocalMachine
PolicyState : Set
Value       : Lab-IT-Test-Policy Applied
Type        : String
ValueName   : PolicyTest
HasValue    : True

This confirmed that the configuration existed inside the GPO.

However, this did not yet prove that a computer had actually processed the policy.

That distinction became the most important part of the exercise.

GPO Configuration Is Not the Same as GPO Application

At this point there were several different states:

The GPO existed

↓

The GPO was linked

↓

The GPO contained the test setting

But that still did not prove:

The setting had been applied to a computer.

To investigate actual processing, a live domain-joined machine was identified.

Identifying the Live Domain-Joined Machine

The current Windows Server machine was queried:

Get-CimInstance Win32_ComputerSystem |
    Select-Object Name, Domain, PartOfDomain

The result was:

Name            Domain   PartOfDomain
----            ------   ------------
WIN-URRN4NJRE9I corp.lab True

The machine was therefore joined to the corp.lab domain.

Its corresponding Active Directory computer object was then checked:

Get-ADComputer -Identity "WIN-URRN4NJRE9I" |
    Select-Object Name, Enabled, DistinguishedName

The result showed:

Name            Enabled DistinguishedName
----            ------- -----------------
WIN-URRN4NJRE9I True    CN=WIN-URRN4NJRE9I,OU=Domain Controllers,DC=corp,DC=lab

This revealed an important detail.

The live machine was a Domain Controller.

It was therefore not moved into Lab-Computers simply to make the test GPO apply. Doing so would have changed the intended Active Directory structure and potentially affected domain-controller policy processing.

Checking Actual Group Policy Processing

The next step was to check the Resultant Set of Policy information using:

gpresult /r /scope computer

The computer settings showed that the machine was receiving:

Applied Group Policy Objects

    Default Domain Controllers Policy
    Default Domain Policy

The test GPO was not listed.

This was expected because the live machine was located in:

OU=Domain Controllers,DC=corp,DC=lab

while the test GPO was linked to:

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

The test GPO was therefore outside the machine’s OU scope.

Independently Checking the Registry

The policy was then checked directly in the local registry:

Get-ItemProperty `
    -Path "HKLM:\Software\Lab-IT" `
    -Name "PolicyTest" `
    -ErrorAction SilentlyContinue

No output was returned.

This provided an independent confirmation that the test registry value had not been applied to the live Domain Controller.

The result demonstrated an important distinction:

The setting existed in the GPO

but:

The setting was not present on the live computer.

That was not a failure of the GPO configuration. It was a consequence of the GPO’s scope.

What the Test Demonstrated

The exercise demonstrated the difference between several stages of Group Policy administration:

GPO exists

↓

GPO is configured

↓

GPO is linked

↓

Computer is within the linked scope

↓

Group Policy processes the GPO

↓

Configuration appears on the computer

The live Domain Controller allowed the scope question to be tested without modifying the permanent domain structure.

This was more useful than simply seeing a policy apply, because it demonstrated why a correctly configured GPO may not appear in gpresult.

Removing the GPO Link

After the test was complete, the GPO was unlinked from Lab-Computers.

Remove-GPLink `
    -Name "Lab-IT-Test-Policy" `
    -Target $LabComputersOU.DistinguishedName

The OU inheritance was then checked again.

The final link state showed:

GpoLinks              : {}
InheritedGpoLinks     : {Default Domain Policy}
GpoInheritanceBlocked : No

The direct test link had been removed.

Deleting the Test GPO

The temporary GPO was then deleted:

Remove-GPO -Name "Lab-IT-Test-Policy"

A separate query was used to verify that it no longer existed:

Get-GPO -Name "Lab-IT-Test-Policy" -ErrorAction SilentlyContinue

No output was returned.

The GPO had therefore been removed rather than simply unlinked.

Final State

The target OU was checked one final time:

Get-GPInheritance -Target $LabComputersOU.DistinguishedName

The final state was:

GpoInheritanceBlocked : No
GpoLinks              : {}
InheritedGpoLinks     : {Default Domain Policy}

The final environment therefore contained:

• no Lab-IT-Test-Policy;
• no direct test GPO link on Lab-Computers;
• the existing Default Domain Policy inheritance;
• the original Lab-IT OU structure;
• the live Domain Controller remaining in the Domain Controllers OU;
• the existing LAB-TEST-PC01 computer object remaining in Lab-Computers.

The temporary configuration was completely cleaned up.

Verification Rather Than Assumption

One of the main lessons from this laboratory was that a successful administrative command is not necessarily proof of the final state.

For example:

New-GPLink succeeding proves that the link command completed.

It does not, by itself, prove that the intended computer processed the GPO.

Likewise:

Set-GPRegistryValue proves that a setting was written to the GPO.

It does not prove that the setting exists on a particular computer.

The laboratory therefore used several independent checks:

• Get-GPO
• Get-GPOReport
• Get-GPInheritance
• Get-GPRegistryValue
• gpresult
• direct registry inspection

This provided a much clearer picture of what was actually happening.

Why GPO Administration Matters for Security

Group Policy is not only a Windows administration mechanism.

It is also an important part of Windows security administration.

In a production environment, GPOs can control areas such as:

• security configuration;
• authentication behaviour;
• Windows Defender settings;
• firewall configuration;
• auditing;
• user rights;
• software configuration;
• administrative restrictions.

Because of this, understanding where a GPO is linked, who or what is in scope, and whether it was actually processed becomes important when investigating configuration changes or security incidents.

A policy that exists in Active Directory but is not within an object’s scope has a very different security impact from a policy that is actively being applied.

From Group Policy to Identity Security

This laboratory continues the progression from basic Active Directory administration towards identity and security work.

The previous exercises focused on:

Users

↓

Groups

↓

Organisational Units

This exercise added:

Group Policy

↓

Policy Scope

↓

Configuration Processing

That provides a foundation for later work involving:

Hybrid Identity

↓

Microsoft Entra ID

↓

Identity Security

↓

Detection Engineering

The underlying principle remains the same: understand the directory state first, then understand how configuration and access are applied to that state.

Conclusion

This laboratory provided practical experience with the Group Policy lifecycle:

Inspect → Link → Configure → Verify → Process → Validate → Unlink → Delete → Verify

The most useful result was not simply creating a working GPO.

It was demonstrating that:

A configured GPO is not necessarily an applied GPO.

The test GPO was correctly configured and linked to Lab-Computers, while the live Domain Controller remained outside that scope.

gpresult and direct registry inspection confirmed the actual result.

The exercise therefore reinforced a principle that applies broadly to infrastructure administration:

Do not stop at configuration. Verify the resulting state.

Repository

The complete command history, PowerShell output and validation evidence for this laboratory are maintained in the GitHub repository:

Lab 2.7 — Active Directory Group Policy Administration Fundamentals

The repository contains the detailed implementation record, while this article focuses on the reasoning, observations and practical lessons from the exercise.

Skills Demonstrated

• Active Directory Group Policy administration
• Windows PowerShell 5.1
• GroupPolicy PowerShell module
• GPO inspection
• GPO linking
• GPO configuration
• Group Policy inheritance
• OU-based policy scope
• Computer Configuration
• Registry-based GPO testing
• gpresult
• Resultant Set of Policy analysis
• Direct registry verification
• GPO lifecycle management
• Controlled cleanup
• Evidence-based infrastructure administration
• Windows security administration fundamentals