Lync 2013 Client Autodiscover

A recent NextHop article explains in some detail the fact that the new Windows Store Lync client only supports the newer Lync Autodiscovery method for locating a Lync registrar to sign-in to the environment.

This article shows how to verify and test the automatic sign-in behavior of various Lync clients in an environment by showing the different client behavior and comparing the Windows client to the Windows Store app.  Changes to guidance and deployment practices surrounding the Autodiscover service are also discussed.

Behavior

In order to observe this behavior simply run a network capture on a workstation running the Lync 2013 client and then attempt to sign-in using a bogus SIP domain name.  As each autodiscover step fails to receive a suitable response the process will advance to the next logical step.

The following test scenario uses Wireshark but the same process can be used with other network packet capture utilities.

Lync 2013 Windows Client

  • Sign out of the Windows Lync 2013 client on the test workstation and then launch Wireshark.

  • Start a live capture in Wireshark and then enter the text ‘dns’ in the Filter field to only display DNS related traffic entering and leaving the workstation.

image

  • Switch to the Lync 2013 client and enter a fake SIP Address (e.g. jeff@notasipdomain.com) and click Sign-In.

image

  • Monitor the Wireshark window while the Lync client is attempting to sign-in and notice each type of DNS record which is resolved and the resulting failure.

image

  • As long as the test domain name selected is in fact fake and not actually configured for Lync then the entire process should fail, resulting in the following error.

image

  • Stop the trace in Wireshark and take note of the Destination IP address for each DNS resolution query (not the query response).  This IP address should be that of the primary DNS server assigned to the workstation.  Use the following query in the Wireshark filter field to display only the DNS queries themselves, hiding all other traffic from the capture window.

dns and ip.dst==192.168.1.254

image

  • The resulting display should show the exact records and order that the Lync 2013 client attempted to query in order to perform autodiscovery of the Lync registration server.

image

The results above clearly show that the new order of preference for the Lync 2013 Windows client is to leverage the Lync Discover service which was first introduced in Lync Server 2010 CU4 for supporting the Mobility clients.

  1. The lyncdiscoverinternal.<sipdoimain> Host (A) record is tried first.  This record should only be available to hosts with acesss to the internal DNS servers, so external clients (not connected via VPN) should typically receive no response for this query and then move on to the next.

  2. The lyncdiscover.<sipdomain> Host (A) record is then attempted and would be the preferred first resolution for external clients.

If neither of these records are resolvable then the legacy DNS Service Locator Record (SRV) and Host Record (A) fall-back process is used.  The Lync 2013 Windows Store app actually stops here (as shown in the next section) and does not advance further, hence the requirement for deploying the Lync Discover service correctly even if mobility client are not planned for support in an environment.

  1. The sipinternal.<sipdomain> Host (A) record is then queried and would normally be resolvable only against internal DNS zones, in the same fashion that lyncdiscoverinternal would have been (if it existed).

  2. The sip.<sipdomain> Host (A) record is tried next and is often used for both internal and external resolution.
  3. In the event that none of the records above successfully return a query the last attempt is to sipexternal.<sipdomain> which should only ever be populated in an external DNS zone.  (This record is rarely used in real world deployments).

Lync 2013 Windows Store App

  • Restart the Wireshark capture, using either the same filter or less specific ‘dns’ filter and sign in to the Lync 2013 Windows Store app instead.

image

  • The sign-in attempt should fail much quicker than in the previous example.

image

  • Stop the Wireshark capture and review the results.

image

In this capture the only DNS queries performed by the MX client were for the pair of lyncdiscover and lyncdiscoverinternal host records.  There are no attempts to resolve the legacy SRV and A records which are used by the normal Windows clients.

Previous Guidance

When the Mobility clients were launched late last year for Lync Server 2010 the new Autodiscover service was initially perplexing.  The solution seemed like a lot of work just to support a unique set of clients, both for the product team to develop and for customers to understand and deploy correctly.  These new solution seemed to foreshadow additional changes in future clients as well.

Now that Lync Server 2013 is available and there are at least two new clients now which also leverage this service it is becoming more clear that the new autodiscover approach will be the primary, and eventually maybe the only approach for Lync clients to locate servers to connect to.

