Virtualization platforms, such as Hyper-V, offer a number of convenience features that make managing, maintaining, backing up, and migrating computers easier. However, there are some common deployment practices and features that should not be used for virtual domain controllers. The following list describes the practices to avoid when you deploy domain controllers:

• Do not implement differencing disk virtual hard disks (VHDs) on a virtual machine that you are configuring as a domain controller. This makes it too easy to revert to a previous version, and it also decreases performance. For more information about VHD types, see New Virtual Hard Disk Wizard (http://go.microsoft.com/fwlink/?LinkID=137279).
  
  
• Do not clone the installation of an operating system without using Sysprep.exe because the security identifier (SID) of the computer will not be updated. For more information about running the System Preparation tool (Sysprep), see "Using virtual hard disks" in Ways to deploy an operating system to a virtual machine (http://go.microsoft.com/fwlink/?LinkId=137100).
  
  
• To help prevent a potential update sequence number (USN) rollback situation, do not use copies of a VHD file that represents an already deployed domain controller to deploy additional domain controllers. The next three items in this list are also recommended to help avoid potential USN rollback. For more information about USN rollback, see Appendix A: Virtualized Domain Controllers and Replication Issues.
  
  
• Do not use the Hyper-V Export feature to export a virtual machine that is running a domain controller.
  
  

Warning
Running Sysprep on a domain controller damages the AD DS installation. Use Sysprep before you install the AD DS role to produce a unique security identifier (SID) for that installation.

System Center Virtual Machine Manager (VMM) 2008 provides unified management of physical machines and virtual machines. It also provides the ability to migrate a physical machine to a virtual machine. This process is known as physical-to-virtual machine conversion (P2V conversion). During the P2V conversion process, the new virtual machine and the physical domain controller that is being migrated must not be on at the same time, to avoid a USN rollback situation as described in Appendix A: Virtualized Domain Controllers and Replication Issues.

You should perform P2V conversion using offline mode so that the directory data is consistent when the domain controller is turned back on. The offline mode option is offered and recommended in the Convert Physical Server Wizard. For a description of the difference between online mode and offline mode, see P2V: Converting Physical Computers to Virtual Machines in VMM (http://go.microsoft.com/fwlink/?LinkId=155072). During P2V conversion, the virtual machine should not be connected to the network. The network interface card (NIC) of the virtual machine should be enabled only after the P2V conversion process is complete and verified. At this point, the physical source machine will be off. Do not bring the physical source machine back onto the network again before you reformat the hard disk.

Caution
To prevent issues with Active Directory replication, ensure that only one instance (physical or virtual) of a given domain controller exists on a given network at any point in time.

You can use P2V migration through the VMM to create test environments. You can migrate production domain controllers from physical machines to virtual machines to create a test environment without permanently bringing down the production domain controllers. However, the test environment must be on a different network from the production environment if two instances of the same domain controller are to exist. Great care must be taken in the creation of test environments with P2V migration to avoid USN rollbacks that can affect your test and production environments. The following is a method that you can use for creating test environments with P2V.

One in-production domain controller from each domain is migrated to a test virtual machine using P2V according to the guidelines stated in the Physical-to-virtual migration section. The physical production machines and the test virtual machines must be in different networks when they are brought back online. To avoid USN rollbacks in the test environment, all domain controllers that are to be migrated from physical machines to virtual machines must be taken offline. (You can do this by stopping the ntds service or by restarting the computer in Directory Services Restore Mode (DSRM).) After the domain controllers are offline, no new updates should be introduced to the environment. The computers must remain offline during the P2V migration; none of the computers should be brought back online until all the computers have been fully migrated. To learn more about USN rollback, see Appendix A: Virtualized Domain Controllers and Replication Issues.

Subsequent test domain controllers should be promoted as replicas in the test environment.

For virtual machines that are configured as domain controllers, disable time synchronization with the host through Integration Services. Instead, accept the default Windows Time service (W32time) domain hierarchy time synchronization.

Host time synchronization makes it possible for guest operating systems to synchronize their system clocks with the system clock of the host operating system. Because domain controllers have their own time synchronization mechanism, host time synchronization must be disabled on virtual machines that are configured as domain controllers. If domain controllers synchronize time from their own source and also synchronize time from the host, the domain controller time can change frequently. Because many domain controller tasks are tied to the system time, a jump in the system time could cause lingering objects to be left in the directory and replication to be stopped.

You can disable host time synchronization in the virtual machine settings in the Integration Services section of the Hyper-V Manager by clearing the Time Synchronization check box.

For information about installing and using Integration Services, see the Hyper-V Getting Started Guide (http://go.microsoft.com/fwlink/?LinkId=137146).

To optimize the performance of the domain controller virtual machine, use the following recommendations for storing operating system, Active Directory, and VHD files:

• Guest storage. Store the Active Directory database file (Ntds.dit), log files, and SYSVOL files on a separate virtual disk from the operating system files. Integration Components must be installed so that synthetic drivers can be used for Integrated Drive Electronics (IDE) instead of emulation. Virtual SCSI and IDE disks perform at the same speed when they use synthetic drivers.
  
  
• Host storage of VHD files. Recommendations: Host storage recommendations address storage of VHD files. For maximum performance, do not store VHD files on a disk that is used frequently by other services or applications, such as the system disk on which the host Windows operating system is installed. Store each VHD file on a separate partition from the host operating system and any other VHD files. The ideal configuration is to store each VHD file on a separate physical drive.
  
  
• Fixed VHD versus pass-through disks. There are many ways to configure storage for virtual machines. When VHD files are used, fixed-size VHDs are more efficient than dynamic VHDs because the memory for fixed-size VHDs is allocated when they are created. Pass-through disks, which virtual machines can use to access physical storage media, are even more optimized for performance. Pass-through disks are essentially physical disks or logical unit numbers (LUNs) that are attached to a virtual machine. Pass-through disks do not support the snapshot feature. Therefore, pass-through disks are the preferred hard disk configuration, because the use of snapshots with domain controllers is not recommended.
  
  

To reduce the chance of corruption of Active Directory data, use SCSI controllers or disable write caching on ATA/IDE drives:

• Use SCSI physical drives (as opposed to IDE/ATA drives) on Hyper-V servers that host virtual domain controllers. If you cannot use SCSI drives, ensure that write caching is disabled on the ATA/IDE drives that host virtual domain controllers. For more information, see Event ID 1539 – Database Integrity (http://go.microsoft.com/fwlink/?LinkId=162419).
  
  
• Use virtual SCSI controllers for any virtual machine that runs as a domain controller. If you cannot use virtual SCSI controllers, ensure that write caching is disabled on the virtual IDE drives of virtual machines that run as domain controllers. You can see the type of disk controllers that are installed in the Virtual Machine Manager Settings dialog box. For more information, see Configuring Virtual Machines (http://go.microsoft.com/fwlink/?LinkID=129912).