Stage an Enterprise GPO Hardening Pilot

Build a recoverable GPO hardening pilot with isolated domain controllers.

Introduction

30 Second Summary

One security setting can affect every server it reaches. A small test group limits the impact while a reliable backup keeps recovery within reach.

In this project, you will design a recoverable hardening pilot for an existing Windows Server 2022 Active Directory domain. Three staged Group Policy Objects will target an empty server ring while DC01 plus DC02 stay unaffected.

What You'll Build

You open three hardening reports in Group Policy Management Console to show their pilot-only links plus clear proof that DC01 plus DC02 remain outside the deployment scope.

By the end of this project, you'll have:

  • A recoverable starting point with dated AD DS health evidence plus one backup instance for every existing GPO.
  • A protected server deployment ring that keeps Pilot empty for future member servers. DC01 plus DC02 remain outside its scope.
  • Three reviewable hardening reports showing sign-in protection, legacy-protocol controls, plus firewall defaults. Each policy link points only to Pilot.
  • Secret Mission: Create a controlled regression in the empty-scope legacy-protocol GPO. Restore it from backup to prove the secure setting returns.

Are there any prerequisites?

You need DC01 plus DC02 running as Windows Server 2022 domain controllers in VMware Workstation Pro.

You also need Domain Admin access or delegated equivalent access.

Internet access is required briefly to download Microsoft Security Compliance Toolkit 1.0.

Before We Start

This project begins by setting a safety boundary for your hardening pilot. You will keep DC01 and DC02 outside the new GPO scope while you build a recoverable path for testing future member servers.

Verify the Administration Toolkit

Safe Group Policy hardening starts with proof that your Active Directory administration tools can read the domain before you make a change.

In this step, you will verify Windows PowerShell on DC01. You will prepare the local evidence workspace for the Microsoft Security Compliance Toolkit 1.0 baseline.

In this step, get ready to:
  • Confirm the required Active Directory and Group Policy commands run on DC01.
  • Create the local folders that will hold backups and reports.
  • Prepare the Microsoft baseline package as local reference material.
Verify the management tools

The Active Directory module provides Get-ADDomain. Group Policy Management provides the Get-GPO cmdlet.

  • Press the Windows key on DC01 to open the search bar.
  • Type Windows PowerShell into the search bar.
  • Choose the administrator option for Windows PowerShell.
  • Approve the Windows permission prompt.

Before you run the checks, do you expect DC01 to recognize both commands? Hold that prediction for the output.

  • Test the Active Directory and Group Policy tools by running:
Get-ADDomain
Get-GPO -All

What do these checks prove?

  • The Get-ADDomain result proves that the Active Directory module can return the current domain.
  • The Get-GPO -All result proves that the GroupPolicy module can enumerate existing GPOs.
  • If a command is unavailable, Server Manager can add the missing administration tools.

✔️ Both commands return results

Good. DC01 can read the domain and enumerate its existing GPOs.

  • Press the Windows key to open the search bar.
  • Type Server Manager and press Enter.
  • Select Tools in the top-right corner.
  • Select Group Policy Management.

The Group Policy Management Console should load the forest and domain tree.

  • Close Group Policy Management.
  • Return to Server Manager.
  • Select Tools.
  • Select Active Directory Users and Computers.

The Active Directory Users and Computers console should load your domain tree.

ⓧ A command is unavailable

One missing command means one management feature needs attention. Install the supported administration tools through Server Manager before repeating the check.

  • Press the Windows key to open the search bar.
  • Type Server Manager and press Enter.
  • Select Manage in the top-right corner.
  • Select Add Roles and Features.
  • Select Next until you reach Features.
  • Expand Remote Server Administration Tools.
  • Expand Role Administration Tools.
  • Select AD DS and AD LDS Tools.

The Active Directory administration tools are now selected. Add the Group Policy feature before installing.

  • Select Group Policy Management.
  • Select Next.
  • Select Install.
  • Wait for the feature installation to finish.
  • Select Close.
  • Return to the elevated Windows PowerShell session from earlier.
  • Repeat the management tool check by running:
Get-ADDomain
Get-GPO -All

What changed?

  • The AD DS and AD LDS Tools feature supplies the Active Directory module and administration consoles.
  • The Group Policy Management feature supplies the Group Policy console and cmdlets.

You should now see domain details followed by the existing GPOs.

  • Return to Server Manager.
  • Select Tools.
  • Select Group Policy Management.

The Group Policy Management Console should load the forest and domain tree.

  • Close Group Policy Management.
  • Return to Server Manager.
  • Select Tools.
  • Select Active Directory Users and Computers.

The Active Directory Users and Computers console should load your domain tree.

Still missing a management command?

If Get-ADDomain remains unavailable, confirm that AD DS and AD LDS Tools completed installation.

If Get-GPO -All remains unavailable, confirm that Group Policy Management completed installation.

Start a fresh elevated Windows PowerShell session after correcting the missing feature. Help me troubleshoot missing Active Directory or Group Policy commands on DC01.

Create the evidence folders

A dedicated evidence workspace keeps policy backups separate from reports. It also reserves an isolated folder for the later rollback drill.

  • Press the Windows key to open the search bar.
  • Type File Explorer and press Enter.
  • Enter C:\ in the address bar.
  • Use the folder creation control in the toolbar to create LabEvidence.
  • Open the C:\LabEvidence folder.
  • Create a folder named GPO-Backups.
  • Create a folder named Reports.
  • Create a folder named Rollback-Drill.

