Tim McMichael

Navigating the world of high availability...

Get-storagegroupcopystatus = Initializing

Get-storagegroupcopystatus = Initializing

  • Comments 4
  • Likes

A question that I see a lot of, and causes come confusion out there, is why does get-storagegroupcopystatus report a status of initializing for replicated storage groups.  This status occurs when using any form of replication (LCR = local continuous replication / CCR = cluster continuous replication / SCR = standby continuous replication).

 

Some history...

 

In Exchange 2007 RTM there was no initializing status.  When the replication service was restarted for any reason, the replication service would display a status of healthy for each storage group.  The issue here is that the storage groups may not have actually been healthy.  It would be possible that two databases copies could be diverged, but this would not be detected until the first log on the source was generated, copied, inspected, and compared to the passive database instance.  While waiting for this to happen, the administrator is given a false sense that all is well because all instances by default were assumed healthy.

 

An example of how this is not the most desired approach can be seen with CCR installations.  In this configuration we'll assume there is a reason that the passive database copy was diverged from the active copy.  When the customer issues a move-clusteredmailboxserver, we are able to move the instance between the two nodes.  Since the replication service reported the instances as healthy, nothing prevented us from moving the resources between the two nodes.

 

The change...

 

In Exchange 2007 SP1 we took a change to the replication service to now display a status of initializing.  What initializing is telling the administrator is that:

 

  • The replication service has not received a notification to copy a log.
  • The replication service has not yet copied a log.
  • The replication service has not yet inspected a log.
  • The replication service has not placed a log out for replay and determined divergence information.

 

When the above criteria have been met the replication service will change the instances from initializing to either healthy or failed.  Here is an example of get-storagegroupcopystatus showing initializing status:

 

Name                      SummaryCopySt CopyQueueLeng ReplayQueueL LastInspecte
                          atus          th            ength        dLogTime
----                      ------------- ------------- ------------ ------------
2008-MBX3-SG1             Initializing  0             0
2008-MBX3-SG2             Initializing  0             0

 

Where I most commonly hear this question is in test labs where activities like move-clusteredmailboxserver do not work.  When storage groups are in an initializing state commandlets report that action cannot be taken because replication is failed.  It really is not about replication being failed but more that replication is in any other state but healthy.  Other conditions that we see the initializing state is post VSS backups of the passive database copies or when an replication instance is suspended and resumed.

 

Here is an example of a move-clusteredmailboxserver command results where storage group copy status is initializing:

 

Move-ClusteredMailboxServer : Continuous replication is in a failed, seeding, or suspended state on '2008-MBX3-SG1'. Move-clusteredMailboxServer cannot be performed if one or more of the server's storage group copies are in failed, seeding or suspended states.
At line:1 char:27
+ Move-ClusteredMailboxServer <<<<

 

To change replication to a healthy state I usually do one of two steps:

 

  1. Dismount and re-mount all databases -> this should hopefully cause log roll to occur and the replication service to replicate a log.
  2. Create test mailboxes in each store and send mail to them.  Mail flow will create log files.  If the mail flow is not significant enough to roll the logs, automatic log roll will occur at a later time even though the log file is not full.

 

Monitoring...

 

There are two reliable ways to monitor continuous replication status for initializing state. 

 

The first method is to run get-storagegroupcopystatus.

 

The second method is to use performance monitor and the "MSExchange Replication" performance object.  Under this object is a counter named "Initializing".  If the counter displays a value of 1 then the storage group instance is in initializing state.  If the counter displays a value of 0 the the storage group is not in the initializing state.  Below is an example of performance monitor showing databases in an initializing state moving from Initializing to Healthy.

 

image

 

Information on monitoring continuous replication can be found here -> http://technet.microsoft.com/en-us/library/bb629521.aspx

Comments
  • Tutorial: Secure journaling in Exchange Server 2007 Crash Course: Microsoft Exchange Server 2007 Unified

  • The thing about #2 is that you state automatic log roll should take care of it.  However, looking at the CCR documentation on Technet, CCR Log Roll occurs by default at 90 seconds.  When I have seen initializing issues, it can take a while before the initializing to go away but like you said, dismounting and mounting will fix it.

    After updating CCR to Rollup 5, I have not seen this issue anymore.  At least on my CCR it doesn't and another person I have talked with.

  • Outlook Live: Microsoft’s efforts towards living in the cloud How to troubleshoot performance issues

  • Recently there have been some questions about transaction log rolling and continuous replication.&#160;

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment