none
EWS Not deployed .. again RRS feed

  • Question

  • I have the same issue that has been reported here several times but none of the "solutions" provided works in my environment. Please read before posting the same old links again.

    I have various domainnames for my users primary SMTP. This cannot change.

    I have one SIP domain and everyones SIP address exist as a secondary SMTP.

    If I change so that the primary SMTP becomes the SIP address, everything works. If not my conversation history does not work.

    If I add autodiscover.all.our.primary.smtp.domains.com to client HOSTS file and point it to our internal address of exchange, it works.

    I have all the nessecary SANs on my exchange certificate. Autodiscover.all.smtp.domains.com

    I can sucessfully run Outlook autodiscover wizard internally and externally with all our SMTP domains

    Why oh WHY does not the Lync clients find the EWS via autodiscover?! Our SMTP domains does not exist on the inside so it has to go the internet way and it should work, I can see the clients resolve our autodiscover-addresses to the IP of our external firewall.

    Is is possible to add a record for SMTP autodiscovery in our internal DNS without creating a new zone for each SMTP domain? Also I will not modify the HOSTS file on all our clients.

    Please help!

    Friday, September 23, 2011 7:47 AM

Answers

  • For some reason I managed to dubble register on the forum, please ignore this.

    The problem is now solved. The whole thing was related to bad autodiscover publishing via TMG server. Unfortunately this was one of the last things I investigated as this is not really my responsibility and also I know for a fact that the company cellphones used autodiscovery fine. I tested serveral publishing scenarios and read multiple guides on the subject but firewalls isnt really something I normally work with so when I found a solution that worked I settled there even though it requires user input for authentication. The original setup published all exchange services using one weblistener and 3 fw rules. My current setup has a second web listener for autodiscover, rpc, ews and oab which has no pre authentication in TMG. OWA, active sync, epc etc use the old listener with pre authentication. I also had to redirect all our external autodiscover DNS names to the IP of the new web listener which gave our global mobile users some problems while this was propagated over the internet but as of today I hear no more complaints.

    My only question now is if I have created a potential security issue by moving authentication to the CAS server? Of course I only use https.

    Thanks everyone that helped me narrow it down to the TMG server!


    / Janne
    Monday, October 3, 2011 9:50 AM

