Microsoft Exchange Server can handle a lot of emails and data with multiple databases in its lifetime. However, there comes a time when the database will not process any more emails or possibly dismount. When you inspect the problem, you may find that the database is over 1TB (or 1024GB). This happens if you are running the Exchange Server Standard Edition as it has a hardcoded limit on each database of 1TB.
So, what happens when you have the Standard Edition of Exchange Server 2013, 2016, or 2019 installed and your database goes over 1TB? Periodically, Exchange checks the size of the database. If the database size reaches over 1TB, Exchange Server has a functionality that automatically dismounts the culprit database. If you are running a database availability group (DAG) for high availability of Exchange Server, Exchange will allow you to failover your databases to another site, even if your limit has been reached.
So, what happens now?
There are two options to resolve this problem. The easiest way to solve the problem is to upgrade to Exchange Server Enterprise Edition. But this would be costly and not feasible for some businesses. (For more information on Exchange Server licensing, check out this link.)
The workaround for not buying the Enterprise Edition and being able to mount the database until you fix the problem is to use registry changes to mount the database and split the data to remain below the limit.
Before you begin the procedure, it is best to take a backup. Now, if it is not possible to take a backup of the server, you should back up the registry as you need to modify it for this job. To back up the registry, follow these steps:
- Open regedit.exe
- Click on the root of the registry
- Click on File and then click on Export
- Save the copy of the file somewhere safe just in case
Now, while being on the registry, navigate to the below location:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Server Name>\Private-<database GUID>
Here, the database GUID is your database GUID. If you do not have it in hand, you can open the Exchange Management Shell and use the PowerShell cmdlet Get-MailboxDatabase to verify the GUID against the name of the database.
Get-MailboxDatabase | Format-Table Name, GUID
Once you have the GUID of the affected database, go back to the Registry. If the DWORD entry Database Size Limit in GB exists, change the number to the size you want in GB. If the DWORD does not exist, create a new DWORD with the exact name (case sensitive) and enter the size, as requested, to be over the current size.
Once this is complete, you need to mount the database by using the force command. To do this, you need to use the Mount-Database PowerShell cmdlet as shown below.
Note: It is not available through the Exchange admin center (EAC). If you try it from the EAC, it will fail.
Mount-Database <database name> -Force
Once this is done, your database should mount with no problem.
Here, you can create a new mailbox database and move the mailboxes to balance the sizes between two or more databases. If you have already used the five-database limit of the Standard Edition, you must check the sizes of each database and move the mailboxes accordingly to balance out. The only solution then is to move to Enterprise Edition.
Important note: It is not suggested to remain working with the workaround as, in reality, you would be breaching the licensing and support agreement with Microsoft. This workaround must only be used to fix the problem and then revert.
Things to consider when applying the Exchange database workaround
- If you have a database availability group setup, the change will automatically propagate to the other servers.
- The registry workaround might be reverted when applying any Exchange Server cumulative updates.
- The workaround will not allow any automatic failover of databases within your DAG. This means that if there is a failover, you must manually mount the databases using the PowerShell Mount-Database command with the -Force parameter.
This temporary Exchange database workaround is not a fix!
The process mentioned above is just a workaround and not a fix. If you use the Registry wrongly during the process, you could damage the server or the databases. The worst thing about this workaround is that you will lose the automatic failover if you are running a DAG. If such cases occur where the database will not mount, you can rely on a third-party application, such as Stellar Repair for Exchange. This application will surely come in handy as it can open any Exchange Server Database from any version — online or not and in any health condition. It can export the data to PST or directly to a new and live Exchange Server database on any version. It can also be used to export directly to a Microsoft Office 365 tenant.
Featured image: Shutterstock