none
Lync Phone Edition can't retrieve autodiscover.xml

    Question

  • Our Aastra and LG-Nortel Lync phones can't connect to EWS. Digging around in the clg2 logfile from the Aastra, I found that this is because it can't download autodiscover.xml.

    The autodiscover url is found through the SRV record:

    INFO  :: NAutoDiscover::DnsAutodiscoverTask::PopulateAutodiscoverUrlsFromDnsSrv: DNS SRV for email domain, mysipdomain.nl, SRV record, _autodiscover._tcp.sipdomain.nl, succeeded.
    
    INFO  :: NAutoDiscover::DnsAutodiscoverTask::PopulateAutodiscoverUrlsFromDnsSrv: SRV record found for record, _autodiscover._tcp.sipdomain.nl, value, autodiscover.mydomain.nl.
    
    INFO  :: NAutoDiscover::DnsAutodiscoverTask::TryAutodiscoverUrls: Trying url, https://autodiscover.mydomain.nl/autodiscover/autodiscover.xml
    
    
    

    But after this, for some reason, the process throws an error saying that the server is not trusted, resulting in the phone not being able to connect to EWS:

    INFO :: DoesDomainMatchServer: DoesDomainMatchServer-no match(sipdomain.nl, autodiscover.mydomain.nl) INFO :: DoesDomainMatchServer: DoesDomainMatchServer-no match(outlook.com, autodiscover.mydomain.nl) INFO :: DoesDomainMatchServer: DoesDomainMatchServer-no match(lync.com, autodiscover.mydomain.nl)

    INFO  :: DoesDomainMatchServer: DoesDomainMatchServer, ret=1, (mydomain.nl, autodiscover.mydomain.nl) INFO :: NAutoDiscover::DnsAutodiscoverTask::TryAutodiscoverUrls: Server is autodiscover.mydomain.nl not trusted, hr=0x0. WARN :: NAutoDiscover::DnsAutodiscoverTask::PerformAutodiscovery: DNS autodiscover failed ERROR :: NAutoDiscover::AutodiscoverTaskBase::OnExecution: Autodiscovery failed. hr=0x80004005.


    Resulting in the phone not being able to connect to EWS. As far as I know the certificate is not the issue, because this would generate a specific error starting with "NAutoDiscover::DnsAutodiscoverTask::TryAutodiscoverUrls: Exception with this url"

    What could be the reason for the server not being trusted?

    Sunday, April 28, 2013 7:02 PM

