Regardless of the virtualization safeguards probably mitigating risk, I still come back to the original question which is why subvert a system which has its own replication mechanism (AD) with the vmWare alternative? Perhaps there’s a detail I’m missing here but that’s where this breaks down for me.
Thanks, Brian Desmond w – 312.625.1438 | c – 312.731.3132 From: [email protected] [mailto:[email protected]] On Behalf Of Charles F Sullivan Sent: Friday, February 5, 2016 2:53 PM To: [email protected] Subject: RE: [NTSysADM] Replicating AD VMs All DCs are at 2012 R2. The forest/domain functional level as well. ESXi and vCenter are newer than the first version that supported VM-Generation. Anyway, I’d seen the page you linked but forgot about it, so thanks for that. My take on this is that the Generation ID will change when I use vSphere Replication. Because the DCs are all Windows 2012 R2, they will handle this. From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Stephen Gestwicki Sent: Friday, February 5, 2016 3:17 PM To: [email protected]<mailto:[email protected]> Subject: RE: [NTSysADM] Replicating AD VMs 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 - Stephen From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Christopher Bodnar Sent: Friday, February 05, 2016 2:17 PM To: [email protected]<mailto:[email protected]> Subject: RE: [NTSysADM] Replicating AD VMs Are you familiar with this? https://blogs.technet.microsoft.com/askpfeplat/2012/10/01/virtual-domain-controller-cloning-in-windows-server-2012/ From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Charles F Sullivan Sent: Friday, February 05, 2016 1:42 PM To: [email protected]<mailto:[email protected]> Subject: [NTSysADM] Replicating AD VMs Is there any reason I should be afraid to use VMware replication to make copies of our DCs in the event of a data center-wide disaster? We have 5 DCs, all VMs, in a Windows 2012 R2 Forest/Domain functional AD. We have one forest, one domain. One of these DCs is running at a backup site about a mile away. I would like to use VMware Replication to keep copies of the other four DCs at the same location. The replication would be set with an RPO of 15 minutes. In a disaster scenario for our data center, the DC at the other site would be the only one standing, but I would bring up the replicated DCs, one at a time, starting with the PDCe. The only other thing I would need would be to confirm that the IP configuration holds or set it correctly if needed. Everything else is taken care of, such as physical network, DNS, etc. We already know we can recovery services such as this at the other site because we have tested it. Also, VMware replication would not be used as a replacement for backups, and we have other AD DR plans which have been tested using conventional backups. I simply want to know, from an AD perspective if this is a bad idea. The platform is irrelevant. We could just as well be using Hyper-V, but I will also check on the VMware Forums in case there’s something I should know related to VMware’s solution. Thanks in advance for any feedback. ________________________________ ----------------------------------------- This message, and any attachments to it, may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are notified that any use, dissemination, distribution, copying, or communication of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately by return e-mail and delete the message and any attachments. Thank you.
