如何在 WiX 权限元素中指定 AppPool 身份? [英] How to specify the AppPool Identity in a WiX Permission Element?

问题描述

我正在为 .NET 4.0 和 IIS 7.5 更新我们的安装程序之一，其中一项任务是切换 AppPool 以使用其自己的身份.我发现这在 WiX 中使用 IIS 扩展相当简单，但我正在努力处理我们定义的两组额外权限，特别是授予 AppPool Identity 写入权限:

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 in WiX using the IIS Extension, but I'm struggling with two extra sets of permissions that we define, specifically to grant write permissions to the AppPool Identity:

<Directory Id="LOGS_LOCATION" Name="logs">
    <!-- SourceDirlogs -->
    <Component Id="LogsFolder" Guid="{3A7C38C7-6604-4063-A425-D62427B21AEE}" KeyPath="yes" DiskId="1">
        <CreateFolder>
            <!-- SYSTEM account is automatically given access, but set other ACEs here to avoid Users having access -->
            <Permission User="Administrators" GenericAll="yes"/>
            <Permission User="[ASPNET_USER]" Domain="[ASPNET_DOMAIN]" GenericRead="yes" GenericWrite="yes" Read="yes" Delete="yes" DeleteChild="yes" Traverse="yes"/>
            <!-- IIS5: ASPNET, IIS6: NetworkService, IIS7: AppPool identity -->
        </CreateFolder>
    </Component>
</Directory>

ASPNET_USER 和 ASPNET_DOMAIN 分别定义为 AppPoolName 和 IIS APPPOOL(其中 AppPoolName 与应用程序池的名称完全匹配).

ASPNET_USER and ASPNET_DOMAIN are defined to be AppPoolName and IIS APPPOOL respectively (where AppPoolName exactly matches the name of the App Pool).

当我运行安装程序时，我收到一个 1609 错误，指出 IIS APPOOLAppPoolName 不是有效身份并且安装失败.如何将 App Pool Identity 指定给 Permission 元素，以便 Web 应用程序可以写入日志目录?我需要使用不同的身份吗?

When I run the installer, I get a 1609 error stating that IIS APPOOLAppPoolName is not a valid identity and the installation fails. How can I specify the App Pool Identity to the Permission element so that the web app can write to the logs directory? Do I need to use a different identity?

推荐答案

这是一个有趣的问题.

当您创作 Permission 元素时，它会生成记录) 的 LockPermissions MSI 表.根据 MSDN，此表中的记录由 InstallFiles 提供, CreateFolders 和 WriteRegistryValues 操作.当 CreateFolder 元素是父元素时，显然是 CreateFolders 动作.

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.

在创建相应的 AppPool 时，会创建与 ApplicationPoolIdentity 对应的安全帐户.现在，ConfigureIIs 操作按顺序安排在 CreateFolders 之后.在 CreateFolders 之前移动 ConfigureIIs 显然没有任何意义.

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:

• 将 Permission 元素替换为 PermissionEx 元素(来自 WiXUtilExtension).它涵盖了 Permission 的功能，并增加了更多的灵活性(例如，不覆盖 ACL，而是追加).

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

将 SchedSecureObjects 操作(负责处理 PermissionEx 内容的操作)移到 ConfigureIIs 操作(负责 IIS 操作的操作)之后.

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.

这篇关于如何在 WiX 权限元素中指定 AppPool 身份?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！