Event ID 226 and Event ID 9519: an Exchange database will not start

Fix it now

The information store tried to start a database and refused. Neither event number tells you why: the same pair appears for edition limits, dirty shutdowns, full volumes, missing paths and permissions alike. The hexadecimal error code carried inside the event is the diagnosis, and the licensing check is worth doing first only because it takes one command.

Get-ExchangeServer <ServerName> | Format-List Name,Edition,*Trial*
Get-MailboxDatabase -Server <ServerName> -Status | Format-Table Name,Mounted
eseutil /mh "D:\Databases\DB01\DB01.edb"
Mount-Database -Identity <db>

1. Write down the hexadecimal code from the event body before you do anything else. Without it you are guessing between five unrelated faults.
2. Check the edition first because it is quick: Standard Edition and the Trial Edition both stop at five mounted databases, and a server stood up for a project reaches that without anyone noticing.
3. Count what is mounted properly. Passive copies mounted for log replication occupy slots; recovery databases do not count at all.
4. If the edition is not the constraint, read the eseutil /mh output and check whether it reports a clean or dirty shutdown, then check free space on both the database and log volumes.

Do not run a hard repair to make a mount error go away. Repair discards whatever it cannot fix and leaves a database Microsoft will not support in production. Restore from backup, or replay the logs, before anyone types a repair switch.

If the database mounts, you are done. If it does not, the next section takes each of the documented reasons in turn.

Why it happens

The store records a failure to start a database in more than one place, which is why these two events usually appear together: one records that a database failed to start, the other names the specific database and carries the underlying error. Neither event number is published by Microsoft with a description, so neither narrows anything. The hexadecimal value inside the event is the only part that identifies the fault, and it is the part people skip.

The instinct on a mount failure is to suspect the database, and that instinct is wrong often enough to be expensive. People restore from backup and run recovery against clean files while the store was simply enforcing an edition boundary. Standard Edition supports five mounted databases and Enterprise supports up to 100, and a server that has never had a product key entered runs as the Trial Edition and behaves as Standard while it does. A migration that grew the estate from three databases to six mounts five and refuses the sixth.

One thing worth correcting, because it changes how urgently you treat an unlicensed server: Microsoft states that no loss of functionality occurs when the Trial Edition expires. An expired trial leaves you unsupported and out of compliance, which are real problems, but it does not switch anything off. The ceiling that refuses your sixth database was there on the first day and would have been there had the trial never expired. The licence is the fix when the edition is the constraint, and it is a distraction when it is not.

Full reference

Sorting the licensing case from the rest

Counting mounted databases correctly

• Microsoft defines a mounted database as an active database mounted for use by clients, or a passive copy mounted in recovery for log replication and replay.
• That means availability group copies consume capacity on every server that holds one.
• Recovery databases are explicitly excluded from the limits, so dismounting one frees nothing.
• Standard Edition supports five mounted databases; Enterprise Edition supports up to 100.
• The Trial Edition behaves as Standard, and continues to do so whether or not the 180 days have elapsed.

Applying a product key

The Information Store restart dismounts every database on the server and disconnects every client until it comes back. It is the step that needs a window, not the key.

What the event numbers do not tell you

Neither of these event identifiers has a current published description from Microsoft, and both appear for unrelated faults. Treat them as a signal that the store logged a start failure and go straight to the error code they carry. If you are searching, search the hexadecimal value rather than the event number, and be sceptical of any result that assigns a single cause to the event identifier itself.

Every code this article covers

Confirm the fix worked

1. The database mounts and reports as mounted in Get-MailboxDatabase -Status.
2. Get-ExchangeServer <name> | Format-List Name,Edition,*Trial* shows the edition you purchased and no trial state.
3. Clients on that database can connect and send mail.
4. The application log runs through the next backup cycle with no further start failures.
5. If you replayed logs or restored, the database reports a clean shutdown state before it was mounted.

Questions people ask about this