A co-worker of mined had attempted to put in a Exchange 2013 recently – in which causing the UM Server not to work unexpectedly. Although after cleaning up the Exchange 2013, we notice that:

  • Dialing to Voice Mail doesn’t to work anymore
  • Dialing to the Exchange Auto Attendant & Subscriber access seems to just “dropped”
  • Miss call notifications & voice mail no longer arrives in the mailbox

From the Exchange Server, such error kept surfacing when an attempt is made through the Lync Client

The following UM IP gateways did not respond as expected to a SIP OPTIONS request.

Transport = TLS, Address = LyncPoolServer.domain.com Port = 5061, Response Code = 0, Message = This operation timed out

UMNotWorking01

From the Lync Server:

Dial Plan Unknown

Dialplan [DialPlanName.domain.com] not recognized by routing application.

Cause: Dial plan does not exist, or Microsoft Lync Server 2013 does not have permission to read the relevant Active Directory objects.

Resolution: If the dial plan is valid, then run  exchucutil.ps1 in appropriate Exchange forest to give permission to Microsoft Lync Server 2013. If the dial plan is not valid, then clean up proxyAddress attribute for the affected users.

UMNotWorking01

As we suspected that during the Exchange 2013 installation, some of the permissions may have been reset or altered, causing the issue above, so we went ahead and re-run the script of ExchUCUtil.ps1 from the Exchange 2010 Unified Messaging role server and restarted the services.

However, the first error still appears and to confirm this, we’d to check the Dial Plans on the Exchange UM Server:

Get-UMIPGateway | fl

UMNotWorking03

Notice that the Port displays the value of 0 ; to solve this matter, we’d to manually assign the port number of 5061 to each Lync Server 2013:

Set-UMIPGateway -Identity LyncPool.domain.com -Port 5061

Next, a restart on the Microsoft Exchange Unified Messaging & Lync Server Front-End services will bring the Voice Mail back “alive”

The followings had also been conducted in the process of troubleshooting to make sure that the configuration are in-place:

  1. OcsUMUtil – refresh the data to make sure the Auto Attendant & Subscriber Access is still mapped to the correct objects
  2. Certificate – the subject name (SN) is match the FQDN of the UM Server (make sure the certificate is still valid!) and it is issued by the internal Microsoft Certificate Authority
  3. DNS Records – make sure the Lync Pool servers can be resolved with both its A & Reverse Records