Installing a SharePoint Server Subscription Edition update without downtime, step by step

A Subscription Edition farm is supported only while it runs a recent build: each monthly public update is supported for a year, as Chapter 42 of the Field Guide sets out. So an update is not an occasional project. It is a monthly operation, and on a farm people use all day the question is whether it can be done while they work.

Microsoft's answer is zero downtime patching, a method "developed in SharePoint in Microsoft 365" and documented for SharePoint Server 2016, 2019 and Subscription Edition. Its promise is precise: users keep "working on, saving, and searching documents" while the farm is patched (zero downtime patching steps, checked on 6 November 2026). This article sets out what the farm needs before that is possible, every step with Microsoft's own commands, the places where Microsoft's pages disagree with each other, and what the method does not cover. It is written for Subscription Edition, the only version of the three still in support: 2016 and 2019 left support on 14 July 2026, as the end of support tracker records.

The documentation was read on 6 November 2026. No farm was accessed for this article.

What the farm must have first

High availability is the requirement, and MinRole is not. Microsoft is explicit on both: "A highly available SharePoint Server farm is a requirement for ZDP", while MinRole "could enhance" the experience but "is not a requirement". High availability here means two of every role, on separate hosts: two front ends behind a load balancer, two application servers, two Distributed Cache servers and two search servers, with the databases on a SQL Server cluster that fails over by itself.

The method works by drawing a line down the middle of the farm. Microsoft's example names the servers in pairs, SPWeb01 and SPWeb02, SPApp01 and SPApp02, and so on: everything done to the 01 column is then repeated on the 02 column, and while one column is being worked on the other carries the users. A farm with one server in any role cannot do this. For it, Microsoft documents the in-place method with backward compatibility, which reduces downtime and does not remove it (install a software update, checked on 6 November 2026).

Search needs the same pairing inside the index. In Microsoft's words: "patch one index replica at a time and never patch or upgrade index replicas from the same partition at the same time." A search topology with a single replica of any partition is not highly available for this purpose, whatever the server count says.

What an update is, on Subscription Edition

Every update installs in two phases (software updates overview, checked on 6 November 2026):

Zero downtime patching is these two phases run in an order chosen for uptime. Between them the farm runs in a mixed state, which its backward compatibility allows, and Microsoft attaches a caution to it: the longer a farm stays in that state, the more likely it is to meet a case where it does not behave as it should. The two phases belong in one window, not in two.

On Subscription Edition an update is one package. The October 2026 update, KB5002927, build 16.0.20326.20190, is the single file uber-subscription-kb5002927-fullfile-x64-glb.exe (KB5002927, checked on 6 November 2026). Microsoft's zero downtime page was written for 2016 and still says to patch each server "with the 'STS' and 'WSS' packages", the two packages those versions ship. On Subscription Edition, read that as the one package the update provides.

Before the window

1. Read the update's notes for what has to happen first. The October 2026 notes require SharePoint Workflow Manager's own update, KB5002799, to be installed "before you install this cumulative update" on a farm that runs it, and a farm on the classic Workflow Manager to set server debug flag 53601, followed by iisreset. The same notes say the update introduces the Version 26H2 feature update, and that the ImportWeb SOAP feature is disabled from this update unless Enable-SPImportWeb turns it on for a site collection. A monthly update can change what the farm does, not only fix it, and the notes are where that is said.

2. Take the full backup, and know what it returns the farm to. Chapter 42 sets out the ways back from an update and what each costs. Zero downtime is not one of them.

3. Reboot and test every server. Microsoft asks for every server "fresh from a reboot and healthy" before patching, and for the front ends to be tested before either leaves the load balancer, so that the one left in rotation can carry the whole load.

4. Enable side-by-side, once. It makes every front end serve the same static files while files on one of them are being replaced. It "is built into PSCONFIG but must be enabled", with one content web application's URL:

   PowerShellCopy code

   $webapp = Get-SPWebApplication <webappURL>
   $webapp.WebService.EnableSideBySide = $true
   $webapp.WebService.update()

5. Pause search crawls and profile imports for the window, as Microsoft recommends.

Phase 1: the binaries, half the farm at a time

1. Take the first front end, SPWeb01, out of the load balancer. Install the update, reboot, and return it to rotation.
2. Take the second front end, SPWeb02, out of the load balancer. Install the update and reboot. Leave it out of rotation until the upgrade is complete, unless the farm is under heavy load, in which case Microsoft allows returning it until psconfig is ready to run.
3. On the 01 column's application, Distributed Cache and search servers, install the update and reboot. Their work falls on the 02 column meanwhile.
4. Repeat on the 02 column: SPApp02, SPDCH02, SPSRCH02. The work falls on the 01 column.

Before rebooting a Distributed Cache server, stop its cache gracefully. The zero downtime page asks for this only before psconfig, but Microsoft's update installation page says it applies to the update itself: "Prior to restarting a server from running a software update or Configuration Wizard, you must stop Distributed Cache to prevent unallocated cache fractions." How to stop it is the first of the three disagreements, below.

