Get-ExchangeDiagnosticInfo: Deep dive

In a previous post here, I wrote about a few basic commands, which are useful to quickly gather information about transport component of an Exchange server.

In this post I want to give you a deep dive about it and how you can explore what the CmdLet can do for you as it evolves in each Exchange version and can be very useful.

Gather all available processes

When you start you need to know, which processes are exposed to it. You can easily check what’s available with the following command

([xml](Get-ExchangeDiagnosticInfo)).diagnostics.ProcessLocator.process | sort name | select name -Unique


Depending on your configuration you might get a different result. In this case, it’s a server in my productive environment and I get a total of 38 processes returned.


Now as you know what processes can be queried, you can start digging into those. I don’t pick MSExchangeSubmission as this was already covered in my other post. As an example I pick a more interesting one: MSExchangeMailboxReplication

In this example I store the output into a variable $diag:

$diag = ([xml](Get-ExchangeDiagnosticInfo -Process MSExchangeMailboxReplication )).Diagnostics

In the variable I have now two root nodes: ProcessInfo and Components


ProcessInfo contains detailed information, but Components is much more interesting. It contains much more details:

  • ADDriver
  • ProcessModuleInfo
  • ThreadStacks
  • SystemWorkloadManager
  • MailboxReplicationService
  • config
  • VariantConfiguration
  • AdminAuditLogHealth


Depending on process and components, you will find several nested information. Some of them will show you in a Help node, what Arguments are supported. Here I picked the component MailboxReplicationService


You can add supported arguments into your query as a parameter. In the following example I queried from the current resources MailboxReplicationService

Gathering data

([xml](Get-ExchangeDiagnosticInfo -Server $env:computername -Process MSExchangeMailboxReplication -Component SystemWorkloadManager -Argument Resource)).Diagnostics.Components.SystemWorkloadManager.Resources.Resource | ogv


Here you can see all Classification (Discretionary, InternalMaintenance, CustomerExpectation and Urgent). Also in what state they are. In this example the resource Processor is for the first three Classifications in either Critical,Overloaded or Full state.

Note: This server had mailbox moves ongoing. Otherwise you would see no load.

Tip: Did you realized the parameter -Server? You don’t have to run the command on the server. Rather define the parameter and gather data remotely.

The service keeps for a specific time old data. You can query these with the following command

([xml](Get-ExchangeDiagnosticInfo -Server $env:computername -Process MSExchangeMailboxReplication -Component SystemWorkloadManager -Argument History)).Diagnostics.Components.SystemWorkloadManager.History.Entry | select DateTime,type,ResourceKey,Classification,Load,Info | ogv


To get the current ResourceMetricPolicy

([xml](Get-ExchangeDiagnosticInfo -Process MSExchangeMailboxReplication -Component SystemWorkloadManager -Argument Policy)).Diagnostics.Components.SystemWorkloadManager.Policy.ResourcePolicy.ResourceMetricPolicy | ogv


Note: Yes, these values are not the original ones. We tweaked our policy, when we upgraded from Exchange 2010 to Exchange 2013 based on this KB article. But the values in the article are far too high. Be careful!

Another example is the following one. The command will list from the EWS component the current stats. Here you can see for instance, when someone runs over budget

([xml](Get-ExchangeDiagnosticInfo -Process MSExchangeServicesAppPool -Component EwsBudgetCache)).Diagnostics.Components.EwsBudgetCache.BudgetCacheHandlerMetadata.Budgets.BudgetHandlerMetadata | ogv


or Exchange Active Sync

([xml](Get-ExchangeDiagnosticInfo -Process MSExchangeSyncAppPool)).Diagnostics.Components.StandardBudgetCache.BudgetCacheHandlerMetadata.Budgets.BudgetHandlerMetadata | ogv


You want to know how all EAS devices from all mailboxes on a server sync?

([xml](Get-ExchangeDiagnosticInfo -Process MSExchangeSyncAppPool)).Diagnostics.Components.AirSyncDeviceHealth.ArrayOfAirSyncDeviceHealth.AirSyncDeviceHealth | select StartTime,DeviceID,UserEmail,HttpStatus,AirSyncStatus,HasErrors,@{L="ErrorDetails";e={$_.ErrorDetails.ErrorDetail.ErrorMessage}},RequestTime,IsHanging,CommandName | sort StartTime| ogv



Get-ExchangeDiagnosticInfo is a very powerful CmdLet, which makes it possible for you to have a look behind the curtain. When you want to get data from the different Microsoft.Exchange.Store.Worker processes, you need to define the PID of the process.

I hope this helps and you find this post interesting.

1 thought on “Get-ExchangeDiagnosticInfo: Deep dive

  1. Pingback: Advanced troubleshooting calendar items | The clueless guy

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s