0

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.

Community
  • 1
MALfunction84
  • 161
  • 1
  • 10

2 Answers2

1

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).

but its corresponding SID is only created on the node where I went through the "Add Application Pool" process

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.

TristanK
  • 8,953
  • 2
  • 27
  • 39
  • Ok, you're probably right about someone adding those app pool identities to IIS_IUSRS manually. However, the way I can tell the identities don't exist on the second node is that it doesn't resolve "IIS AppPool\" as an account when I try to apply file permissions. (We have DFSR set up so content is replicated between the nodes, and this also replicates file permissions.) On one box, I can see the app pool identity's name in the permissions. On the other box, it just shows a SID that it can't resolve to an account name. If I type in the account name, "Check Names" fails. – MALfunction84 Nov 04 '11 at 15:06
  • Actually, the issue I'm seeing is similar to what [this guy](http://serverfault.com/questions/114345) asked about, only I'm using shared config. – MALfunction84 Nov 04 '11 at 19:17
  • a) any events logged by WAS? ; b) IIRC the App Host Helper service is typically responsible for SID-to-name mapping, and if it's having a problem reading the shared config, that might explain it; c) it seems like various bits have been changed from defaults, and I'd be tempted to set one up to see if this is default behaviour. – TristanK Nov 04 '11 at 22:30
  • **a)** There are some WUSA errors on both machines. Our sysadmin is looking into that. **b)** That service is running on both machines with no problem. **c)** It's a pretty standard cluster setup: DFSR and shared config. – MALfunction84 Nov 07 '11 at 16:28
  • Don't know what WUSA is. c) it might seem that way to you, but my point is that adding people to IIS_IUSRS is unusual, and implies other advanced configuration properties have been set without understanding the implications. – TristanK Nov 09 '11 at 11:18
  • WUSA is a Windows Update service. Those errors are unrelated. – MALfunction84 Apr 11 '12 at 21:20
  • c.) Yes, someone else who didn't fully understand the problem had made that change to IIS_IUSRS, but that was all he did. It's a red herring. – MALfunction84 Apr 11 '12 at 22:05
0

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.

MALfunction84
  • 161
  • 1
  • 10