I've configured SSL offloading on an Exchange 2010 CAS Array. I've followed the steps in the avialable articles, double and triple checking. However when I try to open http://mail.site.com/owa I am redirected to https://mail.site.com/owa. I hve cleared all the require SSL checkboxes on bath servers in the array, (including the root) I have set the SSLOffloaded reg key, I've reset IIS, I've even restarted both servers, numerous times. All the OWA and such specified urls have been setup for HTTP, not https. SSL offloading simply isn't working. We are planning on using HLB for exteral access and NLB for internal access. Any ideas on what I might have missed? On a related topic, why do all the hundreds of websites on configuring SSL in Exchange 2010 all ahve the same screenshots?

First - the CAS array should be used for Outlook MAPI TCP/IP access ONLY. The CAS array host name should be unique, used internally only. It should not resolve externally. If you want to use the same load balancer for HTTPS traffic, then you can, but this should be using a different name. So the CAS array address would be outlook.example.local, the OWA, ActiveSync, Outlook Anywhere etc would be host.example.com. With regards to your second question, everyone is probably lifting Microsoft's own screenshots, or those from msexchange.org etc. These are the ones I see most often: http://social.technet.microsoft.com/wiki/contents/articles/how-to-configure-ssl-offloading-in-exchange-2010.aspx (and the author also posts on msexchange.org) I presume that you have checked that IIS hasn't been setup to redirect http traffic to https? What have you done with regards to the URL on the OWA virtual directory? Simon. Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.

Our CAS array is "Client.company.int" OWA and such are published as Email.company.com. I'm not trying to get MAPI on the net, just OWA and such. Are you saying I can't use the same CAS servers for my CAS Array for internal MAPI and External HTTP? I checked IIS for redirection, and the EXternal URL is set to http://email.company.com. So essentially I'm trying to do SSL Offloading to the netscaler for the two members of my array for HTTP traffic, while keeong the array for internal clients for MAPI. Sorry I couldn't do more detail here, I'm not in the office right now. Dave

As I stated I've been through the Configuring SSL offloading instructions, twice now. The latest thing I've done to try to track down what is happening is I have changed both the internal and External URLs for OWA. For test purposes they are both: Client.company.Int/OWA When I open Email.Company.Com (that is a name in DNS that points to the NLB) the results are: https://email.company.com/owa/auth/logon.aspx?replaceCurrent=1&url=https%3a%2f%2femail.company.com%2fowa%2f If I navigate to Client.company.int/owa (also points to the NLB) the results are: https://client.company.int/owa/auth/logon.aspx?replaceCurrent=1&url=https%3a%2f%2fclient.company.int%2fowa%2f So somehwhere HTTPS is being forced on it, but all my require SSL checkboxes are cleared on both IIS server (there have been multiple IISReset /noforce commands issued as well as multiple reboots). Where else might this be hiding?

Being picky, because on a forum we have to take everything at face value, have you configured the URLs as http://host.example.com/owa or host.example.com/owa - they are different. If you run get-clientaccesserver |fl and get-owavirtualdirectory |fl get-ecpvirtualdirectory | fl get-webservicesvirtualdirectory |fl does that show the correct URLs. With regards to the CAS array bits - you need to be sure of your terminology. You can use the same kit and even IP address for CAS array and web services, however the term "CAS Array" is specific to one function, the MAPI client part. Don't mix them up as it can cause confusion. Have you bypassed the load balancer completely to ensure that isn't the cause of the problems? You should be able to browse to http://localhost/owa and get OWA to come up. Simon.Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.

The urls are configured as HTTP://host.example.com/owa, all the get's show the correctly configured names. We have NLB configured however it doesn't matter whether or not I use the local name/address or the NLB name/address I get the same results. The examples I posted above are from an internal machine with the DNS entries configured for internal addresses. As for the load balancer, that's where the problem showed up. We can't configure the load balancer because it show's the servers as down, again either by individual addresses or the NLB address. I don't think it's the url's per say as whatever url I use it becomes https with "replaceCurrent=1&url=https%" as shown in the example above. I just need to know where that action is coming froma as I can't see it anywhere.

Just a little more info: I ran the following: C:\Windows\System32\inetsrv>AppCmd list config "Default Web Site" -section:access and came up with: <system.webServer> <security> <access sslFlags="None" /> </security> </system.webServer>

If it was an environment I control, I would be seriously considering standing up a temporary installation of Exchange CAS role only to test with. You should be able to just change the URL from https to http in OWA, remove the require SSL setting, and with no other configuration make a HTTP request. You will not get the forms based login page. Basically try to have as close to a "out of the box" installation as you can. Something isn't correct there, but I am not sure what. The require SSL wouldn't be doing this, as that just throws an error back. The URL that is being redirected to is coming from Exchange. It is like the configuration isn't being seen for some reason. Are these the ONLY CAS servers that you have? No others anywhere? Thinking about how CAS gets proxied around and whether something else is happening that you aren't aware of. Simon.Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.

After getting MS support involved and using the right search words we found that this is working as expected. Oddly enough to get the behavior I wanted you need to set the SSLOffloaded key to 0. See the follwoing link for the details: http://social.technet.microsoft.com/Forums/en-US/exchange2010/thread/89795a1a-fc69-488e-94e7-b88eb43fdfe1