Sometimes when patching a SharePoint farm with multiple SharePoint servers the SharePoint Configuration Wizard or the Central Admin complains that one or more servers in the farm are missing a specific fix although this fix has actually been installed on these server.
If you read certain blog posts or forum entries you will usually find the recommendation to run Get-SPProduct -local to fix this problem.
Why does this happen and why will executing the Powershell command Get-SPProduct -local fix the problem?
Before you upgrade to SharePoint Foundation 2013 or SharePoint Server 2013, you have to understand the components of you SharePoint 2010 deployment. This model illustrates how you prepare to upgrade, how to upgrade databases, and how to upgrade sites. APPLIES TO: 2013 2016 2019 SharePoint in Microsoft 365. Rule Name: Product / patch installation or server upgrade required. For a successful SharePoint 2010 to SharePoint 2013 upgrade, Plan and prepare your SharePoint 2013 destination, Plan how you intend to meet the time and space requirements for the migration, Perform dry runs, test the results and repeat the dry runs till satisfied, Identify and prioritize SharePoint 2010 customizations, Use PowerShell scripts if and wherever necessary. 0 site collection(s) are contained in the content databases. 0 site collection(s) still need upgrade. 1 other objects encountered, 1 of them still need upgrade or cannot be upgraded. I Tried psconfig command: psconfig -cmd upgrade -inplace b2b -wait and the result was: SharePoint Products Configuration Wizard version 15.0.4569.1503. Upgrade Blocked The server is blocked from the upgrade. The current server is installed with latest CU and it will remain blocked until all the SP servers in the farm are installed with the same version.
First of all let me explain how SharePoint Configuration Wizard running on one machine knows about fixes installed on the another machine in the same farm before SharePoint Configuration Wizard has been executed on these other machines.
A common understanding is that SharePoint updates are split into two different steps:
- Installation of the actual binaries on the machine
- Execution of the SharePoint Configuration Wizard to perform updates in the SharePoint databases
The reality is not that simple.
As explained in the past the SharePoint Configuration Wizard does not only perform database updates – it also does lots of stuff on the local machine like copying files around, settings ACLs on files, …
A less known fact is that installing the binaries also updates some information in the SharePoint config database.
How does this happen?
The installation packages for SharePoint fixes include some custom actions which (e.g.) guarantee that the WWW Publishing Service of IIS and the SharePoint Timer Services (owstimer.exe) get stopped before the binaries are installed and that these services will be restarted afterwards.
In addition one of these custom actions sets the CreateProductVersionJob registry value to '1' if the patch installed successfully:
Whenever the SharePoint Timer Services starts it checks the value of this registry key and verifies if it is set to 1. If this is the case the SharePoint timer service creates an instance of the Product Version Job timerjob based on the SPProductVersionJobDefinition which is scheduled to execute directly after the start of the SharePoint timer service.
This timerjob uses the windows installer information on the local machine and updates the information about all installed SharePoint packages (including all installed SharePoint hotfixes) in the SharePoint configuration database. At the end of this timerjob the CreateProductVersionJob registry value is set back to 0 to ensure that the timerjob is not created during the next restarts of the timer service.
In theory that should guarantee that the information about all installed patches on each machine in the SharePoint farm is correctly updated whenever the SharePoint Timer service starts on this box after a hotfix has been installed. But in some scenarios this can fail. Common reasons for this are that the SharePoint timer job is disabled on a specific server in the farm. Other reasons are that the account of the SharePoint Timer services does not have permission to read the information about the installed patches from the registry and therefor cannot update the information in the SharePoint Config DB.
Why does Get-SPProduct -local help here?
The reason is simple: this Powershell command performs exactly the same steps as done by the Product Version Job timerjob. You would not expect this as this Powershell command starts with a 'Get' verb. It is not obvious that this command performs update operations in the SharePoint database – but before retrieving the information for the current server from the database the Powershell command first ensures that this information is accurate by updating the information in the SharePoint configuration database.
When using this command the operation is performed directly in powershell.exe and not in a timerjob and it will use the account of the powershell.exe – usually the account of the person logged on to the machine which is often a different account than the farm account used by the SharePoint timer service.
In the past the SharePoint Configuration Wizard only verified if the most current patches are installed on all servers in the farm and showed a report with the servers which are missing fixes.
The latest version of the SharePoint Configuration Wizard (currently released with August 2016 CU for SharePoint 2016) has been updated to perform the same operation as the Product Version Job timerjob and Get-SPProduct -local if it identifies that the server it is running on is on the list of servers that misses a specific fix.
That means that running the SharePoint Configuration Wizard will fix the patch registration for the local server automatically if required – of course it cannot do this in case that other servers in the farm are affected. But running the SharePoint Configuration Wizard on these other servers will correct the issue on these servers without a need to run the Get-SPProduct -local Powershell command.
For SharePoint 2013 it is planned to release this change in a couple of months in one of the next CUs.
Here are some useful tips to help you carry out a successful SharePoint 2010 to SharePoint 2013 upgrade.
Plan and prepare your SharePoint 2013 destination
Before you actually begin upgrading your Site Collections and databases to SharePoint 2013, you need to plan how you will setup the SharePoint 2013 Farm, create and connect the database and how you will create the Site Collections. You may have to configure the Server operating system and the database like Windows Server 2012 and SQL Server 2012. Only when these are in place can you create your SharePoint 2013 environment. You also need to identify – how this environment will differ from SharePoint 2010, the missing components and install or upgrade them. An important task during the preparation is to identify Sites that are unused or sparingly used. You may decide not to upgrade them or, merge that content to other relevant Sites. Planning this way can simplify your upgrade and shorten the time needed as well.
Plan how you intend to meet the time and space requirements for the migration
You will need a large database to upgrade SQL, content databases, Site Settings, customizations, Web Parts, Workflows, etc. It's always safe to create double or triple the size of the existing SharePoint 2010 database as it will reduce the time needed, as well as help in managing changes after the upgrade.
Perform dry runs, test the results and repeat the dry runs till satisfied
Always execute dry runs to identify upgrade bottlenecks. This will help in – identifying the points where upgrade can seize up, testing the level of end user functionality after the upgrade, revealing areas that need to be mapped properly in order to assign correct permissions, revealing shortcomings that need to be rectified in order to bring the data up-to-date, etc. After a few attempts, the administrators may gain enough knowledge and confidence for a successful upgrade.
Sharepoint 2013 Upgrade Available
Identify and prioritize SharePoint 2010 customizations
It's essential to identify and clearly map user defined customization so that subsequent to the upgrade, SharePoint users can continue to work as usual. Hence it's necessary that you identify all the Custom Content Types, Workflows, Web Applications, Themes, Document Templates, Lists, Metadata columns, public URLs, Site Collections, Web Parts and all the possibilities in the Site Content. Any differences in these can interfere with the upgrade or the end result may not be satisfactory to the SharePoint user.
Upgrade Sharepoint 2010 To 2013
Use PowerShell scripts if and wherever necessary
Tasks like attaching the databases or mounting them are performed through scripts. These not only ensure a safe handling of the database but automate the task resulting in reduced or no errors. Hence it's necessary to script all those tasks that are better done in this manner.
