I’ve been migrating classic mode SharePoint 2010 sites to claims sites for a while now, so much that I even have a script to do it for me. However, for some reason I have never come across the problem I encountered today. The documentation on converting a classic mode web application to a claims based application I though was pretty solid on technet. Today I came across a strange issue where the site collection administrator was getting access denied in odd locations… or locations I thought were odd because SharePoint hadn’t security trimmed the links as I thought it would if access really was denied.

If your trying to setup or change the configuration of SharePoint on a development machines which has Office 2013 install you may encounter some strange errors relating to types such as: Failed to call GetTypes on assembly Microsoft.Office.InfoPath.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c. Could not load file or assembly ‘Microsoft.Office.InfoPath, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c’ or one of its dependencies. The system cannot find the file specified. This is related to the way in which SharePoint is loading certain assemblies and struggles with the new assembly for InfoPath.

I recently found a small bug in the SharePoint 2010 PowerShell comlets for creating the state service database using “New-SPStateServiceDatabase”. You will receive the rather unhelpful error message “Operation is not valid due to the current state of the object”. I believe this is a generic WCF error as that’s all I was able to find when researching what may cause the problem. However, it later transpired that this was because I was trying to use a database alias (or potentially database server) which SharePoint isn’t currently aware of, as using the alias (or database server) that was used for the initial farm setup didn’t result in the same issue.

If you have ever decided to make a blank site just because you know your going to start from scratch then find out that alot of the features your used to in a team site simply arn’t available or don’t work as they do in the team site? SharePoint has a number of hidden features which you can’t activate via the interface. If you have decided to use managed meta data and run into issues then its probably because the hidden “TaxonomyFieldAdded” feature isn’t available.

Symptoms Multiple Upload is disabled along with the Explorer option on Document Libraries. Resolution This problem is usually caused by a mismatch with Office and Internet Explorer. If you are workign on a 64bit version of Windows you will have two Internet Explorer links, one which opens the 32bit version (x86) and another which will open the 64bit version. The client integration options will only be available in the version which matches your office bit version.

The Get-SPHealthScore power shell commandlet is a simple commandlet that will query the value of the health score for any SharePoint 2010 URL (providing the header hasn’t been removed for security reasons which I will discuss in a later post). function Get-SPHealthScore([string]$url) { $request = [System.Net.WebRequest]::Create($url) $request.Method = "HEAD" $response = $request.GetResponse() if(($score = $response.Headers.Get("X-SharePointHealthScore")) -ne$null) { Write-Host $score } else { Write-Host 'The specified URL is not a SharePoint 2010 site or does not contain a health score' } } If you’re not familiar with the health score header, it is added to any SharePoint response for use by Microsoft Office applications in order for them to reduce their request rate if the server is particularly busy.

One of the things that annoys me about SharePoint is the way in which it automatically names the databases, even when you don’t use the wizard (don’t get me started on that). One thing you can’t do when you run the configuration wizard to create a brand new farm is to specify the database name for the central administration database. Instead you end up with something like “Content_Admin_abcdefg0093857378383”, if this annoys you as much as it does me then there is a solution.

If you’re working with larger SharePoint farms it’s conceivable that you may have a requirement for multiple User Profile Service Applications. This is completely supported, however one thing to be aware of is the fact that each User Profile Synchronization Service instance only supports 1 User Profile Service Application. Therefore it you need to run two User Profile Service Applications with Synchronization you will need at least two servers running the User Profile Synchronization Service, one for each.