4

I'm trying to figure out continuous "Unable to write SPDistributedCache call usage entry." error in ULS and some instructions like this suggests that issue might be with super accounts having incorrect username.

The user accounts used for superreader and superuser accounts are currently set in domain\superuser and domain\superreader format to web app's portalsuperreaderaccount and portalsuperuseraccount properties.

But I'm wondering if they would need to be updated into i:0#.w|domain\username format instead to fix issues?

As far as I know these both formats should resolve fine but thinking if this still could be an issue.

  • Have you changed your web application to Claimes Based? – SunP Jul 20 '16 at 8:53
  • Not recently and I've not been the one originally setting up this farm but as far as I'm aware it has been claims based pretty much from beginning. – Kim B Jul 20 '16 at 8:57
  • In that case it is necessary to have i:0#.w|domain\username format. The way to do this is, simply go to your WebApp -> User Policy -> Add User and add the superusers again. They should now have the proper format and can be used with claims based. – SunP Jul 20 '16 at 9:09
  • @SunP In user policy the accounts are with the claims prefix but not in portalsuperreaderaccount and portalsuperuseraccount properties of the web app. – Kim B Jul 20 '16 at 9:31
  • @KimB It turns out that there are cases when this can actually be a problem. If so run the script in my updated answer and hopefully your ULS errors will resolve. – Benny Skogberg Jul 20 '16 at 18:58
3

No it doesn't. The i:0#.w| part is an internal signature for SharePoint that identifies the authentication type as claims rather than the soon to be deprecated classic authentication.

Update

Usually this isn’t a problem, but if you have the object cache accounts without the initial claims signature all users will get access denied to the object cache (which you see in the ULS logs). There may be a number of reasons why this happened, but there are ways to fix it.

According to Scott on MSFT in his post SharePoint – PowerShell to configure SuperUser and SuperReader accounts on all Web Apps, this cause error:

What you will see is that there is a check for Claims Authentication.

The reason for this is that you will notice that when User rights are granted in Central Admin via User Policy for each Web App you will see that the Claims identifier ("i:0#.w|") is shown (Yes, even in SharePoint 2013).

If you do not provide the claims identifier and you implement Object cache all users will receive "Access Denied" prompts and will be denied regardless of how many times they try to login.

The way to solve it is to update your webapps that uses claims, but is missing the initial claims signature. For this you use PowerShell:

Add-PSSnapin Microsoft.SharePoint.Powershell -ErrorAction SilentlyContinue
####SET ACCOUNT NAMES (Replace Domain and UserName)
#SUPER USER ACCOUNT – Use your own Account (NB: NOT A SHAREPOINT ADMIN)
$sOrigUser= "blue\SP_SuperUser"
$sUserName = "SP_SuperUser"
#SUPER READER ACCOUNT – Use your own Account (NB: NOT A SHAREPOINT ADMIN)
$sOrigRead = "blue\SP_SuperRead"
$sReadName = "SP_SuperRead"

$apps = get-spwebapplication 
foreach ($app in $apps) {
   #DISPLAY THE URL IT IS BUSY WITH
   $app.Url
   if ($app.UseClaimsAuthentication -eq $true)
   {
    # IF CLAIMS THEN SET THE IDENTIFIER
    $sUser = "i:0#.w|" + $sOrigUser
    $sRead = "i:0#.w|" + $sOrigRead
   }
   else
   {
   # CLASSIC AUTH USED
     $sUser = $sOrigUser
     $sRead = $sOrigRead
   }

   # ADD THE SUPER USER ACC – FULL CONTROL (Required for writing the Cache)
   $policy = $app.Policies.Add($sUser, $sUserName)
   $policyRole = $app.PolicyRoles.GetSpecialRole([Microsoft.SharePoint.Administration.SPPolicyRoleType]::FullControl) 
   $policy.PolicyRoleBindings.Add($policyRole)
   $app.Properties["portalsuperuseraccount"] = $sUser
   $app.Update()
   # ADD THE SUPER READER ACC – READ ONLY
   $policy = $app.Policies.Add($sRead, $sReadName)
   $policyRole = $app.PolicyRoles.GetSpecialRole([Microsoft.SharePoint.Administration.SPPolicyRoleType]::FullRead) 
   $policy.PolicyRoleBindings.Add($policyRole)
   $app.Properties["portalsuperreaderaccount"] = $sRead
   $app.Update()
 }

Hopefully you and I have a better understanding of what tha claims signature does, and doesn’t do.

  • 3
    No, its matter alot when you configured the claims authentication. – Waqas Sarwar MVP Jul 20 '16 at 14:08
  • Agreed, this should not have been marked as an answer as it is incorrect. – Trevor Seward Jul 20 '16 at 14:53
  • I've corrected my answer, since there are cases where this actually is a problem. Hopefully OP can benefit from the answer by using Scotts script. – Benny Skogberg Jul 20 '16 at 18:56
  • 1
    Thanks for the clarification and correction. I now noted that this difference between classic and claims is mentioned in TechNet article as well. "Make note of how the names for the Object Cache Super Reader and Object Cache Super User accounts are displayed in the User Name column. The displayed strings will be different depending on whether you are using claims authentication for the web application." technet.microsoft.com/en-us/library/ff758656.aspx – Kim B Jul 21 '16 at 5:50
3

Yes, it does matter. Especially in the Object Cache Configuration( Super User & Super Reader).If your webapplication configured as claims based authentication then this is import piece.

  • Make Sure your Account in Web Application Properties( Via PowerShell) have the same format i.e cliams|domain\username, as they are in the Web Application's Policy( from Central admin > policy for web application).

If it mismatch, you will get the access denied error.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.