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.