Ravindran ManiNotes

SharePoint / Guide 7

Security patches

Why patching matters, how to install updates, what to run afterwards, and how to verify every server.

Patching is the most important routine job on an on-premises farm, and the one most often postponed. This guide covers why it matters, how to install updates safely, what to run afterwards, and how to prove every server is on the same build.

Why it matters

On-premises SharePoint servers are high-value targets: they're often reachable from the internet, run with powerful service accounts, and hold sensitive documents.

In July 2025, attackers exploited a critical remote code execution vulnerability in on-premises SharePoint Server (CVE-2025-53770, widely called "ToolShell") before most farms were patched. Organisations around the world were compromised. The response required installing the emergency update and rotating the farm's ASP.NET machine keys, because attackers had stolen them. Farms that were already current on updates, with AMSI integration turned on, were in a much better position. SharePoint Online wasn't affected.

The lesson: treat SharePoint updates like Windows updates. Install the monthly security update every month.

Check your version is still supported. SharePoint Server 2016 and 2019 reached end of extended support in July 2026 and no longer receive security updates. Subscription Edition is the supported on-premises version.

What Microsoft ships

  • Monthly updates on Patch Tuesday. For 2016, 2019 and Subscription Edition, the monthly public update contains both security and non-security fixes. It's the same as a cumulative update (CU).
  • 2016 and 2019 usually have two packages each month: the core sts package and the language-dependent wssloc package. Install both, plus language pack updates if you use language packs.
  • Subscription Edition has a single package each month, and it also delivers feature updates.
  • Emergency (out-of-band) updates for actively exploited vulnerabilities. Watch the Microsoft Security Response Center for these.

Every update is cumulative, so the latest one brings a farm up to date from any earlier build of the same version.

Before you patch

  1. Back up: farm configuration, content and service databases, and a snapshot of each server if they're virtual machines.
  2. Record the current build and state: run Get-SPPatchStatus.ps1 and keep the output.
  3. Check the farm is healthy: no databases already needing upgrade, Health Analyzer reviewed, enough free disk space on every server.
  4. Pause search so crawls don't fight the upgrade:

powershell $ssa = Get-SPEnterpriseSearchServiceApplication Suspend-SPEnterpriseSearchServiceApplication -Identity $ssa

  1. Download every package for your version and languages, and copy them to each server.

Installing: the two phases

A SharePoint update is two separate steps. Every server must finish phase 1 before any server starts phase 2.

Phase 1: install the binaries on every server. Run the update package (.exe) on each SharePoint server; this can be done on several servers at once. When the installer asks, don't run the configuration wizard yet. Restart the server if the installer asks you to.

Stopping these Windows services before installing speeds the installer up considerably, especially on search servers; start them again afterwards:

$services = 'SPTimerV4', 'SPAdminV4', 'SPSearchHostController', 'OSearch16', 'W3SVC'
Stop-Service -Name $services -Force -ErrorAction SilentlyContinue
# ... run the update package ...
Start-Service -Name $services -ErrorAction SilentlyContinue

(OSearch16 is the search service on 2016, 2019 and Subscription Edition; on 2013 it's OSearch15.)

Phase 2: run the configuration on each server, one at a time. Start with the server that hosts Central Administration, then do the others one by one. This upgrades the databases and brings each server to the new build:

.\Invoke-SPPostPatchConfig.ps1

Invoke-SPPostPatchConfig.ps1 checks it's running elevated and runs the standard command:

PSConfig.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install

Zero-downtime patching (2016 and later)

With at least two servers in every MinRole role behind a load balancer, users don't need to see an outage:

  1. Take one front-end server out of the load balancer, install the binaries, run PSConfig, and put it back.
  2. Repeat for each server in turn, keeping at least one server of each role serving users at all times.
  3. Turn on side-by-side support so users on upgraded and not-yet-upgraded servers get matching static files (JavaScript, CSS) during the rollout. Enable it once, then copy the files on each server after installing the binaries:

powershell $ws = [Microsoft.SharePoint.Administration.SPWebService]::ContentService $ws.EnableSideBySide = $true $ws.Update() Copy-SPSideBySideFiles

After you patch

  1. Upgrade any content database still behind (PSConfig usually does this; large databases sometimes need a separate run):

powershell Get-SPContentDatabase | Where-Object NeedsUpgrade | Upgrade-SPContentDatabase -Confirm:$false

Invoke-SPPostPatchConfig.ps1 -UpgradeContentDatabases does the same.

  1. Resume search:

powershell Resume-SPEnterpriseSearchServiceApplication -Identity $ssa

  1. Check the upgrade logs in the hive's LOGS folder (Upgrade-*.log and PSCDiagnostics_*.log) for errors.
  2. Review Health Analyzer in Central Administration.
  3. Test the key sites, search, and any custom solutions.

Verify every server

A farm is only patched when every server is on the same build and nothing is waiting for an upgrade. Run:

.\Get-SPPatchStatus.ps1

Get-SPPatchStatus.ps1 reports, for every SharePoint server: the file version of the core SharePoint DLL, whether the server still needs upgrade, and the state of the Timer and IIS services. It also lists any database that still needs upgrading, and gives an overall verdict.

In Central Administration, Upgrade and Migration has the same information: Check product and patch installation status (every server should show the same patch level) and Review database status.

Hardening that goes with patching

  • Keep AMSI integration on. Current updates for 2016, 2019 and Subscription Edition support the Windows Antimalware Scan Interface, which lets Microsoft Defender (or a compatible antivirus) inspect requests. Use it in full mode where supported.
  • Rotate machine keys after any suspected compromise, and restart IIS on every server afterwards:

powershell Set-SPMachineKey -WebApplication https://sharepoint.ravindran.in Update-SPMachineKey -WebApplication https://sharepoint.ravindran.in

  • Don't publish Central Administration to the internet, and limit which networks can reach the farm.
  • Follow Microsoft's guidance for any emergency update; it sometimes includes steps beyond installing the package, as ToolShell did.