我们有一个使用共享configuration设置的IIS 7.5服务器场。 configuration文件被导出到两台机器都可以访问的networking共享。 我们知道共享configuration正在工作，因为所有内容都是同步的 – 新的站点，站点绑定，URL重写规则 – 除应用程序池标识SID 之外的所有内容。
在IIS 7.5中创build应用程序池会触发以S-1-5-82开头的SID创build新的应用程序池标识（ 更多信息 ）。 启用共享configuration后，应用程序池将显示在两个节点上，因为它存储在ApplicationHost.config中，但其相应的SID仅在通过“添加应用程序池”进程的节点上创build。
我可以在第一个节点上打开“计算机pipe理”，并在IIS_IUSRS组中查看应用程序池标识。 但是，在另一个节点上，这个组是空的。
这是IIS中的错误，还是我们的共享configuration有问题？
更新： IIS_IUSRS组是无关紧要的。 问题的performance是我可以将文件权限分配给一个节点上的应用程序池标识，而不是另一个节点上。 它与此问题的主题类似，但运行IISRESET不会将其修复到第二个节点上。
我们…我会在这里吐出我的理解，你可以挑选你喜欢的东西。
S-1-5-82- {应用程序池名称的SHA1}对应用程序池所在的所有框都是相同的，并且名称相同。 共享configuration将在所有框上创build相同的应用程序池; 应用程序池将为它们创build相同的SID。
但是，这个ApplicationPoolIdentity在我熟悉的任何界面中通常不会以用户帐户的forms显示。 当然，它会出现在奇怪的权限列表中，但不会出现在组中，也不会出现在用户pipe理器中（或者我们现在称之为的）。
但其相应的SID仅在通过“添加应用程序池”进程的节点上创build
你怎么知道？ 小组成员的事情？ 我怀疑你的实际问题是你没有描述过的 – 你正在描述一个更像是其他问题的症状的问题。 组成员的声音听起来像某人某人 – 它不是共享configuration的一部分，所以不会复制。
更进一步：通常不需要任何东西成为IIS_IUSRS的成员。 只有在manualGroupMembership为true的情况下，应用程序池帐户才需要添加到此组。
所以这听起来像是有人在一台机器上手工添加了“IIS AppPool \ YourAppPoolName”（注意间隔）到IIS_IUSRS组，并没有打扰到第二台机器。
应用程序池标识永远不会以用户帐户（AFAIK）的forms显示，并且通常在该组中不可见（因为manualGroupMembership = false是默认值，每个人都对此感到满意），并且该组中的成员资格不是某个共享configuration得到你。
所以我可以想象，因为两个框上的App Pool Identity名称是相同的，所以SID 将是相同的， 因为它是基于名称的计算值 ，并且您的问题可能不是您想象的那样（但是在猜测，就是在第二个框上，App Pool ID没有被添加到IIS_IUSRS，而有人做了manualGroupMembership = false）。
因此，将它视为任何其他本地用户帐户 – 因为它是 – 并将其添加到它所需的任何权限组成员 – 共享configuration不会复制组成员资格（或任何其他框级别的属性），只是IIS组态。
问题出在用户configuration文件服务。 共享configuration同步IIS节点上的应用程序池，并按预期工作。 通常情况下，创build新应用程序池时，User Profile Service负责创build与App Pool身份对应的用户帐户。 在这种情况下，这是失败的。
重新启动用户configuration文件服务解决了这个问题。 现在，在本地或远程添加新应用程序池时，将创build用户帐户。