Danger, Will Robinson! This does not mean what you may think it means!
Stopping Windows SharePoint Services Web Application on a member of your SharePoint farm does not actually stop any services running on the server. It indicates to WSS that this member will no longer perform the Web Front End role for the farm and the Config_db is modified to reflect this change in the farm topology.
As a result, the next time this farm member checks its roles in the Config_db and learns that it no longer needs the content web applications, it deletes the applications and the directories used by those applications on the file system.
Not to worry, you say, because if I start Windows SharePoint Services Web Application on the farm member again, it will magically create both the application and the file system from information contained within the Config_db. In fact, if one adds a member to the farm and starts the WSS Web Application (role) on the new member, all the required IIS applications and directories will be created on the new Web Front End member from information contained in the Config_db.
True. . . but what is contained in the Config_db concerning the web applications?
When one creates a new application in Central Administration, the information entered in the creation pages of Central Administration is placed in the Config_db and then the appropriate WFEs in the farm (those running the WSS web application) check the updates in the Config_db and create the appropriate applications and file system directories USING DEFAULT SETTINGS WHERE INFORMATION IS NOT INCLUDED IN THE CONFIG_DB.
Therein lies the danger. Only the information ORGINALLY entered into the creation pages in Central Administration is stored in the Config_db.
What information may be missing?
· Any customizations made in IIS Manager including additional host headers or changes to host headers, additional port numbers, bound IP addresses, changes to authentication methods, SSL certificates and configurations, etc.
· Any changes or additions to the file system including ANY modifications to the web.config file.
You may have noticed by now that even if you add Alternate Access Mappings in Central Administration Operations, the new host headers do not get added to the IIS web site (application) properties. You will need to add them manually. The host header information will be discarded when the farm member deletes the web sites as instructed by the Config_db settings and will not be included should the member subsequently assume the WFE role.
Here is the results of some of my tests with screen shots:
Original configuration of web sites from IIS manager:
Portal was configured with two Host Headers with both host headers were configured as alternate URL mappings for the application:
· (default) portal, port 80, all unassigned
· Portal.trainsbydave.com, port 80, all unassigned IP addresses
SSL was configured with all unassigned, port 443 (This was the only site using 443 for SSL.)
Step 2:
I stopped the WSS Web Application in Central Administration, Operations, Services on the Server.
Here is the results in IIS Manager:
Step 3: Restarted Web Application in Central Administration, Operations, Services on the Server.
Here is the results in IIS Manager:
Note that web sites have the same identifiers as before. However, the Portal application was missing all of the custom settings:
It was also missing the SSL certificate.
Step 4: I restored the IIS metabase from a portable backup with the following results:
All SharePoint sites worked as before (almost, more to follow).
So, it seems that the quickest way to restore the IIS configuration of a WFE after the Web Application has been stopped and restarted would be to use IIS backup & restore.
If one has multiple WFEs using bound IP addresses for SSL, then the restores would need to be accomplished from local backups on each machine. For new WFEs, a portable backup could be restored on the new WFE and then local or NLB IP addresses bound to the individual sites.
(I did not have multiple WFEs for the purposes of this test.)
But wait, there’s more. . .
A Safe Control Assembly line had been added to the web.config for the application by the deployment of a solution prior to the re-cycling of the WSS Web Application role.
In the newly created Portal application’s web.config, the SafeControl Assembly line was missing and my deployed solution no longer worked.
A folder containing non-SharePoint web pages placed in the file directory of the web application no longer exists and links to those pages no longer function.
So we not only need a portable IIS Metabase backup to restore IIS configuration or to create them on the new WFE, but we also need a current file system backup that must be restored to have fully functioning SharePoint applications simply because the information stored in the config_db is incomplete.
I can understand that non-SharePoint information need not be stored there. However, it only seems logical that anything accomplished through the Central Administration pages or with the use of STSADM.EXE should be stored in the database. Also, the inability to added host headers in IIS when they are defined in Alternate Access Mappings and store them in the database is a weakness. Even the storage of SSL certificates and configuration would not have significant impact on the database size and perhaps make possible the implied promise of role information storage in the config_db.
Remember: Portable IIS Metabase backups and directory files system backups of every WFE with every change to IIS and to SharePoint configuration.
Perhaps, if enough people open a support case with Microsoft Support Services and ask for a Design Change Request, a solution can be provided within a service pack or certainly by the next release.
Joel Oleson has provided some information on this issue in his blog:
http://blogs.msdn.com/joelo/archive/2007/01/02/relationship-between-the-iis-metabase-and-sharepoint-configuration-database.aspx
Thanks to Joel and Troy Starr for their assistance as I researched and tested the impact of the role changes.