If you ever worked with Exchange 5.5, you probably recall that Exchange Server was finicky when it came to mounting
databases. And when you had a problem, they were notoriously difficult to fix.
Things improved with Exchange 2000 and even more with Exchange 2003. But even so, there are still things that can occur that will prevent Exchange from mounting databases properly. In this article, I will discuss five potential causes of and solutions to database mounting problems.
Potential problem #1: Exchange has insufficient rights
One common database mounting issue is that the database won't mount if the SeSecurityPrivilege right has been modified. If this is the case, you might receive one of the following messages in the Application event log:
Process MAD.EXE (PID=1088). All Domain Controller Servers in use are not responding:
The Metabase Update service failed to start, error '80040a01.'
Unexpected error. An unknown error has occurred. ID no: 80040a01 Microsoft Exchange System Attendant occurred.
Error 0x80004005 starting database "First Storage
GroupMailbox Store(EXCHANGE1)" on the Microsoft Exchange Information Store.
Failed to configure MDB. The Microsoft Exchange Information Store service could not find the specified object. ID no:c1041722.
Failed to replicate the security descriptor to the metabase. Users may not be able to read or write data to the metabase. Error code is 8000500d.
The Directory Service Referral interface failed to service a client request. RFRI is returning the error code:[0x3f0].
Error 0x80004005 connecting to the Microsoft Active Directory.
A fatal error occurred reading a value from the directory. No MTA name was found. Contact Microsoft Technical Support. [MTA MAIN BASE 1 12] (16)
How to fix the problem. When you initially install Exchange into a domain, or when you run the Exchange Setup program in Domain Prep mode, the Exchange Enterprise Servers group is assigned the SeSecurityPrivilege right. If this right is removed, then Exchange will stop working either the next time an Exchange Server is restarted or when the Kerberos security refresh interval expires.
To fix the problem, you can either manually assign the necessary permission or you can run Exchange Setup in the Domain Prep mode. You can access full instructions here.
Potential problem #2: Hardware problem
If you see event ID number 474 in the event logs, it is a good indication that the database is corrupt. This event is usually accompanied with a description similar to this one:
Information store "2680" the database page read from the file "C:Program FilesExchsrvrmdbdatapriv1.edb" at offset 4050944 (0x00000000003dd000) for 4096
(0x00001000) bytes failed verification due to a page checksum mismatch. The expected checksum was 1537063750 (0x5b9dbb46) and the actual checksum was 1536998214 (0x5b9cbb46).
The read operation will fail with error - 1018 (0xfffffc06).
If this condition persists then please restore the database from a previous backup.
How to fix the problem. Although there are several potential causes of database corruption, this message often points to a hardware failure at the hard disk level. If you suspect that a hard disk issue is to blame, then you can replace or reformat the hard disk and restore your Exchange databases from backup. If you want your users with mailboxes on the malfunctioning server to have access to e-mail in the meantime, you can always temporarily move their mailboxes to a different server. In doing so, they won't be able to access their old mail, but they will be able to send and receive new mail. You can read more about this issue at: http://support.microsoft.com/?id=327334.
Potential problem #3: Antivirus software deletes or modifies transaction logs
Although having good antivirus protection on your Exchange Server is crucial, there are some folders that should not be scanned. One such folder is the one containing the transaction logs.
Reason: All inbound messages (infected or not) are written to the transaction logs when they arrive. If your antivirus software is set to scan the transaction logs folder, then it might detect a virus signature and attempt to alter or delete the transaction log, which will cause Exchange to crash. When this occurs, the Exchange System Manager might generate an error message saying: An internal processing error has occurred. Try restarting the Exchange System Manager or the Microsoft Exchange Information Store service, or both.
Additionally, the event log might display an Event ID 455 (Information Store (1892) b2a6f816-2baf-462e-918c-eda5d1fb24d3: Error -1811 (0xfffff8ed) occurred while opening log file C:\Program Files:\Exchsrvr\mdbdata\E00.log) or an Event ID 9518 (Error Current log file missing starting Storage Group /DC=COM/DC=EXAMPLE/CN=CONFIGURATION/CN=SERVICES/CN=MICROSOFT EXCHANGE/CN=FIRST ORGANIZATION/CN=ADMINISTRATIVE GROUPS/CN=FIRST ADMINISTRATIVE GROUP/CN=SERVERS/CN=COMPUTERNAME/CN=INFORMATIONSTORE/CN=FIRST STORAGE GROUP on the Microsoft Exchange Information Store. Storage Group -- Initialization of Jet failed.).
How to fix the problem. Make sure that your antivirus software is set not to scan the installable file system. For additional information about this issue, check out http://support.microsoft.com/?id=819553.
Potential problem #4: Active Directory service permissions are modified
The Exchange Information Store can fail to mount if the machine account no longer has rights to read the Information Store. This can occur if the machine has been removed from the Exchange Domain Servers group, or if the server's permissions have been altered (inherited rights removed or an explicit deny assigned).
You may also experience the problem if the server object no longer exists in the Active Directory. The primary symptom of this problem is event number 7024 accompanied by a message indicating that the information store service terminated with a server specific error number 0.
How to fix the problem. Run Exchange Setup in DomainPrep mode. You might also run ADS Edit to make sure that the CN=InformationStore,CN=ServerName,CN=Servers,CN=AdminGroupName,CN=Administrative Groups,CN=ExchangeOrgName,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=DomainName, DC=com object exists. The full solution to this problem can be found at http://support.microsoft.com/?id=283179.
A similar issue can occur if read access to the WellKnown Security Principals container has been removed. If this is the issue, though, the Event Log will display Event ID number 5000. The description will be unable to initialize the Microsoft Exchange Information Store service. Error 0x8004010f. To fix the problem, you will have to use the ADSI Edit utility to give Everyone Read access to the WellKnown Security Principals container. You can get the full instructions for doing so at http://support.microsoft.com/?id=318098.
Potential problem #5: The Exchange databases exceed the 16 GB size limit
Exchange Server 2000 and 2003 Standard Edition have a 16 GB limit to the size of the database. As soon as a database reaches 16 GB, the database is shut down to prevent any more data from being inserted into it.
The description of the error in the event log may be a bit misleading. The event log indicates that PRIV.EDB has exceeded the 16 GB limit. In reality, this message will be triggered if any database exceeds the size limit. Furthermore, even if the PRIV.EDB file is to blame, it's possible for you to get this message even if PRIV.EDB is below the 16 GB limit. That's because Exchange looks at the database size, not the file size. The database is made up of PRIV.EDB and PRIV.STM. If the combined total bytes in these two files exceed 16 GB then the error will be triggered.
How to fix the problem. You should temporarily increase the size of the database and then remove unwanted data. Functionality for doing so is built into Exchange Server 2003, but you will need to apply Service Pack 3 and the September 2003 Post Service Pack 3 Roll Up to Exchange Server 2000 before you will be able to perform this operation.
The basic idea is that you can stop the SMTP service to prevent new mail from coming in during the repair operation. You can then modify the registry to set the maximum database size to 17 GB. This will allow you to mount the database. You must then delete some data from the database to get it below the 16 GB limit.
Applying quotas is a good way to help accomplish this. You can also modify the retention time for deleted items. Finally, modify the registry so that the database size is set back to 16 GB and then turn the SMTP service back on. Don't try to leave the maximum database size set to 17 GB. If you do and the database reaches 17 GB in size, then there is no way to fix the problem. Full instructions for this fix are provided at http://support.microsoft.com/?id=828070.
In tomorrow's tip, I will talk about five more potential causes of database mounting problems and suggest ways to solve them.
Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. Brien has served as the CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer, he has written for Microsoft, CNET, ZDNet, Tech Target, MSD2D, Relevant Technologies and numerous other technology companies. You can visit Brien's personal Web site at http://www.brienposey.com>http://www.brienposey.com.
Do you have a useful Exchange tip to share? Submit it to our monthly tip contest and you could win a prize and a spot in our Hall of Fame.