You should see three empty folders inside C:\LabEvidence. Your evidence workspace is ready for the diagnostics and backups created later.

How will these folders be used?

  • The GPO-Backups folder will hold point-in-time backups of the domain GPOs.
  • The Reports folder will hold diagnostic text files and GPO HTML reports.
  • The Rollback-Drill folder will isolate the dedicated legacy-protocol rollback backup.
Download and review the security baseline

A security baseline gives you Microsoft-recommended configuration guidance for specific Windows roles. You will use this package as reference material without applying its policies.

  • Press the Windows key to open the search bar.
  • Type the name of your browser and press Enter.
  • Navigate to the Microsoft Security Compliance Toolkit download page.
  • Select Windows Server 2022 Security Baseline.zip.
  • Start the download.
  • Save the archive as C:\LabEvidence\Windows Server 2022 Security Baseline.zip.
  • Switch back to the elevated Windows PowerShell session from earlier.
  • Extract the downloaded baseline package by running:
Expand-Archive -Path 'C:\LabEvidence\Windows Server 2022 Security Baseline.zip' -DestinationPath 'C:\LabEvidence\Windows Server 2022 Security Baseline'

What does this command do?

The Expand-Archive cmdlet reads the downloaded ZIP archive. It extracts the contents into C:\LabEvidence\Windows Server 2022 Security Baseline.

This command only extracts local reference files. It does not apply a baseline or change Group Policy.

  • Return to File Explorer from earlier.
  • Open C:\LabEvidence\Windows Server 2022 Security Baseline.

You should see the extracted baseline files and included documentation.

Archive did not extract?

Confirm that the downloaded file is named Windows Server 2022 Security Baseline.zip inside C:\LabEvidence.

Check that the destination folder does not contain a partial extraction from an earlier attempt.

Help me troubleshoot the baseline archive extraction.

  • Locate the documentation included with the extracted baseline.
  • Identify the guidance intended for domain controllers.
  • Identify the guidance intended for domain security.
  • Identify the guidance intended for member servers.
  • Leave every included baseline unapplied.

Why use the Microsoft baseline?

The toolkit package includes GPO backups and GPO reports. It also includes spreadsheets and supporting scripts.

These materials map Microsoft guidance directly to Windows Group Policy workflows. That makes the package a practical reference for the staged pilot.

Before the final check, do you expect the management commands to return the same domain information after preparing the local files? Hold that prediction while you rerun them.

  • Return to the elevated Windows PowerShell session from earlier.
  • Run the final toolkit check:
Get-ADDomain
Get-GPO -All

What should the final check show?

You should see domain details from Get-ADDomain. You should then see the existing GPOs from Get-GPO -All.

  • Switch back to File Explorer from earlier.
  • Open C:\LabEvidence\Windows Server 2022 Security Baseline.

You should see the baseline files and documentation you reviewed. That gives DC01 a working administration toolkit plus a local source of hardening guidance.

✔️ Everything is ready

Your DC01 administration toolkit and local evidence workspace match the required starting state.

ⓧ I'd like to double check

  • The empty C:\LabEvidence\GPO-Backups folder exists for backups of all existing domain GPOs.
  • The empty C:\LabEvidence\Reports folder exists for diagnostic files and GPO HTML reports.
  • The empty C:\LabEvidence\Rollback-Drill folder exists for the dedicated legacy-protocol GPO rollback drill.
  • The C:\LabEvidence\Windows Server 2022 Security Baseline folder contains the extracted Microsoft baseline files and reviewed documentation.
  • Elevated Windows PowerShell on DC01 can run Get-ADDomain and Get-GPO -All.
  • Group Policy Management Console and Active Directory Users and Computers are available on DC01.

Your administration toolkit and baseline reference are ready. Next, you will capture directory health evidence before backing up every existing GPO.

Capture Health Evidence and Back Up Every GPO

Your administration toolkit is ready on DC01. The next safeguard is a pre-change record of Active Directory Domain Services health.

An unhealthy directory can make a later hardening change difficult to diagnose. Targeted Group Policy backups provide rollback for policy mistakes. Domain controller disaster recovery still needs system-state coverage.

In this step, get ready to:
  • Capture pre-change AD DS diagnostic evidence.
  • Confirm replication summaries show zero failures.
  • Create a point-in-time backup of every existing GPO.
Establish the AD DS health gate

The dcdiag command tests domain controller health across the enterprise. Its verbose output creates evidence that the directory was checked before any hardening changes.

  • Switch back to the elevated Windows PowerShell session on DC01.
  • Save enterprise-wide diagnostic output to dcdiag.txt by running this command:
dcdiag /e /v /f:C:\LabEvidence\Reports\dcdiag.txt

What does this command capture?

  • The /e option tests every domain controller in the enterprise.
  • The /v option records verbose test details for the health review.
  • The /f: option writes the diagnostic evidence to C:\LabEvidence\Reports\dcdiag.txt.
  • Switch back to File Explorer on DC01.
  • Enter C:\LabEvidence\Reports in the address bar.
  • Open dcdiag.txt.
  • Review every failed test in the report.
  • Stop this project if an unresolved AD DS, DNS, SYSVOL, or connectivity failure remains.

That first health gate is clear once the review has no unresolved failures. You now have a pre-change directory health record.

Seeing an unresolved directory failure?

  • Investigate the named component on the affected domain controller before continuing.
  • Rerun the diagnostic command shown above after correcting the cause.

Use this diagnostic output to get focused help: Help me interpret my dcdiag failures.

