Continuous Replication Deep Dive White Paper is here...
Published Jul 01 2008 04:25 PM 2,567 Views

Many of you have been wondering how continuous replication works in Exchange 2007.  The Continuous Replication Deep Dive whitepaper discusses how log shipping, log inspection, and log replay work within Exchange 2007.  In addition, the paper discusses the mechanics of how scheduled and unscheduled outages are handled in a continuous replication enabled environment.  A big thanks goes to Scott Schnoll, Becky Benfield, Ramon Infante, and Alex Wetmore for helping me put this paper together.  Check it out here: http://technet.microsoft.com/en-us/library/cc535020(EXCHG.80).aspx.

- Ross Smith IV

14 Comments
Not applicable
So I got very excited about SCR. I went ahead and set up a 2nd server with just the mailbox role. Enabled SCR on a couple of storage groups - great!

The limitations of having one database per SG didn't bother me - I do this anyway for performance reasons so I have about 24 storage groups and one database per SG.

So I continued on, and then all of a sudden I get:
Enable-StorageGroupCopy : The number of standby continuous replication targets on this computer has reached the limit: 5

WHAT?????

Are you kidding me? So you can only use SCR with 5 storage groups, and only one db per sg, so that means 5 databases total? This means pretty gigantic databases.

This is pointless for all but small shops, which likely don't have the budget or need to do SCR.  Do I need to think about doing CCR over a wan instead?

Am I missing something?
Not applicable
Sounds like you installed Standard Edition Exchange, rather than Enterprise Edition.  Upgrade to Enterprise, and you can have up to 50 SGs...
Not applicable
I'm hoping it's because I hadn't entered the product key yet (brand new install) - thanks!

Are there plans to allow backups of SCR targets?  Or should I look into doing CCR over the wan if I want to do that?
Not applicable
pesos,

Yes indeed - until you enter a product key, Exchange will be in let's call it "Standard" mode:

http://technet.microsoft.com/en-us/library/bb232170.aspx

"Even though Exchange 2007 and Exchange 2007 SP1 come in two edition offerings, these are licensing editions that are defined by a product key. There is a single set of binary files for each platform (one for x64 systems and one for x86 systems), and the same binary files are used for both editions. When you enter a valid license product key, the supported edition for the server is established. See "Evaluations and Product Keys" below for other important information about product keys."
Not applicable
Hi Pesos,

Glad you were able to correct your issue and allow for all of your storage groups to replicate to the SCR target.

At this time we are not providing a means to perform an Exchange aware backup for SCR targets in Exchange 2007.  What I highlighted in the paper (suspend replication, take backup, resume replication) is what you can do if you want to backup your SCR target copies.

Choosing to do SCR or geographically dispersed CCR requires a lot of thought and planning.  Things to keep in mind when doing geographically dispersed CCR:
1.  If using Windows 2003 as the base OS, you must span the subnet between the datacenters.  If using Windows 2008, you can use different subnets (but now you must deal with DNS replication).  Also, regardless of which OS you choose, you must span the AD site between the datacenters.
2.  Hub Transport and CAS placement.  You may have to move servers in and out of the AD site to ensure that the CMS only communicates with local HT and CAS boxes.  Otherwise, requests may go to either datacenter which could become a problem as latency and throughput will affect the experience (remember that both HT<->MBX and CAS<->MBX communication is RPC and it is not WAN optimized).
3.  Failovers/Handoffs.  Whenever you have to perform a hand-off (say for security patch) you now have to go out of your primary datacenter.  Failovers may not be automatic (depends on the why the failover is occuring and where the file share witness exists and whether it is accessible).
4.  Log replication cannot get behind.  If it does, then that storage group may not be able to mount (RTO hit) and a reseeding may be requiredo on the passive node if you manually mount the database.

Ross
Not applicable
Thanks Ross, those are all great points.  If SCR can be backed up manually by pausing/resuming, that sounds like a good option for me since we aren't really looking for failover, but more for a simply way to do periodic offsite backups without having to travel to the primary datacenter.

Thanks!!
Not applicable
Hi Ross, I looked at the white paper and I want to confirm -- what you meant above is that to back up an SCR target, I'd have to disable replication, stop the IS service on the SCR target, and then just back up the database and log files as flat files, rather than using some kind of exchange-aware backup?

thanks,
Wes
Not applicable
Yes.
Not applicable
Gotcha.  Does stopping the IS service suspend replication?  I'm thinking about scripting this, and wondering if that one step would be enough to free up the dbs/logs for backup.
Not applicable
Hi Wes,

Sorry I misread your earlier statement.  No you do not need to stop the information store on the SCR target.  You simply perform the following:

1. Suspend-StorageGroupCopy <identity> -StandbyMachine <SCRTarget>
2.  Take backup.
3.  Resume-StorageGroupCopy <identity> -StandbyMachine <SCRTarget>

Ross
Not applicable
fyi - all but one of my SGs were failing SCR replication with the following:

The Microsoft Exchange Replication Service encountered an error while inspecting the logs and database for EX1BAa_l on startup. The specific error code returned is: Microsoft.Exchange.Cluster.Replay.FileCheckLogfileMissingException: File check failed : Logfile 'D:exchsrvrMailboxBAa_lE0200000001.log' was not found.
at Microsoft.Exchange.Cluster.Replay.FileChecker.CheckLogfiles(Int64 minimumGeneration, Int64 maximumGeneration)
at Microsoft.Exchange.Cluster.Replay.FileChecker.RunChecks()
at Microsoft.Exchange.Cluster.Replay.ReplicaInstance.ConfigurationChecker(Object stateIgnored).




I noticed that the one that was working was the only SG that did not have an underscore in the name, so I created a couple more SGs without underscores in the name and moved mailboxes over to them - they are also working fine.  Is it possible that SCR replication breaks when underscores are in the name of the SG?  My DBs had no underscores, but dashes instead (which I removed when creating the new ones).
Not applicable
I posted this on the exchange forums and was told since these were existing storage groups you have to run suspend and then update in order to get the DB to create, since the first gen log file does not exist.  The others work because they're brand new SGs I guess...
Not applicable
Hope this is clear......

Is it possible to setup Exchange 2007 SP1 SCR replication
as below.

Site1         Site2
Server1                        Server2

SG1
 SG1DB>>>>----SCR----->>>>>SG1
          SG1DB
SG2
 SG2DB>>>>----SCR----->>>>>SG2
          SG2DB
SG3
 SG3DB<<<<<----SCR-----<<<<SG3
          SG3DB
SG4
 SG4DB<<<<<----SCR-----<<<<SG4
          SG4DB
Not applicable
Same question as dwilliamjoe.

What I think he means is since SCR is enabled on the SG (not on the whole server-node), can you have a server in each site servicing clients, and at the same time having a replicated copy of the SG from the server in the other site ? And vice versa.

So 2 servers, one in eacg site, each with their own SG, and that SG has a replicated copy on the other server.

This would mean that the standby Exchange server is no longer standby only, is also serves local clients. A better use of investment.

If this is possible, I'm sold. I'll be moving to 2007 before the end of this year.
Version history
Last update:
‎Jul 01 2019 03:38 PM
Updated by: