Several months ago I deployed a greenfield Lync Server 2013 organisation with Enterprise Voice with voice-mail via Exchange Server 2013 (also used for email services) for a non for profit client. It was the final stages of deployment and the remaining piece of the puzzle was to complete the voice-mail configuration via Exchange UM roles (the UM service and UM Router on respective Exchange Server 2013 roles: CAS and MB). However, with the days of project consulting winding down and deadlines approaching, a problem popped up that took the wind out of my sails.
On the Lync enterprise front end pool I was receiving numerous errors as follows:
Source: LS Exchange Unified Messaging Routing Event ID: 44022 Description: An attempt to route to an Exchange UM server failed. Cause: An attempt to route to an Exchange UM server failed because the UM server was unable to process the request or did not respond within the allotted time. Resolution: Check this server is correctly configured to point to the appropriate Exchange UM server. Also check whether the Exchange UM server is up and whether it in turn is also properly configured.
As well as:
Source: LS Exchange Unified Messaging Routing Event ID: 44009 Description: Attempts to route to servers in an Exchange UM Dialplan failed. No server in the dialplan [SERVER] accepted the call with id [id]. Cause: Dialplan is not configured properly. Resolution: Check the configuration of the dialplan on Exchange UM Servers.
A great colleague and I spent the better part of an afternoon and evening going over and checking and cross-checking everything from start to finish. One of the last things we had done was actually also related to an SSL certificate association with a service that was updated and which with false hope thought had caused the issue one of the Exchange servers. Unfortunately that was not the case. Many Google’s later and late in the evening PowerShell came to the rescue!
We needed to firstly check the ServerComponentState of Exchange Server to determine what was active and what was inactive. We used the following command found via TechNet:
Get-ServerComponentState -Identity ExchangeServer
The resulting output is as follows:
Eureka! One of the Exchange Server components was inactive, namely the one that was causing voice-mail to not work: component UMCallRouter. Services in services.msc were all started and had been the whole troubleshooting time, event logs though as shown above were leading us down the wrong rabbit hole- to Dialplan’s and ‘routing’ between Exchange UM servers. The Set-ServerComponentState is the next Powershell cmdlet (via TechNet) that we need to use to effectively start the UM component.
The following cmdlet sets the UM component state to Active:
Set-ServerComponentState -Identity ExchangeServer -Component UMCallRouter -State Active -Requester HealthAPI
Here we are using the Requester as the HealthAPI. Only the requester that put a component into a inactive state can put it back into an active state. Via the TechNet article, there are 5 requesters: HealthAPI, Maintenance, Sidelined, Functional and Deployment. In our case we simply were lucky enough to choose the first requester off the list and that was the requester that was causing up grief.
Its not a coincidence at all that it was the HealthAPI that had set the component to inactive.Exchange Server will use one of the 5 requesters to inactive a component depending on the issue: in our case there was a fundamental health issue with the Exchange Server organization, the SSL certificate. Essentially each requester tracks why a component was made inactive as each requester keeps its own “log” both in ADDS as well as the servers local registry. While Exchange Server itself will pick the best fit for the reason there is a inactivated component, Exchange administrators can pick any of the 5 arbitrarily, though it makes more sense to be specific, as well as been considerate and thoughtful in administration.