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.
Turns out there is a small paragraph at the very bottom of the article which essentially points out “don’t forget to update your super user/reader properties!”… which I did! Not sure why I haven’t come across this until now but hope this helps others with the same issue.
The below PowerShell should help you out in fixing the issue:
$wa = Get-SPWebApplication -Identity <web app url>
$wa.Properties[" portalsuperuseraccount"] = "i:0#.w|<super user account in domainlogin format>"
$wa.Properties["portalsuperreaderaccount"] = "i:0#.w|<super reader account in domainlogin format"
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=188.8.131.52, Culture=neutral, PublicKeyToken=71e9bce111e9429c. Could not load file or assembly ‘Microsoft.Office.InfoPath, Version=184.108.40.206, 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. Thanks to Hermanote for the workaround which is to remove the InfoPath feature from office only, and the error goes away.
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.
Its taken me a while to find this one as the state service isn’t usually one of the first service applications I configure, so it appears most of the other service application creation cmdlets don’t mind registering a new database host, but for some reason this one does!
If you use sql alias (as a best practice you should) and have a different alias for service applications, I would advise creating another service application before creating the state service database in order to make sure SharePoint is aware of the alias/dbserver.
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.
The feature can be activated via powershell using the following:
Enable-SPFeature -id “73EF14B1-13A9-416b-A9B5-ECECA2B0604C” -Url
Opening a file directly from a SharePoint 2010 on a workstation with Office 2007 installed can result in an “Unable to open file <filename>” dialog.
Install the latest Office 2007 Suite service pack (Currently Service Pack 3)
Multiple Upload is disabled along with the Explorer option on Document Libraries.
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. For example if you have 32bit office installed you will need to use the 32bit shortcut for internet explorer in order to use the mutliple upload and explorer options.
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).
$request = [System.Net.WebRequest]::Create($url)
$request.Method = "HEAD"
$response = $request.GetResponse()
if(($score = $response.Headers.Get("X-SharePointHealthScore")) -ne$null)
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. The score ranges from 0 – 10 although the server would unlikely respond with anything higher than an 8 as the higher the value, the busier the server up until the request is throttled.