Applications Systems
SAM AppInsight for Exchange / ARM Exchange Scan error: The WinRM client received an HTTP bad request status (400), but the remote service did not include other information about the failure
This article describes different ways to resolve the following AppInsight for Exchange and ARM Exchange Scan error that may appear in SolarWinds SAM and ARM: "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."
First published date
Last published date
Overview
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.
This will happen in the following environments:
- SAM 6.4 and later
- AppInsight for Exchange
- ARM Exchange Scan
Product section
Cause
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:
-
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).
-
In the Connections pane, expand the server node and click Application Pools.
-
On the Application Pools page, select the application pool you want to start or stop.
-
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
Run inetmgr on the Exchange server to open IIS Manager.To check PSLanguageMode settings for both the Default Web Site and Exchange Back End websites:
- Expand the tree to the Default Web Site/PowerShell virtual directory.
- Double-click Application Settings.
- Verify that the PSLanguageMode setting exists and is set to FullLanguage.
- If necessary, update the PSLanguageMode setting and click OK. See also Unable to setup PSLanguageMode setting for the PowerShell website .
- Restart the IIS server to recycle the application pool.
- 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:
- Start the Exchange management Shell (© 2018 Microsoft Corp., available at https://docs.microsoft.com, obtained on July 12, 2018).
- Run the following command:
get-powershellvirtualdirectory -server <server name> | fl
- 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 AppInsight for Exchange: WinRM testing failed with due to an expired SSL certificate 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:
- In the Orion Web Console, navigate to Settings > All Settings > SAM Settings > Manage Application Monitors.
- Select the checkbox for the Microsoft Exchange monitor on the affected Exchange Server node.
- Click Edit Properties.
- 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:
- Run inetmgr on the Exchange server to open IIS Manager.
- Expand the server and then expand Websites.
- Click Powershell.
- In the view that appears, select Group by: Area.
- In the IIS Section, double-click Authentication.
- Right-click Windows Authentication.
- Select Providers...
- 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:
- In the Orion Web Console, navigate to Settings > All Settings > SAM Settings > Manage Application Monitors.
- Select the checkbox for the Microsoft Exchange monitor on the affected Exchange Server node.
- Click Edit Properties.
- Replace ${IP} macro with the server FQDN in both URLs at the top of the page.
- Scroll to the page bottom and submit changes.