Mainly technical stuff from my job as a UC consultant

Menu

Lync Server 2013 mobility – revisited

This has somewhat proven to be one of the more popular posts on my blog, both regarding stats and comments/questions. I have promised to update it to reflect some more recent experience and knowledge on the subject, but haven’t had the time until now (vacation time) to do so. But finally, here goes.

I’d like to start off by pointing out the excellent blog post from MVP Jeff Schertz on the same subject, and for someone wanting to delve into the same level of detail that he provides it is really worth the read.

Myself, on the other hand, will deliver more of a “practical overview” so to speak. To clarify some of my earlier points, and to point out some changes.

So to the point: Mobility for Lync, starting with the Lync Server 2013 CU1 (Feb 2013) release, really changed a great deal from previous versions. The biggest change was UCWA, the “module” that finally allowed for voice and video on the mobile client (and Screen sharing view-only as of July, at least for Windows Phone and iPad). With UCWA what also changed was how mobile clients connects with the Lync Server. Where the Lync 2010 mobile client could connect with both the internal (port 443) and the external (port 4443) web services of the Front End server, depending on where the client resided, the Lync 2013 mobile client will need to connect with the external web services. The way Lync is designed this communication is always established using HTTPS/TCP 443, so the traffic will need to pass through a reverse proxy or similiar service that will take this communication and forward it to the server hosting the external web services, now using port 4443 instead. This was an important point I tried to make as clear as I could in my previous point on the subject. To clarify and visualize, I have “borrowed” the figure from Technet referring to the “Technical requirements for Mobility”, as I find this as good as what I could come up with myself:

As you can see by the figure, even though when using lyncdiscoverinternal.<sipdomain> DNS record for lookup and actually connecting to the Lync pool directly from an internal network, the following traffic (registration, signalling etc) will all need to traverse the perimeter and connect to the reverse proxy in order to work (or it will fail). To clarify a somewhat erroneous point from my previous blog; you do not need to publish the lyncdiscover.<sipdomain> DNS internally, redirecting this traffic externally. Using lyncdiscoverinternal.<sipdomain> like you used to with Lync 2010 mobility is probably still a “best practice”, and why this will still work with the new UCWA way of connecting is because the token returned by the lyncdiscover service will contain both the internal and the external web services FQDN – and the Lync 2013 mobile client will know what to opt for.

This leads me to another important point regarding DNS. Since the Lync mobile client will try to resolve and ultimately connect to the external web services FQDN, this record has to be part of your internal DNS – at least if your DNS server is authorative for this namespace. In consequence, it is also worth mentioning that with “split-brain” DNS (i.e. your internal and external namespace is the same) it is necessary that your web services FQDN for internal and external use are not the same. How would the Lync client be able to connect to right one if they were?

One final point I would like to make only applies to migration scenarios, but still an applicable one. This one I owe to one of my colleagues, Tom-Inge Larsen, and his blog post on the topic. It really puzzled me that in a coexistence scenario, the external web services would not work for users homed on either the 2010 or the 2013 pool, depending on where the reverse proxy publishing rule was redirecting traffic. I found it kind of strange that Microsoft would make it like that, and force a complete cut-over migration for all users in order to have it working for everyone. Fortunately there is a solution, and to this day I can still not find this well documented by Microsoft, at least not within the Migration part of Lync 2013 Technet documents. What you need to do is define a separate FQDN for your Lync Server 2013 external web services. Next you create a reverse proxy publishing rule for this FQDN (also needing a certificate that includes this entry), and also update your external DNS with this record. This way, even if your simple URL’s are still pointing towards the legacy pool during migration, the Lync servers will be able to redirect traffic to one another. And as long as there is an externally available “path” to the new pool then conferences scheduled on the new pool will be available for external participants.

Ok, this post proved to be longer than first intended, but I like to put some clarity to the hard facts so to speak. Summing up in a few words what to consider when deploying Lync Server 2013 mobility:

Point your lyncdiscoverinternal.<sipdomain> record in internal DNS to your Front End pool.

Have the external web services FQDN in internal DNS (e.g. lyncweb.contoso.com) point to the public IP/interface of your reverse proxy, as the mobile client will need to resolve and connect to this.

