SharePoint 2010 – The 14 Hive and other important directories

The 14 Hive – Folder Location
The 14 Hive folder is located at the following path
C:Program FilesCommon filesMicrosoft SharedWeb Server Extensions14

14hive

The 14 Hive – Folder Structure
The 14 Hive has a definite folder structure which holds the core SharePoint server files.

  • ADMISAPI:- It contains soap services for Central Administration. If this directory is altered, remote site creation and other methods exposed in the service will not function correctly.
  • Bin:- The directory contains all the core binary files, utilities which used by SharePoint Services.  command line tools such as STSADM.EXE also present in this folder.
  • Config:- This directory contains files used to extend IIS Web sites with SharePoint Server. If this directory or its contents are altered, Web application will not function correctly.
  • HCCab:- This directory has a set of cab files which has content information used by the SharePoint help system.
  • Help:- The folder contains html help file (.chm) used by the configuration wizard.
  • ISAPI:- This directory contains all the standard Web Services for SharePoint and resources and configuration files that the web services use.
  • Logs:- This is the folder where we can have all the SharePoint related logs will see. This is important when any problem or error occur in SharePoint you have to trace the logs files in this folder to get the error messages.
  • Resources:- This directory contains the core.resx file used for creating language packs for SharePoint.   by which different SharePoint sites with different languages and cultures can be create.
  • Template:- It contains the core web site functionality like the features, templates, configurations, resources of a web site.
  • UserCode:- This directory contains files used to support sandbox solution.
  • Web Clients:- This directory contains files related to Client Object Model.
  • Web Services:- This directory is the root directory where SharePoint back-end Web services are hosted, for example, Excel and Search.


Other Important SharePoint 2010 Directories
1) C:Inetpubwwwrootwss – This directory (or the corresponding directory under the Inetpub root on the server) is used as the default location for IIS Web sites.
2) C:ProgramFilesMicrosoft Office Servers14.0 – This directory is the installation location for SharePoint Server 2010 binaries and data. The directory can be changed during installation.
3) C:ProgramFilesMicrosoft Office Servers14.0WebServices – This directory is the root directory where SharePoint back-end Web services are hosted, for example, Excel and Search.
4) C:ProgramFilesMicrosoft Office Servers14.0Data – This directory is the root location where local data is stored, including search indexes.
5) C:ProgramFilesMicrosoft Office Servers14.0Logs – This directory is the location where the run-time diagnostic logging is generated.

“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 , 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.

2577.image_3AD92119

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

beed1f75-c398-4447-aef1-e66e1f0df91e
d5595f62-449b-4061-b0b2-0cbad410bb51

4774.image_1834E29E

# 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_MACHINESOFTWAREMicrosoftShared ToolsWeb Server Extensions14.0WSSInstalledProducts

6837.image_75FCD717

{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 http://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 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.

Install & Configure SharePoint 2013 with SQL Client Alias

* Though this topic is very simple and highly recommended approach in the enterprise deployments, I have seen many deployments which are not following this approach. E.g.: Using SQL client alias for SharePoint installations will be really useful if you want move all databases to another SQL Server by just making alias change point to the new SQL server.

* In this post I’m going to cover how we can install & configure SharePoint 2013 Preview with SQL Client Alias. Though this post is talking about SharePoint 2013 preview, the underlying concept will be same for SharePoint 2010 & SharePoint 2013 RTM.

* In my test lab, I have total four virtual machines configured. This post is based on a SharePoint small server farm for setup and proof of concept. I will refer to this same environment in my future blog posts, there will be more servers adding to the existing server farm.

litdc : is the domain controller and AD server (domain : litware.local), this machine is installed with Windows 2008 R2 + SP1

litsql1 : is the SQL server machine which is installed with SQL Server 2012 RTM with Windows 2012 Server Release Candidate.

litsp1 : is the one of the SharePoint Servers, I’m configuring this server with WFE role. This server is installed with SharePoint Server 2013 Preview with Windows 2012 Server Release Candidate.

litsp3 : is the one of the SharePoint Servers, I’m configuring this server with Application role (central administration and other services). This server is installed with SharePoint Server 2013 Preview with Windows 2012 Server Release Candidate. Name of the server is litsp3 as I’m planning to add one more SharePoint Server litsp2 to with WFE layer later. 

In this post I’m only concentrating on the part of configuring SharePoint Servers with SQL Client Alias.

# Step 1

To harden the security for SQL server it is highly recommend to install SQL Server with named instance with custom port and block all default SQL specific ports. So, that is our first step to consider while setting up the SQL Server.

While installing the SQL Server in litsql1 server I have installed it with named instance “litsql1sql1”.

* After the installation of SQL Server with named instance, we have to assign a custom static port number for the SQL Service. You can do this in “SQL Server Configuration Manager”. 

* We have to configure it by taking the TCP/IP properties of “Protocols for SQL1 (SQL1 instance name)”. By default, whenever we install SQL Server with named instance it will assign a “TCP Dynamic Port”, we have to clear it out in the same location (just before TCP Port).

After doing the above step, we have to restart the “SQL Server Service” to use the newly assigned port.

To confirm the usage of the new port, you can either look at the SQL Server Logs in the SQL Server Managements studio or can look at the windows application event logs directly.

# Step 2

Once the above port validation is over the next important step is  open the custom port for In bound connections if you have firewall enabled. Just need to create a new Inbound Rule for allowing connections for the custom port, in my case it is  “65000”

# Step 3

Alright, now we can go to SharePoint side. 

* In my case there are two SharePoint Servers to be configured, one WFE – litsp1 and one Application Server – litsp3.

* Since I’m going to host central administration in litsp3

* I’m going to configure this server first. Main configuration needs only before running the PSConfig. * I have installed SharePoint 2013 Preview in both of these servers initially.

Before running the PSConfig , we have to configure the SQL Client Alias. There will be two versions of cliconfig in 64 bit operating system.

C:WindowsSystem32cliconfg.exe  – 64 bit version of cliconfig.exe

C:WindowsSysWOW64cliconfig.exe – 32 bit version of cliconfig.exe

SharePoint 2010 & 2013 are 64 based so we have to configure the 64 bit version of cliconfig.

C:WindowsSystem32cliconfg.exe

* In my test case I have created alias “spsql” with network library type “TCP/IP” (don’t use named pipes).
 
* In the Server Name textbox we have to give the SQL Server name (litsql1) and then uncheck the “Dynamically determine port” option and give the custom port number, in my case “65000”. After saving the changes you can validate the registry settings to make sure that it is applied correctly.

# Step 4

* At this point we are good to run SharePoint PSConfig and provision a new server farm.

* While creating a new farm, provide the SQL Client Alias “spsql” instead of the the SQL Server Instance name “litsql1sql1”.

* After finishing the PSCofig tasks, central administration site will be provisioned the SQL Server name will be used as “spsql”. 
* To connect other servers to the SharePoint farm we have to repeat step #3 in all servers. In my test lab I have one more server to be added to the same farm.