Exchange UM and Lync issue using wildcard certificate

Recently, after installing and configuring Lync in an Exchange environment, a customer had issues like not being notified of voice-mail messages (also known as MWI or Message Waiting Indicator) and things like play-on-phone wasn’t working properly. To configure Exchange UM and Lync integration, the customer used the ExchUCUtil.ps1 script on Exchange and OCSUMUtil.exe tool on Lync. They also applied a valid, not-self signed certificate for Exchange UM services, as stated in the official instructions here.

Attendants and Subscriber Access was functioning properly, as well as call diversion to voicemail. Also, people were able to retrieve and replay voicemail messages.

So, apparently communications originating from Lync to Exchange was working, but from Exchange to Lync wasn’t.

I started off by inspecting the eventlog on the Exchange Server. Here I noticed UMCore process generated event 1400 periodically when trying to contact the UM IP gateway (Lync server):


This provided a clue as to what I already expected; the Lync server wasn’t responding to Exchange.

A quick search led me to this blog, which is mainly a checklist. Since Lync and Exchange were able to set up an RPC session and after verifying the ability to communicate from Exchange to Lync by doing a telnet on port 5061, I concluded networking wasn’t the issue and required services seemed to be running properly.

Next, I increased the logging level for all UM related components using:

Get-EventLogLevel “MSExchange Unified Messaging\*” | Set-EventLogLevel –Level Expert

I created a new voicemail message and after a short while MWI General event 1344 showed up:


Again, an indication signaling from Exchange to Lync didn’t work. Because I was able to open communications on port 5061 earlier on, I suspected Lync might be rejecting or refusing communications for whatever reason. Therefor, I connected to the Lync server. Since no clues were found in the event  log, I fired up the Lync Server Logging Tool. I turned on logging for SIPStack, checked All Levels and All Flags and started logging. Since I didn’t want to wait for the UM contacting Lync cycle and because it was a live system so a lot of SIP traffic was expected, I quickly created another voicemail waited a while (for accommodate for Voicemail Preview generation) and stopped logging. Next, I selected Analyze Log Files to inspect the results.

Note: Analyze Log Files requires installing the Lync Resource Kit as utilizes the Snooper tool; hardcore SIP fanatics may prefer the Notepad view and click on View Log Files instead.

When going through the events I noticed the following dialog between the Exchange server (srv12) and Lync (srv03):


After establishing a TLS session (so SIP secured was configured properly on both sides), the Lync Server received a SIP OPTIONS request after which it actively terminated the connection returning “The peer is not a configured server on this network interface” . The details section of this message displayed the following:

ErrorMsg@LyncLogger - Details

Now I have obfuscated the remainder of the FQDN, but as you probably still can see is that it states a wildcard as FQDN, e.g. * Since “*.<something” isn’t a valid FQDN, Lync server wasn’t too blame for rejecting communications. I went back to the Exchange server because I suspected it might be a certificate issue and because I learned that the FQDN shown was the subject (CN) of the wildcard certificate used (and wildcard certificates aren’t supported by Lync).

I opened up the Exchange Management Console, went to Server Configuration to view the certificates. Indeed the public wildcard certificate was used for UM services. Luckily there was already another internal certificate in-place for Exchange,with the host FQDN as subject. I selected it, opened up Assign Services and activated it for UM (which automatically disables UM for the other certificate).


After switching certificates for UM, UM services like MWI and play-on-phone started working properly.

Apparently, the instructions “If you didn’t choose to create a wildcard certificate .. you must use a public certificate if you are using Unified Messaging with Office Communications Server” isn’t complete, since Lync verifies the certificate’s subject against the FQDN of the host it’s talking to. So that rules out certificates with a wildcard Subject (CN). Unfortunately, the certificate creation instructions don’t rule out (public) wildcard certificates for UM and there’s no mention of limitations regarding the Subject. I assume originally the customer created an improper – yet technically valid – request for an “all in one” certificate for internal usage and applied the result to all Exchange and Lync services, breaking UM – but not IIS nor SMTP, in the process.

Update: Turns out the requirement for non-wildcard subjects in certificates subject names is mentioned in the Supportability section of the Lync documentation on TechNet here. It reads: “There is no support for a wildcard entry as the subject name (also referred to as the common name or CN) for any role”.  Using wildcards as one of the Subject Alternate Names (SAN) is supported for most Lync roles. Since a lot of people find certificates challenging and troubleshooting improperly configured certificates isn’t everyone’s favorite pastime, being as clear as possible helps a lot. In my opinion, the certificate generation page should mention limitations or requirements and a link to the supportability page wouldn’t hurt. Luckily, in this case the issue can easily be solved using a trusted certificate generated by an internal CA.

4 thoughts on “Exchange UM and Lync issue using wildcard certificate

  1. Thanks alot man
    i passed the lync exams few months after elease and i remeber the exam had question about which certificates to use….
    wild card or san
    i chose san but i knew for sure the documentation said wildcard(not like ocs r2) are fully supported…

  2. FYI it is not just wildcard entries that cause this problem but the root issue is that Lync ignores the SAN field of the Exchange Server certificate entirely during these communications. So if the Exchange server FQDN is not defined as the Common Name on the certificate then this happens. The supported approach is to assign a separate certificate to the UM service which only contains the server’s FQDN as the Common Name and has no SAN field at all.

      • Exchange log said:
        Certificate subject name is not valid. UM local monitoring sip options probe will fail
        System.ArgumentException: A null or empty IP address or routing host name was specified.
        at Microsoft.Exchange.Data.Transport.RoutingHost..ctor(String address)
        at Microsoft.Exchange.UM.UMCore.SipPeerManager.GetSipPeerFromUMCertificateSubjectName()

        Sip client log was a bit more precise:

        ms-diagnostics: 1010;reason=”Certificate trust with another server could not be established”;source=””;dialplan=””;umserver=””;responsecode=”504″;nexttarget=””;routingtype=”Routing to UM for Subscriber Access”;msexchErrorType=”Refer to HRESULT code for specific security status”;msexchPeerServer=”mail”;msexchHRESULT=”0x800B010F(CERT_E_CN_NO_MATCH)”;msexchsource=””;appName=”ExumRouting”
        Server: ExumRouting/
        Content-Length: 0

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s