Tuesday, September 19, 2006
The Exchange database store may not mount in Exchange Server 2003 or in Exchange 2000 Server, and event IDs 9175, 486, 455, 413, and 5 may be logged
When you try to mount a database on a server that is running Microsoft Exchange 2000 Server or on a server that is running Microsoft Exchange Server 2003, you may receive the following error message:
An internal processing error has occurred. Try restarting the Exchange System Manager or the Microsoft Exchange Information Store service, or both.
ID no: c1041724
Exchange System Manager
Additionally, the following events may be logged in the Application log:
Event Type: Error
Event Source: MSExchangeSA
Event Category: (14)
Event ID: 9175
Description: The MAPI call 'OpenMsgStore' failed with the following error: The Microsoft Exchange Server computer is not available. Either there are network problems or the Microsoft Exchange Server computer is down for maintenance. The MAPI provider failed. Microsoft Exchange Server Information Store ID no: 8004011d-0526-00000000
Cause 1
Error 1811 corresponds to JET_errFileNotFound. This issue may occur in an Exchange log file that has a mismatching signature and LGeneration. Typically, the Exchange log file is the E00.log file. If the E00.log file has a mismatching signature, the information store might not mount even if the database is consistent. To resolve this issue, see the "Resolution 1" section.
Cause 2
This issue may occur if an antivirus program quarantines or deletes the current Exchange log file. To resolve this issue, see the "Resolution 2" section.
Cause 3
This issue may occur if the eseutil /p command was run on the affected databases and if the log files were not removed. To resolve this issue, see the "Resolution 3" section.
Cause 4
This issue may occur if you run the following command with an incorrect logfile base name, as in the following example:
eseutil /r three-character logfile base name
To resolve this issue, see the "Resolution 4" section.
Resolution 1
To resolve this issue, run the eseutil /mh command on all available databases in the corresponding storage group. If all databases are consistent, run the eseutil /ml command on the E00.log file. If there is a signature mismatch between the E00.log file and the recorded log signature in the database (eseutil /mh output), follow these steps:
1. Save your current log files.
2. Delete the E00.log file. When you mount the information store, a new E00.log file that has the correct signature and LGeneration is generated.
3. If you still cannot mount the information store, delete all transaction logs. These files include the Exx.log files and the Exxnnnnn.log files.
Resolution 2
1. Examine the configuration of the antivirus program. a. Make sure that the antivirus program is not configured to scan the Exchange Server directories.
b. By default, some antivirus programs are set to scan drives and directories weekly in a manual mode or in an automatic mode. This setting may be easily overlooked. Make sure that you add the Exchange Server directories to the excluded locations for the antivirus program. For more information about how to configure antivirus programs to work together with Exchange, click the following article number to view the article in the Microsoft Knowledge Base: 823166 (http://support.microsoft.com/kb/823166/) Overview of Exchange Server 2003 and antivirus software
2. Review the log files of the antivirus program to verify whether the Exchange log file was quarantined or deleted.
3. Use one of the following methods to recover the Exchange log file.
Method 1: If the Exchange log file was quarantined
If the Exchange log file was quarantined, follow these steps:
a. Recover the Exchange log to the folder that contains your production log files.
b. Start the Microsoft Exchange Information Store service. If no other log files are missing, the database mounts. If other log files are missing, see if the missing log files are located in the quarantine folder of the antivirus program. If the log files are not located in the quarantine folder, follow the steps that are described in the "Method 2: If the Exchange log file was deleted" section.
Method 2: If the Exchange log file was deleted
If the Exchange log file was deleted, you must restore the Storage Group database from a backup. Then, you must play through the log files. If you cannot restore the database from a backup, see the "Method 3: If you cannot restore the database from a backup" section. To restore an available database, follow these steps:
a. Move all inconsistent databases to a backup folder.
b. If a new E00.log file was created, move the new E00.log file to the backup folder. Additionally, move the E00.chk file to the backup folder.
c. Copy all existing log files to the backup folder.Note You must copy the log files. Do not move the log files.
d. Rename the last E00*.log file to E00.log.
e. Restore the database from a backup. Then, replay the log files. This brings the database to a consistent state. However, the database does not include the E00.log file that was copied to the backup folder. Although there is some data loss, you now have a database that can be mounted.
f. Start the Microsoft Exchange Information Store service.
Method 3: If you cannot restore the database from a backup
If you cannot restore the database from a backup, you must run repair utilities against the database to bring the database to a consistent state. Then, follow the steps that are described in the "Method 2: If the Exchange log file was deleted" section.
Resolution 3
To determine whether the eseutil /p command was run, follow these steps:
1. Click Start, click Run, type cmd, and then click OK.
2. Type the following at the command prompt: c:\program files\exchsrvr\bin\eseutil /mh "c:\program files\exchsrvr\mdbdata\name of Exchange database.edb"Note This example assumes the following: • The Exchange Server program files were installed in the c:\program files\exchsrvr folder.
• Your database is in the c:\program files\exchsrvr\mdbdata folder.
3. Read the repair count attribute. If the repair count attribute is 0 (zero), the eseutil /p command was not run. If the repair count attribute is a number other than 0, the eseutil /p command was run on the database.
If the public and private databases are in a consistent or clean shutdown state, you can move the transaction log files to another folder. To determine whether the databases are in a consistent or clean shutdown state, follow these steps:
1. Click Start, click Run, type cmd, and then click OK.
2. To examine the private information store, type the following: c:\program files\exchsrvr\bin>eseutil /mh "drive:\program files\exchsrvr\mdbdata\priv1.edb"
3. To examine the public information store, type the following: c:\program files\exchsrvr\bin>eseutil /mh "drive:\program files\exchsrvr\mdbdata\pub1.edb"Note These examples assumes the following: • The Exchange Server program files were installed in the c:\program files\exchsrvr folder.
• Your database is in the c:\program files\exchsrvr\mdbdata folder.
4. Review the results of the consistency check. If a database is consistent (state = clean shutdown), all the log files have been committed to the information store. If the database is not consistent (state = dirty shutdown), the database may not be corrupted. The log files may not have been committed to the database yet.
5. If the state reports clean shutdown, move all the log files from all the mdbdata directories to a backup folder.
6. Mount the databases.
An internal processing error has occurred. Try restarting the Exchange System Manager or the Microsoft Exchange Information Store service, or both.
ID no: c1041724
Exchange System Manager
Additionally, the following events may be logged in the Application log:
Event Type: Error
Event Source: MSExchangeSA
Event Category: (14)
Event ID: 9175
Description: The MAPI call 'OpenMsgStore' failed with the following error: The Microsoft Exchange Server computer is not available. Either there are network problems or the Microsoft Exchange Server computer is down for maintenance. The MAPI provider failed. Microsoft Exchange Server Information Store ID no: 8004011d-0526-00000000
Cause 1
Error 1811 corresponds to JET_errFileNotFound. This issue may occur in an Exchange log file that has a mismatching signature and LGeneration. Typically, the Exchange log file is the E00.log file. If the E00.log file has a mismatching signature, the information store might not mount even if the database is consistent. To resolve this issue, see the "Resolution 1" section.
Cause 2
This issue may occur if an antivirus program quarantines or deletes the current Exchange log file. To resolve this issue, see the "Resolution 2" section.
Cause 3
This issue may occur if the eseutil /p command was run on the affected databases and if the log files were not removed. To resolve this issue, see the "Resolution 3" section.
Cause 4
This issue may occur if you run the following command with an incorrect logfile base name, as in the following example:
eseutil /r three-character logfile base name
To resolve this issue, see the "Resolution 4" section.
Resolution 1
To resolve this issue, run the eseutil /mh command on all available databases in the corresponding storage group. If all databases are consistent, run the eseutil /ml command on the E00.log file. If there is a signature mismatch between the E00.log file and the recorded log signature in the database (eseutil /mh output), follow these steps:
1. Save your current log files.
2. Delete the E00.log file. When you mount the information store, a new E00.log file that has the correct signature and LGeneration is generated.
3. If you still cannot mount the information store, delete all transaction logs. These files include the Exx.log files and the Exxnnnnn.log files.
Resolution 2
1. Examine the configuration of the antivirus program. a. Make sure that the antivirus program is not configured to scan the Exchange Server directories.
b. By default, some antivirus programs are set to scan drives and directories weekly in a manual mode or in an automatic mode. This setting may be easily overlooked. Make sure that you add the Exchange Server directories to the excluded locations for the antivirus program. For more information about how to configure antivirus programs to work together with Exchange, click the following article number to view the article in the Microsoft Knowledge Base: 823166 (http://support.microsoft.com/kb/823166/) Overview of Exchange Server 2003 and antivirus software
2. Review the log files of the antivirus program to verify whether the Exchange log file was quarantined or deleted.
3. Use one of the following methods to recover the Exchange log file.
Method 1: If the Exchange log file was quarantined
If the Exchange log file was quarantined, follow these steps:
a. Recover the Exchange log to the folder that contains your production log files.
b. Start the Microsoft Exchange Information Store service. If no other log files are missing, the database mounts. If other log files are missing, see if the missing log files are located in the quarantine folder of the antivirus program. If the log files are not located in the quarantine folder, follow the steps that are described in the "Method 2: If the Exchange log file was deleted" section.
Method 2: If the Exchange log file was deleted
If the Exchange log file was deleted, you must restore the Storage Group database from a backup. Then, you must play through the log files. If you cannot restore the database from a backup, see the "Method 3: If you cannot restore the database from a backup" section. To restore an available database, follow these steps:
a. Move all inconsistent databases to a backup folder.
b. If a new E00.log file was created, move the new E00.log file to the backup folder. Additionally, move the E00.chk file to the backup folder.
c. Copy all existing log files to the backup folder.Note You must copy the log files. Do not move the log files.
d. Rename the last E00*.log file to E00.log.
e. Restore the database from a backup. Then, replay the log files. This brings the database to a consistent state. However, the database does not include the E00.log file that was copied to the backup folder. Although there is some data loss, you now have a database that can be mounted.
f. Start the Microsoft Exchange Information Store service.
Method 3: If you cannot restore the database from a backup
If you cannot restore the database from a backup, you must run repair utilities against the database to bring the database to a consistent state. Then, follow the steps that are described in the "Method 2: If the Exchange log file was deleted" section.
Resolution 3
To determine whether the eseutil /p command was run, follow these steps:
1. Click Start, click Run, type cmd, and then click OK.
2. Type the following at the command prompt: c:\program files\exchsrvr\bin\eseutil /mh "c:\program files\exchsrvr\mdbdata\name of Exchange database.edb"Note This example assumes the following: • The Exchange Server program files were installed in the c:\program files\exchsrvr folder.
• Your database is in the c:\program files\exchsrvr\mdbdata folder.
3. Read the repair count attribute. If the repair count attribute is 0 (zero), the eseutil /p command was not run. If the repair count attribute is a number other than 0, the eseutil /p command was run on the database.
If the public and private databases are in a consistent or clean shutdown state, you can move the transaction log files to another folder. To determine whether the databases are in a consistent or clean shutdown state, follow these steps:
1. Click Start, click Run, type cmd, and then click OK.
2. To examine the private information store, type the following: c:\program files\exchsrvr\bin>eseutil /mh "drive:\program files\exchsrvr\mdbdata\priv1.edb"
3. To examine the public information store, type the following: c:\program files\exchsrvr\bin>eseutil /mh "drive:\program files\exchsrvr\mdbdata\pub1.edb"Note These examples assumes the following: • The Exchange Server program files were installed in the c:\program files\exchsrvr folder.
• Your database is in the c:\program files\exchsrvr\mdbdata folder.
4. Review the results of the consistency check. If a database is consistent (state = clean shutdown), all the log files have been committed to the information store. If the database is not consistent (state = dirty shutdown), the database may not be corrupted. The log files may not have been committed to the database yet.
5. If the state reports clean shutdown, move all the log files from all the mdbdata directories to a backup folder.
6. Mount the databases.
# posted by Tech Mania @ 11:51 AM 
