One of the cool things about Exchange is a role called Unified Messaging (UM). This role allows you to bridge voice messaging, call routing, and emails, all into a convenient package. What’s even better, you can get Lync to integrate right into that feature set too, giving your Lync system a voicemail system.
Part of our pilot program was to setup Lync and Exchange UM. This was to allow us to demonstrate that Lync and our existing Exchange infrastructure could potentially replace the older PBX style system, while giving us cost savings across the board. Configuring the Lync and UM integration is pretty easy, this site gives a great step-by-step walk through of the process. As we were working with consultants during the installation, they walked us through the steps, with a minor deviation to the instructions on that site.
When it came time to test, we called the UM extension number, and got a fast busy. Because it was close to end of day, we thought about giving it time to perform replication at the AD level as contacts and AD records are created as part of the process. Unfortunately the next morning, the issue was still around. Digging about, we confirmed all the settings were correct, however we were seeing weird errors regarding TLS and certificate names in the Application log on the UM server…
The Unified Messaging server failed to exchange the required certificates with an IP gateway to enable Transport Layer Security
(TLS) for an incoming call. Please check that this is a configured TLS peer and that the certificates being used are correct. More
information: A TLS failure occurred because the target name specified in the certificate isn't correct. The error code = 0x1 and the message = Incorrect function.. Remote certificate:
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
(Lyncpool.internaldomain.local). Remote end point: 10.10.10.17:50574.
Local end point: 10.10.102.27:5061.
The error suggested we were seeing an issue with the SSL certificate on the Lync pool front end server. The first thing to check was that the Subject Name (SN) for the SSL certificate was the same as the name used for the UM IP gateway (Lync pool).
We verified that the SN matched the UM IP gateway, and that the fingerprint reported by the error message above (which I changed if you didn’t guess) matched. Next was to make sure the certificate chain wasn’t broken. Both servers had a correct certificate chain, and because they were internal certificates issued from our own CA server, the full chain of trust was available. We verified that both servers could open the others’ certificate and also saw the full chain.
We then went back and revalidated all the configurations again, and we didn’t spot anything obvious, the consultants were stumped.
After several hours of bashing our heads against it, the consultants started throwing out some wild ideas, such as us using an unrecommended TLD in the cert, and some other bits and pieces too. I found those a little hard to follow, but continued to research. Going back over the post we’d discovered on UM configuration, I scoured the images looking for something we may have missed. It wasn’t until I got to the very last image that I spotted the issue…
The output of the script reports the pool name, associated dial plan, and the UM IP Gateway. When I looked in the Exchange Management console, the “Associated UM IP gateways” field was empty (highlighted with red border as filled in), suggesting that the dial plan had no gateway assigned. When I discussed it with the other team member we remembered that the step to run the ExchUCUtil.ps1 script was done before executing the OcsUmUtil.exe process. We believe that the order of execution resulted in some entries not being updated with the correct information, which in turn made Exchange UM have issues matching an UM IP gateway to a dial plan. After re-executing the ExchUCUtil.ps1 script on the UM server, the UM IP Gateway field was populated with “1:1”, which matched the UM IP Gateway tab for the Lync Front End server.
Less than a minute after we confirmed the field had been populated with information, we ran a test call to the UM extension, and was greeted with the friendly UM voicemail system.
This is a weird case where an error message took us down the wrong path, if it had been a little clearer, it may have steered us in the right direction. A better error, obviously, would be to report that the inbound call was not matched to the calling UM IP Gateway. We probably would have had the issue resolved in about 10 minutes, instead of 2 days.
As a side note, the SSL certificates must be configured correctly as well, otherwise you will get exactly the same error message. This is why we went down the path of examining the certificates very closely. The UM server SN must be the Fully Qualified Domain Name (FQDN) of the server, and the UM IP Gateway SN has to be that of the Lync Front End server.