DiRT restore to cold standby for DR testing

[robrhodes]

Is there any potential negative impact to performing a DiRT restore to a standby Unity server that uses the same Exchange back-end as the production Unity servers (Unity failover)?

I have a customer that would like to test their DR plan by performing a DiRT backup of their secondary Unity failover server and restoring to a cold-standby server. The standby server has been completely configured and has the appropriate license file. The back-end Exchange server for the cold-standby is the production Exchange server.

Before I click that last OK button to kick off the restore I want to make sure there are no account attributes or anything else that would be modified by the restore that would have to be changed back for returning to the production servers.

[lindborg]

STOP!!!

yes - there's a very big problem - all the users in the directory will be forcibly repointed to the new Unity server you do the restore on. That means each an every AD account in the direoctory that is a Unity subscriber will be touched to point it at the new Unity server and the existing production Unity server will immediately start to note that those users are no longer assigned to it. That's bad. It's major. Don't do it.

please, please, please review the help file - it covers in great detail what happens during a restore - this is covered in there.

If you want to test a system restore, do it on another, isolated network with it's on DC/GC/Exchange server in a lab setup. DiRT restores in a production environement are serious businss.

[robrhodes]

Thought so, just wanted validation. Thanks for the prompt response.

[amyguysignore]

So if this were an actual DR site where we needed to just do a Dirt Restore on a Unity Standby box in the Same domain pointed to a different exchange server in the Org a the DR location, by running DIRT Restore will repoint all the users that are in the Unity restore to talk to the new exchange box?

[ranpierce]

I have an actual DR site and DiRT is the last thing you want to have to do.

If the exchange partner server name has changed because Exchange has also failed over or for some other reason. As long as the subscribers and Unity accounts are on that server, I run MSCW to partner with the failed over Exchange. (Exchange 2007 now)

Exchange 2003 the failover exchange kept the same name and I never had to run MSCW.

DiRT, A total rebuild of Unity is done.

Randy

[Tommer Catlin]

Here is what I did, and it works pretty well.

VM only with failover and offbox exchange running at the primary site.

(domain A)

DR site, I have another Unity server, exchange all on box VM Only waiting on standby

(domain B)

I configured CUCM to roll through the hunt groups (Primary, Failover, and then DR site) In the event the domain A is not available)

The customer is running DIRT backup and then DIRT restore /dirty on the DR site once a week, but not brining over the messages. Everything but the messages.

It seems to work. It works fine because it's a different domain, etc. If it was the same domain, it would be messy because of AD.

It's not the cleanest, but if you want clean, move to Connection 7 with active/active. No need for AD, Exchange etc.

[amyguysignore]

Thanks for the replies..Here is what we are looking at:

Production site:

Unified messaging with their exchange 2003 cluster environment. They have a unity failover box as well, on site. CM Pub and sub on site. (bandwidth not enough to put failover at DR site)

DR Site:

DC, GC, as well as an Exchange server that is in the same domain as production site. Some third party tool that replicates the mailstore from the production exchange server to the message store at the DR site every couple of hours.

If the production site gets taken out of commission, can I take a current dirt and restore it to a unity box that is at the DR site, already in the domain and connected to the message server at the Dr site as its partner. Unity is basically just installed and working but no subscribers added.

I have done something similar when I do hardware migrations but in the step that is missing from above is before I restore to the new unity box i uninstall unity from the production box taking out all unity attributes from the users. If I skip this step because if the site is gone I cant uninstall will this work?

[Tommer Catlin]

I dont think that will work very well. It will probably work at the DR site, but the rollback will be a mess. The old Unity server will probably have to be rebuilt from scratch and re-installed or you will have to use GSM to move the Unity subscribers from the DR server back to production. The SQL database will not take the DIRT restore correctly or maybe the a dirty will work, but that would be risky.

In theory, since the Mailstore is replicated, using the same server name or exchange server name, Unity should not have a problem with this.

If you have other locations that use digital newtworking, they may have issues with the locations and where these DR subscribers are located after DR and during.

I would say as a test, if you can do all this in the lab and not affect production is the following:

DIRT backup the old server

Verify the DR server is running, taking calls, MWI, etc

DIRT restore /dirty to the DR server

Test

Bring up the old Unity server, blank out the Unity database because you will not be able to have the same subscriber on (2) unity servers, currently, the DR server has the subscribers.

DIRT should be able to restore a clean database to the Unity server

DIRT backup the DR server

DIRT restore the production server

DIRT restore a clean database to the DR server

This is all super risky and not very clean. You have a lot of tools and methods and none are really documented or possibly supported with this method. There are no real DR supported configurations when using UM or VM and Unity 5.x and 7.x or even 4.x. My method is puring hypthetical and who knows if it will work.

Another option would be is to have a couple rotating spare drives on hand. Pull a drive, ship a drive, pull a drive, ship a drive and rotate that between DR and the production site. The only thing you need to change is the IP address of the Unity server once it comes up.

It's almost worth adding in the extra bandwidth and cisco requirements to get the failover server to work at the DR site. (follow the guidelines) if voicemail and CallHandlers are that important.

How about a backup Unity server just for callhandlers. In the event production is down, roll the calls into a CUE or Unity server at another site. Prep the message for "experiencing technical difficulties and zero for the operator" or something like that.