Resolving "The super user account utilized by the cache is not configured."

If you have a SharePoint Publishing site and you check the event viewer every once in a while you might see the following warning in there:

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.
Additional Data:
Current default super user account: SHAREPOINT\system

This means that the cache accounts for your web application aren’t properly set and that there will be a lot of cache misses. If a cache miss occurs the page the user requested will have to be build up from scratch again. Files and information will be retrieved from the database and the file system and the page will be rendered. This means an extra hit on your SharePoint and database servers and a slower page load for your end user.

If you are upgrading a SharePoint 2007 environment that used forms based authentication, or you are moving a content database with a web application that uses forms based authentication in there you will not only see this message, you will get continuous access denied errors instead.

As the warning in the event log suggests there is a way to fix this by running an STSADM command. Unfortunately this is only part of the story.
The way to correct this problem is to first create two normal user accounts in AD. These are not service accounts. You could call them domain\superuser and domain\superreader, but of course that’s up to you.
The domain\superuser account needs to have a User Policy set for that gives it Full Control to the entire web application. In order to do this you perform the following steps:

  • Go to Central Administration
  • Go to Application Management
  • Go to Manage Web Application
  • Select the web application we’re talking about
  • Click User Policy
  • Add Users
  • Click Next
  • Fill in domain\superuser
  • Select Full Control
  • Click OK

The domain\superreader account needs to have a User Policy set for that gives it Full Read to the entire web application. In order to do this you perform the following steps:

  • Go to Central Administration
  • Go to Application Management
  • Go to Manage Web Application
  • Select the web application we’re talking about
  • Click User Policy
  • Add Users
  • Click Next
  • Fill in domain\superreader
  • Select Full Read
  • Click OK

If your web application is using claims based authentication the users should be displayed like i:0#.w|domain\superuser and i:0#w|domain\superreader.
Now we need to assign the right values to the right properties of the web application. If you are using classic authentication you could use the STSADM command mentioned in the event log warning. However if you are using any type of claims based authentication you will need to use Windows PowerShell. And Windows PowerShell is the hipper more modern and sustainable option anyway.
If you are using classic mode authentication run the following cmdlets on one of your SharePoint servers:

$w = Get-SPWebApplication "http://<server>/"
$w.Properties["portalsuperuseraccount"] = "domain\superuser"
$w.Properties["portalsuperreaderaccount"] = "domain\superreader"

If you are using claims based authentication run these cmdlets on one of your SharePoint servers:

$w = Get-SPWebApplication "http://<server>/"
$w.Properties["portalsuperuseraccount"] = "i:0#.w|domain\superuser"
$w.Properties["portalsuperreaderaccount"] = "i:0#.w|domain\superreader"

After you've run these PowerShell cmdlets you need to perform an IISRESET to finish it off.

Now you should be freed from the warnings in the event viewer. If you got access denied messages because you moved a content database with a web application that uses claims based authentication you should now be able to log in again.

[Update 7/8/2011]: Microsoft now published an article about the Object Cache User Accounts on TechNet. It can be found here:

