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 domain\login format>"
$wa.Properties["portalsuperreaderaccount"] = "i:0#.w|<super reader account in domain\login format"
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.
Came across a problem recently while on site with a client which I have never come across before.
If you are trying to test your SharePoint Server web applications locally on a SharePoint server and you find that it is refusing to accept the locally logged on user or another user who should have access to the site by asking for your credentials 3 times before telling you that you don’t have access, it is because of a security feature within IIS which will not allow the use of integrated security for a hostheader that is not the server’s hostname.
Fortunately there is something you can do:
The feature is called “Loopback Security” and can be disabled through a registry key.
Create a new DWORD registry key called “DisableLoopbackCheck” in the location “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa”, then set its value to “1″.
You should then be able to access the sites with host headers.
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.
Open up Powershell and load the SharePoint addons (or start the SharePoint Powershell from the programs menu), then do the following:
- The first thing we need to do is get the ID for the database, the easiest way to do this is to type the following and locate the line with the Administration Content data base on it and copy the value from the ‘Id’ column:
- Next we need to load the database reference into a variable so that we can update the name
$admindb = Get-SPDatabase -Identity <Identity from step 1
- Change the name property of the new variable with the name you want the database to be called
$admindb.Name = “”
- Update the database (Note: this will update SharePoints record for the database but not the actual database, at this point central administration will become unavailable – see below)
- At this point Central Administration will no longer work as it doesn’t know the database exists, to correct this you first need to stop the following services so you can change the database’s actual name:
SharePoint 2010 Administration
SharePoint 2010 Time
- Using SQL Management Studio or an SQL Server client of you choice you can now update the name of the database, this must match the name that you specified in step 3 for the desired name.
- Finally start the two services we stopped in step 5 and everything will be back to normal only this time with a database name that hopefully makes sense and is named using a similar naming schema to the rest of your deployment databases.
Full PowerShell Prompts:
$admindb = Get-SPDatabase -Identity ""
$admindb.Name = ""