(No Ratings Yet)
Loading...We recently installed Lync 2010 and integrated it with our Exchange 2010 Unified Messaging (UM). Everything seemed to go smoothly and we have since released it to all of our users. We are getting great positive feedback and wanted to enhance the offering. To that end, we started playing with Polycom CX100/200/300 devices (I hope to have reviews of those out soon). These are speakerphones and telephones that connect to your PC via USB and interact very well with OCS 2007 and Lync 2010.
The CX300 has the ability to connect the user quickly with voicemail as long as it is being hosted on Exchange 2010 UM. When you get voicemail, a light on the “1” key of the dialpad will light up red as your message waiting indicator (MWI). The user is supposed to be able to simply press and hold the “1” key for about 2 seconds and the phone will automatically put you into voicemail.
There are some setup functions that you must run on your Lync front-end server and on the Exchange server running the UM role. On the Lync server, you must run the Exchange UM Integration Utility which will build a proxy user to host the subscriber access number to Exchange UM. Depending on your installation, you may also have to set the UM startup to be in TCP, SIP Secure, Secure or Dual mode. Since we are integrated with Cisco CallManager, we were configured for TCP mode, but needed to move to Dual mode.
To use Lync with Exchange UM, this is done using TLS so certificates are required on both systems. We already have a CA for our domain and we issued certificates to all of our servers. I thought the process would be simple enough. Set the issued certificate on Exchange UM to support the UM role (done using the EMC) and then set the UM service for Dual mode and restart the UM service.
However, we got an error stating “Voice Mail is unavailable or may be offline”. This happened with the CX300, but it also happened when we clicked on the “Call voice mail” option within the standard Lync client. Clearly something was wrong.
Luck for us, we had a consultant available and he suggested that this is usually a certificate or DNS issue. We were extremely confident that we had done this properly, but willing to learn. He told us to run the Lync Logging Tool (SIPStack, All Levels, All Flags) and then retest.
We followed his instructions and using the Analyze function within the tool, it quickly spotted the error. It said that the subject field of the certificate on Exchange UM was invalid. At first I thought it was nonsense — who looks at the subject field; or any field for that matter. The point of the certificate is to validate identity not scope out particular fields for some type of valid entry. So, I looked at all of the certificates that have been issued to computers from our domain, and sure enough the subject fields are blank.
So, I went into the EMC and asked Exchange to create a new certificate request. I sent that to our CA and issued a new certificate for the server and installed it. I then activated it for UM service and restarted the services on that Exchange server. After waiting a few minutes, I retested with the CX300 and it dialed voicemail and worked perfectly.
Who would have thought? Well, for one — our consultant. Early in our deployment of Lync, he sent us an E-mail that said:
- Generate a certificate (internal CA is fine) for Exchange UM
- (It looks like there is already one installed using a custom eSilicon template, but I would generate one using the default WebServer template if possible)
- The subject name should just be the FQDN of your UM server.
- After creating the cert you can enable it for UM with the Enable-ExchangeCertificate cmdlet.
- Your UM is currently operating in TCP-only mode. Lync requires TLS, so I would recommend changing UM to operate in “Dual” mode here to accommodate both Cisco and Lync connections
- Assign the Lync dial plan to the UM server via the Add button
- After all these changes, restart the UM service
As you can see, he clearly told us to make the subject name of the certificate to be the FQDN of the Exchange UM server. I did not think it was necessary and I could not find a single document anywhere stating that as a requirement. When you build a certificate request from the EMC, it does do this, so I assume everyone just used that process and did not try other options.
So, if you want your Lync/Exchange UM environment to come up cleanly, then make sure to use the EMC to generate your certificate requests or verify that the certificates being issued from your CA to all of your systems has the subject field filled in with the FQDN of your system.
