I won`t try to explain what Exchange Server 2007 SCR is, if you are reading this you probably know what you want, but you`re not sure how to do it properly. I read lot of documentation on Exchange Server 2007 SCR but haven`t been able to find accurate and detailed “how to” for this “poor man`s failover” option. After more than few hours of reading and testing, here is my tutorial for Exchange 2007 SCR.
For this LAB I used following setup:
2x Windows Server 2008 R2 DTCNTR SP1 (Server named DC is domain controller while PC1 is just server attached to domain.)
2x Exchange Server Enterprise 2007 SP3 (Both installations with Mailbox, CAS and Hub transport roles)
1x Windows 7 Pro x64 (with installed Outlook 2007 SP3)
Server DC is source server and it has Exchange 2007 Server Storage Group named SG and database named DB
PC1 is target server with has Exchange 2007 Server Storage Group named SGPORT and database named DBPORT
In this scenario I`ll be configuring SCR on two separated servers without any clustering connections between them.
If you want to know more about Exchange Server 2007 SCR look here:
http://technet.microsoft.com/en-us/library/bb676465.aspx
http://technet.microsoft.com/en-us/library/bb738132.aspx
Configuring SCR:
On both servers (source and target) there`ll be same path to DB, Log Files and System Files.
C:\ExchangeLog
C:\ExchangeDB
Try to avoid spacing or special characters in naming of your Exchange directories and database since you`ll have issue or two when executing commands in shell.
So, both servers have same path for DB and Logs
Here is procedure of creating Storage Group and Database for source server – DC.
Storage Group
Server Configuration | Mailbox | Database Management | Right click – New Storage Group | Define name – in my case SG, choose directories for Logs and System Files, in my case C:\ExchangeLog for both | New
Finish
New Database:
Server Configuration | Mailbox | Database Management | Right click on created storage group – New Mailbox Database |Name of database – DB, path C:\ExchangeDB | New
Finish
We need to create same directory structure on target server (PC1) but these directories need to be empty, no DBS or LOGs in them. If there is something in these directories command that we`ll use later -> Enable-StorageGroupCopy won`t pass.
To recap current situation:
Server DC – Storage Group Name: SG, Database Name: DB
Server PC1 – Storage Group Name: – , Database Name: –
Activation of SCR:
Command for activating SCR:
(I don`t have to mention that you`ll need to change names “DC”, PC1” and “SG” to names of your servers, storage groups.)
Enable-StorageGroupCopy DC\SG -StandbyMachine PC1 -ReplayLagTime 0.00:02:00 -TruncationLagTime 0.00:02:00
Needs to be run from source server (DC in my case)
Explanation for commands:
ReplayLagTime -> ReplayLagTime is the time that the target server will wait to replay a log file into the EDB. Above, it is set to 1 hour. If not specified, the default is 24 hours. While this may work – it can mean replaying a lot of logs, so a lower setting is preferred. There is a hard coded lag of 50 files here. This means you will always see the ReplayLagTime as at least 50 when running Get-StorageGroupCopyStatus
TruncationLagTime -> TruncationLagTime is the time that the SCR target will delay deleting a replayed log. This is helpful if there was ever an incident where restoring from backup had to be performed, and the replayed log files from an SCR source could be used to shorten the gap between backup and moment of failure.
We`ll now check health of copy. Under SummaryCopyStatus there has to be Healthy if everything is ok.
Get-StorageGroupCopyStatus DC\SG -StandbyMachine PC1 | fl
Logs are now synced between DC (source) and PC1 (target) servers. DB directory on PC1 is still empty. Next step will be to seed DB from DC to PC1.
But before seeding DB We`ll create new Storage Group and DB on PC1. Storage Group Name: SGPORT and DB name: DBPORT. Both Logs and DB MUST BE PLACED IN SEPARATE DIRECTORY.
We`ll create two new directories for SGPORT and DBPORT – C:\ExchangeDBPort and C:\ExchangeLogPort
After creating new DB named DBPORT, we`ll have to dismount it.
Why this step? Because when we come to step of failover, we won`t be able to do it to the groups with same name on other server.
Seeding DB from source (DC) to target (PC1) server:
Once again, directories (in my case ExchangeDB and ExchangeLog) on target server need to be empty. If directories are not empty seeding won`t pass.
I also deleted logs transferred during SCR activation.
First we need to temporary stop SCR:
Suspend-StorageGroupCopy -Identity DC\SG -StandbyMachine PC1
Check the status of SCR
Get-StorageGroupCopyStatus DC\SG -StandbyMachine PC1 | fl
Let’s start seeding procedure.
Procedure has to be started from target server (in my case PC1)
Update-StorageGroupCopy -Identity DC\SG -StandbyMachine PC1
I got error:
I forgot to add exception to firewall. After adding Windows Powershell to firewall exception, everything pass ok.
After configuring firewall everything went ok
Checking ExchangeDB and ExchangeLog directories on target server after executing command
Everything is copied from DC, except logs named E00 and .jrs.
Now we need to resume SCR
Resume-StorageGroupCopy –Identity DC\SG -StandbyMachine PC1
Checking status of SCR
Get-StorageGroupCopyStatus DC\SG -StandbyMachine PC1 | fl
Now we`ll check health of seed source -> target server from source server (DC).
Get-StorageGroupCopyStatus -StandbyMachine PC1
And vice versa. Add –server DC switch to command.
Everything is OK.
Next command is:
Test-ReplicationHealth
On source server (DC) I also started command for checking log status on target server (PC1)
Get-StorageGroupCopyStatus -StandbyMachine PC1 | ft name, LastInspectedLogTime
Failover from source to target:
I`ll simulate failover with dismounting of currently active database.
In my case it`s DB on source server DC.
Dismount-Database DC\SG\DB
DB is dismounted
Client also lost connection with Exchange Server.
Next command that we need is:
Restore-StorageGroupCopy DC\SG -StandbyMachine PC1
I got this error:
This error is expected, since I don`t have any kind of cluster configured, and it is impossible to copy all the logs.
I`ll add –force parameter to command
Logs directory on DC looks like this
While log directory on PC1 looks like this
E00 and .jrs logs are still missing.
We`ll check status of database once more. First on DC. This step is not necessary, so you can skip it, but I`ll do it since I just dismounted the DB.
eseutil /mh C:\ExchangeDB\DB.edb
DB has to be in Clean Shutdown state.
Now I`ll check status of DB on target server (PC1).
DB is in Dirty Shutdown State. That is normal, since I`m missing log file (E00).
First I`ll check log consistency
Eseutil /ml C:\ExchangeLog\E00
All is ok.
Now, I`ll look for .chk files in log directory. I found E00.chk and deleted that file. This is necessary, because if there are .chk files in log folders, repair command wouldn`t work.
Next command is as follows
Eseutil /r E00 /l C:\ExchangeLog /s C:\ExchangeLog /d C:\Exchangedb
After that check of the DB status
Clean shutdown.
Next command will refresh AD with new path for Storage Group and DB files. Now previously created SGPORT and DBPORT enter the game. Following commands will change path of temporary SGPORT and DBPORT to production SG and DB.
Move-StorageGroupPath PC1\SGPORT -SystemFolderPath C:\ExchangeLog -LogFolderPath C:\ExchangeLog -ConfigurationOnly
Move-DatabasePath PC1\SGPORT\DBPORT -EdbFilePath C:\ExchangeDB\DB.EDB -ConfigurationOnly
For temporary DB named DBPORT option –AllowFileRestore should be configured, so we`ll be able to overwrite it.
Set-Mailboxdatabase PC1\SGPORT\DBPORT -AllowFileRestore:$true
Now, let’s check the settings on PC1 for Storage Group. Storage Group path for SGPORT changed to production directory.
And temporary DB named DBPORT changed path from this:
To this:
So we copied logs and DB, checked status of DB and we`re ready for mount.
Mount-Database PC1\SGPORT\DBPORT
DB won`t mount if you have DB in dirty shutdown state. You need to have a DB in clean shutdown state in order to be able to mount it.
Look at the Management Console
And at last, check on client PC
Still disconnected.
When I look into mailbox properties of user I see that user is still trying to mount DB from source server, which is now dismounted.
In order to change that, enter following command
Get-Mailbox -Database DC\SG\DB |where {$_.ObjectClass -NotMatch '(SystemAttendantMailbox|ExOleDbSystemMailbox)'}| Move-Mailbox -ConfigurationOnly -TargetDatabase PC1\SGPORT\DBPORT
After that I checked properties of user mailbox once again. OK
Checking client PC and restarting Outlook 2007
And that’s it. If you want to bring back DB to source from target, repeat procedure in opposite direction.