When writing a Best Practices on Group Policy, it’s hard to know where to start; though fundamentally, if you don’t get your OU structure right (or at least on the right track) at the start, it’s going to be so much hard to manage and maintain your environment.
The structure of your OUs is about designing it for the ease of management (for you!).
There are two mains objectives in OU design, to ease:
- delegating permissions (over the management of those objects in those OUs) and;
- the application of Group Policy
So keep that in mind, even though this discussion will focus purely on design for the purposes of easing the management of Group Policy.
Create a false AD root
At some point, if you haven’t already, you’ll want to exclude some users and computers from Group Policy altogether – whether that’s for testing or production purposes – and a false root will give you that, quickly and easily. And if you did want to delegate permissions to manage “everything” you wouldn’t actually want to hand over the keys to the root of Active Directory; but you could delegate permissions over your new false root and make it look like they have access to manage everything.
But what is a false root? It’s nothing more than a new OU (under your real root of AD), and you then build out your OU structure underneath it.
Usually, a false root OU will be the name of the company, eg:
Under that is where you would then break out into sub-OUs for Servers, Workstations, Users etc etc, and start applying your Group Policies.
“But what about Domain Controllers – do I move those under the new root?”
NO – absolutely not. Domain Controllers should stay in the Domain Controllers OU.
Group Policies DO NOT apply to groups
Outside of needing to delegate permissions, groups can sit anywhere in Active Directory. Some people think that the members of a group and the group itself need to live in the Same OU. They absolutely do not, and probably should not. Groups can be used to filter Group Policies, absolutely, but they will not apply to groups. Group Policies need to be linked to an OU with actual user or computer accounts.
If you are following the Microsoft best practice for RBAC (and why wouldn’t you be) you would probably have an OU for security “Role Groups”, an OU for security “Access Groups” and possibly an OU for email “Distribution Groups”. You’re not going to be applying Group Policies to these anyway, so they can sit wherever looks most logical.
Separating Users and Computers
Fundamental to understanding how Group Policy works, and it’s something I’ll be covering in another 101 post, is that each Group Policy you create will apply to a user object, or a computer object, but not both – and separating your objects into different OUs at this base level is paramount to getting things right.
“Does that mean I should I have one giant OU for all of my users?”
Not necessarily, but maybe. If you think you’re going to need fundamentally different sets of GPOs for say, Managers, over Non-Managers, then by all means, create OUs with those names. You would probably make them sub-OUs of a larger Users OU so that you can have global user-based GPOs at the top Users OU, then more specific GPOs at the next levels down, like this:
And similarly for computer objects and groups, you might want to do something like this:
Similar to how we structured our users, we create a Computers OU so that we can apply GPOs to ALL computers, and then when we need to apply server-specific or workstation-specific GPOs, we already have them separated out.
The above is still quite simplistic, but it’s a start. As you start creating Group Policies, you’ll start to get a feel for when you need to create new OUs to make your life easier… and that’s the point. If you find yourself saying things like “it’d be so much easier to manage these GPOS is we had a dedicated OU for our Remote Desktop Servers”… well, you have your answer – create that new OU.
“Do I need OUs to seperate out computers by Operating System?”
Usually not. Group Policies can be filtered/applied based on operating system, so that’s not really a valid reason to keep them separate. If you really (really) have to separate them out for whatever reason, just make sure you have a “Workstations” OU above them to allow you to apply more universal GPOs to everything, and then get more specific with your sub-OUs.
Invariably though, I see OUs being overused to the extreme. Less is more sometimes.
“Do I need OUs to seperate out users or computers by Location/Department?”
Again, no, not usually. If you have 100 Accountants, you would deinitely put them into a role group, but I don’t usually see a need for them having their own OU.
It’s also possible that different countries have different regulatory requirements, and will require different GPOs, per country. In this case it makes sense to have separate OUs.
“Why create another OU (or sub-OU) when I can just filter by AD Group?”
It comes down to manageability. Is it clear what GPOs apply to what servers? What are you really using those OUs for?
EG: If you find you need to apply a dozen GPOs that are specific to just your Remote Desktop Servers, it’s probably too difficult glancing across your GPOs and knowing what applies to what. Instead, create a new sub-OU (presumably under the Servers OU), move the computer objects and apply those specific GPOs there, like this: