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"
$w.Update()
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"
$w.Update()
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.
Microsoft has published an article about the Object Cache User Accounts on TechNet. It can be found here:
http://technet.microsoft.com/en-us/library/ff758656.aspx., but they don't talk about Claims Authentication here though! :(