Phase 2: the upgrade, one server at a time

Every server now has the binaries and has been rebooted. The build-to-build upgrade runs with one command, the same on every server:

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

1. On SPWeb02, still out of rotation, open the SharePoint Management Shell and run it. When it completes, return SPWeb02 to the load balancer. It is fully patched and upgraded.
2. Take SPWeb01 out of the load balancer, run the same command, and return it.
3. On each remaining 01 server, SPApp01, SPDCH01 and SPSRCH01, run the command one server at a time.
4. Then on each 02 server, SPApp02, SPDCH02 and SPSRCH02, one at a time.

Microsoft is firm about the serial order in this phase: the commands run "one server at a time and not in parallel", because running them serially "is the safest and most predictable means" of keeping the farm up. On each Distributed Cache server, stop the cache gracefully before the command and bring it back after.

A farm with many or large content databases can shorten the phase: during it, Upgrade-SPContentDatabase can upgrade databases ahead of psconfig. That is the second disagreement, below.

Switching to the new build

When every server has been through psconfig, one more step completes the side-by-side process and moves users to the new interface files, with the new build number:

$webapp = Get-SPWebApplication <webappURL>
$webapp.WebService.SideBySideToken = "16.0.20326.20190"
$webapp.WebService.update()

The build in that example is October 2026's; use the build of the update installed. psconfig copies the files the switch needs into a folder named for the build. Its log, under C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\LOGS, says whether the copy succeeded, and Copy-SPSideBySideFiles repeats it if not.

Then confirm the result where Microsoft says to look: the Upgrade and Migration page in Central Administration, "the primary tool to view product and patch installation status, data status, and update status". Resume the crawls and the profile imports, and open the pages people use.

Where Microsoft's pages disagree

How to stop the Distributed Cache gracefully. Three pages give three answers:

• The zero downtime page says to remove the Distributed Cache instance before psconfig and add it again after, with Remove-SPDistributedCacheServiceInstance and Add-SPDistributedCacheServiceInstance.
• The page on managing the service says that on Subscription Edition the graceful-shutdown script is not run; instead, Stop-SPDistributedCacheServiceInstance is run with -Graceful. The update installation page agrees: that switch must not be used on 2013, 2016 or 2019, "But Stop-SPDistributedCacheServiceInstance -Graceful can be used for SharePoint Server Subscription Edition" (manage the Distributed Cache service, checked on 6 November 2026).
• The cmdlet's own reference page says the -Graceful switch "is not capable of properly transferring cached items to another Distributed Cache host within the farm" (Stop-SPDistributedCacheServiceInstance, checked on 6 November 2026).

Our reading is that the two pages written about Subscription Edition by name carry more weight than a reference page that does not distinguish versions, and we would use -Graceful on Subscription Edition. We would also prove it in the rehearsal, because the transfer "takes 15 minutes or more" and what is lost if it fails is specific: tags and document activities live only in the Feed Cache and "are not persisted to content databases".

Whether a content database is available while it upgrades. The zero downtime page recommends Upgrade-SPContentDatabase during the process and says nothing about availability. The page on the in-place method with backward compatibility says of the same cmdlet that "the content for each database will be unavailable while this process is running on that database". Zero downtime is a statement about the farm. Whether each database also stays available during its own schema upgrade is not established from Microsoft's pages, and the rehearsal is where it is measured: time the upgrade of the largest database, and open a site in it while it runs.

Which packages to install. As above, the zero downtime page names the 2016 and 2019 packages; Subscription Edition ships one.

What zero downtime does not cover

• The database servers. SQL Server is behind the procedure, "not directly included in the ZDP process". Its own patching keeps the databases available only if the cluster fails over, and is planned separately.
• A way back. The procedure is a way forward. The full backup and the second farm are the ways back, and Chapter 42 costs each.
• Code on the farm. Farm solutions and other customisations are upgraded with the farm, and whether they work at the new build is a question for the rehearsal, not for the procedure.
• What the update changes. A feature update or a feature disabled by default, as in October 2026, changes the farm whatever the uptime.

Where this fits

Chapter 42 decides the calendar: how soon each update reaches production, where it is rehearsed and what the farm returns to if it fails. This article is the window itself. What each month's update fixes, version by version, with whether Microsoft marks a vulnerability as exploited, is on the security updates page, read from Microsoft's Security Response Center.

Sources, checked on 6 November 2026

• SharePoint Server zero downtime patching steps (Microsoft Learn)
• Software updates overview for SharePoint Server 2016, 2019, and Subscription Edition (Microsoft Learn)
• Install a software update for SharePoint Server (Microsoft Learn)
• Manage the Distributed Cache service in SharePoint Server (Microsoft Learn)
• Stop-SPDistributedCacheServiceInstance (Microsoft Learn)
• KB5002927, the October 2026 security update for SharePoint Server Subscription Edition (Microsoft Support)

Tags#sharepoint#lifecycle#security