This is the most thorough guide to group policy best practices on the web.
I understand that group policy can get complicated, it can be complex and it can be difficult to troubleshoot when you have multiple GPOs applied across the entire domain.But here’s the kicker:
Implementing group policy is actually very simple.
In this guide, you’ll learn everything you need to know about group policy design and implementation best practices. These are proven tips and techniques that many IT professionals use.
Warning: Group Policy is not a one size fits all. Every Active Directory environment is different and there is no cookie cutter solution for group policy. These best practices have worked well for environments I have managed, but may not work for yours. It is best to plan and test any changes to group policy. One small change could lead to major issues and impact critical business services.
I do recommend reading them all as some may not make sense without further reading.
This GPO should only be used for account policies settings, password policy, account lockout policy, and Kerberos policy. Any other settings should be put into a separate GPO. The Default Domain Policy is set at the domain level so all users and computers get this policy.
This GPO should only contain the User Rights Assignment Policy and Audit Policy. Any other settings to the Domain Controllers should be set in a separate GPO.
Good OU structure makes it easier to apply and troubleshoot group policy. I prefer to separate the users and computers into their own OU, then create sub OUs for each department or business function.
Example OU structure.
Putting users and computers in separate OUs makes it easier to apply computer policies to all the computer and user policies to only the users.
The only GPO that should be set at the domain level is the Default Domain Policy. Anything set at the domain level will get applied to all user and computer objects. This could lead to all kinds of settings getting applied to objects that you don’t want. It’s better to apply the policies at a more granular level.
Applying GPOs at an OU level will allow sub OUs to inherit these policies. This way you don’t need to link a policy to each individual OU. If you have users or computers that you don’t want to inherit a setting, then you can put them in their own OU and apply a policy directly to that OU. Below is an example.
The Windows 10 Settings contains a policy that turns on the screen saver after 30 minutes. This policy is applied at the Winadpro computers OU, so sub OUs will inherit this policy. I have a training lab that I don’t want this policy applied to so, I created and linked a GPO directory to the Training Lab OU that disables the screen saver. This directly linked GPO will take precedence and get applied over the inherited policies.
If you have a good OU structure then you can most likely avoid the use of blocking policy inheritance and using policy enforcement. I find it much easier to manage and troubleshoot group policies knowing neither of these are set in the domain.
If a GPO is linked to an OU and you don’t want it to be, delete it instead of disabling it. Deleting the link from an OU will not delete the GPO, it just removes the link from the OU. Disabling the GPO will stop it from being processed entirely on the domain, this could cause problems.
Being able to quickly identify what a GPO does based off the name will make group policy administration much easier. Giving the GPOs a generic name like laptop settings is too generic and will confuse people. Some good examples are Browser Settings, Power Settings, MS Office Policies, Screen Saver off, and Citrix Receiver. These are all descriptive and one look at the name gives you a good idea of what that policy is used for.
For example, I have a GPO called browser settings, it only has computer settings configured and no user settings so, I have disabled the User configuration for this GPO. This will speed up group policy processing.
Loopback processing, in a nutshell, takes user settings and limits those settings to a computer the GPO is applied to. It is very useful but can also cause issues if used incorrectly. A common use of loopback processing is on terminal servers and Citrix servers. Users are logging into a server and you need specific user settings applied when they log into only those servers. You would need to create a GPO, enable loopback processing and apply it to the OU that has the servers in it.
Group policy can get way out of control if you let all your administrators make changes as they feel necessary.
Change management can be dreadful and it can really slow projects down.
I’m not saying all group policy changes should go through a formal change management process but they should be discussed with management and documented.
One little GPO change could send a flood of calls to the helpdesk. It happens, so it’s best to discuss and document changes to GPOs.
It can be easy to fall into the trap of stuffing everything into one GPO.
I’m guilty of this too,
and it becomes a giant headache to manage.
There really is no reason to do this, many small GPOs do not affect performance. Small GPOs make troubleshooting, managing, design, and implementation 10x easier.
Here are some ways to break out GPOs into smaller policies:
Here are some settings that can cause slow startup and logon times.
For more group policy performance tips check out this great video by Jeremy Moskowitz Group Policy: Notes from the Field.
These two commands are great for troubleshooting and verifying GPOs, both commands are built into windows. When troubleshooting you need a way to verify GPOs are getting applied and check exactly what policies are applied. These two commands are a huge life saver. I’ve written a how to guide on each command, check them out below.
I hope you found this article helpful if you have any group policy questions leave a comment below.