Cloud Voicemail – Unable To Resolve DNS SRV Record

Cloud Voicemail as a part of Office 365 is becoming an increasingly popular way to provide voicemail features for Skype for Business on-premises. As more organisations make the move to Exchange Online, voicemail is also going in the same direction. During a recent deployment for customer, we encountered an issue whereby calls to Cloud Voicemail would fail to connect. The symptom was the standard ringing duration followed by a call drop at the point Cloud Voicemail should have answered.

Problem

In the Lync Server application event log on the Front End Server, we noted event ID 44009 LS Exchange Unified Messaging Routing being produced with a “no server in the dialplan” error. This is a common error when configuring the now retired Unified Messaging in Exchange Online, so why were we seeing this with the new Cloud Voicemail platform?

As this particular error did not provide any clue in relation to the underlying problem, we then turned our attention to the Centralised Logging Tool in order to take a debug trace. After running the Centralised Logging Tool on the Front End server using the “Voicemail” scenario along with selecting the Front End Server and Consolidated Edge as the servers to monitor, we identified the following:

There were two key parts we identified in this debug message that we believed contributed to the issue. The first was “Unable to resolve DNS SRV Record” and the second was the “msexchdomain=domain.local“. The DNS SRV record message was in fact a red herring, as federation between external domains worked perfectly fine. In addition, the required _sipfederationstls DNS record was in place and our Skype for Business to Microsoft Teams hybrid was also operational.

This turned our attention to the msexchdomain entry showing as “domain.local”, the customers internal Active Directory domain name. When the customer had originally deployed a Microsoft Lync Server 2010 solution many years ago, they had configured their primary SIP domain to be domain.local rather than their externally facing domain name. Despite the external facing domain name being configured as a secondary SIP domain in their Skype for Business topology, it was not set as the default domain.

Resolution

The resolution to this problem actually turned out to be quiet simple once the underlying cause had been found. The calls being sent to the Cloud Voicemail platform were being delivered with an msexchdomain of domain.local. This was not and cannot be configured in Office 365 as a domain due to this not being externally resolvable. As such, when the call was routed to Cloud Voicemail it was rejected as the domain.local was not a valid Microsoft Exchange domain in Office 365. To resolve the issue we performed the following actions.

1. Open the Skype for Business Server Management Shell.
2. Run “Get-CsSipDomain” and confirm the internal Active Directory domain name is in fact the default SIP Domain.
3. Run “Set-CsSipDomain -Identity externaldomain.co.uk -IsDefault $True”
4. Once replication has occurred, restart either the RTCCAA/RTCCAS services or simply reboot each Front End server.
5. Attempt an inbound call and let this go to voicemail, which should now connect correctly.

If you need help debugging a tricky Skype for Business issue, why not check out our technical support services and see how we can help you out. Alternatively, you can drop us a message with your requirement by using our handy contact form below.