The impact of this phased change will mean a few best practices will need to be updated and the reliance on reverse proxy solutions for external web services publishing may become nearly a requirement versus a recommendation in some scenarios.  Clearly for Lync 2013 support a combination of both discovery scenarios will be ideal, but the writing may be on the wall for the next release of Lync to completely ditch the legacy SRV/A record approach and rely solely on the Lyncdiscover approach.

The most immediate impact is to previous guidance for the Autodiscover service configuration which was originally designed specifically for mobility clients.  The inherent problem seen during these initial deployments is that the large majority of environments utilize a private CA for certificates issued directly to internal Lync servers but now a large amount of unmanaged Lync clients were connecting to Lync directly from internal networks: personal mobile devices connected to internal Wi-Fi networks.  Previously the majority of clients which would typically connect via an internal network would be domain-joined Windows workstations which would already have the private CA certificate chain provided via Group Policy (when an Enterprise Windows CA was paired with the Active Directory environment).  Additionally any internal Lync Phone Edition client device would be able to automatically download the same private CA certificates by leveraging LDAP or DHCP information provided to the endpoints to locate the Lync Certificate Provisioning service.

But the mobility clients do not automatically download certificates so if the certificate presented by the Front End or Director servers is not trusted then the clients are unable to establish a TLS connection preventing their use.  The resolutions provided for this issue were either to deploy the needed certificates to all devices (a potential device management headache) or to instead redirect the internal lookup requests from these devices out to the externally published Lync services which would traditionally contain a third-party public certificate which these devices would already trust by default.

The latter approach is what became more common as it was easier to manage and only impacted the mobile clients.  All other Lync clients would still leverage the existing SRV and/or Host records to locate the proper Lync server.  Internal clients (and those on VPN in some cases) would be directed to internal servers and clients on the Internet would be directed to the external servers.

But when using the Lync 2013 Windows client it is clear that the first DNS resolution attempts are placed to the Lyncdiscoverinternal and Lyncdiscover FQDNs.  In the scenario above this would mean that internal Lync 2013 clients would be redirected out to the reverse proxy and treated like external clients which is not a desired behavior.  Thus the autodiscover DNS records would need to be realigned to their proper locations with Lyncdiscoverinternal existing only in the internal DNS zones and pointing to the internal Front end or Director, while the Lyncdiscover record would on;ly be published in external DNS zones and be pointed to a Reverse Proxy server.

Updated Guidance

As these changes are new and there are still a very limited number of Lync Server 2013 deployments in production to date it is not realistic to define a new best practice at this point in time.  Instead alternative configurations can be investigated and over time one or more of these scenarios may take root in the field as best practices.  Additionally Microsoft may release updated documentation or articles with an official stance on what is recommended.  But for now the existing TechNet documentation does not provide any real solution for these potential problems.

Split-Brain DNS

The first solution would be to simply start issuing public certificates to the internal Lync servers but this approach may not work for all environments as many third party certificate authorities will not allow certificate requests which contain internal-only domain names.  In networks were Split-Brain DNS is employed then this should not be an issues as all namespaces in use (both for servers and SIP domains) are publically resolvable and can be verified by the CA as owned by the requestor.

In these organizations the simplest approach would be to configure the lyncdiscoverinternal record in the internal DNS zone, pointing to internal Lync servers. Then publish the lyncdiscover record in the external DNS zone, pointing to a reverse proxy or other web publishing solution.

Disparate Namespaces

Editor’s Note:  In light of new details the guidance in this section is no longer valid.  I’m leaving it intact in the article as a reference (the configuration examples may be handy for other unrelated topics) but there is a major design flaw in this approach which will at minimum prevent the WebTicket service from functioning, among other web services.  In short the Server or Pool FQDN must also exist on the Web Services certificate, so although this configuration would work for the Mobility clients it would end up breaking all SIP clients!

Please take a look at the follow-up article Lync Server ‘Certificate Cliff’ for a full explanation of the limitations and the impact on future guidance for Lync Server deployments. -J.S.

But for networks were different namespaces are in use and the Lync server’s FQDN uses an internal-only namespace (e.g. lync.schertz.local) which can never be published to public DNS zones then this creates a problem.  A single public certificate can not be used on the internal Lync server.

