I am often asked “should I virtualize my domain controllers”? I thought I’d spend some time walking through the decision points and the common pitfalls in either option.
Option 1: Don’t Virtualize Domain Controllers:
This option is essentially the “do nothing option”. It continues on as you always have. It continues consistency of domain controller services on hardware, but does not gain the abstraction that you enjoy in a virtualized scenario.
Option 2: Virtualize Some Domain Controllers:
This option is the most common. I see a lot of companies virtualizing branch domain controllers or *some* of the domain controllers in their datacenters. These domain controllers benefit from the abstraction of the domain controller functions from the limitations of specific hardware. I usually recommend companies start here, as it is a good place to get comfortable with virtualization of domain controllers, without jumping in head first. In this scenario, I see a lot of companies keep physical domain controllers at their primary datacenter, especially necessary to allow Hyper-V clusters to boot up and serve virtual machines from CSV volumes.
Option 3: Virtualize Everything:
This option says “let’s do it”! In order to go down this route, you need to configure your virtual environment to avoid “chicken and egg” scenarios where domain controllers aren’t booted up and the other virtual machines aren’t able to function. This includes Hyper-V clusters, which do have a dependency on domain controller functions. In this scenario, you’ll configure domain controllers to startup first, then have the other systems on delayed start to avoid issues. Also, you’ll have domain controllers living in “off-cluster” locations, usually being local drives on Hyper-V hosts, or standalone Hyper-V hosts.
How can I virtualize domain controllers successfully?
Here are the steps to success in virtualizing domain controllers:
- Don’t place Hyper-V domain controllers in a cluster. Since the cluster is dependent on domain controllers to function, putting them in the cluster itself won’t do you a lot of good. Make the domain controllers on off-cluster Hyper-V hosts, or on local disk on the Hyper-V hosts for the cluster.
- Configure other virtual machines with a delayed start (after a domain controller boot).
- Disable time synchronization between the virtual domain controller and the host OS.
- Avoid single points of failure. Don’t put all your virtualized domain controllers on one Hyper-V host.
- Make sure you’ve allocated the appropriate performance to the domain controller, especially in very large Active Directories.
- Never, ever, not-ever use snapshots and domain controllers. I’m talking about checkpoints / snapshots (not VSS backups). You will almost certainly encounter serious USN rollback / replication issues if trying to use checkpoints / snapshots. They are not an option. Examples of replication issues can be found here: http://technet.microsoft.com/en-us/library/dd348479(WS.10).aspx
- If P2Ving a domain controller, make sure you do it offline, not online. Use the SCVMM offline P2V option.
- Ensure backups of the Active Directory database continue to occur. A VHD backup is not a replacement for Active Directory backups.
- Do not use the export feature on virtual machines that are configured as domain controllers.
- Do not clone domain controllers that are virtual machines.
Virtualized Domain Controllers Planning Considerations: http://technet.microsoft.com/en-us/library/dd348476(WS.10).aspx
Deployment Considerations: http://technet.microsoft.com/en-us/library/dd348449(WS.10).aspx
Ben Armstrong has a good post on this as well: