Active Directory Design Principles: Part 2

Design your Active Directory

In most corporations and large organizations, there are people with job titles such as "Network Architect", "Windows Server Configuration Owner" or "Network Designer". These people do not have these titles just for fun. In large organizations, there is an actual need for people whose sole purpose is to design or optimize the networking topology according to how technology progresses. This is also valid for people who work in the Security and the actual Business Solutions sections of large corporations.

There are always new ways of doing things and new designs surfacing in the IT world, and those people need to stay on top of their respective fields. If you are a medium to small-sized company, you can probably combine all of those roles into one person or have several roles distributed over few people.

This is especially true for Windows Server architecture and Active Directory. When designing your Active Directory, you need to really open your mind and focus on the future. A bit of clairvoyance doesn't hurt here. The problem with an Active Directory design for a medium to large-sized company is actually two-fold. One, you need to be able to make your design scalable in the future and two, you need to be able to migrate to your new architecture with the least user impact.

In order to make this a bit easier, here are two small checklists. The first one contains things to consider when designing a global AD, and the second one is a checklist of things to consider when finalizing the design, or when migrating. These points are not in any particular order as they should all be considered.

Checklist When Designing a New AD

  • Is the name future-proof (DNS)? Do you own the DNS name?
  • How many users are in each office?
  • What's the bandwidth available between offices?
    • Is it enough for smaller offices to authenticate in a central location?
  • Who will administer the AD?
    • Who will perform day-to-day tasks (password resets, user and computer account creation)?
  • Are there plans to build on the AD with additional services, such as Exchange, SharePoint etc.?
  • Which DCs will be Global Catalog Servers?
  • Where will the FSMO roles be located?
  • Will the new design support all the current business functions?
    • If not at the beginning, will there be a transition period and if so how long?
    • Have you cleared this with business?
    • Will all the third-party applications still work with this design?

Checklist When Finalizing the Design or When Migrating to an AD

  • Have you chosen a design?
    • If yes, have you considered the model carefully, taking into account future growth?
  • Is the DNS name available and is it future-proof?
  • Have you calculated the appropriate number of DCs?
  • Have you considered DC failover and the network strain?
  • Is the number of administrators and their roles clearly defined?
  • Do you have processes for change mangement in place?
    • If no, should you?
  • Do you have back-up designs and solutions in place where it matters (hub sites and data centers)?
  • Is your staff trained or will there be training to bring them up-to-date with the new methodologies?
  • How significant will the user impact be?
    • Are mechanisms in place to inform the users of the coming changes?
  • Are all networked applications accounted for?
  • Have service accounts been assigned and possibly consolidated across the enterprise?
  • Is a realistic implementation schedule in place?
    • Has it been approved and discussed?

Naming standards

Before you begin to design anything, you need to make sure that you have a naming standard for everything across your entire organization. If this is missing, and everyone just decides what to name the GPO and computers, how usernames are formatted, how service accounts are named, etc., then you will never have a proper structure.

Username and service account naming

There are endless ways of naming your user accounts and you probably already have one or another in place. If, however, you have a multitude of different ways because of acquisition, or autonomy of certain offices in the past, defining a universal way of naming user accounts is crucial. This will not only help you with administration, but also with deploying services across your organization. If you name the service accounts using a standard, every administrator knows exactly what the account is for. When you name the users in a standard way, processes regarding user administration can be very streamlined. You should also consider the lockdown of service accounts, for example by defining what machine they can authenticate from and what they can access. The same goes for user accounts.

Group policy naming

A common thing for administrators to do is name group policies after what they see as the most logical thing at that moment. You should have clear guidelines of how to name GPO's so that they make sense even to a new person. "Internet Explorer Test 3" as a GPO name is not anything that you could guess what it includes, or to whom it applies. Naming conventions are overlooked a lot of the time, not only for GPOs but for many administrative things that do not seem to matter at the time. In short, the naming of the GPO is important so that you can immediately know what the policy does and who it applies to. This makes troubleshooting much easier. The following figure shows GPOs named with a little bit more sense, as it shows that the policy is global and that the settings that these policies set are for users and computers.

active directory

Design with scalability in mind

