Sometimes support is just about figuring out what someone did wrong when configuring an application. I recently did a new install of SharePoint Server 2010 with Enterprise features that was to be used for a migration from an older MOSS 2007 farm. I set my new Server up with SP1 and created mysite and intranet web applications. The Intranet just had a test Team Site ready to be replaced with the migrated content. I set up the User Profile Service and imported objects from Active Directory. The profiles were there, mysites were set up and user search was working. I though everything was fine but then I clicked the Edit my Profile link on the Profile page of a mysite and got an unexpected error.
OK so I’m sure that the tracelogs will help me out here. I used ULSViewer (http://archive.msdn.microsoft.com/ULSViewer) to capture the trace logs at the point of the error. Immediately after the unexpected error in the tracelog was:
Application error when access /_layouts/EditProfile.aspx, Error=Server Out Of Memory. There is no memory on the server to run your program. Please contact your administrator with this problem. at Microsoft.SharePoint.Library.SPRequestInternalClass.GetUserToken(String bstrUrl, String bstrLogin) at Microsoft.SharePoint.Library.SPRequest.GetUserToken(String bstrUrl, String bstrLogin) at Microsoft.SharePoint.SPWeb.GetUserToken(String userName) at Microsoft.SharePoint.Publishing.CacheManager.<.ctor>b__0(SPSite newSite) at….
Server out of memory that must be absurd. After a long spell of troubleshooting with a very good Microsoft PSS engineer I suddenly realised that if I accessed EditProfile.aspx.aspx from another web app then it worked fine. Something must be wrong with my mysite web app,
What I eventually worked out was that In order to get rid of the Event Log warning:
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.
On the http://mysite web app (and other web apps), I follow Mirjams article: http://www.sharepointchick.com/archive/2010/10/06/resolving-the-super-user-account-utilized-by-the-cache-is.aspx. I checked again that I had the accounts in the User Policy:
This all looked right. So in Powershell then, had I set these correctly?
PS C:\Users\administrator.xxx> $wa=Get-SPWebApplication http://mysite:80 PS C:\Users\administrator.xxx> $wa.properties["portalsuperreaderaccount"] i:0#.w|xxx\SPsuperreader PS C:\Users\administrator.xxx> $wa.properties["portalsuperuseraccount"] i:0#.w|xxx\SPsuperuser
Oh, that’s not right, these are the settings for a Web App that is running in Claims authentication. The MySites web app is running in Classic authentication so these needed to be re-set.
PS C:\Users\administrator.xxx> $wa.properties["portalsuperuseraccount"] = "xxx\spsuperuser" PS C:\Users\administrator.xxx> $wa.properties["portalsuperreaderaccount"] = "xxx\spsuperreader" PS C:\Users\administrator.xxx> $wa.update() PS C:\Users\administrator.xxx>IISRESET
I’m sure that with a “normal” content Web App when you get these wrong you just get an access denied whenever you try to browse the web app. It is strange that with a MySite host and SSSC enabled everything works until you get an Unexpected Error/Server out of memory when you try to edit the user profile.
There is now a Technet article linked from Mirjam’s (http://technet.microsoft.com/en-us/library/ff758656.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
Well, if the warning relates tot he Publishing Infrastructure and the object cache I recon it has very little to do with the MySite site collections anyway. Perhaps the warning should only appear in the event log when Publishing Infrastructure feature is enabled within site collections in a given web app.
So it really is important to get these settings right, if you are going to apply them.