Comments -
  1. Gravatar


    very nice post. :)

    Just a note in line 3 of claims powershell cmdlet the user should be "i:0#.W|domain\superreader" to match the rest of the posting.

  2. Gravatar

    Thanks Nuno, you're right. I adjusted the script.


  3. Gravatar

    You can script the Policy part very easy with PowerShell too!

  4. Gravatar

    It is worth noting that the "Get-SPWebApplication" Powershell cmdlet your script depends on, is part of Gary Lapoint's awesome extension set and NOT native functionality. (
    Readers would need to install Gary's extensions in order to execute your script.
    It is always a good idea to note dependencies for readers.

    NICE POST!!!


  5. Gravatar

    Hi Cornelius,

    The Get-SPWebApplication cmdlet I'm using is a standard cmdlet and NOT part of Gary's awesome extension set.
    The extension Gary wrote is for SharePoint 2007 and my post is about SharePoint 2010.
    You might want to double check these things before posting a comment like that.


  6. Gravatar

    I am willing to bet I know why Corne had trouble finding this in PowerShell... you have to be in the SharePoint 2010 Management Shell, not just Windows PowerShell. I have made this mistake numerous times and now replace the taskbar pinned PowerShell shortcut with the SharePoint 2010 Management Shell shortcut instead. The other option to save yourself from this error is to add the environment variables to the root profile of Windows PowerShell to include the SharePoint cmdlets.

    Thanks for the great post Mirjam!

  7. Gravatar

    Good tips thanks for it.The steps and codes are very clear and easy to understand.

  8. Gravatar

    Thanks for this - a better explanation than Technet but doesn't there need to be an IISRESET?

  9. Gravatar

    Hi bcweb,

    Yes, it does :-)


  10. Gravatar

    SharePoint 2010: The super user account utilized by the cache is not configured

  11. Gravatar

    Are you sure that the accounts have to be "two normal user accounts in AD" Why can they not be "Service Accounts"

  12. Gravatar

    Hi Glenn,

    Yes, I'm sure.


  13. Gravatar

    A "Service Account" IS a regular Domain Account with some specific right depending of the task and purpose.

    Right to give is clearly identified in this post.

    In my perception, this is two "Service Account" with less right than a Service Account added as a Managed Account because they are not in SharePoint Local group on WFE.

    Nice post MirJam

  14. Gravatar


    I am currently trying to do this in my environment using a user account that is setup as a Trust Identity Provider login. The username for this account in Sharepoint has a weird character in it (looks like a g with a ' over it) where the # is in your example. I can't get this character to show in Power Shell (tried pasting but a ? shows instead). Any idea on how to set the cache user accounts with this special character in the username?

    - Jonathan

  15. Gravatar

    Hi Jonathan,

    Can you tell me what the Trusted Identity Provider is?


  16. Gravatar

    I am getting event id 7363 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
    erros i am getting: acces denied for some users in some subsites, whole web app is using claims and publishing portal, no FBA yet. some domain users even though we give permission to the sub sites they get access denied. please comment on how to solve this. isssues.

  17. Gravatar

    Hi Sunny,

    Make sure you create a domain account (so not NT AUTHORITY\LOCAL SERVICE), make sure you give this domain account Full Read access to the web application as described in the article and if your web application is using claims you should run the second PowerShell script.


  18. Gravatar

    What about changing the password to the super reader/super user accounts? If we change the password to these accounts in AD are there other places within SharePoint that need to be updated?


  19. Gravatar

    Hi John,

    You don't have to change the password of the superuser and superreader accounts in SharePoint. It's not stored in SharePoint, so you can change the password in AD without a problem.


  20. Gravatar

    AWESOME! Thanks! That's what I needed to hear!

  21. Gravatar


    First, thanks for a great post...

    Just curious, in regards to the SuperReader account, what are the downsides if any to using the Search Crawler account (sp_search) instead of creating another AD account ?


  22. Gravatar

    Hi Gerald,

    The superreader and the search service account are two different accounts that have different uses and that could have different life cycles. Therefore it's better to not use the same AD account for both purposes.
    You could even have a different superreader account for different web applications, or have web applications that shouldn't be indexed by search and where the search service account shouldn't have permissions.

    Hope that clarifies things.


  23. Gravatar

    Hi Mirjam,
    it works like a charm, thanks a lot.
    But - just curious - what is SharePoint really doing with these accounts? As we never configure the password anywhere it cannot really use the accounts for anything?

  24. Gravatar

    This didn't work for me, I still get the event viewer error. Thanks though

  25. Gravatar

    Hi Christoph,

    Microsoft actually posted an article on TechNet 3 weeks ago with a bit more background information. About what the accounts are used for they say:

    In SharePoint Server 2010, querying for items is linked with the user account that makes the query. Various parts of the publishing feature make queries for which the results are cached in the object cache. These results are cached based on the user making the query. To optimize the cache hit rate and memory requirements, the queries must be based on whether a user can see draft items. When a publishing control requests the object cache to make a query to get data for the control, the cache makes the query, not as the user making the request, but instead it makes the query twice: once as the Portal Super User account and once as the Portal Super Reader account. The results of these two queries are stored in the object cache. The results for the Portal Super User account include draft items, and the results for the Portal Super Reader account include only published items. The object cache then checks the access control lists (ACLs) for the user who initiated the request and returns the appropriate results to that user based on whether that user can see draft items. By adding the Portal Super User and Portal Super Reader accounts to the Web application, the cache must store results for only two users. This increases the number of results that are returned for a query and decreases the amount of memory that is needed to store the cache.

    Ok, that's a bit long, but if you still want to know more you can find the post here:


  26. Gravatar

    should we remove the NT AUTHORITY\LOCAL SERVICE account from Policy settings

  27. Gravatar

    Hello Mirjam,

    I love this article. Because our company has multiple farms and creates new farms on a regular basis, I created a script that will do everything for you. It only asks for the 2 users that you want to use (e.g. mydomain\sp2010superuser and mydomain\sp2010superreader).
    It will add these users to policy for web application for all existing web applications and also set the properties for all web applications.
    I hope this script will be of use for someone out there.

    # This script will add the superuser and superreader account to the Policy for web app
    # and also set the web application properties so that the users will be used for caching
    # The script is designed in a way that you do NOT have to adjust the script before use
    Add-PSSnapin Microsoft.SharePoint.PowerShell

    # Function
    function addUsersToPolicyAndProperties
    $webapps = get-spwebapplication
    $superuser = Read-Host "Vul het SuperUser account in: <Domain>\<Username>"
    $superreader = Read-Host "Vul het SuperReader account in: <Domain>\<Username>"

    foreach($webapp in $webapps)
    try {
    $SUpolicy = $webapp.Policies.Add($superuser,$superuser)
    $SRpolicy = $webapp.Policies.Add($superreader,$superreader)
    $webapp.Properties["portalsuperuseraccount"] = [string]$superuser
    $webapp.Properties["portalsuperreaderaccount"] = [string]$superreader
    Write-Host "$webapp.url has been configured correctly"
    Write-Host "Error adding the users for $webapp.url" -fore red
    Write-Host "The script is done running, press a key to exit" -fore green
    $x = $host.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown")

    #Call function

  28. Gravatar

    Hi Al,

    I'm assuming by Policy settings you mean from the User Policy settings for the web application.
    If that's the case you can remove the NT AUTHORITY\LOCAL SERVICE account from it.


  29. Gravatar

    Hi Mirjam,

    we get aware of this issue while sniffing around the ULSLog from SP. Very happy to find a solution we've configured Sp2010 according to your post. Since then site performance decreases dramatically from around 500 ms to 4000 ms ("Execution Time" from Developer Dashboard).
    Is ther a way to "turn back the wheel" which means to unconfigure SuperUser and SuperReader from Web Application?


  30. Gravatar

    Hello Thomas,

    You can use the same PowerShell commands, you just have to change them a little:
    $w = Get-SPWebApplication "http://<server>/"
    $w.Properties["portalsuperuseraccount"] = $null
    $w.Properties["portalsuperreaderaccount"] = $null

    This will clean up these properties for the web application that you specified.

    Don't forget to remove the accounts in the policy for web app too.

  31. Gravatar

    In a recent post I talked about the publishing cache. It turns out this also applies for Classic Authentication

  32. Gravatar

    Hi Mirjam,

    Thank you for the great post. I have multiple content databases for my web applications (one content database per site collection). I was wondering if I'd need to provide the superuser and superreader accounts direct permission into the content databases rather than just providing permission in Web Application User Policy?


  33. Gravatar

    Hi Saji,

    Even if you have multiple content databases you only have to assign the superuser and superreader accounts the appropriate permissions using the Web Application User Policy. There is no need to give them direct permissions on the content databases.


  34. Gravatar


    I'm working on a rollercoaster problem. I wild hunch is that is started after picking up the event id warning for the missing superuser and superreader and then setting them accordingly. Shortly after the site was published over SSL via TMG 2010 SP2.

    Now in IE9 (and not in other browsers or in InPrivate browsing) I was first experiencing a problem loading the CSS. Among others switched on Blog caching. Now after some time I'm experience a problem with Javascript as controls like Site Actions and the Ok button adding a list item do no longer work.

    Can it have anyhing to do with setting the two accounts? I'm concentrating a lot on all the possible caching.. but maybe I'm wrong. The MSDN forum is also not yielding answers (only a lot of viewers) .. so for other background see here : - I also have a Fiddler session archive showing the site loading in InPrivate and in Normal, but will probably only share that with paid assistance on this problem ...

    I know you might be receiving all sorts of stuff and would not bother anyobdy like you if it was not driving me completely craze and without googling, reading and twittering the hell out of this problem (maybe the solution is so dead simple maybe ... )

  35. Gravatar

    Hi Mirjam,

    Thanks for the good post,
    do we need to do anything on database side to give permission for Superuser and superreader accounts?

  36. Gravatar

    Hi Sah,

    You don't have to give the SuperUser and SuperReader account explicit permissions on the database. You only have to perform the steps listed above.

    Hope that helps.


  37. Gravatar


    Two questions for you:

    1) How would I go about reviewing the superuser currently set on each of the web applications?

    I used the code found here and it appeared to work well. I am however still getting one entry in event viewer stating "Current default super user account: SHAREPOINT\system". I do have a claims based site, and I believe I did configure that what correctly/differently from the others based on your alternate instructions.

    2) Which leads me to my other question. Does the Central Admin site also need these settings applied?

  38. Gravatar


    Great post, I used this in one of my test environments and it worked great! I do have one question, are we able to revert these changes and have the Superuser account and Superreader account set back to the original settings?

  39. Gravatar

    Hi Michael,

    No, you cannot revert the super user and super reader settings back to their original values. The only way to reset them is to delete the web application and recreate it.


  40. Gravatar

    Hi Rob,

    1. Yes, you can by using pretty much the same PowerShell script that you use to set them:
    $w = Get-SPWebApplication "http://<server>/"

    2. Only web applications that have the publishing features enabled on them need the super user and super reader settings, so you don't have to set them on the Central Administration web application.

    Hope that helps.


  41. Gravatar

    Great post i also feel in the victims of leaving out the IISRESET part...
    I used to the the "The super user account utilized by the..." error but after running this script it went away.
    but im still stuck with 'Access Denied' for all user in my SharePoint Site acept for site collection administrators. i have tried all that i know. and still nothing...

  42. Gravatar

    Hello Mirjam,
    We have ran across this issue on both out QA and Prod farms. One of our guys set up your fix on our QA farm. For some reason no users are able to log into the sharepoint site anymore. We are on claims and ran the scripts as such. Any reason you can think of that may be causing this issue? Or where to look?

  43. Gravatar

    Hi Robert,

    If you are using SAML claims then you should replace i:0#.w| with the claims encoding for you environment. You can find this on the accounts on the People and Groups pages in your farm, or here

    If you are using Windows claims you could try running the non-claims version of the script.
    Not being able to log in general means that the accounts that were used in the script are the wrong accounts, or have the wrong encoding.

    Hope that helps.


  44. Gravatar

    hi Mirjam,

    Can we remove NT Authority\local service after configure both domain super user/reader accounts?


  45. Gravatar

    Hi Lap,

    If you had the NT Authority\local service account set as the superuser or superreader account, that will be overridden when you set a different account as the superuser or superreader account, so you don't have to remove anything.

    Hope that helps.


  46. Gravatar

    Hi How do i find which webapplication we are talking about?

    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



  47. Gravatar

    Thanks worked like a bomb!

  48. Gravatar

    Hi everyone, as soon as you read this, you'll know you're dealing with a newbie...

    This is going to sound really stupid and basic for most if not all of you, but, can you tell me what am I missing here? what account name do I put in the "PortalSuperUserAccount" ?

  49. Gravatar

    is PortalSuperUserAccount = domain account?

    if so, I am sorry you wasted your time reading my question....

  50. Gravatar

    Hi Dave,

    The portalsuperuseraccount and the portalsuperreaderaccount can be any domain account, but I do recommend that for both types of accounts you create a dedicated domain account that is not used for anything else.

    Hope that helps.



Leave a Reply


Please add 3 and 8 and type the answer here: