• This topic has 14 replies, 3 voices, and was last updated March 10, 2020 by Matt M.

How do others make AD available in Test Failover?

  • Matt M
    February 27, 2020 06:40:54 PM

    Needing to bring Active Directory into our Test Failover network and looking for some options.  Can anyone share what they have done to accomplish this?  I’ve read one solution that simply replicates an AD server to the DR site that is then ONLY used for testing.  Then it’s brought up in the test failover network with the other servers when needed.  Has anyone tried this or are there other options available?

    Thank!

    Matthew C
    February 28, 2020 12:49:41 PM

    Matt – how I do this is I clone one of my DC’s at my target site, into the Zerto isolated test network. That way I can bring up AD and when I do a failover test, all the servers can properly authenticate. Once I end my testing, I just delete the cloned DC VM. Works really well and is a very quick process.

    Christopher W
    February 27, 2020 08:47:03 PM

    Hi Matt,

    Chris from Zerto Support here. 

    These knowledgebase articles outline recommended best practices concerning replicating AD domain controllers:

    https://www.zerto.com/myzerto/knowledge-base/best-practices-for-active-directory-domain-controller-availability/

    https://www.zerto.com/myzerto/knowledge-base/replication-of-a-domain-controller-using-zerto/

    Please let us know if you have any additional questions.
    Regards,

    Chris

    Matt M
    February 27, 2020 09:24:08 PM

    Thanks, Chris.  Yeah, I saw that article earlier.  It makes it pretty clear that you should not replicate a domain controller with Zerto.  We do have a domain controller at our DR site that is actively replicating (via native MS AD replication) with production.  My question is how do I use that to authenticate in my isolated Test Failover network?  The domain controller operates outside of that bubble.

    Christopher W
    February 27, 2020 09:36:25 PM

    Hi Matt,

    Given it’s on a separate network, you can’t authenticate to it unless you were to set up something like inter-VLAN routing to enable communication between the two networks:

    https://www.cisco.com/c/en/us/support/docs/lan-switching/inter-vlan-routing/41860-howto-L3-intervlanrouting.html

    Thanks,

    Chris

    Matt M
    February 28, 2020 01:07:07 AM

    Yes, this is true.  But then wouldn’t there be an issue with my production AD seeing not only my production file server but also the replicated file server that has been spun up in the test network?

    Matt M
    February 28, 2020 05:34:46 PM

    Thanks so much Matthew!  That’s exactly the kind of information I was looking for.  Do you happen to have a method for users to login to your test network via RDS?  Wondering if I need to setup a multi-home system so users can login and test, but not sure.

    Matthew C
    February 28, 2020 06:09:39 PM

    You could setup a multi-home system, however I don’t do this. I’m too concerned with production and test getting cross traffic, I just like to keep them 100% isolated. How I test is I get the people that need to verify the applications and I have sit at my desk. I log into the VI Console, and have them login to a shared Citrix server (which I also cloned) and they access all the applications that way, in a closed network.

    Matt M
    February 28, 2020 06:35:10 PM

    Thanks again, Matthew.  Super helpful!  Cross network traffic has been my #1 concern as well.  I work for a largish enterprise and I don’t want to be the one who corrupted AD.  I’ll give this a go.  Our current environment houses 2 separate domains with a one-way trust.  Users are authenticating on one domain, then accessing resources that are in a second domain so I’ll need to clone DCs from both and bring them into test.  Hopefully that doesn’t throw a wrench in it, but we’ll see.

    Matt M
    March 3, 2020 09:19:06 PM

    Matthew, do you do anything else to your DC once you bring it up in test?  Do you have to manually re-IP it?  Since I have to bring in 2 DCs from different domains (trust between), re-IP them, that seems to blow things out of the water.  I’m also failing over an app server and file server.  Attempting to access files from the app server but no go.  Can’t authenticate.  Might just be too many moving parts for this to work for us.

    Matthew C
    March 3, 2020 09:24:34 PM

    I don’t think you need to re-IP your DC’s. I don’t do that. Because it’s an isolated network, there is no need to re-ip your servers at all. I don’t have 2 different domains, but I don’t see why it wouldn’t work. What you might need to do is simulate the routing path between your domains. You could do this with a simple windows box with routing turned on, or you could get more creative with something like a PF Sense firewalls. I’ve used a windows VM in the past to do this, I attach 2 NIC’s, one on each subnet, and assign those NICs the gateway addresses that are in production. Then when you clone your 2 DC’s into the isolated network, their gateway is available and they can talk to each other. You can use 1 isolated vlan to make this all work.

    Matt M
    March 3, 2020 09:37:00 PM

    Yeah, good point.  I was leaning toward not changing anything on each but, as you mention, leveraging a VM that has a leg in each subnet.  Thanks for the feedback.

    Matt M
    March 9, 2020 06:37:05 PM

    Follow up:  I haven’t completed testing on this yet but after further research it appears that I will need to seize FSMO roles for the DCs that I’m bringing into the test failover network and perform some metedata cleanup.  I’ll post more info as it becomes available in case others run into this.

    Matthew C
    March 9, 2020 06:55:28 PM

    That’s an interesting find. In my tests I’ve always cloned in the DC that had all the FSMO roles so I never ran into that.

    Matt M
    March 10, 2020 12:05:42 AM

    Unfortunately, as mentioned, we have to clone 2 DCs from 2 different domains into test.  I can easily seize FSMO roles on one of the DCs but the other is part of a much larger forest and only corp IT has schema\enterprise admin rights.  Without seizing those roles I don’t think there’s any chance it’s going to work.  So far I’ve been able to get the 2 DCs and a couple of other servers to all see each other on the test failover network but AD is failing.  DCdiag reports numerous errors.  Still working with corp IT on this.

    https://www.concurrency.com/blog/november-2018/active-directory-during-dr-tests

You must be logged in to create new topics. Click here to login