XADM: Information Store Fails to Start: 4294965882, FFFFFA7A, Event 177, 1081, and Others

The Microsoft Exchange Server information store may not start after restoration of an online backup. Information store utilities such as Isinteg and Eseutil also may not start. You may receive some or all of the following error messages: You may observe some or all of the following clusters of events in the Application Log:

When the service pack level for Windows NT changes, Exchange Server rebuilds its database indexes as a precaution against incompatibilities with the service pack. This reindexing occurs whether the service pack level is changed upward or downward.

In most cases, the index rebuild is virtually transparent and goes unnoticed. But if the computer name has also been changed along with the service pack level, the above symptoms may appear. The most common case in which this happens is during restoration of an online backup during single mailbox recovery procedures undertaken on a laboratory server.

To have consistent success with Exchange online restores, always target the Exchange restore procedure to a recovery computer running the same Microsoft Windows NT Service Pack as the computer the backup was taken from. For example, if the Exchange 5.5 server you backed up was running Windows NT 4.0 SP5, your recovery server must also run Windows NT 4.0 SP5.

These symptoms may also appear when no service pack revision has occurred, but computer names have changed, if both computers are running Windows NT 4.0 Service Pack 4.

IMPORTANT: Please read the entire "Resolution" section before proceeding. The steps to get to the defrag procedure are listed below.

This problem can be resolved by any one of the following three methods:

• Performing an offline defragmentation of the database (ESEUTIL /D
• Giving the current server the same name as the server from which the backup was originally taken. This may be inconvenient, as two servers with the same name cannot co-exist on the same network.
• Following the procedure outlined below:IMPORTANT: Perform the following steps in exact order, omitting none of them. While some steps may seem redundant, each one plays a vital role in successfully reindexing and avoiding the necessity to defragment the database or rename the server.
  
  WARNING: If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.
  
  
  1. After online restore, start the information store.
     
     NOTE: After restoration of an online backup, the first thing you should always do, not just in this case, is to start the associated database service. Running Eseutil or Isinteg, or otherwise tampering with any of the restored files or registry entries before starting the database service may make your database permanently unstartable and require another restoration of your full backup.
  2. Start Regedt32, and then locate the following registry key:
     
     HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\Restore in Progress
     Make sure that the "EDB Database recovered" value is 01, not 00. If this value is 01, it means that critical parts of the restore process have finished (specifically, the restored .pat files have been applied to the database) and it is safe now to remove the Restore in Progress key.
     
     If the flag is 01, save, and then delete the Restore in Progress key. If it is still 00, you must discover the cause before deleting the key.
     
     In the case of the symptoms described in this article, stopping ALL Exchange Server services, including the System Attendant, and then restarting the database service sets the flag to 01, unless there are complicating unrelated factors present. Verify that all services have actually stopped by typing net start at a command prompt.
     
     IMPORTANT: If the flag is 00 at this step, you must stop all services, restart the database service, and then recheck the key before proceeding to the next step, despite the fact that doing so may seem redundant, and even though the database service will likely fail the next start attempt anyway.
  3. Stop ALL Exchange Server services. Verify that all services have actually stopped by typing net start at a command prompt.
  4. Start the database service. It should fail with a 1011 error, indicating that you must patch the database. Patching is a normal operation that does not imply or suggest any damage or corruption.
     
     If you do not receive a 1011 or other event telling you to patch the database, you must troubleshoot the failure before proceeding to the next step.
  5. Run Isinteg -patch.
  6. Start the database service.