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.

Comments

Popular posts from this blog

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

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. 

Ports that need to be open on Firewall for Edge Transport servers

Ports that need to be open on firewall for Edge Server subscription with Hub Server to function properly: For Inbound traffic: SMTP - TCP port 25 (from Internet) SMTP - TCP port 25 (from Edge server to Hub server on internal network) For Outbound traffic: SMTP - TCP/UDP port 25 (from Edge to Internet) SMTP - TCP/UDP port 25 (from Hub to Edge server) LDAP for EdgeSync - TCP port 50389 (from Hub to Edge server) Secure LDAP for EdgeSync - TCP port 50636 (from Hub to Edge server) Since Edge server needs to communicate with Hub server it is important that it can resolve Hub transport servers by FQDN and Hub transport servers must be able to resolve Edge servers by its FQDNs. To accomplish this you need to either open 53 (DNS) port and configure internal network adapter to use internal DNS but as a security precaution I would suggest to enter DNS records for Edge servers on local DNS manually and to fill hosts file on Edge servers with FQDNs for Hub transport servers.