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

问题描述

我正在更新我们的.NET 4.0和IIS 7.5安装程序之一，其中一项任务是将AppPool切换为使用自己的标识。我在使用IIS扩展的WiX中发现这相当微不足道，但是我正在努力处理我们定义的两组额外权限，特别是授予AppPool标识的写权限：

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">
    <!-- SourceDir\logs -->
    <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 APPOOL\AppPoolName 无效身份和安装失败。如何将应用程序池标识指定给权限元素，以便Web应用程序可以写入日志目录？我需要使用不同的身份吗？

When I run the installer, I get a 1609 error stating that IIS APPOOL\AppPoolName 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?

推荐答案

这是一个有趣的问题。

当您创作权限元素时，会产生记录（ s） 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:

• 用 PermissionEx 元素（ WiXUtilExtension 中的元素）。它涵盖了权限的功能，并且增加了更多的灵活性（例如，不覆盖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屋！