The super user account utilized by the cache is not configured
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:
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:
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! :(
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
- 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
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! :(
Comments
Post a Comment