Lync 2010 reports lync cannot connect to the exchange server

While this hasn't been causing us any problems (yet), I am planning to use Lync 2010 with Exchange 2010/Outlook calendar integration shortly and until all Exchange connectivity issues are resolved, this can't be achieved.



The Problem

After the Lync 2010 client has been open for around a half hour or so, a red error box appears in bottom right hand corner of the client, clicking on the error displays a message.

Exchange Connection Error - Click to display details.

and then after clicking that error we see a further error message.

Lync cannot connect to the Exchange server. Lync will attempt to retry the connection.

Investigating the problem

To get some more information you can hold CTRL and right click on the Lync 2010 icon in the notifications area and select the "Configuration Information" window. This window shows how Lync is setup and potentially will display any problems.

On my configuration I noticed the "EWS Internal URL" and "EWS External URL" were both blank, and the "EWS Information" had a status of "EWS not deployed". I know it certainly is deployed, but just to be sure I verified it was configured and there was a instance of EWS under my Exchange 2010 IIS instance.

What I also noticed after browsing through my registry, was that the "Autodiscover" key was totally missing our of my Lync configuration. The following key should exist, replace <SIP> with your sip account name, so for me it was jtrevaskis@domain.edu.au

HKCU\Software\Microsoft\Communicator\<SIP>\Autodiscovery

If the Autodiscovery registry key does not exist, then your Lync client has not been able to connect to the Autodiscovery service of outlook and resultantly it cannot enumerate the locations of critical Exchange services such as EWS that will seed the Lync client information.



But I already have the Autodiscover service configured perfectly

Well that is what I thought too! What I didn't realize is that when I originally configured Lync I set my client domain as my external domain. It is important to identify what your SIP domain is, so when you log into Lync, what address is used, for me it was my external email domain and this is the root cause of my problems.

Internal Domain: domain.internal
External Domain: domain.edu.au

So while I have my DNS records for autodiscover.domain.internal A and _autodiscover._tcp.domain.internal SRV configured perfectly, the Lync client is actually looking for for autodiscover services at autodiscover.domain.edu.au and _autodiscover._tcp.domain.edu.au

I ran a quick Wireshark session to confirm my suspicions and within a few minutes of starting the Lync client I was seeing DNS lookup requests for _autodiscover._tcp.domain.edu.au



The Solution

I don't really want to offer Autodiscover services to the outside world and I don't want to publish _tcp records onto my external DNS services. After all, my Lync clients are being used internally only, so I wanted to find a solution that would work internally without disclosing too much information.

I got it! OK this is a little bit of a hack, but it works perfectly for me, and ensures none of my internal DNS records need to be published on the internet.

1. I created a _tcp.domain.edu.au zone on my internal DNS servers.

2. In my newly created zone, I added a SRV record by right clicking the zone and selecting "Other Records" and then "SRV".

3. I entered _autodiscover as the service type, _tcp as protocol, 443 as port number and the FQDN of my Exchange IIS service instance that is offering my Autodiscover and EWS services.

That is it, simple as that! I restarted my Lync client and within 5 minutes the "Configuration Information" window was displaying the correct EWS URL's and the HKCU\Software\Microsoft\Communicator\<SIP>\Autodiscovery registry key had been created and fully populated.

If you want to use Lync externally or already have external _tcp DNS records, then you can easily point your clients to an external EWS server and achieve the same result.

The main requirement is that a _autodiscover._tcp SRV record points directly to your Exchange IIS instance that is hosting EWS. As long as you achieve that, be it via a hack like mine, or publishing external _autodiscover._tcp records and pointing them to an external EWS instance, it should work.



Other issues worth investigating

If you are still having issues, it would be worth checking your Exchange 2010 IIS instance to ensure Autodiscover and EWS are configured and that you can reach the Autodiscover service via https://domain/Autodiscover/Autodiscover.xml to which you should see some XML random returned.

Also ensure that when you visit you Exchange IIS instance https://  in a web browser via the same FQDN you entered in your DNS SRV record above, you receive no certificate errors. If there are any certificate errors you will need to resolve them before Lync will be able to reach the Autodiscover service.