Which we found out when we tried to use load balancing for the https and certification. What we want to do is to let the load balancer redirect to any of the two frontend webservers, and not create the certificates directly onto the IIS sites (as usual). So we entered the https URL in the AAM, but we did not create a cert or activate the 443 port on the web application. But when we tried to access the https URL in our browser, we got two login prompts – the first against the https and then a login for the http URL! We changed every setting, tried different configurations, but still we could see in the logfiles that there was a redirect from incoming https to http! WTF? We even created a certificate on one of the IIS web apps just to be sure that the site was working. And that was no problem at all. Of course. No errors in configuration there 🙂 Got a mail from my collegue with a link that describes this error on MS site:
http://technet.microsoft.com/en-us/library/cc288609.aspx#section6
This is a part of the error description that MS gives on the link above:
“Note: Installing the Infrastructure Update for Windows SharePoint Services 3.0 in a Windows SharePoint Services 3.0 farm that uses alternate access mappings with a reverse proxy or a network load balancer, such as in an extranet deployment, may cause some public URLs to become unresponsive. Microsoft is aware of this issue and is developing a solution. Before installing the Infrastructure Update for Windows SharePoint Services 3.0, customers who use this configuration should use a test environment to verify that public URLs remain accessible after the update is installed. “
No wonder. The funny thing about this is that when you have installed the infrastructure update, – there is no return! You cannot remove it. (And you do want all updates when you install the server for sure.) So I think it is a bit late for “verify that public URLs remain accessible after the update is installed” once you’ve installed the update. Even on a test server…
