(This is an updated version 2.0: 01.20.2014)
there is always confusion in how Lync is crawling Exchange Web Services (EWS).
Generally it is necessary to understand how DNS must be implemented:
Just remember, identify if you have DNS Split configuration, different internal and external DNS names and what are your SMTP and SIP Domains.
Very often you find in Lync/ Exchange deployments an issue, where the Lync configuration show up with empty:
EWS Internal URL
EWS External URL
EWS Information = EWS not deployed
Therefor Exchange Web Service are not connected deployed and several Lync Integration Features are not working, e.g. Presence Information based on your Outlook Calendar.
The feature depending on EWS are:
- Unified Contact Store
- High-Resolution Photos
- Meeting tab
- Contact Information
- Presence based on Calendar Information
- Conversation History
- Missed Conversations
- Missed Calls
- Voice Mail Playback
Exchange Setup DNS:
You need PER SMTP Domain 3 DNS Record, internally (Split DNS) and on the external DNS Server, 2x for Autodiscover and 1x for EWS
autodiscover.domain.name CNAME exchangeserver(CAS)
_autodiscover._tcp.domain.name SRV 0 0 443 exchangeserver(CAS)
ewsurl.domain.name A exchangeserver (CAS)
if you use internally another domain, e.g. your Active Directory domain, sure you can have internally another EWS published, but Autodiscover use by Lync identifies still the xml file via the users SIPDOMAIN. So split DNS is recommended (at least for Autodiscover)
As it's never really proper discussed:
Autodiscover will never use the internalURL and externalURL. in Exchange 2007/2010 you are able defining those parameters, in Exchange 2013 they are even documented in TechNet, but they simply don't exist anymore. You'll receive an error if you specify the URLs.
The correct discovery process is like (OUTLOOK):
- SCP lookup (only if client is domain joined)
- HTTPS root domain query
- HTTPS Autodiscover domain query
- HTTP redirect method
- SRV record query
- Local XML file
- cached URL in the Outlook profile (new for Outlook 2013).
The correct discovery process is like (LYNC):
- internal, Autodiscover is identified by DNS entry.
- external, Autodiscover is identified by DNS entry.
Additionally you need to check:
Autodiscovery Virtual Directory:
Setup the internal and external URL, including HTTPS and Basic Authentication
Set-AutodiscoverVirtualDirectory -Identity 'autodiscover (default Web site)' -ExternalURL 'https://ews.domain.name/autodiscover/autodiscover.xml' -InternalURL 'https://ews.domain.name/autodiscover/autodiscover.xml' -BasicAuthentication $true
The AutodiscoverVirtualDirectoy URL are supposed for Microsoft's optional use only.
Therefore it is not necessary and not Best-Practise defining them!
If you set the URL's, it will NOT HAVE AN IMPACT. Meaning, if they are defined or not, it will not change the Autodiscover behavior, since they are NOT USED within Exchange.
What is IMPORTANT, is the Authentication, you must set it the Basic Authentication, so the SSL configuration will take part.
It would be enough is you configure simply:
Set-AutodiscoverVirtualDirectory -Identity 'autodiscover (default Web site)' -BasicAuthentication $true
If you define them, you have a reminder what is configured, more like a comment
Web Services Virtual Directory:
Setup the internal and external URL, including HTTPSand Basic Authentication
Set-WebServicesVirtualDirectory -Identity "SERVER01\EWS(default Web site)" -ExternalUrl https://ews.domain.name/EWS/exchange.asmx -InternalUrl https://ews.domain.name/EWS/exchange.asmx -BasicAuthentication $true
The EWS Services are responsible for the Lync integration, especially for Calendar Information and The Conversation History.
Therefore this is the most essential configuration.
Publishing EWS service via Reverse Proxy:
Autodiscover and EWS service do NOT support FBA (form based authentication).
The client need the XML file straight and without authentication webpage, than access the EWS URL need to be authenticated at the Exchange CAS server. Authentication must be NTLM over HTTPS. (So do not use http, the password would be submitted in clear text). The NTLM authentication is hard-coded in Lync Client.
First the good new, there is nothing which we have to consider for Lync Server. The Feature is a Client Integration Feature, therefor we have nothing to configure.
There is only one exception, this is the CWA integration for Exchange OWA.
During setup and integration of CWA features, truly the EWS configuration must meet the requirements identically with the Lync Client Configuration.
One last thing necessary to consider and plan proper are the Certificates:
Since all communication is based on HTTPS and TLS, which includes the encryption. Certificates are used for trans-coding.
What is now complicated is the DNS Setup, SMTP/SIP Domains and the SAN Names in this involved certificates.
Lync in this case is straight forward, you simply have to include all SIP Domains in your SAN.
But however Exchange now requires another possible way:
- make sure you have configured the CAS Server Certificates including all SAN Names for all SMTP and SIP domains
- make us of IIS based redirection web pages. If you chose this configuration, it is possible minimizing the required SAN configuration.
If possible and I personally prefer DNS Splitting, for internal and external resolving. This makes your deployment more supportable.
How Lync discover the EWS service via autodiscover:As illustrated, it is essential for best user experiences having the Lync SIP Domain identically with the default Exchange EMail Domain. Lync is using the smtp-domain for the autodiscovery process. This is especially important if you are not inside your corporate network (LAN). Lync is never able to use SCP, only DNS A and SRV-Records.
DNS resolution occurs first:
Access now the Autodiscover.xml file located on the Exchange environment in the following order.
One more remarks:
If you didn't deploy EWS correctly from the very beginning, you might encounter other Client issues. Therefore it is recommended you delete the following file:
This file is ONLY created by Outlook, Lync do not write this file it only uses the web services.
You should try and access Autodiscover via web browse using a link provided above. You must be asked for your credential (it requires you are having a Exchange Mailbox). Exchange will than show you this XML:
<?xml version="1.0" encoding="UTF-8"?>
-<Error Id="2907134699" Time="12:55:55.0540898">
If you see this message, Autodiscover is reachable and ok.
Next check access to https://EWSURL/ews/exchange.asmx you will be redirected after login with your credentials to: https://EWSURL/ews/Services.wsdl and another xml document is provided.
Verify also on the client, where Outlook is installed HKCU\Software\Microsoft\x.0\Outlook\Autodiscover\RedirectServers and if necessary delete those entries. Double check those Keys too: HKCU\Software\Policies\Microsoft\Office\x.0\Outlook\Autodiscover
On the Exchange CAS Servers, you also should check manually on the EWS and the Default Website, if NTLM is the first choice for authentication and NEGOTIATE the second option. You do so, if you open IISManager and use Windows Authentication/ Providers.
Also see the cache files in Lync, navigate to C:\Users\<user>\AppData\Local\Microsoft\Office\15.0\Lync\email@example.com there is file named: EwsFolder<user>@acp.de.cache this file is not readable, so delete it and let is recreate.
If nothing should help, resetting the Exchange virtual Directories is the last option:
refer to her: TechNet ff629372
The Registry Key under HKCU\Software\Microsoft\Office\x.0\Lync\<user.name>\...
here LyncAutodiscover is not for EWS, it caches the LYNC WEB SERVICES only.