Relationship between the IIS Metabase and SharePoint Configuration Database
In SPS 2003 and WSS 2.0 the metabase stores the entire configuration for the IIS Web Site (IIS virtual server/IIS Web Application). In MOSS 2007 and WSS 3.0 this is true as well, but there are some slight differences that you should be aware of.
The configuration database cares about all the databases used, all of the IIS Web Sites/Web Applications, solutions, web part packages, site templates, web application and farm settings specific to SharePoint technologies (like default quota, blocked file types, antivirus configuration, etc...) and many that are as well listed in the IIS metabase (such as host header configuration, SSL enabled, authentication, and ports).
The IIS metabase contains the by default, the port, host header, authentication, and many unique items that are not in the config database (IIS bindings/IP Assignments, SSL Certificate, ISAPI, and HTTP headers, etc...)
Since these are all changes in the platform (WSS 3.0) I'll simply refer to them as differences in WSS.
In WSS 3.0 once an IIS Web Application (IIS Web Site) has been extended either being created via the Central Admin UI or via the IIS Manager or applicable IIS vbs create scripts. The IIS configuration that would be common across the WFEs is stored in the configuration database, this design is for consistency. A Timer job pushes down common configuration changes across the web farm. There are some cases where this could cause problems...
When you make changes to an IIS Web site directly through IIS Manager instead of SharePoint, SharePoint won't be aware of those new settings. When you stop the SharePoint Web Application service, SharePoint will delete those IIS Web sites from the server. When you then start the SharePoint Web Application service again, SharePoint will recreate those IIS Web sites based on the settings that SharePoint was originally aware of. (Those stored in the config db.) So, you have to restore the IIS metabase to apply the changes to the bindings, certificate assignments, etc., that you made in IIS Manager. This will make them stick. There's an explanation in KB 927376 that provides more detail.
The full set of IIS bindings and SSL certificates are not exposed in the web application creation UI - specifically the IP address assignment. The reason for this is that while the other bindings are usually identical for all servers in the farm, the IP binding is almost always unique for each server in the farm when you want to assign such a binding. This presents the problem where we would have to create a control to specify what that binding is on a per server basis, which doesn't fit well with our "each box is a clone of each other box" server farm model. And if you later decided to add a server to the farm, we would need to provide a way to specify what those bindings should be for the new server before it tried to create the IIS Web site for your web application. Currently the way to apply those items is to apply them via the IIS manager, do an IIS metabase backup, restart the WSS Web Application service, then restore IIS metabase.
The moral of the story... Use a mixture of Host Headers, ports (most common for SSPs Admin and Central admin), and IP bindings, for common configuration across the servers when possible to support hosting multiple IIS Web Sites/Web Applications on the same server. Be careful when you change any web application settings in IIS Manager... they may not be there after the services are restarted. Note: Host headers are supported with SSL with wild card SSL certificates. You can use IP bindings but they aren't exposed in the SharePoint web application creation UI, first go into SharePoint to extend the web application with a host header binding, then go into IIS Manager to remove the host header binding and add an IP binding and SSL certificate to the IIS Web site as applicable. Be sure to do an IIS metabase backup, restart the WSS Web Application Service and then restore the IIS metabase.
It may be new to some of you reading this, but prior to WSS 2.0 SP2 there was no support for IP bound IIS virtual servers. There is some good information in the “What's New in SP2” on advanced extranet configurations for reverse hosting, URL mapping, port changes, and limited support for ADFS.
The next major tip is to ensure you regularly backup your IIS Metabase. Given there is a possibility that it can become corrupt (haven't seen that happen in IIS 6), or overwritten by other applications (seen this many times), or by human error. There are scripts to backup the metabase (link is a WSH script to backup your metabase) on a daily basis with your backup software or with a script and scheduled task. Of course if you are making changes in the metabase via script or making changes via IIS Manager, you can use the GUI to backup the metabase before and after the change making it easy to roll back to your last known good state.
In summary...
What is the recommended way to configure IP bound Virtual Servers or SSL certificates in both a single server and those with more than 1 WFE?
In both cases, it's best to first to have SharePoint extend the web application with a host header binding, then go into IIS Manager to remove the host header binding and then add the IP binding and/or SSL certificate to the IIS Web site, backup the metabase, restart the WSS Web Application Service, and restore the IIS metabase. Then follow the same steps on all other servers as they are added to the farm.
Thanks Troy Starr for this explanation/work around and Daniel Webster and Bill English for bringing this to my attention.
<Update>Daniel has posted a bunch of good info on implications of WSS application service stop and start</Update>
Dan