Verify replication health

Healthy domain controllers must replicate directory changes without recorded failures. The repadmin summary provides a second health gate focused on replication.

  • Save a source and destination replication summary to repadmin.txt by running this command in the same elevated session:
repadmin /replsum /bysrc /bydest /sort:delta > C:\LabEvidence\Reports\repadmin.txt

What does this command capture?

  • The summary groups replication results by source and destination domain controller.
  • The /sort:delta option sorts the results by the longest replication delta.
  • The redirection operator saves the summary to C:\LabEvidence\Reports\repadmin.txt.
  • Return to the C:\LabEvidence\Reports folder in File Explorer.
  • Open repadmin.txt.
  • Confirm every domain controller shows 0 in the failure columns.

You should see DC01 and DC02 with zero replication failures. Your saved evidence now covers directory diagnostics plus replication health.

Seeing replication failures?

  • Identify the source or destination domain controller with a nonzero failure count.
  • Resolve the replication issue before creating the GPO backups.
  • Rerun the replication summary command shown above after the fix.

Use the affected controller details to get targeted help: Help me investigate my replication failures.

Back up every existing GPO

A GPO backup preserves policy settings for targeted rollback. This backup set does not include the directory database or the other components required for domain controller recovery.

  • Return to the elevated Windows PowerShell session on DC01.
  • Back up every existing GPO to C:\LabEvidence\GPO-Backups by running this command:
Backup-GPO -All -Path 'C:\LabEvidence\GPO-Backups' -Comment 'Before staged hardening lab'

What does this backup protect?

  • The -All option selects every GPO in the domain.
  • The -Path option stores the backup instances in the existing evidence folder.
  • The -Comment option labels each instance with 'Before staged hardening lab'.

This folder supports GPO-level rollback. System-state or forest recovery requires separate backup coverage.

Before you check, make a prediction about how the backup entry count should compare with the original GPO count.

  • Press the Windows key to open the search bar.
  • Type Group Policy Management into the search bar.
  • Press Enter to open Group Policy Management.
  • Expand your domain in the console tree.
  • Right-click Group Policy Objects.
  • Select Manage Backups.
  • Point the backup manager at C:\LabEvidence\GPO-Backups.
  • Confirm every GPO that existed before this lab has a backup instance in the list.

You should see one point-in-time backup instance for every existing GPO. That policy rollback point is now verified without changing any GPO.

Missing a GPO backup?

  • Confirm Manage Backups points to C:\LabEvidence\GPO-Backups.
  • Rerun the backup command shown above from the elevated Windows PowerShell session if an expected GPO is missing.

Use the missing GPO name to get focused help: Help me troubleshoot my incomplete GPO backup set.

Your directory health evidence and GPO rollback point are ready. Next, you'll build a protected OU hierarchy with an empty pilot deployment ring.

Build the Protected Pilot OU Hierarchy

Your pre-change AD DS health evidence is clean. Every existing Group Policy Object (GPO) now has a point-in-time rollback copy.

A domain-wide Group Policy link would expose every server to untested settings. Role-based organizational units create smaller policy boundaries with a controlled blast radius.

An empty Pilot OU gives future member servers an isolated deployment ring. Active Directory Users and Computers provides the visual check that DC01 and DC02 remain outside it.

In this step, get ready to:
  • Create the protected root OU plus its privilege boundaries.
  • Create the protected member-server branch with empty deployment rings.
  • Confirm the empty Pilot ring plus the unchanged Domain Controllers OU.
Create the protected privilege boundaries

The root OU creates a dedicated boundary for this lab. Its child OUs separate privileged computers from privileged identities and service accounts.

  • Switch back to the elevated Windows PowerShell session on DC01.
  • Build the root path plus its four protected child OUs by running this block:
$domainDN = (Get-ADDomain).DistinguishedName
$rootDN = "OU=Enterprise Lab,$domainDN"
New-ADOrganizationalUnit -Name 'Enterprise Lab' -Path $domainDN -ProtectedFromAccidentalDeletion $true
New-ADOrganizationalUnit -Name 'Tier 0' -Path $rootDN -ProtectedFromAccidentalDeletion $true
New-ADOrganizationalUnit -Name 'Tier 1' -Path $rootDN -ProtectedFromAccidentalDeletion $true
New-ADOrganizationalUnit -Name 'Privileged Identities' -Path $rootDN -ProtectedFromAccidentalDeletion $true
New-ADOrganizationalUnit -Name 'Service Accounts' -Path $rootDN -ProtectedFromAccidentalDeletion $true

What does this block create?

  • The $domainDN variable captures the current domain distinguished name through Get-ADDomain.
  • The $rootDN variable builds the distinguished name for Enterprise Lab.
  • The New-ADOrganizationalUnit commands create the root plus four role-based boundaries.
  • The protection flag guards each new OU against accidental deletion.
  • Check that PowerShell returns to the prompt without reporting an error.

Good progress. Your domain now has a protected home for the pilot architecture.

Did an OU fail to create?

  • Use the elevated PowerShell session from earlier before retrying the block.
  • Compare $domainDN with the distinguished name returned by Get-ADDomain.
  • Check whether an OU with the same name already exists before running its creation command again.

Help me diagnose why the protected Enterprise Lab OUs were not created.

Add the member-server deployment rings

The member-server branch separates future workloads from privileged boundaries. Its children provide distinct rings for pilot testing and role-based placement.

  • Extend Tier 1 into three empty deployment rings by running this block:
