Domain Controller Virtualization Options

by Daniel Petri - December 31, 2008

One of the most frequent questions on virtualization forums that deal with server deployments is the question of how should one deploy their Active Directory domain controllers. Should Active Directory domain controllers be deployed on stand-alone separate servers or separate physical servers?

Should domain controllers run inside virtual machines that are hosted on servers that are part of the same domain? Shouldn't domain controllers be just placed on regular physical servers, just like you used to do before the advent of virtualization products?

A few days ago I bumped onto a great blog post written by Ben Armstrong, the Virtual PC Guy. Let me talk a bit about the options listed in his blog post.

The basic problem with domain controllers is the typical, "What comes first? The chicken or the egg?" dilemma. If you virtualize all of your servers, including the domain controllers, then how do you handle the domain controllers that control the domain used by your Hyper-V servers?

There are several different options to consider if a the server hosting a virtual machine that's running the domain controller fails, or if the virtual machine fails itself. The following outlines several different approaches that helps assure the continuity of your Active Directory in the event of a disaster:

    1. Keep the root domain controller on physical hardware. By keeping the root DC on separate physical hardware you can avoid many potential problems.  However you also miss some of the major benefits of virtualization for the server running the domain controller, which are better hardware utilization, hardware mobility, easier backup and so on. Naturally, you will need to treat that DC  as you did up to a few years ago, when ALL the servers used to be separate physical servers.

  • Keep the Hyper-V servers out of the domain, i.e. leave it in a workgroup, and virtualize the DCs – This will mostly work for small deployments where you can consider leaving the Hyper-V servers as part of a workgroup and then running all domain controllers inside virtual machines, just like any other VM.  There are 2 problems in this approach:  First, you lose the security advantages of running Hyper-V servers in a domain environment; and second, when more than a couple of Hyper-V servers need to be managed in this manner, it is hard to have multiple administrators in such an environment.  Another drawback of this approach is that you will not be able to use all the functionality of SCVMM 2008.


  • Establish a separate (physical) domain for Hyper-V servers - This approach is a compromise between the first two approaches. Here you maintain a small domain environment for your Hyper-V servers using a physical server acting as a DC for this domain. Then, running as virtual machines, you deploy the DCs for the main/production domain. The advantage to this approach is that you get all the benefits of having your Hyper-V servers in a domain, but your primary domain environment benefits from being virtualized (better hardware utilization, hardware mobility, easier backup and so on). The problem with this approach is that you still have one or more underutilized server (the DCs for the Hyper-V domain).


  • Run the domain controllers inside Hyper-V – You can take a fourth approach, where you run your domain controllers in virtual machines, and then join the parent Hyper-V environment to the same domain (i.e. the one that is managed by these virtualized DCs). This setup sounds a bit problematic, but it can be accomplished with some careful planning.


In any case, since domain controllers are the most important machines in a Microsoft-based environment, and having failed DCs hanging out there can have adverse effects on many network services, devices and applications, you should really consider carefully planning your setup, just like you would for physical servers. For example, here are some important considerations:

  • If you virtualize your DCs, you should configure the VMs running the domain controllers to always start when the parent starts, no matter what their running state was (this is configurable in the virtual machine settings).
  • If you virtualize your DCs, configure any other virtual machines to start automatically but with a delayed start time to allow the domain controllers to start up prior to the other virtual machines.
  • If you virtualize your DCs, you should configure the domain controller virtual machines to shutdown (and not save state) if the physical computer is shutdown.
  • Plan and test managing of the Hyper-V environment in case all the virtual domain controllers fails to start.
  • You should NEVER use saved state/snapshots with domain controllers, unless there's only one DC.
  • Just like in physical servers, ALWAYS have more than one domain controller.
  • Spread the domain controllers across separate physical machines. There's no point running all DCs on the same Hyper-V host server if it fails for some reason.
  • Disable time synchronization for the domain controllers.  They are supposed to be the source of time in the domain, and you don't want them to take the time from their host, which then takes the time from the domain controller.
  • Make sure you plan, text and implement a good and working System State backup for at least some of your DCs. This is mostly true for Global Catalogs and FSMO Role holders.
  • If you have more than one Hyper-V server hosting virtual machines running domain controller roles, you might want to plan a method of quickly transferring these VMs between the physical Hyper-V hosts. This can be accomplished by using Power Shell scripts or VM management tools such as SCVMM 2008.

Hopefully, this made sense and got you all thinking.

Join The Petri Insider - Weekly IT Tutorial and Tips, Whitepaper and Webinars