Administration: Changing a MOSS Site's Application Pool

Problem

Whilst developing a new version of our MOSS based product, we decided that we would like to isolate new sites by placing them in a brand new IIS 6.0 application pool. The idea behind this was to prevent issues on the new sites affecting clients on the old (stable) version of our product by running them in a new worker process.

While it would have been easy to opt to create a new Web application in our new application pool, we were faced with the problem of modifying an existing MOSS site to use a newly created pool. Note that I am not talking about change the identity of the application pool - this has already been documented on sites such as Eli Robillard's "World of Blog" - thanks Eli for the info.

When a member of our development team first asked me how to go about doing this, I incorrectly assumed that this would be as straightforward as going into IIS and modifying the properties of the MOSS Web site, having configured the appropriate SQL and group permissions (details of which are documented on technet).

However, having attempted this in our pre-production environment I can safely say this was simply not the case. Whatever I tried, SharePoint refused to allow me access to the site and greeted me with the standard MOSS access denied page. Taking a look online using a popular search engine, I found others had encounters similar issues but (as far as I could tell) had not come up with a solution.

Solution

The fix? In the end I simply had to delete and recreate the Web application. I created the process below which I hope others will find useful. Before you begin:

1. Backup your farm (i.e. full SQL backup)
2. Backup IIS on all WFE servers
3. Backup the web.config of the site you wish to modify the application pool for
4. Create the new application pool and document the new identity (service account) used
5. Document any custom Web parts that are deployed to the Web application
6. Document regional settings - e.g. time zone
7. Document authentication settings (e.g. Basic, Integrated)

As always, you should always test these steps in your own environment before using them in a real-world scenario:

1. Delete Web application in SharePoint Central Administration - do NOT delete the content database or IIS Web site just yet.

2. Delete IIS Web site

3. Create new Web application with new IIS site (making sure to select your brand new application pool) & note down default content DB name (to be deleted)

4. Perform an “IISreset /noforce”

5. Reconfigure your IIS settings (e.g. authentication providers, SSL certificate, host header bindings, home directory, logging, virtual directories)

5. Remove automatically created content db in SharePoint Central Administration

6. Confirm DB create date and delete temporary content db in SQL Server management studio.

7. Rename & Reattach correct content DB and confirm no. sites > 0 (could have attached the wrong content DB – minimal chance as I have checked all portal URLs)

8. Restore web.config (as SharePoint overwrites it upon creating a new Web application - you backed it up right?)

9. Add policy for web application if applicable

10. Redeploy web parts to all restored web applications if applicable

11. Set authentication providers

12. Set general settings (timezone) for restored web application

13. Set People picker settings for restored web application using STSADM

I think it's worth stating again that you should attempt these steps yourself in a test environment before attempting them on your production servers.

Feel free to let me know if you encounter any issues or whether these steps worked for you.

Cheers, Ben.

Subscribe to the RSS feed

Follow me on Twitter

Follow my Networked Blog on Facebook