Lync MVP

Lync MVP
MVP AWARD

Wednesday, January 30, 2013

Lync and Exchange Web Services (EWS) and different DNS Domains- Exchange crawling e.g. for presence

Hi all,

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 Config, different internal and external DNS names and what are your SMTP and SIP Domains.
There are configuration necessary, similar to Mutli-Tenent setups.

Very often you find in Lync/ Exchange deployments an issue, where the Lync configuration show up with empty:
EWS Internal URL
EWS External URL
and
EWS Information = EWS not deployed

Therefor Exchange Web Service are not connected and several Lync Integration Features are not in use, e.g. Presence Information based on your Outlook Calendar.





Exchange Setup first:

You need PER SMTP Domain 2 DNS Record.
autodiscover.domain.name CNAME exchangeserver
_autodiscover._tcp.domain.name SRV 0 0 443 exchangeserver

NOTE:
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 process is like:
internal, Autodiscover will be queried via SCP.
external, Autodiscover is identified by DNS entrie.


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://mail.domain.name/autodiscover/autodiscover.xml' -InternalURL 'https://mail.domain.name/autodiscover/autodiscover.xml' -BasicAuthentication $true

Web Services Virtual Directory:
 Setup the internal and external URL, including HTTPS
Set-WebServicesVirtualDirectory -Identity "SERVER01\EWS(default Web site)"-BasicAuthentication $true -ExternalUrl https://www.domain.name/EWS/exchange.asmx -InternalUrl https://www.domain.name/EWS/exchange.asmx
 

Lync Setup last:

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 transcoding.
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 to 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.
But still in both configurations, you need to consider your DNS Zone setup.
If possible, I personally prefer DNS Splitting, for internal and external resolving. This makes your deployment more supportable.

Note:
if you consult a customer and you are propose DNS Spliting, make sure you fully validate other Web base services, which depends on DNS names too!!


One more remaks:
If you didn't deplyo EWS correctly from the very beginning, you might Encounter other Client issues.
therefore it is recommended you delete the followin file:

%userprofile%\AppData\Local\Microsoft\Outlook\*autodiscover.xml



