Sometimes, the biggest surprises come from the smallest security tweaks. That’s exactly what our colleague Mike Ostrander uncovered while helping one of Cloudwell’s long-standing enterprise clients update their SharePoint Server Subscription Edition environment.
What looked like a routine cumulative update turned into a lesson in how “security hardening” can have unintended consequences — and why staying ahead of Microsoft’s patch curve matters more than ever for on-prem SharePoint environments.
The Background: A Subtle Change with Major Consequences
In September 2025, Microsoft released a cumulative update for SharePoint 2016, 2019, and Subscription Edition that quietly adjusted folder permissions for security reasons.
According to Stefan Gossner, Senior Escalation Engineer at Microsoft, the patch removed write access to the layouts folder for two key groups:
WSS_WPG
IIS_IUSRS
In isolation, that’s good security hygiene — fewer write permissions mean less attack surface.
But there was a catch: many SharePoint environments still run certain services under Local Service, System, or Network Service accounts (as noted by Microsoft).
When the October 2025 CU rolled out, those local accounts no longer had the rights they needed to complete the installation. The result: failed updates, cryptic Access Denied errors in the logs, and some very puzzled admins.
The Problem: One Server Refused to Patch
During a routine support engagement with one of Cloudwell’s long-standing enterprise clients — an organization running a hybrid Microsoft environment with both cloud and on-prem workloads — the team noticed something odd.
The client’s development SharePoint farm had two servers: one that successfully installed the October 2025 CU, and another that stubbornly refused to upgrade. Every attempt to apply the patch failed, leaving the servers out of sync — a situation that can quickly spiral into bigger operational risks if left unresolved.
That’s when Mike Ostrander stepped in to investigate.
The installation logs revealed Access Denied messages linked to the layouts directory — a classic permissions failure. After some digging, Mike found the smoking gun: Stefan Gossner’s Microsoft blog post detailing a new issue introduced by the September 2025 CU.
The Fix: Cleaning Up Service Accounts and Permissions
Following the Microsoft engineer’s guidance, Mike confirmed the root cause:
The September CU removed write privileges from WSS_WPG and IIS_IUSRS. This meant any SharePoint service still running under Local Service or System would break the next patch cycle.
Armed with that insight, Mike applied the remediation steps exactly as outlined in Microsoft’s article:
- Identify services running under Local Service, System, or Network Service accounts.
- Update them to use domain-based service accounts that belong to WSS_WPG and IIS_IUSRS.
- Remove the local accounts from those groups to prevent blocked-rights inheritance.
- Re-run the update — and watch it complete cleanly.
After these changes, the patch installed without issue, the servers aligned on the same build, and the client’s SharePoint environment was fully operational again.
The Lesson: Security Improvements Need Operational Awareness
Microsoft’s intention was solid — reduce attack surface by tightening permissions. But in environments where legacy configurations persist (especially dev/test systems), these changes can quietly disrupt the next update cycle.
For IT leaders managing on-prem or hybrid SharePoint deployments, this incident highlights a few important truths:
- Security and stability go hand-in-hand. Patching blindly can be just as risky as not patching at all.
- Service-account hygiene matters. If your farm still uses Local Service or System accounts, now’s the time to modernize.
- Every CU deserves testing. Even a single permission change can ripple through your patch pipeline.
The Cloudwell Takeaway
At Cloudwell, we’ve seen how patching “gotchas” can surface in the most unexpected places — even in well-maintained enterprise environments.
Thanks to Mike’s quick thinking and deep SharePoint expertise, our client avoided extended downtime and now has a more secure, maintainable configuration.
If you support on-prem SharePoint 2016, 2019, or Subscription Edition:
- Audit your service accounts before applying the next CU.
- Run updates in a non-production farm first and review installation logs closely.
- Verify group memberships for WSS_WPG and IIS_IUSRS to ensure no local system accounts remain.
And if you hit similar issues — or just want an extra set of eyes on your next patch cycle — Cloudwell’s team is here to help keep your Microsoft 365 and SharePoint environments secure, supported, and surprise-free.