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: 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)]]><![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.”

Summary

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.

Lync Basic 2013 Client

Lync Basic 2013 downloads

This client essentially maps directly to a Lync 2013 Standard Client Access License.  English only.  Localized (read modified for other languages) releases will be coming in November.

32 Bit - http://www.microsoft.com/en-us/download/details.aspx?id=35451

64 Bit - http://www.microsoft.com/en-us/download/details.aspx?id=35450

Details:

Lync Basic 2013 provides all the basic functionality that’s available in the full version of Lync (Lync 2013). However, if you want to use any of the following features, talk to your workplace technical support about upgrading to Lync 2013:

• Advanced call features (not available with all Office 365 subscriptions); advanced call features include team ring, call forwarding, simultaneous ring, voice mail, call park, call delegation, response groups, and remote call control
• Calendar delegation
• Gallery video view
• OneNote sharing
• Recording
• Skill search (not available with Office 365)
• Virtual Desktop Infrastructure (VDI) (not available with Office 365)

YMMV

Lync Server DNS Pinpoint zones

Edited 10.29.2012 1535 PST – thanks to Jeremy!

Scenario

I recently did a project where the client wanted to use their email address domain for their SIP domain – fairly common – but they did not have an internal DNS zone for that domain.  Their internal AD structure was domain.local – not something we can publish for external or federation access.  Furthermore, the client did not want to establish split-DNS – which is the common solution for this type of environment.  But, the client also wanted external users, mobility, and federation. 

What the client was doing was using an external DNS provider to resolve their SMTP domain lookups.  When the external name resolution directed an internal client to an external IP that was NAT to an internal resource, the firewall did an automagic redirect to the proper internal target.

Clearly, this will not work for Lync – even if mobility needs to always achieve the same connection regardless of location, using the firewall to execute fancy footwork won’t work due to how an Edge server works, or how TMG works.  TMG would see those packets as spoofed and simply drop them.  Edge will work, after a fashion, but when the client starts connecting internally and externally at the same time, the combination is guaranteed to produce inconsistent user experience and outright failures.

Remember that Lync 2010 does an automatic lookup for _sipinternaltls._tcp.<domain.name> where <domain.name> is the SIP domain that provisioned for the user who is logging in with a SIP enabled AD account.  Therefore, in our test case, we want the Lync 2010 Client to find _sipinternaltls._tcp.domain.com.

What to do?

The answer is to create “pinpoint” DNS zones.  This type of DNS zone is a single record that is represented by the zone itself.  For instance, if you need/want to have SIP.domain.com, but you don’t want to have to double manage a lengthy list of A records in two places (split DNS) then you can create a pointpoint zone that looks like this:

When the client goes looking for SIP.domain.com, it can certainly find it, yes?  But name resolution for anything else in domain.com other than that specific name (SIP.domain.com) will need to go somewhere else for resolution.

Let’s take a look at how to create a pinpoint DNS zone record.

Start with your DNS Manager…Right-click the “Forward Lookup Zones” and choose “New Zone.”

Click NEXT in the “Welcome to the New Zone Wizard” and then choose Primary Zone.
 

Choose the Zone Replication Scope option that makes sense for your environment…

 

And then name your zone.  We want SIP.domain.com. I always only allow secure dynamic updates

 

Select Finish, and you have created the new zone.

After you get your new zone, you need to add a host record so your DNS server can reply to DNS queries with an IP address.  To do that, right-click your zone and choose “New Host (A or AAAA)…”  Leave the NAME blank, input the IP, and I always adjust internal A records downwards.  In this case, I used a five minute TTL because I am forever whipping my Lync lab into some different configuration and I want the client connection points to be updated quickly.

 

Voila!  Now we look like the first picture. 

Pretty slick.  But, perhaps you know that the Lync 2010 client looks for SRV records by default?  How to construct an SRV record using this pinpoint technique? 

Get yourself to a command prompt…You will have a seriously hard time doing this in the GUI as this action is not supported in the DNS Manager GUI.  See this reference.

and enter the following:

dnscmd . /zoneadd _sipinternaltls._tcp.domain.com. /dsprimary

(creates the actual pinpoint zone)

&

dnscmd . /recordadd _sipinternaltls._tcp.domain.com. @ SRV 0 0 5061 sip.domain.com

(adds the SRV record to that zone)

Here is the final client lookup flow. We resolve to an SRV record that the Lync 2010 client looks for (_sipinternaltls._tcp.domain.com) and pointed that to another pinpoint zone (sipinternal.domain.com) with the FE pool having a cert that included that name in the SAN.  We did this to get around the strict DNS naming issue that would have caused login issues  due to the difference between the FQDN (tsoorad.net) and the SIP domain name (domain.com).

Remember to add the SIP domain to the Lync Front End Server (or servers) as shown.

YMMV!

Lync Server 2010 DNSLB with Kemp HLB

One of the things that has always bugged me about blogs on “how to” is that most of them (mine included) are derived from lab environments – and while that is great, they don’t always show “real” life for a “real” environment.  Close, but not really.

I recently did a project with Lync Server 2010 where DNSLB was used internally.  And HLB, of course, was used for the web services – both internal and external access feed through the HLB.  Most of the examples you find out there in the blogosphere show DNSLB, or they show how to setup with all the load-balancing going through the HLB.  So, what I am going to demonstrate here is DNSLB for the Enterprise Pool, along with HLB for just the web services (internal and external) AND use a live environment.  I have redacted the actual domain name, and I changed the actual external IP.  But other than that, this is a working environment supporting all workloads.

Environment Notes

The environment has split-dns, and uses the same name internally as externally; that is, domain.net is the AD DS name as well as the SIP domain name internally and for remote access and federation purposes.

The final architecture was two Enterprise Edition FE, with a SQL cluster.  Only one Edge was used as the remote access/federation was not seen as business critical.  An Archiving/Monitoring server was deployed to support IM history and compliance.  A pair of Kemp VLM-100 appliances provide Load Balancing for the FE pool. All servers are virtual.

Internal DNS

Here is what the Internal DNS and IP layout looks like.  Note that two of the entries are actually pointing internal clients to the outside – specifically, internal wireless Lync clients need to be able to find and route to the external side of the Reverse Proxy.

 

External DNS

Hardware Load Balancer

The client chose to use a pair of Kemp load balancers.  They proved to be very easy to configure for High Availability.  Literally, mere minutes.  We used this document here for the configuration of the units into HA, and this document for the configuration of the load balancers for Lync.

Here is the main setup from member HA1.

If you read the documentation, you will be told to setup some miscellaneous options for the Layer 7 work…

Here is all you need to get a DNSLB pair of Lync Enterprise Edition pool with two members load balanced from the HLB perspective.

Each virtual server get’s these options:

and

The virtual server that handles the traffic from the reverse proxy (Lync external web services) needs to have a certificate – you can export the certificate from one of the Enterprise pool members.  Import that into the load balancer.  The aforementioned documentation does a good job of walking your through that.

Also note that for Lync Mobility, you need to have a cookie set.  In Kemp parlance, the settings on the :4443 virtual server look like this:

And finally, because the traffic is coming in from the reverse proxy and is destined for the Lync Web External site on port 4443, there would be no point in checking for the service being available on port 443, so the virtual server for 4443 gets a minor change in the “checked port” section of the virtual server.

Summary

Lync Server 2010 can use DNSLB very effectively, but the Lync Web Services still need a Load Balancer.  The Lync Server 2010 documentation presents all the information you need.  The Kemp load balancer documentation does a great job of helping you configure their products.  Interestingly, support for the products is also important; if you need help with a configuration there is nothing like a knowledgeable engineer on the phone to help you figure things out.  In this case the Kemp support folks patiently helped my client discover that the original virtual server address we were using was already in use by an undocumented network device which, of course, made the HLB look like it had something wrong.

Lesson learned from that?  In addition to planning out the IP space(s), the DNS (internal and external), the physical network in terms of devices and addressing needs to be nailed also.

YMMV.

Lync 2013, Exchange 2013, Office 2013, SharePoint 2013 RTM

Microsoft announced today that Office 2013, Exchange 2013, Lync 2013, SharePoint 2013 have reached the RTM milestone.

I am psyched.  In particular, I have been part of the TAP for Exchange 2013 and Lync 2013.  Participation in both has been very educational.  I have also been using Office 2013 components in my everyday work for the last six months or so and I can say that I am quite pleased.

In conjunction with Server 2012, this upcoming year looks to be very exciting.

YMMV

Lync 2013 Calling Party Number Translation Rules

Situation

You have internal users that are Enterprise Voice enabled, and they possess sufficient power/position to not want their DID to be advertised when they call out.  What to do?

With Lync 2010, you can manipulate ALL outbound calls from Lync to have a common Calling Party inserted into the call setup – but this manipulation occurs at the trunk level for every call no matter who is placing the call or from where in your environment.  One rule covers it all.

With Lync 2013, we can now manipulate the trunk action based on the Calling Party number.  For instance, let’s say the CEO calls out for some reason, but does not want their DID to be advertised.   Instead, they want the call to appear to be coming from the executive secretary. With Lync 2013 we can now provide this functionality and apply this to only specific numbers while the remainder of the calls go out as provided for in the general configuration.

Let’s take a quick look at how this is done.

The Solution

First, we assume that there is a valid Lync 2013 topology that includes at least one mediation server or mediation pool, and at least one valid trunk out to somewhere.  I also encourage a little test as shown – just to make sure that things are working as expected.

The sharp-eyed reader will note that I am using fellow MVP Ken Lasko’s LyncOptimizer.  No point in reinventing the wheel!

For our example, let’s stipulate that the CEO wants to dial out from his assigned DID number, but have it appear to the called party that the call is coming from the CEO’s secretary.  For this we will have:

CEO number (calling party): 503-312-1234

Secretary number:  999-234-9000

You may want to run a quick test on your trunk, just to make sure your calls behave properly.  Note that when you are testing at the trunk level, you need to consider what the normalization rule is going to add or subtract to the digits entered by the user.  From above, see that the dialed number: 5033121234 normalized to +15033121234, so this is the value to use for testing at the trunk.

---

NOTE:  My trunk needs to strip the “+” before sending the call out, and usually this happens on the default “Called number translation rule” that I put into place.  This new calling party translation rule will go around that other rule, so we need to be careful and take the “+” out when creating the new rule.

---

To start making the new outbound calling party rule, go to the “Calling number translation rules” and select “New.”

Name your new rule

Build the translation rule – see how the built-in logic gives you a mini-tutorial on the pattern match.  Slick. Remember the normalization will change what digits the user enters, and that you need to have the translation rule see the number as it trunk will get it from the route.  The length is also important as that can change how the TRUNK’s translation pattern works.  Digits to add is literally what you want to change the calling party into. 

Click on “OK” to finish.  And let’s test our work. At the bottom of the trunk configuration under “Associated translation rules”  there is another testing area. Be sure to select “Calling number.”

Remember to commit your changes!

Last Thoughts

I used an extreme case here to show the possibilities.  Your carrier may have some logic that will only accept numbers within your DID block as calling party numbers – if that is the case, you will need to confine yourself to using those numbers or have the CO potentially replace your carefully crafted calling party translation with a generic Caller ID value.

YMMV.

Private Domain Certificates

Today, you can get a public Certificate Authority  - DigiCert, Entrust, etc – to issue you a trusted certificate for your internal domain.  For instance, if you have an internal AD name such as domain.local, or domain.tld, or any other that is not registered according to the governing body, then your certificate provider will issue you a certificate for the FQDN of your internal servers and your devices will trust that certificate providing your devices trust the issuer – standard fare for most of the public CA issuers.

In an effort to tighten security on the Internet by creating more stringent standards, the CA/Browser Forum recently formulated new guidelines in their Baseline Requirements for issuing SSL certificates.

One of the new changes is the elimination of certificates using internal names. This change makes it impossible to obtain a publicly trusted certificate for any host name that cannot be externally verified as being owned by the organization that is requesting the certificate.  According to this CA/Browser  document:

Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Server Name.

In addition, it appears that internal name certificates will NOT be issued after 1 Nov 2015.  Or, at least DigiCert will not issue them after that date:

In accordance with this new standard, DigiCert will no longer issue certificates to these internal names with expiration dates after November 1, 2015.

If you fall into this category, you should begin planning now to: a) deploy internal PKI and figure out how that action will change your environment(s); or b) change your internal AD DS name (yuk!).

Interesting note:  www.digicert.com is already planning ahead to help you out!  See this nifty tool.

YMMV