New in SharePoint 2016 it should be possible to install a CU or Service Pack without any downtime, our farms physical architecture was specifically designed to allow for this.
This includes actually installing the CU and rebooting servers!
First enable the side by side upgrade functionality at the web application level, this example is patching our TEST environment (it does not recycle IIS or cause any outages). Ensure you replace the web application URLs with your own and run this from a SharePoint PowerShell prompt on a server with a farm administrator account (usually the system or installer account):
$webapp = Get-SPWebApplication https://yourservername.com.au
$webapp.WebService.EnableSideBySide = $true
$webapp.WebService.update()
$webapp = Get-SPWebApplication https://yourmysitesservername.com.au
$webapp.WebService.EnableSideBySide = $true
$webapp.WebService.update()
The rest of this article assumes you have at least two web front ends and usually at least two other servers in your farm. Also assumes your web front ends are load balanced. Also assumes you have the CU file downloaded and ready to go on each server in the farm.
My farm consists of six servers and looks like this
- WEB1
- WEB2
- APP1
- APP2
- CUS1
- CUS2
First up
Remove WEB1 from the load balancer and let the connections drop. Assuming a physical load balancer of some sort such as an F5.
Cumulative Update Installation
Phase 1 – Patch install
- Install the patch on
WEB1 now that it’s out of the load pool
- Reboot once the CU is installed
- Run warmup as required and put back into the load balancer
- Take WEB2 out of the load balancer pool
- Install the patch on
WEB2
- Reboot once the CU is installed
- Run warmup as required and put back into the load balancer
- Install the new patch
on all the other servers that end with “1” so:
- APP1
- CUS1
- Reboot those servers after the CU installs and verify the services on those boxes are back online in Central Admin
- Install the new patch
on all the other servers that end with “2” so:
- APP2
- CUS2
- Reboot those servers after the CU installs and verify the services on those boxes are back online in Central Admin
All servers should now have the CU installed and should have been rebooted. There should have been no outages for end users. You can of course patch all “1” or all “2” boxes at the same time for faster results but it is riskier as you are down to a single APP or CUS box in case something does go wrong during the patching. Doing the front ends first and then the other servers is a more robust way of ZDP.
What can go wrong?
I’ve noticed occasionally not caused by ZDP, neither will cause an outage. Sometimes SharePoint CU’s fail to restart IIS and the service is stopped, all application pools are down even though the CU was installed successfully. Just manually start the service.
Phase 2 – PSCONFIG upgrade
During the ZDP process, you can run Upgrade-SPContentdatabase to reduce the overall time it will take to finish running PSCONFIG. Consider this if you have a large number of databases or select large databases.
So you can run:
get-spcontentdatabase | upgrade-spcontentdatabase
SQL doesn’t go down! Doing this first will speed up PSCONFIG.
WEB2 should be out of the load balancer!
- In TEST the Distributed Cache runs on WEB1 and WEB2 ensure before running PSCONFIG you also gracefully remove the distributed cache via PowerShell DON’T RUN THIS ON ALL SERVERS ONLY RUN IT ON WEB2 in TEST:
Remove-SPDistributedCacheServiceInstance
- Remove all the databases from HA using SQL Management Studio or PSCONFIG will fail
- Next run PSCONFIG from an elevated CMD prompt
Be sure that the required commands are run one server at a time and not in parallel.
cd C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\BIN
Then:
PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install
If WAIT proves troublesome you can use:
PSConfig.exe -cmd upgrade -inplace b2b -force -cmd applicationcontent -install -cmd installfeatures
Then via PowerShell on the WEB2 box restore the distributed cache:
Add-SPDistributedCacheServiceInstance
- Warmup WEB2 and put WEB2 back into the load balancer pool
- Remove WEB1 from the load balancer pool and repeat step 4 above
- At this point WEB1 and WEB2 should be fully patched and PSCONFIG should have run successfully, both WEB boxes should be back in the load balancer and working
- Now to run PSCONFIG on
the rest of the farm in the right order, starting with all the servers that end
in “1” so:
- CUS1
- APP1
So you’ve patched all the “1” servers, ensure in Central Admin that the services on them are in a healthy state before proceeding.
Then repeat the above process but for all servers ending in a “2”.
To reiterate be sure that the required commands are run one server at a time and not in parallel.
cd C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\BIN
Then:
PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install
Finally finish everything by switching the side by side to the new patch number (do this on both web applications):
$webapp.WebService.SideBySideToken = <current build number in quotes, ex: "16.0.4338.1000"
$webapp.WebService.update()
e.g.
$webapp = Get-SPWebApplication https://yourservername.com.au
$webapp.WebService.SideBySideToken = "16.0.4744.1000"
$webapp.WebService.update()
$webapp = Get-SPWebApplication https://yourmysitesservername.com.au
$webapp.WebService.SideBySideToken = "16.0.4744.1000"
$webapp.WebService.update()
During this whole process https://yourservername.com.au should be available and serving pages! ZERO DOWNTIME PATCHING.