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.
There are several considerations in this, some which are handled on IIS (HTTP compression, caching headers fx), and some which are handled during the build process / before deployment (such as Javascript and CSS file concatenation & whitespace minification).
As such, it's a bit hard to give you a complete rundown in one answer, as some of it will depend on your build & release methods. In high level steps:
The site is "cookieless" by virtue of you using a new domain, one that is not tied to your webapplication. Since you're not setting any cookies for the domain (using f.x. .NET application code), it's then "cookieless".
You should absolutely enable HTTP compression for static text content such as Javascript and CSS.
I'm not the greatest IIS administrator, but as far as I can tell, you only need the default IIS components associated with the basic "Web Server (IIS)" server role.
You should absolutely enable long caching headers for the static content. The general recommendation is 31 days, but you can set it higher or lower. Remember, if you serve static content with long cache headers, then you must change the URL if you change the file, to avoid old cached content being re-used by the clients.
You should enable HTTP keep-alive (same docs as caching headers).
In addition to this, there are pre-deployement tasks, such as whitespace compressing the Javascript and CSS, and ideally compress PNG's better, etc. This is were your development tools and build cycle helps decide how to proceed.
When you're done, try downloading a few files from your static servers with YSlow enabled. I find that the "Classic V2" ruleset gives the biggest impact for the effort, so I would suggest check your score against this YSlow ruleset.
Of the "Classic V2" ruleset, these rules apply cleanly to your static server IIS instances & content:
3. Add an Expires or a Cache-Control Header
4. Gzip Components
10. Minify JavaScript and CSS
11. Avoid Redirects
13. Configure ETags
19. Use Cookie-Free Domains for Components
22. Make favicon.ico Small and Cacheable
Best Answer
With a 301 redirect using your language of choice?