Matthew Chestnut is a Senior Consultant at ThreeWill. He has over 20 years of software development experience around enterprise and departmental business productivity applications. He has a proven track record of quality software development, on-budget project management and management of successful software development teams.
What I’ve Learned about Updating SharePoint Server
Back in March 2017, I recorded a podcast discussing “Best Practices for Updating SharePoint Large Farm Environments.” In this article, I’d like to provide additional details on how to install a software update for SharePoint Server.
For further reference, the Microsoft document “Install a software update for SharePoint Server” has additional details regarding several update options and more specific steps on how to implement the update itself.
The primary type of updates I’ve been doing involves installing service packs or cumulative updates to a production SharePoint farm, basically the same major version number. However, these steps can be following for a new release of SharePoint, too (though, be sure to read the installation notes for additional details.)
The process that I’ve been following is described in the Microsoft document as the “In-place with Manual Database Upgrades” option. What I like about this option is that there is minimal downtime for a production SharePoint farm. Our customers like that, too!
Here is what Microsoft says…
Use the in-place method with backward compatibility
This scenario takes advantage of the backward compatibility of SharePoint and the deferred upgrade feature to reduce the farm downtime that is required to deploy a software update. However, downtime is not completely eliminated. The sites and services will not be available while the database content is being upgraded.
Be sure to note that downtime is minimized, not eliminated, so I still perform the farm updates during maintenance windows (outside normal working hours.)
I break the update process down to these basic steps:
- Update Phase – This is the “binary installation” step where the new application assemblies are installed.
- Upgrade Phase – This is when the content databases are upgraded.
- Wizard Phase – Finally, the SharePoint Products Configuration Wizard is run on all SharePoint servers in the farm.
- If you have a load balancer you will need to take servers out of the rotation to install the updates, then put them back into the rotation after updated. For the purposes of this outline, I’m going to ignore the load balancer scenario.
- During this phase do not run the SharePoint Products Configuration Wizard (psconfig.exe). This is very important. The wizard is the last step in the process.
- I refer to this as the “binary installation” step because you simply run the downloaded executable file (.EXE) along with any supporting files (.CAB).
- As an aside, I follow the guidance provided in Russ Maxell’s blog post “Why SharePoint 2013 Cumulative Update takes 5 hours to install?” I use his script to launch the update, which stops some services that can cause the update to take a long time to complete.
- I start with the Central Administration server. I then do the same for all other SharePoint servers in the farm. This step can be run in parallel.
- Note that you may have to reboot the server once the update is complete. The update will tell you if that is necessary.
- Be sure to review the update logs to make sure the update completed without issues.
- In general, this step does not take too long to complete for each server.
- Once the “Update Phase” is completed, the farm is running in backward compatibility mode.
- The key point is that the farm is running and can service user requests.
- While this step is optional, it makes the final step of running the SharePoint Products Configuration Wizard execute much faster. If we don’t upgrade the content databases now, the configuration wizard will upgrade them, in serial fashion, one-by-one, with no real progress indicator.
- By using the Upgrade-SPContentDatabase PowerShell command, you can have upgraded several content databases in parallel. Just be sure not to overload your database server by performing too many upgrades concurrently. Typically, I do them one-at-a-time, using a PowerShell script, providing feedback as each content database is upgraded.
- This step tends to take the longest time, overall, especially if many content databases are involved.
- Note that the sites inside the content database won’t be able to respond to user requests while the content database is being upgraded.
- Now it’s time to execute the SharePoint Products Configuration Wizard on all servers in the farm to finalize the process.
- I start with the Central Administration server first. This usually doesn’t take too long to execute since the content databases have already been upgraded. However, there are some service databases that need to be reviewed and upgraded, if need.
- I then continue running the configuration wizard on the remaining servers in the farm.
Now, we’re done! This pattern has served me well over the years. If you have any suggestions or tips that you follow to update a production SharePoint farm, please let me know in the comments below!