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).
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.
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:
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:
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.
Information on monitoring continuous replication can be found here -> http://technet.microsoft.com/en-us/library/bb629521.aspx