Richard Dudley

When you first extend a virtual server in an SPS Portal, you have the opportunity to choose an application pool.  Changing from the default app pool requires a few tricks (I'll save those for another blog post).  You can also change the application pool after the portal is set up and running.  Note that I'm not talking about the App Pool Identity--I'm talking about a completely different application pool.  My reasons for doing this were to change the user account under which one of my portals ran for security reasons.

To get about 99% done, there's a great article at http://www.microsoft.com/technet/prodtechnol/office/sps2003/maintain/apppool.mspx.  The Resource Kit covers some of the same information, but lacks the concise step-by-step instructions in the Technet article.

If, after the IISRESET at the end, yuo get a 403 error when you try and access the portal, check that you set the app pool on the _vti_bin, _layouts and _wpresources directories through the IIS Admin tool.  I forgot to do this, and got that 403 error, which seems to be a pretty common problem judging by the info in the newsgroups.  Note that each portal will have these dirs installed underneath them--you only need to change the app pool settings for the ones below the virtual dir you are changing.  Leave the others alone!

Once I had the 403 worked out, I started getting a 500 Internal Server Error.  I found that I also needed to add the user account to the <machine>\Administrators group.  I tried creating another user group and simply granting it the same permissions on the 60 hive as the Admin group, but that didn't fix the problem.  The user, for whatever reason, needed to be in the Administrators group.  If I ever figure out what other permissions were needed where, I'll post them.

Once I had the 403 and 500 errors worked out, my portal operated as normal.  Groovy!

There are a number of reasons why you might want to separate multiple portals into one or more application pools, but you need to resist the temptation to do this too much, as each app pool is a memory hog (requiring 5-10x more RAM than simply adding a portal to an existing app pool).

<update 2005-10-21>

In a private e-mail, Paul Schaeflein pointed me to a blog post of his on a similar topic.  The article I cited above has you add the app pool user ID to three local groups--IIS_WPG (as in Paul's post), SPS_WPG and STS_WPG.  I confirmed I had my user listed in all three groups (it was), and removed it from the Administrators group.  I again got the 500 error.  I put the user back into the Administrators group, and the portal worked again (I'm doing this with a test portal--don't panic).  It's possible that permissions are not set correctly on my server, although I didn't do anything fancy during installation of SPS or when I extend the virtual directories.  This is a Win2K3 server, configured for worker process isolation mode.