This post will try to explain how you can easily configure a SharePoint web application its superuser and superreader accounts. SharePoint uses these accounts for its caching system. Out of the box system accounts are used for this and you might get a warning in your event log periodically. However, if you get this part wrong, all of your users might end with an access denied message.

1. Here’s how you can do it for a claims based Web application that’s configured with a claims provider as authentication provider.

$webappurl = https://portal.contoso.com
###
### encode users
###
$mgr = Get-SPClaimProviderManager
$tp = Get-SPTrustedIdentityTokenIssuer -Identity "CONTOSO ADFS Provider"
#set super user to windows account (claims based)
$superuser = S_SPS_SU@CONTOSO.COM
$superuserclaim = New-SPClaimsPrincipal –ClaimValue $superuser -ClaimType http://schemas.xmlsoap.org/claims/UPN -TrustedIdentityTokenIssuer $tp
$superuserclaimstring = $mgr.EncodeClaim($superuserclaim)

#set read user to windows account (claims based)
$readuser = S_SPS_SR@CONTOSO.COM
$readuserclaim = New-SPClaimsPrincipal –ClaimValue $readuser -ClaimType http://schemas.xmlsoap.org/claims/UPN -TrustedIdentityTokenIssuer $tp
$readuserclaimstring = $mgr.EncodeClaim($readuserclaim)

###
### web policies
###
$webApp = Get-SPWebApplication $webappurl

#SuperUser
$policy = $webApp.Policies.Add($superuserclaimstring, $superuser)
$policyRole = $webApp.PolicyRoles.GetSpecialRole([Microsoft.SharePoint.Administration.SPPolicyRoleType]::FullControl)
$policy.PolicyRoleBindings.Add($policyRole)
$webApp.Update()
#ReadUser
$policy = $webApp.Policies.Add($readuserclaimstring, $readuser)
$policyRole = $webApp.PolicyRoles.GetSpecialRole([Microsoft.SharePoint.Administration.SPPolicyRoleType]::FullRead)
$policy.PolicyRoleBindings.Add($policyRole)
$webApp.Update()

###
### web properties
###

#$webApp = Get-SPWebApplication webappurl
$webApp.Properties["portalsuperuseraccount"] = $superuserclaimstring
$webApp.Properties["portalsuperreaderaccount"] = $readuserclaimstring
$webApp.update()

2. Here’s how you can do it for a claims based Web application that’s configured with Windows authentication.

$webappurl = https://portal.contoso.com
###
### encode users
###
$mgr = Get-SPClaimProviderManager
#set super user to windows account (claims based)
$superuser = "CONTOSO\S_SPS_SU"
$superuserclaim = New-SPClaimsPrincipal -identity $superuser -IdentityType "WindowsSamAccountName"
$superuserclaimstring = $mgr.EncodeClaim($superuserclaim)

#set read user to windows account (claims based)
$readuser = "CONTOSO\S_SPS_SR"
$readuserclaim = New-SPClaimsPrincipal -identity $readuser -IdentityType "WindowsSamAccountName"
$readuserclaimstring = $mgr.EncodeClaim($readuserclaim)

###
### web policies
###
$webApp = Get-SPWebApplication $webappurl

#SuperUser
$policy = $webApp.Policies.Add($superuserclaimstring, $superuser)
$policyRole = $webApp.PolicyRoles.GetSpecialRole([Microsoft.SharePoint.Administration.SPPolicyRoleType]::FullControl)
$policy.PolicyRoleBindings.Add($policyRole)
$webApp.Update()
#ReadUser
$policy = $webApp.Policies.Add($readuserclaimstring, $readuser)
$policyRole = $webApp.PolicyRoles.GetSpecialRole([Microsoft.SharePoint.Administration.SPPolicyRoleType]::FullRead)
$policy.PolicyRoleBindings.Add($policyRole)
$webApp.Update()

###
### web properties
###

#$webApp = Get-SPWebApplication webappurl
$webApp.Properties["portalsuperuseraccount"] = $superuserclaimstring
$webApp.Properties["portalsuperreaderaccount"] = $readuserclaimstring
$webApp.update()

3. And here’s for a SharePoint web application that is in classic (windows) authentication mode:

