Hide this message
Looking to compare latest NPM features with previous versions of NPM?
The NPM new feature summary offers a comparison of new features and improvements offered with this release.
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.
Consider the following resolutions.
Restart the following application pools that are responsible for PowerShell web endpoints: MSExchangePowerShellAppPool and MSExchangePowerShellFrontEndAppPool
The following steps are recommended per Microsoft troubleshooting.
Open IIS Manager.
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, use one of the following procedures:
Go to the Exchange Server IIS Manager, recycle following application pools and wait 10-20 minutes:
Check PSLanguageMode settings for both the Default and Exchange Back End websites:
If there are pending Windows Updates, simply reboot the Exchange Server.
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
If it appears as False, switch
get-powershellvirtualdirectory -server <server name> | set-PowerShellVirtualDirectory -WindowsAuthentication $true
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.
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
Only use this Workaround if all other solutions do not resolve the issue.
Use FQDN instead of IP addresses in the endpoint URLs: