We are running Exchange Server 2013 CU23 on all servers and recently when trying to perform an eDiscovery search in the Compliance Management section of the Exchange Admin Center it reported an error “The request failed. The remote server returned an error: (400) Bad Request.”
I got this error as soon as I selected the Compliance Management section and even if I manage to create an eDiscovery search it would fail at the last step with the same error. The error was not specific to any server but happened across all the Exchange 2013 servers in the environment.
If I try to execute the cmdlet Get-MailboxSearch or New-MailboxSearch it would also return the same error. The error returned in Event Viewer is as shown below:
Microsoft.Exchange.Data.DataSourceOperationException: The request failed. The remote server returned an error: (400) Bad Request. ---> Microsoft.Exchange.WebServices.Data.ServiceRequestException: The request failed. The remote server returned an error: (400) Bad Request. ---> System.Net.WebException: The remote server returned an error: (400) Bad Request.
Upon researching about this error we came across this MS thread which discussed the same issue. We ran the below command on our multi-role Exchange 2013 server to check the existing values configured on the InternalNLBBypassUrl parameter of the EWS frontend and backend website:
Get-WebServicesVirtualDirectory -ShowMailboxVirtualDirectories -Server ServerName | fl identity,*url*
As you see, the InternalNLBBypassUrl on the EWS Default Web Site and Back End website is populated with a value. However, this is different from the default configuration of the EWS virtual directories as per Microsoft. According to Microsoft, the correct configuration for the Default Web Site’s InternalNLBBypassUrl is “Null”. And since the Back End website listens on TCP 444 the format should be https://serverfqdn:444/ews/exchange.asmx. ie, it should look like below configuration:
So to fix the issue, first correct the InternalNLBBypassUrl value on the EWS Default Web Site. Launch the Exchange Management Shell and execute the below command
Set-WebservicesVirtualDirectory -Identity “Servername\EWS (Default Web Site)” –InternalNLBBypassUrl $null
Secondly, correct the InternalNLBBypassUrl value on the EWS Back End website. This has to be done using PowerShell by loading the Exchange PowerShell Snapin. This is because running the same command on Exchange Management Shell will fail with an error mentioning that the operation is outside the users’s write scope. Also, keep in mind that modifying the back end website using this method maynot be supported by Microsoft.
Launch Windows Powershell as an Admin and execute the below commands:
Add-PsSnapin *Exch*
Set-WebservicesVirtualDirectory -identity “ServerName\EWS (Exchange Back End)” –InternalNLBBypassUrl https://serverfqdn:444/ews/exchange.asmx
Now run the command to confirm if the changes have been applied:
Get-WebServicesVirtualDirectory -ShowMailboxVirtualDirectories -Server ServerName | fl identity,*url*
If in case the changes are not applied yet, you can Recycle the MSExchangeServicesAppPool from IIS.
Navigate to the Exchange Admin Center -> Compliance Management and make sure that you are no longer receiving the 400 error code.
Repeat the same steps for all the Exchange Servers in your environment. Ideally, if this setting is corrected on the Exchange Server that hosts the Arbitration mailbox or Discovery Search mailbox, the issue should get fixed. However, if this server is not available for any reason the mailbox might move to a different server and then there are chances you might notice the error again. So it is better to make the same changes on all the servers.
To check the location of the Arbitration Mailbox and Discovery search mailbox you can use the below commands:
Get-Mailbox -RecipientTypeDetails DiscoveryMailbox | select name,database
Get-Mailbox *Disc* | fl name,alias,servername
Get-Mailbox -Arbitration | fl Name,Database
In my case, couple of Exchange Servers were recently recovered due to corruption and after the disaster recovery steps, the default values were changed. So if your environment has any Exchange Servers recovered recently, just make sure that these values are configured correctly.
Anish Sam Johnes 