Exchange 2013 – How To Find Which Store Worker Process Is Responsible For A Mailbox Database

Exchange 2013 has a new store named the Managed Store.

In order to provide failure isolation in the database level in 2013, Microsoft has introduced two new processes as part of the managed store concept. First is the Store Worker Process(Microsoft.Exchange.Store.Worker.Exe) which does the same job that store.exe handled in previous versions. The only difference in 2013 is that a single Store Worker Process is only responsible for one database.

The benefit with this model is that if there is anything wrong with a single database process, it only affects that database. All other databases will be online as they are serviced by different worker processes. So, if you have 5 databases mounted, you will have 5 separate store worker processes.

The second one is the Store Service Process(Microsoft.Exchange.Store.Service.Exe) & it is the process that controls the different store worker processes. When a database gets dismounted, it is the store service process which terminates the store worker process that was responsible for that database. Similarly, when a database gets mounted, the store service process brings a new store worker process for that database. The store service process is a controller of all the other store worker processes.

The question I got from Simon (via email) was about finding a way to determine which store worker process handled a mailbox database. In short, he wanted to map all the mailbox databases to it’s store worker process. Let’s find out how easy it is.

I have three databases mounted on my server.

As you would expect, I have a single store service process and three worker processes.

I can find out the process ids of the worker processes using the Details tab of the task manager, but it doesn’t tell me which worker process maps to which database.

In order to find the mappings, launch Exchange Shell & run the command below.

Get-MailboxDatabase –Status | ft name, workerprocessid

Now that you have the store worker process & the process id from the task manager and database name & process id from the Shell, it is easy to find out which worker process is handling which database. In my case, worker process with pid 5764 maps to DB1, 8872 to DB2 & 8608 to DB3.

If you find that one store worker process is hot on CPU or memory, you can find the database behind it this way and take administrative action.