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

DiagDeep_01.png

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.

Exploring

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

DiagDeep_02.png

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

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

DiagDeep_03.png

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

DiagDeep_04.png

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

DiagDeep_05.png

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

DiagDeep_06.png

To get the current ResourceMetricPolicy

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

DiagDeep_07.png

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

DiagDeep_08.png

or Exchange Active Sync

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

DiagDeep_09.png

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

DiagDeep_10.png

Conclusion

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.

Advertisements

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s