Working With Active Directory and Group Policy

Philip ElderSenior Technical Architect - HA/Compute/Storage
Philip is a Senior Technical Architect specializing in high availability solutions for SMB/SME businesses and hosting companies.
Edited by: David Draper
Our Group Policy work started with Small Business Server in 2000. Microsoft gave us an excellent OU and GPO model in subsequent SBS editions that utilized WMI filters, OU linking, and VBS scripts. These are some of experiences plus our spending a lot of time with Jeremy Moskowitz's GP books.
Here we present a number of key elements to a well functioning Active Directory Domain Services setup along with Group Policy.

If you've run into a problem and lost a DC, the bottom of this article has the necessary clean-up steps once a new PDCe is elevated via seized FSMO Roles.

Active Directory Recycle Bin

When an AD object gets deleted there can be no end of heartache to get it back. At least, that's how it used to be. We'd have to "re-animate" the object and go through re-connecting that object to AD.

Not anymore. But, before we move on, let's take a look and see what's there:
Get-ADOptionalFeature -Filter *
If we see the following (domain clipped) then we're golden:
If we don't, then the way to enable it is the following in an elevated PowerShell:
Enable-ADOptionalFeature -Identity 'Recycle Bin Feature' -Scope ForestOrConfigurationSet -Target '' -Server dc1
Set the domain and the target PDCe then run the script. Once run, paste the above query into PowerShell to verify it as being enabled.

As always, before making a change back up the PDCe and make sure that backup is good.

As part of our change control management, we use Windows' Snip for each step. It's quick and provides a visual reference along with our change log notes.

Group Policy Central Store

If you haven't already done so, set up the Group Policy Central Store.

  1. Find the latest version of Windows 10 Pro or Windows 11 Pro
  2. Copy the C:\Windows\PolicyDefinitions folder to C:\Temp
  3. Right click and Copy that folder
  4. Navigate to C:\Windows\SYSVOL\Domain\Policies
  5. Paste the PolicyDefinitionsfolder
    1. NOTE: If upgrading an existing Central Store then:
      1. Create a folder called PolicyDefinitions-2022-12-14
      2. Copy the existing contents from the PolicyDefinitions folder into the above created folder
      3. THEN copy and paste the new PolicyDefinitions contents in to the PolicyDefinitions folder and acknowledge the overwrite prompt
This is what a Central Store will look like over time:
Always verify the new Policy Definitions _before_ running the above process to update the Central Store as there are new GPO settings but there are GPO settings that also get dropped!

Microsoft curates a list in a spreadsheet for each Policy Definitions update. Since it's always being updated name wise here is a DDG search:
Besides being able to back up the PolicyDefinitions folder prior to updating and thus having an out if something hopelessly breaks, editing Group Policy becomes a fairly straightforward.

The above tells us that we have successfully set up the GP Central Store!

If something chokes, create a new backup folder, cut and paste the contents of the PolicyDefinitions folder into it. Then, copy the contents of the earlier backup folder back into the PolicyDefinitions folder.

Wait for replication if need be.

Group Policy Objects (GPOs) and Organizational Units (OUs)

In Active Directory Users and Computers all new non-DC systems get dropped into the Computers CONTAINER. It is _ not_ an OU. Thus we can't create and link a Group Policy Object there.

In Active Directory Users and Computers all new non-DC systems get dropped into the Computers CONTAINER. It is _ not_ an OU. Thus we can't create and link a Group Policy Object there.
Group Policy is similar in its application as CSS (Cascading Style Sheets) is for HTML. That means that in a given OU structure the GPO and its settings closest to the AD object applies. ENFORCE creates a bit of a caveat depending on the settings.

Here's how we tend to set our OU and GPOs ( our blog post).

From the above blog post:
NOTE: It is important to never make changes to the Default Domain Policy and the Default Domain Controllers Policy. All Group Policy customizations should be done in a Group Policy Object that is created, linked, and set to Enforced to the OU the AD Computer _or_ User Objects are found.

