We have 2 mailbox servers with Windows 2008, running Exchange 2007 SP1, Update Rollup 5, Enterprise edition. We have created the mailstores on each server with the location name preceeding the Mailstore name (so names are unique), and both servers have all mailstores on their D drive, with consistent naming for them. One Mail server "ServerMX4" is in Melbourne, the other "ServerMX3" is in Adelaide. Latency is 15ms and our slowest link is 6Mbps. ServerMX4 has 800 mailboxes and 450Gb, and ServerMX3 has 1000 mailboxes and 700Gb I enabled SCR for the whole environment simply by performing the following commands; Code Snippet Get-StorageGroup -Server ServerMX3 | Enable-StorageGroupCopy -Standbymachine ServerMX4 Get-StorageGroup -ServerServerMX4 | Enable-StorageGroupCopy -Standbymachine ServerMX3 This all works fine - data is being replicated. But, how do we throttle the replication to only occur during after hours or weekends? The reason we have 6Mbps links is that we have many applications that are sensitive to packet latency, packet loss and slow links. We need to disable or reduce the bandwidth used by SCR to less than 512Kbps - how can we achieve this? Is there a way to set days of the week or hours of the day for replication?

Hi, Based on my research, we do not have parameters to control the time to replicate transaction logs or reduce the bandwidth after enabling SCR. The only commands which we can used to control log replication is Suspend-StorageGroupCopy and Resume-StorageGroupCopy. Log shipping is continuous from source to target. For more information regarding optimizing network for SCR, please refer to following article: http://technet.microsoft.com/en-us/library/cc164368.aspx Mike

In addition to what Mike said, I'd wonder why you'd want to do this? i.e. SCR is a site resilience solution as you know. If you set the days of the week for replication and you had a failure outside of these days, the SCR copy would be so out of date as to really be worthless as a backup.Neil Hobson, Exchange MVP

The reason we want to throttle the connection is mostly due to the initial propogation of the entire database during the transition from Exchange 2003 to Exchange 2007 - the transfer of almost 1.2Tb cannot be efficiently done over the Internet without stopping all other services for the entire organisation of nearly 2000 people in 68 sites. If we could limit this initial propogation to just weekends, then after that we would set it to out of hours for normal operations - this would be a great capability.The default Replay Lag Time is 24 hours. I understand this as that all logs are at least 24 hours old, and hence the SCR target is 0-24 hours behind the source. I see this as a benefit because if corruption or datadeletion of one storage group occurs, then there is potentially 24 hours to go to the Target and bring the database online before the deletion or corruption is replayed into the Target.As you point out, SCR is a site resilience solution, and therefore the target will not be on a 1Gbps or even 100Mbps link - the ability to specify the bandwidth or time for replication would be a very beneficial capability - particularly if the links are unused overnight and more data could be sent across them.I completely disagree with your belief that if a backup is out of date then it is really worthless as a backup. We have backups to tape too, but in the event of a problem, the time it takes to procure a new system, build it, configure it, patch it, and then start recovering data from tapeis considerably longer than the time it takes to bring back an SCR or LCR copy. If data in the LCR or SCR copy is even a week out of date, then it will still be 99% of data, and still enough for the business to get back to work. Backup systems using tapes are not taken every few seconds, and even if backups are taken every night, they are still up to24 hours out of date.

Hi Christian, From your description, your main concern is to seed the 1.2Tb database over Internet which may affect the Network efficiency. If I'm off base, please feel free to let me know. According to Continuous Replication Deep Dive whitepaper, for initial seed the database on SCR target, we have three options: 1. Automatic seeding An automatic seed produces a copy of a storage group's database in the target location. Automatic seeding requires that all log files, including the very first log file created by the storage group (it contains the database creation log record), be available on the source. Automatic seeding only occurs during the creation of a new server or creation of a new storage group and database. 2. Seeding using the Update-StorageGroupCopy cmdlet You can use the Update-StorageGroupCopy cmdlet in the Exchange Management Shell to seed a storage group copy. You can also use the Update Storage Group Copy wizard in the Exchange Management Console to seed a storage group copy. 3. Manually copying the offline database This process dismounts the database and copies the database file to the same location on the passive node. If you use this method, there will be an interruption in service because the procedure requires you to dismount the database. According to your situation, I suggest you use the third method to manually copy the offline database to target server. Mike

Hi Mike, We are also experiencing the same issue as outlined in the OP in this thread. However, I am more interested in the Suspend-StorageGroupCopy and Resume-StorageGroupCopy commands you have mentioned in your previous post. Am I correct in assuming that even if you suspend SCR, only the replay of logs into the standby database is suspended but the log shipping from the source to the target continues consuming bandwidth? Right now our SCR target server is dedicated to this purpose with no other online databases. So I shutdown that server as an emergency measure to give bandwidth priority to other applications using that network link. This works fine since I can turn it on again during after-hours until the initial seeding is complete. But if we decide to host additional mailboxes on that server in the future, turning off the server would not be an option. It would be nice to have a command to completely halt replication and turn it back on after-hours if there are any spikes in email replication traffic after the initial seeding is complete. Would these suspend and resume commands work for that purpose? Thanks