Warning: PowerShell Won’t Throw An Error When You Are About to Kill Your Web Application

Here is a little gotcha that PowerShell and SharePoint hit me with.

PowerShell will not return an error when you assign a user account to a SharePoint web application if the user does not exist or has been entered incorrectly. However, after an IIS reset, your SharePoint site fails and returns an error.

Symptom:  SharePoint will not serve any content when you browse a site.  Instead, the site displays the following error:

Error: The user does not exist or is not unique.

Background:

Warning messages appeared in the server logs indicating that the web cache is not configured correctly:

ID 7362: 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 error repeated in the event log between one and ten times an hour.

A search found many articles that say we need to add SuperUser and SuperReader to our domain (names can be your own, the suggestion is service-SuperUser and service-SuperReader) and then configure them for those roles on the SP server.

Following the instructions in this article (which matched many, many others), the Active Directory administrator created service accounts for these roles, then sent me the account names he created. I added the SuperUser account to the User Policy for each web application, and it worked just fine. When trying to add the SuperReader, however, the SharePoint UI failed when trying to check the name of the user using “Check Names”.

However, I was able to browse the users using the “Browse” button (next to the “Check Names” button) and find the SuperReader account just fine and added it. I did this for the other web applications while the AD Admin checked the account. He let me know he had mistyped the account name, and had corrected it to match what he had sent me. So everything was just dandy now right?

Nope. See, here is the first gotcha.

SharePoint 2010 uses the pre-Windows 2000 name for users. You read that right – it uses the version of the name that systems used before the turn of the millennium.

So if your UserNameIsJustTooDamnLong, your pre-Windows 2000 UserNameIsJustTooDam truncated. (That joke probably won’t translate too well for my non-English-speaking visitors. Sorry.)

Which leads to the second problem, and where PowerShell doesn’t return an error, and your SharePoint site gets taken down.

The next instruction is to run this PowerShell command for each web application:

$w = Get-SPWebApplication "http:///"
$w.Properties["portalsuperuseraccount"] = "domain\superuser"
$w.Properties["portalsuperreaderaccount"] = "domain\superreader"
$w.Update()


If, for example, your SuperReader account name was ThisUserNameIsJustTooDamnLong, the command would look like this:


$w.Properties["portalsuperreaderaccount"] = "domain\ThisUserNameIsJustTooDamnLong"


But, according to SharePoint, the account name is “domain\ThisUserNameIsJustTo”. It has no idea who “domain\ThisUserNameIsJustTooDamnLong” is, because “domain\ThisUserNameIsJustTooDamnLong” is not the same as “domain\ThisUserNameIsJustTo”.

Wouldn’t it be nice if, when you input code like


$w.Properties["portalsuperreaderaccount"] = "domain\ThisUserDoesNotExist"


that the code would return some sort of error in PowerShell? It doesn’t. All of these


$w.Properties["portalsuperreaderaccount"] = "domain\ThisUserExists"
$w.Properties["portalsuperreaderaccount"] = "domain\ThisUserDoesNotExist"
$w.Properties["portalsuperreaderaccount"] = "domain\foo"


are considered equally valid when entered in PowerShell. No error gets returned because neither PowerShell nor SharePoint validate that the user exists.

But once you reset IIS, your site goes down and you get: “Error: The user does not exist or is not unique.”

A little late now!

So let this be a lesson to you – type carefully, be sure the user exists, and watch the limits on the pre-Windows 200 name, even here in the 21st century!

(Oh yeah, be sure to test your code in your dev environment before using it in production. Okay? Thanks!)