In a split-brain DNS scenario, also make sure that your web pool FQDN’s for internal and external services are not the same, as the mobile client will need to know the difference.

In a migration scenario from Lync Server 2010, make sure that you plan for a separate FQDN for your external web services (not the same as your Lync Server 2010 external web services ), including certificate and also public IP if necessary. Then publish the Lync Server 2013 web services externally just the way you did with the legacy pool.

That concludes my first blog in some time, hope that will be helpful to somebody!

Yes, you are correct. External web services in this sense is nothing more than a URL used for accessing the web services, so if you don’t want to publish any Lync services on the internet you could just point this to an internal Resource. But you would anyway need some service (Reverse Proxy or Firewall doing NAT/PAT) to redirect the request made for the external web services to the Front End server at port 4443.

I have noticed the same, and also tried to have the Mobile Client logging in without redirecting it through Reverse Proxy – only to experience that it does not work.
This is just the way it has to be in order to make it work, I Guess.

Regarding internal wifi usage – I have found this solution does not work when connected to the internal wifi network for iOS devices and windows phone 8 devices. This is because the client always tries lyncdiscoverinternal on both http and https which directs the signin request to the internal auto discovery service respectively. The response from the internal auto discovery (either on http or https) does not include any external resources for the client to connect therefore redirected to the internal web service URL for a web ticket which is on https for obvious security reasons and the TLS handshake will fail unless the mobile device has the internal root cert chain installed. You can test this by putting the internal auto discover URL in a browser and open the downloaded file in notepad. You will see the internal web service URL and the only external URL provided is for xframe, which is not used in this case.

Conversely if using split brain, i.e, your pool name, internal, external web services urls are all using a public domain, than you can issue public signed certs specifically for the internal and external web services on the FE using the lync cert wizard.

But many deployments don’t use public domain internally, so MDM route may be better in this case. Ideally only mobile devices that are managed via corporate MDM should connect to internal wifi, in which case push the internal root cert chain via MDM policy. A guest network should be stood up for BYOD to mitigate security risks, in which case lyncdiscover on external DNS would be used and pass thru the RP with no problem.

I figured I’d share this information as it has been difficult to get mobility working correctly internally, external is quite simple. I hope this helps someone!

I appreciate you sharing your findings with us, sharing is caring after all!

However I cannot fully see why you would not get this working. In my company we support BYOD, and as you mention we do direct all mobile and non-company computers to a separate WiFi using external DNS.

Even though you do not put BYOD’s on their separate WiFi this should be possible, but like you say there are some caveats like the cert chain needing to be public (since server certs will often be published by internal CA).

What I have done at my company is also publishing the external Lync web services internally as well. This is accomplished by having your Reverse Proxy Lync publishing rules respond to requests from an internal NIC/IP as well – or set up a separate publishing rule binding it to the internal IP. Then, in internal DNS, point extlyncweb.domain.com to this internal IP instead of the public or “outside” one. This will also ensure that a public cert will be the one facing connecting clients. This kind of solution will also prevent your mobile clients from having to traverse firewalls back-and-forth for their web service connection – remember that media will always be P2P whenever possible.

Now, either by
a) not publishing lyncdiscoverinternal.domain.com at all and publish the lyncdiscover.domain.com in internal DNS to this new “internal RP service”, or
b) also publish another rule on your reverse proxy for your INTERNAL Lync web services (still using public cert but redirecting clients to Front End server port 443 rather than 4443)
you should be able to have all mobile clients connect flawlessly to Lync web services.

Regarding what the Lync autodiscover service (aka lyncdiscover) reply contains I find that the JSON file will contain what you have defined in Topology Builder to be the external Lync Web Services FQDN (I could post pictures or attach text for proof, but trust me on this). Now, if you happen to have a split-brain DNS and have been using the same FQDN for both internal and external web services of course you would be in trouble, since all clients would eventually end up (internally) on the one leading to internal web services, port 443 and private cert chain. In such a case you would either have to republish your topology separating these FQDN’s or using the Reverse Proxy tweak I suggested initially in my reply.

