Skip to main content

MEMCM IIS Settings you may want for your Management Points and Distribution Points

Over the years we've uncovered various iis settings for our Management Points and Distribution Points, which we've found needed tweaking (for a company our size and complexity). Perhaps none of these settings will be relevant in your environment. If you have some issues with your clients' ability to communicate to IIS these settings may be a starting point for your troubleshooting or remediation of your MPs and DPs.

These are all Configuration Items.
1 Test and Remediation for any ManagementPoint role servers
4 Test and Remediation for any DistributionPoint role servers

Since I've been told that trying to import an exported .cab of these CIs often fails, I'm instead going to list out every setting and script inside, instead of trying to make it "easy" by offering a .cab for import.

You'll want to make all of these CIs "Application" Type CIs. That is so that you can add all 5 rules to a baseline, and target the baseline to a collection of "all your CM Servers", without having to break up and maintain collections for "these are the MP server", and "these are the DP servers". Let the CI do the "should I bother" check, using the application detection logic.


Management Point ones--you only want your servers with the MEMCM Management Point role to deserve this CI. This is what I currently have as the application detection logic:


<#
.SYNOPSIS
This is to check if the server has a MP role
#>

Param (
$VerbosePreference = 'SilentlyContinue',
$ErrorActionPreference = 'SilentlyContinue'
)
$Value = (get-itemproperty 'HKLM:\software\Microsoft\sms\mp' | Select IISPortsList).IISPortsList
if (-not ([string]::IsNullOrEmpty($Value))) {
write-host $Value
}

Distribution Point Ones--you only want your servers with the MEMCM DP role and IIS to deserve these 4 CIs. This is what I currently have as the application detection logic for the 4 CIs for the DP ones:

 


<#
.SYNOPSIS
This is to check if the server has a DP role
#>

Param (
$VerbosePreference = 'SilentlyContinue',
$ErrorActionPreference = 'SilentlyContinue',
$WebServerInstalled = (Get-WindowsFeature -Name Web-Server).InstallState
)
$Value = (get-itemproperty 'HKLM:\software\Microsoft\sms\dp' | Select ContentLibraryPath).ContentLibraryPath
if (-not ([string]::IsNullOrEmpty($Value)) -and ($WebServerInstalled -eq 'Installed')) {
write-host $Value
}