$tier1DN = "OU=Tier 1,$rootDN"
$serversDN = "OU=Member Servers,$tier1DN"
New-ADOrganizationalUnit -Name 'Member Servers' -Path $tier1DN -ProtectedFromAccidentalDeletion $true
New-ADOrganizationalUnit -Name 'Pilot' -Path $serversDN -ProtectedFromAccidentalDeletion $true
New-ADOrganizationalUnit -Name 'Application' -Path $serversDN -ProtectedFromAccidentalDeletion $true
New-ADOrganizationalUnit -Name 'Database' -Path $serversDN -ProtectedFromAccidentalDeletion $true

How are the deployment rings arranged?

  • The $tier1DN variable points to the existing Tier 1 OU.
  • The $serversDN variable identifies the new Member Servers branch.
  • The Pilot, Application, and Database OUs create separate destinations for future member servers.
  • Every new OU keeps accidental deletion protection enabled.
  • Check that PowerShell returns to the prompt without reporting an error.

The deployment rings are now in place. Pilot is ready to act as the smallest test boundary.

Could PowerShell not find the parent OU?

  • Confirm that Enterprise Lab plus Tier 1 completed in the previous chunk.
  • Compare $tier1DN with the hierarchy created under $rootDN.
  • Run the missing parent OU command before retrying its child command.

Help me find the broken distinguished name in my member-server OU hierarchy.

✔️ Awesome, I've got everything!

Your PowerShell commands completed without errors. Continue to the visual hierarchy check.

ⓧ I'd like to double check the full code

Compare your two PowerShell blocks with the complete OU creation sequence below:

$domainDN = (Get-ADDomain).DistinguishedName
$rootDN = "OU=Enterprise Lab,$domainDN"
New-ADOrganizationalUnit -Name 'Enterprise Lab' -Path $domainDN -ProtectedFromAccidentalDeletion $true
New-ADOrganizationalUnit -Name 'Tier 0' -Path $rootDN -ProtectedFromAccidentalDeletion $true
New-ADOrganizationalUnit -Name 'Tier 1' -Path $rootDN -ProtectedFromAccidentalDeletion $true
New-ADOrganizationalUnit -Name 'Privileged Identities' -Path $rootDN -ProtectedFromAccidentalDeletion $true
New-ADOrganizationalUnit -Name 'Service Accounts' -Path $rootDN -ProtectedFromAccidentalDeletion $true

$tier1DN = "OU=Tier 1,$rootDN"
$serversDN = "OU=Member Servers,$tier1DN"
New-ADOrganizationalUnit -Name 'Member Servers' -Path $tier1DN -ProtectedFromAccidentalDeletion $true
New-ADOrganizationalUnit -Name 'Pilot' -Path $serversDN -ProtectedFromAccidentalDeletion $true
New-ADOrganizationalUnit -Name 'Application' -Path $serversDN -ProtectedFromAccidentalDeletion $true
New-ADOrganizationalUnit -Name 'Database' -Path $serversDN -ProtectedFromAccidentalDeletion $true

What should match?

This sequence derives every child distinguished name from the current domain. It creates only the protected OU hierarchy for this step.

Verify the empty Pilot boundary

An empty deployment ring gives you a place to stage future policy without targeting a live server. The final check confirms that the hierarchy matches this design.

Before you refresh, predict which containers you expect under Enterprise Lab.

  • Press the Windows key on DC01.
  • Type Active Directory Users and Computers into the search bar.
  • Press Enter.
  • Expand your domain in the console tree.
  • Right-click your domain node.
  • Select Refresh.
  • Expand Enterprise Lab.
  • Expand Tier 1.

Under Enterprise Lab, you'll see Tier 0, Tier 1, Privileged Identities, and Service Accounts.

  • Expand Member Servers.

Under Member Servers, you'll see Pilot, Application, and Database.

  • Select Pilot.

The details pane contains no computer objects for Pilot. This empty result proves that no live server is inside the deployment ring.

  • Select the built-in Domain Controllers OU.

You'll still see DC01 and DC02 in the built-in Domain Controllers OU. Neither computer object has moved into Enterprise Lab.

  • Return to Pilot under Member Servers.

You now have protected role boundaries plus an empty deployment ring. DC01 and DC02 remain outside the new hierarchy.

Your pilot boundary is ready. Next, you'll stage three hardening GPOs without linking them to a target.

Stage the Hardening GPOs

Your protected OU hierarchy now limits the future blast radius. An OU alone changes no security settings.

This step creates three Group Policy Objects. You will keep every GPO unlinked so the domain controllers remain outside the policy scope.

In this step, get ready to:
  • Create three unlinked pilot GPOs.
  • Configure six registry-backed controls across the three GPOs.
  • Prove that DC01 remains outside their scope.
Create the unlinked GPOs

Separate GPOs make each hardening area easier to review. Their comments also record that the policies belong to the pilot.

  • Switch back to the elevated Windows PowerShell session on DC01.
  • Create the three pilot-only GPOs by running these commands:
New-GPO -Name 'LAB-WS2022-Member-Server-Baseline' -Comment 'Staged sign-in protections for member servers. Pilot only.'
New-GPO -Name 'LAB-WS2022-Firewall-Baseline' -Comment 'Staged domain-profile firewall defaults for member servers. Pilot only.'
New-GPO -Name 'LAB-WS2022-Legacy-Protocol-Hardening' -Comment 'Staged LLMNR and insecure SMB guest-logon controls. Pilot only.'

