Using the Exchange Server 2013 Management Pack for Troubleshooting
Topic Last Modified: 2013-04-09
Getting Started with Exchange Server 2013 Management Pack provides an overview of the management pack dashboard. This topic walks you through how it can help you troubleshoot a problem. The process is best illustrated with an example. Consider the following scenario:
Rob Fielder is an Exchange administrator at Contoso. He opens the SCOM Console and click on the Server Health in the Exchange Server 2013 dashboard to check the status of his Exchange servers. He notices a critical state for the Service Components on one of his CAS servers.
Rob double-clicks on the server which opens the Health Explorer window. In this window he can see that the service component that is in an unhealthy state is the OWA.Proxy health set. He click on it to see the relevant information for this health set.
The link provided under External Knowledge Resources takes Rob to the Troubleshooting OWA.Proxy Health Set topic. In this article, Rob sees that the first thing to do is to verify that the issue still exists. Following the instructions, he runs the following command to verify the current state of the OWA.Proxy health set in the Shell:
Running this command gives him the following output:
Server State Name TargetResource HealthSetName AlertValue ServerComp onent ------ ----- ---- -------------- ------------- ---------- ---------- Server1 Online OWAProxyTestMonitor MSExchangeOWAAppPool OWA.Proxy Unhealthy OwaProxy Server1 Online OWAProxyTestMonitor MSExchangeOWACale... OWA.Proxy Healthy OwaProxy
Rob sees that the problem lies within the OWA Application Pool. The next step is to rerun the associated probe for the monitor that is in unhealthy state. Using the table in the “Troubleshooting OWA.Proxy Health Set” topic, he determines that the probe that he needs to rerun is OWAProxyTestProbe. He runs the following command:
Invoke-MonitoringProbe OWA.Proxy\OWAProxyTestProbe -Server Server1.contoso.com | Format-List
He scans the output for the ResultType value and sees that the probe failed:
ResultType : Failed
He proceeds to the “OWAProxyTestMonitor Recovery Actions” section of the article. He connects to Server1 using IIS Manager to see if the MSExchangeOWAAppPool is running on the IIS Server. Once he verifies that it is running, the next step instructs him to recycle the MSExchangeOWAAppPool:
C:\Windows\System32\Inetsrv\Appcmd recycle APPPOOL MSExchangeOWAAppPool
After seeing that the MSExchangeOWAAppPool is successfully recycled, he goes back to verifying if the issue still exists by rerunning the probe using the Invoke-MonitoringProbe cmdlet and this time sees that the result is successful. He then runs the following command to verify that the health set is reporting Healthy status again:
This time he sees that the problem is resolved.
Server State Name TargetResource HealthSetName AlertValue ServerComp onent ------ ----- ---- -------------- ------------- ---------- ---------- Server1 Online OWAProxyTestMonitor MSExchangeOWAAppPool OWA.Proxy Healthy OwaProxy Server1 Online OWAProxyTestMonitor MSExchangeOWACale... OWA.Proxy Healthy OwaProxy
He goes back to the SCOM console and verifies that the issue is resolved.
The scenario covered above is a simple demonstration of the troubleshooting workflow when you see an alert in the SCOM console. Even though the details will vary, you will generally follow a similar troubleshooting workflow for each problem reported in the console.