Trending Issue: Module “SPRequestFilterModule” could not be found after September/October 2023 CU

Since release of September 2023 CU we received a couple of support cases where all web applications stopped working with a 500 server error.
A similar problem related to problems coming from Antivirus Scanners was discussed in my previous article.

In a couple of cases we identified a second problem with similar symptoms but different cause.

This new issue also shows a HTTP 500 Error and is also related to the AMSI functionality – but in this case the problem is caused by a configuration problem in the applicationHost.config file of IIS.

Symptoms

The easiest way to spot this issue is by looking into the Modules configuration of the IIS website for the affected web application. Here you can see that the SPRequestFilterModule is not correctly registered as the Code column is empty:

The problem will also be revealed when using Failed Request Tracing in IIS:

Background Information

We have heard about assumptions that the module is incorrectly registered in the web.config as it does not have a path here:

<modules ...>
   ...
   <add name="SPRequestFilterModule" />
</modules ...>

Just to be clear: this line is fully correct and should not be changed!
If you look around you will notice other SharePoint modules in the same section which have a similar registration and work perfectly correct:

<modules ...>
   ...
      <add name="SPNativeRequestModule" preCondition="integratedMode" />
      <add name="SharePoint14Module" preCondition="integratedMode" />
   ...
</modules ...>

All these modules are registered in the applicationHost.config file as global modules which guarantees that they can be loaded by just specifying the name without having to specify the class and assembly in the web.config:

<globalModules>
   ...
   <add name="SharePoint14Module" image="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\isapi\owssvr.dll" preCondition="appPoolName=SharePoint Central Administration v4;SharePoint - 2002;SharePoint - 2001;SharePoint - 2000;SharePoint - 80;SharePoint - 2003;SharePoint - 2004" />
   <add name="SPNativeRequestModule" image="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\isapi\spnativerequestmodule.dll" />
   <add name="SPRequestFilterModule" image="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\isapi\sprequestfilteringmodule.dll" preCondition="integratedMode,bitness64" />
</globalModules>

Coming back to the support cases. The entry in the web.config for these cases is correct.
The problem is caused by a missing SPRequestFilterModule registration in the applicationHost.config.

Solution

To fix the issue ensure that the green line above is listed in the globalModules section of the applicationHost.config.

This can be achieved either by manually editing the applicationHost.config or by running the following PowerShell script:

$assembly = [System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
$amsiReceiver = $assembly.GetTypes() | ?{$_.Name -eq "AntimalwareScanFeatureReceiver"}
$amsiReceiver::EnsureGlobalConfiguration()
 
# Also run this line for 2019 and Subscription Edition
$amsiReceiver::ChangeGlobalConfiguration()

We discourage from fixing the issue by adding the path to the SPRequestFilterModule in the web.config as this is just a local fix for this given web application. When creating new web applications later or extending an existing one will result in the same issue as the web.config file generated by these operations expects the module to be globally registered. In addition, reprovisioning the web application later – e.g. by applying a CU which performs this step to update the web.config – might revert the manual changes in the web.config.

24 Comments


    1. Reply

  1. We activated AMSI in Sharepoint SE in June and also received the 500 error in September. The entry in the applicationHost.config file only existed on the server that hosts Central Administration. On the other servers, we registered the module in IIS as server-level native modules.
    https://blog.kenaro.com/2023/09/18/internal-server-error-on-sharepoint-server-2019-o-premises-after-update/

    Then the entry was present in the applicationHost.config, but not yet in the web.config of the WebApplications. Only after we did AMSI Disable-SPFeature -Identity 4cf046f3-38c7-495f-a7da-a1292d32e8e9 -Url http://url-to-webapp and then enable-SPfeature was also present. And everything was fine.
    Maybe a permissions issue with the Farm-Account?

    Reply

  2. Can be added in a scripted way as well:

    $fn = “$([environment]::GetEnvironmentVariable(“SystemRoot”))\system32\inetsrv\config\applicationhost.config”
    $l = [System.Collections.Generic.List[string]]::new( ([system.io.file]::ReadAllLines($fn)) )

    if( $null -eq ($l | ? { $_ -like “SPRequestFilterModule“} ) ) {
    Write-Host “SPRequestFilterModule not found…”

    if( (Test-Path "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\isapi\sprequestfilteringmodule.dll") ) {
    write-host "missing module found on disk!"

    . iisreset /stop

    $m = @()
    for( $i = 0; $i -lt $l.Count; $i++ ) {
    if( $l[$i].IndexOf("</globalModules>", [StringComparison]::OrdinalIgnoreCase) -ge 0) {
    $l.Insert($i, ' <add name="SPRequestFilterModule" image="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\isapi\sprequestfilteringmodule.dll" preCondition="bitness64" />')
    break
    }
    }

    [system.io.file]::WriteAllLines($fn, $l.ToArray())

    . iisreset /start
    } else {
    Write-Error "Missing module DLL not found on disk!"
    }

    } else {
    Write-Host “SPRequestFilterModule is already registered in IIS!”
    }

    Reply

    1. … this is a copy of the script from the blog post mentioned….

      Reply

  3. the same issue happened with me for SharePoint SE after November update,

    Reply

    1. Hi Abdullah,
      thats correct. A fix is currently scheduled for December 2023 CU.
      Cheers,
      Stefan

      Reply

      1. This has happened yet again during Dec CU patching on our 2019 Production farm.

        Reply

      2. DEC CU has not resolved the issue. I have ran into the 500 Server error on two 2019 SP farms just this week alone, and not until I have restored the line to the ApplicationHost.config file, then reran SP P&C has it resolved.
        My farm is also configure for HA, meaning I’m making use of zero downtime patching, which of course is’t working as expected, and is affecting the business
        Please ensure this is resolved in the Jan patch

        Reply

      3. Hi Stefan,
        will January CU 2024 fix this issue?
        Best regars, Michael

        Reply

        1. Hi Michael,
          we did not receive a case where a customer requested a fix for this issue.
          All cases I see were resolved using similar steps as mentioned in this article.
          Cheers,
          Stefan

          Reply

      4. Stefan, I encountered this issue in our newly built SharePoint Farm (SharePoint Server Subscription edition) where April 2024 patch is already installed. Still the new CU didn’t resolve the issue until we do it manually as per your suggested approach in this blog.

        Reply

  4. I ran into this issue on a Windows 2019 server installing SP2016 with the Sept 2023 patch.

    Reply

  5. Hi Stefan, after December CU I dont see SPRequestFilterModule module anymore in iis. Applicationhost.config still contains related dll. Is this correct? If not, what is correct way to add SPRequestFilterModule to IIS modules?

    Reply

    1. Hi Antti,
      a little bit more info would be important. Which Operating System version are you using? Did you enable or disable AMSI?
      With “IIS” I assume you mean the web.config. The entry is removed from the web.config as soon as the AMSI feature is disabled. And readded when it is enabled for the specific web application.
      For Windows Server versions older than Windows Server 2016 AMSI is not supported and the AMSI feature will automatically be disabled which also removes the entry from the web.config file.
      I hope this helps.
      Cheers,
      Stefan

      Reply

      1. Hi, operating system is Windows server 2019 Standard. And yes, I meant web.config with IIS: We disabled AMSI to exclude seacrh problem, since September or october update crawl will get stuck eventually after few runs. It did not help and we are still investigating. . And besides that AMSI gives error since customer policy does not allow windows real time protection in windows.

        Reply

        1. Also we have this error: “Search Component: Content2-efe5a169-6c0a-4d2b-ba6d-d928e39399a6 – A parser server worker (WorkerID=1) failed to restart and it’s being removed from the pool. The pool still have 8 worker(s) available” but I presume this consist the old office document version parsing in search.

          Reply

        2. Hi Antti,
          as ASMI is disabled it is expected that the entry has been removed from the web.config file.
          So everything seems to be correct.
          Cheers,
          Stefan

          Reply

  6. Ok, thank you for information

    Reply

  7. We just ran into this issue after applying the January update, though it only occurred on one of our SP web servers.

    Reply

  8. Hi Stefan!
    Got this issue on only one WFE server in the farm.
    New farm April 2024 CU SP 2019

    Thank you very much for the solution. spent hours to figure this out because not erros in ULS or application logs.
    Only Failed Trace requests helped.

    Reply

    1. Same here using the Feb 2024 CU. @StefanGoßner, any info on a MSFT fix for this?

      Reply

  9. Ran into this again with a new SP2019 server and the FEB 2024 CU

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.