Top 10 common database mounting issues and how to fix them
Home  /  Blog  /  Email Recovery   /   Top 10 common database mounting issues and how to fix them

Top 10 common database mounting issues and how to fix them

Email Recovery, by

Database dismounting can be a result of diverse situations. IT teams need to be able to overcome these issues quickly to reduce downtime and get the databases functioning properly. In majority of cases, the Exchange Server’s application logs provide enough information to troubleshoot the problem and determine the root cause. In this article, we will discuss 10 of the most common issues that result in databases failing to mount and show you how to fix them.

1. The Exchange Server 2003 mailbox store is not mounting when the mailbox database reaches its 16-GB limit

When the Exchange Server 2003 Standard Edition reaches its 16-GB limit, the mailbox store fails to mount and the following events are logged:

Event ID: 1112

Description: The Exchange Server mailbox has reached its threshold. has reached the maximum allowed size. Trying to unmount the database.

Event ID: 445

Description: Information Store (3160) The database “D:\Program Files\Exchsrvr\MDBDATA\priv1.edb” has reached its maximum size limit. If the database cannot be restarted, an offline defragmentation may be performed to reduce its size.

Cause:

This error occurs when the Exchange mailbox store in the 2003 Standard Edition of Exchange reaches its 16-GB limit.

Solution:

By using the new Recovery Storage Group feature in Exchange Server 2003, you can mount the database to a recovery storage group and use the Exchange Server 2003 version of the Microsoft Exchange Merge Wizard (Exmerge.exe) to extract mailboxes from the database.

2. The database is corrupt and will not mount

When the database has been corrupted, it cannot be mounted and the following event is logged:

Event ID: 474

Description: The following message is usually received for this error: The database page read from the file at offset (database page ) for bytes failed verification due to a page checksum mismatch. The expected checksum was and the actual checksum was …

The database page read from the file <> at offset <> (database page <>) for <> bytes failed verification due to a page checksum mismatch. The expected checksum was <> and the actual checksum was <>…

Cause:

This event Id indicates that a database page cannot be read because of a page checksum mismatch. This means that a specific database page within the Microsoft Exchange Information Store service file (such as priv1.edb) is corrupt. Because of this error, users cannot start MS Outlook on client computers and cannot send-receive emails.

Solution:

Run system diagnostic tests. These tests may not be conclusive if the problem is not that frequent and appears only under very complex loads. To solve the problem, you can migrate to new, supported hardware. You can repair the database with eseutil/P tool, followed by eseutil /D tool and isinteg –fix, and convert EDB to PST buy using efficient third party tool.

3. Permissions in Active Directory service are modified

When this error occurs, the information store is not started and the following event ID is logged in the Application event log:

Event ID: 7024

Description: The Microsoft Exchange Information Store service terminated with service-specific error 0. Some other informational events are logged after this: Event ID: 1024,

Cause:

The account no longer has the rights to read the information store. This could be due to any of the following:

The server might not be a part of the Exchange Domain Servers Group. Inherited rights might have been taken back from the information store. The administrator might have added Explicit denies for this object. The object itself might have been deleted.

Solution:

If you are using ADSI Edit snap-in, the LDP utility or any other LDAP version 3 client and erroneously modify the AD’s attributes, serious problems can occur. You may be required to reinstall Microsoft Windows Server 2000/2003, Microsoft Exchange Server 2000/2003 or both Windows and Exchange. You can also employ ADSI Edit to check the permissions on the following AD object or to verify that they are there:

CN=InformationStore,CN=ServerName,CN=Servers,CN=AdminGroupName,CN=Administrative Groups,CN=ExchangeOrgName,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=DomainName,DC=com CN=InformationStore,CN=ServerName,CN=Servers,CN=AdminGroupName,CN=Administrative Groups,CN=ExchangeOrgName,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=DomainName,DC=com

If you discover that the permissions are incorrect or the Exchange accounts are misplaced, run setup.exe /domainprep. You can also run the ADSI Edit by installing Windows 2000 Support Tools.

4. Antivirus software deletes or modifies the transaction log files

Having antivirus software in place contributes to the security of your Exchange Server. However, there are some folders on the server, such as the folder containing the transaction logs, that should never be scanned.

Event ID: 455

Description: The following message is usually accompanied with the event (Information Store (1892) b2a6f816-2baf-462e-918c-eda5d1fb24d3: Error -1811 (0xfffff8ed) occurred while opening log file C:\Program Files:\Exchsrvr\mdbdata\E00.log)

Event ID: 9518

