In Part 1 we extended the forest and domain schema in preparation for the first 2008 R2-based DC, and now in Part 2 we’ll create and fire up the new DC.

The big question was whether to create a virtualized domain controller or not. There are obvious concerns with going down this path in terms of redundancy and reliability, and particularly if the underlying hypervisor is a member of the domain, but after reading this article by Virtual PC Guy Ben Armstrong, I’m quite comfortable in taking this approach. With suitable precautions, of course.

Because the DC is running on Hyper-V, here’s the basic rundown of critical steps to take:


  • Configure the VM to start when the parent starts, regardless of its previous state. This ensures that as long as the parent system is up, so is the VM. Note that this is not the default behaviour for a Hyper-V virtual machine. To change this setting:
    • Right-click on the VM in Hyper-V Manager
    • Select Settings
    • Scroll down the left pane to Management
    • Change “Automatic Start Action” to “Always start this virtual machine automatically”
  • If there are other VMs hosted on the same system, delay their startup. This lets the DC initialise quicker and prevents processes on the other VMs which rely on domain communications from failing. To add a delay:
    • Go to “Automatic Start Action” again and add a startup delay of 120 seconds (this should be sufficient time)
  • Configure the VM to shut down when the parent shuts down, rather than go to a saved state. Because Active Directory relies so strongly on data integrity, pushing a DC into a saved state means that you’re running a massive risk of timestamp corruption and failed disk writes, both of which are seriously bad news for AD. It’s much safer to switch the machine off. To make this change:
    • Right-click on the VM in Hyper-V Manager
    • Select Settings
    • Scroll down the left pane to Management
    • Change “Automatic Stop Action” to “Shut down the guest operating system”
  • Have some method of administering the Hyper-V host if the DC fails for some reason
    • Keep track of local admin accounts
    • Use the Hyper-V Remote Management Configuration Utility (HVRemote) to configure the Hyper-V parent for remote access/management from a non-domain machine (just in case)
  • Finally, if possible have some form of redundancy in the DC infrastructure. If one DC is down, it’s always better to have another one in the wings. This one can be virtual too, and if the underlying hypervisors are on physically different servers, then so much the better

vm_local_storage The other consideration is what resources are needed. A Server 2008 R2 dedicated domain controller which doesn’t do anything else (recommended) will happily bumble along on 1GB RAM and a small amount of drive space. Of course, you can always throw more RAM if necessary. Of greater concern is disk allocation. Again for the sake of redundancy it’s nicer to be able to spread the AD load around, and for that reason I chose to add a couple of 10GB fixed-size VHDs to the system and attach them to the Hyper-V SCSI controller. With the OS I assigned them to drives M:\ and N:\ so that they couldn’t accidentally interact with any other hardware added later. Then during the dcpromo stage of Active Directory configuration, I pointed the NTDS database to M:\ and the NTDS logs to N:\.

Fixed-size VHDs are pretty much mandatory in this environment. Dynamically expanding VHDs don’t give the same performance as fixed-size, and differencing disks aren’t supported for domain controllers – they’re also a bad idea as it creates a potential point of failure. Unless you’re supporting a massive AD environment 10GB VHDs are more than sufficient (probably overkill really) but if you need to expand in the future then VHD Resizer will do the job.

One thing – I had some issues with this particular virtual machine about a week ago, and it turned out to be an dodgy physical network card in the Hyper-V parent. Because this caused no end of problems and eventually resulted in me having to strip out the DC from AD and start again, this time around I was paranoid and took a complete copy of the VHDs before starting the dcpromo. Nothing went wrong, but half an hour spent in creating a roll-back position was worth it.

In the third and last part of this tutorial, with all DCs running Windows Server 2008 R2 we’ll migrate the AD functional level and take a look at some of the new benefits and features.

Read 4sysops without ads by becoming a member!

Your question was not answered? Ask in the forum!

Articles in series

Active Directory Functional Level Server 2008 R2

  1. Ken Curtis 10 years ago

    Good article - The one thing I would add is that on the Hyper-V virtual machine: If one of them is the authoritaive time server for the domain, go into the settings for that virtual machine, choose "Integration services" and disable "time syncronization". If you don't, the Hyper-V host will force the time back to the (wrong) time every time the DC updates it's time from a time server and the time on your domain will not be accurate.


  2. Author
    James Bannan 10 years ago

    Yep, good call - at the moment the DCs don't draw their time from an external source, but that will be the case in future, so I'll definitely make that change.


  3. Bill 10 years ago

    Just found this page; it really sums up the stuff I've learned over the past several days.

    I have a couple of questions:

    1. For the hyper-v host (that's going to host the DC and other VMs), what size partition would you suggest?

    2. About the fixed 10Gb VHD's you created. You say: "I chose to add a couple of 10GB fixed-size VHDs to the system and attach them to the Hyper-V SCSI controller. With the OS I assigned them to drives M:\ and N:\..."
    a. by "system", do you mean you created these from the Hyper-V host, through the Manager? If so, what did you call them?
    b. in which OS did you "assign" them to different drive letters...the hyper-v host? The virtual DC?
    c. what is the Hyper-V SCSI controller? A physical SCSI controller in the physical box that the host is installed on?

    Trying to learn as much as I can...thanks for the article, and I hope you can answer my qusetions!



  4. Bill 10 years ago

    Ok...nevermind question 2..I understand now. 🙂

    2a. yes, from hyper-v host; just called them ad-data.vhd and ad-logs.vhd
    2b. via disk manager in the DC VM
    2c. hyper-v manager, settings for the DC VM, add hardware, SCSI Controller, add HDD, etc, etc.

    Still curious about question 1.



Leave a reply

Your email address will not be published. Required fields are marked *


© 4sysops 2006 - 2020


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account