Microsoft is aware of active attacks targeting on-premises SharePoint Server (2016, 2019, Subscription Edition) customers by exploiting vulnerabilities partially addressed by the July Security Update.
SharePoint Administrators are advised to check there SharePoint machines for a file named spinstall0.aspx in the
…\16\TEMPLATE\LAYOUTS directory. If this file exists the machines are most likely already affected.
Microsoft has released security updates on July 20th that fully protect customers using SharePoint Subscription Edition and SharePoint 2019 against the risks posed by CVE-2025-53770, and CVE-2025-53771. Customers should apply these updates immediately to ensure they’re protected.
Please read the following blog post from Microsoft Security Response Center for guidance and mitigation and monitor it for further updates:
These vulnerabilities apply to on-premises SharePoint Servers only. SharePoint Online in Microsoft 365 is not impacted.
Important Update: We have seen cases where customer machines were exploited, and the threat actor uploaded a file with a different name than SPINSTALL0.ASPX.
We observed a wide variety of names, such as SPINSTALL.ASPX, SPINSTALL1.ASPX, SPINSTALL2.ASPX, and even completely random names like JSNASDW1.ASPX.
Please check for files created in the last couple of days, rather than only looking for files named SPINSTALL0.ASPX, as mentioned earlier in this blog post.
If the SharePoint security fixes have already been installed, be aware that you may find several hundred recently created files (e.g. SP.JS, SP.Runtime.JS, AddGallery.xap). These files and others with identical timestamp are part of the security fix and should be excluded from your checks.
Additional guidance/clarification
Install Security fixes
Microsoft has released Security fixes for all supported versions of SharePoint including SharePoint Server 2016, SharePoint Server 2019 and SharePoint Server Subscription Edition.
The fixes for each SharePoint version are documented in CVE-2025-53770 and CVE-2025-53771.
- For SharePoint Server 2016 two fixes are required: KB5002760 and KB5002759
- For SharePoint Server 2019 two fixes are required: KB5002754 and KB5002753
- For SharePoint Server Subscription Edition only one single fix which contains both components: KB5002768
Common problems if only one of the two fixes are installed (SP2016, SP2019) are missing navigation menues and JavaScript errors.
The security fixes are cumulative updates. This means you can install them directly on SharePoint Server RTM or any later CU.
There is no need to install other SharePoint CUs before this fix is applied.
Ensure to run the SharePoint Configuration Wizard after installing the fixes.
If there are still issues with the navigation menu after applying the fixes, test if disabling side-by-side patching resolves the issue.
Activate AMSI
Activating AMSI is mandatory to protect the machine if the security fixes cannot be installed at this time.
Follow the instructions in this article to activate AMSI:
Important: AMSI is an Operating System feature which only exists in Windows Server 2016 and higher. It is not possible to use AMSI on Windows Server 2012 or Windows Server 2012 R2.
Important: AMSI requires an AV solution which supports it – e.g. Microsoft Defender for Endpoint Protection to be installed on the SharePoint machine.
To verify if AMSI works correctly and to answer other AMSI related questions please have a look at this blog post:
Rotate ASP.NET machine keys
Important: Rotating the machine keys AFTER the fix is installed is critical to protect the machines. It is NOT sufficient to install only the fixes!
Use the following PowerShell command to rotate the machine key for a Web Application:
Set-SPMachineKey -WebApplication https://url-to-web-application
This command has to be executed against all web applications (including the Central Administration Website).
If a web application has been extended the command has to be executed against all extended endpoints / IIS web sites of the web application.
This command should generate new random machine keys, apply them to the local machine and add them in the SharePoint configuration database. A timerjob will afterwards replicate the new machine keys to all other SharePoint servers in the farm.
Important: Verify that the machine keys got correctly replicated to all machines in the farm. The machine key for a given web application needs to be identical on all servers. Different web applications will usually have different machine keys. In the discussion below is a script which helps with this verification.
In case that some servers did NOT receive the new machine keys after a couple of minutes execute the following command on those machines:
Update-SPMachineKey -WebApplication https://url-to-web-application -Local
This command will retrieve the new machine keys from the Configuration Database and update the web.config file on the current machine associated with web application accordingly.
Restart IIS on all SharePoint Servers
After the new machine keys have been replicated to all servers for all web applications it is important to restart IIS.
Execute IISRESET on each of the frontend servers.
Permalink
there are any update about the release of SharePoint 2016 patch?
Thanks
Permalink
Not at this time.
Permalink
We are also waiting on this release!
Permalink
Hi Jose,
the SP2016 fix was just released. Check the CVE articles.
Cheers,
Stefan
Permalink
Hi Stefan,
is it recommended to rotate the machine key even the latest security update is installied or was that just needed at the time the new updates were not released?
Thanks
Steffi
Permalink
Yes absolutely. The exploit focused on stealing these keys. To be on the safe side ensure to rotate the keys after installing the fix.
Permalink
Hello Stefan Goßner,
Has this issue been introduced with latest patches (release on July 8th) or it is an older one? It is important information, because it would allow us to understand if we are affected by it.
Thanks
Permalink
Hi Giedrius,
no. This is not an issue that was recently introduced.
Cheers,
Stefan
Permalink
In case we are on SP2019 June CU – do we install the patch (KB5002754) directly or we need to install July CU before the KB5002754 ? Thanks
Permalink
Hi Jakub,
there is no need to install KB5002741 from July CU.
But you need to install KB5002739 from July CU.
Cheers,
Stefan
Permalink
I think you meant (KB5002754) ? ours latest is from may but installing this latest one should do right ?
Permalink
To be completely correct I meant KB5002754 + KB5002739
Permalink
Hi Stefan
When installing
– language pack KB5002739 (16.0.10417.20027)
– security update KB5002754 (16.0.10417.20037)
Does the order matter?
Can the two binaries be installed together before running psconfig?
Permalink
Hi Rene,
KB5002739 is no longer the correct one.
You need to install KB5002753 instead.
Sequence does not matter but SharePoint configuration wizard needs to be executed of course as always.
Cheers,
Stefan
Permalink
Hi Stefan,
After installing language pack KB5002739 (16.0.10417.20027) and security update KB5002754 (16.0.10417.20037), what build version should be visible in PowerShell or Config DB Version from Servers in Farm page on CA?
(Get-SPFarm).BuildVersion
Major Minor Build Revision
16 0 10417 20027
Is this correct?
Permalink
Hi Greg,
meanwhile KB5002753 has been released and should be installed on top or instead of KB5002739.
Cheers,
Stefan
Permalink
“SharePoint Administrators are advised to check there SharePoint machines for a file named spinstall0.aspx in the
…\16\TEMPLATE\LAYOUTS directory. If this file exists the machines are most likely already affected.”
What this means exactly? If the file is found the machine is vulnerable to this attack or the machine is already being attacked?
Permalink
spinstall0.aspx file is not a part of SharePoint. The presence of it is an Indicator of Compromise (IoC). Finding the file means the server has most likely already been breached
Permalink
Correct.
Permalink
If customer has been breached, whats the recommendation Stefan, is it not follow the recommended steps and delete that file?
Permalink
Hi Luis,
a malicious actor can execute Powershell scripts on the machine and it would be hard to identify what has been done (installing backdoors, other malware, …)
In general we recommend to reinstall compromised servers or revert to an older snapshot for virtual machines from before the machine got compromised.
Cheers,
Stefan
Permalink
Since we are on June CU, do we need to install July CU first for SP 2019? Or we can go straight with the KB5002754 installation?
Permalink
Same Question for the SPSE. Should we upgrade first to the July CU or can we go straight to KB5002768 / are we even affected as we are still on the June CU?
Permalink
You can go straight to KB5002768.
Permalink
Does the same goes for SharePoint Server 2016 if its on May 2025 CU?.. can directly go to July 2025 CU?
Permalink
Yes.
Permalink
You need to install the language dependent fix from July CU + the new security fix.
Permalink
I understand you first needs install July because there are some remeditations applied for the same vulnerabilities.,
Permalink
The security fix includes July CU
Permalink
We have applied the latest update for SP Server 2019 https://www.microsoft.com/en-us/download/details.aspx?id=108259. Do we need to also apply this Security Update https://www.microsoft.com/en-us/download/details.aspx?id=108286, is it different than the first published or are we covered? Should we also enable the Antimalware Scan Interface?
Permalink
Hi Georgia,
yes. The new fix is an out-of-band release to address the security vulnerability. July 2025 CU (which you already installed) does not include a complete fix for the issue.
Cheers,
Stefan
Permalink
Just installed the 2019 Update and did not encounter anything out of the ordinary.
Waiting for the 2016 patch to drop.
Thanks for the post! 👍
Permalink
Hi!
Regarding the guidance Defender should be used. Should this be obsolet after installing the seucrity update?
Permalink
Hi Rene,
it can help to identify if the machines were already compromised before the patch was installed.
Cheers,
Stefan
Permalink
Is SharePoint 2013 also affected by this vulnerability?
Permalink
Hi Robin,
SP2013 is out of support since several years.
It is vulnerable to a large number of security issue which were fixed for 2016, 2019 and SPSE.
Cheers,
Stefan
Permalink
Thanks Stefan. I am aware that it is out of support since a long time. However, due to the high criticality, it would be still interesting to know in order to take measures. Unfortunately, I could not find any official information regarding SP2013…
Permalink
Hi Robin,
we do not have official information related to this but as all supported OnPremises versions (2016, 2019 and SPSE) are affected personally I would assume that earlier versions are also affected.
Cheers,
Stefan
Permalink
Thanks!
Permalink
Since we are on June CU, cve-2025-53770 vulnerability impacts the June CU patched environment as well ?
Permalink
Yes.
Permalink
Any update on 2016 CU?
Permalink
Not yet.
Permalink
Hi Ram,
the SP2016 fix was just released. Check the CVE articles.
Cheers,
Stefan
Permalink
Hello Stefan,
Thanks for the info.
We have 2 SP platforms, one 16.0.16731.20180 and the second one 16.0.16130.20640
Do we need to upgrade to any specific CU before installing this critical update ? Or we can deploy the critical update straight ?
Permalink
Hi Mohammed,
no – you can directly apply the critical update.
Ensure to execute the SharePoint config wizard afterwards as usual.
Cheers,
Stefan
Permalink
Good news !
Thanks a lot for your feedback
Permalink
Hi,all!
Should we upgrade first to the July CU or can we go straight to KB5002768?
we are still on the MAY CU
Permalink
You can go directly to KB5002768.
Permalink
Hi Stefan,
I have SharePoint SE and installed KB5002768. Defender is also installed with real-time protection ON.
AMSI is activated on all my Web Applications but when I Navigate on the central admin > Security section > ‘AMSI Configuration’ I only have the ability to enable or disable it. The option recommended in the Guidance document to setup it as Full mode is simply not there. Do you know why?
Regards.
Pascal
Permalink
Hi Pascal,
did you run the SharePoint configuration wizard after applying the fix?
Cheers,
Stefan
Permalink
Yes. And I also rebooted the server. Strange there nothing indicating an error or a misconfiguration.
Permalink
Hm… strange.
Try PowerShell to configure it:
$webAppUrl = “http://spwfe”
$webApp = Get-SPWebApplication -Identity $webAppUrl
$webApp.AMSIBodyScanMode = 1 # 0 = Off, 1 = Balanced, 2 = Full
$webApp.Update() # To save changes
Permalink
In the “Customer Guidance…” Link it is stated to “Search for Machine Key Rotation Job and select Run Now.”
On my 2019 farm I do not have a job with such a name. Is this still required? Does it have a different name?
Permalink
Yes. Use the PowerShell option in this case.
Permalink
Thanks 🙂
Permalink
Hi, on SharePoint SE, we don’t have the Timer Job “Machine Key Rotation Job” too. I can force the creation when I manually run “(Get-SPFarm).TimerService.EnsureDefaultJobs()”. After that I can Run Now the Job, but in the ULS we see only “The flight MachineKeyRotation is off and the timer job is skipped”.
Permalink
Hi Hennrich,
Please use the documented PowerShell command instead.
Cheers,
Stefan
Permalink
Hi,
we did that, but Update-SPMachineKey does not generate new Keys, it just writes the current ones to the web.configs. Set-SPMachineKey (with no parameters) indeed does generate new Keys and writes it to the web.configs.
Regarding the timer job, if there a other customers that can see the timer job, but it will do nothing as in our case, they could not rely on that.
Both must be noted in the Customer guidance for the CVE – otherwise, no one can rely to be safe.
Please correct me if I’m wrong.
Regards
Permalink
The link in the Customer Guidance post reads “Update-SPMachineKey” but links to the article for “Set-SPMachineKey” at least 😉
Permalink
The PowerShell Machine Key Rotation command isn’t working for us yet; the key is not changing*.
We are working on it and will update when fixed. In case someone had the same problem and fixed it, please let us know.
We’ve stored the old key and attempted the rotation using Update-SPMachineKey -Local. The command asks for a web application (which it should not do when using the -Local switch). When providing the web application manually the Shell is idle (no result message, not an error, just waiting for next command). After an iisreset, the key in our web.config files remains unchanged
Permalink
Hi Emil, to generate a new machine key you need to use the Set-SPMachineKey command, Update-SPMachineKey will only replicate the current key but will not generate a new one.
Permalink
update-spmachinekey will always require a web application. -Local ensures that only the web application config on the current server is updated rather than in the whole farm.
Permalink
Hi Stefan,
Is it possible that the AMSI config screen doesn’t show up if you don’t use the Microsoft Defender for Endpoint protection but different virus/antimal software? We have the SharePoint Server Antimalware Scanning Active for all our WebApps but the AMSI Configuration in the security section is not there.
Permalink
Hi Sandra,
SharePoint does not know which Virus/AV solution is installed. It directly talks to the Operating System AMSI functionality where AV solutions integrate with.
So this is not related to the installed AV solution.
Cheers,
Stefan
Permalink
Hello Stefan,
could you give us the exact power shell command that is neccessary for the machine key rotation?
Thanks!
Regards,
Martina
Permalink
Hello Martina,
I used this command: Update-SPMachineKey -WebApplication
Best regards,
Laszlo
Permalink
Hi Laszlo, this command will not rotate the machine keys. Set-SPMachineKey does this.
Permalink
Hi Stefan,
thanks for clarifying this and also thank you for being so much supportive all these years 🙂
Best regards,
Laszlo
Permalink
Hi Martina,
to rotate the machine keys you need to run Set-SPMachineKey -WebApplication.
Update-SPMachineKey will NOT rotate the machine keys. It will just ensure that the current keys are applied on all servers in case there is an inconsistency.
Cheers,
Stefan
Permalink
Hello Stefan,
We need to run the command on all the SahrePoint servers or is it enough to run the command only on one if you don’t get any errors?
Thanks a lot !
Permalink
Hi Ciro,
if you do NOT add the -Local parameter the command will update the keys on all machines in the farm.
Cheers,
Stefan
Permalink
Hi Martina,
you need to run
Set-SPMachineKey -WebApplication http://….
this needs to be executed against all web applications.
Cheers,
Stefan
Permalink
Thanks Stefan, this is really helpful! Great support for us on-premises customers!
Regards,
Martina
Permalink
If your farm is on SharePoint Enterprise 2016 (16.0.5508.1000) are you still vulnerable?
Permalink
Hi Tom,
the answer is Yes. There is currently no fix available for SharePoint Server 2016.
Its important to apply all mitigation steps in the customer guidance.
Cheers,
Stefan
Permalink
I installed the patch this morning and now the quick launch has stopped working on the default sitepage on 2019. Has anyone else come across this ?
Permalink
Hi Karl,
I would recommend to open a support case for this to get this investigated.
Cheers,
Stefan
Permalink
Yes, I did. See below. I’m trying to reproduce this at the moment on my virtual environment.
Permalink
Hi Karl,
please install this fix and run the config wizard to resolve the issue:
https://www.microsoft.com/en-us/download/details.aspx?id=108287
Cheers,
Stefan
Permalink
Do we need to install the July CU and KB5002768?
Permalink
No. KB5002768 includes July CU.
Permalink
Hi, does anyone face the issue that on SP2019 modern sites the left sidebar is missing after installing the patches? I found this issue this on two farms now after restarting the machine…
Permalink
Hi Stefan,
did you install also the language dependent fix from July 2025 CU and did you run the SharePoint configuration wizard after installing the security fix?
If you I would suggest to open a support ticket to ensure that this can be investigated.
Cheers,
Stefan
Permalink
Yes, I did.
Permalink
I have the same issue. The ribbon buttons and the left menu are missing.
Any suggestions how to solve that?
Permalink
Hi Malu,
please open a ticket to ensure that this being tracked and investigated.
Cheers,
Stefan
Permalink
Hi Stefan,
We and our clients are facing the same issue. SP2019 in modern mode misses left menu + command bar after KB5002754 instalation.
Is it currently investigated? Can we expect another path soon?
Permalink
Hi Bartek,
yes, I have seen a support case about this topic.
Cheers,
Stefan
Permalink
Thank you for this info, I was able to reproduce the issue, but so I won’t flood the support team’s inbox with further tickets.
Permalink
Same issue here on SP2019. it seem to be related to one .js file that is not updated correctly. The error is Uncaught (in promise) TypeError: Cannot read properties of undefined (reading ‘call’) at sp-pages-assembly.js. The file is located in C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\TEMPLATE\LAYOUTS\Next\spclient\en-us\sp-pages-assembly.js
Trying a lot of fixes (including the side-by-side functionality one) but style not working. We put the KB on DEV but are not confident to put it on PROD now …
Permalink
I’ve narrowed down the issue to the following file in the hive
C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\TEMPLATE\LAYOUTS\16.0.10417.20037\Next\spclient\5.sp-pages-navigation.js
If you replace that with an older version the nav will come back (PLEASE NOTE I AM NOT AN MS Engineer and CANNOT say if this will have any knock on affect)
Permalink
Hi Pascal,
please install this fix and run the config wizard to resolve the issue:
https://www.microsoft.com/en-us/download/details.aspx?id=108287
Cheers,
Stefan
Permalink
Hi Stefan,
Thanks a lot ! The language depend patch fixed the issue.
I would like to take this opportunity to thank you for your blog which has been my bible for SharePoint updates for several years.
Thanks Stefan !
Pascal
Permalink
Thanks Pascal!
🙂
Permalink
Hi Stefan, I’ve narrowed down the issue to the following file in the hive
C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\TEMPLATE\LAYOUTS\16.0.10417.20037\Next\spclient\5.sp-pages-navigation.js
If you replace that with an older version the nav will come back (PLEASE NOTE I AM NOT AN MS Engineer and CANNOT say if this will have any knock on affect)
Permalink
I to have just found the same issue after running the Set-SPMachineKey on all my webapps. Thankfully, this is my Staging farm, and as I’m not the only one, I won’t be running this on Prod until resolved.
The security patch will still be installed
Permalink
I had this issue even before i ran Set-SPMachineKey. Just saying…
Permalink
Per our current knowledge the issue is not related to the machine key rotation.
Permalink
That would make sense, as we have also noticed this in one of our other farms where the security fix has been installed, along with the July patches also
Permalink
Hi Stefan,
In my SP2016 farms, spinstall0.aspx is not found in “C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\TEMPLATE\LAYOUTS”. Does this mean that I can ignore this vulnerability? One farm has the July CU applied and the other one has the June CU.
Thanks, Sam
Permalink
Hi Samson,
no. It just means that so far your server has not been compromised.
To protect it you need to apply all steps in the customer guidance.
Cheers,
Stefan
Permalink
If the latest security patch has been installed and spinstall0.aspx has NOT been found, do you still recommend rotating machine keys?
Note some of the confusion in the comments is that the MS article specifically says “use the Update-SPMachineKey cmdlet” but the link, if clicked on, does take you to “Set-SPMachineKey” cmdlet.
Permalink
Yes – absolutely – it is required.
The correct command is Set-SPMachineKey. Update-SPMachineKey does not rotate the machine keys.
Permalink
Yes, the language dependent fix from July 2025 CU was installed and in lieu of running the Config Wizard, this psconfig was run:
PSCONFIG.EXE -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install
Can it be that spinstall0.aspx didn’t get applied with the psconfig above?
Permalink
spinstall0.aspx is not a file coming with SharePoint. If this is on a SharePoint machine it means the machine was most likely compromised using the security vulnerability.
Permalink
Hello.
Just to confirm a few things.
ASMI – does this need to be activated. During its initial release back in Sept 2023, it caused us all sorts of performance issues, and we left it deactivated. Does it now need activating as part of this CVE?
Rotating machine keys – We have multiple web apps on each farm. Assume I will require the following:
Set-SPMachineKey -WebApplication “Each web application” or will the same key be used for all web apps.
Update-MachineKey – WebApplication – assume updates across the entire farm
Many thanks
Scott
Permalink
Hi Scott,
AMSI is currently mandatory for SP2016 to protect the servers as the fix for this SharePoint version is currently not available. SP2019 and SPSE can be protected by installing the fixes released yesterday.
With Set-SPMachineKey you can modify the machine key for a given web application. You need to apply this to all web applicatons.
Update-SPMachineKey only replicates the configured key to all machines in case they are out of sync.
The correct command to be used to rotate the machine key is Set-SPMachineKey
Cheers,
Stefan
Permalink
Thank you Stefan,
Like many others, there does appear to be some confusion around what PS to use for the key rotation?
Even with multiple web apps, we simply run “Set-SPMachineKey” and this will update it across the farm? No requirement to use the “Update-SPMachineKey”
Thanks again
Permalink
Hi Scott,
yes. If you do NOT specify the -Local parameter with Set-SPMachineKey it will be applied to this web application on all machines in the farm.
If you pass in -Local it will be only updated on the current machine.
Cheers,
Stefan
Permalink
Hi,
here are my findings after reflecting the .net source of the cmdlets.
Call this on the first server. Omitting the parameters -DecryptionKey and -ValidationKey will automatically generate new random keys. These will be written to all local web.configs on this server, for each iissetting of each web application.
Get-SPWebApplication | foreach { Set-SPMachineKey -WebApplication $_ }
Restart-Service W3SVC
If you have multiple servers in the farm, call this on each other server separatetly, with a short delay, so the updated SPWebApplication objects with the new keys are invalidated from the object cache on the other servers after Set-SPMachineKey.
Get-SPWebApplication | foreach { Update-SPMachineKey -WebApplication $_ }
Restart-Service W3SVC
Using the -Local switch parameter with Set-SPMachineKey will generate new keys and write them to web.config but will not save them in the SPWebApplication object, so you cannot replicate them with Update-SPMachineKey.
When not using the -Local switch at all the cmdlets will create a new Health Analyzer Rule (internally called ViewStateKeysAreOutOfSync, misleading Display Name is “Web.config files are not identical on all machines in the farm.”) that will daily check if the keys are in sync over all servers.
Permalink
Hi Stefan,
I am taking the opportunity from your response to ask if in a SharePoint 2016 farm where AMSI is activated, full mode is enabled by default or not? The patch level of the farm is November 2024.
Also I would like to ask if we block the respective vulnerable paths (/_layouts/15/ToolPane.aspx* and /_layouts/15/SignOut.aspx*) at CDN level, would you consider it a valid temporary mitigation strategy until a new Security Update is published by Microsoft?
Thanks,
George D.
Permalink
Hi,
on our SP19 farm I have installed the KB5002754 and the language dependent KB5002739. After installing the binaries, looking into the “View installed updates” (Windows control panel) only the KB5002739 is being listed as installed.
When I try to run the KB5002754.exe on its own, I get the message “The update is already installed on this system”.
So is it only an display error that the KB5002754 is not being listed explicitly in the “View installed updates”?
Permalink
Hi Labinot,
did you run the SharePoint configuration wizard after installing the fixes?
Cheers,
Stefan
Permalink
Hi Stefan,
yes, I did run it on the WFE and APP server. Funnily enough, the KB5002754 is listed on the APP server in the “View installed updates” but not on the WFE. We use MinRoles, no Custom roles applied.
Permalink
Am I correct in assuming this Security Update will update the binaries only and not the database schema?
Permalink
Hi Andre,
there is no guarantee for this as this fix most likely several other fixes which were planned to be included in August CU.
In any case: after installing this fix it is mandatory to run the SharePoint configuration wizard.
Cheers,
Stefan
Permalink
Hi Andre, Stefan
I guess it also depends on the version / build number you had before the patching right?
If your farm was running the January 2025 CU, installing the Security Update would surely modify the database schema as this is a cumulative update.
Thanks
Matt.
Permalink
Yes – thats correct.
Permalink
After Set-SPMachineKey do we need to run iisreset on all SP Servers ?
Permalink
Hi Alexandre,
IISReset has to be run on all servers after the change has been replicated to these servers, correct.
Cheers,
Stefan
Permalink
Stefan, is there a need to run Update-SPMachineKey on the rest of the servers in the farm after running Set-SPMachineKey one one of them (without using the -local switch)? One of the commenters above indicated them running both, so wanted to get clarification…
Permalink
Hi Somu,
in an ideal world – no. The change should replicate automatically. But if you identify a server which still has the old machine key after a couple of minuets you can run Update-SPMachineKey to replicate the change from the Config DB to the affected machine.
Important is that after the new machine key is present an IISRESET is done.
Cheers,
Stefan
Permalink
What if we have already installed KB5002754 on Sharepoint 2016? Will it update with the new version or is there another workaround? We are using WSUS for patching.
Permalink
KB5002754 is a fix for SharePoint Server 2019. It cannot be installed on SP2016.
Permalink
Apologies. KB5002744 for SP2016. I saw a notice that this KB would be updated with the fix. Is that accurate or will MS issue a separate patch?
Permalink
Hi David,
this KB will not be updated. A new fix with new KB will be made available when the fix is released.
Cheers,
Stefan
Permalink
Thanks. Just applied the new Security Update for SP SE
Permalink
We just updated a SP 2019 farm with July 20th fix and July 8th language pack. Now we are not able to control websites with modern view – we can not add pages or edit permissions. Websites with classic view do not show these problemes.
In the browser dev console we see exactly these messages:
https://learn.microsoft.com/en-us/answers/questions/180911/cant-edit-modern-pages-on-upgraded-instance-of-sha
We tested with Chrome, Edge and Firefox.
Update of the farm went smooth so far. What can we do?
Permalink
Hi Yoda,
I would recommend to open a support case to get assistance.
Cheers,
Stefan
Permalink
Hi Stefan,
thank you. This would lead to a time consuming process with pre-qualifying ping-pong and spending hours of talking and writing emails.
We think about it.
Permalink
the problem is described here as well: https://blog.stefan-gossner.com/2022/05/31/trending-issue-left-navigation-missing-after-applying-may-2022-cu-for-sharepoint-server-2019/
I already tried some fixes – no luck until yet, I will continue tomorrow.
Nevertheless – a real annoying topic.
Could it be related to the fact, that the language CU is older?
Permalink
Dear Stefan,
we do have an SP2016 Farm, which has the Build 16.0.5469.1000
We still want to update the Farm with the July 2025 Update, but we tried to search for the following Informations:
From which build oder patch Version of SharePoint Server 2016 is SharePoint affected by the vulnerabilities CVE-2025-53770 and CVE-2025-53771?
We need a Source.
King Regards
Jonas
Permalink
Hi Jonas,
all patch levels are affected.
Cheers,
Stefan
Permalink
If we discover that our WFE’s are compromised (SP2016), does the hotfix (once released) correct that or do we need to rebuild?
Permalink
Hi Daniel,
no it will only fix the underlying vulnerability.
Rebuilding the server would be recommended.
Cheers,
Stefan
Permalink
Did you mean NOT recommended 🙂
Permalink
no – rebuilding is recommended if the machine has been compromised.
Permalink
Hi Stefan,
We are currently running a SharePoint 2016 farm, and the file spinstall0.aspx does not exist on the system.
The server can initiate outbound connections but is not accessible from the outside.
Since there is currently no security update available for our SharePoint 2016 system, we are considering whether it would make sense to disconnect the server entirely from the internet for the time being, for security reasons.
Do you think this step makes sense and would improve security?
Permalink
Hi Emanuel,
only inbound requests are critical – not outbound.
Cheers,
Stefan
Permalink
Thank you for the quick response.
Permalink
does anybody know what will be the new build number in 2019 after deploying the new patch?
Permalink
16.0.10417.20037 ?
Permalink
16.0.10417.20037
Permalink
thank you
Permalink
Hi Stefan,
If in a SharePoint 2016 farm where AMSI is activated, full mode is enabled by default or not? The patch level of the farm is November 2024.
Also I would like to ask if we block the respective vulnerable paths (/_layouts/15/ToolPane.aspx* and /_layouts/15/SignOut.aspx*) at CDN level, would you consider it a valid temporary mitigation strategy until a new Security Update is published by Microsoft?
Thanks,
George D.
Permalink
Does SharePoint SE need APS.net key reset?
https://msrc.microsoft.com/blog/2025/07/customer-guidance-for-sharepoint-vulnerability-cve-2025-53770/ says “Customers using SharePoint 2016 or 2019 should follow the guidance below.” and “5. Rotate SharePoint Server ASP.NET machine keys”
Does that mean SharePoint SE not need APS.net key reset?
Permalink
Yes.
Permalink
so we have the lastest patch of March 2025 for SharePoint 2019. installing the latest security patch of KB5002754 will cover us ?
Permalink
Hi Sam,
from a security perspective – yes. But the users might see a lot of errors.
Reason is that the language dependent fix from March CU does not fit to the language independent security fix.
To address this you need to ensure that the language dependent fix from July CU (KB5002739) is also installed.
Cheers,
Stefan
Permalink
thanks for clarification. If everyone is still confused, the latest SharePoint server security updates you should have for 2019 is KB5002739 and KB5002754. cheers !!
Permalink
Hello,
In our SharePoint 2019 environment, after installing the latest July CU and running the configuration wizards, the Farm Information page (_admin/FarmServers.aspx) shows both of our WFEs as compliant “No.” However, the Status column for each WFE says “No Action Required”. We experienced no issues during the updates.
Is anyone else experiencing this issue?
Thanks,
Michael D.
Permalink
Does Set-SPMachineKey need to be run against the Central Admin web application as well?
Permalink
Yes.
Permalink
We’ve installed KB5002754, then KB5002739 from July 2025 CU on our SharePoint Server 2019. The installation went well without errors, but the modern pages UI is broken as reported by other people here – so it doesn’t look like an issue specific just to our farm.
I’ve submitted a ticket to MS support, hopefully we’ll get a resolution soon.
Good thing we caught it in non-production environment. It’s frustrating to see that MS releases a broken patch for a critical security issue that people will rush to fix. Be careful with it.
Permalink
Hi Egor,
please install this fix and run the config wizard to resolve the issue:
https://www.microsoft.com/en-us/download/details.aspx?id=108287
Cheers,
Stefan
Permalink
Please also install the language pack for SP2019:
It is available here: https://www.microsoft.com/en-us/download/details.aspx?id=108287
This should fix the navigation and missing menu issues on modern pages.
Permalink
Is there any sort of ETA for the SharePoint 2016 Enterprise patches? Are they expected today?
Permalink
An ETA is not yet available.
Permalink
Hi Tom,
the SP2016 fix was just released. Check the CVE articles.
Cheers,
Stefan
Permalink
Can we just install the two CVE patches for SP 2016 and bypass July 2025 patches?
Permalink
Yes
Permalink
Hi Tom,
It is on,
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-53771
https://support.microsoft.com/pt-br/topic/description-of-the-security-update-for-sharepoint-enterprise-server-2016-july-21-2025-kb5002760-3ba63c92-23dd-4a1c-9f23-6dbcca9447ed
(KB 5002760) and (KB5002759)
Permalink
Hi all, for those noticing problem with SharePoint Server 2019 and the security fix (Javascript Errors and Navigation missing): this issue was caused by the fact that with the out-of-band security fix only a language independent fix was released. The problem is that this fix includes changes to Modern UI which has dependencies to the language dependent components.
To resolve this the product group now released also the matching language dependent fix which resolves this:
https://www.microsoft.com/en-us/download/details.aspx?id=108287
Permalink
Thanks for the update, Stefan!
Does this replace the July 2025 language dependent component? Do we still need to apply July 2025 CU?
Permalink
Yes exactly.
Permalink
Sorry if my question was ambiguous. Do you mean that we DO NOT need to install July 2025 CU at all because the newly released KB5002753 (wssloc) together with KB5002754 (sts) fully replace it?
Permalink
Yes exactly. No need for July 2025 CU. Just install the two fixes (KB5002753+KB5002754)
Permalink
So do we then need to install patches KB5002754 + KB5002753 and ignore the standard July CU patches 2741 and 2739?
Permalink
yes exactly.
Permalink
I installed all patches… including: KB5002753
(KB5002754, KB5002739 and KB5002753)
Run Product Wizard on all Server – with GUI and with PS: psconfig.exe -cmd upgrade -inplace b2b -force -cmd applicationcontent -install -cmd installfeatures
did iisreset / restart timerjobservice
still got the Javascript Errors and Navigation Issues on our production enviroment..
Permalink
Hi Pivo,
in this case please open a ticket with Microsoft Support to get this analyzed.
Cheers,
Stefan
Permalink
Same thing is happening in our DEV environment. KB5002753 and KB5002754 installed but the navigation issue persists. Seems we are not the only ones. Is Microsoft already looking into this?
Permalink
Hi Maurice,
we are looking into this on a case-by-case basis as support cases arrive.
Cheers,
Stefan
Permalink
Getting back to this, it turns out that disabling the SideBySide feature fixes the navigation issue after installing both updates. We had this enabled because of the zero downtime patching process. For more info on enabling/disabling SideBySide see here:
https://learn.microsoft.com/en-us/sharepoint/upgrade-and-update/sharepoint-server-2016-zero-downtime-patching-steps
Permalink
Thanks Maurice!
I would assume that running Copy-SPSideBySideFiles and guaranteeing that the correct side-by-side token is configured would have fixed it as well.
Cheers,
Stefan
Permalink
Just ran Copy-SPSideBySideFiles on both servers in our DEV farm, enabled SBS again and set the token to 16.0.10417.20037. Also did an iisreset. But it didn’t fix the navigation issue. Only completely disabling SBS fixes it for now.
Permalink
Hi Maurice,
this is really strange.
I would suggest to open a support case with Microsoft to get this investigated as Side-By-Side patching is fully supported and recommended.
Cheers,
Stefan
Permalink
I assume this guy is from CZECH because of the nick name. If so, it looks like issue with CZ langpack.
Permalink
we use german language pack 😉
Permalink
Thank you very much for maintaining this blog Stefan! Just saw this comment and grabbed the language dependant fix for SP2019 to fix my navigation bar issue and appear to be good to go now. Thanks again for going above and beyond to keep this up to date!
Permalink
in SharePoint 2019 left Navigation still missing in modern sites after installation of KB500753
“sp-pages-assembly.js?uniqueId=23Q8x:91 Uncaught (in promise) TypeError: Cannot read properties of undefined (reading ‘call’)
at t (sp-pages-assembly.js?uniqueId=23Q8x:91:787)”
before that, of course, i had CU 7/25 and KB500754 installed
Permalink
Hi Jo,
did you run the SharePoint configuration wizard?
Cheers,
Stefan
Permalink
Hi Stefan,
of course I did
Permalink
In this case it is not expected and I would recommend to open a ticket with Microsoft Support to get this analyzed.
Permalink
If my SharePoint 2019 only installed to Intranet with firewall, could the attack be avoid?
Permalink
Hi Amy,
depends. If the SharePoint Server is reachable from Internet through the firewall then yes.
And it can also be attacked from within the Intranet if any Intranet machine has been exploited.
Cheers,
Stefan
Permalink
2016 Security Update Patch is Live – https://www.microsoft.com/en-au/download/details.aspx?id=108288
2016 Language Pack – https://www.microsoft.com/en-au/download/details.aspx?id=108289
Blog (in process of updating) for all updates/authoritative source/guidance – https://msrc.microsoft.com/blog/2025/07/customer-guidance-for-sharepoint-vulnerability-cve-2025-53770/
Permalink
Hey Stefan
We have Sharepoint 2016 on prem and we installed (KB5002744) and (KB5002743) prior to the exploit being published. Actually early last week. Since the KBs are already on the systems. What would do if we can reinstall or what are next steps for someone who patched earlier?
Thanks as always
Dan
Permalink
Hi Dan,
please install these fixes which were just released:
https://www.microsoft.com/en-au/download/details.aspx?id=108288
https://www.microsoft.com/en-au/download/details.aspx?id=108289
Cheers,
Stefan
Permalink
Hi Stefan,
Are these fixes cumulative? We don’t need to install July 2025 CU for SP2016 in order to install these fixes?
Permalink
Correct
Permalink
Thank you Stefan!!!
Permalink
its taking longer than regular time for the KB 5002768 , am running it manually, do i need to do this using the powershell script like other patches?
Permalink
Hi Vikram,
the same steps as for regular CUs to speed up the installation would help:
https://blog.stefan-gossner.com/2024/03/08/solving-the-extended-install-time-for-spse-cus/
Cheers,
Stefan
Permalink
Hi Stefan,
We installed July Patches and then running KB 5002768 and then run config wizard on all servers, is this the correct approach for this? Can you please let me know
Permalink
Hi Vikram,
KB 5002768 would have been enough. It includes the July patches.
But ensure to also rotate the machine keys using Set-SPMachineKey -WebApplication after the patch is installed.
Cheers,
Stefan
Permalink
Hi Stefan,
if our system is not attacked, do we still need to do the rotation of machine keys step?
Permalink
To be on the safe side: yes.
Permalink
Hi stefan
After install newly released patch sharepoint 2016. After ps configuration
Do we need to do anything?
Permalink
Hi Ram,
yes – you need to rotate the machine keys for each web application using Set-SPMachineKey.
Cheers,
Stefan
Permalink
Thanks for update
For one web application one time is fine
No need to run all the servers i am right?
Permalink
Yes – but better double check on the other servers to ensure that the timerjob that replicates it was successfully updating the machine keys.
Permalink
Hi Stefan,
We are on SP 2019, installed KB5002753 and KB5002754. Config wizard also completed.
but i am unable to view the “Machine Key Rotation Job ” from CA.
So , Set-SPMachineKey and update-SPMachineKey mandatory to run or we can ignore .
Thanks,
KK
Permalink
Hi KK,
no worries – just use the “Set-SPMachineKey -WebApplication https://…” PowerShell command instead.
And don’t forget to IISRESET all machines after the new key has been replicated.
Cheers,
Stefan
Permalink
Hi Stefan,
Set-SPMachineKey -WebApplication “Web app name” or “Web URL” is alone enough to rotate the machine keys. no need of the second command mentioned “Update-SPMachineKey” ??? .
Also are we supposed to run this command only for the internally exposed web applications to the users or even for the central admin. since you’ve mentioned this can also be attacked from within the Intranet if any Intranet machine has been exploited.
Permalink
Hi Raja,
yes. Set-SPMachineKey will update the machine keys on all servers. No need to run Update-SPMachineKey.
It is recommended to run it against all SharePoint web applications including the Central Administration Website.
Cheers,
Stefan
Permalink
Hi Stefan,
we ran it on all web apps but missed central admin is that fine? or can I run on central admin too and do iisreset? what would you recommend?
Permalink
You can run the command against the Central admin now and just recycle the worker process of the central admin or do an IISRESET.
Permalink
Hi Stefan,
Hope this new fix KB5002760 and KB5002759 for SP 2016 Server are cumulative, only these files need to be patched, and we can ignore the old July patch 2 files.
After applying this patch, do we need to still do machine key rotation or is it part of the patch already?
Related to machine key rotation:
– We don’t see the job definition named – “Machine Key Rotation Job” to manually run. how to find and run this job through central admin.
– Through PowerShell command, we’re not clear what to be executed and the impact, since the blog specifies two commands
o Set-SPMachineKey
o Update-SPMachineKey
Is it specific to web application or server, since the command mentioned about -WebApplication
Permalink
Hello Raja,
Hopefully I can answer some of your questions, as I am almost at the stage of completing the entire process across all my farms.
After applying the patch, machine key rotation will still need to be done. I too was unable to see the timer job, and discovered that it may be due to having Defender installed and the ASMI feature activated. You can still rotate keys using PS.
I have multiple web apps, so here’s what I ran, specifying each web app name. This updates the machine key across all of the servers.
Set-SPMachineKey -WebApplication “Web app name”
Following this, you will need to run iisreset.exe on ALL SP servers
Hope this helps
Permalink
Thanks, Scott, for your response. much appreciated.
Set-SPMachineKey -WebApplication “Web app name” or “Web URL” is alone enough to rotate the machine keys. no need of the second command mentioned “Update-SPMachineKey”.
Also are we supposed to run this command only for the internally exposed web applications to the users or even for the central admin. since Stepan mentioned this can also be attacked from within the Intranet if any Intranet machine has been exploited.
Permalink
Hey Stefan,
a company just reached out to me, wanting to check if their SharePoint Server 2016 is affected. It seems not the case, but unfortunately the farm was patched many years ago. Build number 16.0.5329.
Can I install KB5002760 and KB5002759 directly?
Thanks in advance!
Best regards,
Mark
Permalink
Yes you can.
Permalink
Hello together,
we have SP 2019 Enterprise Farm and we installed both Patches KB5002754, KB5002753
But we have the problem that the left navigation bar is already missing and on the right the buttons on the Master Page doens’t loaded.
Has anyone a solution or idea, what we can do? Will it be fixed with further patches ?
Thank you very much for an answer.
Michael
Permalink
Hi Michael,
did you run the SharePoint configuration wizard after installing the patches?
Cheers,
Stefan
Permalink
Hi Stefan,
yes i run the wizard two times on all farm servers
Best regards
Permalink
Hi Michael,
in this case it is not expected.
I would suggest to open a ticket with Microsoft Support to get this analyzed.
Cheers,
Stefan
Permalink
Hi Stefan,
On SharePoint 2019 classic design, the security update has broken our clients BCS models.
We’re getting following exception:
Exception thrown while performing the BDC query in Entity Picker System.InvalidOperationException: The Model contains LobSystem (External System) of Type ‘DotNetAssembly’ which is not supported.
We’re currently trying to restore the SPS_BusinessDataCatalog DB from an environment where the patch hasn’t been installed yet. I know SharePoint has stopped support since September 2024 CU for SharePoint 2019, but the patch is breaking what was working before.
Permalink
Hi Isak,
this is expected and by design.
Sounds as if you upgraded from a rather old build. DotNetAssembly was disabled in a security fix 9 month ago already.
The solution is to move the business logic from the assembly to a custom WcF service and use the WcF LobSystem instead.
Cheers,
Stefan
Permalink
Hi Stefan,
Thank you for your reply.
The servers were previously on April 2025 CU patch acoording to:
https://blog.stefan-gossner.com/2025/04/08/april-2025-cu-for-sharepoint-server-2019-is-available-for-download/
Converting these to custom WcF will take some time, and this patch seem too urgent to wait for that to be done. BCS models were working fine before the security patch.
Best regards,
Isak
Permalink
Yes I understand. But you are not alone.
A lot of customers had to go this route since the fix was initially rolled out in September.
Permalink
https://learn.microsoft.com/en-us/sharepoint/business-connectivity-services-retirement
“Impact to SharePoint Server
This announcement has no impact on Business Connectivity Services in SharePoint Server.
This feature will remain supported in SharePoint Server 2016 and SharePoint Server 2019 until those products reach their end of support date of July 14, 2026.
Microsoft has no plans to retire Business Connectivity Services in SharePoint Server Subscription Edition at this time. Deprecation and removal announcements for SharePoint Server Subscription Edition are announced in the What’s deprecated or removed from SharePoint Server Subscription Edition article.”
Why is this now impacting SharePoint Server 2016 and 2019?
Will there be fix?
Permalink
Hi Yrjö,
BDC itself remains supported as listed. But the LobSystem DotNetAssembly and WebService got disabled with September 2024 CU through a security fix due to vulnerabilities in these two LobSystem types
The recommended solution is to migrate the business logic from the assembly into a WcF service and use the LobSystem type WcF to reference it via BDC.
Cheers,
Stefan
Permalink
Hi Isak,
We’re in the same situation. It appears that the DotNetAssembly type has been deprecated for some time, but the enforcement only started with the June 2025 CU. We only began encountering errors with our BDC queries after installing this CU.
I just wish Microsoft had communicated this change more clearly.
Best regards,
Andrei N.
Permalink
Hi Isak,
We’re running into the same issue and I’m wondering if restoring the old BDC DB worked for you? If not, what did you do in your case?
Permalink
For future reference – we tested restoring an older BDC DB and it does not work. It seems you will need to revert to an older snapshot before this security patch in order to have DotNetAssembly type work.
Permalink
Dear Stefan,
Thank you for your blog!
Permalink
Regarding rolling of the machine key:
Get-SPWebApplication -IncludeCentralAdministration | foreach { Set-SPMachineKey -WebApplication $_ }
Restart-Service W3SVC
-> otherwise you would omit the central administration webapp
and then on each farm member:
Get-SPWebApplication | foreach { Update-SPMachineKey -WebApplication $_}
Restart-Service W3SVC
Correct?
Permalink
Hi Yoda,
Update-SPMachineKey will update ALL machines in the syntax above – not just to one where the script is executing.
So if you execute this on all machines in an 8 server farm it is updated 8 times on all machines.
In general Set-SPMachineKey should change the key on all machines automatically. If that is not the case and you would like to force it using Update-SPMachineKey using the script above I would recommend to use the -Local parameter:
Get-SPWebApplication | foreach { Update-SPMachineKey -WebApplication $_ -Local }
Restart-Service W3SVC
Cheers,
Stefan
Permalink
OK, thank you.
But the parameter -IncludeCentralAdministration makes sense in order to generate a new key for central, or doesn’t?
This is missing often in the hints.
Permalink
Hi Yoda,
if the central admin is running on multiple machines – yes.
In most farms I have seent it is only on one server and does not have to be replicated using Update-SPMachineKey
Cheers,
Stefan
Permalink
You mentioned there is this Language Pack dependency do SP19. Is there a similar dependency for SPSE?
Permalink
Hi Andre,
SPSE has Uber packages. Means the language independent and dependent fixes are always bundled in one fix.
Only for SP2016 and SP2019 customer need to take care of the dependencies themselves.
Cheers,
Stefan
Permalink
Hi Stefan,
Our SharePoint Server 2019 farm is currently running on an older build version: 16.0.10402.20016 (September 2023). We would like to apply the following updates: KB5002753 and KB5002754.
Could you please confirm whether we can apply these two updates directly, or if a specific CU must be installed as a prerequisite first? Thanks in advance.
Permalink
Hi Marina,
Confirmed. There is no need to install an older CU.
Ensure to run the SharePoint config wizard afterwards and in regards to the security issue also perform the Machine Key rotation AFTER the fixes are installed.
Cheers,
Stefan
Permalink
Thanks a lot☺️
Permalink
Hello,
did the installation of the KB5002753 resolve the issue with the left navigation bar for anyone?
We have SP 2019 farm, both packages (KB5002754, KB5002753) have been installed, psconfig was run twice, once after installing the first package yesterday, and again today after installing the new package.
IIS has been reset on all SharePoint servers. The problem still persists.
Has anyone a solution or idea, what we can do?
Best regards,
Zan
Permalink
Hi Zan,
we have several customers who opened support cases who confirmed that KB5002753 resolved the Nav and Javascript issues.
Cheers,
Stefan
Permalink
We installed KB5002754 + KB5002739 yesterday, do we need to install also the new language pack KB5002753?
Permalink
Hi Ellie,
about the terminoloty: it is not a new Language Pack. “Only” a fix for the language elements which got installed through the language pack.
But yes: you need to install it. Otherwise you will most likely see problems in Modern UI.
Cheers,
Stefan
Permalink
Hi Stefan,
First of all, thank you for your professionalism and dedication in your blog! Replying everyone is massive!
We are in the same scenario as Ellie, we have installed KB5002754 & KB5002739 and rotated the machine keys successfully. For the time being, we have not experienced any Modern UI issue, so the question is: Are we safe security-wise (AMSI and Defender running + no spinstall0.aspx found)? Can we take some time to plan the installation of KB5002753 later?
Highly appreciating your effort!
Permalink
Hi Tony,
from a security perspective KB5002753 is not required.
It was only released to address the modern UI issues a large number of customer experienced.
So yes – if you don’t need it you can postpone or skip it and directly go to August CU which will include it.
Cheers,
Stefan
Permalink
Hi
Thanks for all the information!
I am afraid this is kind of a n00b question, but when we run the Configuration Wizard, would it be fine to run it simultaneously on all nodes, or should they rather be run sequentially in a specific order?
Permalink
Hi Brian,
you need to run in on a single machine at the beginning to perform the database upgrades.
After this is completed you can run it on all other machines in parallel as only local operations will be performed.
Cheers,
Stefan
Permalink
Oh is that so? I was under the impression, that in a multi server farm it should be one after another, starting with the Application server (that hosts the CA). If true, this is good to know and will speed things up significantly.
Thanks!
Permalink
Yes. Was alway as I mentioned above.
Permalink
https://learn.microsoft.com/en-us/sharepoint/upgrade-and-update/install-a-software-update it states it would be the server with CA first, then all application servers, and only after that the front ends. Do we really need to follow this order? Or can we start everything in parallel after the server with CA is done?
Permalink
No harm in trying that.
Config Wizard that you start on the first server will lock the config database, so when you start Config Wizard on the next server in parallel, it will not do anything, just wait until the lock is released by the first instance of the Wizard. Basically, it only saves you a bit of time that takes you to notice that one server is done and to start the next one.
Permalink
You are right. Tried last night on a large farm and exactly as you described. Just a faster queue, nothing really happening in parallel.
Permalink
We’re running 2016 and have installed the 2 patches. We cannot activate AMSI, but since the 2 patches have been installed, are we safe to connect the servers to the internet again?
Permalink
Hi Tommy,
yes – if you also rotated the machine keys and did an IISreset.
Cheers,
Stefan
Permalink
Stefan, do you have any info regarding other language packs (de, fr etc.)? Thanks a lot
Permalink
Hi Cori,
all language pack updates are in the same package.
We do not have separate fixes for different languages.
Cheers,
Stefan
Permalink
Hi Stefan!
Thanks for all your hard work, your blog is invaluable for us SharePointers!
I have two questions:
1) We are on SP2016 and have just applied the July 2025 CU. From an installation perspective, should the new SP2016 security updates KB5002759 and KB5002760 be treated and installed just like any other CU? (Like side-by-side commands when using ZDP, and everything else.)
2) Do we need to rotate the machine keys one more time after applying the new security updates for 2016?
Thanks!
Permalink
Hi Will,
1) yes – these are CUs just released outside the regular release cycle
2) yes.
Cheers,
Stefan
Permalink
Hi [again], Stefan – and thanks for clarifying the ConfigWizard run
(Once, and then in parallel if needed).
I am now preparing to upgrade an oldish SP2019, and have fetched the 2735/2754 patches to install there.
(SP2019 version 16.0.10401.20003)
I have slightly stalled at my checking of AMSI presence/confiugration, because that feature ist not even in the menu in CentralAdministration -> Security.
I remember having an issue a year or so ago, in which Sharepoint and the Antivirus kept hogging the CPU, and we decided to run
“Disable-SPFeature -Identity 4cf..lots-of-numbers….8e9 -url https://ourSP2019.do.main ”
It seems obvious, but was that the reason why AMSI is now gone from menu?
Is the reverse now as simple as “Enable-SPFeature -Identity 4cf..lots-of-numbers….8e9 -url https://ourSP2019.do.main ” (If so, is it important to execute before patch, or does it not matter much?)
Is this AMSI strictly needed – if the SP2019 is purely inside only, no internet presence.
Thanks in advance 😉
Permalink
Hi Brian,
if the fixes from July 21st were installed then AMSI is optional.
If not, it is mandatory.
Cheers,
Stefan
Permalink
SP2016. “In general Set-SPMachineKey should change the key on all machines automatically”
Just to be clear: Running Set-SPMachineKey on the app server will rotate the keys on all servers in the farm, is that correct?
And thank you so much for the help.
Permalink
Yes, Stefan has stated that a bit higher up in the thread (do a CTRL+F for “Set-“):
QUOTE:
Hi Raja,
yes. Set-SPMachineKey will update the machine keys on all servers. No need to run Update-SPMachineKey.
It is recommended to run it against all SharePoint web applications including the Central Administration Website.
Cheers,
Stefan
Permalink
Prior to applying this patch Defender was reporting an alert for “Exploit:Script/SuspSignoutReq.A” for item “amsi:\Device\HarddiskVolume2\Windows\System32\inetsrv\w3wp.exe” but it was reporting that the action taken was quarantined. There was no evidence of spinstall0.aspx anywhere on the server and AMSI was already enabled.
After applying the patches, running pcsonfig, and rebooting we are still seeing the same message from Defender. Is the expectation that applying this patch will cease the alerts in Defender or is it simply that when someone tries to use the exploit that the request will be handed off to Defender to block/quarantine the request preventing them from depositing the spinstall0.aspx page?
If it only stops the creation of the spinstall0.aspx page and this is an expected response from Defender, then what is your recommendation for filtering out these noisy responses so that we can focus on threats that haven’t been addressed?
Permalink
Be careful – meanwhile we have seen customers where machines were exploited the thread actor uploaded a file with different name than SPINSTALL0.ASPX.
We saw a large variety of names e.g. SPINSTALL.ASPX, SPINSTALL1.ASPX, SPINSTALL2.ASPX but also completely random names like JSNASDW1.ASPX.
Please check for files created in the last couple of days rather than only checking for files with the name SPINSTALL0.ASPX as mentioned earlier in this blog post.
Permalink
There are no unexpected .ASPX files in the “C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\TEMPLATE\LAYOUTS” directory. What is the expected behavior in Defender after the patch is applied? When I go to the “History” tab and select “All detected items” and click on “view details”, there are still entries for “Exploit:Script/SuspSignOutReq.A” with an “Action taken” as “Quarantine”.
Each of these entries show as coming from “amsi:\Device\HarddiskVolume2\Windows\System32\inetsrv\w3wp.exe”
When we scan c:\Windows\System32\inetsrv it comes back clean with no threats and the PC Status is “Protected”. Yet if we give it enough time, we still see new entries appear in defender’s history under “All detected items”.
Should we be seeing new entries in Defender’s history?
Permalink
Hi Don,
this means that SharePoint AMSI integration is enabled.
AMSI acts as the first line of defense for such attacks. It is implemented as a Module in the IIS pipeline which passes all incoming requests to your AV solution using AMSI to verify if it is a malicious request.
If yes, the request will be blocked and logged accordingly. As the request was passed by the Module to your AV solution w3wp.exe is marked as the originator. So that is expected.
This will happen independently if the fix is installed or not as AMSI blocks the request before SharePoint starts handling it.
Cheers,
Stefan
Permalink
We are running Sharepoint 2019, we did not have the spinstall0.aspx file present on any of our farm servers, and we have followed all recommendations, installing the update, running products config wizard, rotating keys, AMSI is enabled.
We did see a few entries in our IIS logs since we have performed all remediation tasks like this:
2025-07-21 18:12:06 POST /_layouts/15/ToolPane.aspx DisplayMode=Edit&a=/ToolPane.aspx 443 – Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64;+rv:120.0)+Gecko/20100101+Firefox/120.0 /_layouts/SignOut.aspx 401 0 0 47 (I removed our internal IPs for security reasons)
Are we secure? Or are those log entries a concern despite following all remediation steps?
Permalink
Stenfan,
We have SharePoint 2019 on May CU. No spinstall0.aspx is found on our systems. The WFEs are accessible to the internet. Should we restore the WFEs from VM backups or all of the servers in the farm?
Thanks
Ping
Permalink
Hi Ping,
do not only check for SPINSTALL0.ASPX. We have found evidence for other file names.
Double check that no file was created sind July 18th in the layouts directory.
If one of these files exists, you should restore a backup.
Cheers,
Stefan
Permalink
Important Update: we have seen customers where machines were exploited where the thread actor uploaded a file with different name than SPINSTALL0.ASPX.
We saw a large variety of names e.g. SPINSTALL.ASPX, SPINSTALL1.ASPX, SPINSTALL2.ASPX but also completely random names like JSNASDW1.ASPX.
Please check for files created in the last couple of days rather than only checking for files with the name SPINSTALL0.ASPX as mentioned earlier in this blog post.
Permalink
We see on all 4 farm servers 2 app/2 web servers a large number of files created at 1:41am on July 20th:
files like: sp.ui.combobox.debug
sp.ui.controls
sp.uo.dialog
sp.ui.discussions
All Javascript files… 296 files in total. Not sure if that is from a job or is this concerning?
Permalink
Or are these date created stamps from the installer for the update we applied yesterday?
Permalink
Exactly the same time and numbers of files on my 3 environments… 295 .js and 1 .xap file.
@Stefan?
Permalink
Exactly the same for my 3 environments; 295 .js files and 1 .xap file on 20 July 1:41 AM
Permalink
Noticed the same on 3 SP19 environments, same date + time and 295 .js files + 1.xap
@Stefan?
Permalink
Hi Mike,
looks as if you installed a SharePoint fix yesterday.
The files installed during the patch installation need to be ignored of course.
Cheers,
Stefan
Permalink
Hi Stefan,
Thanks for the message.
We’re seeing a consistent pattern here. Like Mike, we also see these these files with a creation date July 20th, 1:41 AM, even though we installed the patch on July 21st.
Is it possible that the patch installer sets the file creation/modification dates to the original build time, rather than the actual installation time? That would explain the earlier timestamp we’re all observing.
Just wanted to confirm if this is expected behavior.
Cheers,
Emiel
PS thanks a lot for all the effort and time especially the last days
Permalink
Yes. The modified date should reflect the install time.
Permalink
same .js files with 1:41am on July 20. I believe it is from the fix.
Permalink
Hi Stefan,
Thank you for the confirmation “Yes. The modified date should reflect the install time.”. I cannot reply to it so I reply to the earlier message.
Based on your reply, we are concerned because the file timestamps do not match the installation time on our servers.
To be clear:
– The patch was installed on July 21st.
– The “Date Created” and “Date Modified” for the files are both July 20th, 1:41 AM.
This is the exact same behavior across all of my 3 environments and Mike’s 4 farm environments, affecting both Application Servers and Web Front-End servers.
From your reply it seems that this is not the expected behavior, what do you recommend as our next steps?
Regards,
Emiel
Permalink
Hi Emiel, let me quickly verify it.
Permalink
Hi Emiel,
I have to correct myself. I can confirm that the SP2019 fix install indeed places 295 Javascript files and one xap file in the layout directory dating July 20th, 2025 – 1:41 AM
Both, the creation and the last modified date will reflect this date.
Cheers,
Stefan
Permalink
Only now realized that Microsoft includes a list of files that are included in security updates.
It’s in the “More information” – “File information” section of the description of the update.
Good to keep in mind 🙂
Permalink
Hi Stefan –
We installed the fix released last night and ran the wizards on each of our three servers, then ran Set-SPMachineKey and Update-SPMachineKey for all four of our web applications. I’ve done IIS resets, rebooted, and reran the wizard on all servers. Central admin will load but we are getting a 500 error on all of our other web apps. I’ve checked the web configs and the machine keys match on all 3 servers. We have no errors in event viewer. Is this known to be an issue after rotating the machine keys?
Thanks for your help.
Permalink
Hi Staci,
no this is an unrelated issue.
Errors can happen between rotation and IISRESET due to temporary inconsistencies of the machine key while it is replicated.
But not after the IISRESET
Cheers,
Stefan
Permalink
So it turns out Antimalware being on in that web app started causing an issue after we did the key rotation/IIS resets (site was up and fine with Antimalware on and patches applied). Turning Antimalware off fixed the site and it now loads (but if I turn it on again, immediate 500 errors). Is there any documentation on Antimalware causing the 500 errors in SP2016? I wasn’t able to find much. This is our dev environment. Prod is in a state with patches and Antimalware on and is currently fully functional, but I’m afraid to rotate keys at this point for fear that it’ll cause the same problem.
Would it be preferred to have patches and Antimalware on or patches and keys rotated (if Antimalware starts causing 500s in prod after rotating keys?) I’m not sure how they are related at all but definitely the cause in dev.
Permalink
Staci,
Are these servers Windows Server 2012 R2? If so, then you cannot use AMSI.
Cheers
Permalink
Quick question, do we need to follow the bellow after applying the KB5002754 for SP19?
Their is point of highlight from Microsoft article all service owners that are patching their services:
Rotate SharePoint Server ASP.NET machine keys
After applying the latest security updates above or enabling AMSI, it is critical that customers rotate SharePoint server ASP.NET machine keys and restart IIS on all SharePoint servers. Follow the PowerShell guidance in Improved ASP.NET view state security and key management.
To update the machine keys for a web application using PowerShell:
Generate the machine key in PowerShell using Set-SPMachineKey -WebApplication .
Deploy the machine key to the farm in PowerShell using Update-SPMachineKey -WebApplication .
After the rotation has completed, restart IIS on all SharePoint servers using iisreset.exe.
If you cannot enable AMSI, you will need to rotate your keys after you install the new security update.
https://teams.microsoft.com/l/message/19:meeting_MjE0YmE4ZGItMGFiMy00OTRiLWEwYTYtZTUxYjBjODFmYjM2@thread.v2/1753199300872?context=%7B%22contextType%22%3A%22chat%22%7D
Permalink
Hi Rodrigo,
yes. machine key rotation is mandatory after installing this fix.
Cheers,
Stefan
Permalink
We installed KB5002754 + KB5002739 on a clients Dev Farm yesterday. Cleared the Caches and ran psconfig.
Thought all was well, but we have noticed that the Site Permissions and Site Information menu items from the gear icon no longer work from the home page (Modern). The Search this site from that page no longer works and the Edit page functionality is gone. I tried creating a new page but can’t edit that either.
If I bring up the dev tools I see multiple references to sp-pages-assembly.js deprecation notices and errors.
Still reading through these, but thought I would post in case others are seeing this behavior as well.
Permalink
Hi Carl,
meanwhile KB5002753 was released (see above in the blog post) which is a newer version of the language dependent fix (use instead of KB5002739) which fixes a lot of similar issues.
Please verify if this is addressed using this fix.
Cheers,
Stefan
Permalink
Stefan, is there a way to check if Set-SPMachineKey was run successfully? When I ran it, it took only a second or two to finish on the shell for a 10-server 2016 farm and it didn’t seem to show up in the Job History. In ULS, it leaves only 3 instances of “Entering BeginProcessing Method of Set-SpMachineKey” and “Leaving BeginProcessing Method of Set-SPMachineKey” without referencing any servers except the one that was run on. Is this behavior something expected?
Permalink
we used following script to check machine keys before and after set-spmachine:
Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue
$webApps = Get-SPWebApplication
foreach ($webApp in $webApps) {
$configPath = $webApp.IisSettings[“Default”].Path
if (Test-Path $configPath) {
$webConfigPath = Join-Path $configPath "web.config"
if (Test-Path $webConfigPath) {
[xml]$xml = Get-Content $webConfigPath
$machineKey = $xml.configuration.'system.web'.machineKey
if ($machineKey) {
Write-Host "Web App: $($webApp.Url)"
Write-Host " ValidationKey: $($machineKey.validationKey)"
Write-Host " DecryptionKey: $($machineKey.decryptionKey)"
Write-Host " Validation: $($machineKey.validation)"
Write-Host " Decryption: $($machineKey.decryption)"
Write-Host ""
} else {
Write-Host "Web App: $($webApp.Url) – No <machineKey> section found."
}
} else {
Write-Host "web.config not found for $($webApp.Url)"
}
} else {
Write-Host "IIS Path not found for $($webApp.Url)"
}
}
Permalink
Thanks for that script.
Permalink
On our Subscription Edition the configuration has been encrypted using Protected Configuration (https://learn.microsoft.com/en-us/previous-versions/aspnet/dtkwfdky(v=vs.100))
In this case, instead of ValidationKey/DecryptionKey verification use
if ($machineKey) {
Write-Host “Web App: $($webApp.Url)”
Write-Host “Cipher: “$($machineKey.EncryptedData.CipherData.CipherValue)”
Write-Host “”
}
Permalink
Timo, I am not sure if you have a farm that have multiple servers per role/webapp.
If you do, have you been able to successfully verify the ciphervalue between servers?
I suspect that the ciphervalue will be different for each time one use update-machinekey, making it unusable for direct comparison (works fine for verifying that it has been updated though)
Permalink
As we have to patch Central Administration as well, I would recommand replacing the first row with that one:
$webApps = Get-SPWebApplication -IncludeCentralAdministrationPermalink
Stefan
The link you provided in your post for Critical SharePoint Exploits Exposed: MDVM Response and Protection Strategy does not seem to work for me. I get a message about content being archived
Permalink
Thanks Keith!
Very weird – indeed. I get the same. I removed the link for the time being.
Cheers,
Stefan
Permalink
Hi Stefan,
Just following up on Raja’s question above.
Do the KB5002760 and KB5002759 for SP 2016 Server also include the July Patches? Can we ignore the old July patch 2 files?
Permalink
Yes. No need to install the older patches.
Permalink
Thanks!!
Permalink
Hi Stefan,
We’ve rolled out the sts and wss patches, ran the config wizard, rebooted servers and rolled the machine keys. We are now on version 16.0.10417.20037 on SharePoint 2019. However, we still see new alerts “An active ‘SuspSignoutReq’ exploit malware was prevented from executing via AMSI” in Defender pouring in. Is this to be expected after the patch and can I let my team know not to worry or is something wrong?
Permalink
Hi Jenne,
AMSI sits in front of SharePoint. It will deflect requests which are trying to exploit the vulnerability independent if the fix is installed or not.
But it proofs that your Servers are indeed currently being targeted by a bad actor.
Cheers,
Stefan
Permalink
That doesn’t surprise me at all, but good to know that it is to be expected. Thank you, hope this all blows over soon.
Permalink
Good morning Stefan,
I’m managing a SharePoint 2016 farm running on Windows Server 2012 with ESU.
The environment is protected by Trend Micro Deep Security and Trend Micro XDR.
I’ve come across conflicting information regarding AMSI compatibility with this operating system; some sources claim it’s supported, while others suggest otherwise.
Do you or any of the blog contributors have more definitive insights on this topic?
Permalink
Hi Loris,
I don’t know – but you can quickly test yourself.
Enter the following AMSI test command in a Powershell window:
AMSI Test Sample: 7e72c3ce-861b-4339-8740-0ac1484c1386
If the output reports malicious content the OS-AMSI integration works correct.
In addition you can test the SharePoint AMSI integration using the following command:
Invoke-WebRequest -Uri “https://servername/sites/sitename?amsiscantest:x5opap4pzx54p7cc7$eicar-standard-antivirus-test-fileh+h*” -Method GET
If this command returns a 400 Bad Request AMSI is working in SharePoint
(Or you can also just enter the Url in a browser and check if you get a 400 Bad Request.)
Cheers,
Stefan
Permalink
As a word of caution to anyone running these tests, it’s highly recommended to inform your administrators and security people beforehand. When you have your internal processes in order and things are working as they should, executing the command will trigger alerts and people will start running. Giving them a heads-up will probably be much apricated. A little coordination can save a lot of excitement 🙂
Permalink
Hi Stefan,
Can we perform the same test directly from a browser not with powershell. Are you expecting a 400 error message on the browser?
https://servername/sites/sitename?amsiscantest:x5opap4pzx54p7cc7$eicar-standard-antivirus-test-fileh+h*
Or testing with powershell is enought?
Invoke-WebRequest -Uri “https://servername/sites/sitename?amsiscantest:x5opap4pzx54p7cc7$eicar-standard-antivirus-test-fileh+h*” -Method GET
regards,
Matthew
Permalink
Hi Mathew,
yes – of course.
And yes: 400 bad request is the expected result if AMSI blocked the request.
Cheers,
Stefan
Permalink
Thank you for your reply,
We don’t have the same behaviour between Powershell and Edge. Edge is not giving any message and Powershell is clearly blocking + message on defender. Any idea?
regards,
Matthew
Permalink
Hello Stefan,
Thanks for your help on these issues.
On our SP2016 farms, we have the same behavior as Matthew: Edge accepts the url with “HTTP/1.1 200 OK” andwhile in PowerShell the Invoke-WebRequest with exactly the same url returns – as expected – (400) Bad Request, with a detection in Defender.
Edge issue?
Kr, Peter
Permalink
Hi Peter,
you need to remove the $eicar string piece.
In PowerShell this will happen automatically as $eicar is treated as a variable which uninitialized represents an empty string.
Try this Url:
https://servername/sites/sitename?amsiscantest:x5opap4pzx54p7cc7-standard-antivirus-test-fileh+h*
Cheers,
Stefan
Permalink
That worked! thanks a lot Stefan.
Sounds obvious when someone tells you.
Peter
Permalink
Hi Stefan,
We’ve installed the July 2025 CU for SharePoint Server SE (KB5002768)
and configured AMSI in Full mode using:
$webApp.AMSIBodyScanMode = 2
We’re now trying to validate that AMSI integration with Windows Defender is functioning properly.
To simulate a detection, we used the Microsoft-provided EICAR-style test string from official documentation. Example:
https://webappurl/sites/site1?amsiscantest:x5opap4pzx54p7cc7$eicar-standard-antivirus-test-fileh+h*
However, we do not see any detection in Windows Defender logs:
Event Viewer > Applications and Services Logs > Microsoft > Windows > Windows Defender > Operational
No Event ID 1116
No detection name like Exploit:Script/SharePointEicar.A
Questions:
Is there an official or supported method to simulate an AMSI detection for SharePoint (e.g., test page, payload)?
Should we expect to see Defender events when using the EICAR-style string via HTTP?
Is there a way to confirm that AMSI is actively scanning IIS (w3wp.exe) in the SharePoint context?
Thanks in advance for your support.
Best regards,
Permalink
Hi Philippe,
please verify if AMSI is working on the machine from an OS level.
To do this execute the following command in a PowerShell window:
AMSI Test Sample: 7e72c3ce-861b-4339-8740-0ac1484c1386
Cheers,
Stefan
Permalink
Hi Stefan.
First of all, thank you very much for your support!
We were able to patch in time, but we’re seeing constant attacks targeting the ‘ToolPane.aspx’ page, which is concerning. Like others, we’d prefer to temporarily block access to this page. Do you know what this page is used for in SharePoint? (Maybe the ToolPane when editing webparts?)
Regards,
Johan
Permalink
Hi Johan,
to determine impact of blocking this would require more research.
Please open a ticket with Microsoft to get this investigated.
Cheers,
Stefan
Permalink
We have blocked ToolPane.aspx since yesterday, no issues reported so far. As there any other known “entry point” we could block?
Permalink
Thanks for the reply.
We also has blocked the Toolpane.aspx page and no issues have been reported. Since then, Defender has detected no further attacks.
Permalink
Hi once more.
Re. Sharepoint 2019
I’m currently installing patches (KB5002753/KB5002754) on a SP2019.
Should I be worried if the Security menu in CentralAdministration does not contain AMSI at all.
( The farm has previously had the AMSI disabled with the disable-spfeature (Due to performance issues))
If I try to reverse that action (after installing Juli2025 patch) – the response is:
” Feature ‘antimalwarescan’ is already activated at scope ‘the web application URL, you’ve just entered’ ” ?
Also, the SP2019 CentralAdmin -> Monitoring -> TimerJobDefinitions does not contain the timerjob for MachineKey, is that expected? (Should it still be “set”, the key.
But solely doable with powershell ( Set-SPMachineKey )?
Thanks
Permalink
Hi Brian,
no you don’t have to be worried. In earlier versions of SharePoint please use PowerShell.
Yes, please use PowerShell for the machine key rotation.
Cheers,
Stefan
Permalink
Hi, I have installed the latest KB for SharePoint Subscription Edition. When rotating the key via Central Administration > Monitoring > Machine Key Rotation Job, nothing happens. I’ve click “Run Now” maybe like 10 times now and nothing happens. If I use PowerShell, it works.
Any idea what’s causing this?
Permalink
Hi Joshuaa,
in this case please use the PowerShell command (Set-SPMachineKey -WebApplication https:/…) to rotate the machine keys.
Cheers,
Stefan
Permalink
Thank you! To clarify, if I have an extended web application, I just use Set-SPMachineKey on the default zone only?
Permalink
Hi Joshuaa,
depends. If the web application has been extended to other zones (means that a different IIS website backs it) then you need to do it for all of them as the have different web.config files which need a new machine key.
Cheers,
Stefan
Permalink
Hi Stefan,
Thank you but it seems like running Set-SPMachineKey for the default zone also changes the extended zones. I compared the web.config’s before and after values.
Permalink
I witnessed something slightly different. Set-SPMachineKey updated web.config of the extended web app according to the timestamp of the file, but it didn’t actually update the key values in the file. Had to run Update-SPMachineKey -Local to update the values (and applied iisreset). Regardless, activating AMSI gave a 500 error on the extended web app unlike the one for the default zone, which worked fine. Had to deactivate AMSI to restore.
Permalink
Hi Sam,
the 500 server error only on the extended web app is weird.
Enabling AMSI added an entry in the web.config to reference the SPRequestFilteringModule that is defined in the applicationHost.config.
We have seen 500 server issues here if the applicationHost.config is missing – but this would affect ALL web application on all zones where AMSI is enabled and not just some.
So here we seem to have a different error.
I would suggest to check the ULS log for the details of the exception.
Cheers,
Stefan
Permalink
Should we expect a language pack update for SPSE?
Permalink
Hi Donald,
SharePoint Server Subscription Edition uses Uber packages where language dependent and independent fixes are in the same package.
With other words: the fix documented in the CVE includes also the updates for the language pack.
Cheers,
Stefan
Permalink
hi Stefan
I have just upgraded my SP 2016 farm to KB5002759 & KB5002760 after my IT SEC team chased us
In future, how do I know when these urgent security fixes are released by Microsoft?
As these are not listed in the usual SharePoint update history page?
https://learn.microsoft.com/en-us/officeupdates/sharepoint-updates#sharepoint-2016-update-history
Thanks
Permalink
Something, that should be mentioned among all of these comments:
THANK YOU STEFAN FOR THE TREMENDOUS SUPPORT AND EFFORT IN THIS SITUATION.
YOU ARE AWESOME!
(by the way, do we reach the comments limit of a WordPress blog post soon? 🤔
Permalink
Thanks Christian!
No idea if there is a comment limit in WordPress. 😀
Permalink
I agree! Stefan, you rock! 😀👍 Microsoft can’t pay you enough!
Also, your blog is an essential communication channel between Microsoft and Microsoft’s SharePoint customers. What would we do without it?!
Permalink
We would be all looking into getting out of SharePoint and MS would lose thousands of big clients on the following weeks. That is what would happen if it wasn’t for Stefan.
As that guy said, “Microsoft can’t pay you enough!”
Permalink
😂😂😂
Permalink
After updating to KB5002768 (SPSE), the “Highlighted Content” web part has stopped working on our existing sites (whole site stopps working). However, if we add a new instance of the web part to a site, it works as expected. Is there a known fix/does anyone else have the same issue?
Permalink
Hi Daniel,
I haven’t seen this issue.
My suggestion would be to open a ticket with Microsoft support go get this investigated.
Cheers,
Stefan
Permalink
So as mentioned we’ve installed the updates, rotated asp.net keys, AMSI is installed, we see the typical quarantined entries in defender for AMSI.
We see entries like this in the IIS logs on the webservers… we do NOT have SPinstall0.aspx on any of our sharepoint servers. Are these just attempts by bad actors or should be be concerned?
http://contoso.com/_layouts/15/spinstall0.aspx 401 0 0 43
2025-07-22 12:10:39 GET /_layouts/15/spinstall0.aspx – 443 – Go-http-client/1.1 – 401 0 0 52
2025-07-22 12:13:34 GET /_layouts/15/spinstall0.aspx – 443 – Go-http-client/1.1 – 401 0 0 52
Thanks for your help!
Permalink
This is an attempt to attack the server.
The attacker assumes here that the file was already created earlier through the exploit.
Permalink
After you Set-SPMachineKey and Update-SPMachineKey on the 1st application server and reset IIS then move on to other servers in the Farm do you need to do Update-SPMachineKey on the other servers as well?
What I have for CVE July 2025 patching is this:
Rotate Keys
Reset IIS
Install STS patch
Install WSS patch
Rotate Keys
Reboot Server
Run Products and Config Wizard on each machine after patches are deployed
Reboot Server
Cheers
Permalink
Hi Noral,
Update-SPMachineKey should not be required.
Set-SPMachineKey sets the new key on all machines.
Only in the unlikely event that the new machine key does NOT get replicated to some machines in the farm Update-SPMachineKey would be helpful.
In this case execute it on the machine where the new key was not updated with the -Local parameter. This pulls the new machine key from the config DB and updates the local web.config file.
Cheers,
Stefan
Permalink
Cheers – thank you Stefan
Permalink
We have applied the required updates and have AMSI installed and running as well as rotated the asp.net keys. We are seeing the expected quarantine alerts in AMSI/defender, and confirmed no new aspx files after July 18th, including no spinstall0.aspx. We are seeing IIS log entries like below, i’ve changed the URL name and removed our internal IPs for security purposes:
http://contoso.com/_layouts/15/spinstall0.aspx 401 0 0 43
2025-07-22 12:10:39 GET /_layouts/15/spinstall0.aspx – 443 – Go-http-client/1.1 – 401 0 0 52
2025-07-22 12:13:34 GET /_layouts/15/spinstall0.aspx – 443 – Go-http-client/1.1 – 401 0 0 52
Is this something we should be concerned about? As I mentioned the file spinstall0.aspx is not on any of our sharepoint servers. Just a bad actor trying to poke around?
Thanks for your help!
Permalink
i tried to go to a fake page I called “mike.aspx” to see the behaviour in the log files and see the same type of entry. Safe to say just bad guys knocking on the door like we see in the AMSI logs?
Permalink
Just a heads up about the machine key process:
I just realized how unreliable the Set-SPMachineKey command is, thanks to Varga Gábor’s brilliant script for reading machine keys (see above). At least in our environment, after waiting 20 minutes, only half of our ~10 webapps had new keys in their web.config files, even on the server where I ran the command.
So we had to run the Update-SPMachineKey on all servers, which I did according to previous comments (including Stefan’s addition of -Local).
Permalink
We are fully patched, have AMSI, and our environment is behind Microsoft Enterprise private network connector (app proxy), and we’re still seeing detections. No one else has mentioned being behind an app proxy and seeing attacks still. That is very confusing. Any thoughts?
Permalink
Hi Chris,
yes – the detections mean that AMSI is working and is successfully deflecting the malicious requests using your AV solution.
See here for more details:
https://blog.stefan-gossner.com/2025/07/23/clarifying-common-questions-around-amsi-in-sharepoint/
Cheers,
Stefan
Permalink
I suppose the confusion on our part is how this is even reaching our machine, given that we’re using a Microsoft Entra private network (app proxy). If you browse to the URL of our SPSE, you are instantly redirected to a Microsoft login prompt. This must mean that the app proxy isn’t truly in front of the environment; it must first hit the WFE and then redirect.
Permalink
How do we know what file to look for exactly? I see a lot of JavaScript files that were created on 20th July 25. Names Like SP.JS, callout.js, SP.Runtime.JS, AddGallerx.xap. Some .ascx files. There are ~300 files with that creation date. No new .aspx files
We already installed the KB Patches and rotated machine keys.
Permalink
Hi René,
the file you mean come from the SharePoint patch you installed.
All have the same date and time.
So the file needs to have a different timestamp from the regular SharePoint files created by the patch – if it exists at all.
Cheers,
Stefan
Permalink
Hello there fellow members of this amazing community, I have a SP2016 farm with 10 WFE, with 10 WebApps a default zone and a extend zone, my question is.
After running Set-SPMachinekey on every WebApp, the machinekey entry on web.config must be identical fon every server? Ex:
#1Webapp on WFE 1 – Machinekey: xxxxxxXPTA02
#1Webapp on WFE 2 – machinekey: xxxxxxXPTA02
#2Webapp o. WFE 1 – Machinekey: xxxxxxGT157K
#2Webapp o. WFE 2 – Machinekey: xxxxxxGT157K
This is correct?
Or machinekey must be random on all WFE and WebApp?
Thanks in advance!
Permalink
Hi Allen,
the machine key in the web.config for each web app needs to be identical – otherwise you would run into problem as soon as the load balancer redirects requests from the same user to different machines.
The machine key of different web application on the other hand should be different.
Cheers,
Stefan
Permalink
Allen
Take a look at this comment – https://blog.stefan-gossner.com/2025/07/21/important-active-attacks-targeting-on-premises-sharepoint-server-customers/#comment-37691
That will help you.
Permalink
If you’re using SCOM in your environment, it will generate an error if the web.config files are not identical across all SharePoint servers hosting the same web application.
This way, you can also quickly see which servers have no Machine key’s synced.
Permalink
Hello Stefan,
I got an infra-SharePoint 2019; I patched it with both KB ( KB5002754 and KB5002753 ) and already rotated keys. unfortunately, We cannot see the left navigation menu, cannot create and edit a new page ( modern ) cannot access site information’s from top right wheel neither.
I see in the blog that some similar cases have been created and escalated to Microsoft engineer to fix this issue, do you have a statement on that ?
Thanks in advance.
Permalink
Hi Adrien,
in case that side-by-side patching is enabled, please disable it and test again.
One user here in the chat reported that it solved the issue which would mean an inconsistency in the side-by-side directory.
Cheers,
Stefan
Permalink
Can confirm, disabled SideBySide and ran IIS reset of web front end machines fixed the issue, just as with Maurice above.
NOTE: IISRESET is REQUIRED after disabling SBS. Confirm via Dev Tools to show the .js pages loading directly from _layouts rather than _layouts//.
Since attacks were shown to compromise the _layouts folder for those attacked, assuming MS broke SBS tokens with the Machine key update?
Permalink
Hi Janey,
it is not yet clear what happend on the affected machines.
Best would be to open a support case to get this investigated as side-by-side patching is supported and recommended.
Cheers,
Stefan
Permalink
Hi Stefan,
What is the process (Powershell commands and steps) for rotating the keys for a SharePoint 2016 farm using two WFE and two App servers?
Thanks!
Permalink
Hi Drake,
it should be sufficient to execute the following PowerShell command on any of these servers:
Set-SPMachineKey -WebApplication https://url-to-webapp
In rare cases it happend that the new machine keys did not replicate automatically.
In this case open a PowerShell window on the machine where the new machine key has not arrived and execute the following command:
Update-SPMachineKey -WebApplication https://url-to-webapp -Local
This will replicate the new machine key from the config database to the local server
Cheers,
Stefan
Permalink
HI, there has been a lot of chat on AMSI rotating keys. Just to be sure, we have On-prem 2019 installed. We applied the July patches and KB5002754. We also ran psconfig after patching. Do we need to enable AMSI or rotate the machine keys.
Permalink
Hi Elizabeth,
if you installed KB002754 you should also install KB002753.
If these two fixes are installed AMSI is recommended but not required.
But machine key rotation after the fixes are installed is critical to protect your servers.
Cheers,
Stefan
Permalink
Per your previous post, KB002753 is not required and that we can wait till the August patch since it address the modern UI issue which we do not encounter. Please confirm.
Thank you, Elizabeth
Permalink
Confirmed. 😊
Permalink
Hi all,
I have added a summary of our discussion above in the blog post.
Please let me know if additional information is needed.
Thanks,
Stefan
Permalink
After running all these steps I can see that machinekey for the normal webapplications is identical on all app and wfe servers.
Only the machinekeys of Central Admin webapps seem to differ in my two App servers which are hosting Central Admin. Same situation in my TEST environment.
Is this normal or should they also be identical?
Permalink
Following the application of both of the patches on our SP2019 farms, we have noticed an issue when creating a new Site Page.
Farm 1 – unable to name the page – can add Quick Links web part – can add link
Farm 2 – can name page – can add Quick Links web part – unable to add link
We also have two staging farms at the same patch level, with no issues?
Has this issue been identified by anyone else?
Thanks
Permalink
Hi Stefan,
our workflows do not work after applying kb KB5002768, ULS contains:
Block the namespace: clr-namespace:System.CodeDom;Assembly=System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, type: CodeBinaryOperatorExpression
Potentially malicious xoml node…
RunWorkflow: System.InvalidOperationException: This feature has been temporarily disabled….
Do you have a solution? (?web.config?)
Thanks
Permalink
Hi Milan,
sounds as if the servers haven’t been patched for a long time.
This sounds like a side effect of a security fix introduced in September 2024 CU.
https://blog.stefan-gossner.com/2024/12/11/resolved-trending-issue-problems-with-workflows-after-applying-september-2024-cu-for-sharepoint-2016-2019-se/
Cheers,
Stefan
Permalink
Great, it worked, thank you very much!!! One line from the link was missing in my webconfig, or rather it was for individual typenames, not for “” (authorizedType Assembly=”System, Version=4.0.0.0…TypeName=”“….)
Permalink
After installing this security update for Subscription Edition, OIDC authentication will not work anymore. Tested on two farms. Seems that there’s a problem on getting certificate after completion of idp signin.
This happen in “/_trust/default.aspx” and the error is
“System.InvalidOperationException: Operation is not valid due to the current state of the object.”
related to
Microsoft.SharePoint.IdentityModel.<…>.GetCertificateOrThrow
Any advice?
Permalink
Problem solves. The nonce certificate was expired in 2024. Probably prior to this patch the expired date was not checked. Updated the certificate and everything is now working as expected.
Permalink
Hi Stefan,
our workflows do not work after applying kb KB5002768. Do you have a solution? (web config?)
Thanks
Permalink
If we patch before cycling machine keys – as long as we cycle afterwards, we’re good right?
(We’re getting told we must cycle them AGAIN even though we patched and cycled, because CISA guidelines say “twice”…. )
Permalink
Hi Brian,
you can rotate as often as you like – but the rotation AFTER the fix install is the most important one and only one rotation is required.
Important is that the machine keys are different from those before the fix was installed.
Cheers,
Stefan
Permalink
Thank you for the clarification on the machine key rotation process, as the existing documentation is extremely lacking and unclear. The process that we followed seems to generally align with your process. But I do have some questions for clarification:
The machine key rotation instructions reference a timer job, which is not present in our SP 2019 on-prem environment. Is that expected? Since it was not present, we opted to rotate keys via PowerShell, based on our limited understanding of the instructions.
We have 4 web applications (Get-SPWebApplication) and Central Administration is NOT listed among them. Therefore, we didn’t perform the machine key rotation against CA. So we will take care of CA today. Since the initial machine key rotation, our workflows have been broken. Is this expected if we overlooked the machine key rotation on CA?
Your instructions state that “the command has to be executed against all extended endpoints of the web application”. I’m not sure what “extended endpoints” means – does that mean all of the sites/subsites under the web application – as those are the endpoints?
@Varga Gábor thank you for the script to verify machine keys. As we were rotating keys the other day, I found it surprising that there isn’t already a built-in command to view the keys.
Permalink
Hi Dan,
yes – the article is not very clear here. The specific timerjob mentioned here does not exist in SP2016 and SP2019.
The recommended way to rotate the keys here is to use the Set-SPMachineKey PowerShell command.
Yes – rotation of the central admin website is also strongly recommended.
About the extended endpoints: This is the additional IIS web site(s) the web application was extended to (if any).
When you have a SharePoint web application you can extended it to a different IIS website with different hostname or different port or similar – e.g. to have one zone supporting SSL and the other not. I was referring to these IIS web sites as endpoints.
Each of these IIS website contain a different web.config file with machine keys that need to be rotated.
Please let me know if that answers your questions.
Cheers,
Stefan
Permalink
A great big THANK YOU to Stefan Goßner!
Without your invaluable help (and so many hours you have fought!), I’d be kind of lost on the shredded Sharepoint fields with this hiccup on SE/2019 versions.
The recent (last?) thing I found is a Sharepoint SE farm, updated and reboted, And Set-SPMachinekey -WebApplication URL.To/WebApp run with no errors. However I can’t see the keys anywhere in either web.configs on any of the servers.
Since the servers are not online/public here, I am fairly calm, but IF you have suggestions on what to check, I’d love to hear them.
E.g. any requirements to do before those keys is correctly written to web.config by set-spmachinekey ??
(Server works just as well as before the update was initiated)
(The CA server web.config DO actually have the various validationkey strings that the script (the script in the blog) checks for, but they are empty. And the Frontend server does not have any of the strings the script searches for. And I am pretty certain I have found the correct web.config file)
Permalink
Hi Brian,
its hard to analyze this using just this discussion here in the blog.
My suggestion would be to open a support ticket with Microsoft to ensure that an engineer can look into this specific issue.
Cheers,
Stefan
Permalink
I am trying to rotate my machine keys. Support said to run a script on where the central admin is hosted. I get the error web configuration file has no system.web section. I can run the Set-SPMachineKey from my web server with no issues.
Since support has not come back and I really need to protect my prod servers, can you tell me if I can run Set-SpMachineKey and later $update-SPMachineKey from my web server. IIS Reset after. If so I assume if I have multiple web servers I can run it only in one?
Appreciate any insight
Permalink
Hi Elizabeth,
yes it should be possible to run Set-SPMachineKey and later run Update-SPMachineKey -Local on the central admin server.
Cheers,
Stefan
Permalink
Sorry but I am not familiar with rotating machine key and articles I read confuse me even more. If I have
– Web1
– Web2
– App1 (central admin is hosted here)
– App 2
I can run Set-SpMachineKey from Web1r and not the other servers. This will protect all my servers. Later when support helps me figure out why I cannot run set or update from App1, I can run Update-SPMachineKey -Local.? This will not have any impact even if it is days before I can run Update-SPMachineKey -Local.?
I appreciate your input.
Permalink
Elizabeth:
Disclaimer – Use at your own risk. This worked in my development environment.
I have 7 server in our SP 2016 Farm and here is how I did it, from MY perspective:
On the Central Admin Server:
Check “C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\TEMPLATE\LAYOUTS” for any files created in the last few weeks. If compromised you will need to rebuild the server. Contact MS Support!
Then I ran the following PowerShell Script:
*** Start Script
MS Recommends running this Pre and Post installing the patches
Add-PSSnapin Microsoft.SharePoint.Powershell
Get-SPWebApplication -IncludeCentralAdministration | ForEach-Object {
Write-Host “Updating machine key for $($.Url)”
Set-SPMachineKey -WebApplication $
Update-SPMachineKey -WebApplication $_
}
Restart-Service W3SVC
*** End Script
Now we need to get the machine keys for the Web Apps to compare with the other servers:
Run the script provided by “Varga Gábor”:
*** Start Script
*** Copy this output to compare to other SP Servers
Add-PSSnapin Microsoft.SharePoint.Powershell
Clear-Host
$webApps = Get-SPWebApplication -IncludeCentralAdministration
foreach ($webApp in $webApps) {
$configPath = $webApp.IisSettings[“Default”].Path
if (Test-Path $configPath) {$webConfigPath = Join-Path $configPath "web.config"
if (Test-Path $webConfigPath) {
[xml]$xml = Get-Content $webConfigPath
$machineKey = $xml.configuration.'system.web'.machineKey
if ($machineKey) {
Write-Host "Web App: $($webApp.Url)"
Write-Host " ValidationKey: $($machineKey.validationKey)"
Write-Host " DecryptionKey: $($machineKey.decryptionKey)"
Write-Host " Validation: $($machineKey.validation)"
Write-Host " Decryption: $($machineKey.decryption)"
Write-Host ""
} else {
Write-Host "Web App: $($webApp.Url) – No <machineKey> section found."
}
} else {
Write-Host "web.config not found for $($webApp.Url)"
}
} else {
Write-Host "IIS Path not found for $($webApp.Url)"
}
}
*** End Script
Install sts2016-kb5002760-fullfile-x64-glb.exe (Do not reboot if prompted)
Install wssloc2016-kb5002759-fullfile-x64-glb.exe (Do not close – require reboot if prompted)
Then I again ran the following PowerShell Script:
*** Start Script
MS Recommends running this Pre and Post installing the patches
Add-PSSnapin Microsoft.SharePoint.Powershell
Get-SPWebApplication -IncludeCentralAdministration | ForEach-Object {
Write-Host “Updating machine key for $($.Url)”
Set-SPMachineKey -WebApplication $
Update-SPMachineKey -WebApplication $_
}
Restart-Service W3SVC
*** End Script
Reboot the Server
DO NOT RUN PRODUCTS AND CONFIGURATION YET!
For the rest for the servers us this procedure:
Check “C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\TEMPLATE\LAYOUTS” for any files created in the last few weeks. If compromised you will need to rebuild the server. Contact MS Support!
Then I ran the following PowerShell Script to get the Machine Keys:
NOTE: Servers with the Role of Index Server will not return any machine keys – this is normal
*** Start Script
*** Copy this output to compare to other SP Servers
Add-PSSnapin Microsoft.SharePoint.Powershell
Clear-Host
$webApps = Get-SPWebApplication -IncludeCentralAdministration
foreach ($webApp in $webApps) {
$configPath = $webApp.IisSettings[“Default”].Path
if (Test-Path $configPath) {$webConfigPath = Join-Path $configPath "web.config"
if (Test-Path $webConfigPath) {
[xml]$xml = Get-Content $webConfigPath
$machineKey = $xml.configuration.'system.web'.machineKey
if ($machineKey) {
Write-Host "Web App: $($webApp.Url)"
Write-Host " ValidationKey: $($machineKey.validationKey)"
Write-Host " DecryptionKey: $($machineKey.decryptionKey)"
Write-Host " Validation: $($machineKey.validation)"
Write-Host " Decryption: $($machineKey.decryption)"
Write-Host ""
} else {
Write-Host "Web App: $($webApp.Url) – No <machineKey> section found."
}
} else {
Write-Host "web.config not found for $($webApp.Url)"
}
} else {
Write-Host "IIS Path not found for $($webApp.Url)"
}
}
*** End Script
Compare with out put from Central Administration Server. If they are different then run this script:
*** Start Script
Get-SPWebApplication -IncludeCentralAdministration | ForEach-Object {
Write-Host “Updating machine key for $($.Url)”
Update-SPMachineKey -WebApplication $ -Local
}
Restart-Service W3SVC
*** End Script
Install sts2016-kb5002760-fullfile-x64-glb.exe (Do not reboot if prompted)
Install wssloc2016-kb5002759-fullfile-x64-glb.exe (Do not close – require reboot if prompted)
DO NOT RUN PRODUCTS AND CONFIGURATION YET!
Reboot the Server
After all servers are patched and rebooted continue as you would with any other patch:
Run Products and Configuration Wizard on the Central Admin Server – personally reboot the server again.
Run Products and Configuration Wizard on all the other servers one server at a time.
Lastly, Windows Server 2012 R2 CANNOT USE AMSI or you will get 500 errors!
Run this script ONCE on any SP Server to enable AMSI on NON-Windows Server 2012 R2 SP Servers:
*** Start Script
Add-PSSnapin Microsoft.SharePoint.Powershell
Clear-Host
Get-SPWebApplication -IncludeCentralAdministration | ForEach-Object {
Write-Host “Enabling AMSI for $($.Url)”
Enable-SPFeature -Identity 4cf046f3-38c7-495f-a7da-a1292d32e8e9 -Url $.Url
}
*** End Script
I happen to be server reboot happy and rebooted all the servers in the Farm again.
Follow these links for testing AMSI – the 2nd link is more though IMHO:
https://blog.stefan-gossner.com/2025/07/23/clarifying-common-questions-around-amsi-in-sharepoint/
https://www.blackhillsinfosec.com/is-this-thing-on/
Again disclaimer – Use at your own risk. This worked in my development environment.
Permalink
Hi Noral,
I really appreciate the time you took to help. My issue is I am getting an error when I run
Set-SPMachineKey -WebApplication $
Update-SPMachineKey -WebApplication $_
on the app server that runs Central admin. The error I get is The web configuration file, , has no system.web section or more than one system.web sections. I checked the web.config and do not see the issue.
I can run
Set-SPMachineKey -WebApplication $
Update-SPMachineKey -WebApplication $_
from my web server so am not sure if that is sufficient since what I read is that I have to perform this from my app server.
It was also not clear if I have to run
Set-SPMachineKey -WebApplication $
Update-SPMachineKey -WebApplication $_
from all servers in the farm.
What I can try is what you suggested and go to each server and run “Varga Gábor”’s script to see if the keys match, including the one from the app server.
Thanks again for putting so much effort in helping me.
Permalink
Hi Elizabeth,
I think that’s the way to go. And to be sure it’s good to login to each IIS server/ Application Server and Web Front End to do the iisreset and check if the web.config file has been updated.
So I suggest (please check scripts before running them):
Log the current machine keys for each web application from an AS server. This will give you a baseline to compare against after the update.
Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue
$webApps = Get-SPWebApplication
foreach ($webApp in $webApps) {
$configPath = $webApp.IisSettings[“Default”].Path
if (Test-Path $configPath) {
$webConfigPath = Join-Path $configPath “web.config”
if (Test-Path $webConfigPath) {
[xml]$xml = Get-Content $webConfigPath
$machineKey = $xml.configuration.’system.web’.machineKey
if ($machineKey) {
Write-Host “Web App: $($webApp.Url)”
Write-Host ” ValidationKey: $($machineKey.validationKey)”
Write-Host ” DecryptionKey: $($machineKey.decryptionKey)”
Write-Host ” Validation: $($machineKey.validation)”
Write-Host ” Decryption: $($machineKey.decryption)”
Write-Host “”
} else {
Write-Host “Web App: $($webApp.Url) – No section found.”
}
} else {
Write-Host “web.config not found for $($webApp.Url)”
}
} else {
Write-Host “IIS Path not found for $($webApp.Url)”
}
}
2. Manually check some web.config files on you servers to confirm the script has indeed retrieved the correct keys + see that they are in sync (they are, but it’s good for verification).
3. For each web application: set a new key and push it to all web.configs. You should only need to run this from one server (could be the one hosting Central Administration or an AS). The update command should trigger SharePoint to update the webconfigs on other servers.
Add-PSSnapin Microsoft.SharePoint.PowerShell
$webApps = Get-SPWebApplication
foreach ($webApp in $webApps) {
Set-SPMachineKey -WebApplication $webApp.Url
Update-SPMachineKey -WebApplication $webApp.Url
}
4. Run script 1 again and check if the values for all web applications have changed.
5. Log in to each IIS/AS and WFE server to perform an iisreset (IMPORTANT) and manually check if the web.config was indeed updated with the new keys (modified date is a good indicator, but best to open it and check the values).
PS don’t forget to iisreset the server on which you ran the update script.
Permalink
Hi Emiel,
Thanks for the detailed explanation. I did a variation of what you said and it works.
1) set and updated CA machine key from CA server
2) set and updated web application key from 1 web server
3) run iisreset on all
4) checked the keys on all servers – the CA key was visible on app server hosting CA. The web servers all had the same keys for web application.
5) application came up and tested a few functionalities successfully
I do have to check the test CA server web.config and compare to prod due to the error message in test.
thanks again!
I am glad this blog exists. It is good to hear so many experiences and see the community helping each other.
Have a great weekend
Elizabeth
Permalink
Hi Stefan, customer is observing issues after installing the patches. I can confirm the both patches were installed, wizard was ran and everything was followed as descibed.
The issue is while editing pages. I am sure it is not permissions issue, it looks more like a broswer issue, but they tried several browsers and the issue raised after the installation.
Someties the EDIT button on a page is missing. Even refreshing page does not help.
If a user is able to EIDT a page, while editing the page the users does not see all WP components correctly, and e.g. the main banner picture cannot be changed, becuase the control i snot working (users are clicinkg and clicking and nothing happens).
When the user is editing same page directly on a SharePoint Server (using a same user account), they are sucessfull. Other user (e.g. me – nut I am admin) does not see these issues.
There is no side-by-side patching enabled so no more than one folder in TEMPLATES.
Customer is on a latest patch level.
Any idea? Thank you
Permalink
Hi again, it looks like it is due to the CZECH language used in a browser. When I am using US language, it’s ok. When switching to CZ, I see described issues.
So it looks like a bug in a CZ language pack in last CU (maybe the last but one also)!
If you can confirm by yourself this is the issue, could you please ask PG to repair upcoming langpack?
Permalink
I can confirm the same issue and root cause as reported by Jakub. When Czech is set as the preferred language in the browser (Edge or Chrome), it causes the reported issues on modern SharePoint sites. Switching the browser’s preferred language to English resolves the issue by preventing SharePoint from using the language pack. We are running SharePoint 2019 with both KB5002754 and KB5002753 installed.
Permalink
Hi Jakub and Michal,
it is possible that there is a problem with the updates to the czech files in the fix.
Please open a support case specifying this specific issue and that it is related to the czech language pack to allow us in support to confirm this in a repro and raise the issue with our product group.
Cheers,
Stefan
Permalink
Hi Stefan,
thanks for your quick response. The support case has been opened.
Permalink
Hi Jakub,
did you test with in-private browsing? Just to be sure that no older cached content is causing a problem.
Cheers,
Stefan
Permalink
Yes, we did. The behavior is same as Michal described. Thank you, Jakub
Permalink
Morning Stefan,
I am hoping you could help with my question below.
In light of the attack, our team have applied the patch and rotated the machine keys as advised by Microsoft’s recommendation from the article you have shared. After that we scanned the files in our SharePoint web servers and noticed that the .JS files under the 16 hive PROGRAM FILES\COMMON FILES\MICROSOFT SHARED\WEB SERVER EXTENSIONS\16\TEMPLATE\LAYOUTS have the modification timestamp of July 20, 2025.
The modification date aligns closely with the active exploitation window (July 18-22, 2025). Is this something we should be concerned about?
Thanks.
Permalink
Hi Phu V. Huynh,
these are most likely the files that got installed by the security fix.
The SharePoint security fixes have install several hundred files (e.g. SP.JS, SP.Runtime.JS, AddGallery.xap).
These files and others with identical timestamp are part of the security fix and should be excluded from your checks.
Cheers,
Stefan
Permalink
Thanks very much!
Permalink
Hi again
I have stumbled over this, more generic Sharepoint issue that hinders successful install of the patches in one of our SP2019 farms.
It is pretty obvious what causes it – “somebody has set an acount somewhere in Sharepoiint/SQL-database/TimerJobs- and then somebody else have gone and deleted that account from the Active Directory, with no word of it to us… (No idea when the account went away, and SP can restart fine, without this account present?)
So Patch installs went fine, and then “Configuration Wizard” on the first of the farm servers came almost to the end, and then failed like follows:
Failed to upgrade Sharepoint Products:
This is a critical task. You have to fix the failures before you can continue. . . .
Upgrade [SearchAdminDatabase Name=SCOR_Search] failed.
Exception: Windows NT user or group ‘domanname\accountname’ not found. Check the name again.
Upgrade Timer job is exiting due to exception: System.Data.SqlClient-SqlException (0x80131904) . .(user not found) . .
I have aborted installation and rolled back, because noone was around to restore the delete AD account, to let us finish the config.
The Farm is restored to it previous old glory, and I have tried to find (in Central Admin) where that now missing account is mentioned, but I fail miserably.
Can someone possibly suggest where you’d go, in SP CentralAdmin to check and possibly change the account presence to another more suitable (preferably exisiting 😉 )
Permalink
we also found a very similar error on a bunch of administrative pages after applying the patch:
Method not found: ‘System.Data.SqlClient.SqlCommand
Microsoft.SharePoint.Utilities.SPSqlCommand.op_Implicit(Microsoft.SharePoint.Utilities.SPSqlCommand)’.
Running the Grey (Config) wizard instead of using PowerShell and everything started working again.
My full write-up of this issue and our solution:
https://rnitfactor.blogspot.com/2025/07/2025-zero-day-sharepoint-patch-gotcha.html
Permalink
Hi Rob,
the blog post is not completely correct. The change from System.Data.SqlClient to Microsoft.Data.SqlClient happend in Feature update 25H1, released March 2025 and was documented here:
https://learn.microsoft.com/en-us/sharepoint/what-s-new/new-and-improved-features-in-sharepoint-server-subscription-edition-25h1-release#new-database-connectivity-layer-with-tds-80-and-tls-13-support
Cheers,
Stefan
Permalink
Thank you for the info. Updating my post.
Permalink
Hi Stefan, we have patched our systems and made the additional changes as noted. We did not see any IOC’s on our servers such as the spinstall0.aspx files or similar. Are you or others seeing any evidence of systems that were compromised and the file(s) mentioned were there at one time and then got deleted post exploit?
Permalink
Hi Jay,
sorry – this is a question I cannot answer.
If you are concerned your system might have been exploited, please open a support ticket with Microsoft.
We have a dedicated team for such type of questions which can assist you.
Cheers,
Stefan
Permalink
Hi Stefan,
Do you expect if the build version of SP19 in add/remove programs should be updated and match the SPFarm version once the relevant security patches for this vulnerability are installed and all steps are followed?
We are seeing that (GET-SPFarm).Buildversion shows build 10417, revision 20037, whilst Add/Remove Programs Microsoft Sharepoint Server 2019 still states 16.0.100337.12109.
Just wondering if we might have missed a step…
Permalink
Hi EasyRider,
please check in control panel / installed updates.
You should find the two fixes you installed with version 16.0.10417.20037.
Cheers,
Stefan
Permalink
Thank you Stefan. Yes those are installed! My ask is specific to the build version in add/remove programs please. I am just wondering if we are expected to see the build version of Sharepoint Server in add/remove programs to be ‘changed/updated’ as a result of installed updates.
Thanks again
Permalink
Hi Easyrider,
yes – that is expected. The based product version does not change.
To see the installed updates you need to look at the installed updates page.
And btw: SPFarm.BuildVersion is not a good way to check if a fix has been installed. As not all fixes modify it and if modified might be to a different version than you expect.
See here for details and the correct way to check for installed updates and version information:
https://blog.stefan-gossner.com/2016/08/23/sharepoint-does-not-have-a-build-version-full-stop/
Cheers,
Stefan
Permalink
the Server restart during installation update after that when i install update I face this message “The installation of this package failed” I can’t uninstall or install the update, also configuration wizard faild to run
Permalink
Hi Abdullah,
I would suggest to check in the Windows installer log to see what problem occurred.
It should be located in the temp directory in subdirectory named “1” or “2”.
Cheers,
Stefan
Permalink
Our SPS 2019 farm is now patched and restarted as you instruct. Our farm is isolated from Internet – Will an intruder still be able to execute powershell scripts on it?
Permalink
Hi Goran,
as long as the machine keys in all web.config files were rotated after the fix was installed your machine will be secure.
Cheers,
Stefan
Permalink
We have followed the steps for rotating the machinekeys, but for some reason, the machinekey for a given web application is different when comparing two different servers that hold the same role/webapp.
What is weird is that when running the Get-SPWebApplication | foreach { Update-SPMachineKey -Local -WebApplication $_ } command, the keys ARE updated, but not with the same key as on the server we executed Set-SPMachineKey on. It appears that Update-SPMachineKey generates a new random key instead of fetching the key from the Configuration Database. Which it shouldn’t according to the information in this blog.
We don’t have a single machinekey that is identical on any of the servers in the farm.
We are running Sharepoint SE (on two WF, two app servers and two search servers)
Permalink
Hi Björn,
it sounds to me as if Set-SPMachineKey did not update the new machine key in the configuration database.
Because Update-MachineKey -Local only pulls the information here and updates the local web.config file.
My suggestion would be to repeat Set-SPMachineKey on one of the other machines (hoping that it will be able to write to the config database) and then run Update-SPMachineKey -Local on all the others.
If that does solve the issue my recommendation would be to open a support case with Microsoft to get this investigated.
Cheers,
Stefan
Permalink
Thank you for incredibly swift response!
Just to clarify, when I refer to the machinekey, I was referring to it’s ciphervalue.
Do I need to decrypt the ciphervalue in order to properly compare the machinekey, or will the ciphervalue be identical for the same machinekey on two different servers?
The machinekey is protected with the DataProtectionConfigurationProvider.
If I, on the same server, repeat the update-machinekey (followed by a iisreset) multiple times – without running set-machinekey, I get a new ciphervalue for the machinekey every time. If it fetched the machinekey from the config db, I would expect the command to produce the same result every time.
Am I incorrectly assuming that the ciphervalue for the machinekey will be consistent for each execution of the update-machinekey.
Permalink
Hi Björn,
in case you have encrypted machine keys – yes. I would suggest to look at this solution which complements the suggestion in comparing the keys:
https://blog.stefan-gossner.com/2025/07/21/important-active-attacks-targeting-on-premises-sharepoint-server-customers/#comment-37936
Cheers,
Stefan
Permalink
That is how I have been verifying the keys (since we are on Sharepoint SE with encrypted keys), by using: Write-Host “Cipher: $($machineKey.EncryptedData.CipherData.CipherValue)”
Despite using the above, the values (ciphervalue) differ between servers in farm for same webapp. And weirdly enough, if we run update-machinekey followed by iisreset, multiple time – the ciphervalue will be different every time. I would expect it to stay the same unless running set-machinekey.
I asked Copilot if an empty machinekey value that is encrypted, would produce output and this is the answer:
If the Section Was Encrypted from an Empty Input
If you encrypted an empty section (or one with no keys defined), the resulting will still contain a hash-like string. However:
The encrypted output will differ each time, even for the same empty input.
This is because DataProtectionConfigurationProvider uses random entropy (salt) during encryption, which ensures that the same input produces different encrypted outputs every time.
If Copilot is correct and not hallucinating, this could explain why update-machinekey produces a different ciphervalue every time. Or really, if the salt is random every time, I guess the same machinekey would produce a different ciphervalue every time, making that method unusable for verification (it can be used to verify that the key has been updated, but not to compare keys from different servers)
Permalink
Hi Stefan –
Is there any guidance if turning on Antimalware in an SP 2016 farm is causing 500 errors (once turned off, everything goes back to normal and pages load). I’ve found articles for newer farms having additional configuration options for the Antimalware service but I can’t find any suggestions on what to do if this is happening in SP 2016 other than turning it off (obviously, we’d prefer to have it on).
Thanks.
Permalink
Hi Staci,
we have guidance on directories that should be excluded from AV:
https://support.microsoft.com/en-us/office/certain-folders-may-have-to-be-excluded-from-antivirus-scanning-when-you-use-file-level-antivirus-software-in-sharepoint-01cbc532-a24e-4bba-8d67-0b1ed733a3d9
Cheers,
Stefan
Permalink
Hi Stefan, but precisely by excluding routes, given this type of attacks, aren’t we leaving doors open that could make the SharePoint farms vulnerable? Thank you very much for all your support on this matter.
Permalink
Hi Stefan, we are having some issues with som out of the box commands since we applied this patch.
Example:
$db = Get-SPContentDatabase {AnyContentDB}
Test-SPContentDatabase $db # WORKS!
Test-SPContentDatabase -Name $db.Name -WebApplication $db.WebApplication #FAILS
Test-SPContentDatabase : A connection was successfully established with the server, but then an error occurred during the login process. (provider: SSL Provider, error: 0
– The certificate chain was issued by an authority that is not trusted.)
the non-patched servers do not present this issue.
Any idea?
Permalink
Hi Andre,
sounds as if the SQL server certificate chain is not trusted by the SharePoint Servers.
https://edvaldoguimaraes.com.br/2025/05/09/enabling-ssl-tls-encryption-for-sql-server-in-sharepoint-environments/
Check section “Configuring SSL/TLS Encryption for SQL Server”
Cheers,
Stefan
Permalink
As for my earlier post regarding not having been able to properly compare machinekeys on Sharepoint SE with encrypted machinekeys – we have now!
TLDR – As long as web.config is updated on both servers (and with a timestamp that is about the same on both servers) – one can expect the machinekey to be identical.
We’ve done some emperical research on our end and found out that even though the machinekey is identical on two servers, the ciphervalue will differ due to having a random element in it.
A web.config with encrypted machinekey would probably look something like below. If comparing the the ciphervalue with another server, it WILL be different (even though the machinekey is identical)
<machineKey configProtectionProvider="DataProtectionConfigurationProvider">
<EncryptedData>
<CipherData>
<CipherValue>AABBCCDDEEFFVERYLONGRANDOMVALUEFFGGHHIIJJKK</CipherValue>
</CipherData>
</EncryptedData>
</machineKey>
In order to verify that the machinekey is in fact identical (despite different ciphervalues), one could decrypt web.config using aspnet_regiis (as per below, don’t forget to change the path and to backup web.config before you try)
Also, this step is not a requirement, it’s for those of you who are intrigued to verify why the ciphervalue isn’t consistent despite machinekey being the same.
aspnet_regiis.exe -pdf “system.web/machineKey” “C:\Webroot\wss\VirtualDirectories\yourwebrootfolder-443”
No need to run iisreset, the machinekey element will be updated instantly with the machinekey element decrypted (allowing for comparison between servers).
Here is how it could look (we’ve obfuscated/replaced the real values)
<machineKey validationKey="AABBCCDDEEFFVERYLONGRANDOMVALUEFFGGHHIIJJKK"
decryptionKey="AABBCCDDEEFFVERYLONGRANDOMVALUEFFGGHHIIJJKK"
validation="HMACSHA256" />
You wouldn’t want the web.config containing a decrypted so in order to encrypt the machinekey element in web.config once again, just run set-machinekey once again:
Get-SPWebApplication -identity https://yourweb.yourdomain.com/ | foreach { Set-SPMachineKey -WebApplication $_ }
The conclusion of this experiment is that, even if the CIPHERVALUE is different for the same webapp on two different servers, the machinekey will be the same (given that web.config are updated on both servers)
Permalink
Hi Björn,
thanks a lot for sharing your findings!
I’m sure this is very valuable for many of readers here.
🙂
Cheers,
Stefan
Permalink
Hi Stefan;
After installing the security patch for the SharePoint Subscription environment, we’re experiencing issues with Kerberos.
Have you reported any issues regarding this?
Permalink
Hi Gabriel,
SharePoint does not implement anything in Keberos. That an OS functionality.
SharePoint only leverages it. So I would assume that this is either just a coincidence or there were also some Windows fixes installed at the same time.
Cheers,
Stefan
Permalink
Hi, we found a bug with the KB5002753 (no issue with KB5002754, we installed 54 first and days after the 53) :
After the installation of KB5002753 if we create a document library with a mandatory custom column in a content type the document just after the creation is in check-out state, even if the mandatory custom column is filled with a default value. It’s not the case on old libraries.
It happen only when the document is created with OOS, if I do a drag and drop or an upload no issue.
For the moment the workaround is to change the mandatory columns to optional or to check-in manually after the creation.
Someone else has this issue ?
Permalink
Hi Stefan,
We have applied the following:
KB5002760 and KB5002759
AMSI with Defender and XDR
Changed the Machine Key
Searched for known script names
Despite these actions, Defender is still identifying an attempt to exploit the system. Is it still possible for this to occur after applying the patch?
Additionally, in the Windows Security log, the timestamp of the attempt appears to be hijacked — it shows no activity between 20:17:05 and 20:17:41.
Here is what Defender is reporting:
Possible exploitation of SharePoint server vulnerabilities
Defender prevented execution of ‘Exploit:Script/SuspSignoutReq.A’ script launched by ‘w3wp.exe’
An active ‘SuspSignoutReq’ exploit malware was prevented from executing via AMSI
URL: POST /_layouts/15/ToolPane.aspx/?DisplayMode=Edit
This is a SharePoint layout page used for editing web parts.
Referer: /_layouts/SignOut.aspx
Indicates the request came after a sign-out action, which is unusual.
User-Agent: Chrome on Linux
Could be a legitimate user or a bot.
Content-Length: 7598
Suggests a substantial payload.
Alert Trigger Time: 20:17:27
Might be relevant for correlating with other logs or user activity
Best regards,
Permalink
Hi Mourad,
of course this is possible even if the system is patched.
AMSI inspects and deflects the malicious requests before SharePoint starts working on them.
As this happens before SharePoint starts processing the request it does not matter if SharePoint is patched or not for this to be reported.
Cheers,
Stefan
Permalink
Hi Stefan
I see thank you _/_
Cheers
Permalink
We also have Office Online Server, and I’ve fetched the KB5002740 WACS OOS 2019 (?).
It installed fine on one test 2019 farm, on the dedicated server they created for it.
However it was probably never actually used, and was upgraded from an old 16.0.10338.20039 which seems like it is a version from 2018 ?!
I then went on to the next one, a Sharepoint SE test farm, with the same version OOS installed (16.0.10338.20039), but the Farm seemed to have been configured to use the OOS server.
I started install, and at ~50% the installers “progress bar” just hung.
I found the MSI logfile, and it seemed to loop around “access denied” in some c:\windows\assembly (GAC?) locations.
It loops for an eternity and then gives up with the short message: “Installation of this package failed”.
The eventlog (not disk) is filled with thousands of “ID 10010 w3wp.exe (pid xxx) cannot be restarted – Application SID does not match the Conductor SID”
I thought I’d just restart IIS for it then – but it insists – the events just change the w3wp.exe pid number and still cannot restart it.
Events seems to be logged under the “SYSTEM” account (I started installer from an Administrator cmd prompt).
I’ve googled to some examples where you can add permissions to GAC with cacls, and tried that.
Then added my own account that started the installed (in the admin cmd prompt).
All To no avail.
CACLS c:\windows\assembly /e /t /p SYSTEM:F
CACLS c:\windows\assembly\temp /e /t /p SYSTEM:F
CACLS c:\windows\assembly\tmp /e /t /p SYSTEM:F
CACLS c:\windows\assembly /e /t /p MyUser@Do.Main:F
CACLS c:\windows\assembly\temp /e /t /p MyUser@Do.Main:F
CACLS c:\windows\assembly\tmp /e /t /p MyUser@Do.Main:F
So I’d like to ask for your input on this, Stefan – if possible :
Is there a special trick to installing the patch for OOS, that I am not aware of.
Any reset of GAC permissions of clearing of any cache or whatnot . . .
(Going from a 2018 version to the newest july 2025 KB5002760)
Permalink
Hi Brian,
this is not a normal behavior. The error message itself is also not related to Office Online Server or SharePoint or similar.
If you search for “Application SID does not match the Conductor SID” in your preferred search engine you will find that this can happen with a variety of applications.
The reason is most likely some type of permission problem.
What I would suggest is to disable IIS before starting the installation of the package and reenable it after the update is completed.
From my experience this can resolve this type of issue.
Cheers,
Stefan
Permalink
I really appreciate your input, Stefan – thanks!
After restoring my snapshot of the server, I’ve now stopped and disabled the WorldWideWebPublishing.
Restarted the KB5002740 OOS patch installer – and it now fails again – BUT slightly different.
Seems to be GAC permissions related – it fails with
“Failing with hr=80070005 at RemoveDirectoryAndChildren at line 393” on what seems to be all things related to “C:\Windows\Assembly\temp” – and even one or more files under
“C:\Windows\Microsoft.Net\assembly\GAC_MSIL\Microsoft.Office.Server.Broadcast.Interface.Data\”
It didn’t do any good trying to adjust ACL (cacls) while installing (Would/Should it?).
So after it failed, I’ve tried adding SYSTEM:F (It kept mentioning S-1-5-18 ) ( and even as last resort Everyone:F ) (cacls /e /t /p user:F) – and restarting the poor little installer.
(All install attempt started from an Administrator CMD prompt)
But it keeps failing.
I’ve now restored the snapshot to a time with only the old version OOS…
If you can think of any (other) way to get that kb5002740 OOS/Wacs patch installed, I’d love to hear about it 😉 ?
Permalink
Oh . . . .
Hi again Stefan!
I think the RemoveDirectoryAndChildren simply got stuck on an abandoned/still running installation I did not see.
I rebooted server, double checked that everyone:F as still active under ..\assembly\t*mp and restarted the patch install.
It succeeded in a couple of minutes.
Now I just need to figure out how to restore the ACLs on GAC folders . . .
I will probably never figure out why this server failed that patch installation in the first place.
Permalink
AND I had to just restore the snapshot again because I obviously do not quite know how to remove “everyone:F” from the tmp/temp in GAC …
I ended up in a tight corner with nobody having any access to those folders.
Administrator was not allowed to see/change security on folders either.
Sigh.
Permalink
This is the “funniest” product patch ever, OOS.
I am just about to find a DomainAdmin that can come and try to install the %¤#(/ OOS patch (kb5002740)
Every attempt so far have failed.
I have found all the Paths (from installer logfile) that installer cannot “RemoveDirectoryAndChildren” from, and used cacls to add “my domain (local admin) account”, SYSTEM and “Everyone” to each of those Paths.
I have stopped/disabled IIS each time now.
I have tried uninstalling OOS completely, only to discover that KB5002740 is in fact only a patch to something already installed 😉
I have tried resetting GAC paths before installation.
Have tried resetting and then adding the accounts to GAC paths.
I think I have tried every attempt at persuading it to install on this server, but in vain.
Stefan:
The Sharepoint using this OOS IS in fact a “Subscription Edition”, but I can only find a 2019 OOS/WACS, is that correct and should it work ??
Permalink
Well – last install failed again.
I rebooted and gave the installer yet another shot with no real changes this time. It ended with asking me to reboot to finish.
I did that.
But when I checked “Add Remove programs”, I still only see the old version installed aug 2022 (10.6.0.10338.20039)
I then tried starting the Installer once more, and THEN it stated “Can’t do that, this update is already installed”
But – as I said, AddRemovePrograms still show the old version .
Is this server just possessed by a ghost of a rotten troll or what? 🙂
( I just now googled “deeper” and stumbled over this page that confuses me a tad more:
https://learn.microsoft.com/en-us/officeonlineserver/apply-software-updates-to-office-online-server
So, the update should be installed by “removing the old version altogether”, and then download the installation package for the new version, and THEN patch that with KB5002740 – or what ? )
Permalink
OOS is a separate product so it doesn’t really matter if you are using OOS 2019 with SP SE. It should work.
Did you by chance install OOS on the same server as SharePoint? In that case, you may have better luck moving OOS to a dedicated server. You also should not use snapshots if SharePoint is on the server. You would be better off re-imaging the server.
Hope that helps a bit
Permalink
Thanks Stefan
No, we have a separate server for OOS in each environment (if it’s used at all).
And I’ve just tried the “official” Micsoroft guide on how to update OOS.
( In short:
Remove-Office-WebAppsMachine,
Run update-file kb5002740 as admin.
Restart server.
Add the OfficeWebAppsFarm with params that one could hopefully remember or deduce from another guide for OOS2016, that you’d better use before removing the config 😉 )
Did like they said, but it still complains a lot about “RemoveDirectoryAndChildren” during installation, in the installer logfile -but runs til end and requests a restart of server “to finish installation”.
But after restart, the server STILL only has the old version installed.
I think I will try asking the OOS gurus at Microsoft, how they intend their product to be patched – if possible 😉
For now, I remain less than impressed with OOS 😀
Permalink
I just want to inform that I managed to upgrade the two test-farms so far, that use Office Online Server.
I believe it was all my own fault, for not finding all upgrade tricks beforehand 🙂
Probably the most important cause I found, was that some Serveradmin decided to implement WindowsDefender on our servers, but make no ‘exclusions’ whatsoever. So I decided to disable Defender during patch installation. That helped a great deal I think.
And I also discovered another [Microsoft-]guide to install patches, where you’d need to remove the config first, patch and then redo OOS config (OfficeWebApps*) and bindings after installation. On the patch download page itself, Microsoft just manages to state that we basically need to “run the installer and that’s it”. Or as they put it:
Click Run to start the installation immediately.
Click Save to copy the download to your computer for installation at a later time
So It worked.
But the MSP instal logfile really in is an uncanny mess of what looks like a gazillion errors in the GAC folders, it just loops through “forever” – but suddenly it carries on and asks us to restart the server to finish installation.
And it updates the “Installed updates” list. But not the “Installed Products, which is still the old initial version”.
The “.INC” textfile is also updated at some point. I don’t know for sure when, but think it would be after first reboot…
The update takes much longer than what seems necessary – especially when it cycles/loops though all those GAC related folder errors. (“RemoveDirectoriesAndChildren”) under “\Windows\Assembly*”
Thanks for the help/sparring, all!
Permalink
Have you tried uninstalling the old version first then reboot? Sorry TMI to sift through so I may have missed it.
Permalink
Hi Rob
Yes, that led me to the dead end, where I now know that the “update kb5002740” will not run at all, since it is only a patch.
I do regrettably not have the installation media at hand, so that must be fetched first.
And I AM sorry about the many updates here now – but this fight with OOS has been intense :p
I even figured out that the very first attempt in a SP2019 farm (on separate server too) didn’t even work as it claimed.
That too is still the old version according to AddRemovePrograms.
Permalink
Understood. Have you checked your GPOs? Verify that the correct service account permissions and User Rights Assignments are in place and that there are no weird Deny rights blocking this?
Permalink
Before you mess with upgrading OOS, go back to the basics. When’s the last time you patched it? If it’s been awhile, can you install a slightly older patch first? Can you install other patches on that server? Can you install anything on it?
Permalink
Thanks for the suggestions!
However – we tried disabling WindowsDefender (That someone installed with no exclusions whatsoever) – and I’ve had a domain admin take a look and run the installation.
But all to no avail.
When server reboots, the version is still the old one (I’ve tried now with both a patch from 14 may 2024, and the latest.)
And the server is spending all it’s time handling errors from Windows Error Reporting and Exceptions from all sorts of .Net – until I shut down “Office Online Service”
So, somethings definitely not right for any newer patch than 16.0.10338.20039
I just need to figure out why/what. (It DOES have .NET 4.8 (Requirements states 4.5.2)
But I think I can see that event logs refer ti 4.0 (?)
Can any of you suggest how I check which .NET the OfficeOnline service would attempt to use, if several versions are installed on the server?
I’m currently waiting to get permissions via my employer, to open support requests with Microsoft.
Permalink
“event logs refer to 4.0 (?)” That is normal. OOS should be able to use any .net version later than 4.6 BUT it also requires .net 3.5 so ensure that is on there or things will break. when I recently had .net issues when updating a 2018 build. Upgrading to the newest version fixed it.
That said…
Sounds like the update is installing after you remove the server from the OOS farm (yes that is the correct procedure). After updating, did you check View Installed Updates to see if that KB is listed? Did you run Get-OfficeWebAppsFarm to see what version is listed there? Did you try smoke-testing it in SP after the update? It may be that it’s fine and you can just ignore the version in Control Panel/Programs.
Permalink
Rob
Thanks for clarifying that the 4.0 framework message is normal!
And yes, I also stumbled over the update guide that tells us to remove OOS from farm first. (I wish someone at M$ read their own “how to install this update” on their own download webpage 😉
But.
I am leaning to the assumption that the install was in fact obstructed by Windows Defender that someone pushed out to servers, with no exclusions whatsoever.
I installed this on a small test server with only two cores. And I actually thought something was very wrong, when it hammered on the CPU for 15-30 minutes after reboot.
But it seems to calm down after some time.
And I’ve confused myself by the fact that version in “AddRemove” is still the old version. I guess that is as expected, because “Installed Updates” actually states KB5002740.
And another claim to see version is apparently
C:\programdata\Microsoft\OfficeWebApps\Data\Local\OfficeVersion.inc
– but that file seems a little inconsistent – I’m not sure I can trust that claim.
I will try another server later today, with my latest procedure and see if I get it right in first try.
Permalink
Hi Stefan,
For a 3-server farm topology (2 WFE and 1 App), what is the recommended way in executing the rotating the Machine Keys powershell commands?
Do we run the Set-SPMachineKey & Update-SPMachineKey in each server in the farm or is it sufficient to run it once on the App server only and this will handle automatically across the other servers in the Farm?
Permalink
Hi Shoaib,
you only have to execute Set-SPMachineKey on one of the machines. It should replicate to all other machines.
If that does not happen use Update-MachineKey -Local on the machines that did not get the new key.
More details are in this blog post.
Cheers,
Stefan
Permalink
Hi Stefan no CU for August yet ? Any ideas with czech language pack left navigation menu issue ? Thanks
Permalink
Hi Michal,
it was just released.
Cheers,
Stefan
Permalink
Anybody tryied czech language pack and left navigation menu issue fixed? Thanks
Permalink
czech language pack 08/2025 does not fixed left navigation menu issue ;-(
Permalink
Hi Michal,
are you using side-by-side patching and if yes: did you update the side-by-side token after running the configuration wizard?
BTW, did you open a support case for the issue. Without a case this issue will not be investigated.
Cheers,
Stefan
Permalink
No i dont use side-by-side patching, ok I am planning to open support case in MS.
Permalink
Sorry to shout here again , but I’ve finally been allowed to patch our last SP2019 farm.
I ran the procedure that worked on all the other farms until now [Thanks again for help on THAT 😉 ].
But it failed miserably on this SP2019 (version from dec 2020).
[Yes, I know, embarrasingly old]
Fortunately we have snapshots in place, so restore was easy.
The patch itself installed as fine as on the other servers I’ve done by now.
But Sharepoint Configuration Wizard failed and I aborted the process because I have no idea how to fix, what it told me was wrong.
The failure was the following, which I would love to hear what others would have done to solve.
(Isn’t there some way to check these “requirements” before trying to spend hours on a failed patch attempt?)
And how on earth do we translate the wacko hexnumbers to something human readable that might trigger someone´s memory on what “feature” they played with during the time of this farm.
(I have not had any share oini setting up this farm, just been handed it to operate it)
What even is “a feature” – mentioned in a database but not being installed in the farm – how does that happen ?!?
What would you do to solve this ?
Message from ConfigWizard failure to install:
An exception of type Microsoft.SharePoint.PostSetupConfiguration.PostSetupConfigurationTaskException was thrown. Additional exception information:
Feature (Id = [80bf3218-7353-11df-af9f-058bdfd72085]) is referenced in database [Content_Transport], but isn’t installed on the current farm. The missing feature might cause upgrade to fail. If necessary, please install any solution that contains the feature and restart upgrade. (EventID:ajxkh)
Feature (Id = [eb657559-be37-4b91-a369-1c201183c779]) is referenced in database [Content_Transport], but isn’t installed on the current farm. The missing feature might cause upgrade to fail. If necessary, please install any solution that contains the feature and restart upgrade. (EventID:ajxkh)
Feature (Id = [0561d315-d5db-4736-929e-26da142812c5]) is referenced in database [Content_Transport], but isn’t installed on the current farm. The missing feature might cause upgrade to fail. If necessary, please install any solution that contains the feature and restart upgrade. (EventID:ajxkh)
Feature (Id = [9bf7bf98-5660-498a-9399-bc656a61ed5d]) is referenced in database [Content_Transport], but isn’t installed on the current farm. The missing feature might cause upgrade to fail. If necessary, please install any solution that contains the feature and restart upgrade. (EventID:ajxkh)
Feature (Id = [86c83d16-605d-41b4-bfdd-c75947899ac7]) is referenced in database [Content_Transport], but isn’t installed on the current farm. The missing feature might cause upgrade to fail. If necessary, please install any solution that contains the feature and restart upgrade. (EventID:ajxkh)
Thanks a bundle, in advance.
Permalink
we met with such an error messages regularly during patching. following script is used by us to fix the issue
collect related ids and contentdatabses from upgrade log file and use the last line as an example
function Remove-SPFeatureFromContentDB($ContentDb, $FeatureId, [switch]$ReportOnly)
{
write-host “Start working on following feature ID: ‘” $FeatureID “‘”
$db = Get-SPDatabase | where { $_.Name -eq $ContentDb }
[bool]$report = $false
if ($ReportOnly) { $report = $true }
$db.Sites | ForEach-Object {Remove-SPFeature -obj $_ -objName "site collection" -featId $FeatureId -report $report
$_ | Get-SPWeb -Limit all | ForEach-Object {
Remove-SPFeature -obj $_ -objName "site" -featId $FeatureId -report $report
}
}
}
function Remove-SPFeature($obj, $objName, $featId, [bool]$report){
$feature = $obj.Features[$featId]
if ($feature -ne $null) {
write-host “It is working on ” $objName “:” $obj.Url
if ($report) {
write-host “Feature found in” $objName “:” $obj.Url -foregroundcolor Yellow
}
else{
try {
$obj.Features.Remove($feature.DefinitionId, $true)
write-host “Feature successfully removed from” $objName “:” $obj.Url -foregroundcolor Yellow
}
catch {
write-host “There has been an error trying to remove the feature:” $_
}
}
}
else {
#write-host “Feature ID specified does not exist in” $objName “:” $obj.Url
write-host “Feature ID ( $featId ) does not exist in $objName : $($obj.Url)”
}
}
asnp so
#copy the list of features to be removed like:
#Remove-SPFeatureFromContentDB -ContentDB “content_portal_01” -FeatureId “13e6c24-24a0-474f-b501-2be1daa20e12”
Permalink
That means you have features that are enabled in that content DB but not on the farm (or the web app). The fixes are:
1. Go to the site collections on the source farm and turn those features off if you can. One of those features is Nintex. See if you can turn off Nintex.
2. If you can’t turn them off (maybe they came from an old migration), then do what Gabor said and remove them via powershell
3. Install and deploy the features on the source farm
4. Dismount the DB during patching, then re-mount without DB upgrade (you will still need to upgrade it at a later time)
Pick one of those then try patching again
Permalink
FYI Each of those 4 is a separate option. Choose only 1.
Permalink
Oh – a thought strikes me…
This farm might be one that has been through a bunch of upgrade from SP2010->SP2013->SP2016->SP2019
( I found a “Features” table in the Content_Transport, and according to that, the features has been created in 2018, so this is a really old farm…) )
That database Content_Transport tells me nothing. Is there a chance that it is just old leftover stuff and that it could be dismounted/dropped entirely? [The name suggests that my former colleagues might have used it temporarily during migrations or whatnot. And left it floating ]
Is there a method in Sharepoint/Powershell to verify this somehow – like in “database X is present, but SP does not really care about it, might as well be gone for all we care”
Permalink
Hi Brian, you can use the Get-SPContentDatabase PowerShell cmdlet to see which webapplocation the database is attached to.
Cheers,
Stefan
Permalink
Thanks a bundle for the inputs, appreciated.
That’s a lot of fiddling on a production system, so I’ll try persuade VM-team to create me a separate copy of the environment to train myself on. And they’ll have to live with an unpatched farm.
Permalink
If you need a quick fix just use option 4. Dismount, then patch. Then try Mount-SPContentDatabase with the NoB2BSiteUpgrade and SkipIntegrityChecks properties when you re-mount.
Permalink
Thanks again, Rob! – I have finally come to the point where I need to fix this. And I’m choosing option 1, removing the features after securing myself a proper backup of all servers.
One question – to be sure I don’t make an avoidable error, as this is production and I do not have a test copy to practise on: The Farm have not changed since my last attempt, so database/Feature-IDs will be the same.
Should I run the remove-spfeature* powershell (on the 4-5 missing features) prior to starting the ConfigurationWizard or at another step, need to ensure anything else is done first?
Any input appreciated, thanks 🙂
Permalink
Assuming you don’t have the missing features anywhere anymore, option number one would not be possible. You will be stuck with either option 2 or 3. I recommend #2 run a script such as Gabor Varga’s. You will have to run the script before the config wizard or the wizard will fail. Just make sure you have FULL backups of the content DBs and the config DB.
Permalink
Hi Jakub Urban and Michal Foltyn have you some update with left navigation menu fixed or any other idea? Thanks
MV
Permalink
Oh MAN this is crazy complicated.
I’ve just tried second time around – this time the language-pack (2753) did NOT install first time (some assembly stuff that already existed,) I had no clue, but since this is Windows I thought, hell I’ll try rebooting and patch thet language installer once more. Lo and behold – it installed flawlessly.
I then went on to doing “option 2 – powershell” – remove the 5 shipwrecked features.
It worked fine too.
Then continue to the infamous Config Wizard.
Which failed – in Same Database, but to NEW Features. I mean “what the actual F…” 😀
Then I thought : Oh, no problemos I have the powershell script to fix that (again)
But NOW the powershell doesn’t work at all!?
It fails with Error occurred while enumerating through a collection: There was no endpoint listening at https://localhost:32843/SecurityTokenServiceApplication/securitytoken.svc that could accept the message. This is often caused by incorrect address or SOAP action.
(I suspect config has done ‘something’ to hinder the powershell functionality)
Now I will try rebooting in the vain hope that something (SOAP/tokenservice starts and I can remove the feature thingies… Or simply ‘ give up’, restore our snapshots and accept that this ¤%#( is not getting patched :p
Hit me if you have suggestions ?
Permalink
UPDATE:
I restarted the Server after closing the errored Config Wizard.
After that, the RemoveFestures powershell hack worked as expected. The two extra features were gone, and the ConfigWizard were able to finish. (YAY!)
ConfigWizard then worked fine on the remaining frontend server.
And lastly, I managed to reconfigure the OOS in first attempt.
So, I need no advice this time, thanks 😀
But I am now gray haired 🙂
Permalink
Great to hear. Good job. For your reference, when you see no endpoint found for a web service including security token service, an iisreset will usually fix that.
Permalink
Great info, thank Rob!