What do these commands create?

  • The member-server GPO holds controls that reduce information exposure on the sign-in screen.
  • The firewall GPO holds the domain-profile firewall defaults.
  • The legacy-protocol GPO holds the SMB guest-logon control plus the LLMNR control.
  • Each New-GPO command creates an unlinked GPO by default.
  • Review the GPO objects returned by Windows PowerShell.

PowerShell prints one GPO object per command. Each object shows the new GPO name before the prompt returns.

Did a GPO fail to appear?

Confirm that the elevated session is running on DC01. A failure at this point commonly indicates a permissions problem or an unavailable Group Policy module.

Ask for help with the failed command before creating any links. Help me troubleshoot a New-GPO command that failed on DC01.

Configure the registry-backed controls

A registry-backed policy stores a defined registry value inside a GPO. These six values form a small member-server hardening portfolio that is easy to inspect.

  • Write the six hardening values into the three new GPOs by running these commands:
Set-GPRegistryValue -Name 'LAB-WS2022-Member-Server-Baseline' -Key 'HKLM\SOFTWARE\Policies\Microsoft\Windows\System' -ValueName 'BlockUserFromShowingAccountDetailsOnSignin' -Type DWord -Value 1
Set-GPRegistryValue -Name 'LAB-WS2022-Member-Server-Baseline' -Key 'HKLM\SOFTWARE\Policies\Microsoft\Windows\System' -ValueName 'DontEnumerateConnectedUsers' -Type DWord -Value 1
Set-GPRegistryValue -Name 'LAB-WS2022-Legacy-Protocol-Hardening' -Key 'HKLM\SOFTWARE\Policies\Microsoft\Windows\LanmanWorkstation' -ValueName 'AllowInsecureGuestAuth' -Type DWord -Value 0
Set-GPRegistryValue -Name 'LAB-WS2022-Legacy-Protocol-Hardening' -Key 'HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient' -ValueName 'EnableMulticast' -Type DWord -Value 0
Set-GPRegistryValue -Name 'LAB-WS2022-Firewall-Baseline' -Key 'HKLM\SOFTWARE\Policies\Microsoft\WindowsFirewall\DomainProfile' -ValueName 'EnableFirewall' -Type DWord -Value 1
Set-GPRegistryValue -Name 'LAB-WS2022-Firewall-Baseline' -Key 'HKLM\SOFTWARE\Policies\Microsoft\WindowsFirewall\DomainProfile' -ValueName 'DefaultInboundAction' -Type DWord -Value 1

What do these values control?

  • The BlockUserFromShowingAccountDetailsOnSignin value of 1 enables the sign-in account-detail restriction.
  • The DontEnumerateConnectedUsers value of 1 prevents connected-user enumeration.
  • The AllowInsecureGuestAuth value of 0 disables insecure SMB guest logons.
  • The EnableMulticast value of 0 turns off LLMNR.
  • The EnableFirewall value of 1 enables the domain firewall profile.
  • The DefaultInboundAction value of 1 blocks unmatched inbound traffic.
  • Check that Windows PowerShell returns to the prompt without displaying red error text.

All six registry-backed policy writes are now complete. The next report commands turn those settings into evidence you can inspect.

Did a registry value fail?

Check the failed command against the GPO name returned in the previous chunk. A single character difference prevents Windows PowerShell from finding the intended GPO.

Rerun only the failed command after correcting the mismatch. Help me troubleshoot a Set-GPRegistryValue command that failed on DC01.

Capture reports and prove isolation

An HTML report records configured settings plus link details. A Resultant Set of Policy check answers a different question by showing which computer policies actually reach DC01.

  • Generate one HTML report for each staged GPO by running these commands:
Get-GPOReport -Name 'LAB-WS2022-Member-Server-Baseline' -ReportType Html -Path 'C:\LabEvidence\Reports\MemberServerBaseline.html'
Get-GPOReport -Name 'LAB-WS2022-Firewall-Baseline' -ReportType Html -Path 'C:\LabEvidence\Reports\FirewallBaseline.html'
Get-GPOReport -Name 'LAB-WS2022-Legacy-Protocol-Hardening' -ReportType Html -Path 'C:\LabEvidence\Reports\LegacyProtocolHardening.html'

What do the reports prove?

  • The member-server report records both sign-in controls.
  • The firewall report records both domain-profile controls.
  • The legacy-protocol report records the SMB guest-logon control plus the LLMNR control.
  • The link details show that the staged GPOs have no deployment target.
  • Press the Windows key to open the search bar.
  • Type File Explorer into the search bar.
  • Press Enter to open File Explorer.
  • Select the address bar.
  • Enter C:\LabEvidence\Reports.
  • Press Enter to load the reports folder.

You should see MemberServerBaseline.html, FirewallBaseline.html, plus LegacyProtocolHardening.html. These files are your configured-policy evidence.

  • Open MemberServerBaseline.html.

You should see BlockUserFromShowingAccountDetailsOnSignin plus DontEnumerateConnectedUsers. Both values should be 1.

  • Return to the reports folder in File Explorer.
  • Open FirewallBaseline.html.

You should see EnableFirewall plus DefaultInboundAction. Both values should be 1.

  • Return to the reports folder in File Explorer.
  • Open LegacyProtocolHardening.html.

You should see AllowInsecureGuestAuth plus EnableMulticast. Both values should be 0.

Your local reports show the settings you wrote. The extracted Microsoft baseline reports provide the reference for the policy labels.

  • Switch back to File Explorer.
  • Select the address bar.
  • Enter C:\LabEvidence\Windows Server 2022 Security Baseline.
  • Press Enter to load the extracted baseline folder.
  • Open the extracted baseline reports.
  • Compare the matching policy labels against your three local reports.

