Continuous Replication Deep Dive White Paper is here...

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.

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

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...

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).

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

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.

Yes.

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

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!!

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