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: 10.10.10.61:443
TRACE :: SIP_MSG_PROCESSOR::OnDnsResolutionComplete get DNS result server: Lync15Edge.tsoorad.com IP: 10.10.10.61:443
INFO :: Use proxy server cache:1
INFO :: Remote Addr: 10.10.10.61
INFO :: Verification Flags: 1
INFO :: Interface Index: 12
INFO :: Interface Type: 0
INFO :: GetAdaptersAddresses Succeeded.
INFO :: Identified local Ipv4 address: 10.10.10.104
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 :10.10.10.61:443
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>
<root>
<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:
UPN:
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)]]><
5 comments:
John,
Do you by chance have Lync MX installed on this same machine?
-Kevin
I did all tests purely for determining DNS resolution. As such, the desktop Lync client was all that was installed on the test workstations.
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.
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....
@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.
Post a Comment