MapiExceptionTooManyMountedDatabases: Standard Edition hits its database cap

Fix it now

The store refused the mount because the server already has as many databases mounted as its edition permits. Standard Edition supports five; Enterprise Edition supports up to 100. A server still on the installation trial behaves as Standard. There is no supported registry value or configuration change that lifts the limit, because it is what distinguishes the two editions.

Get-ExchangeServer <ServerName> | Format-List Name,Edition,*Trial*
Get-MailboxDatabase -Server <ServerName> -Status | Format-Table Name,Server,Mounted
Set-ExchangeServer <ServerName> -ProductKey <ProductKey>
Restart-Service MSExchangeIS

1. Count what is genuinely mounted. Microsoft defines a mounted database as an active database mounted for clients or a passive copy mounted in recovery for log replication and replay, so availability group copies occupy slots on the server hosting them.
2. Do not count recovery databases. Microsoft states explicitly that recovery databases do not count towards the edition limits, so dismounting one frees nothing.
3. Remove what no longer earns its place: databases left mounted after a finished migration, and databases with no active mailboxes.
4. Only then enter a key. Restart-Service MSExchangeIS dismounts every database on the server and disconnects every client while it comes back, so plan it.

Moving from Standard to Enterprise with a product key is a one-way change. You cannot downgrade back with a key; it requires uninstalling and reinstalling Exchange. Decide before you apply it.

If the database mounts after the restart, you are done. If the count was never the problem, the next section covers what else refuses a mount.

Why it happens

Exchange has always sold capacity by edition rather than by capability. Standard and Enterprise install from the same media and run the same code; the product key tells the server which set of limits to enforce. The number of databases a server may mount is the most visible of those limits, and it is enforced by the store at mount time rather than at configuration time. That is why you can create a sixth database quite happily on Standard Edition and only discover the boundary when you try to bring it online.

What counts is narrower than people assume in one direction and wider in another. Microsoft’s definition of a mounted database covers both an active database mounted for use by clients and a passive copy mounted in recovery for log replication and replay, so a two-copy design consumes capacity on both servers holding a copy. Recovery databases, on the other hand, do not count at all. A recovery database created during a restore is not the slot you are looking for, and dismounting one to make room is an hour spent on nothing.

A server that has never had a key entered runs as the Trial Edition for 180 days and behaves as Standard while it does. Microsoft also states that no loss of functionality occurs when the Trial Edition expires, so the expiry is not what stops you. The ceiling was there from the first day. That distinction matters because a server stood up quickly for a project reaches five databases long before anyone thinks about the licensing, and the failure arrives dressed as a storage problem.

Full reference

What each edition allows

Which way you can move

• Trial Edition to Standard or Enterprise: supported with a product key.
• Standard to Enterprise: supported with a product key.
• Enterprise back to Standard: not supported with a key. It requires uninstalling Exchange, reinstalling it and entering the correct key.
• Anything back to Trial Edition: same answer, and for the same reason.
• Because the downgrade path is a reinstall, the edition decision is worth ten minutes of counting before it is worth a purchase order.

Counting honestly before you buy

The restart, and what it costs

Restart-Service MSExchangeIS is not a small operation. It dismounts every database on the server and disconnects every client until the service is back. In a database availability group the copies on other servers carry the load if the databases fail over cleanly, but on a single server it is a full mail outage for its duration. Put the server into maintenance mode, tell people, and do it once rather than discovering halfway through that you entered the wrong key.

When the count is not the problem

• Check the database file state before assuming the edition: a database that will not mount for a storage reason produces a different error entirely.
• Check free space on both the database and log volumes.
• Check that the configured database path still exists, because a changed volume letter or mount point produces a mount failure that looks like anything.
• Check whether other databases on the same server mount normally. If they do, the fault is specific to this database rather than to the server.
• Read the hexadecimal error code the store logged rather than the event number, because the same events cover licensing, storage and log faults alike.

Every code this article covers

Confirm the fix worked

1. Get-ExchangeServer <name> | Format-List Name,Edition,*Trial* reports the edition you paid for and no trial state.
2. The database that previously failed mounts and stays mounted.
3. Get-MailboxDatabase -Status shows every database you expect to be online.
4. The application event log shows a clean store startup with no further mount refusals.
5. Clients on the affected database can connect and send mail after the restart.

Questions people ask about this