Configuring Lync Server 2010/2013 for integration with Exchange Online for UM is a relatively straight forward process. You need a Lync Edge server, federation enabled, proper external DNS SRV records, the appropriate Hosted Voicemail Policy configuration applied to the on-premise Lync environment, and the Exchange Online UM dial plan configured appropriately. Despite having all that configured, I ran into an interesting issue with a Lync 2010 deployment that prevented calls from being routed to Exchange Online UM.
The Lync 2010 servers were all running the October 2012 Cumulative Update and the Lync 2010 clients were all running the latest Cumulative Update from July 2013. Every attempt to dial voicemail directly from the Lync 2010 client resulted in a failure, and an odd SIP 500 error in the tracing logs:
Peer: lyncedgepool01.corp.widgets.com:5061 Message-Type: response Start-Line: SIP/2.0 500 The server encountered an unexpected internal error From: “xxxx, xxxx”<sip:raj@widgets.com>;tag=ba26f8512a;epid=955dceba2a To: <sip:raj@widgets.com;opaque=app:voicemail>;tag=2C5FF02E42C3DDCA8E3E0A5C47158DA3 CSeq: 1 INVITE Call-ID: 100dd855adb04bfbaeafe56658380950 Via: SIP/2.0/TLS 172.20.18.68:56578;branch=z9hG4bK2415C5DE.E7A3270075FF503C;branched=TRUE;received=172.20.1.14;ms-received-ort=56578;ms-received-cid=5CF6F00 Via: SIP/2.0/TLS 172.17.98.94:54425;ms-received-port=54425;ms-received-cid=A3FC600 ms-diagnostics: 1008;reason=”Unable to resolve DNS SRV record”;domain=”widgets.com”;source=”ocsaccess.widgets.com” Server: RTC/4.0 Content-Length: 0 ms-edge-proxy-message-trust: ms-source-type=EdgeProxyGenerated;ms-ep-fqdn=Lyncedgepool01.corp.widgets.com;ms-source-verified- user=verified
What made this odd is that this type of DNS SRV check should not be performed for outbound calls to Exchange Online, especially when this check was for the primary SIP domain configured within Lync. It was very obvious that this issue revolved around the federation logic within Lync so I went round and round on this, double-checking configuration after configuration to verify that I didn’t have something incorrect. Federation was definitely working externally and everything else checked out OK, so I had do to some extra digging.
After consulting with a colleague it turns out we ran into a similar, but not exact issue with a different client. In that issue, the resolution was to simply install the latest cumulative update, which at the time was the March 2013 CU. Following the CU update their issue was resolved, so I requested the installation of the July 2013 CU on my customer’s environment. My client installed the July 2013 CU on their Lync 2010 front-end servers and edge servers and immediately after, voicemail calls began to flow as expected and integration with Exchange Online UM was working. Success!!!
Moral of the story: patches sometimes contain undocumented fixes so don’t ever think a new patch wouldn’t potentially solve an odd issue! Stay as up to date as possible and if issues arise, it might be time to update!