#for a Windows site:
$webappurl = https://portal.contoso.com
#Windows users the domain\group notation
$superuser = "CONTOSO\S_SPS_SU"
$readuser = "CONTOSO\S_SPS_SR"

#add the policies
$webApp = Get-SPWebApplication $webappurl

$policy = $webApp.Policies.Add($superuser , $superuser )
$policyRole = $webApp.PolicyRoles.GetSpecialRole([Microsoft.SharePoint.Administration.SPPolicyRoleType]::FullControl)
$policy.PolicyRoleBindings.Add($policyRole)
$webApp.Update()

$policy = $webApp.Policies.Add($readuser , $readuser )
$policyRole = $webApp.PolicyRoles.GetSpecialRole([Microsoft.SharePoint.Administration.SPPolicyRoleType]::FullControl)
$policy.PolicyRoleBindings.Add($policyRole)
$webApp.Update()

Bonus: here’s how to encode a group instead of a user. Not useful for the superuser/superreader account, but it might come in handy if you want to configure user policies.

$groupnameClaims = "GG_SPS_ADMINS"
#Windows users the domain\group notation
$groupnameWindows = "CONTOSO\GG_SPS_ADMINS"

$mgr = Get-SPClaimProviderManager
$tp = Get-SPTrustedIdentityTokenIssuer -Identity "CONTOSO ADFS Provider"

#get the string for users authenticating over claims
$claim = New-SPClaimsPrincipal -ClaimValue $groupnameClaims -ClaimType http://schemas.xmlsoap.org/claims/Group -TrustedIdentityTokenIssuer $tp
$claimstr = $mgr.EncodeClaim($claim)

#get the string for users authenticating over classic windows
$windowsprincipal = New-SPClaimsPrincipal -identity $groupnameWindows -IdentityType "WindowsSamAccountName"
$windowsstr = $mgr.EncodeClaim($windowsprincipal)

Lately we had to stop (and start) the SharePoint Foundation Web Application services and the Central Admin services on several servers. We noticed that the bindings that were previously active were now totally different from what they were.

Some background: we got some SharePoint Web Applications which are made available over Claims Authentication. In order for these applications to be crawled by the Search service we extended them so that they could be made available over Windows Authentication. Besides that, we also had some URL and TCP/IP Port changes over the past year.

It seems that we did several changes on Alternate Access Mappings (AAMs) (SharePoint Central Admin) and on the IIS bindings (IIS Management Console). And that’s where the problem lies. When you create a Web Application, or extend it, you are asked some parameters (like host headers), and these are stamped in the SharePoint configuration database. These are the settings that are used when you start the “SharePoint Foundation Web Application service” on a given SharePoint server. When you modify AAM’s or IIS bindings, these settings become inconsistent.

Here’s how you can retrieve what’s currently known for your web application:

• $web = Get-SPWebApplication -Identity https://site.customer.com
• $iisDef = $web.GetIisSettingsWithFallback("default")
• $iisDef.ServerBindings
• $iisDef.SecureBindings

If you are interested in the settings (bindings) of an extended site, you have to pass the correct zone along. E.g. for the custom zone:

• $iisCust = $web.GetIisSettingsWithFallback("custom")

Now I tried editing these in several ways, but it seems like this information is really read only. The only way I found to modify these is to go through the Central Admin web application management section and choose the “remove SharePoint from this site” option when selecting a web application (below the delete button). Afterwards you can extend the web application again. I performed this for several sites and it’s not really that painful. Don't forget, your site becomes unavailable in the whole farm as it's deprovisioned and re-deployed afterwards. Obviously this can be scripted as well.

Here’s the source of my information: MSDN Blogs: How to properly change the Host Header URL of a web application in SharePoint 2010

Things I’ve learned #1: the things I conclude from my tampering with web applications:

1. There’s no way to specify what IP to listen on when creating a web application/ extending it
2. There’s no way to select a specific certificate when creating a web application/ extending it (you can select “use SSL” though)

Out of these 2 I assume that you can modify these directly in IIS without breaking anything. Obviously if you start the SharePoint Foundation Web Application service it’s up to you to (re)do the proper IIS configuration.

Things I’ve learned #2:

1. Always specify a host header. for port 80, for use SSL and for custom ports.