31 comments:

  1. Very nice written solution, it saves my time!

    ReplyDelete
  2. Hello!
    Is it possible, that Lync2013 Client NEVER uses the
    _autodiscover._tcp.domain.name
    but always assumes to be able reaching https://autodiscover.domain.com
    instead?

    ReplyDelete
  3. Hi Harald,
    with autodiscover we have four different scenarios.
    1. outlook client, it first queries the smptdomain.com/autodiscover, than https/http autodiscover.domain and at last the SRV record
    2. Lync Client, its similar to outlook, therefor the SRV record will be queried last
    3. Lync Server, it queries only the A/CNAME records as you have defined it also for other trusted services.
    4. Exchange Server, it queries in the same ranking as Outlook, but it depends on Outlook Anywhere is enabled or not.

    I hope this helps you a little bit, generally, Best Practice is having both A and SRV record.

    ReplyDelete
  4. Hi Thomas,
    I'm using Exchange 2013, and I try to set the autodiscover virtual directory external URL as you suggest in the Exchange Power Shell, but the command to set it in Exchange 2013 apparently doesn't exist.
    I verify that your commands are correct for exchange 2010 but not for exchange 2013. Do you have any idea to configure it in Exchange 2013.
    Thanks

    ReplyDelete
  5. Hi Jose,

    this is a very good comment. Well you are right it is working in Ex2k7, Ex2k10 but NOT in Ex2k13.
    Why is this so..?
    The Autodiscover URL was never used in Exchange, in non of the existing versions!

    The Internal Process is via SCP and the External Process is DNS only.
    True there are a lot of information not optimal in TechNet right now. Even this is a normal mistake.

    If you run the autodiscover test in Outlook, you'll see , also this on in TechNet, what will be queried and when.

    I have added one sentence about this now in the Blog.
    Thanks

    ReplyDelete
  6. What if you have multiple cas array's in your organization? Where do you point the "autodiscover.domain.name CNAME exchangeserver" to?

    ReplyDelete
  7. Hi "Anonymous",
    well its still an Lync Blog, but regarding your question where to point the autodiscover if you have multiple CAS Arrays.

    Exchange 2007/ 2010:
    You point internally to most used CAS Array, in case of this Array dies, you reassign to another one. Externally seen its the same, you point to the main published site.
    If you have GEO DNS, you can point to the nearest.

    Exchange 2013:
    There is no such thing as CAS Array, you only have load balances CAS Services. Else 2013 recommends GEO Data based HA, therefor its similar to the older version, point autodiscover to the largest site and repoint if this site fails.

    Regarding the question if it can be a CNAME, well it can be. just point it the DNS name of your CAS Array or the load balance shared IP

    I hope it helps

    ReplyDelete
  8. Hi Thomas,
    I am facing similar issue and did the change as per your article with little change "https://autodiscover.domain.com/autodiscover/autodiscover.xml" in autodiscover virtual directory. But I am bit confused on DNS entry, should I make entry like "dnscmd . /zoneadd _autodiscover._tcp.domain.com. /dsprimary" and then "dnscmd . /recordadd _autodiscover._tcp.domain.com. @ SRV 0 0 443 mail.domain.com" ?

    I have CAS array and in DNS there is one pinpoint zone "mail.domain.com" with A record to CAS Array IP. One more zone "autodiscover.domain.com" with same A record to CAS Array.

    In CAS Server, mail.domain.com redirect to mail.domain.com/owa. May be this is the reason EWS not resolving in Lync 2010 client. Plus IPhone error "cannot connect to exchange web server".

    My internal domain is domain.local and external is domain.com (no entry of domain.com in internal DNS).

    Please help. Thanks

    Prabodha

    ReplyDelete
    Replies
    1. Hi Prabodha,

      you only need the A record pointing to mail.domaincom (CAS Array) in your case and a SRV record also pointing to mail.domain.com

      Delete
    2. Thank you Thomas for the reply. But still not resolving. I just discussed with IT Head and removed all pinpointed zones. The primary zone is "domain.local". I added "domain.com" in internal DNS and add all 'A' records for :

      (Exchange 2010 SP1 - Godaddy SSL Certificate on CAS servers and TMG published)
      mail.domain.com - CAS Array IP (outlook auto resolving to this URL)
      autodiscover.domain.com - CAS array IP
      lyncdiscoverinternal.domain.com - Lync FE IP
      meet, dailin, sip - Lync FE IP

      www.domain.com - public hosted IP for internal user access website.

      SRV record - _autodiscover._tcp.domain.com SRV 0 0 443 mail.domain.com
      and _sipinternaltls._tcp.domain.com SRV 0 0 5061 sip.domain.com

      CAS autodiscover - https://autodiscover.domain.com/autodiscover/autodiscover.xml

      EWS internal & external are same - https://mail.domain.com/EWS/Exchange.asmx

      Lync 2010 standard Front End - reapply SSL Certificate from internal CA (DC). Lync Edge Internal SSL from internal CA (sip.domain.com) and external from Godaddy SSL Certificate with SAN included (Dialin, meet, lyncdiscover, lyncdiscoverinternal, sip.domain.com) and published on TMG with another listener.

      Everything looks fine, but still the issue persist. My doubt going towards authentication. From outside when Outlook Anywhere login pop-up does not resolve username@domain.com but resolve to username@domain.local or domain\username. Is this causing Lync client not able to get EWS?

      Please help, I tried to get help in a lot of forum but no help. MSFT team told me to upgrade to exchange 2010 SP2 (but my doubt if EWS URL resolving from IE explorer, then why not Lync client)

      Thanks & Regards,

      Prabodha

      Delete
    3. Hi,
      I can see some ???
      The Edge Internal Interface only need a Certificate with the FQDN (internal) of this server.
      The external certificate do not have the Web Service Name.

      The Exchange user name resolver issue is properly in you AD, which use the AD suffix you have given. if you wanna change this, you need to change the logon suffix in AD.
      IE has nothing to do with the client/ server beside the Proxy settings, so you need to validat, the lync stays internal if it queries via a proxy!

      Delete
  9. Replies
    1. Dear Thomas, ever since i upgraded my Lync 2010 to 2013 I have on my front end a repeating error (every thirty minutes):Storage Service had an EWS Autodiscovery failure
      And for lync client it will always ask for exchange credentials without any sign in success
      Please Advise

      Delete
    2. The second issue you can solve if you recreate the Outlook Client Profile.
      This issue should not appear on each client, well?

      Let me clarify, you mean the LS Storage Service well.
      This could lead to two different problem.
      1. Your Autodiscovery Setup isn't correct.
      2. You have a Proxy Config active on your Lync Server. Change this to "no proxy" than it should be fine.

      Delete
  10. What command did you use to get the result in the first picture ?

    ReplyDelete
    Replies
    1. This is the Lync client:

      you need to click the "hidden icons" lower right side of desktop, than "right click" the LYNC symbol and chose: "Configuration Information"

      Than this info screen will pop-up

      Delete
  11. Thank you Thomas for your reply.
    Sorry for my late response, can you show me how change my FE to no Proxy?
    This is Elie Hajj

    ReplyDelete
    Replies
    1. Hi Elie,
      you can follow the instruction in my other post:
      http://lyncuc.blogspot.de/2012/12/lync-exchange-certificates-crl-check.html

      this is not only for the CRL Check, it also shows you how to use: netsh winhttp

      Delete
    2. Thank you for your response Thomas but it seems that it's not my case.
      My issue is the same as this post

      http://social.technet.microsoft.com/Forums/en-US/lyncdeploy/thread/c5bf2775-d195-4f3a-944d-733d707ab698?Thread%3Ac5bf2775-d195-4f3a-944d-733d707ab698=Microsoft.Forums.Data.Models.Discussion&ThreadViewModel%3Ac5bf2775-d195-4f3a-944d-733d707ab698=Microsoft.Forums.CachedViewModels.ThreadViewModel

      Which is still till date not resolved.
      If you can help, will appreciate it

      Thank you
      Elie Hajj

      Delete
  12. Hi,
    We have same kind of error and does not seem to figure out how to fix it.
    Lync2013 Client EWS does not work on external network via TMG.
    But in internal network it works directly to Exchange and connects to ews external web uri not the internal...

    In TMG we have published autodiscover and ews with basic auth nothing else no exchange anywhere.

    It seems that with browser after auth popup you get the ews 'xml', but when I debug with Fiddler I see that Lync2013Client gets autodiscover OK and sends POST to ews-url and gets 401 Unauthorised from TMG but does not respond with credentials to TMG's 401 Unauthorised.
    Any toughts ?

    ReplyDelete
    Replies
    1. Tomi, have you solved this? We have the exact same issue. Basically, our ews directory is still under the mail.domain.com url, so even though we have published the autodiscover and ews folders with a separate listener and publishing rule, the ews folder is being requested from the mail.domain.com rule and thus hitting the Form based authentication rule...?
      Thanks

      Delete
  13. Hi Tomi,

    this is all Exchange related. You are not allowed to authenticate the client on the TMG. There are some more nice blogs about Exchange, e.g. msexchange.org. you can also check with www.testexchangeconnectivity.com
    Set the option to: "No delegation, but client may authenticate directly"
    Also helpful TechNet: http://technet.microsoft.com/en-us/library/bb124251.aspx
    And remember, beside OWA, no Form Based Authentication is allowed

    ReplyDelete
  14. Hi Thomas ,

    i am deploying F5 hardware load balancer for load balancing two Exchange 2013 CAS servers .

    outlook is working fine from client side , but when i am opening Lync 2013 client i get username/password prompt and never get authenticated .

    i am doing decryption/encryption on F5 load balancer [client side SSL certificate and server side SSL certificate] used to receive and decrypt the client packet , read it then encrypt it back to the CAS server ] .

    i am testing using local host file on client machine , so will this work or i need an A record and SRV record on DNS ?

    thanks ,
    Yazan Khader

    ReplyDelete
  15. Hi Yazan,

    you are no having an EWS issue, even if it looks like.
    You problem is the Outlook Profile. You have two choise solving this issue by:
    a) repair your Outlook Profile
    or
    b) create a new profile for Outlook,

    than this problem is shall diappear.
    Thomas

    ReplyDelete
  16. In regards to the EWS Virtual Directory permissions why BasicAuthentication? Could you have used DigestAuthentication or Windows Authentication?

    Basic seems to open and Windows may cause issues with authentication when you can't reach a DC.

    ReplyDelete
  17. Hi Les Chafin,

    this is quite logic due to TLS encryption. You need to have a valid certificate deployed as usual with autodiscover.
    If you are connecting from internal LAN, the other authentication methods are not disabled, which means, Windows Integrated authentication on the internal URL are still active. This must also be like this, because internal atuodiscover will also be provide by SCP (Service Connection Point) with is defined in AD under the CAS Server.

    In you second paragraph, you mentioned about issues with Basic authentication if the DC is not available. True, if a DC is nto available, simply no authentication will work, neither basic nor windows integrated.

    Back to the Basic Authentication, if this is not active, any external authentication will fail because you need access via https and this require (also depending on your firewall deployment) basic authentication.

    hope this helps for some better understanding.

    ReplyDelete
  18. Hello Thomas, I have some problem with Lync 2013 EWS integration
    I have domain : domain.local
    mail addresses: user@domain.com
    I have some users that must use user@domain1.com for external mails
    And i have a problem with those people, their Lync Clients don't have any EWS addresses in their properties.
    Can you help me with this problem

    ReplyDelete
    Replies
    1. Better late than never:

      Well this is a common missunderstand in how autodiscover works.

      REMEMBER:
      Autodiscover is ALWAYS Associated with the users primary email domain, in our case even more Exchange and Lync have the same domain in common. this requires a consitent deployment for each SIP and users primary email domain, especially internally in conjunction with SPLIT DNS.

      this is concept is brocken, you will have isuess.

      hope it helps you solving your case

      Delete
  19. Lync 2013 EWS is noot Deployed in Our Desktop

    ReplyDelete
    Replies
    1. Hi Abdul,
      you need than to make sure your autodiscover is setup with exchange according to the deployment guide

      Delete
  20. Many thanks, ISSUE SOLVED on ARR 2.5 IIS 8 + EXCHANGE 2013 + LYNC 2013 + multi tenants + one SSL domain with HTTP redirect for subdomains

    Lync 2013 EWS will not work with HTTP redirect on autodiscover, neither with SRV record, you need the A record + HTTPS autodiscover

    ReplyDelete