Question

我有一台安装了WSUS的Windows 2008 x64服务器，因此破坏了使用32位应用程序池的网站。此问题是由于IIS的applicationHost.config文件中的压缩方案的定义。我们通过复制32位版本的suscomp.dll以相当脏的方式解决了这个问题，但我确信必须有更好的方法！

我可以在IIS7 GUI中以另一种方式解决它，如下所示：

在Web服务器级别，解锁'modules'下的StaticCompressionModule和DynamicCompressionModule条目。
在我的网站级别，删除这些模块。

足够简单 - 只有两个步骤，必须是可编写脚本的，当然？我可以使用appcmd执行第二部分，如下所示：

appcmd delete module "DynamicCompressionModule" /app.name:"Default Web Site/mysite"

但是，如果我尝试在没有第1步的情况下执行此操作，那只会给我一个锁定违规。问题是，我不能在我的生活中找出如何使用Powershell或在Powershell中解锁Web服务器级别的单个模块APPCMD。当然这有可能吗？

其他人遇到过这个并且有任何小块可以分享吗？

谢谢，人

Answer 1

我从来没有这样做但是试一试（首先在测试环境中运行）

Import-Module WebAdministration

# at the web server level, unlock the StaticCompressionModule 
# and DynamicCompressionModule entries under 'modules'.
Set-WebConfigurationProperty //modules -Name Collection -Value @{name='StaticCompressionModule';lockItem='false'} -PSPath IIS:\
Set-WebConfigurationProperty //modules -Name Collection -Value @{name='DynamicCompressionModule';lockItem='false'} -PSPath IIS:\

# at my web site level, delete these modules
Disable-WebGlobalModule -PSPath 'IIS:\Sites\Default Web Site' -Name DynamicCompressionModule

Answer 2

我认为原始问题已经解决了，但是因为我在尝试通过搜索解决类似问题时遇到了这个问题，这个答案可能会帮助其他人。基本上问题是，即使解锁modules部分并将其复制到允许覆盖的<location>，所有本机模块（至少在IIS 8中）都有lockItem="true"放在他们身上。

如果您使用appcmd.exe删除然后在APPROOT lockItem重新创建本机模块条目将消失。用于实现StaticCompressionModule的命令，例如：

appcmd set config -section:system.webServer/modules /-[name='StaticCompressionModule']
appcmd set config -section:system.webServer/modules /+[name='StaticCompressionModule']

请注意，这适用于本机模块，因为name是除lockItem之外的唯一属性（无type或preCondition）。在我的情况下，我希望能够<clear />所有默认handlers和modules，并且只添加我基于模块的应用程序所需的内容：

@echo off
setlocal
set iis=%SystemRoot%\System32\inetsrv\appcmd.exe
set iisx=%iis% /commit:apphost
set ws=config -section:system.webServer
%iisx% unlock %ws%/handlers
%iisx% unlock %ws%/modules
for /f "tokens=3 delims== " %%a in ('%iis% list %ws%/modules ^| find /v "type=" ^| find "add"') do %iisx% set %ws%/modules /-[name='%%~a'] && %iisx% set %ws%/modules /+[name='%%~a']
endlocal

批处理文件中的假设是<add>下的所有modules元素都有一个type且未被锁定或未被锁定，被锁定且只有{{1}这很重要。如果有人试图与我在网络应用程序中做类似的事情，我会尝试在http://christophercrooker.com上发布博客。

Answer 3

以下是IIS7上的托管模块和本机模块的实际工作原理（也适用于IIS 10）以及如何检查它们是否已解锁。我存储了一个我要解锁的模块名称数组，这些模块名称将通过每个检查进行循环。

#need IIS module
Import-Module WebAdministration

#checking to see if module is locked, same for managed and native    
foreach($module in $modules)
{    
    $lock = Get-WebConfigurationLock -Filter "system.webServer/modules/add[@name='$module']" -PSPath IIS:\
    $isLocked = $lock -neq $null
}


#unlocking is different between managed and native modules, so I have a function to check what type the module is
function Is-ManagedModule([string]$ModuleName) {
    $Precondition = Get-WebConfigurationProperty -filter //modules -Name Collection[name="$ModuleName"] -PSPath IIS:\ | Select -ExpandProperty Precondition
    return $Precondition -eq "managedHandler"
}

#and then actually doing the unlock
foreach ($module in $modules)
{
    if (Is-ManagedModule $module)
    {
        #Unlocks managed modules
        Set-WebConfigurationProperty -Filter //modules -Name Collection -Value @{name="$module";lockItem='false'} -PSPath IIS:\
    }
    else
    {
        #Unlocks native modules
        Remove-WebConfigurationLock -Filter "system.webServer/modules/add[@name='$module']" -PSPath IIS:\
    }
}

在脚本中删除IIS7中的模块

3 个答案: