Monday, January 10, 2011

Quick note about troubleshooting voicemail notifications and missed call logs on a Tanjay / CX700 with OCS 2007 R2

It’s been awhile since I’ve done an OCS 2007 R2 deployment with the Tanjay / CX700 phones and to kick off the new 2011 year, we had a client who were previously using USB phones procured 10 Tanjays for boardrooms and select executives.  What ended up happening with the deployment was that everything went somewhat smoothly until we noticed that the voicemail notification and missed call logs were essentially empty for all the accounts we tested with.

As most of us know, Tanjay / CX700 phones rely heavily on Exchange Server 2007’s Autodiscover service because that’s the way these IP phones retrieve this information.  The following is a direct paste from the document: Communicator_Phone_2007_R2_Deployment.doc:


Exchange Server 2007 Autodiscover Service

Microsoft Exchange Server 2007 includes a new Exchange service named the Autodiscover service. The Autodiscover service configures client computers that are running Microsoft Office Outlook 2007. The Autodiscover service can also configure supported mobile devices. The Autodiscover service provides access to Exchange features for Outlook 2007 clients that are connected to an Exchange messaging environment. The Autodiscover service must be deployed and configured correctly for Outlook 2007 clients to automatically connect to Exchange features, such as the offline address book, the Availability service, and Unified Messaging (UM).

For more information, see the Exchange Server TechCenter topic How to Configure Exchange Services for the Autodiscover Service at


Drilling further into the document, we will be able to find the following information that details the process about retriving Outlook contacts, call logs and voicemails:


Retrieving Outlook contacts, call logs, and voice mail

Communicator Phone Edition retrieves Outlook contacts, call logs, and voice mails and displays them on the device. Communicator Phone Edition does this by accessing the Exchange Server 2007 Client Access Server (CAS) and retrieving the information by using Exchange Web Services (EWS). Communicator Phone Edition locates the Exchange Server 2007 CAS by using an A record that is in DNS. It uses the SMTP domain of the primary e-mail address for the user to locate the A record. The primary e-mail address is sent to the device during the sign-in process through in-band provisioning. The A record it is querying is in the following order.

https://<SMTP domain>/autodiscover/autodiscover.xml, https://autodiscover.<SMTP domain>/autodiscover/autodiscover.xml, and http/ https redirect.

Outlook 2007 uses Active Directory Service Connections Points (SCP) and DNS SRV records to locate Exchange Server 2007 CAS. However, the device does not support these additional methods.

The Autodiscover service finds and presents the various URLs that are used to interact with Exchange Web Services and information about how to connect Outlook 2007 to Exchange Server 2007. The device uses those URLs to retrieve the Outlook contacts, call logs, and voice mails from Exchange Server 2007.


Communicator Phone Edition Querying of Exchange Server 2007

The device must be able to resolve to the Exchange Web Services URL and connect to it using HTTP or HTTPS.


If HTTPS is enabled, the certificate must be trusted by the device.

· Communicator Phone Edition tries to connects to the Exchange Server 2007 Autodiscover service in the following order:

· https://<SMTP domain>/autodiscover/autodiscover.xml

· https://autodiscover.<SMTP domain>/autodiscover/autodiscover.xml

· http -> https redirect

· On successful response, Communicator Phone Edition connects to the Exchange Web Service URL in the Autodiscover response XML.

· The certificate from Exchange Server 2007 must be trusted.


With this information, let me note the 2 problems we had in this environment:

Problem #1 – Exchange Autodiscover

Exchange autodiscover wasn’t exactly broken because we did include an entry with the internal domain in the public certificate we were using.  We did this so that internal autodiscover would work and also because the client specifically said that they do not and will not publish autodiscover on the internet due to security concerns.  This meant that we ended up getting a SAN certificate with 5 entries that we used for OCS and Exchange services.  With that being said, the problem with this environment is that the external and internal domain name are different.  The following are the details:



Reviewing the document, we can see that the Tanjay would do the following:

It uses the SMTP domain of the primary e-mail address for the user to locate the A record. The primary e-mail address is sent to the device during the sign-in process through in-band provisioning.

This would not have been a problem if the external and internal domain were the same but in this environment, they were and the certificate we had on the CAS server only had:  If we were to open up a user account’s email address tab via Exchange Management Console, we would see that their primary address was and not  What we ended up having to do was add an entry into the SAN properties of the certificate to include

Problem #2 – Trusted Certificate Chain

The second problem we had was that the public certificate we used (issued by GoDaddy) was issued by a subordinate CA which was not trusted by the Tanjay / CX700.  What we ended up doing was publish it within Active Directory with the certutil command so that the Tanjay would trust it.  More information can be found on the following blog post:

Tanjay / CX700 phones were never really my forte and the last deployment I had with phones was over a year ago so I’m glad I had to go through this troubleshooting process that pretty much served as a refresher.  Please also note that these are only 2 of the problems we had an there are plenty more reasons as to why you would experience such a problem.

No comments: