15 Group Policy Best Practices

by Robert Allen

Group Policy Best practices

This is the most thorough guide to group policy best practices on the web.

In this guide, I’ll share my recommended group policy settings and GPO management tips. These best practices will simplify GPO management, improve security, and GPO performance.

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. It is best to plan and test any changes to group policy before rolling it out to all systems. One small change could lead to major issues and impact critical business services.

GPO Best Practices and Recommended Settings

I recommend reading the full list below as some best practices may not make sense unless you read them all.

1. Do Not Modify the Default Domain Policy

default domain policy gpo

This GPO should only be used for account policy 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. The Default Domain Policy is linked to the root of the domain.

When you put multiple GPO settings into the default domain policy it becomes very difficult to troubleshoot and control GPO settings. It can also impact performance if the GPO has too many settings and every user and computer has to process them. It is best to use small GPOs (see tip #12) than to stuff everything into one big GPO.

2. Do Not Modify the Default Domain Controller Policy

default domain controllers 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.

The Default Domain Controller policy is linked to the Domain Controller OU.

3. Good Organizational Unit (OU) Design Will Make Your Job 10x Easier

A good OU design makes it easier to apply and troubleshoot group policy. It is best to create an OU for computers and a separate OU for users. Then create sub-OUs on how you want to manage your objects. I typically organize objects by department and functionality.

Example OU design:

organizational unit design example

Putting users and computers in separate OUs makes it easier to apply computer policies to all the computers and user policies to only the users.

Related: 21 Effective Active Directory Management Tips

4. Do Not Set GPOs at the Domain Level

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.

gpo linked to root domain

5. Apply GPOs to The Root OU

Applying GPOs at the root of an OU will allow the sub-OUs to inherit these policies. This way you don’t need to link a policy to each individual OU.

gpo linked to organizational unit

If you want to exclude OUs or a group of users you have a few options.

  1. Use GPO Security Filtering – Best option.
  2. Use Item-level targeting
  3. Apply a GPO to the group that disables the policy.

Exclude Users using GPO Security Filtering.

Let’s look at an example. I have GPO that disables saving passwords in the Chrome browser, the GPO is linked to all users.

gpo security filtering

What if I have users in various departments that I don’t want this policy applied to? The solution is to use GPO security filtering.

I create a security group, add users to the group, and then deny this group from applying the group policy. Now all users will get the GP except the users in the security group.

deny gpo access

6. Avoid Using Blocking Policy Inheritance and Policy Enforcement

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 is set in the domain.

7. Don’t Disable GPOs

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, and this could cause problems.

8. Use Descriptive GPO Names

Being able to quickly identify what a GPO is for based on 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. It will also invite other admins to just dump any and all settings into a single GPO. Before are some descriptive GPO names:

  • User – Browser Settings
  • User – Office 365 Settings
  • User – Block PowerShell
  • Computer – Screen Lock On
  • Computer – install Adobe

Just by looking at the above GPO names, you have a pretty good idea of what they are used for.

9. Speed Up GPO Processing by Disabling Unused Computer and User Configurations

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.

To disable the computer or user configuration of a GPO:

  1. Browse to Group Policy Objects
  2. Right Click a GPO and select GPO Status
  3. Select one of the options.
disable gpo configuration

10. Use Loopback Processing for Specific Use Cases

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.

11. Group Policy Change Management

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.

12. Use Small GPOs to Simplify Administration

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, designing, and implementing 10x easier.

Here are some ways to split up GPOs into smaller policies:

  • Browser Settings
  • Security Settings
  • Power Settings
  • Microsoft Office Settings
  • Network Settings
  • Drive Mappings
  • Power Settings
  • Bitlocker
  • Applocker
  • Firewall rules
  • and so on…..

13. Best Practices for Group Policy Performance

Here are some settings that can cause slow startup and logon times.

  • Login scripts downloading large files
  • Startup scripts downloading large files
  • Mapping home drives that are far away
  • Deploying huge printer drivers over group policy preferences
  • Overuse of group policy filtering by AD group membership
  • Using excessive WMI filters
  • Lots and lots of GPOs linked to a user or computer over a slow link.

14. Group Policy Troubleshooting Tips

Know how to use the RSop and gpresult commands to verify and troubleshoot group policy. When troubleshooting you need a way to verify that GPOs are getting applied and check exactly what policies are applied. These two commands are a huge lifesaver. I’ve written a complete how-to article for each command so be sure to check them out.

15. Backup GPOs

If you are not backing up Active Directory or doing system state backup then you need to start backing up your GPOs. You may need to recover a deleted GPO or restore the settings from existing GPOs. See my complete guide on how to backup and restore group policy objects.

To learn more about group policy check out my ultimate guide to group policy management.

I hope you found this article helpful if you have any group policy questions leave a comment below.

Recommended Tools

  • AD Cleanup Tool - Find stale and inactive user and computer accounts in Active Directory. Export, disable, move or delete the stale accounts to increase security.
  • AD User Creation Tool - Bulk import or update Active Directory user accounts. Add users to groups, import into OUs, set multiple attributes and more.
  • NTFS Permissions Tool - Scan and audit NTFS folder permissions. See which users and groups have access to what.
  • AD Reporting Tool - Over 200 reports on users, computers, groups, OUs and more. Customize reports or create your own reports with the report builder.

58 thoughts on “15 Group Policy Best Practices”

  2. Is there a way to have a GPO only apply while a device is on battery power but not when it is plugged in.
    i.e. We have patrol vehicles that while the laptop is in the vehicle and plugged into power we cannot have the screen lock. However, once that machine is off power and on battery only then apply a screen lock after x minutes.

    Reply

  5. Hi Robert,

    Would like to know what may be the cause of my DC administrator account not able to have elevated privileges? for context, I have set that users can not open cmd but when I tried using “run as” administrator, I am getting a message that says “C:\Windows\system32\cmd.exe The requested operation requires elevation”
    Also my users are getting removed from a security group that I created. eg: test user is a member of test_user_security group.

    Thanks in advance!

    Reply

  6. Is there a template for complete block except for one program (remote app) and Explorer (not IE Explorer) to browse users private folder?

    Thanks,

    Reply

  7. Thank you!

    Amazing guide, some things I already knew, but didn’t know the why. I still have a question, if an option has in Computers and Users, what is the best place to put?

    Reply

      • hi Robert,

        For example in:

        Computer Configuration | Policies | Administrative Templates | Windows Componentes | AutoPlay Policies

        and

        User Configuration | Policies | Administrative Templates | Windows Componentes | AutoPlay Policies

        You have the same options. I think putting for computers is better because it would apply to any user, but I’m not sure if it’s a best practice.

        Thanks again.

        Reply

        • It just depends if you want the policy to apply to all users that sign on to a computer, or specific users.

          For example, if you have a shared computer and need specific users to have a desktop shortcut you would use a user configuration. If you used a computer configuration all the users would get the shortcut. If all users need the policy then use computer configuration.

          Reply

  9. I have both my Win 10 citrix and win7 (soon to be win10) workstations on loopback/replace. I always get so much pushback from the network engineers about this.

    Reply

  10. What is the best practice for applying a group policy which contains both User and Computer settings?

    Would you apply the policy to both the OU containing the users and the OU containing the computers or would you split the settings into 2 different policies (despite both policies being for the same cause).

    Reply

    • I recommend you seperate users and computers into their own OU. If that is not an option I would create two GPOs, 1 for the user settings and 1 for the computer settings.

      Reply

      • Hi Robert.

        I already have separate OUs for Users and Computers. My question was what would you recommend is the best method if you have a GPO which contains settings for both Users and Computers.

        Would you split the Computer and User settings into 2 different GPOs (i.e. even if they are all for Internet settings) or would you apply the same GPO to both the Users and Computers OUs and therefore have a GPO with Computer settings on a User OU and a GPO with User settings on an OU for just computers?

        Thanks,

        Andy

        Reply

        • Yes, split it into two GPOs, 1 with just user settings and 1 with just the computer settings. Then you can disable the section that is not used.

          Reply

  11. Best explanation for loopback processing I’ve ever seen. Always slightly confused about what it does. Not anymore 🙂

    Reply

  12. Robert, I deal with GPO management on a daily basis, in a very large environment. I agree with everything you’ve said. Here are a few things that have helped me tremendously, If you don’t want a GPO to apply to specific users or computers or groups for that matter, you can edit that GPO, go properties security and add the user, computer or group and select “DENY” apply group policy. Make sure you take advantage of adding comments to your GPO’s. Some GPO’s are doing alot and commenting them out will help you remember what they do and if there are any special nuance’s you need to take into consideration.

    Reply

    • George great tip. This is a great way to apply GPOs to very specific groups. I need to write a how-to on this, thanks for mentioning this.

      Reply

    • I find the practice of using Deny to be horrible!
      As soon as there is more than one administrator, or a change of admin employees (new person taking over), that kind of structure becomes rather confusing.
      If you need to use Deny, then you’ve designed the OU structure wrong…

      Reply

      • I agree that if it is not documented or communicated it can be a nightmare. But it can also be extremely useful for targeting specific users and computers and to deny it from all users. For example, I have a blanket firewall GPO that all users get for the basic FW settings. I have some users that need FTP on, I create a new security group and only apply this GPO to these users and deny it to all other users. I want to keep all the users in their department OU so moving to another OU is not a good option for this. Targeting a GPO to a security group is great but try not to let it get out of control.

        Reply

        • I would suggest that, if you need to deny certain permissions to certain people, make a group named for exactly what is being denied, and deny the permission to that group. That way, you can easily find all users denied given permissions via the group, and there isn’t a huge ACL on the GPO or its link.

          For example, you might have a GPO named “User – MSEdge – ForceUpdate” linked at an ancestor OU, but you want a couple of specific people 2 OUs down from there to be exempt.

          In an OU that just contains these exemption groups, you could then have a group named “User – MSEdge – ForceUpdate – Deny” and stick those users in there.

          Having the permissions in a group also reduces replication noise, since modifying the ACL on a GPO means the file got changed and now has to be replicated again to all servers hosting the domain service volume.

          That also allows layers, instead of flat permissions.

          I really wish we could organize the Group Policy Objects container, too. One of th most common things you learn early on is that whole “Name stuff with a prefix” bit, which is an absolute MUST if you have more than just a small handful of GPOs. And if we could permission said containers, as well, both for administrative purposes and for application of the policies, MAN that would simplify some tasks.

          Reply

          • Hi,

            On number 5 under the “exclude users using GPO security filtering” I do exactly this. Using security filtering to deny certain users from a GPO works great.

    • Good OU structure is important to implementing GPOs. It helps with properly targeting the right users and computers, troubleshooting and to ensure the policy gets applied. For examples, if you want to prevent certain users from creating a pst file in outlook the GPO needs to be applied to an OU with those users. If you apply the GPO to an incorrect OU it will either not get applied or get applied to the wrong group of users.

      Reply

  16. Hi Robert,

    I happen to come across your site searching for gpresults and bookmarked it.

    Quickly browsing through the various posts you’ve made, I like the summarized points!

    Complete newbie. I’m looking into tackling group policy and also like the rsop testing article.

    My question is whether to disable or delete the group policy – in some reading I came across a while back, it mentioned to disable a group policy as a precaution (for a period of time). Just in case, something does go wrong.

    Thank you for sharing your knowledge

    Patrick

    Reply

    • Not sure I understand your question.

      I would not recommend disabling or deleting the default GPOs or services on domain controllers.

      Reply

  18. Thank you very much for spending so much time in putting this together. What suggestions do you have if the following rules have been broken and they need to be repaired?
    1. Do Not Modify the Default Domain Policy
    2. Do Not Modify the Default Domain Controller Policy

    I very seldom work with GPOs, have inherited a rat’s nest and I’m not sure where to start the unravelling process. On top of it all, there are built-in groups with members who don’t belong there i.e., specific Users are members of Administrators, Domain Admins and Enterprise Admins. I’d like to fix the problem without causing any major disruptions to developers (yes, developers are domain admins because that’s the way they wanted it to be). Would I be better off using third-party software to unravel and straighten out a mess?

    Thank you very much,
    John

    Reply

  21. great tips, i am installing AD, DHCP and DNS for a new organisation and this will definitely help in my planning and configuration. please also share tips on DNS and DHCP if possible.

    Reply

    • Abhilash,

      I suggest grouping similar policies into their own GPO as opposed to stuffing them into one big GPO. This will make troubleshooting, managing and applying policies much easier. I’ll give an example of turning the screensaver timeout on all the computers. If I put this policy into say the default domain policy it would get applied to all computers. Now if someone requests this policy be turned off on some specific computers there is no easy way to do that. If the screensaver policy was it’s own GPO then it becomes easy to filter it out for specific users and computers. It also makes it easier to report and see what policies you have when they are broken out. Does that make sense?

      Reply

  24. i’ve improved a lot my AD administration reading this article!

    Thank you Robert!

    Greetings from México!

    Reply

Leave a Comment