Wednesday, 17 March 2010

Administration: Changing a MOSS Site's Application Pool


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.


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


  1. Thanks for interesting post :-)
    I just created new app pools, assign sharepoint applications to them, and then manually modify keys like this

    in app pools' config files, typically placed in folders like this "c:\inetpub\temp\appPools\SharePoint Auto-Generated Content\SharePoint Auto-Generated Content.config"
    I did it on my work environment, with sharepoint server 2010 standalone installation, so not sure this method is suitable for real-world farms.

    Michael Gamza

  2. Hi Michael,

    Thanks for the comment.

    I wrote this post a while ago so look at things a little differently nowadays.

    SharePoint manages the association between Web applications and application pools and you should not be making these changes yourself.

    As far as I know the only supported way of changing the app pool/ web app association (in 2007 at least) is to recreate the Web app, as I outline above.

    For more on app pools, see this post from Spencer Harbar:

    I also did a recent blog on common SharePoint administration mistakes if you are interested: