Lync 2010 and Exchange Web Services/autoconfigure

I’ve recently been upgrading an OCS 2007 R2 environment to Lync 2010 where the users have SMTP adresses in several SMTP domains, but they only have one SIP domain. All users have an SMTP address at least in the SIP domain, but many of them have their primary SMTP address in different domains from the SIP domain.

What happened when we migrated the first couple of users to the new Lync FE pool and the new client, some of them lost their calendar integration and recent calls list. It was early apparent that these users were the ones that didn’t have their primary SMTP address in the SIP domain, so at least we were able to find a common denominator.

Taking up the configuration information on the client showed “EWS not deployed” and the fields for EWS Internal and External URL were empty. Testing autoconfigure in Outlook did not return any errors. Of course google is my friend, so I found this post at confusedamused that listed a couple of things to check. None of these solved it for me, but check them first in any case.

When more googling didn’t result in any more possible solutions, I started looking at wireshark traces, and noticed that the Lync client was actually looking up DNS autoconfigure for the users primary SIP domain, not the SMTP domain. As it turned out, autoconfigure was set up to use SCP in all the other domains than the SMTP domain that was equal to the SIP domain, so the Lync client failed to get autoconfigure config for the other domains. I dont know why this was not a problem in R2, so theres probably been some kind of change to how the Lync client handles EWS configuration. Adding the autoconfigure host to HOSTS on the client machine I saw that the Lync client was getting “401 Unauthorized” messages back from the EWS server. I didn’t notice at first, but it was trying HTTP, not HTTPS which had failed a couple of packets earlier, because EWS didn’t have a SAN name in the correct domains.

The solution then was to either add autoconfigure names for the other domains to SAN on the EWS IIS certificate, or adding a SRV record pointing to the Exchange CAS for autoconfigure in the other domains. Hey presto!

10 thoughts on “Lync 2010 and Exchange Web Services/autoconfigure

  1. After LOTS of googling and searching, this is what finally got my Home Lab set up up and running fully, THANKS!

    1. Hi Leslin

      What do you mean your client is not updating? The presence?

      Your SIP address needs to be the same as your e-mail address, or at least have an SMTP alias that is the same, so that the client knows that the outlook profile corresponds to the currently logged inn user.

      Alternatively you can set the -DisableEmailComparisonCheck to $true on the client policy to make the Lync client assume that the currently running Outlook profile belongs to the user.


      Set-CsClientPolicy Global -DisableEmailComparisonCheck $true

      will set this parameter on the global client policy. see here.

      Also, there seems to might be something wrong with the CU2 update to the Lync client, see my post here.

  2. Hi,

    Thanks for this post!

    I just installed a Lync Server (not upgraded). Unfortunately, EWS is not working. The Lync Client tells me “EWS not deployed”. So I installed Microsoft Network Monitor and start a trace.

    I found out that the Lync Client search for a SRV record in the DNS zone of the default SMTP domain from the user. Our SMTP domain has no SRV record and we can’t add them because our provider doesn’t support SRV records.

    Our default SIP domein is domain.local. Can I force the Lync-client to search in the zone domain.local for a SRV Record?

    1. Hi AN

      If your SIP domain and your SMTP domain doesn’t match, and the user does not have his SIP address as an SMTP alias, the outlook integration will not work automatically at all, regardless of autodiscover setup.

      What you could try to do is to set the DisableEmailComparisonCheck to $true on the users Client Policy:

      Set-CsClientPolicy -Identity RedmondClientPolicy -DisableEmailComparisonCheck $true

      That should make the Lync client assume that the running outlook profile is the users without running the check (link to technet doc. Also remember to change the Policy name to one that affects the users.)

      However if you are able to change the SIP address of the users to equal your SMTP domain, that would be a much better solution and also make your deployment best practice.

  3. Hi Tom,

    Thanks, I can set the SIP domain the same as my SMTP domain, but my SMTP domain does not contains a SRV record, because my provider does not support it, that’s the problem. Lync will always search in the zone and not in the domain.local zone for a SRV record.

    When I change the default SMTP Address of the user in Exchange (set as reply) to user@domain.local, then Lync will search in the domain.local zone and finds a SRV record pointing to the Exchange. In this situation EWS is working. But, i don’t want to change the default SMTP address to user@domain.local

    1. Ah, I see. If the clients are only internal, and you have control over internal DNS, you could try to create a split-brain DNS where you add the SRV records as their own zone in the internal DNS, like it’s done in this post, only you add the SRVs for autodiscover instead of sipinternaltls.

  4. Hi Tom,

    So, your suggestion is, create a copy of the DNS zone in our internal DNS and create a SRV Record?

    Thanks, I’ll try that..

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 )

Google photo

You are commenting using your Google 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 )

Connecting to %s