Cleanup after SRM test

[Geokes]

Our DR site is connected to the production site with an L3 VPN for AD replication.

SAN and vCenter on an independent link.

Prod : 192.168.1.0 subnet

DR : 192.168.100.0 subnet

Besides the VCenter server we also have a physical AD domain controller (DR-PDC) at the DR site (AD, DNS, DHCP) doing AD replication with the production site.

During tests, we would like to bring up our VMs "outside of the bubble", connected to the 192.168.100.0 network and accessible throught the DR site WAN IP (gateway 192.168.100.1).VMs would authenticate against DR-PDC.

During tests, we can shut down the VPN between sites, stopping AD replication.

My question is - what kind of cleanup, if any, needs to be done on DR-PDC after the test is done and before re-establishing AD replication?

Most VMs use static IPs and are re-IP-ed during the test. (192.168.1.200 becomes 192.168.100.200)

I would think the DNS registrations on DR-PDC would have to be deleted (whats the best way?).

Is there any other cleanup needed?

Would this become any easier if DHCP reservations are used instead of static IPs?

[GreatWhiteTec]

If you use dynamic DNS, you won't have to do any clean up. It would also make it easier if you use dr-ip-customizer to change the IP address of the servers during failover. Once they boot up they will register in DR-DNS. Once you fail-back it will do the same if you set it up to do so.

Dynamic DNS and DNS Scavenging are useful especially in this scenario.

-Dave

A+, DCSE, MCP, MCSA, MCSE, MCTS, MCITP, MCDBA, NCDA, VCP4

[Geokes]

I do use dr-ip-customizer, although not sure how to tell it to do its maginc in reverse on a failback.

A test using Dynamic DNS would look like this:

- create reservation for VMs at production (test-vm - 192.168.1.50)

- create reservation for VM at DR (test-vm - 192.168.100.50)

- disconnect VPN between sites

- bring up twe VMs at DR

- test apps

- shut down test VMs

- Scavenging DR-DNS

- reconnect VPN between sites

- AD still thinks nothing happened and does not get confused by having ghosts of VMs from the test

Am I missing anything?

[GreatWhiteTec · Accepted solution]

Are you testing or doing an actual failover? If you are testing I don't think it will change DNS for real, hence the whole "you can test without affecting production".

I am assuming your DNS is set up as AD-integrated. You can create a test VM a test for real. Of course this will require a separate datastore and all.

While doing a real failover, you don't really need a reservation in DHCP. You can use you static IPs and have the dr-ip-customizer change that for you. Make sure that the settings on the NIC have the "register this connection's addresses in DNS" checked.

A real test would include:

Creating Protection group in main site

create recovery plan in DR

creating the dr-ip-customizer entires

Failover

at boot up, IP settings for the failed over VM will register in DNS

AD-integrated DNS will replicate DNS changes

Flush the local cache on your machine so you can get the latest DNS entries from AD

The Server should work the same as before just with a different IP, and you should be able to get to it from both sites.

Not sure if I'm missing your point, but I do not believe changes are actually made in prod during a test.

[Geokes]

maybe I'm trying to achieve something unusual here.

I would like to do a test of production servers, not an actual failover.

The test would be done outside of the "bubble", meaning connected to the DR network instead of an isolated test network.

(So I could access the servers from the Internet, using the DR site public IPs (as opposed to the production site public IPs))

To avoid conflict, for the time of the test, I vould shut down the connection between DR and production.

Now I have my real servers, using a new IP, authenticating  against DR-PDC and registering their IPs in DR-DNS.

After the test is done, the teset copies of real VMs are shut down.

My concern is specific cleanup what needs to be done on DR-PDC before re-establishing the connection between DR and production.

I hope this makes it a bit clearer.

[Virtugirl]

ive done this type of failover before.  It was actually a dry run weekend for testing DR.  So i will assume that you will be setting the DNS server for your DR VM's up as the DR DC.  From what I can remember, you dont need to do anything to the DC.  You just need to make sure that your master DNS server replicates the correct ip back to the DC once finished.  I have the process document I did for this somehwere on my laptop so I will dig it out and check what I did for the failback

[Geokes]

Thanks, if you can confirm that Active Directory is not affected in any way by this type of testing, I'll be much more confident trying this out.

[Virtugirl]

Ok i found the document and because it was only a small number of servers, I changed the IP's manually on the failback.  I would imagine if you deleted the DNS records off the DR DC once your servers are shut down and then on your production estate forced a replication, this too would be fine.

Other things I did were to seize FSMO roles to and from DR site

Disable the DR DHCP scopes - only neccessary if you have live services at the DR site and want to keep DR workstations seperate

Change home drive locations for users as our filer name changed at the other site

I also changed my Sites and services subnets for applications such as Microsoft SMS which uses this to distribute agents.

Honestly - even if everything goes wrong with the DC... you will always have your production one intact so you can always build a new one and replicate in a relatively short space of time.  I was a little unsure at first about the DC but really its quite easliy to fix if it does go wrong and is one of the least of worries on a failover / failback.