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.

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 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.)

Leave a Reply