I\'m updating one of our installers for .NET 4.0 and IIS 7.5, and one of the tasks is to switch the AppPool over to use its own identity. I have found this fairly trivial i
That's an interesting question.
When you author a Permission element, it results in the record(s) of the LockPermissions MSI table. According to the MSDN, the records in this table are served by the InstallFiles, CreateFolders and WriteRegistryValues actions. When CreateFolder element is a parent, it's obviously CreateFolders action.
The security account corresponding to the ApplicationPoolIdentity is created when the appropriate AppPool is created. Now, ConfigureIIs action is scheduled later in the sequence than CreateFolders. It obviously doesn't make any sense to move ConfigureIIs before CreateFolders.
I'm not sure this will work, but I would try the following:
Replace Permission element with PermissionEx element (the one from WiXUtilExtension). It covers the functionality of Permission, plus adds more flexibility (for instance, not overwriting the ACLs, but appending).
Move the SchedSecureObjects action (the one responsible for handling PermissionEx stuff) after ConfigureIIs action (the one responsible for IIS stuff) if it's not there already.
Now by the time permissions are to be set, the appropriate security account should exist. You might also want to play with the way you reference it, for instance, with or without the domain part.