Exchange database corruption issues are quite common and if you are working in an Exchange environment, you must have had at least one experience of Exchange database corruption. In order to combat the situation of data loss, we stay ready with a backup of our important data saved in Exchange database. However, there is an issue that you might come across if you don’t take proper precautions and that is the issue of restore Exchange Server from backup.

Suppose you mount a blank new database on Exchange Server and after this, you restore the same database from a backup to the production location. Most probably, you will come across a database that contains data only of the time from when you mounted the blank new database i.e. all the previous information from the restore is lost. You will also notice that the database files look reduced in size.

Why does this happen? This problem occurs when a user tries to restore Exchange Server from backup. User restores a particular database without actually deleting the transaction logs. Since a blank new database was mounted on the server, hence there was a record of createDB transaction in the transaction log and so when you try restoring a database without deleting the transaction logs; it acts abruptly with the logs of the backup and logs available in transaction log.

CreateDB being similar to other transaction logs of a database engine is replayed just like any other transaction. Thereby while restoring the database from the backup, createDB transaction is hit. This results in mounting of blank new database and therefore, you get to restore only the email items from the time when you mounted the blank database.

Note that this behavior of Exchange Server (createDB transaction issue) was not experienced in MS Exchange 5.5 or in earlier versions of Exchange. This issue is experienced in MS Exchange Server versions 2000 and 2003.

You can follow the below-mentioned resolutions to ensure that you don’t lose your important Exchange Database data:

• In Exchange 2003 version- It is suggested that you must not restore the backup to the production location if you have mounted a new blank database in production. Rather you must continue to run on the newly mounted blank database and restore to the Recovery Storage group as per the “dial tone” recovery process.

• In Exchange 2000 version- Always restore database to Recovery Server and then use the Exmerge utility to merge the databases together.

“Event Type: Error

Event Source: MSExchangeIS

Event Category: General

Event ID: 1112

Description: The database “Mailbox Store (Server Name)” has reached the maximum allowed size. Attempting to unmount the database.”

Cause of the Error

The main reason behind the emergence of this situation is that the Exchange Server database of Exchange Server 2003 has crossed the threshold limit of 16 GB.

Solution of the Error

In order to resolve this situation, you need to perform the following steps:

1.Increase the size limit of the database by upgrading to Exchange Server 2003 Service Pack 2. This would help you to increase the database size limit to 18 GB.

2.If you have the administrative rights for controlling the Exchange Server, then you can increase the size of the database by 1 GB for the time being. After resolving the issue, remove some of the content (the not so important content) from the database. We suggest you to defragment the Exchange Server database to bring the same back to the pre-determined size limit of the database size.

3.Use the Recovery Storage Group feature to mount the database and then try to extract the Exchange Server database from the mailboxes using the Microsoft Exchange Merge Wizard (Exmerge.exe) utility.

Using the steps mentioned above, you can surely help your EDB database to bring the size under control and use your Exchange Server just the way it worked before. However, if the above steps do not help you recover EDB data, and then you must stick to a powerful and reliable third party Exchange database recovery software to help you. These Exchange database recovery tools are able to perform Exchange Server recovery without overwriting the actual data.

1. Start the System Attendant service.

2. Start the directory service after having copy of the dir.edb file.

3. Open Exchange’s Administrator interface. Check out information regarding connectors and mailboxes.

4. Start the information store service. If it won’t start, you may have to replace the priv.edb or pub.edb file, depending on which part of the information store is damaged. If you replace priv.edb or pub.edb, you must delete all associated log files.

5. Then, switch to the \EXCHSRVR\BIN directory and run the following command: isinteg – patch. If you replaced the pub.edb file, remove any replicated public folders. The information store service should now start.

6. Regenerate the directory service if the directory service database was replaced and you didn’t have a CSV file to rebuild it with; I explain how in the next section.

However, replacing the damaged database is the ultimate solution but before doing so, you can try repairing it using Exchange database recovery software. Exchange database recovery software effectively repairs damaged EDB database file and recovers data from it. The software supports Microsoft Exchange Server 5.0, 5.5, 2000, 2003, 2007 and 2010

• The first component is information store, which comprises two individual databases – private information store and public information store. Working with database engine and MAPI, the information store makes it sure that whatever the operation is performed it is saved on the server.
• The second component is JET database engine, a 32-bit multi-threaded database engine. The JET database engine ensures the performance and speed of the operations performed.

