Object Cache: The super user account utilized by the cache is not configured
You might find this error in the Application event log, or the very similar "The super reader account utilized by the cache is not configured". It might be the first time you even knew of the existence of this duo of caped crusaders; the superuser and the superreader accounts.
In publishing sites there is a mechanism called the Object Cache. Its job is to economize on expensive database calls by caching information in the content database when using the Content by Query web part and certain navigation controls. There are also ways you can take advantage of the object cache from within custom code. But for this to work your web application needs a couple of special accounts to be configured.
Why two accounts? Well, one of the problems with caching is that you usually need to present different results to different users for the same query, and dependent in particular on whether a user can see draft items. So the users are effectively separated into two buckets which are then represented by these two accounts, and when a publishing control requests data from the object cache it makes two queries. One query is made as the Portal Super User account and another is made as the Portal Super Reader account. The results of these two queries can then be used to satisfy all the user requests depending on whether they have permissions to see draft items or just published content (hence the superreader which represents a user with only Read permissions). The object cache returns appropriate results based on the ACLs without needing to store data for each individual user. It's a lean, mean data caching machine.
When you create a SharePoint farm the superuser account is set by default to the System Account, and the superreader account uses NT Authority\Local Service. This works but is not ideal as you can get situations where documents get checked out to the System Account, which is the superuser account, which affects the efficiency of the cache. The same situation arises if you use any "real" user account for the superuser account. If you use claims authentication then NT Authority\Local Service does not get resolved correctly and can give rise to an Access Denied error message. Of course depending on how you set up your farm, for example if you upgraded from an earlier version of SharePoint, the superreader and superuser accounts might not be configured at all. So it is regarded as "best practice" to explicitly set up these accounts as follows.
Create two accounts in Active Directory: domain\sp_superuser and domain\sp_superreader.
Go to Central Administration -> Manage Web Applications and for each web application click on User Policy in the ribbon to the get the User Policy dialog. In the dialog click on Add Users, Next, and give the sp_superuser account Full Control permissions.
Do the same for the sp_superreader account but with Full Read permissions.
Finally, to configure these two accounts for your web application you need to set two web application properties using the following PowerShell:
$wa = Get-SPWebApplication -Identity "WebApplicationName"
$wa.Properties["portalsuperuseraccount"] = "i:0#.w|litware\sp_superuser"
$wa.Properties["portalsuperreaderaccount"] = "i:0#.w|litware\sp_superreader"
$wa.Update()
The precise form of the user name can be seen in the User Name column of the User Policy dialog box mentioned above - if you are not using claims it will just be domain\sp_superuser, etc. You will need to do this for each web application which will be using the publishing feature. It's probably worth doing an IISRESET as well to be on the safe side. A more complete set of instructions for setting up the object cache accounts can be found on TechNet.