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
http://technet.microsoft.com/en-us/library/ff758656.aspx
http://www.sharepointchick.com/archive/2010/10/06/resolving-the-super-user-account-utilized-by-the-cache-is.aspx
The object cache stores properties about items in Microsoft SharePoint Server 2010. Items in this cache are used by the publishing feature when it renders Web pages. The goals of the object cache are to reduce the load on the computer on which SQL Server is running, and to improve request latency and throughput. The object cache makes its queries as one of two out-of-box user accounts: the Portal Super User and the Portal Super Reader. These user accounts must be properly configured to ensure that the object cache works correctly. The Portal Super User account must be an account that has Full Control access to the Web application. The Portal Super Reader account must be an account that has Full Read access to the Web application.
|
|
| The Portal Super User and Portal Super Reader accounts must be separate accounts, and they must not be accounts that will ever be used to log in to the site. |
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.
By default, the Portal Super User account is the site’s System Account, and the Portal Super Reader account is NT Authority\Local Service. There are two main issues with using the out-of-box accounts
http://www.sharepointchick.com/archive/2010/10/06/resolving-the-super-user-account-utilized-by-the-cache-is.aspx
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:
| 1 | $w = Get-SPWebApplication "http://<server>/" |
| 2 | $w.Properties["portalsuperuseraccount"] = "domain\superuser" |
| 3 | $w.Properties["portalsuperreaderaccount"] = "domain\superreader" |
| 4 | $w.Update() |
If you are using claims based authentication run these cmdlets on one of your SharePoint servers:
| 1 | $w = Get-SPWebApplication "http://<server>/" |
| 2 | $w.Properties["portalsuperuseraccount"] = "i:0#.w|domain\superuser" |
| 3 | $w.Properties["portalsuperreaderaccount"] = "i:0#.w|domain\superreader" |
| 4 | $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
$w = Get-SPWebApplication "http://<server>/"
$w.Properties["portalsuperuseraccount"] = "domain\superuser"
$w.Properties["portalsuperreaderaccount"] = "domain\superreader"
$w.Update()
No comments:
Post a Comment