I always kill the link prior to test dr restore. In a DR scenario, your original endpoint won't be there anyway. Also, In a disaster, I'm going to be restoring servers to the same name. So, that's how I'm going to practice it. I bring up everything live as it can be, test the heck out of it with workstations. (Mimicking users and external clients). Pretty much everything except actually switching the public dns records.
-----Original Message----- From: Tom Miller [mailto:[email protected]] Sent: Tuesday, December 04, 2012 7:57 AM To: NT System Admin Issues Subject: DR planning Folks, Next week we are testing two disaster scenarios at a remote site (we pay the site and they provide servers only for restore/DR - no live hosting). We have Exchange 2003 here and a variety for 2008/2003 servers as DCs and member servers for file and print. Recommendations for recovery? This is just a simple test to see what we can do. Long-term I'm going to recommend live servers so I have put a DC and replicate files and Exchange 2010 there. For now I'll need to be able to restore some SQL databases for an enterprise system, Exchange 2003, and files for file and print. Since it's a test and I can't restore servers of the same name and such on a live network - we have an MPLS link to DR site - I was thinking of just building a few new servers, add a DC, and install SQL and restore databases. What about Exchange 2003? Is there a way I can restore the databases but only be able to manually pull mail from them? Or would it be better to just build a new Exchange 2003 server and add DR accounts to it. It has been a long time since I've worked with Exchange, so your thoughts are appreciated. Moving forward, what do you folks do for DR? I was thinking at the remote site (always live eventually): DC, SQL server with replicated databases (2012 AlwaysOn I guess), server for file and print using DFS to replicate critical files, another Exchange 2010 server in the current DAG, and a hub/client access server. Tom ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin
