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.
Permalink
Also discussed here: https://learn.microsoft.com/en-us/answers/questions/1228993/recent-sp-security-update-causes-iis-to-throw-a-50
Permalink
The issue in this conversation is for a different issue only affecting SP2016 on Windows Server 2012 R2:
https://blog.stefan-gossner.com/2023/06/13/resolved-trending-issue-503-response-on-sp2016-servers-running-on-windows-server-2012-r2-after-installing-april-2023-cu/
Was resolved with June 2023 CU for SP2016:
https://blog.stefan-gossner.com/2023/06/13/resolved-trending-issue-503-response-on-sp2016-servers-running-on-windows-server-2012-r2-after-installing-april-2023-cu/
Permalink
Then the problem here has the same “symptoms” as the problem discussed on the MS website? I was able to solve a similar problem on my SP farm using the blog post mentioned there: https://blog.kenaro.com/2023/09/18/internal-server-error-on-sharepoint-server-2019-o-premises-after-update/ – Maybe they are just different problems with the same effect.
Permalink
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?
Permalink
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!”
}
Permalink
… this is a copy of the script from the blog post mentioned….
Permalink
the same issue happened with me for SharePoint SE after November update,
Permalink
Hi Abdullah,
thats correct. A fix is currently scheduled for December 2023 CU.
Cheers,
Stefan
Permalink
This has happened yet again during Dec CU patching on our 2019 Production farm.
Permalink
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
Permalink
Hi Stefan,
will January CU 2024 fix this issue?
Best regars, Michael
Permalink
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
Permalink
I ran into this issue on a Windows 2019 server installing SP2016 with the Sept 2023 patch.
Permalink
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?
Permalink
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
Permalink
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.
Permalink
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.
Permalink
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
Permalink
Ok, thank you for information
Permalink
We just ran into this issue after applying the January update, though it only occurred on one of our SP web servers.
Permalink
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.