Whenever you read books or white papers about Active Directory, they mention the amazing scalability of Active Directory, its security features, and the redundancy. Active Directory was coded from the ground up with mechanisms that make it easy to add or remove domain controllers. With this ability, features are built in to failover to the next domain controller in case of a failure in one of them. The client never really knows about this.

On paper, this is a great thing and reduces the administrative overhead. In practice, it is just as good. Large corporations can have Active Directory structures that work so perfectly that the administrators really do not have to worry about anything regarding stability. This applies even when there are more then 30,000 users over several countries and almost twice as many computer accounts. As the saying goes: "Behind every strong man stands a strong woman". The same goes for Active Directory: "Behind every perfectly working Active Directory, there is a good architect".

Microsoft's recommendation is to have 150 users per domain controller. This is a good recommendation yet you do not need to take it 100% verbatim. In any site with 150-200 users, you should have at least two domain controllers. This is not meant as an issue of scalability but more of a failover issue. In a case of 400 users for example, Microsoft recommends, according to their white paper, three domain controllers. For 400 users in a single site that is a lot. Considering that the heavy load on the domain controllers will be in the morning when people arrive and log in, and after lunch when people log in again, most of the time the domain controllers will sit idle. In this case, the recommendation is rather to spend a bit extra on more RAM and more CPU power than on an extra machine.

If your network is well-designed and your domain controllers have a little more power, you can load a relatively large number of users onto them. It is not unheard of to have over 600 users per domain controller in a large organization and the average load during the day is around 40%. It rises during peak hours of logon and logoff, as is expected, but quite a lot of time they are almost idle.

The key factor here is memory and CPU. If the amount of RAM you have is twice the size of your Active Directory database, the database will be loaded completely into memory by the domain controller. This, combined with a server-class CPU such as XEON or Opteron, will reduce the processing time during authentication per user to fractions of a second. If you could only authenticate five people per second on a domain controller, it would take you two minutes to authenticate 600 users. And 600 users do not all arrive at work at the same time and log in at the exact same time.

Scalability in Active Directory is achieved through the distributed model that it builds on. Every domain controller is writable in the AD and holds more-or-less a complete copy of the directory. When changes occur in one site on one DC, these changes are then replicated out to all the others. This architecture is radically different from Windows NT 4, where there was a primary domain controller and many backup domain controllers.

There is only one problem with this set-up, and this becomes apparent when you have a lot of distributed domain controllers and a lot of sites. If you do not invest time into the design of the sites and site links, you can cause a lot of damage and a lot of unnecessary traffic in a very short time. Site links are there to provide ways of controlling when and how the Active Directory is replicated to other domain controllers. You do not want to end up replicating a 2GB database during business hours over a 2 Mbit link. However, if you do not properly document and implement a good replication design, unnecessary delays will happen. You will then have the nice job of finding out where the replication went wrong, and depending on the number of sites you have, this can be a non-trivial task. The following figure shows different replication schedules and site links that make it quite normal for one site to have a six to eight hour delayed version of the Active Directory.

active directory

Replication schedules are not difficult to design and implement, but do require a bit of time and input from other sources. Remember, because Active Directory is so distributed, the site with the slowest site link and the slowest replication will have the most outdated version of Active Directory. It is recommended that in case something unexpected happens, such as dismissing an employee in a remote office, you force-replicate between the main site and that site-as soon as the changes are made. If the person is leaving in two week's time, set his or her account on the date they are scheduled to leave and then verify that the data has been replicated after this date.

Flexible Single Master Operation Roles (FSMO)

When you design your topology, you have to be aware of the Flexible Single Master Operation Roles (FSMO) and place them accordingly.

FSMO roles are roles that only one server in an Active Directory can have. These roles, while not apparent immediately and not needed all the time, are very important, and some of them are very crucial.

There are five FSMO roles and they must be present in an Active Directory. Three of these roles are domain-specific, which means that in every domain in an AD forest, they have to be present. The other two are forest-specific and therefore one of each needs to be present in each of your AD forests. See the table below for a few summary of roles and where they belong:

Name of the role

Where is it needed

RID Master (Relative ID Master)

In each domain

Infrastructure Master

