The Microsoft Exchange Replication Service was unable to perform an incremental re-seed of the passive node

Details

Explanation

The alert indicates that the Microsoft® Exchange Replication service (MSExchangeRepl), after a failover, could not perform an incremental reseed of the passive node because the database on the active node has diverged from the copy on passive node when the passive node is restored. The issue could be caused by MSExchangeRepl events 2056, 2057, 2058, or 2081.

Incremental reseed must see the active log stream in order to perform its operation.

The Microsoft Exchange Replication service tries to perform an incremental reseed after a failover if the passive and active database copies for the specified storage group are not synchronized. An incremental reseed is performed to avoid a full reseed. The replication service then tries to resynchronize with the now active database.

Note   Incremental reseed cannot detect log file divergence until there is traffic to the storage group.

The causes related to this alert are listed below depending on the particular event that caused the alert:

• MSExchangeRepl 2056: The Exchange Replication service could not perform an incremental reseed of the passive node because the logs on the active node have diverged too widely from the logs on the passive node.

• MSExchangeRepl 2057: The Exchange Replication service could not perform an incremental reseed of the passive database copy because replication was suspended for the storage group specified in the event description. This event is caused when an incremental reseed must be initiated but the storage group copy is currently suspended.

• MSExchangeRepl 2058: The Exchange Replication service could not perform an incremental reseed of the passive node because the service encountered an error as specified by the error code in the event description.

• MSExchangeRepl 2081: The Exchange Replication service could not perform an incremental reseed of the storage group on the passive node because the service could not compare a required log file that is located on the active node with the log file of the same generation ID that is located on the passive node.

Generally, for all three events above, there are three conditions that can cause the databases to diverge:

• The active database was manually mounted after the failover because it was outside the auto-mount criteria but is still an acceptable version of the data. This would have to be explicitly done by the administrator. Such actions guarantee a reseed.

• The system experienced a split brain condition because of a software error or operator error.

  Note

  The Microsoft Cluster Services (MSCS) can usually avoid this condition. However, in rare cases, you can have this condition when both nodes think they are active and generate their own set of logs independently. Therefore, logs of the same name on each node will contain different content.

• The failure occurred when the active node could continue for a brief period although it was not outwardly available. This can occur when there are concurrent double failures on the networks and all traffic to the active node is prevented.

User Action

To resolve the issue, follow these steps depending on the event that caused the issue:

• If the alert is caused by MSExchangeRepl 2056, reseed the storage group copy on the passive node. Follow the steps outlined in this topic, How to Seed a Cluster Continuous Replication Copy.

• If the alert is caused by MSExchangeRepl 2057, the administrator can do the following:

  • Make sure that the specified storage group is configured to use the correct log files and databases.

  • Run the Resume-StorageGroupCopy cmdlet on the specified storage group. For detailed steps, see Resume-StorageGroupCopy.

• If the alert is caused by MSExchangeRepl 2058, follow one or more of these steps to resolve the issue:

  • Fix the error represented by the error code in the event description

  • If the new passive node cannot copy because divergence in the log stream of the storage group on the passive node is larger than the Lost Log Resilience (LLR), allow a lossy mount (that is, allow the copy to mount without all the log files). Run the Get-StorageGroupCopyStatus cmdlet from Exchange Management Shell to check the health status of the copy. For more information, see Get-StorageGroupCopyStatus.

  • Reseed the new passive node. The Exchange Replication service will automatically start to reseed the storage group on the passive node.

  For more information about LLR, see Planning for Cluster Continuous Replication.

• If the alert is caused by MSExchangeRepl 2081, perform a full reseed on the storage group of the passive node. For detailed steps, see the following topics:

  • How to Seed a Local Continuous Replication Copy.

  • How to Seed a Cluster Continuous Replication Copy.

For More Information

To search the Microsoft Knowledge Base articles based on criteria that generated this alert, visit the Search the Support Knowledge Base (KB) Web site.

To review Exchange 2007 event message articles that may not be represented by Exchange 2007 MOM alerts, see the Events and Errors Message Center.

If you are not already doing so, consider running the tools that Microsoft Exchange offers to help administrators analyze and troubleshoot their Exchange environment. These tools can help you make sure that your configuration is in line with Microsoft best practices. They can also help you identify and resolve performance issues, improve mail flow, and better manage disaster recovery scenarios. Go to the Toolbox node of the Exchange Management Console to run these tools now. For more information about these tools, see Toolbox in the Exchange Server 2007 Help.