Networking

10 tips for effective Active Directory design

The way you design your Active Directory can make a huge difference in how well your network functions and how easy it is to administer. These best practices will help you maximize efficiency, simplify maintenance, and readily manage AD as needs change.

Active Directory design is a science, and it's far too complex to cover all the nuances within the confines of one article. But I wanted to share with you 10 quick tips that will help make your AD design more efficient and easier to troubleshoot and manage.

Note: This article is also available as a PDF download.

1: Keep it simple

The first bit of advice is to keep things as simple as you can. Active Directory is designed to be flexible, and if offers numerous types of objects and components. But just because you can use something doesn't mean you should. Keeping your Active Directory as simple as possible will help improve overall efficiency, and it will make the troubleshooting process easier whenever problems arise.

2: Use the appropriate site topology

Although there is definitely something to be said for simplicity, you shouldn't shy away from creating more complex structures when it is appropriate. Larger networks will almost always require multiple Active Directory sites. The site topology should mirror your network topology. Portions of the network that are highly connected should fall within a single site. Site links should mirror WAN connections, with each physical facility that is separated by a WAN link encompassing a separate Active Directory site.

3: Use dedicated domain controllers

I have seen a lot of smaller organizations try to save a few bucks by configuring their domain controllers to pull double duty. For example, an organization might have a domain controller that also acts as a file server or as a mail server. Whenever possible, your domain controllers should run on dedicated servers (physical or virtual). Adding additional roles to a domain controller can affect the server's performance, reduce security, and complicate the process of backing up or restoring the server.

4: Have at least two DNS servers

Another way that smaller organizations sometimes try to economize is by having only a single DNS server. The problem with this is that Active Directory is totally dependent upon the DNS services. If you have a single DNS server, and that DNS server fails, Active Directory will cease to function.

5: Avoid putting all your eggs in one basket (virtualization)

One of the main reasons organizations use multiple domain controllers is to provide a degree of fault tolerance in case one of the domain controllers fails. However, this redundancy is often circumvented by server virtualization. I often see organizations place all their virtualized domain controllers onto a single virtualization host server. So if that host server fails, all the domain controllers will go down with it. There is nothing wrong with virtualizing your domain controllers, but you should scatter the domain controllers across multiple host servers.

6: Don't neglect the FSMO roles (backups)

Although Windows 2000 and every subsequent version of Windows Server have supported the multimaster domain controller model, some domain controllers are more important than others. Domain controllers that are hosting Flexible Single Master Operations (FSMO) roles are critical to Active Directory health. Active Directory is designed so that if a domain controller that is hosting FSMO roles fails, AD can continue to function -- for a while. Eventually though, a FSMO domain controller failure can be very disruptive.

I have heard some IT pros say that you don't have to back up every domain controller on the network because of the way Active Directory information is replicated between domain controllers. While there is some degree of truth in that statement, backing up FSMO role holders is critical.

I once had to assist with the recovery effort for an organization in which a domain controller had failed. Unfortunately, this domain controller held all of the FSMO roles and acted as the organization's only global catalog server and as the only DNS server. To make matters worse, there was no backup of the domain controller. We ended up having to rebuild Active Directory from scratch. This is an extreme example, but it shows how important domain controller backups can be.

7: Plan your domain structure and stick to it

Most organizations start out with a carefully orchestrated Active Directory architecture. As time goes on, however, Active Directory can evolve in a rather haphazard manner. To avoid this, I recommend planning in advance for eventual Active Directory growth. You may not be able to predict exactly how Active Directory will grow, but you can at least put some governance in place to dictate the structure that will be used when it does.

8: Have a management plan in place before you start setting up servers

Just as you need to plan your Active Directory structure up front, you also need to have a good management plan in place. Who will administrator Active Directory? Will one person or team take care of the entire thing or will management responsibilities be divided according to domain or organizational unit? These types of management decisions must be made before you actually begin setting up domain controllers.

9: Try to avoid making major logistical changes

Active Directory is designed to be extremely flexible, and it is possible to perform a major restructuring of it without downtime or data loss. Even so, I would recommend that you avoid restructuring your Active Directory if possible. I have seen more than one situation in which the restructuring process resulted in some Active Directory objects being corrupted, especially when moving objects between domain controllers running differing versions of Windows Server.

10: Place at least one global catalog server in each site

Finally, if you are operating an Active Directory consisting of multiple sites, make sure that each one has its own global catalog server. Otherwise, Active Directory clients will have to traverse WAN links to look up information from a global catalog.

More tips?

What other design practices would you recommend? Have you ever regretted a decision you made when implementing AD?

About

Brien Posey is a seven-time Microsoft MVP. He has written thousands of articles and written or contributed to dozens of books on a variety of IT subjects.

10 comments
stephen.sandifer
stephen.sandifer

Good headline for #6. Although other posters have explained how to recover FSMO roles it is vital that the AD administrator keep track of where they are. #8 should be, "will administer Active Directory", not "administrator". The latter is, of course, not a verb.

Derteufel
Derteufel

You dont have to rebuild an entire AD database if you have a 2nd DC. You can just seize the FSMO roles.

jgeith
jgeith

Make all DCs global catalogs and DNS servers. FSMO roles vs GC isn't an issue if ALL DC's are GCs. But this is an all or nothing design. Assign pri DNS on the NIC to itself, sec to other DNS servers. If each DC has a DNS server it can still start even if your other DNS seervers are not available.

PScottC
PScottC

Mixed DC versions, while functional, may be your biggest headache in the long term. Microsoft's recommended best practice is to keep all DCs at the same OS version and SP level. If you upgrade one, make a plan to upgrade all of them. There are long term issues with AD and FRS replication that can get painful to resolve.

labattomy
labattomy

While the design elements mentioned are critical, I think they are only part of the AD design. After AD is up and running, you need to design your OU structure. I prefer an OU structure based on an administration model keeping in mind the need to either locate objects based on geography or company organizational structure. Either way I then prefer to separate the objects further into sub-OUs based on object Type (ie Users, workstations, Servers, Groups). This makes it easy for delegation of rights as well as for applying Group Policy. I think this applies to large organizations as well as smaller environments.

Dave Pusey
Dave Pusey

You only need to backup a single domain controller. Once it has been restored, the rest can be by dcpromo-ing clean installs of Windows. The roles can then be checked/assigned as per this KB article... http://support.microsoft.com/kb/324801

tim.3.mitchell
tim.3.mitchell

One addendum to number 6: avoid backing up the RID master as this should never be restored, so where possible I prefer to see the RID master held on a separate, non-backed-up DC.

mamacat
mamacat

expensive - depending on the size of the company and the age of the network. With some older servers, that might mean a hardware upgrade as well. Good tip, just in many cases it's really hard to get the budget to do that.

HaroldHO
HaroldHO

It's important to not be too granular, too. Don't confuse granularity with accuracy of application, either. For instance, using OU structure as your only method of targeting users or computers can be ineffective as things move around. Make sure to use a combination of GPOs assigned to specific OUs, higher-tier OUs using security filtering in the scope, and utilizing the Sites to target IP subnets.

kevaburg
kevaburg

We are running 120 Oracle 10g servers and 160 SQL 2005 servers. The problem is we want to migrate to Server 2008 R2. The problem is Oracle 10g R1 won't run on the Server R2 so we have to step backa little for those. The result is a mixture of Windows 2008 R1 and R2 machines (as part of our migration) and the older Server 2003 R2 machines for our legacy applications that we can't do without. The reality is that in large networks with alot of applications, having a single Server OS and service pack installation thoughout the enterprise simply isn't possible.

Editor's Picks