SharePoint Patching and Get-SPProduct -local

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?

Background information

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:

  1. Installation of the actual binaries on the machine
  2. 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:

01-regedit-4

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.

The workaround using Get-SPProduct -local

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.

Improvements in the SharePoint Configuration Wizard

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.

38 Comments


  1. Thank you for this post, I had to resort to using Get-SPProduct -local in a couple of occasions in the past and always wondered how a “get” command solved the issue.

    Reply

    1. Hi Benny,
      please read the last sentence of my article. 😉
      Cheers,
      Stefan

      Reply

      1. Great news!
        We’ve had problems with this on our bigger farms and had to use not only Get-SPProduct -local, but after that use
        PSConfig.exe -cmd upgrade -inplace b2b -wait -force -cmd applicationcontent -install -cmd installfeatures -cmd secureresources
        This fix will solve the issue. Thanks for posting your second demystified article on patching SharePoint 😉

        Reply

  2. This one is awesome! Will there be a similar fix for SP2010 environment also?

    Reply

    1. Hi Vikas,
      SP2010 is out of mainstream supports since roughly a year.
      That means that only security fixes will be created for SP2010 – no other product improvements.
      Cheers,
      Stefan

      Reply

  3. Great explanation! Count me among those that wondered why get-spproduct -local solved the missing patch/fix issue during our monthly maintenance windows.

    Reply

  4. Great post.. Dito the get- wonder that solves the actual set. Thanks Stefan

    Reply

  5. Hi, I wondered when the change would be released, will it be in December updates or likely to be 2017? Thanks.

    Reply

    1. Hi Rosanna,
      it is planned to be avail in December CU – but that is not yet a confirmed date.
      As usual fixes can be postponed if problems show up during testing.
      Cheers,
      Stefan

      Reply

  6. Great article, this saved me too 🙂 Thank you Stefan..

    Reply

  7. Hi Stefan! Thanks for the good news, is the patch update also run when you use the cmd psconfig and not only when running the “SharePoint Configuration Wizard” from the user interface?

    Reply

  8. Wonderful Post and thank you! however it seems he latest version of the SharePoint Configuration Wizard (currently released with August 2016 CU for SharePoint 2016) doesn’t perform the same operation ! I run the same issue in SharePoint 2016 with latest updates and the Configuration Wizard failed and shows missing KB even thought installed. Thanks for the power of PowerShell Get-SPProduct -local issue was solved.

    Reply

  9. Very useful information and very clear explanation. Thank you.

    Reply

  10. Hi Stefan,

    I am getting error “an error occured while running detection” while installing CU on Sharepoint SP1 15.0.4569.1506 server.

    Regards,
    Kurm

    Reply

    1. Hi Kurm,
      sounds to me as if your Windows MSI installer cache is corrupt.
      I would suggest to open a ticket with Microsoft support to get this analyzed in more details.
      Cheers,
      Stefan

      Reply


  11. Hi Stefan,
    i have a little problem with our SharePoint 2013 Farm…. two months ago i have installed the July hotfix in all servers….today i see in two particular server the message “Installation required” on 3 patch, but those patch are installed in this two servers…very strange… i run get-spproduct -local…reboot server…. but didnt change : – (

    You have an idea or workaround for this type of problems ?

    Thank you very much

    Reply

    1. Hi Roberto,
      if these fixes are indeed installed and get-spproduce -local did not resolve it, please open a ticket with Microsoft Support. This is unexpected and I haven’t seen this before. It requires more investigation to see what goes on here.
      Cheers,
      Stefan

      Reply

  12. I have installed March 2021 CU in owa server i can see the some updates are not installed.When i see the installed updates in control panel out of 43 more than half updates are still showing old updates while on other servers is was showing 41 new updates .Tried Get-spporduct -local

    Reply

  13. Hello,
    I have an “InstallRequired” status on my SP Server , so i tried the command “Get-SPProduct -local” but it show me this error : “Object reference not set to an instance of an object”
    If i install new CU could this fix the problem?
    I need solution please

    Reply

    1. I have not seen a scenario where get-spproduct -local would run into a null reference exception.
      Please check in the Uls log if you find the complete calls tack to get a better understanding of the issue.

      Reply

      1. I found missing files in Window\installer so i restored these files et i used Get-SPProduct -local that installed missing features and the “Install Required” Status was resolved , now i have Upgrade Blocked Status

        Reply

        1. Hi Ameur,

          Upgrade blocked means that there are servers in the farm which are missing patches that are installed on the local server. Upgrading the database would mean that these other servers would stop functioning. To prevent this the upgrade is blocked till the missing patches are installed on all servers in the farm.

          Cheers,
          Stefan

          Reply

          1. Thanks for your reply , i have “UpgradeRequired” on my servers what that meaning ?


          2. Hi Ameur,
            on the servers which are listed as “upgrade required” you need to run the config wizard.
            Cheers,
            Stefan


  14. Hi Stefan,
    I’m running into a problem when adding a new SharePoint 2013 server to an existing farm.
    When running the farm configuration wizard on the new server to add it to the farm, the wizard says an update is missing on the new server.
    It needs the update KB3114497, however, this update is no longer available for download.
    So there seems to be no option to add a new server to this farm.
    The existing farm however is already on much more recent version (feb 2022)
    Have you encountered such an issue before? Any idea on how this can be solved?

    Reply

  15. Hi Stefan,
    I have got the exact same issue as Thijs Deschepper, when adding new server to existing SharePoint 2013 farm, the only difference it says “Update for Microsoft SharePoint Enterprise Server 2013 (KB2920804) 64-Bit Edition (15.0.4693.1001)” is missing locally. This update is not available for download though. And I believe it won’t install either because our farm was patched to 15.0.5449.1000, May 2022 CU.
    I have to add new server to that farm because our current app server got file system corrupted and it constantly glitches (search is stopping all the time and there are some other issues).
    Any idea how to fix this issue is appreciated. Thank you in advance!

    Reply

    1. Also worth mentioning that “Get-SPProduct” does not work on this fresh install, it just gives the error: get-spproduct : Cannot access the local farm. Verify that the local farm is properly configured, currently available, and that you have the appropriate permissions to access the database before trying again.
      My user account is in Administrators and WSS_RESTRICTED_WPG_V4 groups on this server.

      Reply

      1. Hi Roman,
        this is expected.
        As the server is not part of a SharePoint farm the config database cannot be read which contains the relevant information.
        Cheers,
        Stefan

        Reply

    2. Well I was able to add the server to the farm using “-cmd installcheck -noinstallcheck” parameter.
      Then I ran PSConfigUI, which again complained about missing install. “Get-SPProduct -Local” didn’t help again.
      So I ran “psconfig.exe -cmd upgrade -inplace b2b -wait -force -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install” which failed, so I ran it with “-cmd installcheck -noinstallcheck” parameter.
      It finished successfully, but still I see “missing KB2920804 update” everywhere.
      I cannot use PSConfigUI because it constantly complains about missing update, and I don’t know if it is OK to continue using this server? =(

      Reply

      1. Hi Roman,
        using -cmd installcheck -noinstallcheck to overcome issues with missing patches is unsupported.
        You would need to removed the server from farm the farm to get back into a supported state.
        Cheers,
        Stefan

        Reply

    3. Good news Stefan, I was able to find old CU installation package. Interestingly that setup ran well and now I see no missing install. But it does not look well for me, that this happened (as far as I understand it should not have). Here is the screen shot of how it looks like in case you are interested
      https://i.ibb.co/Kjbz2gd/sharepoint-2013-missing-patch.png

      Reply

    4. Hi Roman,
      if a patch is missing which you cannot download there are two options:
      1) you can reinstall the other servers in the farm without the missing update
      2) you can open a support ticket with Microsoft to assist you with this.
      Cheers,
      Stefan

      Reply

      1. Hi Stefan, thank you for replies. I am so happy that I was lucky to find that missing CU! No need to reinstall other servers =)

        Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.