On Fri, Feb 5, 2016 at 3:17 PM, Stephen Gestwicki <[email protected]> wrote: > The VM-GenerationID that was added in Server 2012 is what makes this safer > to do. I say safer because that number has to be updated or it won’t do > anything to help you. That means moving the VM files of a DC manually is > just as dangerous as it has always been. > > > > I would make sure all your DCs are on Server 2012 or newer and you are only > running version of VMWare that support the VM-Generation-ID. You may also > want to take a look at this list: > https://blogs.vmware.com/apps/2014/01/which-vsphere-operation-impacts-windows-vm-generation-id.html
Excerpt of above link: The replication of the VM (using vSphere Replication or an Array-Based replication engine) is what triggers the VM-GenID change for the replicated VM. SRM is unaware of VM-GenID. By the time you trigger the RecoveryPlan, vSphere had already made a determination that the machine state has changed. So, technically, the answer to your question is “Yes”. HTH ----------------------- Introduction to Active Directory Domain Services (AD DS) Virtualization (Level 100) https://technet.microsoft.com/en-us/library/hh831734.aspx In this case, when the hypervisor detects a change to VM-GenerationID value, virtualization safeguards are triggered, including the reset of the InvocationID for the virtualized DC (from A to B in the preceding example) and updating the VM-GenerationID value saved on the VM to match the new value (G2) stored by the hypervisor. The safeguards ensure that replication converges for both domain controllers. Sounds definitive to me, I guess. If a VM-GenID is changed by the replication, and these safeguards are triggered by a changed VM-GenID, the last line indicates that replication would then happen correctly. Presuming I understand all this correctly. :-)
