I believe you'll need to blow away the DBs on the production servers, set them back up as SCR targets and re-seed everything.
If this is intended to be a thorough test, representative of a real disaster recovery scenario the assumption would be that the primary site is destroyed and everything in it will need to be replaced, and that would be representative of the process that will be required to fail back to the primary site afterward. -----Original Message----- From: Paul Gordon [mailto:paul_gor...@hotmail.com] Sent: Thursday, May 13, 2010 8:17 AM To: MS-Exchange Admin Issues Subject: SCR Failover questions Peeps, I have an upcoming task to perform a DR test for a client whereby we intend to test the failover process of the SCC mailbox cluster to a standby server that is an SCR target for all the storage groups on that production server. I’m perfectly happy with the configuration & monitoring of the SCR copies, and also with the actual failover, using database portability to bring the standby copies of the databases online, and move-mailbox (configurationonly) all the users to the new location.. that’s all fine & Dandy… The bit I’m not sure about is how best to continue in the simulated failover mode of operation, whilst allowing for seamless failback onto the prod hardware at the end of the test, which is expected to be about 24-hours. The plan is to fail over to DR hardware on a Saturday, fail back to prod on Sunday, and have everything running sweet as a nut again for all the users on Monday morning. Because this is intended to be a fairly realistic, thorough & representative test, the mail service will be running “live” for that 24 hour period on the standby hardware, and this includes receiving all inbound mail for the production domain name during that period. – This means the Exchange databases on the standby hardware will have new content that won’t exist on the “live” server… - and since these are actually in different locations over a WAN link, it’s not a simple matter to simply take a copy of the most current EDB file from the standby server to mount back on the live server… So, what I was wondering is: - at the point I failover the databases onto the standby server, both will be in the same state (In respect of the sync status), so what would be really useful would be to enable SCR back in the OTHER direction, so that the production server then becomes the SCR target and thus keeps ITS copy of the databases up to date with all new content that comes in to the standby server. I’m quite happy about doing that too, but I’m not certain whether I can just enable SCR to the currently existing EDB file on the production server without having to reseed it again from scratch… - thus far, I’ve only ever setup SCR from “clean”, where seeding has always been required… So, - if I have two servers, each with an identical copy of a database, can I enable SCR between them using the existing EDB file as the initial seed, and thus NOT have to resync the whole database over the WAN again? – ideally, I’d just like to have it ship the logs back to the “live” server for the 24 hour test period, so that at the end I can just perform the same process in reverse to restore everything back to the normal running state… I’ve been trying to research this for the last week, but every article I’ve found only goes as far as I’ve already gone, - i.e. setting up & starting SCR, and performing a failover, at which point all articles I've found consider the process complete… TIA Paul Gordon ************************************************************************************************** Note: The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. **************************************************************************************************
