SharePoint is a Microsoft web based product. Like all other Microsoft web based technology, SharePoint leverages IIS6 or IIS7 Web Server. Network administrators’ familiarity with the IIS management console (MMC) can lead them to make inappropriate changes in IIS which will affect the stability of their SharePoint environment.
The first lesson I teach all new SharePoint administrators is: DO NOT MODIFY SharePoint SETTINGS THROUGH THE IIS MMC. If it can be done through the SharePoint Central Administration, it should be done through there. 99% of all SharePoint administration tasks can and should be performed through SharePoint Central Administration. Below is a compilation of common errors performed in IIS by SharePoint Administrators and their cause.
SharePoint administrator should never:
- Change IIS host headers for a SharePoint site without adding the corresponding Alternate Access Mappings (AAM)
An AAM should exist for every URL a user might type in the browser to access a SharePoint WebSite. Missing AAM have unpredictable effects and are in my experience the primary cause of unexplainable issues. An event will also be logged in the Windows Application log for missing AAM.
- Do not delete SharePoint Web Applications from IIS
SharePoint stores all its configuration information in the configuration database. This configuration information includes Web Application (WebApp) information. Deleting a SharePoint WebApp from IIS will not update the SharePoint configuration database. This discrepancy will cause several issues. Including potential account lockout problems (see example below).
- Change the IIS application pool accounts from IIS MMC.
It is best practice to have the SharePoint AppPools running under domain service accounts. There are many situations when the service account or password might need to be changed. This change needs to be made through SharePoint Central Administration and not directly through IIS MMC. The SharePoint site will stop working if the AppPool is changed through IIS.
IIS MMC is required to
- Add an SSL certificate to a properly extended WebApp.
- Add a new host header once an alternate access mapping has been added
- Optimize AppPool settings (http://blogs.msdn.com/joelo/archive/2007/10/29/sharepoint-app-pool-settings.aspx)
- Modify IIS logging settings
Situation: A SharePoint developer deleted a SharePoint WebApp from IIS. The deleted WebApp was using his user account as the App Pool service account. After a month, the domain policy forced him to change his password. The user then suffered continual user account lockouts.
Explanation: SharePoint still had some configuration information it the configuration database and the timer service was trying to perform some actions on the WebApp. Unfortunately, every time it tried to authenticate to a domain controller it failed due to the password having changed.
Resolution: Removing the WebApp from SharePoint Central Admin solved the user’s account lockout problems.