SharePoint 2010 Installation Account can't run SharePoint PowerShell cmdlets

With SharePoint 2007 it was common practice to use an installation account rather than your personal one to install SharePoint. This was due to some quirks with the way installation worked where users added after the fact, even as Farm Administrators, would get permission errors in places like SSP Admin.

Well, trying that with SharePoint 2010 has had some interesting side effects. I created a user, sp_Farmadmin, dropped him in the Administrators group for my SharePoint box and then gave him sysadmin in SQL Server. In theory this should be securityadmin and dbcreator, according to Technet, but surely I didn't give them too little permission to do the job.

I ran the install as sp_Farmadmin, then ran the SharePoint 2010 Products Configuration Wizard. After it finished I opened Central Administration and all looked good.

When I tried to open the SharePoint 2010 Management Shell, however, I got the error "The local farm is not accessible. Cmdlets with FeatureDependencyId are not registered".




I googled a bit and found some hints that it had to do with permissions. I found this gem on Technet:

A user cannot run Windows PowerShell cmdlets in a farm unless you have used this cmdlet to add the user to the SharePoint_Shell_Access role. When a user has been added to the SharePoint_Shell_Access role and is a member of the WSS_Admin_WPG local group, then the user can run Windows PowerShell in a multiple-server farm environment.

I went and checked. Yep, sp_Farmadmin was a member of WSS_Admin_WPG. And in SQL Server, the login had a User Mapping to dbo in the SP_Config database. Within that database, dbo owned the SharePoint_Shell_Access role, but wasn't a member.

Seemed like a slam dunk from there. I logged into the machine again as the domain administrator account (who, as an admin with no specific privileges can run the SharePoint 2010 Management Shell successfully). I ran the Add-SPShellAdmin command and got a nice error "Cannot add domain\sp_Farmadmin to SharePoint_Shell_Access role of the database SP_Config. Possible cause of the error is when the user is the owner of the role."




So they can't be a member of a role they own. I confirmed it by trying to manually add the user to the role in SQL Server. Definitely can't be done. That's inconvenient. I tried to remove the User Mapping, but you can't do that, either. After playing with it a bit I realized the problem is that the user who created the database is mapped to dbo, and since dbo is a privileged identity, you do not want just anybody to be mapped to dbo.

As it turns out, the key to fixing this is to just make sure that the SP_Config database is created by the administrator and not by any special accounts you might want to use for administering SharePoint. Since it's preferable to control the naming of the Central Administration content database anyway, you can kill two birds with one stone by using PowerShell to create the config database using the New-SPConfigurationDatabase command. You can then run the SharePoint 2010 Products Configuration Wizard and when prompted to modify server farm settings, make sure you do not disconnect from the server farm.

Once SharePoint is configured, make sure to use Add-SPShellAdmin to let your users run the SharePoint Powershell cmdlets. This will add them to the SharePoint_Shell_Access role in the SP_Config database. It's supposed to also add them to the WSS_Admin_WPG role as well, but that didn't happen for me so I had to do it manually. Once both of these permissions were in place, the user should then be able to run SharePoint cmdlets. Keep in mind some of the cmdlets require Farm Administrator privileges, although just adding them to the Farm Administrator group is apparently not enough...



I'll keep digging on that one.