All replies

  • What are the domains lync.com and outlook.com for?

    Since your AD domain is different from SMTP domain, you need to create a SMTP domain Zone in DNS server and create the autodiscover DNS record in the SMTP domain zone.

    Please check the certificate on Exchange server containing SAN autodiscover.mydomain.nl and autodiscover.sipdomain.nl.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Monday, April 29, 2013 10:10 AM
    Moderator
  • What are the domains lync.com and outlook.com for?

    Since your AD domain is different from SMTP domain, you need to create a SMTP domain Zone in DNS server and create the autodiscover DNS record in the SMTP domain zone.

    Please check the certificate on Exchange server containing SAN autodiscover.mydomain.nl and autodiscover.sipdomain.nl.



    I suppose the phone has lync.com and outlook.com in its firmware. We have no mention of these domains in our configuration other than for Lync push notifications.

    As you can see in the logs we have an SRV record in place for the autodiscover.sipdomain.nl, pointing to autodiscover.mydomain.com. The certificate for this service contains the SAN autodiscover.mydomain.com but not autodiscover.sipdomain.com. From what I've read this should be sufficient for the SRV record method. (http://technet.microsoft.com/en-us/library/jj591328(v=exchg.141).aspx#BKMK_Scenario2Using)

    PS autodiscover and EWS is working perfectly for normal Lync clients, the only problem is with Lync Phone Edition.
    • Edited by ®win Monday, April 29, 2013 11:00 AM
    Monday, April 29, 2013 10:57 AM
  • allow me to give it a little bump. Still not able to retrieve autodiscover.xml :(

    anyone familiar with this process?

    Friday, August 9, 2013 2:41 PM
  • I think the Lync Phone Edition logic changed within the last few CUs.   The scenario you describe (domain mismatch between user domain and autodiscover domain) worked for phones on 4.0.7577.4100 but stopped working for us when we moved to 4.0.7577.4387.   Frustratingly, I don't see this mentioned in any release notes so I wonder if it was even intentional.

    I have a PSS case open for this very issue.  Moving my SMTP address back into the same namespace as my autodiscover worked so I feel confident this is the issue (though that is not a valid solution).  It seems that this corresponds to the "Allow this website to configure email@contoso.com server settings" prompts in the other clients - except that LPE won't give you the option to allow it.

    As it stands now, I think I will have to either:

    a) add more autodiscover.* names to our SAN cert

    b) experiment with autodiscover "redirection" trick to see if LPE will tolerate that. http://www.msexchange.org/articles-tutorials/exchange-server-2010/mobility-client-access/using-autodiscover-large-numbers-accepted-domains-part1.html

    Tuesday, August 27, 2013 2:32 PM
  • Thanks Hugh, for your reply. It's much appreciated. Please let me know what the results are from your PSS case.

    Your explanation surely matches my experiences. It used to work fine, but stopped working at some point, most likely when we updated the firmwares on our phones. I will try and downgrade one to confirm.

    PS I have tried both the SRV record and redirect method, to no avail.

    Tuesday, August 27, 2013 3:14 PM
  • I just downgraded one of our 6725ip phones to 4.0.7577.4100 and voila Exchange integration started working again.

    I guess this confirms the idea the problem is in current firmware and not in our configuration.

    Tuesday, August 27, 2013 8:47 PM
  • Hugh,

    can I contact you anywhere to discuss this issue and your PSS case? I was wondering if you already got any statement from MS about this and if it would be useful if I'd open a case as well.

    Let me know.


    Friday, September 6, 2013 10:19 AM
  • I asked that my case be escalated into the product team - at which point it stalled out.

    I want to find out if this was an accidental regression in the Lync Phone Edition code or an intentional change (that didn't appear in any release notes I saw).

    ®win,  yes, I think another ticket would help.  Perhaps you have some partner access as well?   The engineer I worked with seemed unaware of the issue until we really drilled into the logs.   I don't think the product team is aware that they've created this deployment pitfall for many of us.

    Friday, September 6, 2013 12:08 PM
  • An article about this issue: http://blog.schertz.name/2013/08/lync-phone-edition-cu7-registration-issues/

    I certainly hope they will reverse this decision. Almost looks like one of many changes to push people from hosters to O365...


    Wednesday, September 11, 2013 6:40 PM
  • Has anyone tested the new October 2013 CU to see if this is corrected?  I didn't see any reference in the release notes (but then I didn't see the breaking change mentioned either) and in my limited testing, I don't see any change in behavior.

    http://support.microsoft.com/kb/2889246

    I have noticed that the phone appears to trust certs with the Active Directory DNS name.   Since this phone is not domain-joined, do you know how it discovers that?   Would that work for both internal and external (no LDAP access) devices?

    DoesDomainMatchServer: DoesDomainMatchServer-no match(xyz.net, autodiscoverus.xyz.com)
    If so, this might be a valid option for me - re-issuing the autodiscover certificate in the xyz.net zone.


    • Edited by H Kelley Tuesday, October 29, 2013 1:57 PM included test results
    Tuesday, October 29, 2013 12:13 PM
  • I have the build 4414 and the behavior for the client registering at least has changed a bit. These are the lines from my updated client:
    DoesDomainMatchServer: DoesDomainMatchServer-no match(sipDomain.com, FEServer01.adDomain.com)
    DoesDomainMatchServer: DoesDomainMatchServer-no match(outlook.com, FEServer01.adDomain.com)
    DoesDomainMatchServer: DoesDomainMatchServer-no match(lync.com, FEServer01.adDomain.com)
    DoesDomainMatchServer: DoesDomainMatchServer, ret=1, (adDomain.com, FEServer01.adDomain.com)

    The last line is new for me.


    Petri

    Tuesday, November 19, 2013 11:28 AM
  • I have that line in my log too, and I've changed my autodiscover URL to use an FQDN from the AD domain, but autodiscover is still not being trusted.

    UCD_LOG_INFO: 01/29/2014|12:53:24 Aries: 01/29/2014|12:53:24.659 5530002:51E0026 INFO  :: NAutoDiscover::DnsAutodiscoverTask::PopulateAutodiscoverUrlsFromDnsSrv: DNS SRV for email domain, xyztr.com, SRV record, _autodiscover._tcp.xyztr.com, suc 55 43 44 5F 4C 4F 47 5F 49 4E 46 4F 3A 20 30 31 2F 32 39 2F 32 30 31 34 7C 31 32 3A 35 33 3A 32 34 20 41 72 69 65 73 3A 20 30 31 2F 32 39 2F 32 30 31 34 7C 31 32 3A 35 33 3A 32 34 2E 36 35 39 20 35 35 33 30 30 30 32 3A 35 31 45 30 30 32 36 20 49 4E 46 4F 20 20 3A 3A 20 4E 41 75 74 6F 44 69 73 63 6F 76 65 72 3A 3A 44 6E 73 41 75 74 6F 64 69 73 63 6F 76 65 72 54 61 73 6B 3A 3A 50 6F 70 75 6C 61 74 65 41 75 74 6F 64 69 73 63 6F 76 65 72 55 72 6C 73 46 72 6F 6D 44 6E 73 53 72 76 3A 20 44 4E 53 20 53 52 56 20 66 6F 72 20 65 6D 61 69 6C 20 64 6F 6D 61 69 6E 2C 20 6D 6F 6E 74 70 65 6C 69 65 72 74 72 2E 63 6F 6D 2C 20 53 52 56 20 72 65 63 6F 72 64 2C 20 5F 61 75 74 6F 64 69 73 63 6F 76 65 72 2E 5F 74 63 70 2E 6D 6F 6E 74 70 65 6C 69 65 72 74 72 2E 63 6F 6D 2C 20 73 75 63 63 65
    UCD_LOG_INFO: 01/29/2014|12:53:24 Aries: 01/29/2014|12:53:24.659 5530002:51E0026 INFO  :: NAutoDiscover::DnsAutodiscoverTask::PopulateAutodiscoverUrlsFromDnsSrv: SRV record found for record, _autodiscover._tcp.xyztr.com, value, autodiscover.xyz 55 43 44 5F 4C 4F 47 5F 49 4E 46 4F 3A 20 30 31 2F 32 39 2F 32 30 31 34 7C 31 32 3A 35 33 3A 32 34 20 41 72 69 65 73 3A 20 30 31 2F 32 39 2F 32 30 31 34 7C 31 32 3A 35 33 3A 32 34 2E 36 35 39 20 35 35 33 30 30 30 32 3A 35 31 45 30 30 32 36 20 49 4E 46 4F 20 20 3A 3A 20 4E 41 75 74 6F 44 69 73 63 6F 76 65 72 3A 3A 44 6E 73 41 75 74 6F 64 69 73 63 6F 76 65 72 54 61 73 6B 3A 3A 50 6F 70 75 6C 61 74 65 41 75 74 6F 64 69 73 63 6F 76 65 72 55 72 6C 73 46 72 6F 6D 44 6E 73 53 72 76 3A 20 53 52 56 20 72 65 63 6F 72 64 20 66 6F 75 6E 64 20 66 6F 72 20 72 65 63 6F 72 64 2C 20 5F 61 75 74 6F 64 69 73 63 6F 76 65 72 2E 5F 74 63 70 2E 6D 6F 6E 74 70 65 6C 69 65 72 74 72 2E 63 6F 6D 2C 20 76 61 6C 75 65 2C 20 61 75 74 6F 64 69 73 63 6F 76 65 72 2E 6D 6F 6E 74 70 65 6C 69 65 72 72 65
    UCD_LOG_INFO: 01/29/2014|12:53:24 Aries: 01/29/2014|12:53:24.660 5530002:51E0026 INFO  :: NAutoDiscover::DnsAutodiscoverTask::TryAutodiscoverUrls: Trying url, https://autodiscover.xyzre.net/autodiscover/autodiscover.xml
    UCD_LOG_INFO: 01/29/2014|12:53:24 Aries: 01/29/2014|12:53:24.661 5530002:51E0026 INFO  :: DoesDomainMatchServer: DoesDomainMatchServer, ret=0, (xyztr.com, autodiscover.xyzre.net)
    UCD_LOG_INFO: 01/29/2014|12:53:24 Aries: 01/29/2014|12:53:24.661 5530002:51E0026 INFO  :: DoesDomainMatchServer: DoesDomainMatchServer-no match(outlook.com, autodiscover.xyzre.net)
    UCD_LOG_INFO: 01/29/2014|12:53:24 Aries: 01/29/2014|12:53:24.662 5530002:51E0026 INFO  :: DoesDomainMatchServer: DoesDomainMatchServer-no match(lync.com, autodiscover.xyzre.net)
    UCD_LOG_INFO: 01/29/2014|12:53:24 Aries: 01/29/2014|12:53:24.662 5530002:51E0026 INFO  :: DoesDomainMatchServer: DoesDomainMatchServer, ret=1, (xyzre.net, autodiscover.xyzre.net)
    UCD_LOG_INFO: 01/29/2014|12:53:24 Aries: 01/29/2014|12:53:24.662 5530002:51E0026 INFO  :: NAutoDiscover::DnsAutodiscoverTask::TryAutodiscoverUrls: Server is autodiscover.xyzre.net not trusted, hr=0x0.
     . . .  
    UCD_LOG_WARN: 01/29/2014|12:53:24 Aries: 01/29/2014|12:53:24.665 5530002:51E0026 WARN  :: NAutoDiscover::DnsAutodiscoverTask::PerformAutodiscovery: DNS autodiscover failed
    UCD_LOG_ERROR: 01/29/2014|12:53:24 Aries: 01/29/2014|12:53:24.666 5530002:51E0026 ERROR :: NAutoDiscover::AutodiscoverTaskBase::OnExecution: Autodiscovery failed. hr=0x80004005.
    

    Does anybody know what the return codes for DoesDomainMatchServer() mean?  Should I be getting a 1 for this?





    Wednesday, January 29, 2014 5:08 PM
  • What is your SIP domain on the phone's SIP addresses?

    And are the domain's modified correctly on here:

    DoesDomainMatchServer: DoesDomainMatchServer, ret=1, (xyzre.net, autodiscover.xyzre.net)

    Because those domains match.


    Petri

    Wednesday, February 26, 2014 8:15 PM