GPO Best Practices

Looking for some "standards" or "Best Practices". I have been told to never edit the Default Domain or Default Controller Policies. Is that really "Best Practices"?

So as a general rule (and I know there are exceptions) most policies should be linked to either the Computer OU or the User OU depending on what the policy does?

Do you try and stay away from writing a new policy for every tiny setting and do something like make a generic "MyCompany Workstation Policy" and "MyCompany User Policy" and keep as many applicable settings in as few polices as possible?
LVL 15
Who is Participating?
Adam BrownSr Solutions ArchitectCommented:
Avoiding modifications to Default Domain and DC policies is absolutely a best practice. Those policies hold settings that are critical to the proper functioning of the domain. Specifically, the User Rights Assignment for Domain Admins, Enterprise Admins, and other groups are defined there, in addition to a number of other security related settings. I've gone into environments that were almost completely broken because someone decided to futz around with the Default policies.

I usually make a few simple recommendations when teaching people about GPOs:
1. Don't disable GPOs. If it's linked to an OU and you don't want it to be, delete the link. Disabling the GPO will keep it from being processed *everywhere* in the domain, which can cause unintentional issues. Also, it's kind of difficult to tell the disabled OU icon from the enabled OU icon at a glance, which can negatively impact troubleshooting.
2. Do not use the Users or Computers folders that are right off the root of the domain. Those are not OUs, and cannot have GPOs linked to them. The only way to apply policies to those folders is to link them to the domain. This is a pain in the butt to deal with in many situations.
3. Don't mix AD objects in OUs. In other words, only computers or users or groups in each OU. Don't have an OU with Users and computers or computers and groups, or any combination. This can cause some unintentional problems (and it's just good organization).
4. OU Structure is extremely important in regards to GPOs. It is easier to write a single GPO and link it in many places than to write a single GPO and link it to one location, but then have to deal with computers or users that the policy should not apply to being in the same OU. Think of your OUs as Group Policy Boundaries first, and Organization System second.
5. Avoid blocking policy inheritance if possible. This goes hand-in-hand with good OU design. Blocking Policy Inheritance is never necessary if the OU structure is designed properly.
6. Avoid using Policy Enforcement if possible. Policy enforcement makes it so the policy will always take precedence and be processed last. That means the settings in the policy cannot be over-ridden by anything other than another policy with Policy Enforcement set. If you have a policy that absolutely has to apply to objects in a specific OU, change the processing order so it is at the top of the priority list.
7. The only thing you want to link directly to the Domain itself is your Domain Password Policy. This *can* be set in the Default Domain Policy, but avoid doing so. Create a new GPO, set the password policy settings, link it to the domain, and make sure that GPO has highest priority. This GPO will control what kinds of passwords users can have on their AD accounts, and linking password policies anywhere other than the domain itself will not change AD account password policy requirements. I've actually had numerous individuals who just couldn't wrap their heads around this rule and thought that linking Password policies to OUs with users in them would allow them to have different password settings for different groups of people in the same domain. You can only have one domain password policy GPO applied per domain. Whichever one has highest priority is your effective domain password policy. If you want to have different password requirements for different groups of people, you have to use Fine Grained Password Policy or another domain.

These aren't really best practices, but strategies that I use:

1. Use easily identifiable names for your GPOs. Arbitrary stuff like "Computer settings" will confuse people who didn't set the GPOs up in the first place.
2. Related to 2, craft your GPOs according to Purpose rather than where you're linking them. That means if you want to have a GPO that has Server Hardening settings in it, only put server hardening settings in it, and label it as such.

There is a lot of discussion to be had in regard to having lots of little GPOs or one big one. I tend to prefer crafting smaller GPOs that can be used on many different OUs than large GPOs with all the settings in them.

There are costs and benefits associated with each strategy you use, so you have to weight those against the needs and wants of the environment you are working in. For instance, having lots of small GPOs can increase GPO processing time and cause you to have a huge list of GPOs to work with, but if done correctly it will allow you to completely avoid having to deal with policy processing order or inheritance issues, since ideally you wouldn't have competing settings in the little GPOs.

Larger GPOs with more settings will require less processing at log on (since systems have to make fewer requests for GPO information), and keep your list of GPOs small, but you will run into more situations where you have GPO setting conflicts that you have to troubleshoot, and GPO inheritance becomes something you have to be more aware of.

Ultimately, GPO best practices are very situational, so it's hard to give you firm guidance of things you should "Always" do or "Never" do. There *are* times when policy enforcement is necessary, or when disabling a GPO is necessary. You have to be a little bit flexible and come up with strategies that work for your environment, and if that means having all your GPO settings in a single GPO, so be it.
Joseph MoodyBlogger and wearer of all hats.Commented:
Most best practices are what works best in your environment. For the single setting vs giant GPO question - see this article:

My personal best practice tips

1.  Always comment everything - future you will be grateful

2. enable verbose (highly detailed) status mode to make troubleshooting a bit easier.

Below are two articles on those two tips:
LockDown32OwnerAuthor Commented:
Thanks Joseph. Interesting reading but I am looking more for how, in general, other admins set up GPOs and where they place them. There seems to be a million different ways to do it and I am just looking for some general guidelines.

No two networks are the same so I know explicit detail won't work. Just looking for the basics.
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

Joseph MoodyBlogger and wearer of all hats.Commented:
One final performance tip: Always place GPOs closet to the objects they are applying to.
LockDown32OwnerAuthor Commented:
That's what I was looking for acbrown2010. Just some general guidelines. A couple observations/questions:

#2 Don't use computers and users right off the root. The only way to link GPOs to these are right from the domain. I figured that out the hard way :) I made two new OUs called "Employees" and "Workstations". Moved everything to them and link GPOs to them. Is that what you would recommend?

#6 If you have more than on GPO linked to an OU the last one linked takes precedence? How do you change the order?

Linking to the Domain itself is cheating? Not recommended?
Adam BrownSr Solutions ArchitectCommented:
#2 - That's the best way to handle it, yes.
#6 - There is a method for determining precedence for GPOs. The further away from the OU the GPO is linked, the lower its precedence, unless it is enforced. GPOs linked to the same OU are processed from the last one linked historically. If you are in the GPMC, you can change the processing order by clicking on the OU and changing Link Order. GPOs in that screen are processed from the bottom up, meaning that the GPO at the top of the list is the one whose settings will "win" during conflicts.

Linking to the domain will cause all computers/users in the domain to apply the policies, which isn't usually something you'll want to have happen. So it's usually best to avoid doing so. Smaller environments can get away with doing it, but larger environments with complex OU structures can have a lot of problems with domain linked GPOs.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.