The solution here could be to start using a combination of both private and public certificates on the internal Lync Servers.  Thus far the accepted best practice has been to use a single certificate assigned to all three usages on a Lync Front End or Director server, meaning that the same certificate is applied to the Server default, Web services internal, and Web services external usages.

image

But there is no requirement that the same certificate must be used on all three usages, this is just the simplest and (in the past) best approach for most deployments.  Thus it would be possible to use an internal certificate authority for the certificate assigned to the Server default usage, containing FQDNs in the internal namespace, while issuing a public certificate to both of the Web services usages.  This configuration separates the internal and external FQDNs in to separate private and public certificates.

image

The following table depicts how the certificate configuration may look for a basic Standard Edition deployment, separating the internal namespace of schertz.local from the external namespace mslync.net.  The server default certificate request would be issued to a Windows Enterprise CA or some other supported internal CA, and the web services certificate would be requested against a commonly trusted public CA like DigiCert, Entrust, Verisign, etc.

Friendly Name Lync Server Cert Lync Web Services Cert
Assigned Usages Server default Web server internal
Web server external
Common Name lync.schertz.local lyncwebint.mslync.net
Subject Alternative Name lync.schertz.local
sip.schertz.local
lyncwebint.mslync.net
lyncwebext.mslync.net
lyncdiscover.mslync.net
lyncdiscoverinternal.mslync.net
meet.mslync.net
dialin.mslync.net
admin.mslync.net

 

For an Enterprise Edition Pool the same approach can be used to support the additional internal FQDNs.

Friendly Name Lync Server Cert Lync Web Services Cert
Assigned Usages Server default Web server internal
Web server external
Common Name lyncpool.schertz.local lyncwebint.mslync.net
Subject Alternative Name lyncpool.schertz.local
lyncfe1.schertz.local
lyncfe2.schertz.local
sip.schertz.local
lyncwebint.mslync.net
lyncwebext.mslync.net
lyncdiscover.mslync.net
lyncdiscoverinternal.mslync.net
meet.mslync.net
dialin.mslync.net
admin.mslync.net

 

Based on this type of configuration it would also be viable to simply use the same exact certificate for both the internal Lync server’s web services and the Reverse Proxy server’s web listener.  This would reduce cost by not requiring a second separate public certificate to be purchased.  In this case make sure to omit the ‘admin’, ‘lyncdiscoverinternal’ and ‘lyncwebint’ hostnames from any reverse proxy rules so that if any external requests for those FQDNs are sent to the reverse proxy they will be dropped.  Exposing these FQDNs in the external certificate is not really any risk, as the internal namespace is still protected and the reverse proxy would not allow connections to these sites anyway.

There is one complication with this overall split certificate approach though as the configuration on the Lync Server must be updated to use different FQDNs for TLS/MTLS connections and HTTP/HTTPS connections.

For Enterprise Edition server pools this same configuration can be defined in a similar fashion using cmdlets or the Topology Builder can instead be used to set this Override FQDN.

image

The Lync Topology Builder has no option to change the web service FQDN of a Standard Edition server though.  But this behavior can be modified for a Standard Edition pool after all, by utilizing PowerShell cmdlets as shown below.

  • Using the Lync Server Management Shell issue the following Get-CsService cmdlet to view the currently defined InternalFQDN of the desired Front End server (e.g. lync.schertz.local), which should be null by default for a Standard Edition server.

Get-CsService -WebServer -PoolFqdn lync.schertz.local | fl *internalFQDN*

image

  • Then issue the following Set-CsWebServer cmdlet to define a new internal web services FQDN (e.g. lyncwebint.mslync.net) to the desired Front End server.

Set-CsWebServer -Identity "Webserver:lync.schertz.local" -InternalFqdn "lyncwebint.mslync.net"

  • To verify the change re-run the same Get-CsService cmdlet as before and the InternalFQDN should now be assigned to the desired parameter.

Get-CsService -WebServer -PoolFqdn lync.schertz.local | fl *internalFQDN*

image

After this type of configuration change it is necessary to re-run the Lync Server Deployment Wizard on each Front end server in the pool to update the web services FQDN properly.

Clarification

It is important to understand that this split certificate approach will only help with supporting the Lync Mobility client as it is not a SIP client and registers to the MCX web service only.  So as long as the web services certificate is trusted by any Windows Phone, Android, or iOS device then both autodiscover and registration attempts will be supported.  But the Windows Store App is a SIP client just like the standard Windows Lync client, thus it must also support the certificate assigned to the server usage.

