Submit a ticketCall us

Don’t fall victim to a ransomware attack
Backups are helpful, but sometimes that’s not enough to protect your business against ransomware. At our live webcast we will discuss how to protect against ransomware attacks with SolarWinds® Patch Manager and how to leverage log data to detect ransomware. Register now for our live webcast.

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: 3-29-2017

Overview

This article provides brief information and steps 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.

The issue could be due to application pools, authentication settings, or other issues. The article includes multiple options for resolving the issue.

Environment

  • All SAM versions
  • AppInsight for Exchange

Resolution

Consider the following resolutions.

Start/Stop Application Pools

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

The following steps are recommended per Microsoft troubleshooting.

  1. Open IIS Manager. 

  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, use one of the following procedures:

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

Cycle Application Pools

Go to the Exchange Server IIS Manager, recycle following application pools and wait 10-20 minutes:

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

Check PSLanguageMode

Check PSLanguageMode settings for both the Default and Exchange Back End websites:

  1. Run inetmgr on Exchange Server.
  2. Go to PowerShell application under the Default website.
  3. Check that PSLanguageMode is not missing or is not set to RestrictedLanguage.
  4. If it is not there or isn't set to FullLanguage, run the configuration from the edit application page, this should fix settings.
  5. Restart IIS server. 

Run Windows Updates

If there are pending Windows Updates, simply reboot the Exchange Server.

Check Windows Authentication

Check that Windows Authentication is enabled on Exchange PowerShell virtual directory:

Start Exchange management Shell and run the following command:

get-powershellvirtualdirectory -server <server name> | fl

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

​If it appears as False, switch WindowsAuthentication to true:

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

Check Cumulative Update

Check if CU (Cumulative Update) has been applied to the Exchange Server before the issue occured.

If it has been applied, re-run Configure Server on Exchange AppInsight set up AFTER removing the WinRM HTTPS  listener and removing the old certificate following this article and re-establish connection.

It might take a few tries as it is dependent on the response of the Exchange server.

  1. Access Orion Web Console.
  2. Settings > SAM Settings > Manage Application Monitors.
  3. Select checkbox of Microsoft Exchange belonging to the affected Exchange Server Node.
  4. Click on Edit Properties.
  5. Click Configure Server and let it complete.

Check order of authentication

There can be issues with the order of Authentication in the Powershell website. Ensure NTLM is first in order of Authentication for the Powershell website via the following

  1. Open a command prompt and run: inetmgr.
  2. Expand your Website.
  3. Click on Powershell.
  4. In the view, select Group by: Area.
  5. Under 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.

Use FQDN instead of IP addresses in the endpoint URLs:

  1. Go to edit application page.
  2. Replace ${IP} macro with the server FQDN in both URLs on the page top.
  3. Scroll to the page bottom and submit changes.

 

Last modified
10:32, 29 Mar 2017

Tags

Classifications

Public