I hope you get this to work, I do not see why you shouldn’t, and feel free to ask more questions or share your progress.

Hi Rune,
We have successfully configured Lync 2013 but are having problems with mobile clients. If we browse to https://lyncdiscover.domain.com/autodiscover/autodiscoverservice.svc/root we are getting the internal Lync FE pool name instead of the External Web Services URL although its configured in our topology as lyncweb.domain.com. Do you have any idea on what might be causing this?

I Assume this is internally? If so; what does the lyncweb.domain.com record point to, in your internal DNS?
It is crucial that this points to the reverse proxy public IP address.

Another thing that pops into mind is Lync discover service itself. Are you currently upgrading from Lync Server 2010? If so; what does the lyncdiscover.domain.com record point to, in your internal DNS?
This must now point to your Lync Server 2013 Front End pool, as the 2010 server will reply with a token directing internal clients to itself.

Now, They are very reluctant in using new Public certificate for external web servcies for Lync 2013. Can we point the Lync 2010 External web services to Lync 2013 Front end pool in reverse proxy and keep Lyncdiscover.domain.com to Lync 2010 pool.

Hi Rune,
If a mobile device connects to internal wifi network and it then attempts to connect to lyncdiscoverinternal.domain.x wont it then fail due to mobile not trusting the internal certificate?
It will then attempt to connect to lyncdiscover.domain.x and if this is only published externally then it may fail to connect if the wifi network cannot route to the outside of the reverse proxy?

– Actually I think it first attempts to connect on port 80 and in this case it will get returned the internal and external web URLs
– If the mobile client then selects the external URL then instead of routing it out to the external nic in the DMZ you could use the internal load balancer i.e. create a rule on the load balancer with a vip on port 443 that points to Lync FEs and add the public cert to this rule( this public cert will have the name of the external web services A record). Then create internal DNS entry for external web services pointing to this internal VIP on the load balancer.
– Process would then be
1. Mobile device queries lyncdiscoverinternal.domain.x
2. Internal and external web services are returned
3. Mobile device selects the external web service address
4. Mobile device hits vip on internal load balancer (because that is where the A record for external web services is pointing to)
5. The mobile device will successfully connect to a Lync FE on port 443 as LB rule has a trusted public cert containing the name of the external web service A record.

Or 🙂
If the above is not true and i.e. the mobile client does not connect on port 80 for lyncdiscoverinternal.domain.x and attempts lyncdicoverinternal.domain.x on https and fails due to cert error it will then try lyncdiscover.domain.x.
So if you also point lyncdiscover.domain.x to the same vip as the external web services then it should work ( provided the name lyncdiscover.domain.x is on the public cert on the load balancer rule)

Hi Patrick, and thanks for your interesting questions! Where to begin…

First: What is undisputable is the mobile client needing to access the “Web Services external” referenced address from Lync autodiscover service. Meaning; you will either have to let the clients be able to reach the externally published IP address (VIP/reverse proxy) or you can setup an internal VIP on port 443 that will redirect to Front End pool port 4443. This is only possible if you have split-brain DNS (separate server for internal and external DNS zone “domain.com”). This is how I have done it in the company where I currently work.

The Lync autodiscover service (lyncdiscover) is nothing but an info service just like DNS. The client will try to resolve (in order) lyncdiscoverinternal.domain.com and lyncdiscover.domain.com – then it will try to connect (in order) via HTTP and HTTPS. So actually the internal certificate on the Front End servers won’t matter when the client looks for info. What matters is the DNS lookup on the external web service that is returned, and the address this points to (internal VIP, external VIP/reverse proxy) will need to have it’s certificates in order (that is, public issued CA that any client will trust).

I have actually setup lyncdiscoverinternal.domain.com on an internal load balancer using public certificate as well, just to make sure that no client will ever have trust issues for any reason.

I have skype for business, 2 edge server, 1 reverse proxy, 2 directors. Internally I can connect well using computers and cell phones, but from outside I can only connect using computers, cell phones do not connect, what could it be?

Have you verified that the lyncdiscover.your.sipdomain.com record is published in public DNS? The mobile client will try to autodiscover the “Web Services External” FQDN using this record, or you can manually specify this in the mobile client.