All replies

  • Have you disabled the client's emailsmtp check?
    Lasse Wedø,
    Blog:Tech@work, Twitter: @lawedo

    Please take a second to hit the green arrow on the left if the post was helpful, or mark it as an answer if it resolved your issue.
    Friday, September 23, 2011 10:15 AM
  • Via Cs-Clientpolicy? Yepp

    Maybe I can verify this applies on the clients in some way but should not be nessecary as I can see that other policys apply


    • Edited by Jan_Banan Friday, September 23, 2011 11:13 AM Typeo
    Friday, September 23, 2011 11:11 AM
  • Nest question: What is the value of the "mail" property in AD?

     

    BTW, you might already have seen this. But there is a troubleshooter guide for the integration right here:

    http://blogs.technet.com/b/nexthop/archive/2011/05/11/understanding-and-troubleshooting-microsoft-exchange-server-integration-white-paper.aspx


    Lasse Wedø,
    Blog:Tech@work, Twitter: @lawedo

    Please take a second to hit the green arrow on the left if the post was helpful, or mark it as an answer if it resolved your issue.
    Friday, September 23, 2011 12:08 PM
  • Thank you for your reply!

    The values for the mail properties are Firstname.Lastname@company.se/de/co.uk/fr etc. Our internal domain name is company.com

    All user accounts have additional email addresses like username@company.com which is also the SIP address of all user accounts.

    If I create a new useraccount with mail property username@company.com and SIP address username@company.com all is good.

    I realize I could problably solve this problem by adding a whole bunch of SIP domains and changeing everyones SIP addresses but this is something I'd rather not do. Adding a bunch of SIP domains require alot of work with internal and external DNS, it adds complexity to our Lync topology, and more importantly I think our current set up is supported and I dont see why we should do it any other way. If we expand in other countries or aquire new domain names for SMTP for any other reason I would have to go through all this again.

    I do not think I've read this particular white paper, I will dedicate the weekend to this :) Thanks again

    Friday, September 23, 2011 1:38 PM
  • When the Lync client signs in, it get the SMTP address of the user from the AD attribute using inband proivisioning

    Once Lync client get the SMTP address , it will contsruct DNS queries ( Reference: http://blogs.technet.com/b/nexthop/archive/2011/05/11/understanding-and-troubleshooting-microsoft-exchange-server-integration-white-paper.aspx)

    https://<smtpdomain>/autodiscover/autodiscover.xml
    https://autodiscover.<smtpdomain>/autodiscover/autodiscover.xml
    http://autodiscover.<smtpdomain>/autodiscover/autodiscover.xml
    • Autodiscover SRV record

    In your case, you dont host any of the zones internally so all the queries are sent to external DNS servers and the result is returned to the client.

    Now the Lync client will construct the soap request and send it to the IP address which it received from DNS server, which is your internet facing CAS server external IP address

    Once the request reaches the internet facing CAS server after being routed from internal user to internet and back to the CAS, the CAS server returns back the internal and external EWS url to the Lync client, , now the Lync client is logged in as an internal user, so will use the internal EWS url it received to connect and retrieve data from Exchange

    If the Lync client had logged in through a Lync edge server as a remote user, it would have connected to the External EWS url it received from the CAS server.

     

    Is is possible to add a record for SMTP autodiscovery in our internal DNS without creating a new zone for each SMTP domain?

    No, you need to have zone on the internal DNS server for each of the SMTP address for the DNS to be authoratative for the zone and to return the DNS answer back to the client.

     

    Wednesday, September 28, 2011 2:42 AM
  • Jimmy,

    I agree with everything you write, but thank you for writing it so I know im not crazy :)

    The problem in my case is that I dont seem to get a correct response from autodiscovery as I never get my EWS url:s listed in the Lync client. Like I wrote before I do get a correct response if I add the local IP for autodiscover.smtpdomain.com in the client HOSTS file and therefore I can only assume I have a configuration error in the way my external autodiscovery works. I never thought to dig further in to this as all my Outlook clients and all my ActiveSync devices report no problem with external autodiscover but I guess I have to tripple check this. There must be a differece in how the Lync client and other clients, ActiveSync primarily, communicates with autodiscover.

    If I use testexchangeconnectivity.com to test autodiscover I have to check the box to ignore trust for SSL or else it fails with error "certificate chain could not be verified" or something similar. autodiscover.smtpdomain.com is among the certificate SAN names and my CRL list is availible but ONLY inside my domain because at the time this certificate was created we had no external CRL configured. Could this be the problem?

    If I check the box to ignore trust for SSL the test passes using https://autodiscover.smtpdomain.com

    Come to think of it, all active sync devices must choose to accept the certificate first time they connect.

    If this is the cause of the problem is my only solution to go and by a cert from a trusted cert provider? I think it could be pretty expensive for a cert with that many SAN names that my exchange server requires.

    Thanks again to everyone posting suggestions. Sometimes its hard to see whats right in front of you :)

    Wednesday, September 28, 2011 9:18 AM
  • I forgot to tell you that all our client computers of course have the root certificate of the exchange certificate installed. Both come from our own CA. If I browse to https://autodiscover.smtpdomain.com/ I dont get a certificate warning on a computer that has the EWS not deployed issue.

    Could it be a CRL or AIA (which I dont know what it is) related problem?

    Must the certificate used for Lync autodiscovery be issued by a publically trusted Root CA like GoDaddy or Verisign?

    Wednesday, September 28, 2011 10:07 AM
  • You can disabled CRL check in IE settings on the client machine and see if it helps.

     Please enable logging on the communicator client having the issue, wait for the EWS error and collect the communicator.etl log from %userprofile%\tracing folder. You can email the logs to jimmytvincent@hotmail.com

     

    Thursday, September 29, 2011 3:01 AM
  • For some reason I managed to dubble register on the forum, please ignore this.

    The problem is now solved. The whole thing was related to bad autodiscover publishing via TMG server. Unfortunately this was one of the last things I investigated as this is not really my responsibility and also I know for a fact that the company cellphones used autodiscovery fine. I tested serveral publishing scenarios and read multiple guides on the subject but firewalls isnt really something I normally work with so when I found a solution that worked I settled there even though it requires user input for authentication. The original setup published all exchange services using one weblistener and 3 fw rules. My current setup has a second web listener for autodiscover, rpc, ews and oab which has no pre authentication in TMG. OWA, active sync, epc etc use the old listener with pre authentication. I also had to redirect all our external autodiscover DNS names to the IP of the new web listener which gave our global mobile users some problems while this was propagated over the internet but as of today I hear no more complaints.

    My only question now is if I have created a potential security issue by moving authentication to the CAS server? Of course I only use https.

    Thanks everyone that helped me narrow it down to the TMG server!


    / Janne
    Monday, October 3, 2011 9:50 AM
  • Hi Janne,

     

    You can create autodiscover.yoursmtpdomain.com record without creating DNS zone.

     

    To do so you have to create zone as autodiscover.yoursmtpdomain.com

    Then you need to create blank Host record pointing to you Exchange CAS server (It means that you just need to select create a Host A record, but do not put any info in Name field so it will automatically act as record for autodiscover.yoursmtpdomain.com) 

     

    Its quite useful when you just need to create couple of records.

     

    Thanks,

    Sunil

     

    Friday, November 11, 2011 6:54 PM
  • Hi there,

    The solution is to create an autodiscover A record in your internal DNS pointing to your  CAS' IP. The record has to be like: autodiscover.SMTPDomain.xx. So if your SMTP domain is different than your SIP domain, you have to create a zone called SMTPDomain.xx in your DNS and create the A record in that zone. That's what i did and now EWS status is ok and it populates the internal and external EW URL in the lync configuration information.

    Friday, October 23, 2015 10:48 AM
  • I am also facing same EWS not deployed issue when connecting from outside, from inside working fine getting internal/external EWS URLS.

    I have already created autodiscover.SMTPdomain.com entries in internal and external domain as well but EWS not deployed showing when Lync users login from outside.

    EWS has been configured in this format https://mail.SMTPdomain.com/ews/exchange.asmx and accessible from outside.

    in our exchange autodiscover URLs is in this format https://mail.SMTPdomain.com/autodiscover/autodiscover.xmlis this is correct or need to create https://autodiscover.SMTPdomain.com/autodiscover/autodiscover.xml in exchange server.

    looking for help



    • Edited by abhay_sbm Thursday, December 29, 2016 10:44 AM
    Thursday, December 29, 2016 10:33 AM
  • Can you also take a look into the article and see if there is something missing in the configuration session 

    http://www.uclabs.blog/2013/01/lync-and-exchange-web-services-ews-and.html


    Linus || Please mark posts as answers/helpful if it answers your question.

    Monday, January 2, 2017 11:53 AM