Submit a ticketCall us

WebinarUpcoming Webinar: How Help Desk and Remote Support Pays for Itself

Learn how help desk software can simplify ticketing management, allow you to track hardware and software assets, and accelerate the speed of IT support and service delivery. Gain insights on how remote support tools allow your IT team to maximize their efficiency and ticket resolution by expediting desktop troubleshooting, ultimately helping keep end-users happy and productive.

Register here.

Home > Success Center > Server & Application Monitor (SAM) > AppInsight for Exchange error: The WinRM client received an HTTP bad request status (400), but the remote service did not include any other information about the cause of the failure

AppInsight for Exchange error: The WinRM client received an HTTP bad request status (400), but the remote service did not include any other information about the cause of the failure

Updated July 12, 2018

Overview

This article provides various methods you can use to resolve the following AppInsight for Exchange error: 

The WinRM client received an HTTP bad request status (400), but the remote service did not include any other information about the cause of the failure.

Environment

  • SAM 6.2 and later
  • AppInsight for Exchange

Cause  

The issue could be due to application pools, authentication settings, or other issues.  

Resolution

Consider the following resolutions.

Start/Stop Application Pools

Restart the following application pools that are responsible for PowerShell web endpoints:

  • MSExchangePowerShellAppPool
  • MSExchangePowerShellFrontEndAppPool

To restart an application pool:

  1. Open IIS Manager on the Orion server. See How to: Open IIS Manager (© 2018 Microsoft Corp., available at https://msdn.microsoft.com, obtained on July 12, 2018).

  2. In the Connections pane, expand the server node and click Application Pools.

  3. On the Application Pools page, select the application pool you want to start or stop.

  4. In the Actions pane, you can either:

    • Click Start to start the application pool.
    • Click Stop to stop the application pool.

Cycle Application Pools

To cycle application pools, open IIS Manager on the Microsoft Exchange server, recycle the following application pools, and wait 10 to 20 minutes for the next poll to run.

  • MSExchangePowerShellFrontEndAppPool (Default Web Site\PowerShell application pool)
  • MSExchangePowerShellAppPool (Exchange Back End\powerShell application pool)
  • MSExchangeOWAAppPool (Default Web Site application pool)
  • DefaultAppPool (Exchange Back End application pool)

Check PSLanguageMode

To check PSLanguageMode settings for both the Default Web Site and Exchange Back End websites:

  1. Run inetmgr on the Exchange server to open IIS Manager.
  2. Expand the tree to the Default Web Site/PowerShell virtual directory.
  3. Double-click Application Settings.
  4. Verify that the PSLanguageMode setting exists and is set to FullLanguage.
  5. If necessary, update the PSLanguageMode setting and click OK. See also Unable to setup PSLanguageMode setting for the PowerShell website.
  6. Restart the IIS server to recycle the application pool. 
  7. Repeat steps 2 through 6 for the Exchange Back End/PowerShell virtual directory.

Run Microsoft Windows updates

If there are pending Windows updates, reboot the Exchange server.

Make sure Windows Authentication is enabled

To verify that Windows Authentication is enabled for the Exchange PowerShell virtual directory:

  1. Start the Exchange management Shell (© 2018 Microsoft Corp., available at https://docs.microsoft.com, obtained on July 12, 2018). 
  2. Run the following command:

get-powershellvirtualdirectory -server <server name> | fl

 

image2015-2-5 17-42-18.png

 

  1. ​If WindowsAuthentication is set to False, switch it to True:

get-powershellvirtualdirectory -server <server name> | set-PowerShellVirtualDirectory -WindowsAuthentication $true

Check for a recent Cumulative Update 

Check if a Cumulative Update (CU) was applied to the Exchange Server before the error message appeared. If so, you may be able to resolve the error by:

  • Following the steps in this article to remove the WinRM HTTPS  listener and the old certificate.
  • Use the Configure Server option for the assigned application monitor, as described next..

If you are utilizing user-defined connection endpoint URLs, you'll need to configure the Exchange server manually. See Advanced Manual Configuration of AppInsight for Exchange.

To re-run Configure Server:

  1. In the Orion Web Console, navigate to Settings > All Settings > SAM Settings > Manage Application Monitors.
  2. Select the checkbox for the Microsoft Exchange monitor on the affected Exchange Server node.
  3. Click Edit Properties.
  4. Click Configure Server.

For more tips, visit the SolarWinds online IT community, THWACK, and read AppInsight for Exchange Stopped Working.

Check the order of authentication providers

The order of Windows authentication providers for the PowerShell website can cause HTTP bad request status (400) errors. Make sure NTLM is first

To check the order of authentication providers for the PowerShell website:

  1. Run inetmgr on the Exchange server to open IIS Manager.
  2. Expand the server and then expand Websites.
  3. Click Powershell.
  4. In the view that appears, select Group by: Area.
  5. In the IIS Section, double-click Authentication.
  6. Right-click Windows Authentication.
  7. Select Providers...
  8. Ensure NTLM is above Negotiate and Negotiate: Kerberos.

Use FQDN

Only use this workaround if all other solutions do not resolve the issue.

To use FQDN instead of IP addresses in the endpoint URLs:

  1. In the Orion Web Console, navigate to Settings > All Settings > SAM Settings > Manage Application Monitors.
  2. Select the checkbox for the Microsoft Exchange monitor on the affected Exchange Server node.
  3. Click Edit Properties.
  4. Replace ${IP} macro with the server FQDN in both URLs at the top of the page.
  5. Scroll to the page bottom and submit changes.

 

Disclaimer: Please note, any content related to third-party products posted herein is provided as a suggestion or recommendation to you for your internal use. Your organization should internally review and assess to what extent, if any, such custom scripts or recommendations will be incorporated into your environment.  You elect to use third party content at your own risk, and you will be solely responsible for the incorporation of the same, if any.

Last modified

Tags

Classifications

Public