In each domain

PDC Emulater

In each domain

Schema Master

In each forest

Domain name Master

In each forest

Each role does different things and in order to understand the importance of the roles, a full description of each role, and the steps you need to take to see which server has what role, is given below:

Relative ID Master (RID Master)

This role allocates security RIDs to DCs within a domain. The DCs use the allocated RIDs and in turn allocate them to security principals, such as users and computers, as they are added. The server that has this role also manages the movement of objects between domains. It monitors all of the pools allocated to all of the DCs within a domain and in doing so allocates more RIDs where needed, to prevent these pools from becoming exhausted, which would result in the inability to create new user or computer accounts.

Infrastructure Manager

The server having this role maintains security Globally Unique Identifiers (GUIDs) and Distinguished Names (DNs) for all objects that are referenced across different domains. However, its most common task is to update user and group links.

PDC Emulator

This is a crucial role, not only because it emulates a Primary Domain Controller for Windows NT, but because other DCs look at the PDC as the primary source for confirmation of authentication, and it is the most trusted source for time within a domain.

To change any of the three domain-specific roles, open Active Directory Users and Computers, right-click on the domain name and click on Operations Masters. You will then get the following screen where you can assign the roles in your domain.

active directory

Schema Master

The server having this role maintains all schema information and all modifications to the schema. The schema in a forest determines what types of objects are permitted and what types of attributes an object can have. A typical scenario for this role would be an installation or deployment of Exchange, or an upgrade from Windows 2000 to 2003, because these operations contain schema modifications.

Domain Naming Master

The server having this role follows all of the names of the domains in a forest. This role is needed in order to add or remove domains.

To change the Domain Name Master, open Active Directory Domains and Trusts, right-click on Active Directory Domains and Trusts and then click on Operations Master. On the resulting screen, you can change the Domain Naming Master.

active directory