Group Policy Objects (GPOs) should be either Computer or User focused. In the Properties for a newly created GPO make sure to DISABLE the respective settings section that will not be used.

Leave the Two Default Group Policy Objects Alone!

Finally, why do we not edit the two default policies? Because, if something breaks how do we figure out what caused the break? With the settings in their own GPO we can edit or unlink the GPO while troubleshooting. We've encountered lots of broken Group Policy that were a result of changes made to the two default GPOs.

Adding Computers and Users

 We use the Add-Computer PowerShell with the -OUPath switch to drop all new systems into their respective OU. Once they reboot they then pick up the appropriate settings for them. Besides OU membership as a form of GPO focus we also use WMI filtering when the GPO is linked closer to the Domain.Com root.

The PowerShell we use to add any system to a domain:
Add-Computer -Credential DOMAIN\UserName -Domain Prefix.Domain.Com -OUPath "OU=Mine,OU=goes,OU=Here,DC=Prefix,DC=Domain,DC=Com" -Restart
Make sure to use a disposable user ID to add the system to the domain as an AD object has a limited number of domain joins associated with it plus we've encountered issues using a domain admin account. If the domain has a fair amount of system churn then expect to replace that account on a regular basis as there's no reliable way that we've found to set up a domain user that allows an infinite amount of domain computer object additions.

NOTE: Use a Standard User to add to the domain not a domain admin account. In our experience, using a domain admin account can mess with the new Computer object's interaction with AD and DNS.

We create the Group Policy Central Store for all of our deployments. It is required for our Ransomware security structures that are defined via Office ADMX but also makes updating the ADMX files for say Windows 10 simple in multi-DC settings.

One thing to be aware of in all this is Group Policy Tattoos. Just because we unlink or remove settings in a GPO does _ not_ mean those settings stop applying at the endpoint. We always test our GPO configuration in a lab setting way before thinking about deploying in production.

Setting up Basic Security Settings

When we are setting up a Greenfield deployment or walking in to an existing network setup there are a number of important settings that we need to secure and manage the various systems on the network.

We create and link a Group Policy Object to the root domain: Default Domain Security Policy. Once the GPO is created we right click on it and click on Properties then add a comment: "2022-03-23 Created by Philip Elder for domain wide security". Since this policy is going to contain Computer focused settings only we DISABLE the User settings under Scope.

The next step is to set up the Windows Firewall with Advanced Security:

There are legacy settings within Administrative Templates please do not use those.

Right click on the above highlighted WDFwAS and Properties:
  • All 3 Profiles
    • Firewall State: ON
    • Settings: YES
    • Logging: YES
  • Public Profile
    • Inbound Connections: BLOCKED

From there we set up a number of exceptions that are important:
  • Remote Desktop (ALL)
  • Remote Event Log Management
    • By default this is not enabled so Manage in Active Directory Users and Computers chokes on the Event Logs of a remote system.
  • Remote Shutdown
  • Remote Volume Management
With the above in place we now have the basics in place for remote management of systems.

Another important setting to enable is "Allow users to connect remotely by using Remote Desktop Services".

This saves having to manually flip the switch on every system to allow inbound RDP connections.

OPTION: Create and Link a GPO to the OU(s) that servers reside in and configure the Windows Firewall to only allow inbound RDP connections from a Jump Server or Jump Servers to help limit lateral movements if someone clicks on a bad link.

Deploying Printers

It is our preference to deploy printers using a Computer based GPO because adding a computer to the OU the GPO is linked to, and enforced, gets it set up with little to no difficulty and removing the machine from that OU same.

Once you've created the GPO for a specific printer, or printers, it's a matter of linking that GPO to the required OUs the machines are resident in.

It is a best practice to disable the User portion of the GPO for those being used to set Computer settings (same for user based settings - disable Computer).

Set up the printer on the system/server it is shared from.

In Print Management, right click and Deploy with Group Policy --> Navigate to the applicable OU --> chose ADD --> Apply & OK.