As SharePoint doesn’t allow you to specify an IP, you’ll be blocked from creating an other site with “use SSL” checked if you don’t specify host headers.

Things I’ve learned #3:

Perhaps a bit dirty, but we noticed that some of our sites weren’t being added in IIS. The following lines re-triggered the registration of the web application in IIS without having to stop and start the SharePoint Foundation Web Application service.

• $web = Get-SPWebApplication https://site.customer.com
• $web.ProvisionGlobally()

Lately we got notified of a small bug in our claim provider we deployed on a SharePoint 2010 farm. In short, when using the “regular” people picker results were being returned just fine. It allowed people to search for both user and group claims. Now it seems that you can modify the behavior of the default picker. The default one results in a picker which is called "Search for People and Groups”. But by specifying some parameter of the field you are defining you can also force it to only “Search for People”. The latter however didn’t returned anything.

Here’s a small overview of the allowed types: MSDN: SPFieldUserSelectionMode

• UserSelectionMode = PeopleAndGroup

• UserSelectionMode = PeopleOnly

We still didn’t had any clue why the people picker wasn’t returning anything. So we decided to double check our code behind the searching and resolving. The only reason we found that could cause the people picker to return nothing was this line of code:

if (!EntityTypesContain(entityTypes, SPClaimEntityTypes.FormsRole))
      return;

To be honest we had that line in there because we created our custom claim provider based upon this sample: MSDN: Claims Walkthrough: Writing Claims Providers for SharePoint 2010 This article has the following statement:

One thing that is important to note here—if you are not creating identity claims, then a claim can be used to provision almost any security item in a SharePoint site except for a site collection administrator. Fortunately, we do get a clue when a search is being performed for a site collection administrator. When that happens, the entityTypes array will have only one item, and it will be Users. In all other circumstances you will normally see at least six items in the entityTypes array. If you are the default claims provider for a SPTrustedIdentityTokenIssuer, then you do issue identity claims, and therefore you can assign one of your identity claims to the site collection administrator. In this case, because this provider is not an identity provider, we will add a special check when we fill the hierarchy because we do not want to add a hierarchy we know we will never use.

After reading that a few times we started putting things together. We added some verbose logging to print the entityTypes and we found out that the only EntityType present was the Users one when searching in the “Search for People” picker. This small if statement exist to prevent you from adding a non-identity claim as a site collection administrator. In our case we can easily adjust or even skip this test altogether because we are using identity claims anyhow! We are not allowing to pick a claim like “favorite color”, which more than one user could have, but we set claims based upon the “UPN” which is an identifier claim in our setup.

Kudos to @ArneDeruwe who originally wrote this claim provider for this project. Together we were able to tackle this problem.

In one of my projects we have a SharePoint solution which is deployed in a Dev, Test, Acceptance and Production environment. It seems that throughout the environments here and there we got some attention points. The SharePoint health analyzer found several problems such as MissingFeature, MissingSetupFile, MissingWebPart, SiteOrphan and all of those fall under the Missing Server Side Dependencies rule. The funny thing is that in most cases these are false positives. Mostly there’s a deleted object referencing a feature or a WebPart hasn’t be retracted completely. Both case don’t have any side effects. But we can’t have the Health Analyzer unhappy do we?

At first sight you find quite some good articles on how to resolve this:

• Phil Childs: MissingFeature
• Phil Childs: MissingSetupFile & MissingWebPart

There’s even a utility on codeplex which is also often referenced in this context:

• SharePoint Feature Administration and Clean Up Tool

However what I didn’t realized at fist is that since SharePoint 2010 SP1 there seems to be recycle bin at various levels.

Example #1: in order to fix the MissingWebPart issue I navigated to http://site.custom.com/_catalogs/wp which gave me an overview of all WebPart files present at that site.  The one referenced in the Health Analyzer was present as well. As we no longer needed it I deleted it. Simply deleting it did not make the Health Analyzer happy.

If you want this error to go away you also need to delete it from the site recycle bin:

And also from the site collection recycle bin:

Example #2: Besides files SharePoint also keeps entire sites in the recycle bin. So you might be having a MissingFeature problem because SharePoint retains a previous/test version of a site for you. You can easily retrieve those with PowerShell:

