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.
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:
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.
To fix the issue ensure that the green line above is listed in the globalModules section of the applicationHost.config.
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.