Unable to Mount Database HR0x80040115 (ec=-2147221227) Error in Exchange Server 2013/2016/2019/SE

You may encounter the error HR0x80040115 (MapiExceptionNetworkError) when the Exchange Server is not able to establish connection to the Information Store service when a database is being mounted. The most common causes for this error are:

• The required Exchange Server service is stopped.
• The service cannot start due to permission issue.
• The database is in Dirty Shutdown state.

You must not confuse the error HR0x80040115 with HR0x80040005. Although they might have similar symptoms and consequences, these errors differ from one another. The error mentioned in this guide refers to the MAPI/RPC connectivity failure between the EMS client and Exchange Store. It doesn’t necessary refer to a DAG error as it can occur in standalone servers, while the HR0x80040005 error refers to an issue with the transaction logs. The most common fix for HR0x80040115 error is to start the stopped services. However, there might be other underlying issues which can cause this error.

What does the Error HR0x80040115 Mean?

When you are presented with the HR0x80040115 (ec=-2147221227) error, it doesn’t necessarily mean that the database is corrupted, although there is a possibility of this. The HR0x80040115 error is mainly a connectivity issue which happens when the Exchange Management Shell (EMS) is connecting to the Information Store via the MAPI/RPC protocol. The code ec=-2147221227 that accompanies the error is also the same but is mainly a hexadecimal representation of the error. Below are some similar errors.

Common Causes of HR0x80040115 Error

There could be many reasons for the HR0x80040115 error – from as simple as a service not started to a serious issue where the database or transaction logs are corrupted. Here are the causes of this error in the order of severity.

Before You Start — Run these Checks

Before you move to the solutions, you must check the following things:

1 — Verify that Exchange Services are Running (Common Fix)

Open the Services management console from the Administrative Tools or by running the services.msc command.

You need to check that all the Microsoft Exchange Server services, which are set to automatic, are running.

2 — Verify the Database Shutdown State

The EseUtil /mh command allows you to check the state of the database. If the database is healthy, it should show Clean Shutdown, but if there is a problem with the database and transaction logs, it will show as Dirty Shutdown. Use the command as given below:

Eseutil /mh <database file full path>

For full eseutil /mh output interpretation, see Microsoft’s eseutil reference.

Below is a matrix to help you in following up this guide with instructions depending on the results found from the above steps (checks).

How to Resolve the HR0x80040115 Error?

You can follow the methods mentioned below to fix this error in Exchange Server 2013, 2016, 2019, and Subscription Edition.

Method 1 — Restart the Exchange Services

It might happen that there are some services which are not started. So, you can start them by:

• Pressing Windows + R and typing services.msc in the Run utility.
• Then, running the Start-Service <service name> command.

You can also do this via the Services Management Console. Right-click on the service and select Restart.

If any service is not starting, you have to check the Event Viewer and the Windows Logs/Application. Here, you can find the reason.

Once all services are running, retry to mount the database via the Exchange Management Shell or from the Exchange Admin Center.

Method 2 — Fix Dirty Shutdown State (Soft Recovery)

If your database is in Dirty Shutdown state, then the first step is to check the consistency integrity of the transaction logs. You can use the EseUtil command with the ml parameter.

EseUtil /ml <transaction log>

Note: If log integrity errors are detected, review the transaction log state before running soft recovery, as recovery may fail if required logs are missing or damaged.   

To perform soft recovery process, you can use the EseUtil command as given below:

eseutil /r E00 /l <logs path> /d <databases full file path>

Method 3 — Verify Admin Permissions (RBAC)

You need to check if the account performing the operation has the correct Exchange Server RBAC permissions – the right role assignment, role group, and membership. To check this, run the below command:

Get-ManagementRoleAssignment -RoleAssignee "<user>" | ft Role,RoleAssigneeName,AssignmentMethod

To run the Mount-Database command, the account must be a member of the Organization Management or Server Management role group.

Next, you need to confirm that the RBAC permissions are enforced through a role assignment policy token. This can be done by using the command below:

