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 they be deployed on
stand-alone separate servers, should they be kept on separate physical
servers, or should they be run inside virtual machines that are hosted
on servers that are part of the same domain? Why do people struggle to
find a solution to this question? Why is it a dilemma in the first
place? Shouldn't domain controllers be just placed on regular physical
servers, just like you used to do before the advent of virtualization
So, what's the basic problem with domain controllers? Well, to make
it short, it's basically the "What comes first? The egg or the hen?"
dilemma. If you virtualize all of your servers, including the domain
controllers, how do you handle the domain controllers which control the
domain used by your Hyper-V servers? What happens if a host server that
hosts a virtual machine running a DC fails? What will happen if the VM
itself fails? What will assure the continuity of your Active Directory
in cases of a disaster? What's the best approach to virtualizing DCs?
Basically, there are a few options that you can consider:
- 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
- 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
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
- 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
- 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
- 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.