As long as these clients are running on Windows 8 workstations which are domain-joined then the same certificate authority trust relationship needed by the standard Windows client is applicable.  So when devices like the Microsoft Surface start to become more common in corporate networks as unmanaged personal mobile devices then there are really only two available options to support all the different client use cases: either move to using a commonly trusted public certificate for all Lync server roles inside and out, or just deal with the management tasks of importing the internal root CA certificates to these devices.  Both approaches have their inherent benefits and drawbacks, but the ideal approach may be one or the other depending on the desired balance between ease of deployment versus overall deployment costs and security.

About Jeff Schertz
Site Administrator

Comments

66 Responses to “Lync 2013 Client Autodiscover”
  1. Erwin says:

    Jeff,

    It seems with Lync 2013 Microsoft also decided to change how the Lync client retrieves autodiscover.xml for Exchange webservices as discussed here: http://social.microsoft.com/Forums/en-US/partnerm

    Due to this change Lync 2013 fails to do an autodiscover lookup if there is no A record available for autodiscover.sipdomain.com. So autodiscoverredirect and SRV record configurations are no longer valid. Is this a bug, or by design?

    • jeffschertz says:

      This has been identified as a bug by Microsoft and will be fixed in a future cumulative update.

      • Joel Gillies says:

        Hello Jeff – great article! I came across this again when I was researching the Exchange autodiscover issue described above. Are you aware that this still appears to be a bug (or perhaps by design) with the Lync mobile client? It appears that Exchange information can't be retrieved by the mobile client without the existence of an A record (autodiscover.domain.com).

        • jeffschertz says:

          Yes, I think that is still the case. AS a best practice I always create an A or CNAME record for the 'autodiscover' FQDN and do not rely on only the SRV or <host>autodiscover options.

          • Ajay says:

            Hi Jeff
            I have been hit with an issue lately in our case we have lyncdiscover.domain.com on public dns and there is no lyncdiscoverinternal a record in our enterprise dns. not all users are provided with remote access in the policy. users are expected to login to lync via a c2s vpn. after publishing of lyncdiscover users are unable to login to lync via vpn rather ther they are getting redirected to RP which is blocking there access. have you come across such scenarios or is it too a part of the bug. < iam unable to understand why the client is not looking for traditional srv records >

  2. @shawnharry says:

    Excellent article. I too noticed this new behavior on initially signing into the client. Great to have a detailed explanation in the public domain as a reference. Whilst i'm a great fan of Wireshark i will say i find Fiddlers debugging tool for debugging web traffic easier than Wireshark for this scenario. Especially when trouble shooting SSL related issues. But i digress :-)

  3. SiCa says:

    i never did find any information about why a single certificate is really best practise. In lync 2010 there are enough company's who split the usage in default and internal (internal CA) vs external with a public certificate.

    In 2010 you would Always need to create the Public CA for external web services and import trusted root Ca on your TMG so it will trust your internal CA. There is in my opinion no real difference if you do it directly (as described in your blog )on the usage of external webservices or make a single usage and use one certificate for all usage in a disparate namespace that is.

    • jeffschertz says:

      The original best practices are born out of simplicity, no reason to complicate the configuration. But with Lync clients now reaching out beyond just managed, domain-connected workstations it becomes more difficult to design for Bring-Your-Own-Device environments.

  4. stephen Wright says:

    does anyone have any information regarding asymmetric media that is new for lync 2013, how it works and the setup?

    Thanks

    • jeffschertz says:

      Steve, I'm not sure what you are referring to, can you provide any background or point to some document or marketing deck that states this?

  5. carsten anker says:

    Hi Jeff,

    Thanks for the article – im a bit confused about the section regarding split-dns. Microsoft says that it is not supported – http://technet.microsoft.com/en-us/library/gg3987… ??

    /carsten

    • jeffschertz says:

      That statement underlines the fact that Microsoft has not yet tested and thus does not fully support Lync 2013 in a Split-Brain DNS configuration. It works fine though any many deployments like this are already in place. Microsoft should be updating that documentation to reflect additional testing sometime this quarter from what I understand.

  6. Dennis says:

    Thx for yet another good blogpost :)

  7. Sica says:

    The certificate cliff url is not working

  8. Cole says:

    We are running Lync Server 2013 Standard Edition and running in a Split DNS configuration with 3 servers with apache running as the reverse proxy. Everything works good except, downloading address book for external clients and we can't login with the mobility client.

    We are using the following external URLs and Public CA SSL Certificates:

    Edge Server
    access.domain.com A-Record (Edge Public IP1 + NAT)
    webconf.domain.com A-Record (Edge Public IP2 + NAT)
    av.domain.com A-Record (Edge IP3 + NAT)
    sip.domain.com A-Record (Edge IP1 + NAT)
    _sip._tls.domain.com 0 0 443 sip.domain.com
    _sipfederationtls._tcp.domain.com 0 0 5061 sip.domain.com

    Edge Server External SAN Certificate:
    SN: access.domain.com
    SAN: access.domain.com, webconf.domain.com, sip.domain.com

    Reverse Proxy
    webext.domain.com A-Record
    webdirext.domain.com A-Record
    meet.domain.com A-Record
    dialin.domain.com A-Record
    lyncdiscover.domain.com A-Record

    Reverse Proxy SAN Certificate:
    SN: webext.domain.com
    SAN: webext.domain.com, webextdir.domain.com, meet.domain.com, dialin.domain.com, lyncdiscover.domain.com

    Are we missing any URLs?

  9. Cole says:

    Figured the problem out! I needed to change my External Web Services URL to webext.domain.com and re-published the topology. Thanks. Apache as a reverse proxy seems to work no problem as well.

  10. Andrea says:

    Hi Jeff, …probably it's a dumb question :)

    In the web services picture I've seen that you use as Listening Port and Published Port the same 443 ?
    Why?
    Your proxy doesn't "remap" to 4443 Internal port, from 443 External published port as aspected …

    TIA
    mr.chichio

    • jeffschertz says:

      Andrea, that screenshot shows the Internal Web Services ports, which are correct (80 and 443 for listening and published). The External Web Services listening ports are 8080 and 4443, which are not pictured.

  11. Griff says:

    We are using TMG to "turn-around" lyncdiscover and web services on a separate internal listener with the external public signed certificate and bridged to 80 and 443. It was one way we could get the LyncMX client to work without modifying certificates or assigning public certs to Lync FEs.

    • jeffschertz says:

      Griff, the problem with this approach though is that now all 2013 clients will follow this same path which is not ideal. I also would assume that using a reverse proxy in front of the internal web services is something that Microsoft would not support. If it's working for you and you don't mind the added hops ad complexity to 2013 clients (if you are even using them yet) then go for it. But I myself will advocate for the proper internal configuration and then just biting the bullet on coming up with a certificate trust solution that works for both corporate and personal devices.

  12. Rob says:

    Hi there,

    Thanks for the post – very interesting. I hope you can please help with a quick question? We have just put in a Lync implementation and have most things working ok inc. edge and reverse proxy. We have a ”.local’ internal domain and .com external. Am I correct that this will mean we can’t ever get Autodiscover to work? It seems that some of the newer clients will only work through Autodiscover.

    Between this and the ‘certificate ciff’ issue, does that mean we have to convert our ‘.local’ domain to something globally resolvable? If so, has anyone done something like this and can point me in the direction of some guides or checklists – it sounds like it could be a bit of a headache?

    We run

    Exchange

    Sharepoint

    Lync (obviously)

    and some LOB applications.

    Thanks in advance for your time,

    Rob.

    • jeffschertz says:

      You can still use the .local namespace internally but (1) you'll need to leverage an internal private Enterprise CA and (2) you'll need to push the root certificate to all client devices. Anything that is no AD domain-joined (like an employees personal mobile device) will need to have your internal root certificate imported in some way in order to connect to Lync.

  13. Zahoor Hakeem says:

    Does we see a Security Vulnerabilities, Because DNS SRV quiries are more secure with respect to Host Record,

    • jeffschertz says:

      I'm not sure I follow; an SRV record simply points to an existing Host record so there is really no difference here from a security standpoint that I can identify.

  14. Miles says:

    Hi Jeff,

    I have a question on the section of using disparate namespaces. You touched on why the front-end pool FQDN needs to be included on the web services certificate, but I read your article “Certificate Cliff” you linked to and it didn’t extrapolate on this point. When do the Lync clients access those web services by the pool or server FQDN?

    In the Certificate Wizard section of the Lync Deployment Wizard, if I place a checkmark next to only the “Web services internal” and “Web services external” options, and then request a new cert, the wizard tells you what FQDNs you’ll need based on your topology. However, neither the front-end server(s) nor pool FQDNs are listed, so the assumption is they’re not needed. You’re saying that they are needed because WebTicketing will break. Is this a bug/oversight in the Lync setup?

    Thanks for your time,

    Miles

    • jeffschertz says:

      The server or pool FQDN is most definitely required on the certificate which is assigned to Lync web services. The Lync clients will attempt connections to the Certificate Provisioning service using the server or pool FQDN in some scenarios, and not always use the web services FQDN. I don't see any way of getting around this currently.

      • Miles says:

        Thanks for the response. So if a front-end pool was used, would you recommend using a publicly resolvable FQDN for the pool (so even internal clients would use FEPool1.domain.com)? That way you could use one public SSL certificate on both the internal and external Lync web sites since the pool name is for ‘domain.com’ instead of ‘domain.local’ correct?

        The Lync team should take a lesson from the Exchange team about isolating different types of communication. Exchange can use self-signed certs to talk to other Exchange servers for secure communication, which allows a public cert to be used for all external client communications, as well as internal client communications.

        • Erwin says:

          This is exactly my issue at the moment. We would like to have a publicly signed certificate for the internal pool, but are unable to include the FQDN’s of the FE hosts on this same certificate because they are in an internal zone. Not sure yet how to get around this…

          • jeffschertz says:

            There is no way around this if the third party CA you are purchasing certificate from is already enforcing confirmation for all domain names contained within the certificate request.

          • Miles says:

            I don’t understand the reasoning for web traffic to use the pool or server FQDN. In a scenario where SIP traffic is highly available via DNS round robin and web traffic is highly available via hardware load balancers, the HA for web services is nullified.

            If the client queries the Certificate Provisioning services using the pool/server name, it first queries DNS for FEPool1.domain.com to “speak” with the web services. Problem is, it’ll get the IP address of one of the servers – NOT the hardware load balancer’s VIP address that’s meant for web traffic! If that front-end server later went down every other connection to the Certificate Provisioning services would fail until the server’s IP was removed from DNS and the client’s DNS cache was flushed.

            The only way around this is to go against Microsoft’s recommendation and use the hardware load balancers for both SIP and HTTP/S traffic. That way the A record for FEPool1 goes to one IP and is highly available no matter the protocol used. Am I missing something?

          • jeffschertz says:

            The client doesn't use the server FQDN for all requests for those services, just a couple specific ones. So after the client has been correctly directed to the proper, online FE server then it may makes some calls to that server's FQDN. We've brought this up with Microsoft with the hope that in future releases they modify this behavior to scrub clients from ever using the server FQDN so that the web services and pool FQDNs can be used for 100% of connections.

  15. Chris says:

    I have an existing environment running Lync 2010, I have public certs on all my front end servers, and I use a hardware load balencer as my reverse proxy doing port translation for lync mobility and it works fine. However based off what I'm reading, for Lync 2013 since we have a .local domain and internal issued certs on the front end this won't work now.

    What if I use my hardware load balancer as a reverse proxy and place a public cert on this? Would lync mobility work then?

    • jeffschertz says:

      Nothing changes in Lync between 2010 and 2013. It's the changes enforced by the public certificate providers which impacts these types of network configurations.

  16. Christiaan says:

    Great Post! But it made me wonder…

    Does the Lync client (phone, soft, store, etc.) behave or react differently to the ability, or inability, to resolve LyncdiscoverInternal? In other words – is there any point/purpose to having both Lyncdiscover (external) and LyncdiscoverInternal (internal) resolve in a split-brain DNS as we can easily enough resolve Lyncdiscover to the correct internal/external interface IP based on your connection?

    Asked another way, can we (in a split-brain DNS) configure only Lyncdiscover for resolution (internal & external) and everything will work as 'normal'? We're busy setting up a new Lync 2013 environment and trying to simplify the set-up as much as possible – plus it doesn't hurt that you can potentially drop 1 more entry from the public CA cert.

    Thanks again for the great blog,
    Christiaan

    • jeffschertz says:

      The record that is actually used to contact the autodiscover service is not what defines the client's location, the web service they connect to is what does this. The response from the internal autodiscover web service will send an 'Access Location' parameter of 'Internal' while connections to the external web service will receive a value of 'External'. So in theory you could use just 'lyncdiscover' as the internal DNS record and then still point it to the internal web service FQDN, but I would not advise doing this. Lync should be deployed as intended and cutting this corner could lead to unwanted behavior either now or in some future version if anything changes. The main reason there are two separate autodiscover FQDNs is to support deployments with a single DNS zone which handles requests for all client requests from both internal and external clients (not split-brain DNS).

  17. So with that all said, how does this affect a Polycom CX600, tethered to a PC. We are seeing the same issues and while we can click through the certificate boxes, obviously you cant with the phone.

    • jeffschertz says:

      LPE does not leverage Autodiscover, it only uses SRV/A discovery, It doesn't matter whether you are using PIN Authentication or USB tethering the phone always performs the registrar discovery process itself over its Ethernet connection.

  18. HUssam says:

    hello after i changed internal fqdn of web service the control panel stop working

  19. paulopreis says:

    Hi;

    For external DNS we use lyncdiscover.publicdomain.com; furthermore, we have our hosting environment in the same publicdomain.com zone. For this we use a wildcard: *.publicdomain.com.
    The challenge we are facing is that the Lync client can resolve lyncdiscoverinternal.mydomain.com as well, so the Lync client cannot decide weather it's on the intranet or internet.

    Any ideas how to solve this?

    Thanks, Paul

    • Jeff Schertz says:

      A proper split-brain DNS configuration is required so that both records do not exist in the same DNS server database. That is the only way to avoid this.

  20. Paul IJpelaar says:

    Thanks for the comment, Jeff.

  21. ajax smith says:

    Hi Jeff,

    We have a reverse proxy in a DMZ with NATing from firewall for real ip to dmz

    ip. We have lyncdiscover.domain.com dns record pointing to this real ip.

    And the reverse proxy is having IIS ARR with rule for lyncdiscover for 443 to 4443

    and 80 to 8080…

    Now we have a situation where the Windows Lync Client is connecting to this

    lyncdiscover and trying and trying to connect?

    We are expecting it should connect using the _tls pointer dns, but we are observing

    that the Windows Client is connecting to the lyncdiscover?

    If we hard code sip.domain.com:443 we observe that it will connect.But in TCPView we

    are seeing that it keeps pounding the reverse proxy.?

    Can you please advice from you experience why such a behavour is coming from the

    windows client ?

    ajax smith

    thank you for your time.

    • Jeff Schertz says:

      As explain this this article the Lync 2013 client will utilize Lyncdiscover before any of the older SRV or Host records. So if Lyncdiscover and/or Lyncdiscoverinternal are defined in the DNS zone for the SIP domain then that is where the client will connect. Make sure you also have defined the internal Lyncdiscover record pointing to the internal web service FQDN to avoid this problem.

      • ajax smith says:

        I had the ip address , now i changed it to the FE FQDN and windows client now connects with auto discover !!! and mobile client says "The server name is incorrect. Please check it and retry"

        thank 4 ur reply

        I have to see whats wrong now….:-(

      • ajax smith says:

        Thanks for your reply.

        When you mean "internal lyncdiscover record" do you mean lyncdiscoverinternal.domain,com pointing to the internal fqdn. (I have that)

        If I shutdown my reverse proxy my external users windows client Lync 2013 can connect with the hard coded sip.kcs.com.kw:443 or auto discover it works.(but then mobile doesn't work)

        seems there is some issue in the configuration of the FE external webservice and the reverse proxy offcourse..

        In my lync client trace in the scenario of connecting to reverse proxy…lyncdiscover

        I get

        The server returned a security fault: 'An invalid security token was provided'.

        The fault reason was: 'An error occurred when processing the security tokens in the message.'.

        could be a certificate issue or webservice issue…

        I feel this is going to take a looong time pufh

Speak Your Mind

Tell us what you're thinking...
and oh, if you want a pic to show with your comment, go get a gravatar!