0

I have a Windows 2008 x64 server with WSUS installed and, thus, broken websites that use 32 bit app pools. This problem is due to the definition of a compression scheme within the applicationHost.config file for IIS. We have solved the problem for now in a rather dirty fashion by copying across a 32 bit version of suscomp.dll but I'm convinced there must be a better way!

I can solve it another way in the IIS7 GUI as follows:

  • at the web server level, unlock the StaticCompressionModule and DynamicCompressionModule entries under 'modules'.
  • at my web site level, delete these modules.

Simple enough - only two steps, gotta be scriptable, surely?? I can do the second part using appcmd as follows:

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

But that just gives me a Lock Violation if I try to do it without step 1. Problem is, I can't for the life of me figure out how to unlock the individual module at the web server level using either Powershell or appcmd. Surely this has got to be possible?

Anyone else come across this and have any nuggets to share?

Thanks, Al.

Al Henderson
  • 307
  • 1
  • 3
  • 11

3 Answers3

0

I've never did this but give this a try (run on a test environment first)

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
Shay Levy
  • 121,444
  • 32
  • 184
  • 206
  • Thanks for the commands above. However, the Set-WebConfigurationProperty commands don't appear to work. They don't error, but if I go to IIS manager I can see that the modules are still locked. If I run the Disable-WebGlobalModule command I get a lock violation. Would be *really* handy if it would give me some indication of what was locked! I've stayed away from this snap in before as I didn't think it worked from a 32 bit powershell prompt (which mine needs to do), looks like I might have been wrong.. – Al Henderson May 16 '12 at 09:26
  • I ran those on my Windows 7 machine, they seemed to be working. Sorry, I can't help much here. – Shay Levy May 16 '12 at 09:55
  • Your help is much appreciated, Shay. Annoyingly close.. :-) – Al Henderson May 16 '12 at 10:16
  • This looks like it should work but it doesn't :( Anyone found something else for scripting this? – Dan Dec 05 '17 at 03:56
0

I assume the original issue is already solved, but since I came across this while trying to solve a similar problem via searches maybe this answer will help someone else. Basically the problem is that even when you unlock the modules section and it is copied to a <location> where overrides are allowed, all of the native modules (at least in IIS 8) have lockItem="true" set on them.

If you use appcmd.exe to delete and then recreate the native module entries at the APPROOT lockItem will disappear. The commands to achieve that for the StaticCompressionModule, for example:

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

Note that this works for the native modules because name is the only property they have other than lockItem (no type or preCondition). In my case I wanted to be able to <clear /> all default handlers and modules and specifically add only what I need for my module based application:

@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

The assumption made in the batch file is that all <add> elements under modules have a type and are not locked or do not, are locked and only have a name that is important. In case anyone is trying to do similar to what I am with a web application, I will try to blog about it at http://christophercrooker.com.

0

Here is what actually works for both managed and native modules on IIS7 (works on IIS 10 too) and how to check if they are already unlocked. I store an array of module names I want to unlock that get looped through for each of these checks.

#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:\
    }
}
Dan
  • 1,101
  • 1
  • 9
  • 30