Active Directory in Hyper-V environments, Part 2

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.

Further reading

Hyper-V Best Practices – Quick Tips (1)
Hyper-V Best Practices – Quick Tips (2)
Microsoft TechNet forums: How to Clone VMs in Hyper-V
Download details: Running Domain Controllers in Virtual Server 2005
All Topics Performance: Hyper-V: Integration Components and Enlightenments
Understanding and Using Microsoft Windows Server 2008 Hyper-V Snapshots
Considerations when hosting Active Directory domain controller in virtual environments
Computer Account SID hell with virtual machines guests and gsgetsid.exe and NewSid.exe
NewSID v4.10 by Mark Russinovich and Bryce Cogswell
[PPT] WIN388 Using Virtual PC 2004: Tips and Tricks by Ronald Beekelaar (TechEd 2004)
How to detect and recover from a USN rollback in Windows 2000 Server
How to detect and recover from a USN rollback in Windows Server 2003
Whitepaper: VMware and VSS: Application Backup and Recovery
Top 5 things to know about Hyper-V
MSN Video: Ronald Beekelaar on Virtualization
Virtual Varia: Hyper-V Installation Tricks – Prologue
Download details: Hyper-V Planning and Deployment Guide
Download details: Running Domain Controllers in Virtual Server 2005

Series Navigation

<< Active Directory in Hyper-V environments, Part 1Active Directory in Hyper-V environments, Part 3 >>

2 Responses to Active Directory in Hyper-V environments, Part 2

  1.  

    Are you saying by “Always shut down virtual Domain Controllers properly to avoid replication errors” and “Never save state in a domain controller as this may cause synchronization issues in the domain”, that Domain Controllers are not to be placed on highly available Hyper-V (clustered hosts) since unplanned node failure results in quick migration of VM’s from that node which would save state (!) of the DC and move it to the another node?

    What would be the recommendation or procedure if the node/host where virtual DC is residing does fail?

  2.  

    Hi summersun,

    Your observation is correct. It is exactly what I’m saying.

    Let me elaborate on this a bit: Pausing a Windows virtual machine can result in timing issues, because Windows will need some time to gather the new time. In Active Directory this may result in replication issues. Since quick migration works by pausing the virtual machine and starting it again on a different host, you could experience issues.

    The way to make Active Directory highly available in both the physical and the virtual world is adding Active Directory Domain Controllers.

leave your comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.