Lync On-Prem and Exchange UM Online

I recently set up Exchange Online for Unified Messaging for a Lync 2013 deployment that I didn’t build, and with which I didn’t have any familiarity.

After following the available documentation for this configuration (such as https://support.microsoft.com/en-gb/outlook ) calls were unable to reach Exchange Online’s Auto-Attendant or Subscriber Access numbers. And it wasn’t just a voicemail route, even calling the Contact objects I’d created with New-CsExUmContact would fail instantly.

Running a trace from the server resulted in:

ms-diagnostics:  1003;reason=”User does not exist”;destination=”+9000@domain.com“;source=”sip.domain.com”

This gave me the impression that communication was reaching Office 365, but was not recognized as valid.

I verified the Line URIs just to be sure, and everything looked good. So, I went back to the beginning and re-traced every step without uncovering any identifiable cause.

Looking for something to go on, and knowing that communication between Lync On-Premises and Office 365 occurs through the federation data path, I thought I’d verify that federation was, in fact, working.

An external federated party was able to successfully initiate an IM without issue. The same was not true in reverse. I finally had something to go on. Outbound federation requests were failing (with the same error I’d seen from Exchange Online).

This pointed me to the Edge servers and name resolution, since successful federation depends on the existence and proper configuration of SRV DNS records. I updated the DNS configuration for the external facing interfaces and suddenly calls starting flowing to Exchange Online as expected.

For a while.

Eventually, success appeared intermittent. Calls from one user would complete, while calls from others would not. Some more digging eventually let me to discover that the network configuration of the second Edge server was incorrect (specifically, it had two gateways, and the internal interface had a lower metric than external).

Once that was corrected, calls started flowing consistently.

Yet another lesson that without sound network connectivity and routing, and proper name resolution, Lync just won’t function as expected or designed.

Shane Skriletz, PEI