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.
Enabling the "Allow users to connect remotely using Terminal Services" policy setting will cause Windows XP machines to which the policy applies to begin allowing terminal services logons (assuming that you're not blocking inbound TCP port 3389 with a Windows Firewall or other firewall setting).
The "Local Policy Does Not Permit You to Log On Interactively" error you're receiving is best mitigated by nesting a group that contains the users who are allowed to logon via Terminal Services into each Windows XP computer's "Remote Desktop Users" group.
You can do this group nesting with Group Policy. Use the "Restricted Groups" functionality (under "Computer Configuration", "Windows Settings", and "Security Settings") to perform the nesting. Make an entry for the "DOMAIN\Domain Users" (or whatever group contains all the users who should have Terminal Services logon access) group there. In the properties for that entry add "Remote Desktop Users" in the "This group is a member of:" section of the policy.
I'd recommend, initially, applying this policy only to some test computers. You can verify it's working by examining the membership of the "Remote Desktop Users" group on the affected computers after the policy has been applied. Once it's to your liking apply it more broadly.
Best Answer
As you said, you need to add the to the local Remote Desktop Users group. If you want to set it up "server side", the solution is to create an AD group, add the needed accounts to that group, then create a GPO setting "Restricted groups":
http://social.technet.microsoft.com/wiki/contents/articles/20402.active-directory-group-policy-restricted-groups.aspx