• $site = Get-SPSite https://site.customer.com;
• $site.RecycleBin | ?{$_.ItemType -eq "Web"};
• $deletedWebs = $site.RecycleBin | ?{$_.ItemType -eq "Web"};
• $deletedWebs | % {$site.RecycleBin.Delete($_.Id)}

The second line will print the deleted sites, the 4th line will actually delete them from the Site recycle bin.

Example #3: my last example has to to with deleted site collections. It seems that every time you delete a site collection they are also retained by SharePoint. If these reference features that you no longer wish to deploy, the Health Analyzer will be unhappy as he finds site collections in the databases without the features being available on the farm. After some searching I found the following SQL query:

USE [SPS2010_ContentDB]
SELECT * FROM features
JOIN webs ON (features.webid = webs.id)
WHERE featureid = 'e8c6c808-ab0b-43ab-bdbc-a977753d754e'

The featureID comes from the Health Analyzer information.We then looked through some more tables like:

SELECT *  FROM [SPS2010_ContentDB].[dbo].[AllSites]

And we saw that there were a lot more entries then we’d expect. So that’s when we realized there had to be some recycle bin for site collections. Some googling quickly gave us: SharePoint 2010: SP1 Site Collection Recycle Bin

In order to see what deleted sites are currently know to SharePoint. The command below will give ALL deleted sites collections but you can also scope the command to a Web Application.

• Get-SPDeletedSite

In order to delete all sites in the recycle bin:

• Get-SPDeletedSite |Remove-SPDeletedSite

However after executing the last command you’ll see that the Health Analyzer is still unhappy and that your SQL query still shows the entries. It seems that there’s a time job on SharePoint which handles the cleanup once a day. If you want to speed up the process, just do a run now on the Gradual Site Delete time job.

Some additional queries I used in the MissingSetupFiles & MissingWebPart problems:

• MissingSetupFile:

USE [SPS2010_ContentDB]
SELECT * FROM AllDocs
WHERE SetupPath = 'Features\EPS.SPS.Core_jQueryReferenceWebPart\jQueryReferenceWebPart\jQueryReferenceWebPart.webpart'

• MissingWebPart:

USE [SPS2010_ContentDB]
SELECT * FROM AllDocs
INNER JOIN AllWebParts ON AllDocs.Id = AllWebParts.tp_PageUrlID
WHERE AllWebParts.tp_WebPartTypeID = 'e8c6c808-ab0b-43ab-bdbc-a977753d754e'

One of the things which pops up quite fast when working with SharePoint and claims based authentication is the weird identifiers you find throughout SharePoint. In one of my troubleshooting sessions I stumbled upon this post which provides a nice picture of the meaning of several parts of an encoded claim.

The post : How Claims encoding works in SharePoint 2010

The picture: Link to original picture (larger)

One thing I came across as well is that when you encode a principal in PowerShell, the shell isn’t capable of showing all encoded strings. Especially the 6th character is often displayed as a ? while in reality it’s some exotic character. The following lines of PowerShell code should print the SharePoint representation of the given claim (with it’s type and value)

• $mgr = Get-SPClaimProviderManager
• $tp = Get-SPTrustedIdentityTokenIssuer -Identity "Cust ADFS Provider"
• $cp = Get-SPClaimProvider -Identity "ADFSClaimsProvider"
• $claim = New-SPClaimsPrincipal -ClaimValue "readPermission" -ClaimType http://schemas.customer.com/claims/technicalrole -TrustedIdentityTokenIssuer $tp
• $mgr.EncodeClaim($claim)

However if you want to see how the encoded claim really looks, I advise you to capture the output of $mgr.EncodeClaim($claim) and pipe it to Out-File claim.txt E.g.

• $mgr.EncodeClaim($claim) | out-file claim.txt

To conclude this post, I would advise to never hardcode any encoded claims in your scripts or code. After all the 4th character is generated on a per farm base and could very well be different in another SharePoint environment. As long as you keep encoding the claim based upon the actual input (claim value, type & provide), you should be safe though.

I have a colleague who wrote a Custom Claim Provider for a SharePoint deployment which uses ADFS as its authentication provider. The goal of the custom claim provider was to ensure that the people picker would resolve things by searching our Active Directory. One of the other things we were working on was to set permissions on certain sites from within .NET code. Online we found several ways to get this task done, but my colleague kept running into an ArgumentException error.