The matching labels confirm that your registry-backed values represent the intended controls. Your local reports also confirm that the GPOs remain unlinked.

Is a report missing?

Confirm that C:\LabEvidence\Reports still exists. Rerun only the report command for the missing file.

A missing setting usually means its registry command did not complete. Help me diagnose a missing setting in my generated GPO report.

  • Switch back to the elevated Windows PowerShell session on DC01.

Before you run this, do you expect DC01 to list any staged GPOs? The check reveals the answer.

  • Check the computer-scope policies applied to DC01 by running this command:
gpresult /scope computer /r

What does the result prove?

DC01 still lists its existing computer policies. The result contains no applied LAB-WS2022 GPO.

This shortfall is intentional. The settings exist in the reports, while their missing links leave them without a deployment target.

Does DC01 list a LAB-WS2022 GPO?

  • Stop the pilot work immediately.

An applied LAB-WS2022 GPO means the safety boundary has been crossed. Inspect the link details in your HTML reports before changing anything else.

Ask for help before removing or changing a link. Help me investigate why DC01 received a staged LAB-WS2022 GPO.

✔️ Awesome, I've got everything!

Great. Confirm that all three HTML reports exist and that DC01 lists no applied LAB-WS2022 GPO.

ⓧ I'd like to double check the full code

Use this complete command sequence to compare every command from this step:

New-GPO -Name 'LAB-WS2022-Member-Server-Baseline' -Comment 'Staged sign-in protections for member servers. Pilot only.'
New-GPO -Name 'LAB-WS2022-Firewall-Baseline' -Comment 'Staged domain-profile firewall defaults for member servers. Pilot only.'
New-GPO -Name 'LAB-WS2022-Legacy-Protocol-Hardening' -Comment 'Staged LLMNR and insecure SMB guest-logon controls. Pilot only.'
Set-GPRegistryValue -Name 'LAB-WS2022-Member-Server-Baseline' -Key 'HKLM\SOFTWARE\Policies\Microsoft\Windows\System' -ValueName 'BlockUserFromShowingAccountDetailsOnSignin' -Type DWord -Value 1
Set-GPRegistryValue -Name 'LAB-WS2022-Member-Server-Baseline' -Key 'HKLM\SOFTWARE\Policies\Microsoft\Windows\System' -ValueName 'DontEnumerateConnectedUsers' -Type DWord -Value 1
Set-GPRegistryValue -Name 'LAB-WS2022-Legacy-Protocol-Hardening' -Key 'HKLM\SOFTWARE\Policies\Microsoft\Windows\LanmanWorkstation' -ValueName 'AllowInsecureGuestAuth' -Type DWord -Value 0
Set-GPRegistryValue -Name 'LAB-WS2022-Legacy-Protocol-Hardening' -Key 'HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient' -ValueName 'EnableMulticast' -Type DWord -Value 0
Set-GPRegistryValue -Name 'LAB-WS2022-Firewall-Baseline' -Key 'HKLM\SOFTWARE\Policies\Microsoft\WindowsFirewall\DomainProfile' -ValueName 'EnableFirewall' -Type DWord -Value 1
Set-GPRegistryValue -Name 'LAB-WS2022-Firewall-Baseline' -Key 'HKLM\SOFTWARE\Policies\Microsoft\WindowsFirewall\DomainProfile' -ValueName 'DefaultInboundAction' -Type DWord -Value 1
Get-GPOReport -Name 'LAB-WS2022-Member-Server-Baseline' -ReportType Html -Path 'C:\LabEvidence\Reports\MemberServerBaseline.html'
Get-GPOReport -Name 'LAB-WS2022-Firewall-Baseline' -ReportType Html -Path 'C:\LabEvidence\Reports\FirewallBaseline.html'
Get-GPOReport -Name 'LAB-WS2022-Legacy-Protocol-Hardening' -ReportType Html -Path 'C:\LabEvidence\Reports\LegacyProtocolHardening.html'
gpresult /scope computer /r

How is the sequence organized?

  • The first three commands create the unlinked GPOs with their pilot-only comments.
  • The next six commands add the registry-backed hardening values.
  • The final four commands create the evidence files before checking DC01.

You have proved that all three hardening GPOs exist while DC01 remains unaffected. Next, you will give these GPOs a controlled deployment path through the empty Pilot OU.

Link the Pilot Deployment Ring

Your three hardening Group Policy Objects now contain the controls for future member servers. They still cannot protect a future server because they have no deployment path.

This step gives those controls a path through the empty Pilot OU. The narrow scope keeps DC01 and DC02 outside the blast radius.

In this step, get ready to:
  • Link the three hardening GPOs only to the empty Pilot OU.
  • Inspect the links through Windows PowerShell.
  • Generate an HTML report and prove both domain controllers remain unaffected.
Link the GPOs to Pilot

The Pilot OU is your controlled deployment ring. Enabled links make the policies available to computers placed inside that OU. Non-enforced links preserve normal inheritance behavior.

  • Return to elevated Windows PowerShell on DC01.
  • Create the Pilot distinguished name and its three policy links by running:
