The World According to Mitch

I am asked all the time what the best practices are for domain controllers in a virtualized environment.  There are several that I will call out, but let’s begin with the simplest rule.

You should never have ONE domain controller.

This rule is not only true in virtualized environments, it is always true.  If you are too small to have a domain that is fine, but if you have a domain you should have two DCs.  If you run Windows Small Business Server that rule is just as true – join a second server to the domain and promote it.  YES IT DOES WORK, please don’t argue it again!

You can absolutely virtualize your domain controllers.

I hear this question from people all of the time… and the reality is that there is nothing wrong with virtualizing your DCs.  If the main concern is the Time Synchronization issue, then there is a simple answer for that.  Your Active Directory domain resources will not be able to authenticate if the time is off by more than 300 seconds (5 minutes).  However that skew is from the domain, and not your wrist watch.  If your radio says it is 3:15pm and your domain says that it is 10:38am, the only thing that matters is that your network resources think that it is between 10:34 and 10:42. 

In simple terms, if one time resource is off it is bad… if ALL of your time resources are off, it’s not.  This theory may fall down with external resources – I have noticed that Twitter (or at least many Twitter clients) are sticklers for time, and if you are off then you will not be able to authenticate.  Lync can also be an issue, and I am sure there are dozens of other externally provided services that will cause issues.  However internally as long as your client and your server have the same wrong time, you’ll be fine.

So with that being said, my tendency is to select one domain controller and configure it to synchronize with an external time server.  I will then create a GPO in my domains to use that server as the authoritative time source for the entire network.  That prevents all manner of things from going wrong if you find the time is off.

Your Domain Controllers should be just that… and not much else!

Your DC should not be a file server, database server, media server, deployment server, update server… there are only three services that my domain controllers generally perform: Active Directory Domain Services, Domain Naming Service (DNS) server, and Distributed Host Configuration Protocol (DHCP) servers.  In my networks these three services go together nearly all of the time.  I don’t know of any good reason to put anything else on a domain controller, and every time someone says ‘Well what about…THIS?’ I disagree.

Of course, sometimes you don’t have a choice… Windows Small Business Server is a good example of that, but as you have likely heard me say before, SBS out of the box forces you to break a lot of rules that are simply not meant to be broken.  If you ever hear me discuss it I have said there are ways to make it more palatable… but that does not change the facts.  This is one reason I always tell my classes that it is easier for an enterprise administrator to adapt to small business IT than it is the reverse… the good habits of the enterprise admin will never hurt the SBS (although they may be considered overkill); some of the habits of small business IT Pros can, conversely, do serious damage to the enterprise IT environment.

Don’t P2V your domain controllers.

This rule is not as clear-cut as the others, but calls on some of them.  I do not believe in performing physical to virtual (P2V) migrations of domain controllers.  If an organization does have a physical domain controller that they would like to retire, I feel the following is a much safer and cleaner practice:

1. Before you begin (as much as 10-14 days in advance) I will reconfigure the DHCP scope on the server in question to shorten the address length from whatever is currently in place (by default 8 days) to 1 hour.  This will prevent or at least minimize problems later on.
2. When you are ready, create a new virtual machine and install the operating system.  Make sure you patch it to the most recent service pack, and apply all applicable critical and security patches.
3. Join the new server to the domain, and promote it to domain controller.  Assuming you are on Windows Server 2008 R2 Service Pack 1 (which you should be by now!) you need to install the Active Directory Domain Services role, but the dcpromo.exe command will do that for you.
4. After the server reboots, it will begin to synchronize with the Active Directory.  Remember, since AD is a distributed database, when you add a new server to the mix it will simply (over a period of time directly related to the size of your organization, factoring for network bandwidth issues) receive a complete copy of the AD that will be identical (upon completion) to the original server.  DNS will do the same thing, as long as you a) install the DNS role when you promote the server, and b) your DNS Zones are configured as Active Directory Integrated.
5. Install and configure the DHCP Server role in the new domain controller.  If you have room to grow with your IP addresses I would recommend creating a completely different scope, but if you are tight then creating an overlapping scope will only cause very temporary headaches, most of which will be mitigated by doing this switchover during off-peak hours.  Remember to copy any reservations from the original server, especially when you have devices (such as printers) that require specific addresses.  Also, do not forget to verify that all of your Scope Options are properly configured.
6. Stop the DHCP Server service on the original server (net stop “DHCP Server”).  Again, If your scopes are overlapping be sure to do this during off-peak hours.
7. If the physical box held any of the Flexible Single Master Operations (FSMO) roles then you should transfer them to the new server, or to another domain controller in the organization.  If you forget to do this they can later be seized, but this is the easiest and least intrusive way of doing it.
8. You can leave your source DC on for a week or two, but after a day or so I would usually power it down; don’t reformat it or throw it out just yet, but at this point you are ready to go!

One of the rules of P2V Migrations is GIGO: Garbage In, Garbage Out.  In other words, any legacy issues you may have had previously – whether it’s clutter, breaks, bugs, or whatnot – goes with you.  With the distributed database replication model of Active Directory you get to start fresh, with all of your data. 

This method is also a great way of upgrading a DC from Windows Server 2003 to Server 2008 R2 – rather than do an in-place upgrade, you can simply do the side-by-side virtualization dance.  It won’t change your schema or upgrade your Domain (or Forest) Function Level, although if it is the first 2008 R2 domain controller in your domain you will have to run a couple of scripts to prepare the domain by running the following commands:

(On the server that holds the Schema Master FSMO role): adprep /forestprep

(On the server that holds the Infrastructure Operations Master FSMO role): adprep /domainprep /gpprep

That’s about it… as I mentioned, there may be exceptions if your DC is doing something that (according to my guidelines) it is not supposed to be doing, but then again this may be a great opportunity for you to step in line with best practices and separate other roles from the domain controller.

No go forth and virtualize your Active Directory Domain Controllers!