{sharepoint} More on SharePoint 2010 Application Pools

More on SharePoint 2010 Application Pools

Print | posted on Friday, December 04, 2009 3:26 PM

Blimey! My recent post about worker processes generated a large number of follow up questions. Instead of answering all of these individually, this post will cover the details and perhaps be useful as a reference in the future.

Before I get started there is one thing which perhaps is obvious, but needs to be made clear: SharePoint 2010 is a beta release. It is always possible that things change come the final RTM release. That’s the point of a beta really!:)

I am going to assume the same setup characteristics from the example in the previous post.

What are the Application Pools that SharePoint 2010 creates?
This
has been the most common question. My previous post deliberately
ignored one and also skimmed over some details as well. Once we’ve
installed SharePoint, run the Configuration Wizard and the Farm
Configuration Wizard, we will have six Applications Pools in addition to those on the machine already. These are detailed below.

1. SharePoint Web Services Root
   Identity: LocalService
   Status: Stopped

   This guy hosts the SharePoint Web Services
   IIS Web Site and is on every machine in the farm. This is the host web
   site for Service Applications, it is analogous to the old “Office Web
   Services”. Service Applications WCFs are hosted in here as Applications
   which can (and should) be run in a different Application Pool. Whilst
   the IIS Web Site is important for bindings and other configuration, it’s
   absolutely OK that this Application Pool is stopped. If you try and
   browse the site, you will get a 503.

2. SharePoint Central Administration v4
   Identity: SharePoint Farm Account
   Status: Started

   This
   one is pretty straightforward. It’s responsible for Central
   Administration on the machines hosting it. It will include at least
   three applications (root, images, inc) plus an app for each Language
   Pack you have installed

3. SharePoint Web Services System (which is named with a GUID)
   Identity: SharePoint Farm Account
   Status: Started

   This
   guy hosts the Topology Service Application, which is known as the
   Application Discovery and Load Balancer Service Application.

4. SecurityTokenServiceApplicationPool (which is named with a GUID)
   Identity: SharePoint Farm Account
   Status: Started

   The
   guy hosts the Security Token Service Application, required internally
   even on a single server farm as well as for supporting inter-farm
   operations, and external Claims.

5. SharePoint Web Services Default (which is named with a GUID)
   Identity: SharePoint Services Account
   Status: Started

   This
   is the big daddy. It hosts all the other Service Applications. You will
   have as many applications in here as you do service applications
   deployed unless you configure their hosting manually.

6. SharePoint – 80
   Identity: SharePoint Services Account
   Status: Started

   This
   is the default application pool used to host end user Content Web
   Applications having used the Farm Configuration Wizard to get up and
   running quickly.

Should I stick with those, I should I do it “properly”? 
It’s
Beta – so yes, you should really, unless you are looking at “advanced”
farm topology and other design aspects. If you are a developer, step
away from the console! Also, be patient and wait for the real RTM
guidance. But the bottom line is the first four are required. You don’t
want to be fiddling about with them. The last two are what the Farm
Configuration Wizard produces and in a real world deployment you would
certainly not create the last one, and you would probably change up the
service apps one as well.

What is up with the crazy GUIDs?
Horrible
aren’t they! An IIS Application Pool can have but one unique
identifier, it’s Name, for which uniqueness is enforced. It works
perfectly. However SharePoint has decided to use GUIDs for this Name.
Within Central Administration the Application Pools are displayed using a
SharePoint only property – Name, which is actually a Display Name (e.g.
SharePoint Web Services Default).

Moreover, the GUIDs used
are, wait for it, yes – unique. These aren't “well known GUIDs” like
class ids. They will be different on every installation. It would appear
the GUID love from SQL server has found it’s way into IIS thru the back
door.

One hopes this will be changed in the future. In the
meantime if you want to find out which App Pool in IIS is which App Pool
in SharePoint (crazy I know!) without fiddling around in the Internet
Services Manager, you can do so with the following PowerShell:

Get-SPIisWebServiceApplicationPool | select Id, Name

Does SharePoint 2010 still “manage” aspects of the Application Pools such a recycle times?
Yes.
This is the same. Avoid fiddling with these settings (e.g. Regular Time
Interval) there are a couple dodgy blog posts out there by people who
should know better recommending you change these settings. Don’t! They
are in there for a reason and besides the SPF Web Application Service is
responsible for their management. There are some settings which are
tweak able, but it’s way too early for guidance here, and besides such
tweaks are only useful in production environments.

Hopefully
this helps address the questions I have had in response to the earlier
post. I’ll be posting more on SharePoint 2010 process isolation in the
future.