The Domain Controller Dilemma

Often I have people ask me about the Domain Controller dilemma.  The basic problem is this: if you decide to virtualize all of your servers, how do you handle the domain controllers which control the domain used by your Hyper-V servers?  There are a couple of options that you can consider here:

  1. Keep the root domain controller on physical hardware

    By keeping the root domain controller on separate physical hardware you can avoid any potential for problems.  However you also miss out on the benefits of virtualization for your domain controller (better hardware utilization, hardware mobility, easier backup, etc…).

  2. Keep the Hyper-V servers out of the domain

    In small deployments you can consider just leaving the Hyper-V servers as part of a workgroup and then running all domain controllers inside virtual machines.  This approach has two problems.  First, you lose the security advantages of running in a domain environment and second, it is hard to have multiple administrators in such an environment (as local user accounts need to be created on each Hyper-V server).  Also, you cannot use all the functionality of SCVMM in such an environment.

  3. Establish a separate (physical) domain for Hyper-V servers

    This approach is a compromise between the first two approaches.  Here you virtualize your primary domain controller environment, but setup a secondary (smaller) domain environment for your Hyper-V servers using a physical server.  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.  The problem with this approach is that you still have an underutilized server sitting around in your server room / data center.

  4. Run the domain controller on top of Hyper-V anyway

    The last option is to just stick the domain controllers in virtual machines and then join the parent Hyper-V environment to the domain in question.  Now, while this sounds like a problematic environment it can be done with some careful planning.  Here are the following steps to take / things to consider:

    1. You should configure the domain controller virtual machines to always start when the parent starts – whether they were running before or not (this is configurable in the virtual machine settings).
    2. If you have other virtual machines configured to start automatically you may want to configure them to have a delayed start time (say by a minute or two) to allow the domain controllers to start up quickly.
    3. You should configure the domain controller virtual machines to shutdown (and not save state) if the physical computer is shutdown.
    4. You should ensure that you have a way of managing the Hyper-V environment if the domain controller fails to start.  This means keeping note of the local administrator account / password and testing that you can use it (either locally or remotely) to access the Hyper-V management console.

So there you have it.  I actually use option 4 for the (albeit small) domain environment that I run in my house and have had no issues.  A couple of extra points to make here:

  • Points 1-3 of option 4 should apply to *any* time that you virtualize a domain controller – even if it is not being used by the parent partition in question.
  • You should never use saved state / snapshots with domain controllers – as this can be catastrophic.