Dela via


“The license state for the current server doesn't match the farm's license state”– SharePoint PSConfig Error

Recently I have involved in an interesting troubleshooting issue. There are many blog posts and TechNet discussions about this error. Thought that to post it here about my experience.

Here is the scenario. Customer has two Windows 2008 R2 Std machines (lets call it as srvsp1 & srvsp2) installed and configured with the following products.

  1. SharePoint Server 2010 Enterprise Edition
  2. Office Web Apps

Recently we have patched those two servers with June 2012 CU , for some troubleshooting one of the servers (srvsp2) was disconnected from the farm. After completing the installation while trying to add the server back to the farm by running the PSConfig we got the below error,

The license state for the current server doesn't match the farm's license state.
System.InvalidOperationException: The current server cannot be joined to this farm because the set of installed products does not match the products installed in the farm.

The license state for the current server doesn't match the farm's license state.
at Microsoft.SharePoint.Administration.SPFarm.Join()
at Microsoft.SharePoint.PostSetupConfiguration.ConfigurationDatabaseTask.CreateOrConnectConfigDb()
at Microsoft.SharePoint.PostSetupConfiguration.ConfigurationDatabaseTask.Run()
at Microsoft.SharePoint.PostSetupConfiguration.TaskThread.ExecuteTask()

Here are the troubleshooting steps.

# Step 1

Verify the configuration database has correct entries of all installed products. For that , we ran the following query against the “Objects” table of SharePoint configuration database.

Select * from Objects with (nolock) where properties like '%icrosoft.SharePoint.Administration.SPInstallState%'

From the result copy the “Properties” column value to notepad or any xml editor tool, in my case I have used Visual Studio.

image

Values that we are interested the ones highlighted in the below screenshot. Same is given below.

<sFld type="Guid">beed1f75-c398-4447-aef1-e66e1f0df91e</sFld>
<sFld type="Guid">d5595f62-449b-4061-b0b2-0cbad410bb51</sFld>

image

# Step 2

Once we get those GUIDs, next step is make sure that any difference in the actual Physical SharePoint server’s installed products and configuration database.

To do that, check the below registry location in both the SharePoint Servers (srvsp1 & srvsp2).

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\14.0\WSS\InstalledProducts

In our case it looked like this:

image

{90140000-1014-0000-1000-0000000FF1CE} REG_SZ BEED1F75-C398-4447-AEF1-E66E1F0DF91E
{90140000-110D-0000-1000-0000000FF1CE} REG_SZ D5595F62-449B-4061-B0B2-0CBAD410BB51
{90140000-112D-0000-1000-0000000FF1CE} REG_SZ 926E4E17-087B-47D1-8BD7-91A394BC6196

Here we can clearly see that the physical box has 3 entries whereas the configuration database has only 2 of them.

More details of the GUIDs are given below.

BEED1F75-C398-4447-AEF1-E66E1F0DF91E is for "SharePoint Foundation 2010",

D5595F62-449B-4061-B0B2-0CBAD410BB51 is for "SharePoint Server 2010 Enterprise"

926E4E17-087B-47D1-8BD7-91A394BC6196 is for “Office Web Companions 2010" (Office Web Apps)

(Just FYI, for more information all different product SKUs and it’s GUIDs please refer this article : https://msdn.microsoft.com/en-us/library/ff721969.aspx )

In our case, the Configuration database should have had 3 entries to match the registry in a normal farm. For some reason it was not updated with the office web apps production installation , it may caused by an installation issue.

Resolution:
=========

Run the following Power Shell commandlet on any working server in the farm. In our case it was srvsp1, the reason we would need to run from this server is because the problem server – srvsp2 is still not in the farm.

Set-SPFarmConfig –InstalledProductsRefresh

This will pick the entries from the server and reset the entries in the Config DB. To double-check, you can run the same SQL query mentioned above and confirm the <sFId /> values.

Hope this will helpful while troubleshooting this specific issue related to SharePoint. There are different scenarios as well, eg: configuration database may have the values but it was not there in the physical server’s registry. To fix that you may end up with uninstall and install the product to update it correctly.

Comments

  • Anonymous
    June 26, 2013
    Thanks for this, I'm installing SPS2013, consisting of four SPS 2013 Servers, after removing and trying to re-add a server to the farm I recieved  the above error. Checked the installed guids in the database and compared them to the servers. The one that wouldn't join had different guid Ids in the local registry. I simply exported the registry settings from another server on the farm and imported into the one with the incorrect guids. Re tried and joined successfully!! Thanks again for this article, very useful : )

  • Anonymous
    August 23, 2013
    Wow, thanks for posting this.  Basically just ran into this same issue and it was kind of mystifying.  Also have to say from reading the docs on Set-SPFarmConfig that I wouldn't have guessed -InstalledProductsRefresh would change the config db (as opposed to the local server).  Quite the useful little trick!

  • Anonymous
    September 04, 2013
    For SharePoint 2013, you can run SharePoint Product Configuration Wizard. The wizard tries to join the farm and if there's any mismatch of installed product on the current server of the farm, it will report the product name.

  • Anonymous
    March 24, 2014
    Dude, I coiuld hug you for posting this!  Flipping awesome sir, you really saved my bacon!! Cheers, Stowner  

  • Anonymous
    May 29, 2014
    I echo the sentiments!  THANK YOU!  I want to hug you or buy you a beer as a thank you!  Just a simple Set-SPFarmConfig –InstalledProductsRefresh did the trick for me as I had an extra entry in the config DB, somehow!  On to expanding my farm...

  • Anonymous
    January 19, 2015
    Thanks - nice, clear, to the point - made it easy to find out exactly where my problem was.  Saved me a whole lot of time. Much appreciated.