$domainDN = (Get-ADDomain).DistinguishedName
$pilotDN = "OU=Pilot,OU=Member Servers,OU=Tier 1,OU=Enterprise Lab,$domainDN"
New-GPLink -Name 'LAB-WS2022-Member-Server-Baseline' -Target $pilotDN -LinkEnabled Yes -Enforced No
New-GPLink -Name 'LAB-WS2022-Firewall-Baseline' -Target $pilotDN -LinkEnabled Yes -Enforced No
New-GPLink -Name 'LAB-WS2022-Legacy-Protocol-Hardening' -Target $pilotDN -LinkEnabled Yes -Enforced No

What Do These Links Do?

  • The $pilotDN variable identifies the protected Pilot OU.
  • The LinkEnabled Yes setting activates each link.
  • The Enforced No setting keeps each link non-enforced.

PowerShell returns details for each new link. The three GPOs now have a deployment path that reaches only the empty Pilot OU.

Inspect Pilot inheritance

Inheritance output separates direct links from inherited policies. It also exposes the enabled state and enforcement state of each link.

  • Inspect the Pilot OU inheritance by running:
Get-GPInheritance -Target $pilotDN

What Does the Inheritance Output Show?

  • The GpoLinks property identifies policies linked directly to Pilot.
  • The InheritedGpoLinks property identifies policies inherited from parent containers.
  • The GpoInheritanceBlocked property shows whether normal inheritance is blocked.
  • Inspect GpoLinks for all three LAB-WS2022 GPOs.
  • Check the enabled state of each direct link.
  • Check the enforcement state of each direct link.
  • Inspect the listed link order.
  • Confirm inheritance remains unblocked.

You should see all three Pilot links enabled. Each link remains non-enforced while normal inheritance remains available.

Missing a Pilot Link?

  • Confirm that $pilotDN contains the full distinguished name of the Pilot OU.
  • Check each GPO name against the names returned by the linking commands.

Use this prompt if the inheritance output does not show all three links: Help me diagnose why Get-GPInheritance does not show my three Pilot OU GPO links.

A consolidated report preserves the configuration after linking. It provides evidence of the GPO settings and their Pilot-only deployment path.

  • Generate the post-staging GPO report by running:
Get-GPOReport -All -ReportType Html -Path 'C:\LabEvidence\Reports\AllGPOs-AfterStaging.html'

What Does This Report Capture?

The report records every GPO after staging. It includes policy details and link information for the three hardening GPOs.

  • Return to File Explorer on DC01.
  • Browse to C:\LabEvidence\Reports.
  • Open AllGPOs-AfterStaging.html.

You should see all three LAB-WS2022 GPOs in the report. Their enabled links should point only to the Pilot OU.

Report File Missing?

  • Confirm that C:\LabEvidence\Reports still exists on DC01.
  • Rerun the report command from elevated Windows PowerShell.

Use this prompt if the report is still missing: Help me troubleshoot why Get-GPOReport did not create the HTML report.

Prove the domain controllers are unaffected

A link proves where a GPO can travel. Resultant Set of Policy proves which policies a specific computer actually receives.

Before you run the checks, which policies do you expect each domain controller to list? Hold that prediction while you test both servers.

  • Return to elevated Windows PowerShell on DC01.
  • Check DC01 computer policy by running:
gpresult /scope computer /r

What Does This Check Prove?

The command displays the computer-scope policy result for DC01. It tests the policies received by the domain controller itself.

DC01 should not list any LAB-WS2022 GPO. This confirms the new Pilot links did not cross into the built-in Domain Controllers OU.

  • Use Windows search on DC02 to open Windows PowerShell as Administrator.
  • Check DC02 computer policy by running:
gpresult /scope computer /r

Why Check the Second Domain Controller?

The second result confirms that the safety boundary protects both domain controllers. Evidence from DC01 alone would leave DC02 unverified.

DC02 should not list any LAB-WS2022 GPO. Both domain controllers remain outside the Pilot deployment scope.

Seeing a LAB-WS2022 GPO?

  • Stop the pilot verification if either domain controller lists a LAB-WS2022 GPO.
  • Inspect Get-GPInheritance -Target $pilotDN to confirm the links target only Pilot.
  • Check Group Policy Management for an unintended link at the domain or built-in Domain Controllers OU.

Use this prompt to investigate the scope: Help me find why a LAB-WS2022 GPO appears in gpresult on a domain controller.

✔️ Awesome, I've got everything!

Your three links are enabled and non-enforced. The consolidated report exists while both domain controllers remain outside the new policy scope.

ⓧ I'd like to double check the full code

Compare your Windows PowerShell commands with the complete sequence for this step:

$domainDN = (Get-ADDomain).DistinguishedName
$pilotDN = "OU=Pilot,OU=Member Servers,OU=Tier 1,OU=Enterprise Lab,$domainDN"
New-GPLink -Name 'LAB-WS2022-Member-Server-Baseline' -Target $pilotDN -LinkEnabled Yes -Enforced No
New-GPLink -Name 'LAB-WS2022-Firewall-Baseline' -Target $pilotDN -LinkEnabled Yes -Enforced No
New-GPLink -Name 'LAB-WS2022-Legacy-Protocol-Hardening' -Target $pilotDN -LinkEnabled Yes -Enforced No
Get-GPInheritance -Target $pilotDN
Get-GPOReport -All -ReportType Html -Path 'C:\LabEvidence\Reports\AllGPOs-AfterStaging.html'
gpresult /scope computer /r

How to Use This Reference

The first five commands build the Pilot target and its links. The inheritance command verifies their state.

The report command creates the final evidence file. Run the last command separately on DC01 and DC02.

That is the safety boundary proven. Your empty Pilot ring can receive the staged controls while DC01 and DC02 continue using their existing policies.

