Tuesday, October 06, 2009

Exchange 2007 SCR How to - Part 1

All of this document is based on database portability offered in Exchange 2007 SP1 known as Standby Continuous Replication, or SCR. Microsoft's article is here: http://technet.microsoft.com/en-us/library/bb738132.aspx and one of the most overlooked items I felt in this document is this bit:
I I will get into more details on this below.
Before getting startedStorage group and database paths must match on the source and target. So D:\Exchange Databases\ for the EDBFilePath must be valid on both servers. Due to this, I recommend creating the folder/path structure on the source and target as you go and name everything really smartly so you know what logs you are looking at when you are in explorer. I typically use the two cmdlets below to make sure I have the info I need:
Get-StorageGroup -server EXCHANGESOURCE ft name,logfolderpath,systemfolderpath
Get-MailboxDatabase -server EXCHANGESOURCE ft name,edbfilepath
The System Folder path is recommended to be in the same folder as the log file path for uniformity as well as to reduce the risk of missing it in this step of having to type the default location of C:\Program Files\Microsoft\Exchange Server\Mailbox\Storage Group.
Also, only one database per storage group is supported for SCR log shipping to work and replay logs on the SCR target.
I recommend putting each .edb file into a separate sub folder as well because you later (in eseutil) need to specify the database directory (not path to EDB) to replay logs, and it’s a little intimidating if you have 4-5 edb files in the same directory.
Seeding the databases
Enable-StorageGroupCopy -StandbyMachine EXCHANGETARGET -Identity "EXCHANGESOURCE\ExecSG" -ReplayLagTime 0.1:0:00 -TruncationLagTime 0.2:0:0

Those day/time formats are in day.hour:minutes:seconds format - leaving one or two zeroes does not matter for hour/day/time.

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 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. The Microsoft default for this is 0, however.
You may receive this warning:
WARNING: ExecSG copy is enabled but seeding is needed for the copy. The storage group copy is temporarily suspended. Please resume the copy after seeding the database.
Get-StorageGroupCopyStatus -StandbyMachine EXCHANGETARGET
Will show the SCR replication status, including copy queue length and a suspended status because the DB is not there yet. If not suspended, suspend with:
Suspend-StorageGroupCopy -Identity "EXCHANGESOURCE\ExecSG" -StandbyMachine EXCHANGETARGET
Now, on EXCHANGETARGET, we can seed the database.
Run EMS as administrator, or these will error with "Access to the path (edbfilelocation)\temp-seeding is denied"
Update-StorageGroupCopy -Identity "EXCHANGESOURCE\Executive Staff Storage Group" -StandbyMachine EXCHANGETARGET
This will then seed the data:

If you receive the following error:
Database Seeding Error: Error returned from an ESE function call (0xc7ff1004), error code (0x0).
You need to enable and allow Windows Powershell as a program in Windows firewall.
Once the seeding is completed, the suspend operation should automatically resume. If it does not, you can manually do this with:
Resume-StorageGroupCopy -Identity "EXCHANGESOURCE\ExecSG" -StandbyMachine EXCHANGETARGET
Confirming that the Database seed is healthy
From the SCR source:
Get-StorageGroupCopyStatus -StandbyMachine EXCHANGETARGET
From the SCR target:
Get-StorageGroupCopyStatus -server EXCHANGESOURCE -StandbyMachine EXCHANGETARGET
This outputs something like:
NameSummaryCopyStatus CopyQueueLength ReplayQueueLength LastInspectedLogTime
ExecSGHealthy 0118710/6/2009
Obviously, "Healthy" is what you want to see here. If there are NotConfigured, they are either not configured, OR you left the -standbymachine off! If you have errors, check your application event logs, ensure the folder structure is correct and read the next step below.
CopyQueueLength is the number of transaction logs waiting to be shipped. If this number is commonly growing, your WAN connection may not have sufficient bandwidth.
ReplayQueueLength is the number of logs in the SCR target's log directory waiting to be replayed. This number will increase continually until a full backup is taken on the SCR source, at which point the SCR target "replays" these logs and commits them to the EDB on the target server. It is important to know there is a hard coded lag of 50 log files that cannot be changed.
Last InspectedLogTime shows the data and time of the last log inspected on the SCR target. The time usually is … in powershell, so run something like:
Get-StorageGroupCopyStatus -StandbyMachine EXCHANGETARGET | ft name, LastInspectedLogTime
Additionally, from the SCR target, you can run test-ReplicationHealth to troubleshoot any issues with SCR. This cmdlet does not work from the source server and errors that LCR (local continuous replication) is not configured. It also accepts a -verbose argument which displays a lot more detail.
Continue reading Part 2 which includes failover and failback as well.


Unknown said...

Nice post on SCR. Keep it up!

seanw said...

Wow, I wish I had read this post earlier while setting up SCR! Reading the technet articles and even watching Scott Schnoll's 5-part video series doesn't properly cover the practical side of SCR setup, which you've done very nicely here. Excellent!

Also, one question. You wrote, "...until a full backup is taken on the SCR target..." Didn't you mean until a full backup is taken on the SCR SOURCE (not target) since it is not possible to backup an SCR Target? ("Unlike CCR and LCR, you cannot back up an SCR copy. " -- http://msexchangeteam.com/archive/2007/06/28/445538.aspx)

Chris Lehr said...


Thanks for the compliments AND for catching that error - fixed now so nobody attempts to backup their target - that wont flush any logs since there isnt a database mounted there!

Unknown said...

Great post! I am setting up a SCR in my environment and have a couple of questions.
1.Does the Enable-StorageGroupCopy command actually copy the Data from the source server to the target server? I'm a little confused on the difference between this command and the Update-StorageGroupCopy command.
2.Is there anyway to control how much bandwidth the copy uses across a link?
3.does it matter which server these commands are run from?

Chris Lehr said...


1) Enable-StorageGRoupCopy does NOT actually copy - just enables it. Due to the size of some mailbox store, the update-storagegroupcopy is the way to seed. You could also manually seed the database by copying the EDB over prior.
2) Not really within Exchange. You could do some QoS over the wire.
3) Sometimes. For the most part every command can be run from either server, but the parameters change since you must specify source/target if it is not given by the commands in my post.

Unknown said...

Thanks for the info. I'd like to ask a couple of more questions.
1. can the source server be the passive node of the CCR?
2. I'm a little worried about the exchange sed process taking up all the bandwith from other resources. I would like to just use the Update-StorageGroupCopy however is copying the data to an external drive a common pratice for starting a SCR. Hope that makes sense.
3. When I'm installing Exchange on the SCR Server, i install the mailbox role however I'm unsure which options I should choose. Can you give me some guidance on that?
Thanks again for your help.

Chris Lehr said...

1) I don't think so
2) You can't use that cmdlet to copy to a USB. However, you can stop your store, copy the EDB to USB, and put it on your DR server, then seed from that.
3) Depends on too many things to really answer and be correct. If you want to engage for a design project, email me@chrislehr.com

TK said...

Hi Guys,
There are a lot of articles out there on SCR. Thanks for producing a clearly written one. I had just finished seeding a Target but was not using the correct syntax for the Get-StorageGroupCopyStatus command to verify my results. Your article pointed out the different ways to run that command dependng on whether you're on the Source or the Target. What a relief to see I had a Healthy status afterall and not a Disabled one.

One question. You say:
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. The Microsoft default for this is 0, however.

Does this refer to a scenario where after having an issue with your Source you might want to forego using SCR failover completely, and instead elect to resort to a tape restore on the Source? And if so in that case does having un-deleted log files handy on the Target be of help?