Common mistake when perform SharePoint zero downtime patching
For SP2013 and before, when content database being updated, the SharePoint service need to be stopped to avoid locking the content database. Since SP2016, upgrade of content database will not cause down time. It makes zero downtime patching (ZDP) possible.
You can refer to follow 2 articles to understand the detail steps and explanation:
SharePoint Server zero downtime patching steps
SharePoint Server 2016/2019 Zero-Downtime Patching demystified
Below I will share some common mistakes during performing ZDP.
A) The installation wizard disappear
After you double click the patch installer can confirm the installation, the patch program is running. But in some cases the running window will be hidden. In order to verify the installation still on-going, open the “Task Manager” (pressing the [Windows] + [R] key combination. Enter the “taskmgr” command and click “OK” )
Look for the Process like below screen. You know the update is still running. Don’t panic, be patient and the program will appear again later.
B) SharePoint Central Administration Web Application content files will not be installed
When you run PSConfig command, below warning show up:
The SharePoint Central Administration Web Application content files will not be installed because a Central Administration Web Application is either off-line or does not exist on this server.
It is because the server do not have Central Administration function. Therefore the related content files not exist. You can ignore the warning. Below screen you can find a success upgrade of Central Administration contents.
C) Fail to run the side-by-side process command
According to standard procedure, after all servers have been through PSCONFIG successfully, you need to run below command:
$webapp = Get-SPWebApplication <webappURL> $webapp.WebService.SideBySideToken = <current build number in quotes, ex: “16.0.4338.1000”>
$webapp.WebService.update()
and failed like below screen:
The error will occur when you start the side-by-side command in server A and run the completion command in server B. To solve it, simply remote in server A and run the completion command (login with the same users, as mentioned in error message)
D) WSS_Logging failed to update during PSConfig run
During PSConfig is running, you may get below error:
An exception of type System.Data.SqlClient.SqlException was thrown. Additional exception information: The operation cannot be performed on database “WSS_Logging” because it is involved in a database mirroring session or an availability group. Some operations are not allowed on a database that is participating in a database mirroring session or in an availability group.
ALTER DATABASE statement failed.
It is because WSS_Logging could not be updated properly when the DB is being synchronizing in Always-On setup. To solve it, you need to remove the WSS_Logging from Availability Databases.
1/ In primary SQL server, select Always On High Availability > Availability Groups > {group name}(Primary) > Availability Databases
2/ Right click on WSS_Logging and Click Remove Database from Availability Group …
Then you can run the PSConfig command again. This time it should not prompt the SQLException.
In order to resume WSS_Logging back to Always-On:
1/ In secondary SQL server, select WSS_Logging(Restoring) and right click, click Delete.
2/ In primary SQL server, change WSS_Logging from Simple recovery mode to Full mode.
3/ Right click on WSS_Logging, click Task > Back Up …. Follow the wizard to make a full backup at local drive.
4/ Always On High Availability > Availability Groups > {group name}(Primary) > Availability Databases
5/ Right Click and select Add Database… add back WSS_Logging
