I found a blog that describes the app pools created by default. Check it out here.
Details from the blog…
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