Home > SharePoint > Setting the SharePoint object caching accounts (superuseraccount | superreaderaccount)

Setting the SharePoint object caching accounts (superuseraccount | superreaderaccount)

Recently, I came across the event log error:

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 unneccesary 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.

So, as instructed, I ran the stsadm command, not realizing the severity of my actions.

What happened was a slew of access denied errors, and more interestingly, was the inability for a user to edit their user profile.

So after some research, I discovered the right way to fix this in a TechNet article Configure object cache user accounts.


The steps are as follows:

1. Create dedicated user accounts in AD for a superuser and superreader.

2. Grant the super reader account full read access to each web application by editing the User Policy for the web app through Central Admin.

3. Grant the super user account full control to each web application by editing the User Policy for the web app through Central Admin.

4. Run the following Powershell script for each web application (making changes where appropriate):

$wa = Get-SPWebApplication -Identity http://dev.domain.com
$wa.Properties["portalsuperuseraccount"] = "i:0#.w|domain\sp-superuser"
$wa.Properties["portalsuperreaderaccount"] = "i:0#.w|domain\sp-superread"

5. Reset IIS

  • Make sure you run this under an account that has Shell permissions to the config database.  Farm account has this automatically.
  • Note the account name format as SharePoint sees it.  copy the format in the User Name column under the Web Application User Policy dialog exactly.  For example, if classic, then format is likely <domain>\<user.name>; if claims then likely i:0#.w|<domain>\<user.name>.
  • Reset IIS after you run the powershell script.
  • If you still see error in the event viewer, it may be that you did set permissions on all web apps.  For example I had to do it on both my primary web app, and the web app that hosted mysites.
  • The official TechNet article.
  • Chris O.Brian has a good script to do this all at once.
  • SharePoint Stef also has a script to handle this.
  1. Jake
    June 30, 2011 at 3:44 pm

    This is exactly right. We are using claims based authentication and attempted to modify these permissions without using the ‘i:0#.w’ header and it broke all authentication for the particular web application. We were unable to login into the site using windows or FBA. So just as it states us the above i:0#.w|\ standard. We ran the stsadm just as it states to do in the event viewer log however it does not include the small detail about FBA sites…

    Thanks for this great site and post.

  1. June 2, 2012 at 10:59 am

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: