Identifying IIS Worker Process in Exchange 2013/2016

It might come a time when troubleshooting performance issues where we need to identify exactly what a particular IIS Worker Process is in an Exchange 2013 environment:

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 IIS Worker Process we are trying to identify is 10300:

Now open a Command line or PowerShell console, navigate to Windows\System32\Inetsrv and then run the command “appcmd list wp” or “.\appcmd list wp” if you are using PowerShell:

We now know that the IIS Worker Process with the PID of 10300 is the Exchange OWA Application Pool.

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.

Exchange 2013 EAC Performance Console

Almost 3 years ago, on my Exchange 2010 ECP Performance Console article on MSExchange.org, I explored the Performance Console of the Exchange Control Panel in Exchange 2010. Did you know that this console is still present in Exchange 2013?

 

This console, which is not visible by default, provides numerous counters regarding the performance of the EAC. We can use it to check how long it takes to authenticate a user, how many PowerShell cmdlets have been invoked and even how long the server took to process requests, and much more.

 

To enable it, we have to manually edit the web.config file located at:

%ExchangeInstallPath%\V15\ClientAccess\ecp\web.config

 

Open the file with Notepad and look for the "appSettings" section, right in the first few lines. In there we will find the following key:

 

<!-- Set ShowPerformanceConsole to "true" to show ECP's Perf Console: -->
<add key="ShowPerformanceConsole" value="false" />

 

 

As the comment explains, all we have to do to enable the console is update the value of the ShowPerformanceConsole key from false to true. Save the file, run the usual IISRESET /NOFORCE to restart IIS and we are good to go!

 

If we now log in to the EAC, we will have a Performance console link:

 

Clicking on this link opens the console itself:

 

 

To learn more about this console, check my Exchange 2010 ECP Performance Console article at MSExchange.org.

Exchange 2013 Performance Health Checker Script

Microsoft has just published the Exchange 2013 Performance Health Checker script, which checks various configuration items on Exchange 2013 servers to make sure they match the recommendations published in the “Exchange 2013 Sizing and Configuration Recommendations” guidance on TechNet. It also reports on OS, system and hardware information. It can be ran remotely, against a single server or a group of servers.

 

The script takes some of the most common configuration causes of Exchange 2013 performance cases that Microsoft has encountered in support and allows administrators to rule them out quickly without having to check each server or read through the entire TechNet guidance.

 

 

The current list of items the script reports on is:

• Operation System version
• Exchange Build
• Physical/Virtual Machine
• Server Manufacturer and Model (physical hardware only)
• VM host processor/memory configuration recommendations
• Exchange server roles
• Pagefile Size
• Power Settings
• .NET Framework version
• Network card name and speed
• Network card driver date and version (Windows 2012 and Windows 2012 R2 only)
• RSS enabled (Windows 2012 and Windows 2012 R2 only)
• Physical Memory amount
• Processor Model
• Number of processors, cores, and core speed
• Hyper-threading enabled/disabled
• Processor speed being throttled
• Current list of active/passive databases and mailboxes (optional)

 

Let us look at some examples. First, we run the script without any parameters, meaning it will check the local server. We could use the –Server parameter to run it against a remote server.

By including the –MailboxReport parameter, the script presents some statistics around mailboxes and databases:

Another useful parameter is –LoadBalancingReport which looks at all CAS servers to determine how user connections are being load balanced across these servers. We can use the -CasServerList to specify which CAS servers we want to check.

Every time the script runs, it outputs the results to a log file as mentioned at the end of every output. In the next screenshot we can see the report from the cmdlet above:

Exchange 2010 Client Throttling Policies

Exchange 2007 introduced a feature called RPC Client Throttling to allow administrators to manage end-user performance by preventing client applications, such as Outlook for example, from sending too many Remote Procedure Call [RPC] requests per second to Exchange, causing the server to suffer in terms of performance. When Exchange determines that a client is having a negative effect on the server, it will send a "back-off" request to the client telling it to delay sending any additional requests for a specified time (maximum of 2000 milliseconds) in order to reduce the performance effect on the server.

In Exchange 2010, Client Throttling has been much improved, monitoring and controlling much more than just RPC requests. Its purpose is still to ensure that users are not intentionally or unintentionally straining Exchange and that users share resources proportionally.

In this article, we will explore Client Throttling Policies in Exchange 2010, what they are used for and how to change them if necessary.

For the full article, please click here: MSExchange.org.

Exchange 2010 ECP Performance Console

A hidden feature that most Exchange Administrators don't know about is the Exchange Control Panel [ECP] Performance Console.

This console, which is not visible by default, provides numerous counters regarding the performance of the ECP. We can use it to check how long it takes to authenticate a user, how many PowerShell cmdlets have been invoked and even how long the server took to process requests.

To learn more about this console and how to enable it, please check the Exchange 2010 ECPPerformance Console article on MSExchange.org