Working With Group Policy

Philip ElderSenior Technical Architect - HA/Compute/Storage
Philip is a 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.
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 GPO 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).

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.

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.

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.

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.

To make things simple, we use PowerShell to add any system to the 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.

Once the 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.                
Philip ElderSenior Technical Architect - HA/Compute/Storage
Philip is a 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.

Get access with a 7-day free trial.
You Belong in the World's Smartest IT Community