Lync Server 2013 – Mobility Setup Tips

Introduction

Since there are already countless Lync 2013 setup guides online, I only wanted to write about a few caveats with the configuration that I found during my recent deployment of the Mobility features.

In terms of Mobility, Lync 2013 relies on a reverse proxy to broker inside and outside connections to the Lync Front End (or Lync Standard Edition) server. This is in order to mitigate issues with users who roam between the inside and the outside of the corporate network. Whether a user is within the network’s perimeter or not, their mobile client will always connect to the reverse proxy, thus helping to prevent timeouts and disconnects when switching between the two.

I decided to go with Microsoft’s recommended TMG (Threat Management Gateway) 2010 server for the reverse proxy solution. I had not worked with TMG before this point, but found it kind of similar to most firewalls that I’ve worked with in the past, such as Fortinet or Juniper devices. The configuration requirements for this deployment were very simple; open ports 80 and 443 and translate internally to ports 8080 and 4443 going to the Lync FE server. The execution, however, was slightly problematic.

**UPDATE**

Check out my latest article for a more comprehensive rundown of Lync 2013 and External Services. I’ll describe, in detail, what’s necessary and why in order to help prepare for the daunting task of Lync Topology Planning!

Certificate Issues

One of the first issue faced was with certificate matching. Lync utilizes two different certificates, or can be set to use just one if you want to include your internal SANs on your public CA cert. We used an Enterprise CA to issue the certificate that is applied to the Lync Server Internal Web Site and a certificate issued by a public CA was applied to the Lync Server External Web Site. 

When requesting the public cert be sure that it includes a SAN for the fqdn of your “External web address”. The reverse proxy will use this certificate and web address header to forward packets to the Lync Front End. The same happens with the Simple URLs (Meet and Dial-in). If your external web fqdn is lyncweb.domain.com, add this SAN to the public cert.

Be sure to also add your Lyncdiscover public URL to ensure discovery for your remote clients.

The public cert applied to the reverse proxy and Lync FE server (External Web Site) should include at least the following CN and Subject Alternative Names:

lyncweb.domain.com (External FQDN)
lyncdiscover.domain.com (Lync Autodiscover URL)
meet.domain.com (Meeting Simple URL)
dialin.domain.com (Dial-in Simple URL for phone dial-in)

(Note: SANs such as Dial-in, Meet, and the Edge service URLs are only necessary if these features are deployed but are not required for basic mobility to work.)

If you’re setting up a Lync Edge Server you may want to also include all of the Edge service SANs in order to use a single certificate. The Edge services are A/V, Web Conferencing, and Access service for federation. The entries listed above are only the bare requirements for simple Lync mobility (phone and external clients).

Another catch here is that you must run the Lync Server Deployment wizard in order to correctly apply the certificate to the External Web Site on the Lync Standard Server IIS. You are able to open IIS and change the bindings for this site manually, but this does not fully register the cert within Lync. Don’t be confused by other guides that tell you to just change bindings in IIS, this does not fully commit! Be sure to run the Lync Server Deployment Wizard for the certificate configuration as outlined in the steps below to correctly apply the certificate.

  1. Log into the Lync FE (or Lync Standard Edition) server
  2. Make sure the public cert with private key is added to the Computer’s Personal store
  3. Run the Lync Server Deployment Wizard
  4. Select Install or Update Lync Server System
  5. On Step 3 of the deployment wizard, select Run or Run Again
  6. Click the drop down next to Default certificate and uncheck all boxes except Web services external”
  7. Click Assign to select your public CA cert and click Next all the way through
  8. Verify that the friendly name for “Web services external” is the name of your public cert
  9. Close

This ensures that the external web site in IIS uses the right certificate as well as having it registered within the Lync topology.

DNS Issues

One issue I found with DNS was the way that the lyncdiscover record was created. In some Lync setup guides, the steps are to create a CNAME record for lyncdiscover to point to whatever external Lync address you choose to use. I found that the lyncdiscover site would not show up properly in this situation, and that changing the lyncdiscover record to an A name pointing directly to the public IP address resolved issues with automatic discovery.

Another recommendation is that you set the internal A name record for lyncdiscoverinternal.domain.com to point to the external interface of the reverse proxy. This helps users who roam from external to internal networks while connected to Lync on mobile devices, a situation that might cause traffic to be directed somewhere else based on DNS.

TMG Setup Issues

Again, TMG was not so complicated to set up and most of the guides are very easy and accurate to follow. One thing that I did have issues with was in setting the correct “To” address in the Web Publishing rule. Most of the guides were pretty unclear as to what to put here. Some said to put the internal fqdn (ie lyncprod.domain.local) and others showed a public address (ie lyncprod.domain.com). It turns out the To:  address on the TMG should be the “External web services” URL that was selected in the Lync topology buider.

External Web Address

This maintains the chain of trust when forwarding from reverse proxy to FE server and back to the client. Also to ensure proper forwarding you should include the Lync FE server’s internal IP address for name resolution when setting up the Web Publishing Rule.

Web Publishing Rule

Summary

There you have it. I hope this guide helps anyone who finds themselves in a jam and can’t locate any information other than the standard guides that are out there. Please feel free to post any comments if you have any questions!

-ScriptdEEZ

Still Having Trouble??

