Virtualized domain controllers can have the following advantages:

• Consolidation. You can consolidate multiple domain controllers with other application servers onto comparatively fewer servers with Hyper-V. If you have multiple domain controllers in a hub site serving a small domain that has a presence in one or more other sites, you do not have to deploy multiple physical domain controllers to provide for bridgehead servers and redundancy support.
  
  
• Testing. Because testing environments rarely require high-performance domain controllers, you can set up a test configuration that represents your production environment using much less hardware than was required before virtualization technology was available. You can represent dozens of domain controllers on a few physical computers that have the same Active Directory configuration (including domains and sites) as your production domain controllers. You can test complex changes, such as schema changes or large-scale Active Directory site or replication changes, before you make these changes in your production environment.
  
  
• Deployment. The hardware environment that Hyper-V emulates remains unchanged throughout the life of a virtual machine, regardless of the underlying native hardware to which you might transfer the virtual machine. Therefore, you can vary server hardware in a preproduction environment to build and test the images even though the intended production server may be significantly different.
  
  
• Performance. If you follow all the performance recommendations in the topics in this guide, you can expect a decrease in performance of only 2 percent to 12 percent on a single domain controller that is running in a virtual machine under heavy load compared to one domain controller that is running on native hardware with the same specifications.
  
  

This guide contains important information about the risks of running domain controller virtual machines in a production environment. Virtual hard disk (VHD) files can be easily used and—potentially—easily misused, which is why it is important to manage them carefully when you deploy them in a production environment. When you consider whether to run domain controllers in virtual machines, remember that mishandling VHD image files can result in forest-wide corruption. Mishandling a VHD file could be as easy as starting an older copy of a VHD file or copying a VHD file to a different place on the network and running multiple copies at the same time.

Virtualized domain controllers can have the following disadvantages:

• Administration. In a production environment, data corruption that affects the entire forest can result from deliberate or inadvertent misuse of VHD files. In most cases, improper restore conditions are detected by the operating system and replication is stopped. However, this cannot guarantee the protection of data under all circumstances. To protect your forest against the effects of improperly restoring a domain controller that is running in a virtual machine, make sure that all the administrators in your organization review the information in Appendix A: Virtualized Domain Controllers and Replication Issues.
  
  
• Security and handling of image files. Anyone who handles VHD files or has other access to VHD files must be highly trusted in the organization and a member of trusted security groups in the forest. Any user who has the ability to copy a VHD file effectively owns the forest and its data. An attacker or unauthorized administrator could use a copied virtual machine file to compromise passwords or corrupt the forest. Also, unlike the theft of a physical computer, theft of a VHD file is more likely to go undetected. Therefore, you should secure the VHD files for the host operating system and the guest operating system with the same physical restrictions and software restrictions that you use to secure a physical domain controller. These restrictions include controlling access to the files and auditing file access as discussed in “Security considerations” later in this topic.
  
  

Using virtual machines makes it possible to have many different configurations of domain controllers. Careful consideration must be given to the way that virtual machines affect boundaries and trusts in your Active Directory topology. Possible configurations for an Active Directory domain controller and host (Hyper-V server) and its guest computers (virtual machines running on the Hyper-V server) are described in the following table.

Configuration 1 is the recommended configuration of domain controllers when you use Hyper-V. In this configuration, the following items must be taken into consideration:

• The administrator on the host computer has the same access as a domain administrator on the writable domain controller guests and must be treated as such. In the case of an RODC guest, the administrator of the host computer has the same access as a local administrator on the guest RODC.
  
  
• A domain controller in a virtual machine has administrative rights on the host if the host is joined to the same domain. There is an opportunity for a malicious user to compromise all virtual machines if the malicious user first gains access to Virtual Machine 1. This is known as an attack vector. If there are domain controllers for multiple domains or forests, these domains should have centralized administration in which the administrator of one domain is trusted on all domains.
  
  
• The opportunity for attack from Virtual Machine 1 exists even if Virtual Machine 1 is installed as an RODC. Although an administrator of an RODC does not explicitly have domain administrator rights, the RODC can be used to send policies to the host computer. These policies might include startup scripts. If this operation is successful, the host computer can be compromised, and it can then be used to compromise the other virtual machines on the host computer.
  
  

In Configuration 2, the host computer is a domain controller with the Hyper-V role enabled. However, if Active Directory Domain Services (AD DS) is configured to use constrained delegation, Service Principle Names (SPNs) will not be automatically created for virtual machines (that is, for non-domain-controller virtual machines. Therefore, these SPNs must be created manually. To add SPNs for the constrained delegation, complete the following procedure.

On the domain controller that is running Hyper-V and for which you want to configure constrained delegation, perform the following procedure.

1. Open an elevated Command Prompt window. To open an elevated Command Prompt window, click Start. In Start Search, type Command Prompt. In the Start menu, right-click Command Prompt, and then click Run as administrator.

2. At the command prompt, type the following commands, and then press ENTER:

   SETSPN -A Microsoft Virtual Console Service/<NetBIOS name> <NetBIOS name>

   SETSPN -A Microsoft Virtual Console Service/<FQDN> <NetBIOS name>

   In these SETSPN commands, type the NetBIOS computer name of the domain controller (for example, SERVER1) for <NetBIOS name>. For <FQDN> type the fully qualified domain name (FQDN) of the domain controller (for example, server1.corp.contoso.com).

Note
As a result of the way that Setspn.exe processes information, you must type the NetBIOS name twice, separated by a space, where indicated.

For more information about constrained delegation, see Kerberos Protocol Transition and Constrained Delegation (http://go.microsoft.com/fwlink/?LinkId=137041).

In configuration 3, both host and guests are domain controllers. This configuration does not raise any security issues as long as all domain controllers are from the same forest. In this case, a user who is logged on to the Hyper-V server (host) should be considered to have default domain-administrator-level permissions in the domains of the virtual domain controllers (guests).

Security of VHD files

One benefit of RODCs is the ability to place them at locations where physical security cannot be guaranteed, such as at branch offices. In this case, more effort must be made to mitigate the effects of an attack. You can use Windows® BitLocker™ Drive Encryption to protect VHD files from being compromised on the host through theft of the physical disk. For more information about BitLocker in Hyper-V, see Windows Server 2008 Hyper-V and BitLocker Drive Encryption (http://go.microsoft.com/fwlink/?LinkID=123534).

Domain controllers that hold most operations master (also known as flexible single master operations or FSMO) roles do not have significantly more load than other domain controllers. Therefore, they do not need special consideration for virtualization. Bridgehead servers do not need special consideration in terms of performance.

The one exception is the primary domain controller (PDC) emulator operations master role, which in general has higher processor load than other operations master roles. As a result, you may decide to use a physical computer to host the PDC emulator role to improve performance.

Domain controllers that are configured as global catalog servers, which typically provide directory services for servers running Microsoft Exchange Server, may experience performance loads that are greater than the other domain controllers in your network. For example, when Exchange servers expand distribution lists, they can place a significant load on the domain controllers that provide global catalog services. For performance reasons, consider using physical servers instead of virtual machines for those global catalog servers that provide directory services to Exchange servers.

Note
For additional information regarding AD DS in virtual hosting environments, see article 888794 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=141292).