SharePoint – PowerShell to configure SuperUser and SuperReader accounts on all Web Apps


I have seen many examples but not enough that spells it out so below you can copy out the script and replace the user name with your users.

Here is the link to the official article explaining SharePoint Object Cache. http://technet.microsoft.com/en-us/library/ff758656(v=office.15).aspx

If your On premise deployment is configured according to the SharePoint Product Line Architecture (PLA) then you would only have 1 web application and this would be a simple task but for many On Premise environments they have many Web applications.
http://blogs.technet.com/b/pla/archive/2013/07/22/benefits-of-using-the-product-line-architecture.aspx


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.

STEPS:

  1. PLEASE GET YOUR AD ADMINS TO CREATE 2 NORMAL AD USER ACCOUNTS (The names and naming convention is completely up to you)
  2. OPEN POWERSHELL ISE OR WINDOWS POWERSHELL WINDOW AS AN ADMIN i.e. FARM ADMIN
  3. COPY OUT THE CODE BETWEEN THE “#—–” BELOW, REPLACE THE DOMAIN AND ACCOUNT NAMES WITH YOUR DETAILS AND EXECUTE

#PowerShell Starts Here
##———————————————————————————

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()

 }


 ##—-PowerShell Ends Here———————————————-

Comments (11)

  1. Tsirikos Dimitris says:

    Greg I have the exact same problem, what did you do to resolve the problem?
    What "manual set of commands to reset it on the Web Application." did you run?

  2. Paul_Pedroza says:

    Fine, thanks!!

  3. Kev Houston says:

    Outstanding solution!

  4. James Cragle says:

    Your script is great. I had some trouble when I had a mix of authentication types. The variables get set in line 25 and then when I hit a different auth type the variable is stuck and causes an error. I added a little "else" statement and slightly changed
    the variable names after the "if" to fit. Hopefully this is helpful to other.
    if ($app.UseClaimsAuthentication -eq $true)
    {
    # IF CLAIMS THEN SET THE IDENTIFIER
    $xUser = "i:0#.w|" + $sUser
    $xRead = "i:0#.w|" + $sRead
    }
    [tag:NOT] CLAIMS SET BACK
    else {
    $xUser = $sUser
    $xRead = $sRead
    }

    # ADD THE SUPER USER ACC – FULL CONTROL (Required for writing the Cache)
    $policy = $app.Policies.Add($xUser, $sUserName)
    $policyRole = $app.PolicyRoles.GetSpecialRole([Microsoft.SharePoint.Administration.SPPolicyRoleType]::FullControl)

    $policy.PolicyRoleBindings.Add($policyRole)

    $app.Properties["portalsuperuseraccount"] = $xUser
    $app.Update()

    # ADD THE SUPER READER ACC – READ ONLY
    $policy = $app.Policies.Add($xRead, $sReadName)
    $policyRole = $app.PolicyRoles.GetSpecialRole([Microsoft.SharePoint.Administration.SPPolicyRoleType]::FullRead)

    $policy.PolicyRoleBindings.Add($policyRole)

    $app.Properties["portalsuperreaderaccount"] = $xRead
    $app.Update()

  5. greg says:

    Scott – I’m all for testing this out, let me know and I can run a test. I have noticed that for many of my accounts at the Web Application level (user policy) I have both Claims and NTLM users, it didn’t seem to break anything so I didn’t really mess with
    cleaning any of that up…. So, if I understand correctly at the Web App level in the User Policy, if doing full Claims I should never require an account with DOMAINSVC_ACT only something in the context of i:0#.w|DOMAINSVC_ACT, correct?

  6. greg says:

    I found a way to get this back. I removed the accounts (if showing on the Web Application User Policy) and then ran a manual set of commands to reset it on the Web Application. Then I did IISReset and things came back, even for the site collections under
    the managed paths.

  7. greg says:

    It seems to only be affecting the sites in the web application that have publishing features enabled. I can’t seem to figure out a way to back this out. I manually tried adding the accounts and the deleting (in CA on the Web Application User Policy) hoping
    that it might reset some stuff. No luck. I’m currently broken in DEV across all sites that have publishing features enabled.

  8. greg says:

    Hi Scott-

    I’m not sure if this put me in a broken state or not but it seems the script above wants to keep appending the Claim portion as it loops through…’i:0#.w|i:0#.w|i:0#.w|i:0#.w|i:0#.w|i:0#.w|i:0#.w|i:0#.w|i:0#.w|DOMAINACCOUNTNAME’

    Since I had applied this I’m not getting this error message on my web apps:

    "The specified user or domain group was not found."

    Looking in the ULS logs:
    System.Security.Principal.IdentityNotMappedException: Some or all identity references could not be translated.
    Getting Error Message for Exception Microsoft.SharePoint.SPException: The specified user or domain group was not found.

    I tried removing the accounts for this but that has done nothing for me. I’m not sure if maybe accounts are hidden from Central Admin and maybe there are some bad references still behind the scenes…

    Just wanted to see if you have seen this issue?

    Thanks

  9. Thanks James. I updated my own script but forgot to post the update to the blog. I have now updated it.

  10. Hi Greg, in my case even if the names existed it fixed the references automatically which is why I didn’t worry about manually removing them or customizing the script to do it for me. It seems you had some bad references but managed to get them sorted
    out. What I have seen is that in some cases the Claims identifier user and NTLM user both show up against the web application which doesn’t seem to affect my web apps but definitely doesn’t make sense. I could probably update the script to clean up the user
    first and then re-apply the superuser and superreader back again. Let me know and I will see if I can change it, test it and re-post the script?

  11. Hi Greg, yes that is correct. I have tested the script extensively. I have however seen in several instances when both account types are added by SharePoint. I am enquiring internally within MS to understand what would cause this but I can only suggest
    that if it happens to just leave both identities in place. The main thing is that if the web app is claims based, then the claims user for superuser and superreader must be present.

Skip to main content