Archive: October, 2011

Resolving the super user/super reader account utilized by the cache is not configured…

2 comments October 9th, 2011

Chances are that if you have a multi-server SharePoint farm, you’ll soon run into these errors in your Event Viewer sooner or later, probably sooner rather than later:

  • Object Cache: The super user account utilized by the cache is not configured. This can increase the number of cache misses, which causes the page requests to consume unnecessary system resources.
    To configure the account use the following command ‘stsadm -o setproperty -propertyname portalsuperuseraccount -propertyvalue account -url webappurl’. The account should be any account that has Full Control access to the SharePoint databases but is not an application pool account.
    Additional Data:
    Current default super user account: SHAREPOINT\system

 

  • Object Cache: The super reader account utilized by the cache does not have sufficient permissions to SharePoint databases.
    To configure the account use the following command ‘stsadm -o setproperty -propertyname portalsuperreaderaccount -propertyvalue account -url webappurl’. It should be configured to be an account that has Read access to the SharePoint databases.
    Additional Data:
    Current default super reader account: NT AUTHORITY\LOCAL SERVICE

I’ve seen my clients run into this issue a lot; however, I myself have personally never encountered the error in an environment of my own. Well the other night I decided I was going to “upgrade” my SharePoint 2010 Single Server environment to a multi-server load balanced farm. Everything went great, I went to bed happy, I woke up in the morning, and my claims based web applications weren’t working anymore. I saw the above error in the Event Viewer of both WFEs. Like I said before, I tell people how to resolve it all the time, but it never brings down a web application, it’s just an annoying error. Well apparently claims based sites in multi-server environments need these accounts to be set properly. So lets walk through it:

  1. Navigate to Central Administration
  2. Application Management
  3. Manage Web Application
  4. Select the Web Application
  5. Click User Policy
  6. Add Users
  7. Click Next
  8. Fill in domain\superuser and domain\superreader accounts
  9. Select Full Control
  10. Click OK
  11. Edit the domain\superreader account you just added and change it to Full Read

If you’re utilizing Claims Based Authentication the users should be displayed something like this:

  • i:0#.w|domain\superuser
  • i:0#w|domain\superreader

Once you’ve completed the above, you are ready to set the accounts as superuser and superreader of the farm for that particular web application.  There are several ways to do this, you can use the STSADM method which I consider the old way, but hey, it still gets the job done:

  • stsadm -o setproperty -propertyname portalsuperuseraccount -propertyvalue account -url webappurl
  • stsadm -o setproperty -propertyname portalsuperreaderaccount -propertyvalue account -url webappurl

You can also use STSADM’s big brother PowerShell which is the better more powerful option…

If you’re utilizing Classic Mode Authentication execute the following cmdlets from any of your SharePoint Farm servers:

$wa = Get-SPWebApplication “http://WebAppURL/”
$wa.Properties[“portalsuperuseraccount”] = “domain\superuser”
$wa.Properties[“portalsuperreaderaccount”] = “domain\superreader”
$wa.Update()

If you’re utilizing Claims Based Authentication execute the following cmdlets from any of your SharePoint Farm servers:

$wa = Get-SPWebApplication “http://WebAppURL/”
$wa.Properties[“portalsuperuseraccount”] = “i:0#.W|domain\superuser”
$wa.Properties[“portalsuperreaderaccount”] = “i:0#.W|domain\superreader”
$wa.Update()

If everything executes successfully, just give IIS a quick restart and you should be good to go. 😉