Skip to main content

Standby Continuous Replication (Part I)

One of the most interesting features of Exchange Service Pack 1 (in the time of writing still in Beta) is probably Standby Continuous Replication (SCR). In RTM version of Exchange Server 2007 Microsoft introduced Local Continuous Replication and Cluster Continuous Replication which are variations of SQL Server's Log shipping feature.

To enable more disaster-recovery situations/possibilities Microsoft introduced Standby Continuous Replication in its Service Pack 1 for Exchange Server 2007.

Characteristics that are distinguishing SRC from LCR and CCR (from Exchange Server SP1 Help):

SCR supports multiple targets per storage group. LCR and CCR support only one replication target per storage group (the passive copy).

SCR includes a built-in delay for replay activity, and allows enables an administrator to specify an additional delay. This is useful in a variety of scenarios. For example, in the event of logical corruption of an active database, the built-in and additional admin-configured delay could be used to prevent logical corruption of an SCR target database.

In the RTM version of Exchange 2007, rules are enforced so that in a continuous replication environment a log file is not deleted unless and until it has been backed up and replayed into the copy of the database. This rule is modified when using SCR. SCR (which introduces the concept of multiple database copies) allows log files to be truncated at the SCR source as soon as they are inspected by all SCR target machines. Log truncation at the SCR source server does not wait till all logs have been replayed into all SCR targets because SCR target copies can configured with large log replay lag times.

Unlike CCR and LCR, you cannot back up an SCR copy. When using SCR, the database headers for SCR copies are updated, and the log files are truncated, when supported backups are taken against the source storage group (or, in the case of LCR and CCR, when backups are taken against either the active or passive copies of the source storage group).

So, if you want to enable "log shipping" for one of Exchange's Storage Groups in your organization you need to go through one command and some prerequisites :)

Storage Group you want to "replicate" to the other Exchange server is on the server which is called Source server and can be:

  • Standalone mailbox server (with or without LCR enabled)
  • Clustered mailbox server in a single copy cluster
  • Clustered mailbox server in a CCR environment

The server where you want to replicate logs to is called target server. It can be one of the following:

  • A standalone mailbox server (without LCR enabled for any storage groups)
  • A node in a failover cluster where the Mailbox role is installed, but no clustered mailbox server has been configured in the cluster.

I will test SCR on clusters some other time and post it on my blog. I tested some of the possibilities already but I am not "satisfied" with results. I will post my discoveries on this later.

To enable Standby Continuous Replication you must run following command:

enable-storageGroupCopy BYPASS\WISHTOCOPYSG -StandByMachineName SCR -ReplayLagTime 0.0:0:0

There is a new parameter -StandByMachineName for enable-StorageGroupCopy command. This parameter is crucial and actually enables Standby Continuous Replication. I will explain other parameters in the second part of the SCR.

NOTE: If your logs and database on the source server reside on drive X:\ and drive Y:\ respectively, than you need to have drive X:\ and drive Y:\ on the target server too.

There is one error I got when I enabled SCR in my test environment. EventID 2074 from MSExchangeRepl source.

SCR enables share on Storage Group log folder and if this share is not created, as in my case, log shipping cannot start. So what I did is I copied 04d2dd45-743b-49c2-ab07-b87126f5d27e$ part of the error and created the share with that name on the source server myself.


Share permissions on Storage group log folder:

  • Exchange Servers -Read
Security permissions on Storage Group log folder:
  • Exchange Servers - Read

 

Reference articles:

  • Scott Schnoll, Microsoft's Senior Technical Writer, posted video series of SCR on MS Exchange Team blog. You can watch video series here.
  • To read more about Standby Continuous Replication click here.
Labels:

Comments

Post a Comment

Popular posts from this blog

Reason: [{LED=250 2.1.5 RESOLVER.GRP.Expanded; distribution list expanded};{MSG=};{FQDN=};{IP=};{LRT=}]

 If you got this error checking the mail flow for a distribution group, it means the distribution group is closed and only internal senders can send e-mail to this group. When outside user sends e-mail to this group you get  Reason: [{LED=250 2.1.5 RESOLVER.GRP.Expanded; distribution list expanded};{MSG=};{FQDN=};{IP=};{LRT=}] Set Delivery for this group to internal and external users and your problem will be solved. 
Read more

Netscaler vs Exchange 2019 "time out during ssl handshake stage

If you are using Citrix Netscaler as load balancer in front of Exchange 2019 server you must know this: Microsoft Exchange 2019 is secured by default and allows only TLS 1.2. Therefore default schannel settings are as follows (using IISCrypto tool from Nartac Software): While Citrix Netscaler offers following Cipher Suites: TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_RSA_WITH_DES_CBC_SHA TLS_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 TLS_DHE_DSS_WITH_DES_CBC_SHA TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA TLS_DHE_RSA_WITH_DES_CBC_SHA TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_RSA_EXPORT1024_WITH_RC2_CBC_56_MD5 TLS_DH_anon_WITH_DES_CBC_SHA TLS_DH_anon_WITH_AES_128_CBC_SHA TLS_DH_anon_WITH_AES_256_CBC_SHA TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA Now, you will fi...
1 comment
Read more

Apple iPhone Text responses go to wrong country code

A user wrote: Recently I went to Portugal and when I was there I bought a sim card and put it in my iPhone 11 Pro, with my primary e-sim still in it. When I got home to Australia, I deactivated the Portugal sim-card, deleted it and took the sim card out. Now when someone call me I respond with text, my iPhone changes the calling numbers country code to +31. I had the same problem. Despite turning "Dial assist" on/off, checking Country, Language and all the suggested stuff it did not work for me. What I did at the end was deleting country prefix from contact numbers --> Save --> Added country prefix again . It works now.
Post a Comment
Read more