Archive: ‘SharePoint’ Category

Resolving the super user/super reader account utilized by the cache is not configured…

2 comments October 9th, 2011

Chances are that if you have a multi-server SharePoint farm, you’ll soon run into these errors in your Event Viewer sooner or later, probably sooner rather than later:

  • 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 unnecessary 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


  • 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

I’ve seen my clients run into this issue a lot; however, I myself have personally never encountered the error in an environment of my own. Well the other night I decided I was going to “upgrade” my SharePoint 2010 Single Server environment to a multi-server load balanced farm. Everything went great, I went to bed happy, I woke up in the morning, and my claims based web applications weren’t working anymore. I saw the above error in the Event Viewer of both WFEs. Like I said before, I tell people how to resolve it all the time, but it never brings down a web application, it’s just an annoying error. Well apparently claims based sites in multi-server environments need these accounts to be set properly. So lets walk through it:

  1. Navigate to Central Administration
  2. Application Management
  3. Manage Web Application
  4. Select the Web Application
  5. Click User Policy
  6. Add Users
  7. Click Next
  8. Fill in domain\superuser and domain\superreader accounts
  9. Select Full Control
  10. Click OK
  11. Edit the domain\superreader account you just added and change it to Full Read

If you’re utilizing Claims Based Authentication the users should be displayed something like this:

  • i:0#.w|domain\superuser
  • i:0#w|domain\superreader

Once you’ve completed the above, you are ready to set the accounts as superuser and superreader of the farm for that particular web application.  There are several ways to do this, you can use the STSADM method which I consider the old way, but hey, it still gets the job done:

  • stsadm -o setproperty -propertyname portalsuperuseraccount -propertyvalue account -url webappurl
  • stsadm -o setproperty -propertyname portalsuperreaderaccount -propertyvalue account -url webappurl

You can also use STSADM’s big brother PowerShell which is the better more powerful option…

If you’re utilizing Classic Mode Authentication execute the following cmdlets from any of your SharePoint Farm servers:

$wa = Get-SPWebApplication “http://WebAppURL/”
$wa.Properties[“portalsuperuseraccount”] = “domain\superuser”
$wa.Properties[“portalsuperreaderaccount”] = “domain\superreader”

If you’re utilizing Claims Based Authentication execute the following cmdlets from any of your SharePoint Farm servers:

$wa = Get-SPWebApplication “http://WebAppURL/”
$wa.Properties[“portalsuperuseraccount”] = “i:0#.W|domain\superuser”
$wa.Properties[“portalsuperreaderaccount”] = “i:0#.W|domain\superreader”

If everything executes successfully, just give IIS a quick restart and you should be good to go. 😉

How to delete a service application using Powershell

1 comment August 9th, 2011

The SharePoint 2010 Central Administration is great, but just like every other version of SharePoint, it doesn’t always quite cut it and even though you’re the “Admin” you inevitabley won’t be able to do something you want to do.  Go figure right? We can’t do whatever we want when we want to? Who would have though that? 

Well STSADM used to be to the “one” who wouldn’t say “NO” as much as often or as LOUD as CA while giving you less lame excuses. 

With SP2010, PowerShell is another option we have to turn to that does more of what we want when we want with even less lame excuses.

Let’s run through how to delete a service application when CA is saying NO…

Lets find the service application we want to delete using the following command:

$spapp = Get-SPServiceApplication -Name "Service Application Name"

For the “Service Application Name” (yes, include the quotes in the command) just type the service name you see in your CA under:

Central Administration >> Application Management >> Service Applications >> Manage service applications

or since we are talking about using Powershell, use the following command to display the services:


For Example: Search Service Application

So your command might look like this:

$spapp = Get-SPServiceApplication -Name "Search Service Application"

So if you remember in STSADM, you would have to run a command that would output the GUID for you, then run another command with the GUID included to get your desired results right?  Powershell actually stores the GUID in the $spapp variable for you.  So all you have to do is run this command and you can kiss that Service Application goodbye.

So keeping in mind that $spapp is storing the GUID for you, type the following command:

Remove-SPServiceApplication $spapp

If you would also like to remove the associated database(s), type the following command:

Remove-SPServiceApplication $spapp -RemoveData

So long story short:

$spapp = Get-SPServiceApplication -Name "Search Service Application"
Remove-SPServiceApplication $spapp


Remove-SPServiceApplication $spapp -RemoveData

SharePoint 2010 Cumulative Updates

No comments May 25th, 2011

SharePoint 2010 Cumulative Updates have always been a little hard to keep up with, by the time you update, you’re already behind. So the only point of this post is really so that I can point people to a URL that I can remember that has all of them in one place, with version numbers and release dates.  So here they are starting from newest to oldest…