Is Mobility still an issue? Are you having trouble with Edge services? Desktop Sharing? Check out my latest blog for in-depth explanation of all Lync 2013 Edge and Mobility Requirements!

 

 

Resources:
Reverse Proxy TMG Setup – http://www.darylhunter.me/blog/2011/11/lync-2010-reverse-proxy-part-3.html
Lync External Access Deployment Checklist – http://technet.microsoft.com/en-us/library/gg425910.aspx
Lync Mobility Deployment Process – http://technet.microsoft.com/en-us/library/hh690023.aspx
TMG Publishing Rules for Lync – http://blog.ucmadeeasy.com/2010/09/24/publishing-lync-server-2010-rc-simple-urls-and-web-components-with-forefront-tmg-2010/

If you found this article helpful or interesting, please donate a tip!
(LTC): LYs82mDXPohGDCzeRct8HkJwUCfwveGH1t
(BTC): 19JUVeefSBNbxUZNNmbDqfcctU6im6vsNg

Advertisements

8 thoughts on “Lync Server 2013 – Mobility Setup Tips

  1. Thanks for your post!!! I have been wrapping my brain around the concepts and precepts of Lync 2013 as a newbie for the past six months; several issues with the logic have plagued me until I discovered your post. Too many authors leave detail to chance, ie the internal or external port of the reverse proxy. Thanks for clarifying and adding useful info to the internet resources! Keep up the good work.

  2. Pingback: Lync 2013 – Standard Edition with Edge Server | ScriptdEEZ
  3. Well explained article and thanks for the same. Would like to clarify what would be requirement if you want to have the Mobile clients to work only internally. Can this be achieved with one FE server and one IIS server configured for reverse proxying internally? I was told by a vendor that even your requirement is to have Mobile clients to work internally, we need to have Edge and Proxy Server published to internet, two public IPs, External CAs etc. Please clarify.

    • This is a perfect example of the confusion I’ve seen around Lync Mobility…

      What your vendor told you is not necessarily true. If you want just simple Mobility, providing these two basic services:

      1. External Users from organization can connect with Lync from a PC
      2. External Users from your organization can connect with Lync from a Smart Phone

      …then you do not need an Edge server.

      If you want other services like Conferencing, joining meetings with other companies, desktop sharing, application sharing, whiteboarding, etc. then you need an Edge server.

      Basic Mobility for external IM can be set up without the need for an Edge server. You WILL, however, require some form of firewall as a Reverse Proxy. The term “Reverse Proxy” is kind of confusing, but all it does is present a certificate on a public IP address, listens for certain URL headers on that IP (lyncdiscover.contoso.com), and translates incoming ports 80 and 443 to 8080 and 4443 going to Lync’s External Web Services URL (on the internal interface of Lync FE).

      There is no way to get this to work without a “Reverse Proxy” unfortunately, but you do NOT need an Edge server for this basic Mobility.

      There are two primary reason for the Reverse Proxy. One is that the Lync FE server listens for connections to it’s “external web services”, the component that serves mobility, on ports 8080 and 4443. Autodiscover and default behavior for browsers when accessing a site on HTTPS is to use 443. Now, Lync FE does use IIS to serve up its web access points but these are not configurable IIS sites in the traditional sense. They are very closely tied to the Lync topology and if you try to change any bindings or mappings on the IIS site you will have problems.

      The second reason for the Reverse Proxy is to keep clients from timing out if, say, they are working with Lync on their cell phone from an internal wifi network and they roam to an outside location then their wifi connection may become external. If there were two separate access points and DNS entries for mobility, one external and one internal, Lync would time out and have to reconnect and re-authenticate rather than just passing the connection from the internal wifi to the carrier’s mobile network to the external network. This could be disruptive to your users’ workflow and so Microsoft enforced this Reverse Proxy requirement in order to keep these timeouts from happening. All DNS records, both internal and external, for the Mobility URLs (lyncdiscover, lyncdiscoverinternal, lyncweb) all need to point to the external IP of the Reverse Proxy.

      So yes, set up a Reverse Proxy on whatever firewall is fit to provide certificates on an external IP and perform this listening and port forwarding. The listening piece of this is very important, as not only do the ports have to be translated but the headers in the packets have to match and be sent to the FE properly. That is why Microsoft recommends using TMG, since it has that capability outlined clearly in its Listeners component.

      You also need the Public CA certificate SANs that I mentioned above for just basic Mobility. Those SANs again are:

      1. Lyncweb.contoso.com (Lync External Web URL) – Should be the Common Name
      2. lyncdiscover.contoso.com (Client Discovery)

      Add meet.contoso.com and dialin.contoso.com for users to join meetings from the outside and use their phone to dialin, but again these two are not necessary for just the most basic of Mobility which is IM.

      And yes, you also need an internal CA Cert for the “Internal web services” site that serves internal clients who use the organization’s internal SIP srv record to resolve to the FE directly. That would be a Lync client logged into a domain machine and using .local DNS namespace.

      I hope this helps!

      • It worked!!!!. Hope Microsoft will publish this article in their Technet forums so that it will benefit users like us. I am sure that there will be many more who may come across similar scenario. Anyhow, this article will definitely clarify it. Thanks for the pain you have taken to give such a detailed explanation. Keep going.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s