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:
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:
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:
- Set the Outlook Web Access SSLOffloaded registry key: http://technet.microsoft.com/en-us/library/bb885060(EXCHG.80).aspx
- Remove the SSL requirement from all Exchange virtual directories via IIS Manager.
- Edit the Exchange Web Services web.config file to force HTTP: http://technet.microsoft.com/en-us/library/ee633481.aspx
- Configure Outlook Anywhere SSL Offload: http://technet.microsoft.com/en-us/library/aa998346.aspx
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:
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.
New site theme looks nice.
Exchange 2010 SSL Offloading
Great find with the Autodiscovery webconfig! I am trying to do the exact same thing with an f5 loadbalancer (SSL offloading, etc). However, we still cannot get this to work even after modifying the ews and autodiscover web.configs. In your testing, you said you went to https://casarray... to test autodiscover. However, by default clients will be using the internal name of a random cas for this. Did you have to hardcode the internal autodiscover url to be the cas array at some point? I cannot find any documentation on how to hardcode the autodiscover internal url.
Thanks!
Thanks Mr. Weber.
Jon, you can set the internal service connection point for Autodiscover with the Set-ClientAccessServer cmd-let. You’ll want to do that usually for any deployment so you can push Autodiscover through the load balancer instead of the default of letting clients pick one round-robin fashion. I usually set it to the same URL as I use for Set-AutodiscoverVirtualDirectory -InternalURL <path>.
You can script these changes as well. Verify localhost accepted changes, as I had to reapply the nossl setting manually through IIS manager on the root site on one of the servers in our array.
cd C:\Windows\winsxs\amd64microsoft-windows-iis-legacyscripts31bf3856ad364e356.1.7600.16385none_da3b5e9090e80564 cscript /nologo adsutil.vbs set w3svc/1/root/AccessSSL False cscript /nologo adsutil.vbs set /w3svc/1/root/Autodiscover/AccessSSL False cscript /nologo adsutil.vbs set /w3svc/1/root/EWS/AccessSSL False cscript /nologo adsutil.vbs set /w3svc/1/root/Exchange/AccessSSL False cscript /nologo adsutil.vbs set /w3svc/1/root/Exchweb/AccessSSL False
cscript /nologo adsutil.vbs set /w3svc/1/root/IISADMPWD/AccessSSL False
cscript /nologo adsutil.vbs set /w3svc/1/root/Microsoft-Server-ActiveSync/AccessSSL False
cscript /nologo adsutil.vbs set /w3svc/1/root/OAB/AccessSSL False
cscript /nologo adsutil.vbs set /w3svc/1/root/owa/AccessSSL False cscript /nologo adsutil.vbs set /w3svc/1/root/Public/AccessSSL False
cscript /nologo adsutil.vbs set /w3svc/1/root/UnifiedMessaging/AccessSSL False
I think you’d be better off using appcmd.exe in the IIS7/IIS 7.5 world, but yes, it could certainly be scripted.
Thanks for the suggestion, this is how you’d do the same thing using appcmd from powershell.
.”$($env:windir)\system32\inetsrv\appcmd” set config “Default Web Site” -commitPath:APPHOST -section:access -sslFlags:None .”$($env:windir)\system32\inetsrv\appcmd” set config “Default Web Site/Autodiscover” -commitPath:APPHOST -section:access -sslFlags:None .”$($env:windir)\system32\inetsrv\appcmd” set config “Default Web Site/EWS” -commitPath:APPHOST -section:access -sslFlags:None .”$($env:windir)\system32\inetsrv\appcmd” set config “Default Web Site/Exchange” -commitPath:APPHOST -section:access -sslFlags:None .”$($env:windir)\system32\inetsrv\appcmd” set config “Default Web Site/Exchweb” -commitPath:APPHOST -section:access -sslFlags:None
.”$($env:windir)\system32\inetsrv\appcmd” set config “Default Web Site/IISADMPWD” -commitPath:APPHOST -section:access -sslFlags:None
.”$($env:windir)\system32\inetsrv\appcmd” set config “Default Web Site/Microsoft-Server-ActiveSync” -commitPath:APPHOST -section:access -sslFlags:None
.”$($env:windir)\system32\inetsrv\appcmd” set config “Default Web Site/OAB” -commitPath:APPHOST -section:access -sslFlags:None
.”$($env:windir)\system32\inetsrv\appcmd” set config “Default Web Site/owa” -commitPath:APPHOST -section:access -sslFlags:None .”$($env:windir)\system32\inetsrv\appcmd” set config “Default Web Site/Public” -commitPath:APPHOST -section:access -sslFlags:None
.”$($env:windir)\system32\inetsrv\appcmd” set config “Default Web Site/UnifiedMessaging” -commitPath:APPHOST -section:access -sslFlags:None