How to determine which store worker process is responsible for which mailbox database?

As we all know by now, the Exchange Store service in Exchange 2013 has been rewritten in such a way that each database now runs under its own process, thus preventing store issues to affect all databases in the server. Managed Store is the new name for the rewritten Information Store process (store.exe). It is now written in C#, designed to enable a more granular management of resources (additional I/O reduction, for example) and is even more integrated with the Exchange Replication service (MSExchangeRepl.exe), in order to provide a higher level of availability.

The database engine continues to be ESE, but the mailbox database schema itself has changed in order to provide many optimizations.

The Managed Store is composed of two processes. The first one is the Store Worker Process (Microsoft.Exchange.Store.Worker.exe) that is similar to the old store.exe process. The difference is, as already mentioned, that there is one Store Worker Process for each database. This means that if one of these processes fails, only the database it is responsible for will be affected, while all the other databases will remain operational.

The second one is the Store Service Process (Microsoft.Exchange.Store.Service.exe) that controls all store worker processes. For example, when a database is mounted, the store service process will start a new store worker process for that particular database. On the other hand, when a database is dismounted, it will terminate the store worker process responsible for that database.

The question that sometimes arises is “how do we determine which store worker process is responsible for which mailbox database?” To show how to do this, I am going to use a test server where I have 2 mailbox databases, and therefore two Microsoft.Exchange.Store.Worker.exe):

First thing we need to do is get the Process ID (or PID). To do this, right-click on one of the columns and select PID:

 

 

We can now see that that PID for the store worker we are trying to identify is 3308:

 

Now open an Exchange Management Shell console and run the following cmdlet:

Get-MailboxDatabase -Status | Sort Name | FT Name, WorkerProcessID

 

We now know that the store worker process with the PID of 3308 is responsible for the mailbox database DB01.

How to Generate Exchange OAB Multiple Times a Day

The generation of the Offline Address Book (OAB) back in Exchange 2010 was based on a schedule set on the OAB’s properties. In Exchange 2013 (at least in CU9 at the time of writing this) and in Exchange 2016 "beta" we still see this property but it is no longer used:

 

 

Instead, Exchange Server 2013 OAB Generation takes place according to OABGeneratorWorkCycle and OABGeneratorWorkCycleCheckpoint properties configured at the Mailbox Server. According to TechNet:

• The OABGeneratorWorkCycle parameter specifies the time span in which the OAB generation on the Mailbox server will be processed. The default value is 8 hours;
• The OABGeneratorWorkCycleCheckpoint parameter specifies the time span at which to run OAB generation on the Mailbox server. The default value is 1 hour.

 

 

Maybe it is because English is not my first language, but it took me a while to understand exactly what the above means... Eventually I got to the conclusion that what the above text is trying to tell us is that, by default, Exchange updates the OAB every 8 hours. If I look at my environment, I can see this is indeed the case:

 

 

For organizations where recipients change at a considerable rate, this might not be ideal. Let us say that we want to want to update the OAB every 2 hours instead. To achieve this, we simply run the following cmdlet:

Set-MailboxServer “server” -OABGeneratorWorkCycle 00.02:00:00 -OABGeneratorWorkCycleCheckpoint 00:30:00

 

 

 

After a few hours, we can check the Application log and look for Event ID 17002 to ensure the OAB is actually being generated every two hours (Event ID 17001 shows when the generation started while 17002 when it completed):

 

 

 

Don’t forget that to set these properties across all your Mailbox servers that might be generating the OAB. The server hosting the arbitration mailbox with Persisted Capability “OrganizationCapabilityOABGen” is the one responsible for the OAB generation. For a non-DAG environment, you can use the following cmdlet to identify the OAB Generation server:

Get-Mailbox -Arbitration | Where {$_.PersistedCapabilities -match "oab"} | FT Name, ServerName

For a DAG environment, use the following one instead:

Get-Mailbox -Arbitration | Where {$_.PersistedCapabilities -match "oab"} | FT Name, Database

And then check which server currently has that database mounted:

Get-MailboxDatabaseCopyStatus “database”