Description: (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.

Reason:

All incoming messages (whether infected or not) are written to the transaction logs. If the Antivirus software is configured to scan the transaction logs folder, it might detect a virus signature in the logs and try to change or delete it, which may cause Exchange to crash. When this happens, the Exchange System Manager generates an error message stating: An internal processing error has occurred. Try restarting the Exchange System Manager or the Microsoft Exchange Information Store service, or both.

Solution:

Go to the settings of your software and ensure that the antivirus application is set not to scan the installable file system.

5. Exchange Server needs rights that Group Policy does not have

If mounting the Exchange 2000 information store databases fails, users may see one or more of the following error messages in the Application event log:

Event ID: 2102, 9004, 1005, 1002, 9519, 1029, 9074, 1121, 125

Cause:

These issues can occur if the ‘Manage Auditing and Security Log’ right (SeSecurityPrivilege) is removed for the Exchange Enterprise Servers domain local group on some or all DCs.

In a domain, when the first Exchange computer is installed, or when Exchange Setup is run with the /domainprep switch, the SeSecurityPrivilege right is given to the Exchange Enterprise Servers group.

If the SeSecurityPrivilege right is taken back, Exchange computers that use DCs in the domain stop working. The issue will become apparent after the Kerberos security refresh intervals expire or when Exchange services are restarted on the servers.

Solution:

To resolve this issue, use the Policytest.exe utility included in the Exchange 2000 installation CD-ROM. This tool can be used to check the SeSecurityPrivilege right’s status on all the DCs in a single domain.

To find out whether Exchange 2000 Enterprise server has the SeSecurityPrivilege right on a DC, do the following:

  • Log on to the DC as an administrator, and then start the Domain Controller Security Policy console. (Which by default is located in the Administrative Tools group.)
  • Expand ‘Security Settings’, after that expand ‘Local Policies’. Then expand ‘User Rights Assignment’, and then open Manage Auditing and Security Log’s properties.

SeSecurityPrivilege right can be granted directly to the Exchange 2000 Enterprise servers, or it can be granted automatically with the /domainprep switch by running the Exchange 2000 Setup.

6. Database mounting failed because of a wrong version of service pack on a clustered Exchange Server

Installing a service pack can also cause an Exchange database mounting failure. If you have Exchange 2000 (and possibly an Exchange 2003) running in your environment, such errors can occur if the Exchange Server is running on a cluster.

Cause:

Let us assume that you install Exchange Server SP 1 on node 2 of the cluster. The cluster will fail over to node 1 at the time of the service pack installation. Installing the service pack alters the database in a way that the DB is mountable only from a system running SP 1. Cluster’s node 1 is not running the SP 1 so consequently it can’t mount the database.

Solution:

To avoid this, Install the Service Pack on all the nodes of the cluster. Microsoft suggests using a rolling upgrade to install service packs onto a clustered Exchange Server.

7. Database mounting failed after running Setup in / disaster recovery mode

Cause:

If users run Exchange 2000 Setup with the /disaster recovery switch, the databases may fail to mount. The /disaster recovery switch is used for preparing the system for database restoration.

Solution:

Open the Exchange System Manager, go to the Administrative Groups, then go to your administrative group, open Servers -> First Storage Group -> Mailbox Store (the database that is not being mounted). Then right-click on the database to open the short-cut menu, and select the Properties command. In the database’s properties sheet, select the Database tab and uncheck the ‘Do Not Mount This Store at Start-Up’ check box.

8. Database mounting failed with an error

At the time of mounting Exchange databases on an Exchange 2000 computer, the process fails and an event (Event ID: 1088) is logged in the Application’s event log.

Cause:

This occurs when the message databases are restored from a server that was upgraded from Exchange Server 5.5 and whose site name is not “First Administrative Group.” When mounting stores on an Exchange 2000 computer, the Organization name and the Administrative Group (or Exchange Server 5.5 site) name of the messaging databases must be same as in the Active Directory. Installing Exchange Server 2000 creates an Administrative Group named “First Administrative Group” by default in the Active Directory.

Solution:

To resolve this error, reinstall Exchange 2000 Server and rename the “First Administrative Group” in Active Directory so that the name is same as the Administrative Group or Site name of the message database.

9. Exchange database mounting failed because Hard disk NTFS file system permissions were modified

When you start Microsoft Exchange Server 2000/2003, or when you create a blank Exchange database, the information store databases may not mount successfully and you may receive the following error message in Exchange System Manager:

“An internal processing error has occurred. Try restarting the Exchange System Manager or the Microsoft Exchange Information Store service, or both. ID no: <>”

The following events are logged:

Event ID: 470, 9519, and 9518

Cause:

This problem usually occurs if the Exchange Server cannot create/access the files in the folder that is specified by the TMP system environment variable. For example, if the TMP environment variable is mapped to a remote drive or to a SAN, and that mapped drive or SAN becomes unavailable, then this error will occur. Such problems can also occur if the Exchange Server does not have full permissions from the root of the drive to the transaction logs and databases. Incorrect registry configuration concerning the TMP or TEMP environment variable can also lead to errors.

Solution:

To resolve this problem, confirm that both the TMP and the TEMP environment variable point to a valid location in the Windows. By default, the following path is specified for both the TMP and the TEMP system environment variables: %SYSTEMROOT%\Temp. Exchange Server must access this folder by the SYSTEM account. Full Control permissions to the Temp folder must be assigned to the local Administrators group or the SYSTEM account.

Validate the permissions on each drive that has the Exchange database files or the log files. The SYSTEM account should have Full Control permissions at the root of the drive and at each folder that has Exchange database files or the transaction log files.

10. Exchange has no hard drive space

When trying to mount a database in Microsoft Exchange Server, the following error messages may be received:

“An internal processing error has occurred. Try restarting the Exchange System Manager or the Microsoft Exchange Information Store service, or both.”

Event IDs: 9519, 9559, 482, 1003

Cause:

Such problems occur if there is insufficient free hard disk space on the disk drive on which the database is being mounted.

Solution:

To solve this problem, free some disk space and try mounting the database again.If only Exchange database files are located on the hard disk, you might have to perform an offline defragmentation of the databases to free disk space.If this drive also contains the Exchange transaction log files, and if it has too many logs, you will be able to free disk space by deleting unnecessary log files.

Download

If your Exchange database file is unable to mount, you can also use Kernel for Exchange Server Recovery to fix the problems that are caused by damaged database, and mount the database.

Leave a Reply

Your email address will not be published. Required fields are marked *

 
Copyright 2017 www.kerneldatarecovery.com All rights reserved       Sitemap: HTML xml | Privacy Policy