We have an IIS 7.5 server farm set up using shared config. The config files were exported to a network share accessible to both machines. We know the shared config is working because everything is synched -- new sites, site bindings, URL rewrite rules -- everything except the app pool identity SIDs.
Creating an app pool in IIS 7.5 triggers the creation of a new app pool identity with a SID beginning with S-1-5-82 (more info). With shared config enabled, the app pool shows up on both nodes because it's stored in ApplicationHost.config, but its corresponding SID is only created on the node where I went through the "Add Application Pool" process.
I can open Computer Management on the first node and see the app pool identity in the IIS_IUSRS group. However, on the other node, this group is empty.
Is this a bug in IIS, or did we do something wrong with our shared config?
Update: The IIS_IUSRS group is inconsequential. The manifestation of the issue is that I can assign file permissions to the app pool identity on one node but not the other. It's similar to the topic of this question, but running IISRESET doesn't fix it on the second node.
We-ell... I'm going to spout off about my understanding here, and you can pick and choose the bits you like.
S-1-5-82-{SHA1 of App Pool name} will be common to all boxes on which the app pool exists, with the same name. Shared Config will create the same App Pools on all the boxes; the App Pools will have the same SID created for them.
But this ApplicationPoolIdentity isn't typically visible as a user account in any interface I'm familiar with. Sure, it'll appear in the odd permissions list, but not in groups, or in User Manager (or whatever we're meant to call it these days).
How can you tell? The group membership thing? I suspect your actual problem is something you haven't described - you're describing a problem that sounds more like a symptom of something else. Group membership sounds like Something Someone Did - it's not part of Shared Config, so won't replicate.
Going another step further: it's not normally required for anything to be a member of IIS_IUSRS. Only if manualGroupMembership is true do app pool accounts need to be added to this group.
So it sounds like someone manually added "IIS AppPool\YourAppPoolName" (note spacing) to the IIS_IUSRS group on one machine, and didn't bother on the second.
The App Pool Identities are never visible as user accounts (AFAIK), and typically aren't visible in that group (because manualGroupMembership=false is the default and everyone's generally happy with that), and membership in that group isn't something Shared Config gets you.
So I'd imagine that because the App Pool Identity name is the same on both boxes, the SID will be the same because it's a computed value based on the name, and your problem is probably not whatever you think it is (but at a guess, it's that on the second box, the App Pool ID didn't get added to IIS_IUSRS, and someone made manualGroupMembership = false).
So treat it like any other local user account - because it is - and add it to whatever permissions groups it needs to be a member of - shared configuration doesn't replicate group membership (or any other box-level properties), just the IIS configuration.
The problem was with the User Profile Service. Shared Config synchronizes the app pools across IIS nodes, and that was working as expected. Normally, the User Profile Service is responsible for creating the user accounts that correspond to the App Pool identities when a new app pool is created. In this case, it was failing.
Restarting the User Profile Service fixed the problem. It is now creating the user accounts when a new app pool is added locally or remotely.