Freigeben über

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

  • Artikel

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. https://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.
https://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

  • Anonymous
    January 01, 2003
    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.
  • Anonymous
    January 01, 2003
    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?
  • Anonymous
    January 01, 2003
    Thanks James. I updated my own script but forgot to post the update to the blog. I have now updated it.
  • Anonymous
    November 17, 2014
    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
  • Anonymous
    November 17, 2014
    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.
  • Anonymous
    November 17, 2014
    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.
  • Anonymous
    December 01, 2014
    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?
  • Anonymous
    December 10, 2014
    The comment has been removed
  • Anonymous
    February 13, 2015
    Outstanding solution!
  • Anonymous
    June 02, 2015
    Fine, thanks!!
  • Anonymous
    August 27, 2015
    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?