The Exchange Server database file can be damaged any time interrupting the operations that are being performed. Once the .edb file is damaged, users mailboxes stored in it gets also damaged thus, puts the users in a critical situation of data loss.

Reasons for the damage of .edb file

There can be many reasons for the damage of .edb file including physical and logical reasons. Some of those reasons are:

• Failure of the JET database engine
• Corruption of the information store
• Virus infection
• Improper system shut down
• Application malfunctioning
• Missing database objects
• User’s errors

Mentioned above are some of the well known reasons that lead into the damage of the Exchange database file on Exchange Server.

Solution

Once the .edb file is damaged, all of the users mailboxes stored in it become inaccessible and the users have to face data loss. However, Microsoft has provided two tools (Eseutil and isinteg) for dealing with corrupt .edb file those tools work only when the corruption is minor. In case of major corruption, Eseutil and Isinteg get failed to repair the .edb file.

Use Exchange database recovery software to recover data from the damaged .edb file when the corruption is major. The Exchange database recovery is a competent tool for repairing the damaged .edb files and getting the lost data (emails, notes, contacts, etc.) back in just few minutes. The software works perfectly with Microsoft Exchange Server 5.0, 5.5, 2000, 2003, and 2007. In addition, the software supports MS Outlook 97, 98, 2000, 2003, and 2007.

A LCID is a 32-bit value termed by Microsoft Windows comprising of a sort ID, language ID and reserved bits which is similar to the particular language. After this situation, the data in Exchange Server becomes inaccessible. If you move database between computers having different LCID installation status, then possibility of occurrence of silent database index corruption is high. For example:

• When LCID that was previously uninstalled is reinstalled, then there is a possibility of silent index corruptions
• When Exchange Server database is copied to a different computer, de-fragmented and then copied to the original computer, it might result in index corruption.

The thing that disturbs you the most is database corruption that leads to inaccessibility of EDB file thereby causing massive data loss. There is this latest service pack for Exchange Server made available by Microsoft, it can fix this problem so it won’t occur in future but it cannot deal with the corruption. The corrupt database indexes will still remain corrupt, even after up-gradation.

In this situation, the only solution you are left with is to perform Exchange database recovery to repair damaged indexes. Exchange database recovery can be made possible through the Exchange Server Recovery software. Exchange Server Recovery software is a powerful third party Exchange recovery tool that can take care of almost all kinds of EDB corruption errors. The Exchange Server recovery software supports all versions of Exchange Server, such as Microsoft Exchange Server 5.0, 5.5, 2000, 2003, 2007 and 2010.

“OpenMsgStore” is one of the methods associated with IMAPISession interface that is used to open a message store in Exchange Server mailbox. This method results a reference that is passed to ImsgStore object for further access. After that we get access to our mailbox email items (received or sent).

There are instances when this method fails. Whenever method fails, an application log is generated that records Exchange Server computer events, which can be analyzed for knowing the root cause of failure. Corruption in the message store is the foremost reason for this behavior.

You may encounter the given event log description displaying in the application event log of Exchange Server computer:

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

Event ID for this error is 9175 and is specific to Microsoft Exchange Server 2000 and 2003.

Cause

Reason for this situation to occur is that the IS (Information Store) is not running or the mailbox store fails to mount. The Information Store may stop due to the following possible reasons:

• You might be using an expired evaluation version of Exchange Server
• The store is dismounted and/or corrupted
• The partition storing the IS files is less than or equal to 10 MB in size
• Information Store is in dirty shutdown state

Solution

Following points are recommended in such situations:

• Use the activated version of Exchange Server
• Backup your store and run ESEUTIL/p command to repair it. The command can delete the corrupted pages and cause data loss.
• Check for IS partition is greater than 10 MB in size
• Replay all the transaction log files for the affected mailbox store

If all these points help you in repairing of Exchange Server, then it’s well and good. Otherwise you would be requiring professional Exchange Recovery software. They scan the corrupt database and repair the same efficiently and effectively. The software recovers deleted Exchange mailboxes, permanently deleted emails from the mailbox folders, and displays these items in Red color.

“JET_errLogCorruptDuringHardRestore -573”

Error – 573 indicates that Exchange Server has detected some corruption in a backup set; therefore you fail to proceed further.

Solution

To solve this problem, try the following methods.

1. Check for some other valid and updated backup set that may be used to restore the database and carry out hard restore.
2. If not successful with it, then run ‘ESEUTIL /P database_filename.edb’ command to repair the database, where ‘database_filename’ is the name of the corrupted database file.

