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.

   

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

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.

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.

     

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.

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.

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)

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

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.

#################################################################
 

Domain Controllers are perfect virtualization targets, but virtualizing a Domain Controller reintroduces possibilities to mess up the Domain Controller in ways most of the Directory Services Most Valuable Professionals (MVPs) and other Active Directory enthusiasts have been fixing since the dawn of Active Directory.
When working with virtual Active Directory Domain Controllers be sure to:
     

Apply minimum patchlevels to virtual Domain Controllers

When deploying Active Directory Domain Controllers as Hyper-V Child Partitions be sure they have at least the following patchlevel:

Operating System	Service Pack level	Additional hotfixes
Windows 2000 Server	Service Pack 4	KB885875
Windows Server 2003	Service Pack 2	KB875495
Windows Server 2008	Service Pack 1 *	- none -

* included in Windows Server 2008 RTM.
     

Install the Integration components

Meeting the Service Pack level requirement allows you to install the Operating System as a Child Partition in Hyper-V and install the Hyper-V  RTM Integration Components (ICs).
The purpose of these Integration Components is to enlighten the virtual guests and to provide drivers and services. Enlightened virtual guests know they are virtual machines and are therefor able to interoperate with the virtual host. Integration Components are also sets of drivers and services that help your Virtual Machines have more consistent state and perform better by enabling the guest to use the synthetic devices offered by the virtual host.
   

Provide adequate Time Synchronization

In virtualization products like Virtual PC, Virtual Server, VMWare ESX, VMWare server and of course in Hyper-V these Integration Components offer time synchronization. For Active Directory Domain Controllers having the correct time is essential. Please note the default behaviors of time synchronization for virtual Domain Controllers:

• Within an Active Directory domain environment time gets synchronized with the Domain Controller holding the Primary Domain Controller (PDC) Flexible Single Master Operations (FSMO) role.
    