Get-ManagementRoleAssignment -RoleAssignee "<user>" -Delegating:$false

The last thing to check is that the RBAC is reachable through the Exchange PowerShell endpoint by using the below command. The command will return the URLs.

Get-PowerShellVirtualDirectory | fl Name,Server,InternalUrl,ExternalUrl

Method 4 — Set AllowFileRestore for Copied EDB

When a database file has been manually copied or restored from backup, the Exchange Server marks it with an AllowFileRestore flag (set as true). If this flag is still set to true when you try to mount the database normally, the Exchange Server may refuse to mount it as a safety measure. Run the following command to reset the flag:

Set-MailboxDatabase "<database name>" -AllowFileRestore $false

Method 5 — Check RPC/Network Connectivity

There are different things to check but you should start with the Exchange Server built-in RPC test. This will give you the health of your RPC/MAPI.

Test-MAPIConnectivity -Server <MailboxServerName>

If the database is not mounted, you should go back to method 2 to check the database.

Next, you should check that the RPC Client Access service is reachable by using the below command.

Test-ServiceHealth -Server <MailboxServerName>

This will give you an indication if the necessary services are running.

If all are running, you need to test that the mailbox server is reachable via the TCP port 135, which is the endpoint mapper.

Test-NetConnection <MailboxServerName> -Port 135

Now, when you’ve completed all the steps and the database is mounted, you should check the end-to-end email flow by sending and receiving emails on a mailbox.

Method 6 — Use Stellar Repair for Exchange (When All Methods Fail)

When native recovery methods fails to resolve the error, this indicates corruption in the database or missing/deleted/corrupted transaction logs. This will not be fixed by using the ESEUtil and restoring from backup would result in data loss. In such cases, you should use a specialized Exchange recovery tool, like Stellar Repair for Exchange. It can recover data from any version of Exchange Server, and can open orphaned (dismounted) databases and of any size. You can granularly export to PST file or to a new live Exchange Server database with automatic mailbox matching, priority exports, and parallel exports. This will reduce the recovery time and help to comply with the business needs. The tool can process all resources of the Exchange Server database – user mailboxes, user archives, shared mailboxes, disabled mailboxes, public folders, and even purged/deleted items.

Verification after Fix

After all the steps have been done and everything seems to be healthy, you need to make sure that the database is mounted and healthy. For this, use the below command:

Get-MailboxDatabase -Identity "<database name>" -Status | fl Name,Mounted

Note: First, mount the database using Mount-Database in EMS.

The databases which are mounted should show the status as True. False means that the database is dismounted due to an issue.

You should also use the EseUtil to check the state of the database.

Eseutil /mh <database file>

If you found the state as Clean Shutdown, then the database is healthy and you can mount it. But if it is in Dirty Shutdown state, then there is an inconsistent log or corruption in the database.

If you’ve a Database Availability Group (DAG), then use the following command to know the status of a copy.

Get-MailboxDatabaseCopyStatus -Identity "<database name>" | fl *

You should also check the email flow from the resources on the database. This helps you to confirm that the database is healthy and the users can access their mailboxes.

How to Prevent the HR0x80040115 Error from Recurring?

This error can be avoided in future by following these practices and tips:

• Set all Exchange services to Automatic (Delayed Start) so they restart properly after Windows updates.
• Enable monitoring for Information Store service health via Exchange Server health checks (such as Get-HealthReport).
• Create a scheduled task to alert when MSExchangeIS stops.
• Always run eseutil /mh on a database after any unclean shutdown before attempting to mount.
• Monitor performance of the server, including storage space.
• Check the Event Viewer and monitor the System and Application logs for any early warnings and signs.

Conclusion

In this detailed guide, we have provided the solutions – with stepwise instructions – to resolve the HR0x80040115 (ec=-2147221227) error. In case the native solutions didn’t work for you, then there are chances that database is corrupted. For quick resolution, you should use an advanced Exchange recovery tool, like Stellar Repair for Exchange. It can recover all the mailboxes and other items from corrupt database, and export them directly to a live Exchange Server.

FAQs