ESEUTIL.EXE and ESE.DLL issues can commonly cause Exchange Server Data Protection Manager (DPM) 2007 replica inconsistencies. But those aren't the only reasons.
An Exchange information store can be marked as inconsistent if certain conditions occur. If you move an Exchange Server database or a set of log files to a new path, DPM won't know how to deal with the change and the database replica will become inconsistent.
Similarly, if you create a new database on your Exchange Server, DPM will report that your Exchange backups are inconsistent. This happens because DPM protects Exchange at the storage group level and all databases within that group share a common set of log files.
When you create a new database, you alter the storage group in which the database resides. It's possible to create a database in a new storage group without triggering an inconsistent state error, but DPM is usually configured to protect all of the storage groups on an Exchange server.
An unplanned cluster failover can also cause the replica to become inconsistent. When a failover affects Exchange Server databases, DPM reacts by flagging the replica as inconsistent.
Replica inconsistencies can also occur from careless administration. DPM performs daily consistency checks of its replicas, but you can also manually initiate a consistency check. Performing a manual consistency check forces the replica into an inconsistent state until the check completes.
General causes for replica inconsistencies
Any kind of network error can prevent a replica from being created or updated, leading to an inconsistent state. For example, power failures, an unexpected server reboot, a connection error or manually canceling the replication process can lead to an inconsistent replica.
Reasons for storage group replica inconsistencies include volume filter bitmap errors, problems with the Windows change journal or low disk space on a server that's being backed up.
A final issue can happen when you're applying DPM 2007 SP1. In this situation, the DPM agents running on your protected servers become invalid and need to be redeployed. It seems that the service pack also incorrectly registers the VSS writer, causing snapshots to fail. It also generates the following error code:
GetDifferentialSoftwareSnapshotMgmt3Interface () failed: (0x80004002).
To solve this, re-register the VSS writer by opening a Command Prompt window and entering the following command:
regsvr32 %windir%\System32\vss_ps.dll
To resolve a replica inconsistency, identify and fix its initial cause. But this alone won't fix the problem. To bring the replica back into a consistent state, wait until the next automated consistency check runs or run a manual consistency check. Keep in mind that this can take some time, especially if you're verifying the consistency of a large storage group or multiple storage groups.
About the author: Brien M. Posey, MCSE, is a five-time recipient of Microsoft's Most Valuable Professional (MVP) award for his work with Exchange Server, Windows Server, Internet Information Services (IIS), and File Systems and Storage. Brien has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. As a freelance technical writer, Brien has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal website at www.brienposey.com.
Do you have comments on this tip? Let us know.
Please let others know how useful this tip was via the rating scale below. Do you know a helpful Exchange Server, Microsoft Outlook or SharePoint tip, timesaver or workaround? Email the editors to talk about writing for SearchExchange.com.