• With the Integration components installed, a child partition (or "Virtual Guest" will synchronize time with the parent partition (or "Virtual Host").

When your Domain Controllers both synchronize time with the virtual host and the Internet you might find time fluctuates within the Domain when either one of the below situations is true:

1. the virtual host is not a member of the domain
2. the virtual host doesn't synchronize time with the Internet itself.

In these cases it is best not to have your virtual Domain Controller synchronize time with the virtual host. In this case turn off the Time Synchronization capability in the Settings for your virtual Domain Controller and provide proper synchronization with an external source. Jorge has a good blogpost on configuring the PDC FSMO in the forest root domain to sync time.
   

Never save state or pause a Domain Controller

Always shut down virtual Domain Controllers properly to avoid replication errors. Pausing a Domain Controller for a long period of time before resuming it can interfere with timely replication. If you do pause the domain controller for a long time, replication may stop and cause lingering objects. Jorge wrote a great post how lingering objects come to life and how the Service pack level affects the tombstone lifetime.
   

Don't use undo disks, differencing disks or snapshots

Microsoft Virtual Server 2005 R2 differencing and undo virtual hard disks (VHDs) could be used to to create hierarchies of virtual machines with incremental configuration variations and rollback capabilities. The new Hyper-V snapshot feature allows to capture the configuration and state of a virtual machine at any particular point in time.
These sets of functionality can be disastrous when used with virtual Domain Controllers. Microsoft recommends not using them, since they can result in loss of Active Directory information when the link between the original disk and the new information gets lost. Undoing changes on a Domain Controller may result in the same consequences. (More on this in the next section on backing up and restoring Domain Controller the right way)
   

Backup and restore Domain Controllers the right way

Only use the standard way to backup and restore Active Directory Domain Controller, since the default checks of Active Directory consistency will only be performed when the Domain Controller is aware of a restore.
Using imaging solutions like Symantec Ghost and Acronis TrueImage seem like smarter backup and restore solutions, but they are imaging solutions (in contrast to proper backup and restore solutions.) Restoring an image of a Domain Controller may cause an Update Sequence Numbers (USN) rollback situation to occur, which may lead to replication problems and other undesired effects. More information here.
Like shutting down a virtual Domain Controller and start up a version of the VHD file from a while back, you want to avoid improperly using imaging solutions.
To avoid USN Rollback and Invocation ID problems but still using imaging solutions or even copying back old versions of a VHD file (big No-no), be sure to check out Jorge's post on backing up and restoring Active Directory in this unsupported manner.
   

Use Fixed-Sized VHDs

Choose to configure fixed-size virtual hard disks as opposed to dynamically expanding. Performance of fixed-sized VHDs is faster and the file system is less likely to fragment. Before placing a VHD on a physical disk it is advisable to defragment the physical disk before creating a virtual hard disk.
    

Use different disks for Active Directory files

To help preserve the integrity of the Active Directory database if a power loss or another failure were to occur, the Active Directory directory service performs unbuffered writes and tries to disable the disk write cache on volumes hosting the Active Directory database and log files.
While integrity is far superior to performance you can radically increase the performance of a virtual Domain Controller by adding (SCSI-based) virtual hard disks (VHD files) to it and placing the Active Directory database, Active Directory logs and Active Directory System volume (SYSVOL) on these VHD files.
  

Use Sysprep instead of NewSID

Especially in VMWare environments I see an abundance of Windows SysInternals' NewSID.exe usage to change names and Security Identifier (SID) on virtual Windows templates. While I agree NewSID is extremely useful it's not a Microsoft supported way to change the SID. When making a virtual template be sure to use Sysprep.
     

Concluding

When working with virtual Active Directory Domain Controllers be sure to:

• Apply minimum patchlevels to virtual Domain Controllers
• Install the Integration components on virtual Domain Controllers
• Provide adequate Time Synchronization to the Domain Controller holding the Primary Domain Controller (PDC) Flexible Single Master Operations (FSMO) role
• Never save state or pause a virtual Domain Controller
• Don't use undo disks, differencing disks or snapshots with virtual Domain Controllers
• Backup and restore Domain Controllers the right way
• Use Fixed-Sized VHDs for your virtual Domain Controllers
• Use different disks than your system disk for storing Active Directory files
• Use Sysprep instead of NewSID for your virtual templates

I hope it's clear by the end of this post not to reuse an old version of the virtual Domain Controller's VHD file or an old image, produced with an imaging solution.

#################################################################

Designing and implementing a virtual environment on top of Hyper-V can be challenging. Placement of Active Directory Domain Controllers require additional consideration, especially in some Hyper-V scenario's where Active Directory membership is strictly needed.
In the scenarios below the Hyper-V parent partitions ("Virtual Hosts") need to have Active Directory membership:

• Clustering When you want to build a Hyper-V Failover cluster you will need to make your Hyper-V parent partitions (the "Virtual Hosts") members of an Active Directory domain. It isn't a good idea to make the parent partitions Active Directory Domain Controllers. The Domain Controller role isn't designed to be clustered. 
  
• System Center Virtual Machine Manager When you want to use System Center Virtual Machine Manager 2008 (SCVMM 2008) with Hyper-V you need to make your parent partitions member of an Active Directory domain. The System Center Virtual Machine Manager 2008 FAQ is pretty clear about that.
  
• Delegation in large Hyper-V environments Hyper-V uses an authorization model which is based on Windows Authorization Manager (AzMan). AzMan provides a flexible framework for integrating role-based access control into applications. It enables administrators who use those applications to provide access through assigned user roles that relate to job functions.
  Authorization Manager applications store authorization policy in the form of authorization stores that are stored in Active Directory Domain Services (AD DS), Active Directory Lightweight Directory Services (AD LDS), XML files, or SQL databases. In large Hyper-V environments Active Directory is the store to hang out with.
  

    
While in other scenarios Active Directory membership is not strictly needed you might find Active Directory membership for the Hyper-V parent partitions useful. Through Active Directory Group Policy Objects (GPOs) you will be able to manage loads of Hyper-V servers more easily than you would in a workgroup environment.


 #################################################################

Hyper-V in Windows Server 2008 Enterprise and Datacenter Edition offers the ability to make virtual machines highly available by leveraging failover clustering. This however is not a good idea in the case of Active Directory Domain Controllers.
In this post I’ll explain why Hyper-V High Availability for Domain Controllers is not a good idea and how to make Active Directory Domain Controllers highly available in a much easier, more cost effective way.
   

How Hyper-V High Availability works

When combining the Hyper-V Server Role with the Failover Clustering role in Windows Server 2008 you effectively create a High Available solution for virtual machines, stored on shared storage.
In it’s easiest (and most common) form two cluster nodes (“virtual hosts”), installed with Windows Server 2008 (Enterprise or Datacenter Edition), the Hyper-V Server Role and the Failover Clustering Server Role are attached to a shared storage device, where the files for a virtual machine (“virtual guest”) are stored.
One of the cluster nodes (“virtual host”) is the active node and runs the virtual machine (“virtual guest”). The other cluster node (“virtual host”) is the passive node. Both cluster nodes communicate through a heartbeat. That way the passive node can detect when the active node fails and become the active node. This is called a ‘failover’. The failover action can also be triggered manually.

The failover process

When a failover occurs behind the scenes the following actions occur:

1. The virtual machine (“virtual guest”) is paused on the active node.
   The memory is written to *.vsv  and *.bin files in the process.
       
2. The ownership of the shared storage volume on which the virtual machines files are stored, is transferred from the active node to the passive node. The active node loses its ability to access the files for the virtual machine (“virtual guest”) and effectively becomes the passive node. The former passive node gains control of the shared storage volume and can now access the NTFS file system on the shared storage device.
       
3. The virtual machine (“virtual guest”) is resumed on the former passive node.

Another word for this behavior is called ‘Quick Migration’. The downtime for the virtual machine (“virtual guest”) depends on the amount of RAM assigned to the virtual machine (“virtual guest”).
    

Domain Controller High Availability

Doing it wrong…

The keyword above in light of Active Directory Domain Controller High Availability is paused. As you might remember from Active Directory in Hyper-V environments, Part 2 I gave the advice to:

Never save state or pause a Domain Controller Always shut down virtual Domain Controllers properly to avoid replication errors.

When you start a Domain Controller, that is in a paused state it will take some time to regain accurate time. When the Domain Controller replicates without accurate time, replication errors occur.

Doing it right!

Within Windows Server 2008 Failover clustering you have granular control over the high availibility settings of each of the virtual machines (“virtual guests”) on each of the cluster nodes. You can choose whether to make a virtual machine highly available on a per virtual machine basis.
Choose not to make an Active Directory Domain Controller virtual machine (“virtual guest”) highly available using failover clustering. Instead deploy Active Directory Domain Controller virtual machines on at least two nodes. For this you don’t necessarily need shared storage.
This is consistent with best practices for physical deployments of Active Directory Domain Controllers: Active Directory uses a scale-out model.
   

Concluding

When you make Domain Controller virtual machines highly available using Hyper-V Failover Clustering in Windows Server 2008 you risk replication errors. Instead deploy multiple Domain Controller virtual machines and rely on the Active Directory model, like you would in a physical world. (Flexible Single Master Operations roles can be seized in case of emergency.)
Hyper-V R2, available in the Windows Server 2008 R2 timeframe will offer high availability without pausing and resuming virtual machines. (among other improvements)

 #################################################################


Designing and implementing a virtual environment on top of Hyper-V can be challenging. In the first four parts of this series I looked at the design choices and management actions regarding Active Directory in Hyper-V environments. Jorge made some interesting points as well, but one Active Directory best practice still remains to be tackled:

Physically secure all domain controllers in a locked room.

In this part I’ll look into the possible ways of securing virtual Domain Controllers running on top of Hyper-V, besides the apparent open doors written by John Gilham:

1. Using NTFS rights and auditing on the virtual host
2. Using Encryption File System (EFS) on the virtual host
3. Using BitLocker Drive Encryption
4. Using syskey.exe

     

NTFS rights

To secure files on a server one would normally look at NTFS rights. For Hyper-V security the same approach is valid, but one should know which accounts to give access to what data.
Let’s first look at the data. Two pieces of information define virtual machines on a Hyper-V virtual host:

• Configuration Information This information contains the rights management within the Hyper-V Manager and contains information on each virtual machine. The files in this location are small. The configuration files are typically stored in:
      
       C:\Program Files\Microsoft\Windows\Hyper-V
     
• VM configuration and hard disks Virtual hard disks contain the information stored on the hard disks within the virtual machine. Snapshots are virtual hard disks that are used as differencing disks when  you use the snapshot functionality in Hyper-V. Virtual hard disks and snapshots are stored in the same folder. These are big files. This folder is typically located at:
      
       C:\Users\Public\Documents\Hyper-V\Virtual Hard Disks

  
As a security measure you should move the default location where the above information is stored to another location. This can be done in the Hyper-V Management Microsoft Management Console (MMC).
In a Hyper-V environment the following accounts should be given access to the above locations:

Location	Account	NTFS Rights
Configuration location	Administrators SYSTEM	Full Control (This folder, subfolders, and files) Full Control (This folder, subfolders, and files)
VM Hard disks location	Administrators SYSTEM CREATOR OWNER	Full Control (This folder, subfolders, and files) Full Control (This folder, subfolders, and files) Full Control (Subfolders and files only)

All other accounts should be given as limited NTFS rights as possible.
The above NTFS rights of course need to be audited. For this use the following high level steps:

1. Log in as an administrator on the hyper-V virtual host.
2. Right click on the location where either the Hyper-V configuration information or the VM hard disks are stored and right-click the folder. Select Properties.
3. Click the Security tab, and then click the Advanced button.
4. Click the Auditing tab.
5. Click the Add button to make the Select User, Computer, or Group dialog box display. Add the administrators group and SYSTEM account.
6. The Auditing Entry dialog box displays. Specify the type of access you want to audit using this dialog box. Next to the access right, select Failed, and then click OK.
7. Click OK to close the Properties dialog box

Also, be sure to check your auditing settings afterwards…
      

Encryption File System (EFS)

Back in the Virtual Server 2005 days Microsoft advised to use the Encryption File System (EFS) to secure virtual hard disks on the disk of the virtual host. While this meant the performance of the virtual machine would diminish with roughly 5%, it was a good security measure. This practice was dropped by Microsoft for Hyper-V, quoting Mert Biyiklis blog:

Microsoft specifically advices not to use Encryption File System (EFS) with Hyper-V.

Hyper-V does not support the use of storage media if EFS has been used to encrypt virtual hard disks. More information can be found here.
       

BitLocker Drive Encryption

BitLocker Drive Encryption can be used to encrypt the contents of the entire hard disk of a Windows installation, except certain boot files, stored on a dedicated boot partition. This feature is currently available in some versions of Windows Vista and Windows 7 and of course in Windows Server 2008 and Windows Server 2008 R2.
BitLocker is an excellent method to encrypt virtual machines, but only from the virtual host itself. Quoting the Hyper-V security guide:

Use BitLocker Drive Encryption in the Hyper-V management operating system only. Do not run BitLocker Drive Encryption within a virtual machine. BitLocker Drive Encryption is not supported within virtual machines.

To enable BitLocker Drive Encryption on a virtual host, make sure to read the post by Jesper Johansson on enabling BitLocker on an existing computer. It involves creating a separate primary partition, making it bootable, booting from it and then turning encryption on. Once you’ve succesfully encrypted your system drive, you can encrypt any other partitions or volumes on which you’ve stored your configuration information and/or virtual hard disk files.
A further note should also be picked up from Microsoft Knowledgebase article 947302 regarding using BitLocker Drive Encryption in Failover Clustering scenarios:

Volumes that are encrypted by BitLocker are not supported in a clustered environment in Windows Server 2008.

This means you can’t encrypt volumes, containing highly available virtual hard disks in a Hyper-V Failover clustered environment…
     

Syskey.exe

The System Key Utility (syskey.exe) is used in old skool (non-virtualized) situations to secure account data on disk. On non-Domain Controllers the passwords in the Security Account Management (SAM) database are further encrypted. On Domain Controllers the passwords in Active Directory data are further encrypted, using stronger encryption algorithms beyond the default algorithms.
Syskey uses an encryption key. This key can either:

• be stored on disk (server generated, default)
• be a system boot password (configured by the administrator)
• be stored on a floppy and needed at boot time (server generated)

Inside the Virtual Domain Controller

Using one of the first two options inside your virtual Domain Controllers results in a situation that isn’t really useable from a security point of view. Remote Server Management and automated Patch Management will need extra procedures, where an admin on a remote location might need to have the password or floppy to reboot the machine when needed.

Syskey on disk

When using the System Key Utility (syskey.exe) with a server generated password on a virtualized Domain Controller disk it becomes harder to retrieve passwords from the Active Directory, when it’s turned off. However, the virtual disk can be taken from a virtual host and brought online on any other Hyper-V environment. One of the most commonly used attack vectors can’t be stopped using this System Key Utility scenario.

Syskey floppy

Hyper-V can’t work with hardware floppies, so the floppy needs to be virtualized and optionally inserted. A virtual floppy can be used, but needs to be stored on the virtual host and needs to be inserted using the Hyper-V Manager. Both require an administrative role being given to someone you might not want to give it to. Storing it besides the virtual hard disk then again is simply security by obscurity.

Syskey password

A boot password is a good security measure, when implemented correctly. Since a virtual Domain Controller can present its password screen at boot time, only procedures needs to be in order to facilitate remote server management and patch management.

The challenge using the System Key Utility (syskey.exe) inside your virtual Domain Controller is now evident. When used properly it can add an additional layer of security. If used improperly it results in hassle and weaknesses.

On the virtual host

Using the System Key Utility (syskey.exe) inside your virtual host doesn’t offer the multitude of options.

Syskey floppy

The floppy drive option requires an administrator at a remote location to have the floppy or leaving the floppy in the virtual host itself.

Syskey password

The boot password requires an administrator at a remote location to know the boot password. Unless you’re using advanced remoting hardware and software like iLO, DRAC, etc you won’t be able to remotely access the boot screen. Adding another person to your inner circle of trust most often results in scenarios you’d want to avoid with these kinds of persons.

Syskey on disk

The server generated password on disk is something you could implement, though. The scenario doesn’t require local access to the virtual host(s), while adding at least a layer of defense against network attacks.

     

Concluding

It should be imperative you should not let unauthorized, incapable and unknown persons anywhere near your domain controllers. Implementing this best practice in a Hyper-V environment though isn’t as easy as it seems.
To secure Active Directory Domain Controllers in a Hyper-V environment, use the following techniques:

Security Measure	Virtual Host	Virtual Guest (Domain Controller)
NTFS rights and auditing	Yes	Built-in*
Encryption File System (EFS)	No	No
BitLocker Drive Encryption	Yes (Unless clustered)	No
System Key Utility (syskey.exe)	Yes (Disk based)	Yes (Disk, password based)

*  A default installation of Active Directory on a Windows Server further restricts user rights
   on the file system and the registry, compared to a default Windows Server installation.


Virtualization offers huge benefits in flexibility, cost-effectiveness and eco-friendliness. It’s an easy business case to make to any IT department nowadays. After all, Gartner claims the cost of energy outweighs the initial purchase of an x86 server in its first three years. However, most virtualization projects aren’t legacy-free: To make a virtualization business case stick, often the choice is made to virtualize existing (physical) servers to virtual machines. 
Domain Controllers are no exception to the practice of virtualizing existing servers. While I still recommend to maintain at least one Domain Controller as a physical box for obvious reasons, you can run virtualized Domain Controllers.  

The smart thing to do?

Whether this is a smart thing to is a big question. When you haven’t been misusing your Active Directory Domain Controllers for anything else but DNS, it might be quicker to create additional virtual Domain Controllers for your Active Directory domains. An additional benefit might be to to transition your Active Directory to a new Windows platform in the process.
When, however, your Active Directory Domain Controllers are also Exchange Servers (not smart!) or perhaps entangled in some weird and difficult to understand authentication scheme, it might be easier to just virtualize the existing situation. A typical garbage in-garbage out-type of migration, if you’d ask me, but definitely quicker to accomplish, compared to the rabbits you have to pull out of a high hat to make things work with new or freshly-demoted Domain Controllers.

About P2V conversions

The process of virtualizing an existing (physical) server, is called P2V’ing a server, where P2V stands for “Physical 2 Virtual Conversion”. While you could clone the disk of a physical server to a virtual server running on Hyper-V through a legacy NIC or other tools, like disk2vhd, you don’t need to go through the hassle: Microsoft has a P2V wizard. It is part of System Center Virtual Machine Manager (SCVMM), where the button to click is named “Convert physical server”. It automatically creates the virtual machine and fills it.
Two types of P2V conversions exist in System Center Virtual Machine Manager:

1. Online P2V conversions
   The P2V Wizard offers the ability to P2V a server, running a Volume Shadow Copy-capable version of Windows Server, without the need to restart the server. The conversion deploys an agent, which scans the configuration of the server. It then uses port 443 and BITS to transfer the contents of the hard disk(s). (the port can be changed though). This type of conversion offers higher availability, which might be beneficial in migration scenarios where you don’t need to bother with data integrity.
   For on online P2V conversion the physical server needs to comply with the following list:
   • The physical server should have at least 512MB RAM
   • The physical server should have an Advanced Configuration and Power Interface (ACPI) BIOS
   • The physical server should be running at least
     • Windows XP with Service Pack 1,
     • Windows Server 2003 with Service Pack 1 (both x86 and x64 installations supported),
     • Windows Server 2008 (both x86 and x64 installations supported) or
     • Windows Vista with Service Pack 1 (both x86 and x64 installations supported)
   • Drives should be formatted using NTFS.
      
2. Offline P2V conversions When digging in the options you can also choose to perform an Offline P2V. When you select this option, the same VMM agent gets deployed, but this time it copies over Windows PE and makes the server boot it. After the server is rebooted into Windows PE, this installation will take care of transferring the contents of the hard disk to a virtual machine. When done, the physical server is kept shut down by default.

I’ve created a little flowchart below to illustrate the process of both conversions and their differences:

P2V’ing Domain Controllers

Disk2VHD

Disk2VHD is a Windows Sysinternals utility, written by Mark Russinovich and Bryce Cogswell. This tool creates point-in-time snapshots of online physical systems. These snapshots are stored inside VHD containers, that you can use to create virtual machines inside Hyper-V or Virtual PC or boot from using the ‘Boot from VHD’ feature. (when using Windows 7 or Windows Server 2008 R2)

System Center Virtual Machine Manager

Online P2V conversions in System Center Virtual Machine Manager are based on point-in-time snapshots. Therefore, it’s no wonder, you’d receive the following warning when you try to Online P2V a Domain Controller:

Warning (13249) Online physical-to-virtual conversion of a domain controller is not recommended.  Recommended Action Run the Convert Physical Server Wizard again, and choose the Offline Conversion option on the Volume Configuration page.

Results

The simple reason for the warning message in System Center Virtual Machine Manager is you may receive the following error on a virtual Domain Controller when you boot it after you previously P2V’d it online:

The Domain Controller will display “The Active Directory is rebuilding indices. Please wait…” The integrity of the database is now at risk. I think we can safely assume the warning in the P2V Wizard in System Center Virtual Machine Manager isn’t an invitation to a game of ‘chicken’… The same error can be expected when you use the Disk2VHD utility.
The question now however is,

How to perform a successful P2V of a DC?

There are four steps to perform a good P2V conversion of a Domain Controller.
These four steps are additional steps to perform with the usual best practices when performing P2V conversions.

1. Take care of FSMO roles

The best practice is to place two Domain Controllers per Active Directory domain. When you adhere to this practice, it is safe to make one of the two Domain Controllers unavailable for P2V Conversion for a while. However, you might not want some Active Directory Flexible Single Master Operations (FSMO) roles to be unavailable for long. Furthermore, since the Domain Controller holding the PDC Emulator FSMO role is the authoritative time source for an Active Directory domain, you should be wary of any time synchronization issues. I feel it’s best to transfer any FSMO roles from Domain Controllers you’re going to P2V. After a successful P2V conversion, you can transfer the FSMO roles back. Keep the following in mind:

• Before you transfer the PDC Emulator FSMO role, check for correct time on the target Domain Controller. It may not have synchronized its time for a longer period or it may have a awry system clock…
• Before you transfer the Infrastructure Master FSMO role, take care of correct Global Catalog (GC) placement. Either the Domain Controller holding the Infrastructure Master FSMO role is the only non-GC Domain Controller, or all Domain Controllers need to be Global Catalogs. In environments with Microsoft Exchange, restart a Domain Controller after making it a Global Catalog.

2. Try a similar server first

Just like with using detergents you’d want to test first in an inconspicuous spot. In terms of converting physical servers to virtual machines you could test a server first, that doesn’t matter much. When you perform an offline P2V of a similar type of server hardware, you get acquainted with the quirks of the P2V Wizard inside System Center Virtual Machine pretty quickly.
In projects with P2V conversions I’ve seen people assigning only one virtual processor to Windows Server 2003 guests and disabling hardware vendor-specific services before P2V’ing.

3. Put the virtual DC on a separate network first

Every Hyper-v host has an ‘internal’ virtual network. Assigning this network to virtual machines is a perfect way to sidetrack them for a while. When converting a physical Domain Controller to a virtual machine, this is the perfect way to detect integrity errors, USN rollbacks and the like. After the server boots up well, you can attach it to your production virtual network. When connected to the production virtual network you can make it synchronize with the other Domain Controller(s) again and transfer FSMO roles.

4. Perform an Offline P2V

When converting a physical Domain Controller to a virtual machine using the P2V Wizard in System Center Virtual Machine Manager, always select to perform an Offline P2V conversion. When you click your way through the P2V Wizard, take some time to explore the “Volume Configuration” page. In the bottom there’s a little piece of text displaying “Conversion Options”. Click it to slide the Conversion Options up.

Now you can opt to perform an “Offline conversion”.
Since the VMM Agent first task is to scan the system the P2V Wizard already knows the hardware in the physical server. When hardware is found, for which the Windows Preinstallation Environment (WinPE) has no driver, the P2V Wizard will display a screen where you can add the corresponding driver.
   

Concluding

When you want to convert a physical Domain Controller to a virtual machine using the P2V wizard in System Center Virtual Machine Manager, use the Offline P2V option on the Volume Configuration page.
Do not use the Disk2VHD Windows Sysinternals utility on Domain Controllers.
Make sure you try a P2V conversion of a Windows Server with the same Windows version and similar hardware first. Also make sure you boot the Domain Controller on a separate LAN segment to prevent Active Directory corruption.