To enhance security of SharePoint Server, three new security features are being introduced in September 2025 CU. These enhancements apply to all supported SharePoint versions — 2016, 2019, and Subscription Edition — and I’d like to highlight them in this article:
- Machine Key Rotation Timer job
- AMSI enabled for all web applications
- Test-DefenderAndAmsiWorkProperly Cmdlet to validate AMSI configuration
Machine Key Rotation Timer job
First introduced in the SharePoint Server Subscription Edition 25H1 feature update a new SharePoint timer job was added to the platform.
With the September 2025 CU, this feature is now also available in SharePoint Server 2016 and 2019!
By default, the timer job is scheduled to run weekly on Sundays at 12:00 AM:
AMSI enabled for all web applications
In the past an administrator had to actively enable AMSI for SharePoint Web Applications. With September 2025 CU this feature will automatically be enabled for all Web Applications.
Trying to disable the AMSI feature will result in the following message:
If AMSI is not working properly ensure to verify the configuration based on these articles and the PowerShell Cmdlet introduced in the next section:
- Clarifying common questions around AMSI in SharePoint
- Trending Issue: Module “SPRequestFilterModule” could not be found after September/October 2023 CU
Test-DefenderAndAmsiWorkProperly Cmdlet to validate AMSI configuration
It is often not trivial to verify if AMSI is working correctly. In articles like Clarifying common questions around AMSI in SharePoint I have described steps that can be used to verify the OS and SharePoint AMSI functionality.
In September 2025 CU, a new PowerShell Cmdlet, Test-DefenderAndAmsiWorkProperly, was introduced. This Cmdlet verifies the configuration of Windows Defender and SharePoint AMSI.
It performs both a Windows Defender health check and a SharePoint AMSI health check.
Below is a sample output where the Cmdlet identified a misconfiguration in a web application within one of my test farms:
Permalink
Hi Stefan,
I have a couple of questions about the new Test-DefenderAndAmsiWorkProperly command. I use Trellix in lieu of Defender. Is there any value for running this command when a Defender-alternate is used? Also, is the “SP” prefix left out from the naming convention by design? (so not Test-SPDefenderAndAmsiWorkProperly)
Thanks,
Permalink
Hi SL,
the SharePoint specific checks can be helpful of course.
3rd party specific checks are not performed by the command.
I do not have an environment to check how the output looks like when using 3rd party AV solutions.
Would be great if you could share it with me after you executed it. 🙂
About the naming: I don’t have insights here but my guess is that the lack of “SP” is due to the fact that there is no SharePoint Defender (SPDefender…)
Cheers,
Stefan
Permalink
Okay, I’ll let you know how it goes with Trellix.
Understood about the naming convention. Looks like it would have been more fitting with an “Test-SPAmsi” prefix. e.g. Test-SPAmsiWithDefender
By the way, when the vulnerability broke out in July, enabling the AMSI feature immediately gave the 500 error in our environment. So with this CU, it looks like there’s no way to keep it disabled. I’ll let you know on this one as well 🙂
Thanks,
Permalink
Hi SL,
if your solution was to disable AMSI rather than fixing the underlying issue then yes – chances are high that you will get the 500 server error again.
Cheers,
Stefan
Permalink
One issue we had with AMSI and 500 was due to IIS missing SPRequestFilterModule:
$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()
https://blog.stefan-gossner.com/2023/10/17/trending-issue-module-sprequestfiltermodule-could-not-be-found-after-september-october-2023-cu/
Permalink
Is there any supported way to defer the AMSI feature temporarely? We’ve observed performance issues when we tried to use the feature in the past and would like to be able to quickly turn the feature off/on if that happens again.
Permalink
Hi René,
support can in context of a support case assist you with this and help to disable it while the underlying issue is being worked on.
Cheers,
Stefan
Permalink
After installing this CU, and executing the Machine Key Rotation Job on Sunday, we began encountering errors related to machine key validation. A typical error message can be found in the ULS, is as follows: “System.Web.HttpException (0x80004005): Validation of viewstate MAC failed. If this application is hosted in a Web Farm or cluster, ensure that the configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster.” We have verified that all web.config files across the farm contain identical machine key values. However, it appears that running the Machine Key Rotation Job does not update the web.config files, even though event logs indicate that changes are being made in the configuration database. Additionally, we can see that Update-SPMachineKey -WebApplication https://site -Local is updating web.config file, but machine key is not changed.
Best,
Adrian
Permalink
Hi Adrian,
in this case I would recommend to open a support case with Microsoft to get this investigated.
Feel free to drop me the SR number using “Contact the blog author” in the upper right of this page.
If I have bandwidth I will take ownership of your case.
Cheers,
Stefan
Permalink
Forgot to mentioned that it is SP2016
Permalink
On single server test farm, the job didn’t run on Sunday automatically, and once I pushed it manually, web.configs weren’t updated. But, Get-SPWebApplication | Set-SPMachineKey worked immediately.
Permalink
Hi,
I can echo that there are problems with this job – I have installed latest 2019 CU to several our pre-prod farms and see that job actually does not change machine keys at all. On multiple-server farms it gives following error:
SPDatabaseServiceInstance.OnDeserialization(): could not set encrypted password in the secured password location. System.UnauthorizedAccessException: Access to the path
While on single-server/development machines does not give ULS error, but still does not rotate key.
I guess this is another trending issue ‘yet to be discovered’ 🙂
Permalink
Hi Giedrius,
thanks for the info!
let me see if I get a repro in a multi server farm.
Cheers,
Stefan
Permalink
Hello Stefan,
Maybe had chance to test it out? We really see weird issues related to rotation of MachineKey job and multiple errors on ULS. I think I soon will raise case in regard to this.
Thanks you
Permalink
Hi Giedrius,
yes – I have identified the issue and already created a hotfix request for this.
Workaround is to disable the machine key rotation job for now and – if required – use Set-SPMachineKey as a workaround.
If you are opening a case, please send me the SR number via the contact the blog author at the top right of this page.
Cheers,
Stefan
Permalink
Hi Stefan!
I have just installed September 2025 CU on a single-server SPSE farm. Tried running the
Test-DefenderAndAmsiWorkProperly
cmdlet and got the following output:
“PS C:\WINDOWS\system32> Test-DefenderAndAmsiWorkProperly
Note: This check is performed on the current server only.
===== Windows Defender Health Check =====
— Core Defender Status —
Defender Core Services: Enabled and Running [OK]
— Component States —
Script Scanning: Enabled [OK]
Network Protection: Enabled [OK]
Behavior Monitoring: Enabled [OK]
IOAV Protection: Enabled [OK]
Cloud Protection: Enabled [OK]
Tamper Protection: DISABLED [X]
Real-Time Protection: Enabled [OK]
— MSDefender – AMSI (Antimalware Scan Interface) —
AMSI Script Scanning: Enabled [OK]
AMSI DLL Present: Yes [OK]
— Service Status —
WinDefend Service (Microsoft Defender Antivirus): Running [OK]
===== Windows Defender Health Check Complete=====
===== AMSI (Anti-Malware Scan Interface) Health Check =====
— AMSI Feature Status —
AMSI Feature: Enabled all web applications [OK]
— AMSI Web Config Status —
AMSI Web Config: All web applications configured [OK]
— AMSI Scanning Status —
AMSI Scanner: Working properly [OK]
— Using HTTP header to test AMSI integration —
AMSI HTTP Header Test: Failed [X]
===== AMSI (Anti-Malware Scan Interface) Health Check Complete=====
===== Overall Security Status =====
Security Check Summary: One or more issues detected [X]
PS C:\WINDOWS\system32> ”
However all tests described in your article “Clarifying common questions around AMSI in SharePoint” run with success.
Please advise how to interpret the output and how to fix each of the detected issues.
Permalink
Hi Yuriy,
Tamper Protection is not enabled. But this is not relevant for AMSI.
See here for details on Tamper Protection:
https://learn.microsoft.com/en-us/defender-endpoint/prevent-changes-to-security-settings-with-tamper-protection
More concerning is the message that the AMSI HTTP Header Test failed.
My suggestion would be to open a ticket with Microsoft Support to investigate this.
Cheers,
Stefan
Permalink
Yes, that message
“AMSI HTTP Header Test: Failed [X]”
is of greater concern to me as well.
Of course going to raise a case with MS, however my point from the start is that there is no documentation\hints\information on how to interpret the cmdlet output and what it actually does under the hood.
The -Verbose parameter does not help much.
Specifically with the “AMSI HTTP Header Test” – does it test plain HTTP only, or HTTPS as well? How it performs the test(s), what are those test(s), how many are they, etc.?
This new cmdlet is much of a black box for now. How and where could the community get more info and explanation about it’s inner workings, output meanings etc.?