There are generally three rules for how to place these roles within an AD (outlined in, in order to make administration and maintenance easier.

  1. In a forest, the Schema and Domain Naming Master should be placed in the same DC.
  2. The Infrastructure Master should be placed in a DC that does not hold a Global Catalog or, if every DC holds a Global Catalog, it can be placed on any DC.
  3. The RID Master and PDC Emulator should reside on the same DC, which should have quite good hardware. If the load on this server calls for a separation, make sure that these two roles are located on DCs that are direct replication partners of each other in the same site.

Placement and maintenance of these roles is very important, and the next table shows each of the five FSMO roles and the consequence of a failure of these roles.

Name of Role

Consequence of failure

Schema Master

No updates to the Active Directory schema will be possible. Since schema updates are rare (usually done by certain applications or possibly an administrator adding an attribute to an object), a malfunction of the server holding the Schema Master role will not pose a critical problem in the short term.

Domain Naming Master

The Domain Naming Master must be available when adding to or removing a domain from the forest (i.e. running DCPROMO). If it is not, then the domain cannot be added or removed. It is also needed when promoting or demoting a server to or from a Domain Controller. Like the Schema Master, this functionality is only used on occasion and is not critical unless you are modifying your domain or forest structure.

PDC Emulator

The server holding the PDC Emulator role will cause the most problems if it is unavailable. This would be most noticeable in a mixed mode domain where you are still running NT 4 BDCs and if you are using downlevel clients (NT and Win9x). Since the PDC Emulator acts as a NT 4 PDC, any actions that depend on the PDC would be affected (User Manager for Domains, Server Manager, changing passwords, browsing, and BDC replication).

In a native-mode domain, the failure of the PDC Emulator isn't as critical because other domain controllers can assume most of the responsibilities of the PDC Emulator.

RID Master

The RID Master provides RIDs for security principles (users, groups, computer accounts). The failure of this FSMO server would have little impact unless you are adding a very large number of users or groups.

Each DC in the domain has a pool of RIDs already, and a problem would occur only if the DC to which you are adding the users/groups on runs out of RIDs.

Infrastructure Master

This FSMO server is only relevant in a multi-domain environment. If you only have one domain, the Infrastructure Master is irrelevant. Failure of this server in a multi-domain environment would be a problem if you are trying to add objects from one domain to another.

The other thing to consider is, of course, the future of the company and its strategy. If your business is in an industry or sector where fast organizational change, such as mergers or acquisitions, is quite possible or even likely, then you should adopt a design that will allow you to incorporate newcomers whilst maintaining the security of your own infrastructure.

The basic motto to follow when designing your Active Directory is to think of the future and not of the present.

Migration from other authentication services

Even though the time of Windows NT 4 is long gone, a lot of companies still have NT 4 domains running and are only now planning to migrate them to Active Directory. When you migrate from other domains, there is nothing more frustrating than installing a domain controller and, when prompted for the future NetBIOS name, it tells you that this name is already used in the network.

You have to do your research beforehand and make a decision as to what name to take. Then, scan your network and make sure no-one is using that name for some purpose at the time of installation. If your organization decides to use something that is already in use on the network, find out who is using it and explain to them that they have to change it due to company policy or, if it is used without authorization, have them remove it. Do not do this without proper approval from higher management.

Migration into Active Directory is, with the tools provided by Microsoft, not really a difficult task any more. The main issues you will face aren't the users and the fact that their logins might not work-this can be fixed fairly quickly by your helpdesk. The real challenge comes with applications that run on Service Accounts or authenticate against specific servers. Suppose NailCorp's accounting software is installed on a server and no one knows how it works any more, or the person who does know is unavailable. Suppose documentation, as it is often the case, is virtually non-existent. Then the machine is migrated to the new domain and the application stops working. After the migration is complete, the old domain controllers are turned off. As it happens, all of this was done during a weekend and the old machines have been removed and placed onto trolleys to be decommissioned or recycled. When the mistake eventually surfaces, things can become quite hectic in trying to get the application running again.

The key point in making a smooth migration is to properly plan it. This is especially true when you have a completely re-designed and very organized OU structure. Once you have policies in place, you don't want to migrate the wrong users or the wrong computers into the wrong OU.

Keeping up-to-date and safe

Now that we have gone through designing your Active Directory, we need to address security and documentation. These are points that are just as vital as your design and migration. During the dot-com bubble, everyone that ever turned on a PC could call themselves a Systems Specialist or Systems Engineer. Crazy things, like Platform Designers, because they had a Windows 2000-based computer at home, were not unheard of either. The problems during the bubble were that people who really knew what they were doing were too expensive for a lot of companies to afford, and cheaper "specialists" were hired instead. These people then messed up most networks and network services and in the end were let go. The company then hired a more expensive person to fix the old issues, and so on. Because of this, and the rapid growth and changing markets during the bubble times, documentation was always ignored and backup solutions were bought and implemented—but 50% of them never really worked when push came to shove.

Those who survived the bubble and still work in IT have, to a big extent, adopted the 'no documentation and so-so backup' mentality. "Good enough is good enough" is what a lot of people say, but when it comes to a service that essentially is the lifeblood of your company, you do not want to go with 'just good enough'.


Documentation seems to be a problem in many companies and is usually the component in a project that is most often overlooked. Every time that either a new employee starts or an external contractor is hired for an AD related project, instead of getting a binder with proper documentation, he or she is assigned a mentor or a buddy who explains the systems and infrastructure. Then, the first new task is to write the documentation that has been missing for the last X years. However, after the first week he or she realizes there is not enough information and when they ask for it, they get some vague pointers on where to look.

Unfortunately, the usual circle is that documentation is left for later stages in the project, and over time gets forgotten or information is passed on by word of mouth, or as a collection of links to websites, instead. Over time, the missing or incomplete documentation becomes a costly burden to the organization knowledge is lost and, because of its non-existence, is impossible to back up. The eventual creation of this documentation, which wouldn't have taken that much time to begin with, is a lengthy and expensive process.

Documentation is not really that hard to do, but it can be hard to convince your project or program manager allocate the extra time in order to complete it. Usually, the questions will arise as to why this needs to be done now and cannot be done later. A good argument for this kind of questioning would be to explain to him or her that at a later time, information is no longer fresh and remembered, or that it is necessary for backtracking problems. I have found that both of these work very well and generally managers will give you time to document properly. If, however, you don't get the time, please make sure that you obtain written confirmation regarding the project or program managers acceptance that there is no way of knowing what has been done, and no time to write proper documentation.

Getting documentation done is actually quite easy. It comprises two steps, and once you have done this a couple of times, it will flow easily and you will produce documentation that your manager will actually be proud to show around.

First open notepad or any text editor and write, in short points, what you do, every step. In some cases, I just copy and paste the command, or the output, or both, into a line and keep going. Once you have completed the task, take a standard company template and format it into four sections. The outline is shown in the following table:

Document part or section


Presentation page

A plain page containing nothing but the title of the document, the department, and the name of the author. A version table at the bottom of the page is optional.


A proper index table. This should be on its own page and will make it look more professional.


This describes, in a short paragraph, what this document is about.


All of the actions you took with detailed descriptions. Screenshots are a big winner here. Also make sure you separate different subjects with headers.

If you stick to your template all the time when writing documentation, you will be the pride of your unit. Basically, should the need arise, you would be able to produce documentation where other people can't. It might look like a lot of extra work but as I mentioned already, it becomes very routine after a couple of times, and when you see a properly formatted document, it does make you proud. It also make your life easier when someone asks you how to do certain things,: you just open the document, print it, and point the person at the printer. A lot of time saved!

Of course, writing it is only one part of the equation. The other part is to keep it up-to-date. If you write a document about what group policies you are currently applying, then any change needs to be reflected in that document for it to be up-to-date.

Documentation plays a big part in disaster recovery, and sitting having a freshly-recovered domain, not knowing some of the settings that were applied earlier that now prevent things from working, dearly-it may even cost you even your job!

When writing your DR, please make sure that you have a printed copy in each location and at least one offsite copy per location. In some companies, it is standard practice for the domain or Enterprise admin at least to have a printed copy at home or on a USB key with him or her at all times. It is also good practice to have a printed copy or an electronic copy in the location's safe so that it can be retrieved very quickly.

Write your documents regarding your infrastructure as clearly as possible, and do not make any assumptions about who will be reading the documents. It could very well be a summer worker or a trainee, although very often companies rely on professional DR-specialized companies. Some of these companies not only do regular, twice a year, complete DR in an isolated environment, but also  sometimes provide you with warm sites to get your infrastructure back up and running more quickly. However, you never know what the disaster situation will be and if it is bad, you will want to ensure that everything possible is provided in the instructions.


I worked in a company once with a seasoned sysadmin who always said: Backups are like rumors, everyone talks about them but no one verifies that they are true. I found this to be correct a lot of times. Another good saying is: There are no backups, only restores, successful or unsuccessful ones. Everything else is just an activity leading to a restore.

Companies have backup strategies in place and the occasional repair or deleted file isn't a problem. But what happens if you have a catastrophic failure? What happens when the tapes that are in the server room neatly on a stacked, and labeled Monday through Friday, get water damaged or, worse, fall prey to an electrical fire?

Backups are one of the most crucial parts of your infrastructure and, next to documentation, probably the one taken for granted the most. It is not enough that you have a big nice tape drive or tape robot and that it backs up 100GB every night. What matters is how fast can you restore the data to a usable state. How fast can you recover a system state for a domain controller if your communications link is down and your network is being rebuilt after a natural disaster?

Testing is the key word. In some of the companies that I have worked for, testing of backups is a routine, weekly, event. This might sound like overkill but when the data contained on those tapes is highly sensitive and costs millions of dollars to replace, you will gladly invest half an hour to make sure that you can restore valid and complete files.

Backups, just like documentation, can be a pain but, in the end, you have to weigh the risk versus benefit, and unless you are backing up completely useless data, I guarantee you that your business people will always show you that it is worth keeping an eye on the backups.


In this article, we went through the actual design work. We looked at some of the crucial points to consider with your infrastructure, which included scalability, security, and documentation.

This should give you a good running start and good points to discuss with your management, or at least bring to their attention because they need to be aware of all of this, and they need to see some benefit in your work. Short-term winnings or savings are not always the best and cannot be applied to everything, and the things discussed in this article are prime examples of this.

You've been reading an excerpt of:

Active Directory Disaster Recovery

Explore Title