CU TitleApplicationKB#VersionReleased
April 2011SPS2010251280014.0.5138.5001April 28, 2011
April 2011SP Foundation251280414.0.5138.5001April 28, 2011
February 2011SPS 2010247587814.0.5136.5002March 3, 2011
February 2011SP Foundation247588014.0.5136.5002 March 3, 2011
December 2010SPS 2010245925714.0.5130.5002December 31, 2010
December 2010SP Foundation245912514.0.5130.5002December 31, 2010
October 2010SPS 2010239432014.0.5128.5000October 26, 2010
October 2010SP Foundation239432314.0.5128.5000October 26, 2010
August 2010SPS 2010235234214.0.5123.5000August 31, 2010
August 2010SP Foundation235234614.0.5123.5000August 31, 2010
June 2010
June 2010
June 2010
June 2010
June 2010
SPS2010 (No Consolidation)983497
June 29, 2010
June 2010SP Foundation202856814.0.5114.5000June 29, 2010

500 Internal Server Error while using Client Certificate Mapping in IIS 7.

2 comments February 26th, 2011

I have a client (he reads my blog from time to time, so Hello if you’re reading this. ;o) who experienced an issue I hadn’t run across before.  They are migrating their MOSS 2007 environment to another location and were basically trying to setup the same version of MOSS but virtualized on Windows 2008/IIS 7 rather than physically on Windows 2003/IIS 6.

They have several Smart Card/CAC authenticated extended sites for external users.  They were using the IIS Certificate Mapping feature which is a bit different and causes some of extra work since their isn’t actually a GUI in IIS 7 like there was in IIS 6. 

We got everything configured properly using the following article if you’re interested in implementing this in your environment:

Configuring Many-to-One Client Certificate Mappings for IIS 7/7.5

Even though we had all this configured properly, the MOSS sites would not resolve, they rendered a non-specific 500 Internal Server Error instead, fun stuff right?

After hours of troubleshooting the configuration and finally bringing on an IIS expert from Microsoft’s support team, they found out that this issue was being caused by the two registry keys below. These were added as part of a security update that was designed as a workaround to a TLS/SSL vulnerability.

  • HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\
  • DisableRenegoOnClient=1
  • DisableRenegoOnServer=1 

These registry keys are mentioned in KB 977377. We resolved the issue by setting both of these to 0 (zero) and rebooting the server. 

So essentially remnant registry settings from the following security patch caused this issue:

Microsoft Security Advisory: Vulnerability in TLS/SSL could allow spoofing KB977377

The TLS/SSL vulnerability was actually fixed rather than worked around in:  

MS10-049: Vulnerabilities in SChannel could allow remove code execution

and replaced the above KB 977377.

Hopefully the above resolution will help someone else…

Enjoy, and let me know if you come across this same issue in your environment.

Utilizing PowerShell to Deploy SharePoint 2010

2 comments January 31st, 2011

Standardization of SharePoint 2010 deployments are important to me, especially within the DoD. It’s my belief that standardization could minimize environmental issues while giving all of us engineers a baseline understanding of how farms have been deployed in common environments, reducing spin up to final resolution times. The use of PowerShell allows us to do this without having to rely on the user to click or not click something which lets face it, sometimes we can’t rely on ourselves to click the right thing every time, so we can’t expect it from anyone else. So let’s look at how we can install SharePoint 2010 using a script and deploy the farm using PowerShell:

I recommend following a previous blog post before implementing the steps below to insure you have prepared your operating system for SharePoint 2010:

Preparing W2K8 for SharePoint 2007/2010 Installation.

Install SharePoint 2010 PreReqs:

For each of the servers in the farm (SPAPPSVR, SPIDX, SPWFE1, and SPWFE2):

  1. Create a folder named SP2010_Build on your D:\
  2. Inside the SP2010_Build folder, create 2 more folders named Products and another named Scripts.
  3. Inside the Products folder, create another folder named SharePoint_2010_Installation.
  4. Copy your SharePoint 2010 RTM files and any updates into the D:\SP2010_Build\Products\SharePoint_2010_Installation folder.
  5. Download the SP2010_PreReq.iso file.
  6. Mount the ISO file to your operating system or burn them to a CD.
  7. Copy the folder named PrerequisiteInstallerFiles to the D:\SP2010_Build\Products\SharePoint_2010_Installation folder.
  8. Copy the file named PrerequisiteInstaller.Arguments.txt file to the D:\SP2010_Build\Products\SharePoint_2010_Installation folder.
  9. Copy the file Prereq_SP2010.cmd to the D:\SP2010_Build\Scripts\ folder.
  10. Execute Prereq_SP2010.cmd from command prompt so that you can view the output:

    Restart Server(s)

    Continue reading…