About Me

My photo
This is a blog for John Weber. One of my joys in life is helping others get ahead in life. Content here will be focused on that from this date forward. John was a Skype for Business MVP (2015-2018) - before that, a Lync Server MVP (2010-2014). I used to write a variety of articles (https://tsoorad.blogspot.com) on technical issues with a smattering of other interests. I have a variety of certifications dating back to Novell CNE and working up through the Microsoft MCP stack to MCITP multiple times. FWIW, I am on my third career - ex-USMC, retired US Army. I have a fancy MBA. The opinions expressed on this blog are mine and mine alone.


Lync 2013 Client Login using LyncDiscover and LyncDiscoverInternal

Perhaps you may not know, but the Lync 2013 client no longer defaults to discovering _sipinternaltls._tcp.domain.com, _sip._tls.domain.com, sip.domain.com, sipinternal.domain.com, or sipexternal.domain.com for automatic login.  What we have now is a default preference for LyncDiscover.domain.com or LyncDiscoverInternal.domain.com.  Should it not find one of those records, Lync 2013 will then start working down the SRV chain, followed by default A records such as SIP.domain.com.  This is different from the default Lync 2010 client behavior, where the client looks for the SRV record first, followed by hardcoded SIP record lookups.  To see the PUBLISHED (as of 30 Oct 2012) Lync 2013 client behavior, reference this link here; to see the published Lync 2010 client behavior, see this link.

LyncDiscover and LyncDiscoverInternal came about when Lync 2010 Mobility arrived to support Lync on mobile devices.  LyncDiscover.domain.com and LyncDiscoverInternal.domain.com are A records for which the Lync Mobility client searches to find the Lync Autodiscover service. Once it finds the Lync Discover service, the client is provided with login resources such as sipserver and href to external web services.

So what’s the Big Deal?

The Big Deal is that if you deploy mobility, you need to have those two records – LyncDiscover.domain.com (for external access) and LyncDiscoverInternal.domain.com (for internal wireless access).  And now that you have those two records, the Lync 2013 client is using them also – and if it finds them, it is reading the sipserver attribute directly and auto-configuring based off of that. 

There are implications to the Lync 2013 client resolving lyncdiscover and lyncdiscoverinternal before resolving SRV records.  If you have a mixed client environment, you COULD have 2013 clients that login correctly and 2010 clients that do not, and if you assume that both discover login sources in the same manner, you would be wrong!  Which could lead to many trips around the troubleshooting circuit.

2010 Client Login Sequence

So, let’s take a look at a 2010 Client login, and see how it looks up where to go.   Here is a segment of a 2010 communicator-uccapi-0.uccapilog file (for the purposes of this test, I forced all my DNS lookups to fail).  First, the client looks for the SRV records:

INFO  :: domainName:tsoorad.com: serviceName:sipinternaltls: transportName:tcp:
:: domainName:tsoorad.com: serviceName:sip: transportName:tls:
:: QueryDNSSrv - DNS Name[_sipinternaltls._tcp.tsoorad.com]
:: QueryDNSSrv GetDnsResults query: _sipinternaltls._tcp.tsoorad.com failed 8007232b
:: DNS_RESOLUTION_WORKITEM::ProcessWorkItem ResolveHostName failed 8007232b
:: QueryDNSSrv - DNS Name[_sip._tls.tsoorad.com]
:: CUccDnsQuery::UpdateLookup - error code=80ee0066, index=0
:: CUccDnsQuery::CompleteLookup - index=0
:: QueryDNSSrv GetDnsResults query: _sip._tls.tsoorad.com failed 8007232b

…then it proceeds to look for the SIP.domain.com, sipinternal.domain.com, and sipexternal.domain.com A records…

ResolveHostName - getaddrinfo failed for sip.tsoorad.com
ResolveHostNameUsingGetAddrInfo - getaddrinfo(sipinternal.tsoorad.com) failed
ResolveHostNameUsingGetAddrInfo - getaddrinfo(sipexternal.tsoorad.com) failed

Pretty straightforward and inline with the aforementioned documentation from Microsoft.

2013 Client Login Sequence

Here is a Lync 2013 client, trying the same process, same user account, same domain.  Note that the DNS query looks pretty much the same. 

In the interest of total disclosure, the Lync 2013 uccapilog file is different, and has a new section in it that summarizes activity for login, so I cut up the first section so that we can see like-to-like comparison.

:: QueryDNSSrv - DNS Name[_sipinternaltls._tcp.tsoorad.com]
:: QueryDNSSrv GetDnsResults query: _sipinternaltls._tcp.tsoorad.com failed 8007232b
:: DNS_RESOLUTION_WORKITEM::ProcessWorkItem ResolveHostName failed 8007232b
:: CUccDnsQuery::UpdateLookup - error code=80ee0066, index=0
:: CUccDnsQuery::CompleteLookup - index=0
:: QueryDNSSrv - DNS Name[_sip._tls.tsoorad.com]
:: QueryDNSSrv GetDnsResults query: _sip._tls.tsoorad.com failed 8007232b
:: DNS_RESOLUTION_WORKITEM::ProcessWorkItem ResolveHostName failed 8007232b
:: CUccDnsQuery::UpdateLookup - error code=80ee0066, index=1
:: CUccDnsQuery::CompleteLookup - index=1
:: Function: CUccServerEndpoint::OnDnsQueryCompleted

…and the 2013 client proceeds to try to find the SIP.domain.com, sipinternal.domain.com,  and sipexternal.domain.com records also…

ResolveHostNameUsingGetAddrInfo - getaddrinfo(sipinternal.tsoorad.com) failed ResolveHostNameUsingGetAddrInfo - getaddrinfo(sip.tsoorad.com) failed ResolveHostNameUsingGetAddrInfo - getaddrinfo(sipexternal.tsoorad.com) failed

And now, here is the Lync 2013 client logging in, but this time it found a LyncDiscover record and the Lync Autodiscover service to use.  Vastly different.  It never looked for the SRV or A Records at all.  It simply announces that it connected to a server.

TRACE :: SIP_MSG_PROCESSOR::OnDnsResolutionComplete[0F50DFC0] Entered host Lync15Edge.tsoorad.com
TRACE :: SIP_MSG_PROCESSOR::OnDnsResolutionComplete get DNS result server: Lync15Edge.tsoorad.com IP:
TRACE :: SIP_MSG_PROCESSOR::OnDnsResolutionComplete get DNS result server: Lync15Edge.tsoorad.com IP:
INFO  :: Use proxy server cache:1
INFO  :: Remote Addr:
INFO  :: Verification Flags: 1
INFO  :: Interface Index: 12
INFO  :: Interface Type: 0
INFO  :: GetAdaptersAddresses Succeeded.
INFO  :: Identified local Ipv4 address:
INFO  :: Found local routable Ipv4 address for SIP proxy server from proxy address list
INFO  :: SockMgr: Create New Connection:DestName:(Lync15Edge.tsoorad.com)DestPort:(443)Transport:(2)httpTunnel:(0)TLS RemotePrincipalName:(Lync15Edge.tsoorad.com)
TRACE :: DestAddr :

See what I mean?  Blammo, straight to the (in my case) edge server!  And here is the fancy new section in the uccapilog file… notice that is shows NOTHING in the way of SRV records or A records like it did before. The conclusion I reach is that it never looked for them after it found the Lync autodiscover (This has been confirmed by contacts within Microsoft).

<!DOCTYPE ProgressReport>


  <Login><![CDATA[Created DefaultCredential: CManagedCredential[DEFAULT this=0A80D210]]]><![CDATA[Adding new managed cred CManagedCredential[DEFAULT this=0A80D210]]]><![CDATA[GetBestManagedCredentialByType return the cred: 00000000, type:specific, userId:PHO]]><![CDATA[Certificate 0x0FA300A0:
Subject: lync15testuser@tsoorad.com
Issuer: Communications Server
Serial number: 08ca2c4e949cc0c9dcc7
Valid from: Wednesday, October 24, 2012 14:46:44
Valid to: Monday, April 22, 2013 14:46:44
]]><![CDATA[Created CManagedCredential[CERT this=0A80E180, PCERT_CONTEXT=0FA300A0]]]><![CDATA[Adding new managed cred CManagedCredential[CERT this=0A80E180, PCERT_CONTEXT=0FA300A0]]]><![CDATA[GetBestManagedCredentialByType found a matching cred: 0A80E180, type:certificate, userId:OCS]]><![CDATA[Bootstrap task queued]]><![CDATA[Starting bootstrap task: baseUrl=, pinBased=0, forceDownloadRootCert=0, deviceId=F87F107C-13E9-531A-8FC9-AA148ABE1C3A, credType=0, cert=0FA300A0]]><![CDATA[Changed CBootstrapper status [10000] -> [10000]]]><![CDATA[Bootstrap task completed with hr=0x1]]><![CDATA[GetBestManagedCredentialByType return the cred: 0A80D210, type:default, userId:CER]]><![CDATA[GetBestManagedCredentialByType found a matching cred: 0A80E180, type:certificate, userId:OCS]]><![CDATA[Created CManagedCredential[CERT this=0A80E250, PCERT_CONTEXT=0FA300A0]]]><![CDATA[Adding new managed cred CManagedCredential[CERT this=0A80E250, PCERT_CONTEXT=0FA300A0]]]><![CDATA[Changed CBootstrapper status [10000] -> [10006]]]><Lync-autodiscovery><![CDATA[GetBestManagedCredentialByType return the cred: 00000000, type:specific, userId:LAD]]><![CDATA[Discovery request sent to URL http://lyncdiscoverinternal.tsoorad.com?sipuri=lync15testuser@tsoorad.com, txn (0F6BE5F0)]]><![CDATA[GetBestManagedCredentialByType return the cred: 00000000, type:specific, userId:LAD]]><![CDATA[Discovery request sent to URL https://lyncdiscoverinternal.tsoorad.com?sipuri=lync15testuser@tsoorad.com, txn (0F6C2708)]]><![CDATA[GetBestManagedCredentialByType return the cred: 00000000, type:specific, userId:LAD]]><![CDATA[Discovery request sent to URL https://lyncdiscover.tsoorad.com?sipuri=lync15testuser@tsoorad.com, txn (0F6C2720)]]><![CDATA[GetBestManagedCredentialByType return the cred: 00000000, type:specific, userId:LAD]]><![CDATA[Discovery request sent to URL http://lyncdiscover.tsoorad.com?sipuri=lync15testuser@tsoorad.com, txn (0F6C2738)]]><![CDATA[

Clearly, the Lync 2013 client is using both LyncDiscover and LyncDiscoverInternal for automatic connections.  While the 2013 client can use the traditional methods, it appears to look for the autodiscover records first and if it cannot find them, then it falls back to the previous versions’ methodology.

Is there any downside to NOT defining LyncDiscover/LyncDiscoverInternal?

Not for the Lync 2013 client – but not doing so will negate the ability of the Lync Mobility client to perform automatic logins.  Having just the LyncDiscoverInternal and LyncDiscover records will result in Lync 2010 (and lower) clients that cannot perform auto-login.  The take-away for me? Yet another enforcement of the lesson “get your name space and DNS figured out before you begin.”


With Lync 2013, the client has a new (improved?!) automatic login search mechanism that demonstrates as preference to LyncDiscover.domain.com and LyncDiscoverInternal.domain.com.  Support for N-1 Lync client environments will still need to configure DNS SRV and A records to support the down-level automatic logins.


KP said...

Do you by chance have Lync MX installed on this same machine?


tsoorad said...

I did all tests purely for determining DNS resolution. As such, the desktop Lync client was all that was installed on the test workstations.

Unknown said...

First of all, thanks for this great post. It's amazing how vague Microsoft can make highly documented specifications.

So, I wanted to chime in with what I've been experiencing with a brand new Lync 2013 install where I've been relying on lyncdiscover A record for Lync Client autodiscover...

I had lyncdiscover.mydomain.com setup and noticed a cert warning when logging in for the first time... "Lync cannot verify that the server is trusted for your sign-in address". Based on this article by MS, http://blogs.technet.com/b/jenstr/archive/2011/02/10/lync-cannot-verify-that-the-server-is-trusted-for-your-sign-in-address.aspx the error is caused by a sip address different than the destination director or FE server domain.

NOTE: Obviously all this is a non-issue for external users or setups where the SIP and local domains are the same.

For example, in my case I was logging in with user@domain.com but the FE server was fe.domain.local. The problem is that the A record for lyncdiscoverinternal pointed to the internal FE server with the domain issued (and trusted) certificate fe.domain.local. However, that wasn't a match with the SIP address... SO... as part of the prevention from DNS spoof attacks the Lync client questioned if the cert was a valid match with the SIP domain. Thankfully you only get this warning once when you log in for the very first time. So it's not really that big of a deal. However, I'm OCD and I wanted to figure out how to get it to work perfectly from the get-go. So, I removed the lyncdiscoverinternal A record and went back to using _sipinternaltls._tcp.domain.com:5061 that points to sip.domain.com with an A record that points to the IP of the FE server. In this setup there is no error.

Based on the article by MS and my own experience, I'd have to say that solely relying on a lyncdiscoverinternal A record for internal use IF your sip and local domain suffix don't match, won't work anytime soon based on the current security of the Lync client. I do plan on using lyncdiscover.domain.com for external users - but even there I think I may still setup _sip._tcp for external users to ensure support for 2010 clients and Mac clients.

Unknown said...

Has there been any changes from the Lync 2013 Android mobile client to the Skype for Business 2015 client of the same flavor. I have no issues with MS remote thick client users logging in but with the S4B client it hangs there. FYI: We are using an edge server....

tsoorad said...

@Rob, I am not an Android user, so my empirical tests are "I don't know" - but I will note that the Win and iOS clients updated...my SfB client on my phone is v 6.2.1502 and has zero problems.

test 02 Feb

this is a test it’s only a test this should be a picture