Lync Mobile Clients and TMG Server Farms

Quick update here for those of you publishing Lync web services with TMG and having trouble with mobile clients:

If you're following the Mobility load balancing requirements you'll find that cookie-based persistence is recommended in order to ensure the clients are always directed to the same Front-End server and session. This isn't an issue for a single FE, but once you start publishing a farm of FEs within TMG you'll notice the Lync mobile clients can't sign in. Android clients can for some reason, but WP7 and iPhone cannot.

The issue you'll face is that while TMG offers you cookie persistence when publishing a web farm, it really only works when the web listener is enabled for forms-based authentication. Since the Lync Web Services cannot be published via FBA the cookie never gets inserted. The end result is that TMG will now round-robin requests between the published farm members and the mobile clients will never sign in due to a ping-pong behavior. You can verify this behavior by draining all Front-End servers from the farm except for one and you'll see the clients can now sign in.

For a small deployment where a single FE can handle your entire user load I recommend switching your TMG persistence to source IP. All requests will hit a single FE, but the mobile clients can now maintain their session. And if an FE fails TMG will then fail over to the next server in the farm automatically. For the folks where multiple FEs are used more for capacity reasons you'll need to use something other than TMG for publishing Lync going forward.

Lync Web App and TMG Hangs

Something I've been noticing in a few Lync (and Exchange) deployments where Forefront TMG is involved is a significant delay in loading websites through the reverse proxy. I generally use Chrome as my primary browser and noticed sites would be extremely slow to load or appear entirely unresponsive when published through TMG. This was happening to both Lync Web App and Outlook Web App scenarios so I figured the issue just had to be with TMG. After some digging it turns out the problem is Chrome because when browsing to these sites in either Internet Explorer or Firefox the pages load just fine.

The issue here is a new feature in Chrome called SSL False Start which is supposed to speed up your SSL connections. Unfortunately, the end result against sites published by TMG is they don't ever load unless the user manually refreshes the page a 2nd time. Keep in mind this applies to any SSL website published by TMG and accessed by a user with Chrome, not just Lync Web App or Outlook Web App.

There is also an issue open on Google Code about this problem, http://code.google.com/p/chromium/issues/detail?id=67617, but there is no server-side fix. At this time the only solution is to modify the Google Chrome shortcut to disable the SSL False Start feature. Just modify your shortcut to be "chrome.exe -disable-ssl-false-start" and all is well.

Lync Reverse Proxy and Friendly Meeting URLs

Those who are familiar with publishing OCS Web Components through a reverse proxy may be in for a bit of a surprise when they go to publish their Lync services to the world and find the friendly meeting URLs not working . Unlike OCS, Lync depends on the host headers to route users correctly to the friendly meet and dial-in URLs. This means that although the services are using the same IIS website, going to https://<Friendly Meet URL>/somepage and https://<Web Components URL>/somepage are actually handled differently. In other words, you can't take a meeting link, replace the friendly meeting URL part with the web components address and expect it to work even if the destination web server is the same.

A typical ISA or TMG configuration looks like the following image when publishing Lync Web Components:

Note the Forward the original host header instead of the actual one (specified in the Internal site name field) selection box is checked. This ensures the reverse proxy passes along the original URL the user requested so IIS knows what content to serve up. If you don't select this option the reverse proxy will simply pass along the Internal Site Name field (lync-fe1.confusedamused.local in this case) as the host header. This works for web components, but not Meet or Dial-In URLs.

And while not the focus here, but another "gotcha" is to make sure you include the Meet and Dial-In friendly URLs on the Public Names tab for the rule or the reverse proxy won't respond to external requests for those names.