Users from a federated organization cannot see the free/busy information of anotherExchange organization

When you configure a federation trust between a local Microsoft Exchange Server organization and a remote Exchange Server organization, users from cannot see the free/busy information of the users in the remote organization.

Additionally, the following errors are logged in the event log on the local Exchange server:

Also, HTTP 500 responses returned for Availability requests on the remote forest Exchange server are logged as follows in the W3SVC logs:

Cause

This issue occurs because the WSSecurity property of the "EWS" virtual directory or the "Autodiscover" virtual directory is disabled on the Client Access servers in the local Exchange Server 2010 organization.

Resolution

Exchange 2016 or Exchange 2013
To resolve this issue, reset the WSSecurity authentication for the virtual directories on the Exchange Back End site for each server in the remote organization.

Open Windows Powershell and add the Exchange Management snap-in.
```
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn 
```
Disable WSSecurity authentication for the EWS virtual directory using the Set-WebServicesVirtualDirectory cmdlet.
```
Set-WebServicesVirtualDirectory "<ServerName>\ews (Exchange Back End)" -WSSecurityAuthentication:$False 
```
Enable WSSecurity authentication for the EWS virtual directory using the Set-WebServicesVirtualDirectory cmdlet.
```
Set-WebServicesVirtualDirectory "<ServerName>\ews (Exchange Back End)" -WSSecurityAuthentication:$True 
```
Disable WSSecurity authentication for the Autodiscover virtual directory using the Set-AutodiscoverVirtualDirectory cmdlet.
```
Set-AutodiscoverVirtualDirectory "<ServerName>\Autodiscover (Exchange Back End)" -WSSecurityAuthentication:$False 
```
Eable WSSecurity authentication for the Autodiscover virtual directory using the Set-AutodiscoverVirtualDirectory cmdlet.
```
Set-AutodiscoverVirtualDirectory "<ServerName>\Autodiscover (Exchange Back End)" -WSSecurityAuthentication:$True 
```

Restart the application pools using the Restart-WebAppPool cmdlet.

Restart-WebAppPool MSExchangeAutodiscoverAppPool
Restart-WebAppPool MSExchangeServicesAppPool

Exchange 2010
To resolve this issue, reset the WSSecurity authentication for the virtual directories on each Client Access server in the remote organization.

Open the Exchange Management Shell.
Disable WSSecurity authentication for the EWS virtual directory using the Set-WebServicesVirtualDirectory cmdlet.
```
Set-WebServicesVirtualDirectory "<ServerName>\ews (Default Web Site)" -WSSecurityAuthentication:$False 
```
Enable WSSecurity authentication for the EWS virtual directory using the Set-WebServicesVirtualDirectory cmdlet.
```
Set-WebServicesVirtualDirectory "<ServerName>\ews (Default Web Site)" -WSSecurityAuthentication:$True 
```
Disable WSSecurity authentication for the Autodiscover virtual directory using the Set-AutodiscoverVirtualDirectory cmdlet.
```
Set-AutodiscoverVirtualDirectory "<ServerName>\Autodiscover (Default Web Site)" -WSSecurityAuthentication:$False 
```
Enable WSSecurity authentication for the Autodiscover virtual directory using the Set-AutodiscoverVirtualDirectory cmdlet.
```
Set-AutodiscoverVirtualDirectory "<ServerName>\Autodiscover (Default Web Site)" -WSSecurityAuthentication:$True 
```

Restart the application pools using the follow syntax:

appcmd stop appPool /appPool.name:MSExchangeAutodiscoverAppPool
appcmd start appPool /appPool.name:MSExchangeAutodiscoverAppPool

appcmd stop appPool /appPool.name:MSExchangeServicesAppPool
appcmd start appPool /appPool.name:MSExchangeServicesAppPool

Properties

Article ID: 2752387 - Last Review: Sep 23, 2016 - Revision: 1

Applies to

Exchange Server 2010 Enterprise, Exchange Server 2010 Standard, Exchange Server 2016 Enterprise Edition, Exchange Server 2016 Standard Edition, Exchange Server 2013 Enterprise, Exchange Server 2013 Standard Edition

Feedback

Was this information helpful?