Share via

Error 5016 Exchange Free Busy

  • Article

 

Issue:

 

Error 5016 exchange free busy,  Can't  see free busy of other calendars

 

 

 

 

Background:

  1. First Reason: Certificate is not assigned appropriately to the Exchange services such smtp/IIS.
  2. Second Reason could be the Federated Trust between on-Premise and Exchange Online.

To use this feature several things will need to be configured:

  • trust with the Microsoft Federation Gateway.
  • organizational relationship must be configured.
  • autodiscover and EWS must allow WS Security authentication.

The proxy needs to allow unauthenticated traffic to the following url’s:

  • /EWS/exchange.asmx/WSSecurity.
  • /autodiscover/autodiscover.svc/WSSecurity.
  • /autodiscover/autodiscover.svc.

 

So we need to :

  • verify if autodiscover allows WS Security for authentication
  • verify the external EWS url
  • verify if Exchange Web Services will allow WS Security for authentication

 

 

Solution:

 

Solution 1: Verify Certificate

Import the certificate

Import-ExchangeCertificate -Path C:\CertificateFile.crt

Enable-ExchangeCertificate -Thumbprint paste_thumbprint_here -Services "SMTP, IMAP, IIS"

 

 

 

Solution 2: Verify AutodiscoverVirtualDirectory

 

Get-AutodiscoverVirtualDirectory|select server, WSSecurityAuthentication

 

Verify if the value of the column WSSecurityAuthentication is set to true

 

Get-AutodiscoverVirtualDirectory|Set-AutodiscoverVirtualDirectory -WSSecurityAuthentication:$true

 

Using this cmdlet the authentication method will be configured but to offer this authentication type you will need to perform an IISReset. Additional you can verify if the svc-integrated handler is attached to the autodiscover virtual directory:

[

](https://johanveldhuis.nl/wp-content/uploads/2013/10/IIS.png)

 

 

Solution 3:Verify the Exchange Web Services

 

this can be done by using the Get-WebServicesVirtualDirectory cmdlet:

Get-WebServicesVirtualDirectory|select server, ExternalUrl, WSSecurityAuthenticationcmdle

 

WSSecurityAuthentication needs to be set to tru

In case that WSSecurity is not true enabled it by using the following cmdlet:

Get-WebServicesVirtualDirectory|Set-WebServicesVirtualDirectory -WSSecurityAuthentication:$true

 

If no external url is configured you will need to configure one

 

To verify if the certificate contains the correct names we will use Powershell again:

Get-ExchangeCertificate|? {$_.Services -like “*IIS*”}|select Subject, CertificateDomains|FL

Verify if the CertificateDomains contain the FQDN you are planning to use for EWS, for examplemail.domain.com of ews.domain.com. If this name is not on the certificate you will need to renew your certificate.

 

Get-WebServicerVirtualDirectory|Set-WebServicesVirtualDirectory -Externalurl “https://ews.domain.com/EWS/exchange.asmx”

 

Solution 4: verify the Federation Trust

 

This can be done by starting with Test-FederationTrustCertificate which will verify if the certificate used for the trust is correct and is installed on all CAS

 

Test-FederationTrustCertificate

 

Test-FederationTrust cmdlet to verify if the Federation Trust really works

 

Test-FederationTrust

 

Test-FederationTrust -UserIdentity user@domain.com

 

I also imported all the federation certificate in the new exchange server after exporting it from the old server

 

Solution 5:  verify the Organization Relationship

 

 not all domains are listed here it can cause strange issues such as it works for domain.

 

Make sure you add your  domain.com to the organizational sharing domains

 

Get-OrganizationRelationShip,  retrieves the current configuration

GetFederationInformation, will send an autodiscover request to the other organization to retrieve the configuration

 

The following parameters are important in this case:

DomainNames

TargetApplicationUri

TargetAutoDiscoverEpr

Solution 6: OU

Makesure that the users is in the OU that is synced with o365

 

Solution 7: Autodiscover

 

Check that the autodiscover URL  (autodiscover.muatazawad.com/Autodiscover/Autodiscover.xml ) is accessible internally and externally. If it is not accessible, check the authentication and  change the authentication for the autodiscover in IIS if it is needed.

 

 -WindowsAuthentication $false

-BasicAuthentication $false

-DigestAuthentication $true

 

Solution 8: Run the Hybrid Configuration Wizard

 

Run  the latest version of HCW on Exchange 2013.

 

Solution 8: Set-IntraOrganizationConnector

 

Set-IntraOrganizationConnector "MainCloudConnector" -Enabled $false

 

Reference:

How to troubleshoot free/busy issues in a hybrid deployment of on-premises Exchange Server and Exchange Online in o365

From <https://support.microsoft.com/en-us/kb/2555008>