Using ESEUTIL utility can discard table rows and even complete tables. So, it would be better if you perform recovery of Exchange database with backup copy.

Last but not the least, if backup thing doesn’t work, go for third party software to get efficient Exchange database recovery. Exchange recovery software repairs corrupt database (.EDB) file to recover mailboxes safely from them. The software rebuilds the entire EDB database which can be easily mounted to MS Exchange server.

Cause

This error particularly results when you run ESEUTIL /CC command using the incorrect file path pointing to Restore.env file.

ESEUTIL /CC is the restore mode command, which is applied to run hard recovery on a database that has been restored from an online backup. Exchange Server creates Restore.env file while restoring from backup to control the hard recovery process.

Solution

Follow the below mentioned steps to recover from the given problem:

1. Run ESEUTIL /CC command using the correct file path of Restore.env file.

2. Check the database consistency. If it is inconsistent, you can use ESEUTIL /P and then ESEUTIL /D command for recovering the database.

ESEUTIL /P is the hard command that deletes the corrupted data, instead of repairing it. So, after using the command, you may find the database with lost pages and deleted information.

So it’s always advisable to use professional Exchange database recovery tool to recover data from corrupt database .EDB file. Error 939586631 will be resolved easily using this tool. Using an efficient EDB repair tool, you can recover all mailboxes stored in the damaged EDB file.

You might have observed that MS Exchange Information Store services stops responding at repeated intervals of time in a day. On viewing the application event log, you come across event ID 467 associated with a 1025 warning:

Warning 1025:

An error occurred on database “First Storage Group\Public Folder Store (server_name)”

Function name or description of problem: SLINK:: EcUpdate Error: 0xfffffa7a

You come across a similar warning each time when event 467 is logged in MSExchangeIS public or private store.

Reason for this issue

Event 467 conveys that secondary index is inconsistent with the associated table. The database page is corrupted and is causing JET engine to hang.

Resolution

In order to resolve this issue, you need to first locate the corrupted database, which is specified in the Description section of event occurred. After the affected database is detected, follow the given below steps:

1. Start Exchange System Manager and dismount the database causing the issue
2. Run eseutil /g command to confirm for database inconsistency
3. Run eseutil /d command to defragment and fix the corruption
4. Mount the database store

If still the issue persists, then go for deleting the database but make sure that you have an updated valid backup. Backups are not the only solution, so if you are not having backup then you should try result oriented Exchange database recovery software. These tools are capable of resolving any kind of error issues related to Exchange Server database. One of the benefits of using Exchange database recovery tool is you can access the users’ mailboxes directly with Outlook, as the software provides option to save the recovered mailboxes in individual PST files.

time Microsoft Exchange offline address book
time 0X8004010F
Task ‘Microsoft Exchange Server’ reported error (0×8004010F): ‘The operation failed. An object could not be found.’
Using a new .OST file to synchronize with Exchange does not solve the error.

Cause

Reason for this error 0×8004010F to crop up is any incorrect entry in the Offline address list server box in the Default Offline Address List Properties dialog box.

Resolution

To resolve this issue follow the given below steps:

1. Start Exchange System Manager.

2. Expand Recipients, and then click Offline Address Lists.

3. In the right pane, right-click Default Offline Address List, and then click Properties.

4. Note the computer name that appears in the Offline address list server box. If a deleted Active Directory service object appears in this box, specify a valid server. For this, follow these steps:

• Click Browse, click an Exchange server in the Select Exchange Server dialog box, and then click OK.

• In the Default Offline Address List dialog box, click OK.

5. Examine the properties of the server’s mailbox store to verify that the correct offline address list is specified. Perform the following:

• If administrative groups are enabled, expand Administrative Groups, and then expand the appropriate administrative group.

• Expand Servers, and then expand the Exchange 2000 server.

• Expand the appropriate storage group, right-click Mailbox Store (ServerName), and then click Properties.

• In the Mailbox Store (ServerName) Properties dialog box, click the General tab.

• Verify that Default Offline Address List appears in the Offline address list box.

6. Exit Exchange System Manager.

7. Restart the Microsoft Exchange Information Store service for allowing the Exchange scheduled online maintenance.

This way you can overcome this ‘Microsoft Exchange Server’ reported error (0×8004010F). But if other error messages indicating Exchange database corruption are occurring, then take help of Exchange recovery software. With this you can perform flawless and fast Exchange Database recovery. One the database will be repaired, you can easily access the users’ mailboxes stored in it.