Lately we had to stop (and start) the SharePoint Foundation Web Application services and the Central Admin services on several servers. We noticed that the bindings that were previously active were now totally different from what they were.

Some background: we got some SharePoint Web Applications which are made available over Claims Authentication. In order for these applications to be crawled by the Search service we extended them so that they could be made available over Windows Authentication. Besides that, we also had some URL and TCP/IP Port changes over the past year.

It seems that we did several changes on Alternate Access Mappings (AAMs) (SharePoint Central Admin) and on the IIS bindings (IIS Management Console). And that’s where the problem lies. When you create a Web Application, or extend it, you are asked some parameters (like host headers), and these are stamped in the SharePoint configuration database. These are the settings that are used when you start the “SharePoint Foundation Web Application service” on a given SharePoint server. When you modify AAM’s or IIS bindings, these settings become inconsistent.

Here’s how you can retrieve what’s currently known for your web application:

• $web = Get-SPWebApplication -Identity https://site.customer.com
• $iisDef = $web.GetIisSettingsWithFallback("default")
• $iisDef.ServerBindings
• $iisDef.SecureBindings

If you are interested in the settings (bindings) of an extended site, you have to pass the correct zone along. E.g. for the custom zone:

• $iisCust = $web.GetIisSettingsWithFallback("custom")

Now I tried editing these in several ways, but it seems like this information is really read only. The only way I found to modify these is to go through the Central Admin web application management section and choose the “remove SharePoint from this site” option when selecting a web application (below the delete button). Afterwards you can extend the web application again. I performed this for several sites and it’s not really that painful. Don't forget, your site becomes unavailable in the whole farm as it's deprovisioned and re-deployed afterwards. Obviously this can be scripted as well.

Here’s the source of my information: MSDN Blogs: How to properly change the Host Header URL of a web application in SharePoint 2010

Things I’ve learned #1: the things I conclude from my tampering with web applications:

1. There’s no way to specify what IP to listen on when creating a web application/ extending it
2. There’s no way to select a specific certificate when creating a web application/ extending it (you can select “use SSL” though)

Out of these 2 I assume that you can modify these directly in IIS without breaking anything. Obviously if you start the SharePoint Foundation Web Application service it’s up to you to (re)do the proper IIS configuration.

Things I’ve learned #2:

1. Always specify a host header. for port 80, for use SSL and for custom ports.

As SharePoint doesn’t allow you to specify an IP, you’ll be blocked from creating an other site with “use SSL” checked if you don’t specify host headers.

Things I’ve learned #3:

Perhaps a bit dirty, but we noticed that some of our sites weren’t being added in IIS. The following lines re-triggered the registration of the web application in IIS without having to stop and start the SharePoint Foundation Web Application service.

• $web = Get-SPWebApplication https://site.customer.com
• $web.ProvisionGlobally()