The Domain Controller Dilemma

The Domain Controller Dilemma

  • Comments 30

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.

Cheers,
Ben

Leave a Comment
  • Please add 4 and 3 and type the answer here:
  • Post
  • So as I understand your option 4, when the physical server boots up and runs through it's usual windows startup process, it's actually part of a domain where the DC is a virtual machine on the physical server itself?

    Since some windows server startup processes (depending on the server roles installed) involve setting up a secure channel with the DC, they could timeout if the virtual DC hasn't started yet.

    This wouldn't be a problem if a second virtual DC, running on seperate physical hardware, is available at the time.

    But what do you do about spreading the FSMO roles between DC's?

    And how do you ensure that if the virtual DC fails, it fails over to another instance?

  • http://support.microsoft.com/kb/888794

    has more information about running domain controllers in a virtual hosting environment.

  • This is very interesting, but I'm still wondering why I shouldn't just run the DC on the host OS and save myself a server license?

    I'm planning on having 2 Hyper V servers and was just thinking of making them both DC's.

    Could you give me some insight why this wouldn't be recomended or what problems I might encounter!

    Thanks

  • iantownsend

    It doesn't save you a license.

    In server standard, you don't get a guest license if you are also running services on the host.

    Likewise in Enterprise, you have four guests only if you are not running host services.

  • Hi There,

    Great Artical.

    Small Question:-

    Should an Additional Domain Controller be talking to an other Additional Domain Controller? If Yes, WHY? There is already a Primary Controller available. and Should all Additional DC be a Global Cataloge Server? If the ADC are in Different Site?

    Kind Regards,

    Thanks in Advance...

  • Thanks Ben for this valuable information. I have opted for option 4 in my private research lab but have issues around NetLogon throwing event id 5719 as it starts before the DC VM starts. For the sake of completeness, event id 5719 logs the following error:

    !----------------------------------------------------

    This computer was not able to set up a secure session with a domain controller in domain <xxx> due to the following:

    There are currently no logon servers available to service the logon request.

    !----------------------------------------------------

    This leads to a delayed start as you might have guessed as seems to be a known behavior. As an attempt to fix this, I tried to set a dependency on VMMS service for the NetLogon service so that the former starts before the latter. Well the startup order works but still NetLogon is fast enough to start before the DC VM actually is up and running. So here are a couple of questions:

    (1) Is there an elegant way of ordering these services so that NetLogon waits until the DC VM is up?

    (2) If option 4 is a preferred option for small to medium sized environment, then wouldn't it be a good idea for Microsoft to reorder these services (permanently) so that NetLogon respects the presence of HyperV on the box and waits until at least the DC VM is up and running before it could start?

    Awaiting your take...

    Rolf

    P.S.: Both the Hyper-V host and VM are on Windows Server 2008 R2 Eval.

  • For option 4 you should also change the time server hierarchy so that the Hyper-V parents obtain their time from upstream NTP servers and not the domain hierarchy. The virtualised domain controllers should then use the Hyper-V hosts as their upstream NTP servers, along with disabling time sync in the domain controller's VM settings. Alternatively the time service configuration can be left alone in the domain controller VMs and the time sync enabled for the VMs.

  • I think you miss one. 5. Using the Hyper-V host as Domain Controller?

  • I am having the following problem. We have our Primary AD server hosted AD server offsite, with our backup AD server locally being replicated from the hosted primary. We had a company virtualize our physical backup AD server. We are having some problems adding PC's to the domain. Have to do it manually, sometimes several atttempts. Also a few IP conflict issues, nothing major. Should we promote the virtualized server and then demote back? There seems to be identification issues.

  • Hello All,

    Point 4 is perfect , but was just hoping if any one could elaborate one section d of point 4.

    I have tried in my lab , i have a Hyper V CORE server running few virtual machines including a DC (only DC) . Now for some reason DC VM fails to start. In this scenario , i wont be able to manage my Hyper V. RSAT tools or Server Manager will throw a error saying "RPC Server unavailable" . Thats pretty much obvious , considering the DC is down. But then how do i manage my Core machine hyper v from a different server ?

    yeah i do use powershell script to start the DC , in case its turned off , but is there any other way ?

    Why is Core server so dependent on the DC , that it wont let me even connect remotely to manager my hyper v

  • Nice post Ben, very helpful.

    Can you please suggest the best practice in following scenario on Server 2012 HyperV

    2 Host Servers are with 8 Core Cpu,, 128 GB RAM, 4x 1GB Port and 4 x10G Ports with VNXE SAN. Need to configure 4 VMs on each server with Replice and live migration.   We are planning domain controller on Virtual Machines (DC1 and DC2) on each host with exchange 2010 .  Plz advise

    1 Do we keep a third DC on physical host? it will need additional license in that case. ?

    2. If we not Join the Host Server on Domain then how live migration and replica will work ?

    Any other advise you may have

    Thanks

    Nitin

  • did your server type is datacenter or enterprices?

  • Hi Ben,

    It's a great article/tips.

    I was planning to install Solarwinds on Windows 2008 R2 Std - 64bit domain controller (physical server) however solarwinds strongly recommends not to install this software (Solarwinds NPM for network device monitoring) on a DC hence thought of configuring Hyper-V on a DC and install 2008 R2 Std edition as a virtual machine and then install Solarwinds software. Is this recommended? or will there be any security flaws? Any suggestion or idea on this would be highly appreciated.

  • I am experimenting with option 4 on Server 2012 R2 but it seems that the Hyper-V Host fails to join the domain sometimes - maybe times out because the DC VM (the only VM) has not started yet or maybe decides to fall back to local cached credentials? So the firewall settings show me that the computer is connected to a public network instead of the domain network. Remote desktop is also impossible for this reason. If I deactivate and reactivate the connection it recognizes the domain network fine but this must be done manually.

  • Any update to these recommendations since Hyper-V 2012 R2 has come out?

Page 2 of 2 (30 items) 12