Jodrik.nl

After running an upgrade from Exchange 2010 to 2013 I began running into the issue that the voicemail for users was no longer working as intended. Several frustrating attempts to resolve this found a severe lack of documentation for this particular state of deployment.

After a long, extensive search I came across a good post in the Microsoft Partner Support channels detailing a link to a blog post. This seemed to make some sense so I set out to try and confirm this was my actual issue. Running a NETSTAT -noa -p tcp > output.txt resulted in the following;

  TCP    127.0.0.1:5060         0.0.0.0:0              LISTENING       9008
  TCP    127.0.0.1:5061         0.0.0.0:0              LISTENING       9008

This indeed seemed to indicate the stated problem. So I ran the Get-ServerComponentState command to check for the inactive setting

[PS] C:\Windows\system32>Get-ServerComponentState -Identity "EXCH2013" -Component "UMCallRouter"
Server                                  Component                               State
------                                  ---------                               -----
EXCH2013.example.local                  UMCallRouter                            Inactive

Which indeed yielded “Inactive”. So I attempted the most basic fix suggested which is just to kick it back into active mode using the following command

Set-ServerComponentState -Component UMCallRouter -Identity EXCH2013 -Requester Maintenance -State Active

This didn’t have any effect however. Component State was still Inactive and it still didn’t work. So I remade the certificate that Exchange uses and assigned this to all services. Still no luck on the componentstate, nor being capable of forcing it.

Eventlog still returned the following messages:

Information 5-3-2014 14:12:32 MSExchange Unified Messaging 1037 UMService
The Microsoft Exchange Unified Messaging Call Router has started successfully.

Information 5-3-2014 14:12:32 MSExchange Unified Messaging 1644 UMCallRouter The certificate used by the Microsoft Exchange Unified Messaging Call Router service will expire in “729” days. No actions are necessary at this time. A reminder will be logged “30” days before the certificate’s expiration date.

Information 5-3-2014 14:12:32 MSExchange Unified Messaging 1645 UMCallRouter The Microsoft Exchange Unified Messaging Call Router service will attempt to use the certificate with the following parameters: IssuerName = “CN=Internal CA, DC=example, DC=local”, SerialNumber = “——————–“, Thumbprint = “—————–“, IsSelfSigned = “False”, NotValidAfter = “4-3-2016 13:47:57”.

Warning 5-3-2014 14:12:32 MSExchange Unified Messaging 1621 UMCallRouter
The Client Access server isn’t currently enabled and the Microsoft Exchange Unified Messaging call router can’t listen on any TCP/UDP ports. Any existing connections will be disconnected.

Information 5-3-2014 14:12:32 MSExchange Unified Messaging 1648 UMCallRouter The Microsoft Exchange Unified Messaging Call Router service has been enabled and will now start listening for new calls in “TCP and TLS dual mode” mode on port(s) “5060, 5061.”.

Warning 5-3-2014 14:12:31 MSExchange Unified Messaging 1621 UMCallRouter
The Client Access server isn’t currently enabled and the Microsoft Exchange Unified Messaging call router can’t listen on any TCP/UDP ports. Any existing connections will be disconnected.

Information 5-3-2014 14:12:31 MSExchange Unified Messaging 1646 UMCallRouter The Microsoft Exchange Unified Messaging Call Router service will attempt to start in the following mode: TCP and TLS dual mode.

Solution
After extensively troubleshooting this problem with Microsoft the issue was found in the Microsoft Exchange Health Manager server not running. After this service was started it took about 15 minutes to boot the UMCR and for it to start working.