我们有一个使用共享配置设置的 IIS 7.5 服务器场。配置文件已导出到两台计算机均可访问的网络共享。我们知道共享配置正在运行,因为所有内容都已同步 - 新站点、站点绑定、URL 重写规则 - 所有内容除了应用程序池身份 SID。
在 IIS 7.5 中创建应用程序池会触发创建一个新的应用程序池标识,其 SID 以 S-1-5-82 开头 (更多信息)。启用共享配置后,应用程序池会显示在两个节点上,因为它存储在 ApplicationHost.config 中,但其对应的 SID 仅在我执行“添加应用程序池”过程的节点上创建。
我可以在第一个节点上打开计算机管理,并在 IIS_IUSRS 组中看到应用程序池标识。但是,在另一个节点上,此组为空。
这是 IIS 中的错误,还是我们的共享配置出了问题?
更新:IIS_IUSRS 组无关紧要。问题的表现是,我可以在某个节点上为应用程序池标识分配文件权限,但不能在另一个节点上分配。它类似于这个问题但是运行 IISRESET 并不能在第二个节点上修复它。
答案1
嗯...我要在这里滔滔不绝地谈论我的理解,你可以挑选你喜欢的部分。
S-1-5-82-{应用程序池名称的 SHA1} 将对所有存在应用程序池的机器通用,并具有相同的名称。共享配置将在所有机器上创建相同的应用程序池;应用程序池将为其创建相同的 SID。
但是这个 ApplicationPoolIdentity 通常不会在我熟悉的任何界面中显示为用户帐户。当然,它会出现在奇怪的权限列表中,但不会出现在组中或用户管理器中(或者我们现在想怎么称呼它)。
但其对应的 SID 仅在我执行“添加应用程序池”过程的节点上创建
你怎么知道的?团体成员的事情?我怀疑你的实际的问题是您没有描述的内容 - 您描述的问题听起来更像是其他问题的症状。组成员资格听起来像是某人所为 - 它不是共享配置的一部分,因此无法复制。
更进一步:通常不需要任何东西成为 IIS_IUSRS 的成员。只有当 manualGroupMembership 为真时,才需要将应用程序池帐户添加到此组。
所以声音就像有人在一台机器上手动将“IIS AppPool\YourAppPoolName”(注意间距)添加到 IIS_IUSRS 组,但在第二台机器上却没有这样做。
应用程序池标识永远不会显示为用户帐户(据我所知),并且通常在该组中不可见(因为 manualGroupMembership=false 是默认值,并且每个人通常都对此感到满意),并且该组中的成员身份不是共享配置可以给你带来一些东西。
因此,我可以想象,由于两个框上的应用程序池标识名称相同,因此 SID将要是相同的因为它是根据名称计算出来的值,并且您的问题可能不是您所想的那个(但猜测是在第二个框中,应用程序池 ID 没有添加到 IIS_IUSRS,并且有人将 manualGroupMembership = false)。
因此,将其视为任何其他本地用户帐户 - 因为它是 - 并将其添加到它需要成为成员的任何权限组 - 共享配置不会复制组成员身份(或任何其他框级属性),只是 IIS 配置。
答案2
问题出在用户配置文件服务上。共享配置在 IIS 节点之间同步应用程序池,并且工作正常。通常,用户配置文件服务负责在创建新应用程序池时创建与应用程序池标识相对应的用户帐户。在这种情况下,它失败了。
重新启动用户配置文件服务解决了该问题。现在,当本地或远程添加新的应用程序池时,它会创建用户帐户。