- This topic has 8 replies, 6 voices, and was last updated November 8, 2017 by Slawomir J.
Domain controller replication case
Ivaylo KMay 25, 2017 04:05:50 PM
Client organization “A” has a business requirement to have main operational site and DR (disaster recovery) site in different geographical zone. The main site and the DR site are connected via strong network connection with very low latency.
Once DR test recovery executed, all of the services including (DC, DB, Applications etc) in the isolated DR site must be able to be up and running operational up to 10 (ten) calendar days
The DR site is running on isolated network with enough IPs to host the most critical services. The DR site must be activated as needed. There is no permanent authentication service (Domain Controller / LDAP / IdM) solution in the DR site.
Domain controller (DC) from the Production site must be replicated to the DR site via Zerto ZVM tool while the same DC is fully operational in the production site. The replicated DC must be able to provide authentication services for the replicated VMs in the DR site while the entire DR site is isolated from the production site.Harry SMay 25, 2017 05:20:03 PM
Is your question around can this be done, or are you asking something else? If you’re asking if this can be done, the answer is yes. You could either replicate the DC with ZVR and isolate during testing, or you can replicate the DC live on the network using AD replication/architecture and (clone, then) isolate this DC from production during testing.
~harryFollow me: www.twitter.com/HarrySiiiIvaylo KMay 25, 2017 08:00:28 PM
This is a real case scenario which my client has. Only the names and the details related to the case are removed.
During the first attempt of using the product , we were not able to have successful recovery of the Domain Controller in the isolated DR network.
As I said, the DR network is isolated and there is no locally hosted DC and DNS server.
Any documentation and / or real case failover instructions for the domain controllers will be great. If that is not the case, what would be a potential workaround or plan B for this recoverySean MMay 27, 2017 07:05:34 PM
At a high level, Zerto can protect any VM and there are no unique needs of Zerto in protecting MS Active Directory Domain controllers (AD DC), however the requirements to protect and recover an AD DC can change depending on the version of Windows Server being used. You can refer to Microsoft documentation on protection and recovery of AD DCs by Windows Server version. Depending on the version you may be able to simply protect the VM and fail it over, or you may need to have one or more changes take place on the guest or in AD post-recovery. These changes can also impact the disaster recovery plan in other ways.
Since you are a Zerto partner I suggest connecting with your Zerto account team on a design discussion. I do not recommend trying to solve this here on the forums since the customer network topology, any number of unique customer requirements, and so on may impact the final design.Slawomir JAugust 21, 2017 12:38:57 AM
In our case, once we started using zerto vss agent, we were able to successfully start not only vm, but also all AD DS on that DR isolated DC.
Hope that may help other guys having similar issues.Carlos CSeptember 1, 2017 07:52:23 PM
so is it supported to replica Windows Active Directory Servers?I usually say to customer hey use Windows replication but not sure about that now
Carlos, it’s neither supported nor unsupported. Zerto protects virtual machines, the contents are irrelevant (besides requirements for things like IP reconfiguration). The question any individual organization would need to ask is does our application support recovery from crash-consistent states, such as with Live Failover to the latest or any timestamped checkpoint? I’d estimate somewhere around 99% of applications are successful with this based on customer feedback. There are still those applications that require recovery from a transactionally-consistent checkpoint through Zerto VSS, and you can determine this through testing since it is zero impact.
In addition you need to ask the question, and plan for the answer to, whether you are changing the IP address on failover and how will AD react to that. Again, nothing to do with Zerto other than us changing the IP address, instead it’s all about the application.Patrick GNovember 8, 2017 07:55:32 PM
Out of curiosity what kind of fail over situation were you trying to accomplish here?
Was it vmWare to AWS? Was it Hyper V to Azure?
Please review my post and chime if you can: https://www.zerto.com/myzerto/forums/topic/ms-server-2012-r2-domain-controller-to-aws/Sr. IT Cloud Engineer for BJ's Wholesale Club, Inc. based in Westborough, MA.Slawomir JNovember 8, 2017 10:28:04 PM
We failed over from hyper-v to vmware.
Yes, we were surprised that failover was fine on OS level, but AD DS were simply corrupted and not loading. In past tests (vmware-to-vmware) we never had issues with failing over domain controller. We’ve tested hundreds scenarios and check points. One domain controller simply refused to come clean in application crush consistent sense.
We’ve even powered off the server (what should prepare it for migration and save RAM cache to files) and run test failover for various check points around shutdown time with no luck.
Only vss snapshot allow successfully bring replica up with all DC services working fine.
Yes, Carlos is right, active directory should be replicated with windows tools, yet what about pure DRaaS scenario? All servers, AD DC inclusive, should be DR prepared and failed over. If you offer to customer only space for DR, customer should not be forced to run new dedicated DC in DR as it would have to be maintain, license and resources paid. Other scenario is when production network is failed over with servers at the same time – thus no way new DC can run on DR platform.
No, Sean, content of virtual machines is the core for the customer business and that is why customer would invest in DR. If you care about VM only then customers will walk away from your product. The expectation is that in fastest possible time, without hit and miss of multitude of check points customer critical applications will be serving end users. No body cares about virtual platform and vms until they serve the purpose.
Our observation suggests that this vm was somehow incorrectly build or got issues down the line, yet as it was customer critical DC (lots dependant applications and services tied to that DC) we couldn’t rebuild that server and it had to be failed over with other servers.
Anyways, in our case vss did the job, but I need to warn you that zerto vss agent is not fully developed and we had many issues with it. Starting with licensing that caused the project to hold for a week, ending on massive problem that zertoVssAgent is not able to talk to protected site ZVM via ZCC and that is defeating the purpose of separating customer network from CSP one.
I hope there will be more customers nagging zerto developers to fix those fundamental flaws.