I tried to simulate what he was doing in PowerShell. Our troubleshooting would benefit from this as a typical refresh of the custom code on SharePoint takes several minutes. One thing we quickly found out that it was working for a claim type we’ve had available in SharePoint and which was also specified in the claims provider. However lately we registered a new claim type in SharePoint, and for some reason this was not being accepted. Here’s how we registered it:

From a SharePoint PowerShell prompt:

• $claimType = http://schemas.customer.com/claims/entity
• $claimTypeSPS = "Entity"
• $ti = Get-SPTrustedIdentityTokenIssuer "Cust ADFS Provider"
• $ti.ClaimTypes.Add($claimType)
• $ti.Update()
• $map = New-SPClaimTypeMapping –IncomingClaimType "$claimType" –IncomingClaimTypeDisplayName "$claimTypeSPS" –SameAsIncoming
• Add-SPClaimTypeMapping –Identity $map –TrustedIdentityTokenIssuer $ti

Typically this should be enough to start using the claim type “Entity” in SharePoint. However when we executed the following lines:

• $mgr = Get-SPClaimProviderManager
• $tp = Get-SPTrustedIdentityTokenIssuer -Identity "Cust ADFS Provider"
• $cp = Get-SPClaimProvider -Identity "ADFSClaimsProvider"
• $claim = New-SPClaimsPrincipal -ClaimValue "readPermission" -ClaimType http://schemas.customer.com/claims/technicalrole -TrustedIdentityTokenIssuer $tp
• $mgr.EncodeClaim($claim)

We stumbled upon this error:

In words: Exception calling "EncodeClaim" with "1" argument(s): "Exception of type 'System.ArgumentException' was thrown.
Parameter name: claimType"
At line:1 char:194
+ $claim = New-SPClaimsPrincipal -ClaimValue "readPermission" -ClaimType "http://schemas.customer.com/claims/entity" -TrustedIdentity
TokenIssuer $tp -IdentifierClaim:$false;$mgr.EncodeClaim <<<< ($claim)
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : DotNetMethodException

So we started digging into it. Long story short, as far as we can tell, from the moment you specify a custom claim provider on your Security Token Issuer, you must include all claims of the security token issuer in the custom claim provider. You can easily check which claim types are currently visible to SharePoint by executing the following lines:

• $cp = Get-SPClaimProvider -Identity "ADFSClaimsProvider"
• $cp.ClaimProvider.ClaimTypes()

Remark:

1. Don’t confuse the Get-SPTrustedIdentityTokenIssuer and the Get-SPClaimProvider.
2. Often the name of the custom claim provider is the same as it’s proper name, but without spaces. This property is also called the internal name.

Here’s a screenshot, I could clearly see that Entity was not included:

And here’s a small code snippet:

Now after adding the claim type in the code, and redeploying the necessary assemblies, things still didn’t work. As far as we can tell the following actions are also required:

1. Restart your SharePoint PowerShell shell
2. Run the Update() method on the Claim Provider Manager ($mgr = Get-SPClaimProviderManager and $mgr.Update() )

And now we can see that we can successfully encode the claim:

Conclusion #1: whenever you write a custom claim provider, make sure to include all the claim types you want to use for that Token Issuer. It doesn’t matter whether you only want to add them programmatically or if you want them to be available for regular users through the graphical interface.

However, after this we were still having issues. We were trying to add the encoded claim as a member of a SharePoint group. This would allow people having the specified claim to access the site we are securing. Here’s the command we executed:

• $tp = Get-SPTrustedIdentityTokenIssuer -Identity "Cust ADFS Provider"
• $url = https://sharepoint.customer.com
• $group = "Visitors"
• $claimType = http://schemas.customer.com/claims/entity
• $claimValue = "DepartmentX"
• $web = Get-SPWeb $url
• $SPgroup = $web.SiteGroups["$group"]
• $principal = New-SPClaimsPrincipal -ClaimValue $claimValue -ClaimType $claimType -TrustedIdentityTokenIssuer $tp
• $SPprincipal = New-SPUser -UserAlias $principal.ToEncodedString() -Web $web
• $SPgroup.AddUser($SPprincipal)

