DOCUMENT:Q224977 20-JUN-2002 [exchange] TITLE :XADM: Store Fails to Start: 4294965882, FFFFFA7A, Event 177,... PRODUCT :Microsoft Exchange PROD/VER::5.0,5.5 OPER/SYS: KEYWORDS:exc5 exc55 ====================================================================== ------------------------------------------------------------------------------- The information in this article applies to: - Microsoft Exchange Server, versions 5.0, 5.5 ------------------------------------------------------------------------------- IMPORTANT: This article contains information about modifying the registry. Before you modify the registry, make sure to back it up and make sure that you understand how to restore the registry if a problem occurs. For information about how to back up, restore, and edit the registry, click the following article number to view the article in the Microsoft Knowledge Base: Q256986 Description of the Microsoft Windows Registry SYMPTOMS ======== 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: Error -1414 or 0xfffffa7a or 4294965882 (JET_errSecondaryIndexCorrupted) Error -1030 or 0xfffffbfa or 4294966266 or c8000406 or 3355444230 (JET_errAlreadyInitialized) Error -1032 or 0xfffffbf8 or 4294966264 (JET_errFileAccessDenied) You may observe some or all of the following clusters of events in the Application Log: Event ID: 172 Description: MSExchangeIS ((pid) ) The database engine is initiating index cleanup of database '' as a result of an NT version upgrade from to . Event ID: 177 Description:MSExchangeIS ((pid) ) Database '': The secondary index '' of table '' is corrupt. Please defragment the database to rebuild the index. Event ID: 1081 Description: Unable to recover the database because error 0xfffffa7a occurred after a restore operation. Event ID: 5000 Description: Unable to initialize the Microsoft Exchange Information Store service. Error 0xfffffa7a. . . . . . Event ID: 1080 Description: Unable to recover the database because error 0xc8000406 occurred after a restore operation. The database was already called. Event ID: 5000 Description: Unable to initialize the Microsoft Exchange Information Store service. Error 0xc8000406. . . . . . Event ID: 1081 Description: Unable to recover the database because error 0xfffffbfa occurred after a restore operation. Event ID: 5000 Description: Unable to initialize the Microsoft Exchange Information Store service. Error 0xfffffbfa. . . . . . Event ID: 145 Description: MSExchangeIS ((pid) ) The database engine could not access the file called \edb.log. Event ID: 1120 Description: Error 0xfffffbf8 initializing the Microsoft Exchange Server Information Store database. Event ID: 5000 Description: Unable to initialize the Microsoft Exchange Information Store service. Error 0xfffffbf8. CAUSE ===== 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. RESOLUTION ========== 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 ). This may take several hours for a large database. - 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" (without the quotation marks) 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" (without the quotation marks) 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" (without the quotation marks). 6. Start the database service. Additional query words: fffffbfa, fffffbf8, c8000406 ====================================================================== Keywords : exc5 exc55 Technology : kbExchangeSearch kbExchange500 kbExchange550 kbZNotKeyword2 Version : :5.0,5.5 Issue type : kbprb ============================================================================= THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY. Copyright Microsoft Corporation 2002.