Summary: The blog highlights common Exchange Server issues that affect the functionality of the server environment. It explains the consequences that appears as the result of Exchange errors and suggests an automated Mailbox Exchange Recovery solution, compatible to run over all Exchange versions.
Microsoft Exchange offers complete emailing and calendaring features and is considered to be one of the most protected communication platforms being used in the business arena. Even so, this does not indicate that the Exchange mailboxes and the data stored within it are immune to corruption or sudden damage.
Likewise other applications and data files, Exchange EDB files also involve the risk of data loss. Let’s look at some of the common Exchange Server issues and errors:
i. Exchange error 1018
ii. Exchange error 1216
iii. Exchange dirty shutdown error
iv. Unable to mount database error
v. Exchange error 1056749110
vi. Unable to initialize Exchange Information Store service
Let’s understand each in more detail.
Exchange error 1018 ‘JET_errReadVerifyFailure’ is a result of page-level corruption found in EDB files. Exchange database file is an array of 4 KB, 8 KB, 12 KB, 16 KB pages organized in a B-tree structure. A page in the database points to the next or the previous page for faster page traversal. The first two pages in the Exchange database are accommodated by the header section, and therefore, the third consecutive page is considered to be the first logical page.
Similar to page number, page checksum is another important concept which is calculated mathematically where the resulting value is mentioned in the header section of each page. If any mismatch exists, the page turns corrupt, thus making it unreadable. Sometimes, errors with NTFS file system, incorrect checksum calculation, writing checksum at incorrect location, or overwritten data gives rise to the Exchange error 1018.
When the header information assessment in the database and log files specifies that some crucial files are modified or removed, Exchange error 1216 ‘JET_errAttachedDatabaseMismatch’ appears. When the running Storage Group stops suddenly, the instance leads to the respective error message. When a recovery method is executed, the Storage Group may start eventually, however some of the files may get lost or deleted in the process.
Sometimes, it becomes impossible to enter the lost information in the storage group or in some cases, the inconsistencies are found in the header information when the Storage Group is restarted. The manual method to recover MS Exchange Server issues is complex and involves the risk of considerable data loss. Therefore, it is recommended to employ a professional mailbox recovery tool to recover lost and inaccessible data.
Every single data addition or modifications made to the database is tracked by the transaction log file. Any inconsistencies in the transaction log files can hinder the smooth functionality of the Exchange database. In severe cases, the database fails to start and affects the whole Server environment. There are many reasons that are responsible for such scenario, sometimes, it is simply that the Server is not shut down properly, therefore, resulting in a ‘Dirty Shutdown’ state.
In such situations it is advised to back up the log files frequently and not to delete them permanently. If required, delete the files only after ensuring that the backup is being created and the particular database file has become redundant, therefore not required for future reference. In many cases, irresponsible behavior of any of the hardware components turns the Exchange database to the consistent mode. To ensure a clean shutdown of the database, make sure that all the log files are committed to the database and then the status for the log files is displayed as ‘detached’.
When the database exists in an inconsistent state and is restored from backup, an error message may appear while mounting the Mailbox Store. The error message states that “Exchange is unable to mount the database that you specified. Specified database: Servername\First Storage Group\Mailbox Database; Error code: mapiExceptionCallFailed: Unable to mount database. (hr=0x80004005, ec=-528).” Missing transaction log files is the main reason behind the error message.
This often brings the Exchange database to a dirty shutdown state. This needs to be resolved with immediate consideration in order to make the database functional. No matter, how many times the attempt to resolve this issue has been made, the same message may appear each time. In order to bring the database to consistent mode, it is required to stop the Exchange Information Store as well as the databases existing within the storage group.
Migration of Exchange mailboxes is the primary task each administrator has to perform. Sometimes, while performing the operation, the process fails and displays the error code -1056749110. Several techniques can be used to recover mailboxes using Windows Server Backup and implement various stages such as
(i) Backing up Exchange Server Mailbox database; (ii) restoring Exchange database to an alternate location; (iii) using Eseutil, bringing restored database to clean shutdown state; (iv) creating Exchange Server Recovery database; and (v) restoring mailbox items from recovery database.
The error message corresponding to code 1056749110 is displayed as “Restore-Mailbox: Error was found for RSG, Test because: Error occurred in the step: Moving messages. This mailbox exceeded the maximum number of corrupted items specified for this move mailbox operation, error code: -1056749110”. This implies that corrupt items exist in the mailbox. One resolution to this error is via restoring the mailbox that incorporates corrupt items from the Recovery Storage Group to a production mailbox.
After starting the Exchange Server 2010/ 2007 service, when the instance to initialize the Information Store fails, the error message “Unable to initialize the Microsoft Exchange Information Store service – Error 0x8004010f” appears and interrupts the smooth functionality of Server. The reason behind the error is when clock on the Server system fails to sync with the clock on the client’s system. To fix the error, it is important to restart the Exchange Active Directory Topology service.
The common conditions that leads to the above mentioned error code are
(i) deleting the default Recipient policy from ‘Email Address Policies’ tab; and (ii) replacing the default policy with custom email address policy. The manual procedure to resolve this issue is quite lengthier and time consuming. Any kind of mistake can lead to mailbox inaccessibility or permanent loss of data.
The Way Forward – Stellar Repair for Exchange
All the above stated errors can be rectified in a secure, reliable, and error-free manner by using a professional third-party Stellar Repair for Exchange Software. It works on MS Exchange Server 2019, 2016, 2013, 2010, 2007, 2003, 2000, and 5.5 versions. The tool is integrated with powerful scan mechanisms that recovers and restores data from all types of corruption and restores it easily, while maintaining the actual structure and hierarchy of the mailbox folders.