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.

Exchange 2010 SSL Offloading

One of the deployments I've been working on recently involved using F5 BigIP hardware load balancers to do SSL offloading for a two-node Exchange 2010 design. To give some background here usually you would just pass through port 443 (I'm skipping over the RPC Client Access piece since it's not relevant here) from your load balancer straight to the Exchange servers, letting the servers handle the SSL encryption like in this diagram:

image

The benefit of that approach is it's simple and a very common deployment method. On the flip side, you can benefit from offloading SSL encryption to the BigIPs and gain some more advanced forms of load balancing. In this case the improved load balancing was the goal along with some internal policies forcing this approach. What happens with SSL offloading is the HTTPS traffic ends at the BigIPs which turn around and pass port 80 clear-text traffic back to the Exchange servers so they have a bit less CPU work to do. That strategy looks more like this:

image

The problem with this configuration is Exchange is really designed to operate with SSL in mind and you have to go out of your way to allow it to operate in clear-text. What you'll need to configure on each CAS server is:

The issue I ran into is after following all of these steps Autodiscover was still not functional through the load balancing. I could enter https://<CAS Array FQDN>/Autodiscover/Autodiscover.xml into a browser and reach the XML file with no problem, but running the Autodiscover test within Outlook would return a 404 error. Every other service was working just fine:

image

This threw me for awhile and after a bit of searching I ran across KB 980048 where it's noted that Autodiscover cannot be used on port 80 with an HTTP POST request, which is what Outlook uses. My attempts at accessing the XML directly succeeded because I was only trying to download the file. Supposedly this is going to be fixed in Service Pack 1.

While the KB provides no immediate solution what I found that works is to use the same methodology Technet recommends for the Exchange Web Services web.config file. Go into your /Autodiscover folder and edit the web.config to replace all instances of httpsTransport with httpTransport (a simple search and replace should work). Be sure to save a copy before you make modifications, restart your server after making the change and you should be able to offload SSL for Autodiscover successfully. Since as far as I know this is undocumented today you can try this at your own risk, but it appears to be working.