Exchange database dismounts unexpectedly

The Exchange mailbox database keeps dismounting, and when we like to mount the database, it’s unable to mount. After repairing the Exchange database and mounting, we did look at the event logs for errors. That’s because we like to prevent Exchange database dismounts from happening again. So why does this happen, and why does the Exchange mailbox database dismount unexpectedly?

Introduction

Database suddenly dismounts, and being unable to mount the database because it’s damaged is not suitable for the organization when you have a standalone Exchange Server. That’s because you have to recover the mailbox database, which will take time.

If you have Exchange Server High Availability set up, you don’t panic because the mailbox database copy will become active on another Exchange Server. You have time to investigate the issue and reseed the mailbox database.

But, if the issue is in the underlying configuration, then it does not matter if you have an Exchange Server High Availability setup or an Exchange Server standalone configuration. Repairing the mailbox database every time does not mean you have fixed the problem. You need a solution that will fix the mailbox database sudden dismount.

Every engineer that maintains an Exchange Server or has an Exchange Server in the organization needs to follow this article. This is not only a solution to the database dismounts, but these are the best practices for preventing the mailbox database from dismounting all of a sudden.

Database dismount event logs errors

In this example, the Exchange mailbox database is ExchangeDB, and it dismounts unexpectedly. When we look at the event logs, the following two errors are interesting:

Event 739, ESE (ESE)

Source: ESE (ESE)
Event ID: 739
Task Category: General
Level: Error
Description:
Information Store (5652) ExchangeDB: The NTFS file attributes size for database ‘D:\ExchangeDB\ExchangeDB.edb’ is 243136 bytes, which exceeds the threshold of 204800 bytes. The database file must be reseeded or restored from a copy or backup to prevent the database file from being unable to grow because of a file system limitation.

Event 203, ExchangeStoreDB

Source: ExchangeStoreDB
ID: 203
Task Category: Database recovery
Level: Error
Message: At ‘5/7/2022 5:28:00 PM’ database copy ‘ExchangeDB’ on this server appears to have a serious I/O error. To help identify the specific failure, consult the Event log on the server for other storage and “ExchangeStoreDb” events. Service recovery was attempted by failover to another copy. Failover was unsuccessful in restoring the service. Error: Couldn’t perform the database failover.

Why do we get these errors, and what is the solution for database I/O error and NTFS file attribute size for database exceeds the threshold of 204800 bytes?

Solution for Exchange database dismounts unexpectedly

Looking at the Exchange Server standalone environment, we can see that there are three problems:

1. The Exchange mailbox database is created in the default Exchange Server installation folder.

You should never create the mailbox database on the (C:) drive. Suppose you have installed Exchange Server on a different drive, say (D:) drive. Then, don’t configure the mailbox database on the (D:) drive.

Important: Do not create the mailbox database on the Windows OS drive or the Exchange Server install drive.

2. The mailbox database size is 550 GB.

Never go beyond 200 GB in mailbox database size if you have a standalone Exchange Server. Having a 550 GB mailbox database takes more time to recover and move when there are issues.

3. The volume allocation unit size is 4 KB (4096 bytes).

Do not configure volumes with an allocation unit size of 4 KB (4096 bytes). Instead, use a disk allocation unit size of 64 KB (65536 bytes) for both .edb and log file volumes. It does not matter if you have the volume configured as NTFS or ReFS. Although, ReFS is the recommended option and what we recommend to use.

NTFS does have its limitations with the overall size of this attribute list per file and can have roughly around 1.5 million fragments. This is not an absolute maximum but is around the area where problems can occur. The File Attribute List (FAL) size will never shrink and will continually keep growing over time.

The maximum supported size of the Attribute List is 256 KB (262144 bytes). If you were to reach this upper limit, you could no longer expand the size of your database and we would be doing a lot more smaller I/O operations and a lot more seeking around the drive to find the data we are looking for.

Now that we identified why the sudden Exchange Server mailbox database dismount happens, it’s time to configure the correct setup with the below steps.

Create disks

Creating disks depends on your environment. If you have a physical server or a virtualized server (VMware/Hyper-V). In this example, we have VMware running, and we did create 8 disks:

• 4x 200 GB disk (database)
• 4x 100 GB disk (logs)

Note: You should run monitoring software on every server, including the Exchange Server. It will tell you for event errors or when the disk space starts to get full.

Create ReFS volumes

Read more in the article Configure ReFS volume Exchange 2013/2016/2019.

In the previous step, we did create the disks. Now it’s time to create 8 ReFS volumes on the Exchange Server:

• 4x 200 GB volume (database)
• 4x 100 GB volume (logs)

Verify ReFS volume allocation unit size

Read more in the article Get allocation unit size with PowerShell.

Always verify that everything is set correctly. The ReFS volumes allocation unit size needs to be 64 KB (65536 bytes). The Windows drive and if Exchange Server is installed on another drive should have the volume allocation unit size of 4 KB (4096 bytes).

Create mailbox databases

Read more in the article Create mailbox database in Exchange Server and Exchange database naming convention.

We did create 4 mailbox databases on the below drives:

Database name	Data drive	Logs drive
DB01	E:\	F:\
DB02	G:\	H:\
DB03	I:\	J:\
DB04	K:\	L:\

The original mailbox database is 550 GB in size. When creating 4 mailbox databases, every mailbox database will be around 137,5 GB in size. The administrators will keep an eye on the mailbox databases and not let them grow over 200GB. If they exceed that size, they will create a 5th mailbox database. Then they can add new mailboxes to the 5th database and move mailboxes between databases if they have to.

If the mailboxes start to grow and want to add a 6th mailbox database, they must purchase an Exchange Server Enterprise license. That’s because you can only mount 5 mailbox databases with Exchange Server Standard Edition and a maximum of 100 databases with Exchange Server Enterprise Edition.

Migrate mailboxes

Read more in the article Mailbox migration best practices.

Move the mailboxes from the old database to the 4 mailbox databases.

It’s possible to move the mailbox database to the newly created ReFS volumes instead of moving the mailboxes. Because the problem is not in the database, and the problem lies in the allocation unit size, which we did fix by creating new volumes with a 64 KB allocation unit size.

In our case, we didn’t move the mailbox database. That’s because the mailbox database had errors, and we would like to start fresh. Also, the mailbox database size was 550 GB, which is too big. Moving the mailboxes from the database will keep the white space, and it means we have to move all the mailboxes eventually to clear the white space.

Remove mailbox database

Read more in the article Delete mailbox database in Exchange Server.

The mailbox is still 550 GB in size, but there are no more mailboxes on it. The last step is to delete the old mailbox database safely.

Conclusion

You learned why the Exchange database dismounts unexpectedly. Look into the event logs and check what the error generates. It’s essential that every Exchange Server organization configures the mailbox databases and logs, just as we did explain in this article.

Don’t create mailbox databases in the default Exchange Server installation path. Instead, create dedicated disks and volumes with a block size of 64 KB. After that, create the mailbox databases or move them. As of last, don’t forget to keep each mailbox database under 200 GB if you have a standalone Exchange Server.

Did you enjoy this article? You may also like Exchange database best practices. Don’t forget to follow us and share this article.