Virtualizing Domain Controllers

One of the frequent questions that come up on the forums is,
“How do I convert (P2V) my Windows Domain Controller (or SBS Server)?”

Let me first start with the following statement.


Now that I have that off my chest - lets explain why and provide some references to back that up.

A Domain Controller could possibly be - and probably is - one of the most important computers on your network. Almost everything relies on Active Directory:

  • Authentication
  • Mail
  • Web
  • File Access
  • etc. etc.

If your Domain controller is not functioning - then rest assured - slowly but surely a lot of other things will stop working shortly thereafter.

I was reading a good blog post from the Active Directory Team on their blog  - How to Virtualize Active Directory Domain Controllers (Part 1). This is a Hyper-V centric article - but it is relevant to VMware as well .I do advise giving the full article a good read.

This is what I have taken with me from the above article.

  1. In most environments there is no reason not to virtualize your Domain Controllers. If they are only being used as Domain Controllers (and not File Servers, DHCP, Web Servers) then unless you have a very large or extremely busy environment your DC’s will not need an extravagant amount of resources so it can run very nicely as a virtual machine.
  2. I would always, ALWAYS, leave at at least one physical server running as a domain controller on the network. The reason being, if your virtual infrastructure depends on your Active Directory infrastructure - and it always does then if your DC’s are not available due to your Virtual Infrastructure being down, or your storage being down, then you will have a serious chicken and egg situation - with not being able to easily bring up the storage or the Virtual infrastructure because they are dependant on DNS / Active Directory and that cannot come up because the the storage / Virtual infrastructure is not available. Jason Boche posted an article last week describing a situation where he had a network component fail - which brought down his NFS storage. One of the VM’s on that storage was his Domain Controller. Once the failure was fixed, he could not bring up the NFS datastores - because they were relying on Name Resolution - and the DC was a VM on the NFS datastore, which could not be mounted, because there was not Domain Controller. As I said Chicken and Egg. True there are ways to get around it but I sleep better at night spending that extra amount of money on a physical server for a domain controller.
  3. Time Synchronization. A  domain controller should always be synchronized with an external time source. do not rely on the internal VMware Tools.
  4. Do not stop or suspend Domain controllers. Leave them on or power them off.
  5. Do not restore a Domain Controller from a snapshot. You will run into USN Rollback problems.
  6. Back up you Domain Controller the same way you would back up a Physical Server, be it NTBACKUP, Windows Backup and Restore (for Windows 2008 and Up) or a 3rd party backup client.
  7. If you try to P2V  a DC you will most likely run into a USN Rollback problem - Knowledge Base Article.
  8. The Easiest way to migrate a Domain Controller is to install a new VM, DCpromo the VM as a new DC and then remove the old one. The process of migrating the data in Active Directory from one computer to another is really simple and completely taken care of by Windows, so do not try and complicate things.
  9. VMware KB 1006996 - Virtualizing existing domain controllers.