VMware has a way to deal with this, just like Hyper-V does. Unfortunately, I don't know what it's called for VMware. Hyper-V has the original name of Hyper-V Replica.
It consists of having uniqueness in a replicated VM. There is a VMGuid and a VMGeneration. VMWare has a way to do the same thing. This allows you to replicate, failover, resynchronize, failback, etc. This is different than Hyper-V Clustering. The CHALLENGE associated with using a "bit-for-bit" copy is associated with USN Rollback scenarios. USN is discussed in detail here: https://technet.microsoft.com/en-us/library/virtual_active_directory_domain_controller_virtualization_hyperv(v=ws.10).aspx#usn_and_usn_rollback -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Charles F Sullivan Sent: Friday, February 5, 2016 2:47 PM To: [email protected] Subject: RE: [NTSysADM] Replicating AD VMs I think your key words are "....and then the *same* VM is powered on at the DR site". As far as I can tell, it would be almost the same using VSphere Replication. Even in your case the VMs that are brought up at the other site are behind in AD changes with the one(s) still standing. I'll be testing this beforehand anyway. Unless the replicated VMs are somehow "marked" as different machines, I don't see where this could be an issue, but I’m still listening. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Michael Leone Sent: Friday, February 5, 2016 2:38 PM To: [email protected] Subject: Re: [NTSysADM] Replicating AD VMs On Fri, Feb 5, 2016 at 2:18 PM, Brian Desmond <[email protected]> wrote: > Essentially you’re circumventing AD’s replication engine with > something that isn’t going to enforce consistency which has the > potential to turn out very poorly. I'm not sure if this is truly the case here, tho. I will admit to being unfamiliar with VMware replication (as opposed to the way we do it, which is SAN replication via RecoverPoint). But in our situation, what is happening is that the LUN that holds the VM is being replicated (synchronously, in my case) to another LUN at a different site. Basically the LUN at the DR site is a non-active copy. So if the LUN at the main production site becomes unavailable, then the LUN at the DR site is marked as active copy, and the VM on that LUN is started. That doesn't interfere with AD replication, which happens via IP to other VMs/hosts. Effectively, the VM at the production site is shutdown, and then the *same* VM is powered on at the DR site. Effectively, it's just like replication failed temporarily. Same VM, same name, same IP, etc. I know that in my case, that is what happened - we had no replication breaks, corruption, etc. Granted, I do have other physical Dcs that never went offline, during this test. But I never had to seize roles, etc. The roles that were on Prod-DC-1 are still on Prod-DC-1 - it's just that Prod-DC-1 was inaccessible for a few minutes. It wasn't like it was out of commission for so long, it tombstoned. You'd get the same effect if you pulled the network cable out of Prod-DC-1 for 15 minutes, wouldn't you?
