Enabling SCR

When installing SCR for your DR site, a couple of decisions need to be made. If the SCR server is going to be just a mailbox server or will it hold the roles of CAS and HUB as well. If all roles are on the SCR server, it is important to remember that the HUB role will act as an additional hub transport server for out going mail. This can be disabled, but it is not recommended.

• For this test in a lab, the following information relates to the install for SCR:
  The SCR server was installed with Windows 2008 Enterprise and Exchange 2007 Enterprise
• Server name is DRMBX1
• Server partitions were created identical to the mailbox server (very important since the replicate needs to go to the same location)
• The server was configured with CAS, HUB and mailbox server roles (if all roles are going to be installed and the server used in a full disaster recovery, the SSL certificate(s) from production should be exported then imported to the SCR server
• If IIS is redirected to the \owa folder in production, the same should be done on the SCR server

1. Enable SCR Copy - In order for each storage group to be replicated over to the SCR server, the following command needs to be run for each storage group (see Test SCR for folder locations):

Enable-StorageGroupCopy EXMBX1\SG1 –StandbyMachine DRMBX1 –ReplayLagTime 0.0:0:0

If stopping the replication is required, use the following syntax:

Suspend-StorageGroupCopy EXMBX1\SG1 –StandbyMachine DRMBX1

or

Disable-StorageGroupCopy EXMBX1\SG1 –StandbyMachine DRMBX1

2. Re-Seed SCR Copy - Once the storage group copy has been enabled, the database will require re-seeding. You might have to suspend the copy before re-seeding. To re-seed each database, use the following command:

Update-StorageGroupCopy EXMBX1\SG1 –StandbyMachine DRMBX1

Depending in the size of the database, it could take anywhere from 30 minutes for a 10GB database and up to 5 hours for a 100GB database. This should only be required for the initial configuration.

3. Check SCR Copy Health - Once the database has been replicated / seeded to the SCR server, to check the health of the copy, run:

Get-StorageGroupCopyStatus EXMBX1\SG1 -StandbyMachine DRMBX1 Fl Summary*,Copy*

4. Create DR Storage Groups and Databases - In order to mount the replicated databases, a few steps need to be completed. A storage group and store will need to be recreated, just to have a location on the SCR server. This will be used just for a reference (pointer) for the actual replicated databases. The storage groups and stores can be created manually or with the powershell commands:

To create Storage Group (This needs to be done for each storage group in production):

New-StorageGroup -Server DRMBX1 -name SG1 -LogFolderPath L:\Recovery\SG1\ -systemfolderpath L:\Recovery\SG1\

To create Mailbox Store:

New-MailboxDatabase -StorageGroup DRMBX1\DR_SG1 -Name DR_Central -EdbFilePath S:\Recovery\SG1\Store1.edb

Once the syntax is run for each storage group and store, the stores will need to be mounted, dismounted and all logs and databases files deleted. Use the following command prompt:

Mount-Database SG1
Dismount-Database SG1
Del S:\Recovery\SG1\*.*
Del L:\Recovery\SG1\*.*

5. Configure SCR for DR

a. Before you are able to mount the databases, the storage group needs to be activated on the SCR server. The following command will need to be run for each storage group after the database is dismounted in production:

Restore-StorageGroupCopy –Identity EXMBX1\SG1 –StandbyMachine DRMBX1 -Force

b. Once the storage group is activate, the database needs to be checked to see if it is in a clean or dirty shutdown. To check this, drilldown to bin directory and run:

ESEUTIL/mh “S:\SG1\DB1.edb” findstr State

The database should always be in a ‘Dirty Shutdown’, so run a soft recovery to commit the logs to the database. You will need to see what generation the checkpoint file is. This example uses generation E02. For the soft recovery, run:

ESEUTIL /r E02 (this will probably error out. If it does run:)

ESEUTIL /r E02 /a

Run ESEUTIL against the database again to make sure the database is in a ‘Clean Shutdown’

ESEUTIL/mh “S:\SG1\DB1.edb” findstr State

c. Now that the database is in a clean shutdown, the redirect for the storage group and database paths need to be done. Run the following two commands:

Move-storagegrouppath DRMBX1\SG1 -SystemFolderpath L:\SG1 -Logfolderpath L:\SG1 -configurationonly -confirm:$False

Move-DatabasePath DRMBX1\SG1 \Store1 -edbfilepath S:\SG1\DB1.edb -ConfigurationOnly -Confirm:$False

d. Finally before mounting the DB we must set it to allow it to be overwritten during a restore as follows:

Set-MailboxDatabase DRMBX1\SG1 \DB1 -AllowFileRestore:$True

e. Now that the database is clean, you can mount the store:

Mount-Database DRMBX1\SG1\DB1

f. The database is now restored and available for use. All we have to do now is ensure that the users know where to access it. This is done by pointing the users to the mounted database on the SCR server.

Get-Mailbox -Database EXMBX1\SG1\DB1 where {$_.ObjectClass -NotMatch '(SystemAttendantMailboxExOleDbSystemMailbox)'} Move-Mailbox -ConfigurationOnly -TargetDatabase DRMBX1\SG1\DB1

Having completed the above steps the next stage is to test that users can now access mail again. It should be noted that they will have to exit and re-open Outlook for the setting to take effect. If the user is running Outlook 2007, their profile will automatically point to the new server name. If they are running Outlook 2003, the server name in the profile might need to be changed.