Best Practices for Designing Group Policy:
The bottom line with Group Policy is that it’s only as good as your Active Directory
design. If you’ve implemented your sites, domains and OUs in the wrong way, Group
Policy will be difficult to use and troubleshoot. So the first step in planning how you’re
going to implement Group Policy on your network is to plan how you’re going to
implement Active Directory itself. Such planning includes decisions like: How many
forests you will deploy (one or several)? How many domain trees? Will there be child
domains? What kind of OU structure will each domain have? And so on. Each of these
decisions should always be made by asking the question: What impact will my decision
have on how Group Policy is implemented in my enterprise? Let’s look at some
guidelines that can help you design Active Directory effectively as far as Group Policy is
The first and obvious principle is to “Keep It Simple, Stupid!” or “K.I.S.S.” In the
context of Group Policy planning, this means two things:
If a single domain will meet all your company’s needs, then use only one domain.
The reason simply is that the number of Group Policy Objects (GPOs) you will
need to create is roughly proportional to the number of domains you have in your
forest. For while linking a GPO residing in one domain to a container (domain,
site or OU) in a different domain does reduce the total number of GPOs you need
to deploy, it can have a significant performance impact and shouldn’t generally be
Keep your OU structure relatively simple, for example two or three levels of OUs
at most. The reason is similar here to why you should keep your number of
domains as low as possible: administrative overhead.
So let’s say you begin your Active Directory design by deciding you’re going to us a
single domain (see Figure 1) with two or maybe three levels of OUs within it. That’s a
good place to start. What’s next?
Figure 1: Have only one domain if possible
Group Policy isn’t just for managing desktops; it’s also terrific for locking down servers
to ensure they’re secure and working properly. And by servers I mean both member
servers (which include file servers, print servers, web servers, DHCP servers, and so on)
and domain controllers. The best way to lock down domain controllers is to leave them in
the default Domain Controllers OU and configure a GPO linked to that OU. There are
two ways you can do this:
Configure the settings in the Default Domain Controllers Policy.
Create a new GPO, link it to the Domain Controllers OU, and configure it.
Which approach is better? Some experts recommend leaving the default GPO untouched
and creating a new GPO and moving it to the top of the link order for GPOs linked to the
OU. That way if something goes wrong later you at least have your default GPO in place
and untouched. On the other hand, if you run the new Security Configuration Wizard
(SCW) of Windows Server 2003 Service Pack 1 on a domain controller, then in addition
to other changes it will modify certain settings in the Default Domain Controllers Policy
to make your domain controller more secure. So either approach works fine, but
personally I prefer the second approach.
What about your member servers? The trick here is to realize that the different member
server roles are basically incrementally different from a baseline (having no role) member
server. So a good approach is to create a top-level Member Servers OU and then beneath
it add additional OUs for each role (Figure 2):
Figure 2: OU structure for member servers.
The advantage of this approach is that you can now create a baseline Member Servers
GPO that generally secures any member server and link it to the Member Servers OU.
That way all of the member servers in child OUs will automatically inherit this policy.
Then you can create a Print Servers GPO and link it to the Print Servers OU, a File
Servers GPO and link it to the File Servers OU, and so on. These different GPOs linked
to child OUs of the Member Server OU can be used to incrementally harden security for
each server role over the basic hardening provided by the Member Servers GPO.
Here’s a tip: if you want to find out more about using the above approach to
harden servers using Group Policy, read the Windows Server 2003 Security Guide
which is available from the Microsoft Download Center. This Guide has terrific
suggestions on how to secure different server roles and it’s well worth plowing
through its almost 300 pages of content. If you don’t have time to read the whole
Guide, check out my blog ITreader.net and click Group Policy under Topics and
you’ll find lots of useful information that I’ve culled from my own reading of the
Guide as well as other Microsoft resources.
Desktop and User Ous
The OU structure you plan for your domain can depend on various things including your
company org chart, branch offices, number of departments, and so on. There’s no hard
and fast single best way of designing OUs for a domain, but the following tips can help
you avoid problems later on when you start creating GPOs to lock down users and their
First off, you should only create an OU if there is some compelling reason for it to exist.
For example, if users in the Sales, Marketing, and Reference departments all have similar
needs as far as security goes, group their accounts into a single OU instead of three. Then
if Sales users have some minor difference in security requirements from the other two
departments, you can create and link another GPO to the OU and use security filtering to
ensure only members of the Sales group have that GPO setting applied to them.
Next, you should try to create your OUs along departmental lines rather than
geographical location. That way you can make more effective use of delegation when you
need to use it. If you must have geographical OUs, make them the top-level OUs and then
create child OUs beneath them for each division or department (Figure 3):
Figure 3: A typical OU structure.
Next, create separate OUs for computer accounts and user accounts (Figure 4). That way
you can use separate OUs to lock down machine settings and user settings. Of course,
you could achieve the same thing by lumping together computer and user accounts into a
single OU, linking two GPOs to that OU, and disabling the machine settings in one OU
and the user settings in the other OU. But keeping your computer and user accounts in
separate OUs will make it easier for you to troubleshoot when Group Policy doesn’t do
what you expected, and it makes mistakes in configuring policy less likely also.
Figure 4: Use separate OUs for computer and user accounts.
Also, try to avoid using Blocking, Enforced, Loopback, and other ways of modifying the
default Group Policy inheritance order. That’s because using these features can make it
really hard to troubleshoot why Group Policy isn’t doing what you intend it to do. If you
find you absolutely must use these features in your Group Policy design, you probably
haven’t designed your Active Directory structure very well. The one exception to this
rule is security filtering, which is a powerful tool that can help make GPO targeting more
accurate without complicating the design. I’ll cover security filtering in a future article on
Finally, avoid making changes to the Default Domain Policy. Instead, create a new GPO,
link it to the domain, and configure its settings as needed. But be very careful what you
configure in any GPO linked to a domain because any settings you configure will be
inherited by all computer and user accounts in all OUs in the domain. So the moral is,
wherever possible configure policy at the OU level and not at the domain level, and use
domain GPOs only for configuring account policy for the domain.