So we are still having issues with the claim types we added. The error makes me suspect the resolving capabilities of the custom claim provider. After some googling I finally found this post: Adding users and claims to a site from PowerShell Here’s the relevant part:

Conclusion #2: whenever you write a custom claim provider, make sure to provide fillResolve capabilities for your custom claim types. I don’t think you are obliged to add them to the fillResolve method which takes a string as value to resolve, but you have to add them to the fillResolve method which takes an SPclaim as value to resolve. You can then simply put an if statement to auto-resolve everything of the claimtypes you don’t want to be looked up.

you can add this in the protected override void FillResolve(Uri context, string[] entityTypes, SPClaim resolveInput, List<Microsoft.SharePoint.WebControls.PickerEntity> resolved) method

if (resolveInput.ClaimType == CustClaimType.Entity)
{
    resolved.Add(GetPickerEntity(resolveInput.Value, resolveInput.Value, resolveInput.ClaimType));                   
    return;
}

Some more background reading:

• MSDN: Claims Walkthrough: Writing Claims Providers for SharePoint 2010
• Custom Claims Providers: Hierarchical Claims - Part 3, Claims Picker Surfacing and Authorization

One of the things I noticed during my latest UAG project is that users seemed to be redirect to some sort of error page. In short: if they logged on to a SharePoint site published over UAG and then had their session time out, after click “ok”, they’d be presented with the “You have attempted to access a restricted URL” error.

Using the UAG web monitor, I was able to get a more specific error:

A request from source IP address x.x.x.x, user to trunk secure; Secure=1 for application Internal Site of type InternalSite failed because
the URL /InternalSite/SessionTimeout.asp?site_name=secure&amp;secure=1 must not contain parameters. The method is GET.

So I started investigating the URL Set of the trunk where I was seeing the issue. I could indeed see that the rule didn’t not expected (allowed) parameters. The rule in question was for the URL /InternalSite/SessionTimeout.asp

I peeked around, and I found out that the rule /InternalSite/setpolicy.asp had these exact two parameters. This made adding them to our rule pretty easy, just click each parameter and chose the copy (and paste) option.

After pasting the rules we needed to perform some minor modifications:

• Change the rule to Handle (instead of Reject) parameters
• Modify the Existence to Optional

Save and activate the configuration and now your users shouldn’t be presented with this unexpected message.

I was assisting a colleague which was installing the Ax 2010 Enterprise Portal on a SharePoint Farm. The farm consisted of 2 servers hosting the SharePoint web applications (the actual sites), and 2 servers hosting the central admin and application services roles. We wanted to start with installing the Enterprise Portal bits on both web front servers without actually choosing the “create site” option in the installer. This would just prep the server and then we’d finalize it by running the “create site” option on the central admin server.

Here’s the screenshot where we selected the Enterprise Portal (and some other prereqs for the Portal):

Some steps further we were supposed to get a dropdown with an overview of all sites hosted by SharePoint. Although SharePoint was installed, and we had multiple sites created, we were greeted with an error stating “Microsoft SharePoint 2010 is not installed or running. Please run the prerequisite utility for more information. Operation is not valid due to the current state of the object.”

Going back and clicking next again doesn’t really solve the problem. Going to the installer log file (which is located in \Program Files\Microsoft Dynamics AX\60\Setup Logs\[Date]) showed us that the installer seemed to query the local IIS configuration just fine. As far as I could tell no actually error was given, but it started processing shortly after trying to get information regarding the first actual SharePoint site.

After staring a bit at the log my eye fell on the “GetFirstHostHeaderOfWebSite” method. It seemed to have ran fine for the default website, but it wasn’t executed for the first actual SharePoint site. And it rang a bell as we have customized this a bit. We had in fact 3 host headers for each SharePoint site. One for the virtual name, one for the virtual name but dedicated to the node and one which was just blank with the IP. I know the last one more or less make the others unnecessary, but we added that one later on when we figured our hardware load balancer status probing wasn’t playing nice with the host headers.

Long story short, after modifying ALL sites found in the IIS configuration so that thed have one or no host headers, the setup was able to enumerate the potential sites to configure the AX Enterprise Portal for just fine. Bit weird and seems like a bug in the installer to me…