Copying files with permissions

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.

The default for robocopy is DAT. This means it copies the data (file content itself), the attributes (Hidden, System, Read-only, etc.), and the timestamps. If handing it DATSOU, which includes security ACLs, auditing info, and ownership. This is directly from the documentation, copied over at the wonderful ss64:

 /COPY:copyflag[s] : What to COPY (default is /COPY:DAT)
                      (copyflags : D=Data, A=Attributes, T=Timestamps
                       S=Security=NTFS ACLs, O=Owner info, U=aUditing info).
              /SEC : Copy files with SECurity (equivalent to /COPY:DATS).
          /DCOPY:T : Copy Directory Timestamps. ##
          /COPYALL : Copy ALL file info (equivalent to /COPY:DATSOU).
           /NOCOPY : Copy NO file info (useful with /PURGE).

So why is DATSOU not working for you? That might help us figure out exactly what you are looking for? As you mention, there are some limitations. We ran into a similar wall with directories that did not have inherited permissions, which is the issue you described. You could build your own duct tape solution by parsing out info from SetACL, which is the most ridiculously powerful and dangerous Windows util I have seen. That is a pain in the ass though.

Solution two, pull what is probably an insanely large wim and just apply the thing to a fresh drive with imagex. There is no rule it has to be a Windows system partition; it can be any arbitrary group of files. I have not tried this, so I am sure others can shoot down this idea from experience.

Solution three, consider DFS replication. If you can keep the old share up, you can use DFS replication to just redirect requests for files on one share UNC path to go to another. I did that successfully recently and it saved me a BUNCH of trouble. I do not know your use case though.