by Phoummala Schmitt
Exchange Federation is a trust relationship between two Exchange server organizations. This trust allows the two Exchange organizations to share free busy information and calendar sharing. This is great for businesses that want to collaborate together, but do not want to establish an AD trust since configuring AD trusts can be complicated. Exchange federation trusts are much simpler to configure and set up, but not without issues though.
I recently ran into a problem with an existing Exchange Federation trust that was already an established for a few years, but all of a sudden the trust relationship seemed to be broken. It was a one way issue, the federating partner could see all details, but the one side limited details. On the side that was “broken”, Free/Busy information was visible in Outlook web access but an odd behavior was the outlook clients could not see free busy information.
[wp_ad_camp_1]
When troubleshooting Exchange federation issues one of the first steps to take is too run the following cmdlet in PowerShell: test – organizationrelationship. The test-organizationrelationship does not test functional parts of Federation, such as calendar sharing, it just testing if the configurations are correct. If the configuration is not correct then obviously your organizational relationship with the partnering company is probably not going to work. To run the test use the following:
Test-OrganizationRelationship –UserIdentity [email protected] –Identity “name of the relationship” –verbose
Before using this command let’s discuss it’s parts. The UserIdentity parameter is the account for which a security token will be requested during the test. Also important to understand is that the Identity is the name of the organization relationship which you are testing against.
So in this particular issue, after running the test-organizationrelationship command we saw that the test could not verify and make an SSL connection. Ah ha!
The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. —> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.
What we learned is that there was an issue with the certificate on the remote Exchange environment and it could not be validated on our side. To verify a certificate issue you can try to access the Exchange Web Services of the other Exchange environment by browsing to https://mail.theirdomain/com/ews/exchange.asmx/WSSecurity . If you get a certificate warning then you have confirmed that the certificate from the remote environment is not trusted by the local Exchange environment or there could be something changed with the certificate.
In this recent case it was determined that the Root CA and Intermediate certificates were not trusted. To fix this issue is simple. Obtain the remote Exchange server’s certificates (root CA & intermediate included), and import into each of the CAS server’s local certificate store.
Once the certificates have been imported you can run another test-organizationrelationship, and see that the test is successful. Check free/busy in outlook and it should be working again.