Как указать идентификатор AppPool в элементе разрешения WiX? - PullRequest
Новая
       47

Как указать идентификатор AppPool в элементе разрешения WiX?

3 голосов
/ 30 августа 2011

Я обновляю один из наших инсталляторов для .NET 4.0 и IIS 7.5, и одной из задач является переключение AppPool для использования его собственной идентичности.Я нашел это довольно тривиальным в WiX с использованием расширения IIS, но я борюсь с двумя дополнительными наборами разрешений, которые мы определяем, в частности, для предоставления разрешений на запись для идентификатора AppPool: 

<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 точно соответствует названию пула приложений).

Когда я запускаю установщик, я получаю сообщение об ошибке 1609 о том, что IIS APPOOL\AppPoolName не является действительным идентификатором, и установка завершается неудачно.Как указать идентификатор пула приложений для элемента Permission, чтобы веб-приложение могло выполнять запись в каталог журналов?Нужно ли использовать другую личность?

1 Ответ

7 голосов
/ 30 августа 2011

Это интересный вопрос.

Когда вы создаете элемент Permission , это приводит к записи (ям) таблицы MSI LockPermissions .Согласно MSDN записи в этой таблице обслуживаются действиями InstallFiles , CreateFolders и WriteRegistryValues ​​.Когда элемент CreateFolder является родительским, это, очевидно, действие CreateFolders.

Учетная запись безопасности, соответствующая ApplicationPoolIdentity, создается при создании соответствующего AppPool.Теперь действие ConfigureIIs планируется позже в последовательности, чем CreateFolders.Очевидно, что нет никакого смысла перемещать ConfigureIIs до CreateFolders.

Я не уверен, что это сработает, но я бы попробовал следующее:

  • Заменить разрешениеэлемент с элементом PermissionEx (элемент из WiXUtilExtension ).Он охватывает функциональность Permission, а также добавляет больше гибкости (например, не перезаписывает ACL, а добавляет).

  • Переместите действие SchedSecureObjects (которое отвечает за обработку содержимого PermissionEx) послеНастройте действие (отвечающее за IIS), если оно еще не выполнено.

Теперь, когда должны быть установлены разрешения, должна существовать соответствующая учетная запись безопасности.Возможно, вы также захотите поиграть с тем, как вы ссылаетесь на него, например, с или без доменной части.

...