Virtualizing business critical applications, like Microsoft Active Directory (AD) must be done right and with caution. Windows Server 2012 has introduced new feature called VM-Generation ID, which enables the underlying ESXi to expose a 128bit counter within the guest VM. This allows the VM to be aware that the VM has been restored from snapshot or cloned. Snapshot which are used by backup software during the backup process to properly backup running VMs or by manual way through vSphere client (not recommended on DCs running in production …).
The VM-Generation-ID unique identifier is an additional attribute of a Domain Controller's AD computer object. The VM-Generation ID can be used to avoid situations where you would need to initiate authoritative restore of AD in order to remediate on replication problems due to USN rollback.
I know many admins who keep at least one AD server on physical host, because not everyone liking the idea of having “all eggs in the same basket”. AD is critical piece of almost every single enterprise.
The VMware vSphere 5.0 Update 2 and higher needs to be in place in order to use this feature.
Microsoft introduced the VM-Generation ID, a 128-bit counter exposed by the hypervisor to the virtual machine guest operating system. The VM-Generation ID provides the virtual machine guest operating system with knowledge of the state of the virtual machine. For example, whether or not the virtual machine has been restored to a previous point in time or has been cloned.
VMware has published a new paper which gives a good tips on how this works and what's the best practices in VMware environments. Only Windows Server 2012 and higher versions can leverage the VM-Generation ID.
The paper is available through this link (pdf) and there is many up-to-date best practices for virtualizing AD, setting the authoritative time source etc…
The USN stands for update sequence number. Here is in short what it does:
Every transaction is stamped with a globally unique identifier, the Update Sequence Number (USN), and the identity (InvocationID) of the Active Directory database where the write operation occurred. Together, these processes provide a replicable transaction.
By implementing the best practices for your AD at your company you ensure that you won't run into problems like an AD corruption due to USN rollback, where you might encounter an error like this one:
“The Active Directory database has been restored using an unsupported restoration procedure. Active Directory will be unable to log on users while this condition persists.” (NTDS General, Event ID 2103)
The paper has been just published by VMware and brings many screenshots, scenarios and tips. I can only highly recommend for reading.
Source and Download: vSphere Blog
