Active Directory in Hyper-V environments, Part 1

This entry is part 1 of 10 in the series Active Directory in Hyper-V environments

Virtualization offers huge benefits in flexibility, cost-effectiveness and eco-friendliness. However, some design choices need to be made towards deploying Active Directory Domain Controllers in virtual environments. Some of these choices are general choices, but some of them apply to Hyper-V enabled environments specifically.

When deploying an Active Directory environment, either for test or production purposes, either virtual or physical, be sure to deploy at least two Domain Controllers per Active Directory domain, whenever possible. When either Domain Controller fails you don’t lose your Active Directory information and any applications, services and users depending on it can continue to operate, unless specifically pointed to.


To virtualize or not

You could opt to deploy both Domain Controllers as virtual machines. Other choices would be to deploy one or both Domain Controllers as non-virtualized machines.

When you deploy your Domain Controllers in virtualization software not validated in the Windows Server Virtualization Validation Program you may be forced to recreate your Domain Controllers as non-virtualized machines when you need to troubleshoot problems with the assistance of Microsoft Product Support Services (PSS) and don’t have a Premier-level support agreement.


Single points of failure

When you place one Domain Controller on one Virtual Host and place the other Domain Controller on another Virtual Host you rule out the Single Point of Failure (SPoF) that is apparent when you use a single Virtual Host, It won’t protect you against failures in the virtualization platform though.

Failures of the virtualization platform

When you deploy all your Domain Controllers virtually you place your faith in your virtualization software vendor: When your virtualization vendor screws up (example here) you won’t have any available Domain Controller, since all your Domain Controllers resided inside your virtualized environment.

Scheduled outages

With two hosts or Hyper-V fail-over clustering you can update and restart one Virtual Host while the other host still offers a virtualized Domain Controller. This protects against misconfigurations and defects to one of the hosts, but it won’t help you against scheduled outages and wide power failures though. The latter may be circumvented by investing in long-term uninterruptible power solutions, (mostly diesel-powered) but this isn’t an option for everyone.


Parent partition as DC

In scenarios with Windows based Virtual Hosts you can opt to make your Virtual Host (in Hyper-V terms: your Parent Partition) an Active Directory Domain Controller as well.

Architectural point of view

From on architectural point of view this is not a desired configuration. From this point of view you want to separate the virtualization and platforms from the services and applications. This way you’re not bound to a virtualization product, a platform, certain services or applications. Microsoft’s high horse from an architectural point of view is the One Server, One Server Role thought, in which one server role per server platform gets deployed. No need for a WINS server anymore? Simply shut it down…

The Windows Server 2008 Enterprise Edition SKU allows you to deploy unlimited virtual Windows Server 2008 machines per physical processor, which makes it ideally suitable for these scenarios.

Performance point of view

From a performance point of view it doesn’t matter whether you install your Domain Controller in the Hyper-V parent partition or in a Hyper-V child partition, since virtualization is about effectively using processor power and RAM.

Creating the Domain Controller as a Virtual Guest (“child partition”) on the other hand allows you to edit the RAM and Disk settings when your environment changes and gives you more flexibility.



In a Hyper-V environment I recommend placing one Domain Controller per domain outside of your virtualized platform and making this Domain Controller a Global Catalog. (especially in environments with Microsoft Exchange)

Microsoft recommends you locate critical server roles on domain controllers that are installed directly on physical hardware. These include Global Catalog servers, Domain Name System (DNS) servers, Flexible Single Master Operations (FSMO) roles and replication bridgeheads

The normal Best practices for securing access to Domain Controllers applies to both these systems. (VHD files of running Domain Controllers need to be secured as well as physically running Domain Controllers.)

Be sure that only reliable and trusted administrators are allowed access to the Domain Controller VHD files. Create a folder for storing all virtual machine domain controller files  and assign permissions to the folder that contains the files so that only domain administrators  and the service account for your Virtualization software have access to the folder. Audit Read\Write access to the folder and monitor the security logs for unauthorized access attempts.

Server Core installations of Windows Server 2008 are perfect candidates for these Domain Controllers, since they don’t require much resources and offer native console security since most of the graphical user interface isn’t available.

You might opt to reuse abandoned hardware without support from the hardware vendor for this purpose. Alternatively you can use a different virtualization platform when you need a lot of Domain Controllers.


Related DirTeam posts

Installing Server Core Domain Controllers

Further reading

Active Directory Best practices: Active Directory
Best Practice Active Directory Design for Managing Windows Networks 
Support policy for Microsoft software running in non-Microsoft virtualization software
Download details: Running Domain Controllers in Virtual Server 2005
Download details: Hyper-V Planning and Deployment Guide
Considerations when hosting Active Directory domain controllers in virtual environments
Running a Domain Controller as a Virtual Machine
Is domain controller virtualization really a good idea?
Halfbaked ideas: A virtual domain controller
Virtualisation, Time Sync & Domain Controllers
Domain controller virtualization
Microsoft TechNet Forums: Domain Controller in Hyper-V and std core…
Microsoft TechNet Forums: Hyper-V Blue Screens the host OS (Beta 1 timeframe)
Microsoft TechNet Forums: Connecting Host to AD running in Hyper-V
Microsoft TechNet Forums: Hyper-v as DC Forums: Run domain controller as a guest OS or host?

Series NavigationActive Directory in Hyper-V environments, Part 2 >>

5 Responses to Active Directory in Hyper-V environments, Part 1


    Hi Sander,
    the issue of disaster recovey a virtualized domain controller has an important consequence. As you probably know, only one restore from the VHD file is not enough.

    SBL – Steffen Brendler


    Hi Steffen,
    Thank you for your reply.

    In part 2 of this series I will look at virtual Domain Controllers do’s and don’ts. Correctly backing up and restoring virtual Active Directory Domain Controllers is part of it of course.


    Hi Sander,

    Great series!

    In part one, the note about non-Microsoft virtualization platforms should probably be updated to refer to non-SVVP products.

    Christoph Wegener


    Thanks for the heads up, Christoph!

    I’m always pleased when readers and co-bloggers have meaningful additions to my posts.

    I’ve updated the post to reflect the changes to this policy from Microsoft Knowledgebase article 897615. (released two weeks after this blogpost was posted)


    Microsoft has published guidance on this topic at

leave your comment