Focus: Microsoft Infrastructure Administration, Active Directory, Group Policy, PowerShell, GPO Scope, Policy Processing, Infrastructure Security
Technology: Windows Server 2025 Standard Evaluation | Oracle VirtualBox | Windows PowerShell 5.1 | Active Directory Domain Services (AD DS) | Group Policy
Domain: Microsoft Infrastructure Administration | Identity and Access Management | Enterprise Security Foundations
Objective
Following the Active Directory organisational-unit administration work from the previous laboratory, this exercise extended infrastructure administration into Group Policy management, GPO scope, policy processing and controlled configuration validation.
Group Policy provides a mechanism for applying configuration settings to users and computers according to their location and scope within Active Directory.
The laboratory focused on creating and managing a disposable test GPO, linking it to a controlled OU, configuring a harmless computer-side registry setting, examining policy inheritance, and verifying whether the policy was actually processed by a live domain-joined system.
The objectives were to:
- Administer Group Policy with PowerShell.
- Identify the existing Active Directory domain and OU structure.
- Inspect the initial GPO state.
- Create or identify a controlled test GPO.
- Link a GPO to a specific OU.
- Configure a harmless computer-side policy setting.
- Validate the GPO configuration independently.
- Understand GPO inheritance.
- Determine the scope of a GPO link.
- Verify Group Policy processing on a live domain-joined system.
- Distinguish between GPO configuration and actual policy application.
- Independently verify the resulting registry state.
- Safely remove the temporary GPO configuration.
- Validate the final Active Directory state.
The laboratory therefore extends the previous progression from directory structure and object placement into centralised Windows configuration management and policy scope.
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 and Target OU
The laboratory began by retrieving the Active Directory domain information directly.
The domain was confirmed as:
corp.lab
with the Distinguished Name:
DC=corp,DC=lab
The existing laboratory OU structure was then inspected.
The target OU for the exercise was:
OU=Lab-Computers,OU=Lab-IT,DC=corp,DC=lab
This OU already existed from the previous laboratory and provided a controlled scope for testing Group Policy.
The approach continued the same principle used throughout the infrastructure labs:
Discover the environment → identify the intended target → make the controlled change
Inspecting the Group Policy Environment
The Group Policy PowerShell module was confirmed to be available.
The installed module was:
GroupPolicy 1.0.0.0
The initial domain GPO inventory was then queried.
Before the test policy was configured, the domain contained the standard:
Default Domain PolicyDefault Domain Controllers Policy
These existing policies were deliberately left unchanged.
This was important because the purpose of the laboratory was to learn GPO administration without modifying the domain’s permanent baseline policies.
Discovering the Existing Test GPO
The laboratory plan called for a disposable test GPO named:
Lab-IT-Test-Policy
When the GPO creation command was executed, Active Directory reported that a GPO with this name already existed.
The command therefore did not create a new GPO.
The existing object was then inspected directly.
Its state was confirmed as:
- Name:
Lab-IT-Test-Policy - GPO Status:
AllSettingsEnabled - GUID:
7d84da3d-02f9-40db-adb5-a9e24670ea9f
The GPO creation and modification timestamps were also inspected.
This became an important part of the laboratory because it demonstrated that an administrative command can produce an unexpected environmental condition.
Rather than assuming that the requested object had been created, the existing state was queried and analysed.
Initial GPO Configuration
An XML GPO report was generated before making configuration changes.
The report showed that the GPO existed in the corp.lab domain but did not yet contain the substantive test registry configuration used later in the exercise.
The computer configuration version was initially:
Directory Version: 0
SYSVOL Version: 0
The GPO also had the expected domain ownership and security information.
This established a baseline before configuration.
The workflow was therefore:
Existing GPO identified
↓
Initial configuration inspected
↓
Controlled setting added
↓
Configuration independently verified
Understanding GPO Scope
Before linking the test policy, inheritance information for the target OU was inspected.
The Lab-Computers OU initially had:
- no direct GPO links;
- the
Default Domain Policyinherited from the domain; - inheritance blocking disabled.
The parent Lab-IT OU was also inspected and had no direct GPO links.
This established an important Group Policy concept:
A GPO existing in Active Directory does not mean that it is being applied to a computer.
For the policy to affect an object, the GPO must be appropriately linked and within the object’s policy-processing scope.
Linking the Test GPO
The existing test GPO was linked to:
OU=Lab-Computers,OU=Lab-IT,DC=corp,DC=lab
The link was created as enabled.
The resulting link state confirmed:
- GPO:
Lab-IT-Test-Policy - Link: Enabled
- Enforced: False
- Target:
Lab-Computers - Link order: 1
The OU inheritance information was then queried again.
The result showed:
Lab-IT-Test-Policy
as a direct GPO link on Lab-Computers.
The inherited policy list now contained both:
Lab-IT-Test-PolicyDefault Domain Policy
This independently confirmed that the link had actually been established.
Configuring a Harmless Computer Policy
A controlled computer-side registry setting was added to the test GPO.
The policy configured:
HKLM\Software\Lab-IT
with the value:
PolicyTest = Lab-IT-Test-Policy Applied
The setting was deliberately chosen to be harmless and observable.
The purpose was not to change an important Windows security or operational setting, but to create a clear state that could later be checked independently.
After configuration, the GPO reported:
Computer Version:
Directory Version 1
SYSVOL Version 1
This indicated that the computer-side policy configuration had changed.
Independent GPO Configuration Verification
The configured registry policy was then queried directly through the Group Policy PowerShell module.
The resulting state confirmed:
- Key path:
Software\Lab-IT - Value name:
PolicyTest - Policy state:
Set - Value:
Lab-IT-Test-Policy Applied - Type:
String
This provided independent evidence that the setting existed inside the GPO configuration.
However, this did not yet prove that a computer had processed the setting.
That distinction was central to the exercise.
GPO Configuration Versus Policy Application
One of the most important lessons from the laboratory was the difference between:
A setting existing inside a GPO
and:
The setting being applied to a computer
The configuration chain can therefore be represented as:
GPO exists
↓
GPO contains a setting
↓
GPO is linked
↓
Computer is within the link’s scope
↓
Group Policy processes the GPO
↓
Resulting configuration appears on the computer
Each stage represents a separate condition.
The laboratory deliberately verified these stages rather than treating the successful execution of the configuration commands as proof of final application.
Identifying the Live Domain-Joined System
The environment was then inspected for an actual domain-joined computer.
The system returned:
WIN-URRN4NJRE9I
with:
Domain: corp.lab
PartOfDomain: True
The corresponding Active Directory computer object was then inspected.
The computer was confirmed to be located in:
OU=Domain Controllers,DC=corp,DC=lab
and was enabled.
This was a critical environmental discovery.
The live Windows Server system was a Domain Controller, not a member computer located in Lab-Computers.
Therefore, it was deliberately not moved into the laboratory OU merely to force the test policy to apply.
Verifying Actual Group Policy Processing
Computer-side Group Policy processing was then inspected using:
gpresult /r /scope computer
The resulting report showed that the live Domain Controller had processed:
Default Domain Controllers PolicyDefault Domain Policy
The test GPO:
Lab-IT-Test-Policy
was not present in the list of applied GPOs.
This was the expected result based on the actual Active Directory scope.
The test policy was linked to Lab-Computers, while the live system was located in Domain Controllers.
The test GPO therefore did not apply to the live Domain Controller.
This demonstrated an important distinction between GPO configuration and GPO scope.
Independent Registry Verification
The computer’s actual registry was then queried for:
HKLM:\Software\Lab-IT
and the value:
PolicyTest
No value was returned.
This provided independent confirmation that the test policy setting had not been applied to the live Domain Controller.
The result was consistent with the Group Policy processing evidence.
The complete reasoning was therefore:
GPO contains the setting
↓
GPO is linked to Lab-Computers
↓
Live system is in Domain Controllers
↓
Test GPO is not applied
↓
Registry value is absent
This provided a practical demonstration of how policy scope determines actual configuration.
Controlled GPO Cleanup
Once the processing and scope behaviour had been verified, the temporary policy configuration was removed.
The first step was to remove the GPO link from:
Lab-Computers
The OU inheritance state was then queried again.
The result showed:
- no direct GPO links;
Default Domain Policyremaining inherited;- inheritance blocking still disabled.
This independently confirmed that the link had been removed.
The GPO itself was then deleted.
A direct lookup for:
Lab-IT-Test-Policy
returned no result.
The GPO was therefore independently verified as absent.
Final Active Directory and Group Policy State
The final state of the target OU was queried again.
The resulting configuration showed:
Lab-Computersstill existed.- No direct test GPO links remained.
Default Domain Policyremained inherited.- Group Policy inheritance was not blocked.
Lab-IT-Test-Policyhad been deleted.
The permanent Active Directory structure was therefore left intact.
The existing Domain Controller was not moved or otherwise modified to force the test policy to apply.
The laboratory computer object:
LAB-TEST-PC01
also remained an Active Directory object in Lab-Computers, rather than being treated as evidence of a live endpoint.
The temporary Group Policy configuration was completely removed.
Verification and State Management
The laboratory reinforced a recurring infrastructure-administration principle:
Command success ≠ desired state confirmed
For Group Policy, this distinction is particularly important.
Creating or locating a GPO does not prove that it contains the intended settings.
Configuring a setting does not prove that the GPO is linked.
A link does not prove that a particular computer is within scope.
A computer being within scope does not by itself prove that the policy has processed successfully.
The laboratory therefore used multiple forms of evidence:
- Active Directory queries
- GPO inventory
- GPO inheritance inspection
- GPO registry-setting inspection
- XML GPO reporting
gpresult- Direct registry inspection
- Final cleanup verification
This provided independent checks at different points in the policy-processing chain.
Security and Infrastructure Perspective
Group Policy is an important part of Windows infrastructure security because it provides centralised control over configuration across domain-joined systems.
A policy can affect settings related to:
- security configuration
- authentication behaviour
- system configuration
- software and administrative controls
- user and computer environments
This means that GPO administration is not simply a configuration-management task.
Changes to GPO scope, inheritance or enforcement can potentially affect large numbers of systems.
The laboratory therefore used a deliberately limited OU and a harmless test setting rather than modifying the Default Domain Policy or Default Domain Controllers Policy.
This reflects an important administrative principle:
Test narrowly before applying configuration broadly.
Group Policy and Identity Infrastructure
The laboratory also demonstrated the relationship between Active Directory structure and Group Policy.
The policy-processing path can be simplified as:
Active Directory Object
↓
OU Placement
↓
GPO Link
↓
Policy Scope
↓
Group Policy Processing
↓
Resulting System Configuration
This connects directly with the previous OU administration laboratory.
OU structure is not merely a way of organising objects.
Object placement can influence which Group Policies are within scope.
Consequently, changes to directory structure can have configuration and security consequences.
From Directory Structure to Policy Administration
The progression through the Active Directory laboratories can now be viewed as:
Active Directory infrastructure
↓
User administration
↓
Group administration
↓
Organisational Unit administration
↓
Object placement
↓
Group Policy administration
↓
Policy scope and processing
↓
Windows security configuration
↓
Hybrid Identity
↓
Microsoft Entra ID
↓
Identity Security
↓
Detection Engineering
The laboratory therefore adds another layer to the infrastructure foundation required for identity and security work.
Understanding how directory objects, OUs and policies interact is particularly relevant when investigating authentication, access and configuration-related security events.
Key Takeaway
The main lesson from this laboratory was that Group Policy administration is fundamentally a scope and state-management problem.
A robust GPO workflow should establish:
- Which domain is being administered.
- Which OU is the intended target.
- Which GPO exists.
- What configuration the GPO contains.
- Where the GPO is linked.
- Which systems are within scope.
- Whether the policy was actually processed.
- Whether the expected configuration appeared on the target system.
- Whether temporary configuration can be safely removed.
The methodology can be summarised as:
Establish expected state
↓
Configure controlled policy
↓
Link to a defined scope
↓
Verify policy processing
↓
Independently verify resulting configuration
↓
Remove temporary configuration
↓
Confirm final state
This provides a practical foundation for Windows infrastructure administration, security configuration, hybrid identity and future identity-security work.
Evidence
The complete PowerShell commands, output, GPO configuration evidence, inheritance checks, policy-processing results and cleanup verification are documented in the laboratory repository.
GitHub laboratory documentation:
Lab 2.7 — Active Directory Group Policy Administration Fundamentals
The repository contains the technical implementation and evidence demonstrating GPO inspection, controlled configuration, OU linking, scope analysis, policy-processing verification and cleanup.
Skills Demonstrated
- Active Directory Group Policy administration
- Windows PowerShell 5.1
- GroupPolicy PowerShell module
- GPO inspection
- GPO configuration
- GPO linking
- GPO inheritance analysis
- Group Policy scope analysis
- Computer-side policy configuration
- Registry-based policy configuration
gpresultanalysis- XML GPO reporting
- Active Directory object discovery
- State validation
- Independent verification
- Controlled configuration testing
- Safe administrative cleanup
- Windows infrastructure security fundamentals
- 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
↓
2.7 Active Directory Group Policy 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
- Group Policy administration
- Policy scope and processing
- Windows security configuration
- Hybrid identity
- Microsoft Entra ID
- Azure administration
- Identity security
- Detection Engineering
Laboratory 2.7 therefore extends the practical identity-administration layer from directory structure and object placement into centralised configuration, policy scope and Windows infrastructure security.