For each individual CI...
The single Management Point role CI is this:

  1. applicationPoolDefaults queueLength should be 4000
    Script, Integer
    Why is this needed? IIS default out of the box is 1000. MEMCM supports 4000. the reason you want the max is if you have a lot of clients (more than 1000) all trying to communicate to the server, the machines over 1000 may get communication failures. This can result in clients not able to download policy, nor able to transmit information to the Management Point.
    1. Discovery Script:
      import-Module webadministration
      (Get-WebConfiguration /system.applicationHost/applicationPools/applicationPoolDefaults).queueLength
    2. Remediation Script
      import-Module webadministration
      Set-WebConfigurationProperty /system.applicationHost/applicationPools/applicationPoolDefaults -Name queueLength -value 4000
    3. Compliance Rule is that this will be an Integer of 4000
      1. Make sure you check that box about 'Run the specified remediation script when this setting is noncompliant' (if you forget, then even if you deploy the baseline w/remediation, it still won't remediate)

So... that was the easy one; just the MP role one; to allow for more clients to chat. Distribution Point IIS settings; we've had to tweak multiple things over the years. The following 4 things are for your DP Role Servers.  The next 4 CIs would be ones you create using "application detection logic" of a DP role (mentioned above)

  1. applicationPoolDefaults queueLength should be 4000
    Script, Integer
    Why is this needed? IIS default out of the box is 1000. MEMCM supports 4000. the reason you want the max is if you have a lot of clients (more than 1000) all trying to communicate to the server, the machines over 1000 may get communication failures. This can result in clients not able to download content.
    1. Discovery Script:
      import-Module webadministration
      (Get-WebConfiguration /system.applicationHost/applicationPools/applicationPoolDefaults).queueLength
    2. Remediation Script
      import-Module webadministration
      Set-WebConfigurationProperty /system.applicationHost/applicationPools/applicationPoolDefaults -Name queueLength -value 4000
    3. Compliance Rule is that this will be an Integer of 4000
      1. Make sure you check that box about 'Run the specified remediation script when this setting is noncompliant' (if you forget, then even if you deploy the baseline w/remediation, it still won't remediate)
  2. SMS Distribution Points Pool appConcurrentRequestLimit should be 65535
    Script, Integer
    Why is this needed? If it's not max allowed, what could happen is 503.2 IIS errors on the Distribution Points, this alleviates those errors.
    1. Discovery Script
      <#
      .SYNOPSIS
      Query applicationHost.config, <configuration> , <system.webServer>,
      change <serverRuntime /> for appConcurrentRequestLimit
      .DESCRIPTION
      Query applicationhost.config, <configuration> <system.webServer>, <serverRuntime />
      .NOTES
      Why: Part of alleviate the 503.2 IIS errors on the Management Points
      2019-12-05 Sherry Kissinger
      .EXAMPLES
      #>
      $VerbosePreference = 'SilentlyContinue'
      $ErrorActionPreference = 'SilentlyContinue'
      Import-Module WebAdministration
      (Get-WebConfigurationProperty -pspath 'MACHINE/WEBROOT/APPHOST' -filter "system.webServer/serverRuntime" -name "appConcurrentRequestLimit").Value
    2. Remediation Script
      <#
      .SYNOPSIS
      Edit applicationHost.config, <configuration> , <system.webServer>,
      change <serverRuntime />
      to <serverRuntime appConcurrentRequestLimit="65535" />
      .DESCRIPTION
      Modify applicationhost.config, <configuration> <system.webServer>, <serverRuntime />
      .NOTES
      Why: alleviate the 503.2 IIS errors on the Management Points
      2019-12-05 Sherry Kissinger
      .EXAMPLES
      #>
      $VerbosePreference = 'SilentlyContinue'
      $ErrorActionPreference = 'SilentlyContinue'
      Import-Module WebAdministration
      Set-WebConfigurationProperty -pspath 'MACHINE/WEBROOT/APPHOST' -filter "system.webServer/serverRuntime" -name "appConcurrentRequestLimit" -value 65535
    3. what means compliant: 65535
      1. Make sure you check that box about 'Run the specified remediation script when this setting is noncompliant' (if you forget, then even if you deploy the baseline w/remediation, it still won't remediate)
  3. SMS Distribution Points Pool RapidFail Should be Disabled
    Script, String
    why is this needed? iis defaults to Stopping (and not restarting) Application Pools if "too many" errors are encountered. Well, in an environment our size... we get errors all the time. We'd rather client keep trying to communicate, even if it generates iiserrors. We certainly don't want the application pools to stop.
    1. Discovery Script
      $VerbosePreference = 'SilentlyContinue'
      $ErrorActionPreference = 'SilentlyContinue'
      import-Module webadministration
      (get-itemproperty 'IIS:\AppPools\SMS Distribution Points Pool' -name failure.rapidFailProtection).Value
    2. Remediation Script
      $VerbosePreference = 'SilentlyContinue'
      $ErrorActionPreference = 'SilentlyContinue'
      import-Module webadministration
      set-Itemproperty 'IIS:\AppPools\SMS Distribution Points Pool' -name failure.rapidFailProtection False
    3. what means compliant, the returned value = False
      1. Make sure you check that box about 'Run the specified remediation script when this setting is noncompliant' (if you forget, then even if you deploy the baseline w/remediation, it still won't remediate)
  4. SMS Distribution Points No FileExtensionFilters
    Script, Integer
    why is this needed? by default, IIS will filter some file extensions. For us, occasionally files within content attempting to be downloaded would include files with those exact extensions, like a .mdb or .vb or .config, etc. etc. This would result in the client claiming "hash mismatch", because quite correctly IIS had a Request Filtering rule denying the ability to download a file from IIS ending in .mdb / .vb / whatever. But... we *DO* need the ability for files of that type to be downloaded into cache; if that is what is in the source files for an application, that is what we need to support. This will remove all fileextension filters, if there is a DP role.
    1. Discovery Script
      $VerbosePreference = 'SilentlyContinue'
      $ErrorActionPreference = 'SilentlyContinue'
      import-Module webadministration
      $CountFileExtensionFilters = (Get-WebConfigurationProperty -Filter 'System.WebServer/Security/requestFiltering/fileExtensions' -PSPath 'IIS:\Sites\Default Web Site' -Name 'Collection' | Measure-Object).Count
      Write-Host $CountFileExtensionFilters
    2. Remediation Script
      $VerbosePreference = 'SilentlyContinue'
      $ErrorActionPreference = 'SilentlyContinue'
      import-Module webadministration
      Remove-WebConfigurationProperty -Filter 'System.WebServer/Security/requestFiltering/fileExtensions' -PSPath 'IIS:\Sites\Default Web Site' -Name 'Collection'
    3. what means compliant, equals  0
      1. Make sure you check that box about 'Run the specified remediation script when this setting is noncompliant' (if you forget, then even if you deploy the baseline w/remediation, it still won't remediate)

 

Then of course.. TEST TEST TEST.

Add these 5 new CIs to a Baseline, and deploy to a single server with one of the roles; and see "what would happen if...".  If you are satisfied it might be helpful, you can then delete the deployment, and redeploy "with remediation", and test again.

 

CMCB

  • Created on .