PowerShell IIS Set-WebConfigurationProperty — заблокированный раздел ApplicationHost.config

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

Мой код выглядит так:

# >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
# >>>>>> Path credentials
# >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

# Set the physical path credentials of the web application (on Basic Settings screen) to Connect As...
$filter="/system.applicationHost/sites/site[@name='{0}' and    @id='1']/application[@path='/{1}']/VirtualDirectory[@path='/']" -f $script:WebSiteName,$appName
Set-WebConfiguration $filter -Value @{userName="$physicalPathCredentialUserID";password="$physicalPathCredentialPassword"}

При выполнении я получаю сообщение об ошибке в PowerShell: «Этот раздел конфигурации нельзя использовать по этому пути. Это происходит, когда раздел заблокирован на родительском уровне». Я попробовал теги PSPath и location, которые работают, когда разделы аутентификации заблокированы, но, похоже, они не имеют никакого эффекта. Я думал, что, возможно, опция -Force сработает, но, хотя ошибок не было, учетные данные физического пути, похоже, не принимались.

Без параметра -Force возникает ошибка, но PowerShell обрезает сообщение, поэтому я не могу точно сказать, на какой раздел он жалуется или какой родительский уровень заблокирован. Я должен предположить, что это раздел «Сайты», так как я пытаюсь настроить: /configuration/system.applicationHost/sites/application/virtualDirectory

Я немного запутался в разнице между разблокировкой и разрешением переопределения, чтобы сохранить значения. PowerShell WebAdministration довольно запутан в этой области. Я не знаю, почему это должно быть так запутанно, чтобы установить значения, которые являются следствием того, что можно установить в пользовательском интерфейсе администрирования IIS. Некоторые значения используют Set-WebConfiguration с уродливой строкой, как показано выше, другие используют Set-WebConfigurationProperty. Если блокировка является известной проблемой, почему разблокировка не документирована лучше?

Я не хочу разблокировать все сайты или все приложения. Я просто хочу разблокировать то, что мне нужно, чтобы установить значения конфигурации для каждого веб-приложения, которое я устанавливаю на веб-сайте по умолчанию.

Каково окончательное решение для разблокировки или переопределения разделов конфигурации в версии 2014 и PowerShell 3.0? И какие настройки принимают PSPath и местоположение?

Кстати, я пробовал варианты следующего:

$filter="/system.applicationHost/sites/site[@name='{0}' and    @id='1']/application[@path='/{1}']/VirtualDirectory[@path='/']" -f $script:WebSiteName,$appName
Set-WebConfiguration $filter machine/webroot/appHost -metadata overrideMode -value Allow

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

Я также попытался установить virtualDirectoryDefaults.userName и virtualDirectoryDefaults.password, которые изначально не использовались, но после IISReset я заметил, что они действительно были добавлены в конец файла applicationHost.config. Я действительно не хочу, чтобы они устанавливались по умолчанию, потому что наши приложения не должны влиять на другие приложения на сервере.

Я ценю любую помощь, которую вы можете предоставить. Я должен что-то упустить, потому что установить эти и другие значения конфигурации веб-приложения не должно быть так сложно.

С уважением


credentials configuration powershell iis locked
person Scott    schedule 29.10.2014    source источник

Ответы (2)


arrow_upward
2
arrow_downward

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

См.: Программная разблокировка разделов конфигурации IIS в Powershell

person briantist    schedule 29.10.2014
comment
Это кажется довольно грубым подходом. Мне действительно нужно выйти из модуля WebAdministration и загрузить ServerManager? Я не могу поверить, что люди, которые написали WebAdministration для PowerShell, не предусмотрели необходимость разблокировать настройки приложения. - person Scott; 30.10.2014
comment
Ну, это не ServerManager, как в модуле для работы с ролями и функциями, это часть элементов управления .net WebAdministration. Тем не менее, этот пост довольно старый. Может быть, есть лучший способ, но я не знаю ни одного, изначально. Если вы хотите использовать сторонний продукт, Carbon, кажется, поместил это в хороший аккуратный командлет (я никогда его не использовал): get-carbon.org/help/Unlock-IisConfigurationSection.html - person briantist; 30.10.2014

arrow_upward
0
arrow_downward

Ваш фильтр выглядит неправильно. Вы можете думать о фильтре как о запросе XPath. Поэтому, если вы используете фильтр //authentication/*, тогда вся ваша конфигурация будет находиться под узлом аутентификации. Это не совсем то же самое, что и XPath, но довольно близко. Просто помните, что вы не можете выбирать разделы метаданных, такие как теги sectionGroup или location, используя только параметр Filter.

У меня была проблема, когда мне нужно было разблокировать аутентификацию Windows на уровне сервера, чтобы я мог установить аутентификацию Windows на разные значения на уровне приложения. Поэтому мне пришлось сделать что-то вроде этого:

Set-WebConfiguration -Metadata OverrideMode -Value Allow -Filter //windowsAuthentication
Set-WebConfigurationProperty -PSPath IIS:\Sites\$WebsiteName\$AppName -Filter //windowsAuthentication -Name Enabled -Value $true

Это привело к созданию раздела в файле applicationHost.config, который выглядел следующим образом:

<location path="" overrideMode="Allow">
        <system.webServer>
            <security>
                <authentication>
                    <windowsAuthentication>
                    </windowsAuthentication>
                </authentication>
            </security>
        </system.webServer>
</location>

Я полагаю, что любая конфигурация, которую вы разместите с этим тегом местоположения, будет считаться разблокированной в соответствии с IIS.

А вот что было добавлено в файл Web.config в самом веб-приложении:

<authentication>
    <windowsAuthentication enabled="true" />
</authentication>

Надеюсь, это поможет.

person arjabbar    schedule 27.09.2017