Secret mission

Secret Mission: Prove GPO Rollback

A policy backup becomes credible when it can reverse a real configuration mistake. Deliberately weaken the staged SMB guest-logon control while the Pilot OU is empty. Restore the GPO from backup and capture proof that the secure value returned.

Clean Up Your Resources

Clean Up Your Resources

Choose whether to keep the pilot available, pause its policy links, or delete the lab resources. These Active Directory objects stay inside your existing Windows Server lab, so they create no ongoing paid service or metered cloud cost.

Resources you used:

  • Protected Enterprise Lab OU hierarchy with the empty Pilot, Application, and Database deployment rings.
  • Three Group Policy Objects: LAB-WS2022-Member-Server-Baseline, LAB-WS2022-Firewall-Baseline, and LAB-WS2022-Legacy-Protocol-Hardening. Each GPO has an enabled non-enforced link to Pilot.
  • Local baseline files, health evidence, reports, rollback evidence, and GPO backups under C:\LabEvidence on DC01.

Keep everything running

No action is needed. Choose this if APP01 is next and you want the pilot ready for controlled testing.

  • Keep Pilot empty until APP01 is ready for controlled testing.
  • Leave the three pilot links enabled with enforcement disabled.
  • Keep inheritance unblocked on Pilot.
  • Retain C:\LabEvidence as the audit trail for the pilot architecture and rollback drill.

Pause - I'll come back to this later

Pausing leaves the GPOs and OUs in place. The disabled links prevent future computers in Pilot from receiving these staged policies.

  • Switch back to the Group Policy Management Console from earlier.
  • Select OU=Pilot,OU=Member Servers,OU=Tier 1,OU=Enterprise Lab,$domainDN in the domain tree.
  • Disable the link for LAB-WS2022-Member-Server-Baseline.
  • Disable the link for LAB-WS2022-Firewall-Baseline.
  • Disable the link for LAB-WS2022-Legacy-Protocol-Hardening.
  • Keep inheritance unblocked on Pilot.
  • Confirm all three links now show a disabled state.
  • Resume the pilot later by enabling the same three links before moving a test server into Pilot.

Delete - I don't want to use this again

Deleting these objects is deliberately final. Your evidence can remain on DC01 until you no longer need the audit trail.

Remove the pilot links
  • Switch back to the Group Policy Management Console from earlier.
  • Select OU=Pilot,OU=Member Servers,OU=Tier 1,OU=Enterprise Lab,$domainDN in the domain tree.
  • Remove the link for LAB-WS2022-Member-Server-Baseline.
  • Remove the link for LAB-WS2022-Firewall-Baseline.
  • Remove the link for LAB-WS2022-Legacy-Protocol-Hardening.
  • Refresh Pilot in the domain tree.

The Pilot OU now shows no links from the staged hardening portfolio.

Delete the staged GPOs
  • Select Group Policy Objects in the Group Policy Management Console.
  • Delete only LAB-WS2022-Member-Server-Baseline.
  • Delete only LAB-WS2022-Firewall-Baseline.
  • Delete only LAB-WS2022-Legacy-Protocol-Hardening.
  • Refresh the Group Policy Objects container.

That's the staged portfolio removed. Your pre-existing domain GPOs remain listed and unchanged.

Remove the server-ring OUs

Removing these protected OUs takes an extra check because accidental-deletion protection must be cleared first. This prevents an unintended removal while the hierarchy is in use.

  • Switch back to Active Directory Users and Computers from earlier.
  • Turn on the console view that exposes advanced object settings.
  • Confirm every OU under Enterprise Lab is empty.
  • Clear accidental-deletion protection from every OU under Enterprise Lab.
  • Delete the empty Pilot OU.
  • Delete the empty Application OU.
  • Delete the empty Database OU.
  • Delete the empty Member Servers OU.
Remove the remaining lab OUs
  • Delete the empty Tier 1 OU.
  • Delete the empty Tier 0 OU.
  • Delete the empty Privileged Identities OU.
  • Delete the empty Service Accounts OU.
  • Delete the empty Enterprise Lab OU.
  • Refresh the domain tree.
  • Confirm Enterprise Lab no longer appears.
  • Confirm the built-in Domain Controllers OU still contains DC01 and DC02.

You have removed only the lab OUs. The built-in domain controller boundary remains untouched.

Decide when to remove the evidence

The reports and backups under C:\LabEvidence are your audit trail. Their deletion is a separate choice after you no longer need that record.

  • Retain C:\LabEvidence while you still need the health records, GPO backups, baseline files, or rollback proof.
  • Delete the C:\LabEvidence folder with the Windows file manager after you no longer need the audit trail.
  • Confirm C:\LabEvidence no longer appears on DC01.

Nice Work!

Nice Work!

Mission complete! You built an evidence-backed Group Policy hardening pilot for future member servers.

You've learned how to:

  • Created a recoverable starting point with pre-change AD DS health records plus point-in-time backups of every existing GPO.
  • Built a protected OU hierarchy with separate privilege boundaries plus an empty Pilot deployment ring for future member servers.
  • Staged three focused hardening GPOs for sign-in privacy, legacy protocols, and the domain firewall profile. GPO reports plus resultant policy evidence prove that Pilot is the only scope while both domain controllers remain unaffected.
  • Completed a controlled GPO rollback in the Secret Mission by reversing a deliberate guest-logon regression from a dedicated backup. The final report proves that AllowInsecureGuestAuth returned to 0.

Ready to quiz yourself?