This post is created to give an overall guide in the conducting of the SharePoint Products Configuration wizard. This is a monthly process that must be completed after every patching cycle. Patching of the SharePoint servers is essential to keeping your SharePoint on premise environment up to date and in the most stable condition.
This is by no means an official document supported by Microsoft, you should always follow their recommendations on taking care of your environment. What you do not want to happen is voiding any of their support because you followed my admittedly nonofficial guide. That said, I have spent countless hours conducting PsConfig on many different on-premise environments and my hope is that this can help you in conducting your own PsConfig in a timely and efficient manner. The most important thing is that your SharePoint environment is back up and running before your users get back on to conduct their regular workday. I personally conduct PsConfig on no less than six environments a month, I am not an official expert, but I hope that my experience can be helpful to you. In short, take everything I say here with a grain of salt. If what I say does not apply to you or your SharePoint environment, dismiss it and move on.
This document specifically pertains to monthly products configuration in on premise environments ranging from SharePoint 2010 to 2019. This obviously will not help you with SharePoint Online because that patching level is not managed internally. It also does not pertain to the initial iteration of products and configuration when you first install SharePoint. There may be additional configurations needed in the initial install and while you may find some pieces of this document helpful, I do not intend it for those purposes. Although I do recommend after your initial install of SharePoint on premises that you then update to the latest patch version and conduct PsConfig, which in that case, this document will be useful.
Overview
In general, you want your PsConfig to be conducted like below:
It does not always go well. It takes a long time, you run into new issues, and you got to troubleshoot your way out of it. I have had PsConfig nights where its lasted a couple of hours and everything went well, and I have other nights where I have call and wake people up because the issues were growing and I needed backup from other administrators to push through. You can prep by conducting PsConfig on lower environments and still run in to issues when conducting it on production. I have found in my experience that you cannot always predict that two environments will react the same to the patches.
In a lot of instances, you are going to spend a large portion of your night stuck in the same loop as below:
Do not get discouraged by this. Your goal is to get to the next error, then the next error, then the next one, eventually you will find your way to a successful completion of products of configuration. The logs outputted by the configuration wizard are very helpful
Useful Links
Stefan Gossner:
https://blog.stefan-gossner.com/
-he has the official Microsoft blog for SharePoint Patching
Every month Stefan releases the CU’s for each version of SharePoint on Premise. This is invaluable information for those of us that must conduct PsConfig every month.
here is what to look at on his site:
Visit Stefan Gossner’s website and look for the SharePoint Product family that relates to your SharePoint
There should be articles listed that tell you about this months Cumulative Update and if you click in those links you should see what improvements have been made and if there are any known issues are in this update
Clicking the KB link will take you to the page with all of the improvement and issue information. Pay attention to the Known Issues section, it may have no effect on your environment but should your users point out issues with your environment after PsConfig has been completed, come back and refer to the KB articles known issues to see if Microsoft has either a fix or workaround to resolve the issue.
Refer to the CU Build numbers as this will be your final guideline to make sure that your SharePoint environment is up to date
One thing of note here is the language independent and the language dependent fix. In this particular case in the picture above there is no language dependent fix, but there generally is at least two CU patches to cover both fixes. I would recommend that you always use the language dependent fix, I have run into issues before that were resolved by using the language dependent fix, there was no rhyme or reason for the fix being the solution as the environment was not using any other languages, but never the less the language dependent fix did resolve the issue. Generally these issues have been resolved using the language dependent fix have been of the visual nature.
Todd Klidnt
https://www.toddklindt.com/blog/default.aspx
he keeps a useful list of all SharePoint build numbers that easy for you to view.
I like to use his site because its quick and easy to match all the versions up.
Configuration Database Version
The configuration database version is the end all be all for your SharePoint patching process. Once you have successfully conducted PsConfig your configuration database version should match the build number that is listed in the most recent kb article that was installed in your SharePoint. Once the database version matches the build number you know your job has been complete. It is also useful for finding out what version of the patching you or on.
For instance, I have run across several customers that were having strange issues within their SharePoint environments and the first thing I asked them to do was show me their configuration version. I then proceeded to match that against Todd Klindts website and find out that they have gone years since they last updated their SharePoint. I am not an official Microsoft representative, but in my experience whenever I wasn’t up to at least two months prior to the presents patch level, Microsoft would strongly suggest that we get up to a more recent patch level before proceeding with troubleshooting. I have followed this guidance with my own customers and have easily resolved multiple issues just by getting the configuration database version up to date.
How to check it:
Go to Central Administration and select Manage servers in this farm from under system settings
We are looking for the server that hosts Central Administration. This is the server that you will start Psconfig from.
Also take note of the configuration database version number on this page. You can reference it to Todd Kindts website to see what version of the SharePoint patches your SharePoint is on.
PreChecks
These precheck below aren’t absolutely necessary, but they are good to keep in your back pocket for when you need them.
Get-spProduct -Local
Execute “Get-SpProduct -local” in PowerShell (with admin) on all servers. The results include which SharePoint products are installed on the server. Performing this command also adds MS patch information to configuration database. Can be executed at any time, has no direct impact on system except for updating the database. (~1-2 min/server)
Upgrade the Content Databases
Execute Upgrade content database from the server that hosts Central Administration using PowerShell (with Admin) using a Farm Administrator. Note that if you are unable to login as farm admin account to the server that you will need to use PowerShell to launch a session with this account with admin support.
This updates the Content Databases outside of PSConfig which gives you more control and reduces issues/delay during a PSConfig. Generates “Upgrade-“ log files for each database being upgraded which can be used to track status. Also recommended to review these log files and work to resolve their warnings and errors. PSConfig may still need to update other System and Service Application databases but majority will be handled here. It was also observed in one environment that some databases may get stuck when performing a lot of upgrades, simply watch the log files and if an hour passes with no updates to any of the logs, end the script and restart it. It will pick up where it was or move on, PSConfig will catch things as well if it needs too. (~1-2 min/server or more)
Get-SPContentDatabase | ?{$_.NeedsUpgrade -eq $true} | Upgrade- SPContentDatabase
Get-SPContentDatabase | Upgrade-SPContentDatabase
Validate upgraded. Cmd should return no results.
Get-SPContentDatabase | ?{$_.NeedsUpgrade -eq $true}Psconfig Via Gui
Click start on the server that is hosting Central Administration and then find SharePoint Products Configuration Wizard. Right click it and open as administrator
This should pop up
Below is telling you that this will cause down time in your environment. Select Yes if you are prepared for this.
Do not disconnect the server from the farm! Just click next
Leave the server as the host for Central Administration. Click next
Here is your final page, verify the settings and click next
Now Wait and Watch
When this server finishes succesfully, continue on for all the app and web servers in the farm. . When you are done do the following:
Central Administration > Upgrade and Migration > Check product and patch installation status and Scroll down the list and look for any errors. Normally marked in RED.
Central Administration > Upgrade and Migration > Review databases status
Check Status Column for anything that does not say “no action required”
Central Admin > Upgrade and Migration > Check upgrade status
All should report Succeeded.
PSConfig via PowerShell
I do prefer the GUI, but I have found out the hard way that sometimes you have to use the PowerShell. In that case, run the below:
PSConfig.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -installThe rest of the steps are very similar to the gui
