Update: The original question was for Windows Server 2008, but the solution is easier for Windows Server 2008 R2 and Windows Server 2012 (and Windows 7 and 8). You can add the user through the NTFS UI by typing it in directly. The name is in the format of IIS APPPOOL\{app pool name}. For example: IIS APPPOOL\DefaultAppPool.
IIS APPPOOL\{app pool name}
Note: Per comments below, there are two things to be aware of:
- Enter the string directly into the "Select User or Group" and not in the search field.
- In a domain environment you need to set the Location to your local computer first.
Reference to Microsoft Docs article: Application Pool Identities > Securing Resources
Original response: (for Windows Server 2008) This is a great feature, but as you mentioned it's not fully implemented yet. You can add the app pool identity from the command prompt with something like icacls, then you can manage it from the GUI. For example, run something like this from the command prompt:
icacls c:\inetpub\wwwroot /grant "IIS APPPOOL\DefaultAppPool":(OI)(CI)(RX)
Then, in Windows Explorer, go to the wwwroot folder and edit the security permissions. You will see what looks like a group (the group icon) called DefaultAppPool. You can now edit the permissions.
However, you don't need to use this at all. It's a bonus that you can use if you want. You can use the old way of creating a custom user per app pool and assigning the custom user to disk. That has full UI support.
This SID injection method is nice because it allows you to use a single user but fully isolate each site from each other without having to create unique users for each app pool. Pretty impressive, and it will be even better with UI support.
Note: If you are unable to find the application pool user, check to see if the Windows service called Application Host Helper Service is running. It's the service that maps application pool users to Windows accounts.
Lots of overloaded terms here, and a change between IIS 7 and 7.5.
App Pool Identity vs App Pool Account
Let's start with the Application Pool identity (lowercase-i-identity, what I call the App Pool Account to avoid ambiguity):
The way I tell it, the Application Pool Account is the account used to boot an App Pool, and the identity that the App Pool assumes when it's not impersonating anyone else.
So whatever identity you give the App Pool, it's going to need to be able to read the files in the content folder: particularly {but not limited to} any web.config files (which form part of the IIS configuration, and control what the App Pool is going to be doing).
If it can't access a folder, it'll assume there might be an important (game-changing) web.config file in there, and display an error. So the App Pool Account needs Read access to all content folders.
ApplicationPoolIdentity
Why differentiate the App Pool Account (the identity of the app pool) from the App Pool Identity? Because the special-capitals-used ApplicationPoolIdentity is a new account type - a managed service account - introduced and made default in IIS 7.5 / Windows 2008 R2, and available from Windows 2008 SP2 as well (but not the default).
See Application Pool Identities on IIS.Net
When you create a website under 2008 R2 or later using the GUI:
- an App Pool will be created to host that website, and
- the account type will be ApplicationPoolIdentity, instead of Network Service (the 2008 default), Local Service or Local System
- a virtual identity, IIS AppPools\AppPoolName will be made available for use as a security principal on the local machine
With 2008 RTM, the default App Pool account was Network Service plus a unique app pool identity/uniquifier; the new R2/SP2 AppPoolIdentity account type is a Network-Service-like account (i.e. is the computer when connecting off-box), but prevents impersonation of another App Pool within the same box.
Back to the original question:
App pool account defines who your app runs as when it's not impersonating anyone else
Authentication method describes how you're going to authenticate the clients (in order to impersonate them)
The Anonymous user account defines who you're going to run as when impersonating a user for a request which isn't authenticated - IUSR is such a user.
Incidentally, with IIS 7.5+, you can set the Anonymous user account to be the Application Pool Identity (properties of the Anonymous authentication method), which might make it more straightforward to isolate and secure the content for a given website.
Set permissions using IIS AppPool\YourSiteName for the name format (see this post).
Best Answer
As noted in the comments, the question is ambiguous.
There is a Private Memory Limit (KB), which defines how large an application pool can grow in system RAM before it gets automatically recycled. For example, when you open Task Manager (taskmgr.exe), you'll see an instance of w3wp.exe running for each application pool. Add the Working Set column. I believe that corresponds to the Private Memory Limit setting.
There is a CPU Limit which dictates how much CPU an application pool is permitted to consume over a period of time. Its default is zero, meaning no limit.
There is a Queue Length setting which dictates how many simultaneous requests can be serviced before the server starts returning 503s. The default is 1000.
There is an Idle timeout, which defaults to 20 minutes. After 20 minutes of inactivity, the application pool stops. I always turn that off, as it takes time for the first request to process from an inactive application pool.
There is an ability to schedule a recycle at regular intervals or at one or more specific times. Perhaps an untimely recycle is interfering with a long-running operation, and the customer is having requests be canceled as a result.
Those are all of the usual suspects I can think of.