Anyone who’s been in AD / Email migration business long enough, can appreciate Exchange cross-org (or on-prem to Online) Federated Calendar sharing feature. Old days of setting up plentitude of Calendar synchronization jobs are going away, and instead of delayed and sometimes not syncing properly Calendar updates we can now fetch live F/B directly from the other side org.
This capability existed before in a way of cross-org (cross-forest) Exchange Availability but now it became noticeably easier to setup and configure, plus having Contact objects in the local GAL no longer required to resolve F/B for the remote users. It is also not required to assign credentials of some service account who’s going to be involved in F/B exchange, Microsoft is now a security broker in this process. Here, I wanted to share some of my personal experience of working with this feature and going to describe its high level architecture, plus cover troubleshooting approach:
- Each Exchange organization participating in Calendar sharing needs to setup Federation Trust first. It can be done via PowerShell or in EAC on Organization Tab. At the beginning you will need to define primary shared Domain like @Contoso.com, and then add any other Domains which organization owns, for example Contoso.ca, Contoso.de and so on, as it’s quite common for companies to own more than just one Domain namespace these days. Without adding these additional namespaces Calendar sharing will only work for single primary namespace. During setup Microsoft will ask to add DNS txt record through your DNS hosting provider under each particular namespace to validate that you in fact own them. Note that Federation Trust is also created when running Hybrid Configuration Wizard as Calendar sharing is also how on-prem Exchange shares Calendar with Exchange online. Along with all namespaces, it also adds TargetAutodiscoverEpr which is Autodiscover entry point, for example: https://autodiscover.contoso.com/autodiscover/autodiscover.svc/WSSecurity
- Now on the same page in EAC | Organization page you can configure Calendar sharing with any organization which already has Federation Trust setup per #1. Setup is quite intuitive as Microsoft Federated Gateway (now called Azure Authentication System) already has all the information and only needs to know what namespace you are looking to setup Calendar sharing with.
So after doing all this, it’s supposed to start working right away but technology does not always cooperate, or else we’d be out of our jobs 🙂 What can go wrong?
Firewalls and proper Communications are normally the key. Exchange needs to reach out externally to Azure Authentication System to obtain delegation token, and then resolve opposite side EWS entry point via Autodiscover. The latter can reside either external or internal to the corporate network. It will work either way as long as Exchange Availability service can get there and obtain a response. As an added flexibility, Calendar sharing settings allow modifying Autodiscover endpoint URL for the Target Exchange system, plus you can also change “hosts” file on Ex server (probably not best but still workable workaround) or even adding Primary DNS zone for autodiscover.contoso.com / ews.contoso.com with single “A” HOST record for opposite side Exchange Autodiscover / EWS listener.
How best to troubleshoot Federated Calendar Sharing?
A. Look into Application log on Exchange server after doing F/B lookup in Outlook or OWA.
Example: Process 5868: ProxyWebRequest FederatedCrossForest from S-1-5-21-252791234-3245363234-309073344-1234 to https://ews.contoso.com:443/EWS/jason.lee..contoso.com/Exchange.asmx/WSSecurity failed. Caller SIDs: WSSecurity. The exception returned is Microsoft.Exchange.InfoWorker.Common.Availability.ProxyWebRequestProcessingException: Proxy web request failed. —> System.Net.WebException: Unable to connect to the remote server —> System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 126.173.139.25:443
In this example EWS connection was resolving to external entry point which was locked to select IP addresses. However both Exchange orgs were already on the same local network (remember, we are doing on-prem migrations!) so we’ve implemented Primary DNS zone EWS.Contoso.com resolving to internal IP for an opposite side Exchange org instead. Other alternative would have been adding some more approved IP addresses on the external firewall.
Example: ProxyWebRequest FederatedCrossForest from S-1-5-21-1740863675-3465329846-2508926007-67471 to https://webmail.contoso.com:443/ews/joseph.howe..contoso.com/exchange.asmx/WSSecurity failed. Caller SIDs: WSSecurity. The exception returned is Microsoft.Exchange.InfoWorker.Common.Availability.ProxyWebRequestProcessingException: Proxy web request failed. —> System.Web.Services.Protocols.SoapHeaderException: An error occurred when verifying security for the message.
Lookin up above error message led to the below Microsoft KB, and after running series of Set-WebServicesVirtualDirectory “<ServerName>\ews (Exchange Back End)” -WSSecurityAuthentication:$False / $True commands on the opposite side Exchange system it resolved the issue.
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.
B. When doing F/B lookup via Scheduling Assistant in OWA, you can examine https communications using IE (EDGE) dev features. Click F12, go to Network, Start / Stop capture and review Response Body on GetUserAvailability https request. Error message in my example says: “WithoutFederatedProxyAddressException: User doesn’t have any SMTP proxy address from a domain that is federated.“
In this particular case below Microsoft article gave me some hint, but basically message itself was even more informative. My symptoms were inconsistent and F/B was working fine for most users while not working just for small bunch of migrated mailboxes. As it turns out, during migration we preserved original org SMTP address without letting Target org stamp any new proxy. So Ex Availability service did not like the fact that mailbox that was performing F/B lookup did not have any single smtp proxy of native Exchange org that was part of federation namespace. As soon as I added one of the local federated namespace as mailbox secondary proxy address, it was able to fetch F/B for it.
This issue occurs if the domain name for the Simple Mail Transfer Protocol (SMTP) address of the user who is trying to view the free/busy information isn’t included among the domain names in the organization relationship.
