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.
- 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.
- 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
- 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.
- 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.
- 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.
- 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.