As the IT department for many small businesses over the last 25 years, I’ve had to configure and manage a variety of user and security management solutions. With Windows NT server, Microsoft introduced Active Directory. At the time, server hardware was barely better than a desktop. IT departments spent more money per system for larger disks, bigger CPU and maybe additional network cards, but the fundamental components and their function were that of a desktop. Because of this unreliability, Microsoft and IT technicians recommended having a Primary Domain Controller (PDC) and a Backup Domain Controller (BDC) along with Read Only Domain Controllers (RODC). This insured that in the case of hardware failure by the PDC, you still had DC’s to authenticate to, rebuild your Active Directory hive, etc.
Even as hardware, and Windows Server improved, this practice of dividing up the load and replicating to multiple servers stuck. Let’s face it, it was still a good idea even with hard drives in a raid 5 array and frequent backups. You could still have hardware or software failures from a variety of possible causes. Therefore, the model remained the best way to protect your AD.
However, for some reason many stuck to this when virtualization came along. As a caveat to what I’m about to say, know that I’m referring to a virtualization environment where there are three or more hosts, clustered, with fail-over. Virtualization removes the need to spread the AD roles around, and there are five of them now: PDC (a legacy from NT), Naming Master, Infrastructure Master, Schema Master and RID Master. One would think after all this time these roles could be clustered, meaning you could assign the same role to multiple DC’s and they would stay mirrored, but the sad truth is that each role can only be on one DC. The good news is that at this point, from a hardware failure perspective, an IT person can be just as secure having all the roles on one DC as they can dividing them up. If a host has a hardware failure, the server restarts, as it was, on another host. This is true in a cluster of any major virtualization technology.
At this point you might be wondering why you should care. Virtualization lets you create multiple servers quickly and easily, so why not keep the roles divided. There is one huge area where this comes into consideration, and that’s backup. Even if you backup every DC that has at least one of the five roles, restoring multiple servers takes more time. If the environment for restoration is during a disaster, hardware, IP address and other changes can make even a “whole” Active Directory environment take a while to come up while the hive reconfigures itself. If you don’t have access to a Domain Admin login that also is in the Schema Admin group (which Domain/Enterprise Admins are NOT in by default) and you didn’t back up your Schema Master, you will probably need Microsoft’s help to have any chance of getting your AD to work in the new environment.
All this being said, here is my recommendation in a virtual environment for your domain controllers. Build one server with one virtual CPU and 4 GB of RAM and put all the primary DC roles on it. Install NOTHING unrelated to Active Directory on the DC. Don’t let WSUS or file services or any other functions put it at risk of software corruption. Build a second server in the environment and make it a DC, global catalog only. Make sure you have administrator login(s) in the Schema Admins group in the case you need to seize all the roles on the second DC. As a global catalog server it has all the information it needs, but the roles do not come up without seizing in the case of software failure on the primary DC. Then make sure that both servers do all the things related to AD that do get mirrored, like DNS or group policy management for instance, but, again, stick to only Active Directory related activities on the servers.
Then if you have remote sites, with physical or virtual servers, make them global catalog domain controllers only. A GC DC provides everything users need to login, authenticate, etc. You can even run DNS and DHCP on these servers and, unlike the AD roles, they will stay replicated and mirrored. As long as you have Schema Admin users, you can even seize the roles on these servers in a pinch. I have witnessed that without making sure all your roles are backed up, and that you have access to Schema Admin, an AD environment can be completely unable to come up. My recommendations are by no means mandatory, but for backing up and restoring your Active Directory environment, they will both simplify your life and cause you the least headache in the case of recovery, especially during a disaster.