Workload Management in Exchange 2013

Workload Management (WLM) is a great new feature that was introduced with Exchange 2013 (well, ok to be fair Exchange 2010 introduced the concept of User throttling. Exchange 2013 simply builds on that). The function of WLM is basically to preserve the user experience by throttling other processes. It is comprised of both User-based throttling (not discussed on this post as it is detailed on TechNet fairly well) and System throttling. To achieve this, different workloads in Exchange are assigned different priorities. For example, mailbox moves are a lower priority workload than, say, Transport (after all, it IS important to get that new email from your favorite coupon site, right?!?).

Starting with RTM and up through CU5, managing System Workload Management settings were available via the following cmdlets

*-ResourcePolicy
*-WorkloadManagementPolicy
*-WorkloadPolicy

WorkloadPolicy defined the classifications for various different workloads. Examples of Classifications include InternalMaintenance, CustomerExpectation, Discretionary and Urgent.

ResourcePolicy defined the Thresholds for the various classifications upon which those workload types would begin to be throttled (micro-delayed).

WorkloadManagementPolicy simply links the two together.

However, starting with CU6, these cmdlets disappeared, and the TechNet links were removed and replaced with this simple statement found here

Note:

The *-ResourcePolicy, *-WorkloadManagementPolicy and *-WorkloadPolicy system workload management cmdlets have been deprecated. System workload management settings should be customized only under the direction of Microsoft Customer Service and Support.

That is all fine and good (after all, I work in CSS!). But for a while, even I didn’t know how to view what the current settings were!!!

Alas – nothing (well, ALMOST nothing) can remain hidden forever. And so I found that the System workload management settings are now visible by using Get-ExchangeDiagnosticInfo. Now I do want to add a caveat here that this blog post will not provide information on how to modify System Workload Policies. However, I felt like it was important to be able to view what the current settings are so that you can understand why certain workloads might end up getting throttled.

If you haven’t already had the pleasure of using Get-ExchangeDiagnosticInfo, there is a lot of information available. I won’t delve in to everything that can be retrieved, but rather will focus on the System Workload policy-related information.

The general syntax to view System Workload policy information is

Get-ExchangeDiagnosticInfo –server <server> -process MSExchangeMailboxAssistants –Component SystemWorkloadManager –Argument policy

However – you will probably notice that the output from this cmdlet is XML format, which is, well, ugly to read. Lets clean it up a little, shall we? Define a variable for your command, and specify the format as XML so Powershell can format it.

[xml]$diag = Get-ExchangeDiagnosticInfo –server <server> -process MSExchangeMailboxAssistants –Component SystemWorkloadManager –Argument policy

Now that we have the data stored in memory, we can look at the components. The Policy is actually comprised of several sub-components. Lets look at the Resource policy portion first. This shows the Metric types (core resources that we measure the health of)

$diag.diagnostics.components.systemworkloadmanager.policy.resourcepolicy

Now notice that the ResourcePolicy actually has a property that is multivalued. We can look at that in more detail and see that each metric type has different values for each classification type. This is what allows workloads with a classification of a higher priority to continue working while those with a lower priority are throttled (micro-delayed).

$diag.diagnostics.components.systemworkloadmanager.policy.resourcepolicy.resourcemetricpolicy | ft

Finally, we can view the workload policy, which provides the list of each defined workload type and the respective classification.

$diag.diagnostics.components.systemworkloadmanager.policy.workloadpolicy

Enjoy!