Once a machine is on the domain it should have the printers.

If the machine is moved about in Active Directory Users & Computers then:
GPUpdate /Force
A reboot may be required.       

Recovering from a Failed DC

If there's nothing else but the ADDS/DNS/DHCP roles on the failed server then seize the FSMO Roles on another DC. If it's the only DC then recover from backup.

Below we also link to a Microsoft article that explains how to correct a problem introduced by restoring a DC in a multi-DC Forest/Domain that then causes a USN Rollback problem.

Check FSMO Role Holder

The first thing we need to do if there's another DC, or more, on the domain is to check where the current owner(s) is/are:

Get-ADForest | Format-Table SchemaMaster,DomainNamingMaster
Get-ADDomain | Format-Table PDCEmulator,RIDMaster,InfrastructureMaster

Seize the FSMO Roles

In the case where we need to forcefully seize the FSMO Roles onto another DC on the domain:
# Destination DC for Operations
$DestinationDC = "NewDC100"

# Seize FSMO Roles
Move-ADDirectoryServerOperationMasterRole -Identity $DestinationDC -OperationMasterRole 0,1,2,3,4 -Force -confirm:$False
Get-ADForest  | Format-Table SchemaMaster,DomainNamingMaster
Get-ADDomain  | Format-Table PDCEmulator,RIDMaster,InfrastructureMaster

Once we've seized the FSMO Roles we need to verify that they are indeed resident on the newly elevated PDCe. Use the PowerShell above in an elevated PowerShell session on a DC.

From there, complete a MetaData clean-up of the old DC using NTDSUtil. If there's more than one defunct DC listed now is the time to get rid of them!

Once that's done, go through DNS for both ADDS Forward Lookup Zones:
  • Corp.Domain.Com(your domain here)
    • Update the NS records for the _mscds stub zone in this zone
  • _mcds.Corp.Domain.Com

You are looking for OLDDCName in all of the ADDS related folders and in the Forward Lookup Zones especially the NS setting for each zone's properties.

Check AD Sites and make sure it's not mentioned there. If it is, then delete.

Once the FSMO Roles are transferred make sure SYSVOL and NETLOGON are presented:
  • \\Corp.Domain.Com
  • \\NewDCName

Reinitialize Replication via BurFlags

If you're having problems getting SYSVOL and NETLOGON you may need to do a BurFlags D2/D4 authoritative restore (FRS) or the equivalent for DFSR replication topologies on the newly elevated PDCe.

Verify that Group Policy is happy by doing a GPUpdate /Force on a member server and a client machine. Create and link a GPO at the domain level called TEST. Check SYSVOL for a newly created GUID. If there are other DCs, verify that the new policy shows up there.

Update DHCP to point to the new DNS servers.

Update the DNS pointers on server pNIC(s)/vNIC(s) on any system that has a static IP set up. This is easily done with PowerShell.

FSMO Role Guidance

As always, make sure there's a backup of the PDCe FSMO Roles holder. We find that there is no reason to put the FSMO Roles on separate DCs. In fact, doing so introduces a level of complexity in a Disaster Recovery situation that just doesn't need to be there.

It's also a good idea to back up the PDCe's System State on a regular basis but especially before introducing any changes to the Forest/Domain ADDS topology!

Active Directory Domain Services and USN Rollback

One of the drawbacks to image based backups is a situation that we enter into when we restore a domain controller (DC) after it goes blotto.

All DCs in a Forest use an Updated Sequence Number (USN) to keep track of everything happening within the Forest that gets replicated between the DCs in the Forest and Domain.

If we restore a DC from image based backup that USN will possibly be an earlier sequence number than is current on all DCs in the Forest and Domain.

This Microsoft article explains how to Recover from a USN Rollback situation.
Philip ElderSenior Technical Architect - HA/Compute/Storage
Philip is a Senior Technical Architect specializing in high availability solutions for SMB/SME businesses and hosting companies.

Comments (0)

Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.