Skip Ribbon Commands
Skip to main content

Quick Launch

Todd Klindt's home page > Todd Klindt's Office 365 Admin Blog > Posts > How to create a SharePoint 2010 admin account and stop using sp_farm
March 16
How to create a SharePoint 2010 admin account and stop using sp_farm

I’ve been getting a lot of questions on Twitter and during my netcast about permissions. People seem to really be taking security seriously these days. It seems gone are the days of installing SharePoint as a domain administrator, running everything as domain administrator and logging in as domain administrator to administrate SharePoint. I think this is a great move, and I’ll admit to slacking a little when I install and demo SharePoint 2010. I normally do everything as sp_install or sp_farm (service account explanation) because that’s easiest. Of course that’s horrible idea, and I do feel suitably ashamed of myself. I was asked about this during a netcast a couple of weeks ago, and again in a comment on my blog this week. I decided to break down and go through the process of setting up an account you can use to administrate your SharePoint 2010 without leaning on the sp_farm crutch. Here we go.

Create the account

The first step is to create the account in active directory. Do NOT use your regular user. You don’t want to accidently delete something in SharePoint because it’s available logged in as an admin user. Also, having a non privileged account makes it possible for you to see problems the same way a regular user would. It’s also a good idea for your admin account to have a different password than your regular account. I know, I know, having another username and password to remember sucks. I feel your pain. You’ll be a better person for it though.

My normal account is contoso\todd, and I created contoso\todd_admin for this exercise. I didn’t do anything special in ADUC or give it an elevated permissions. I put the account’s description in all capital letters so it would stick out. It looks like this in ADUC:


One of the companies I used to work at used this convention and I liked it so much I stole it for my very own.

Giving it permissions

Now that the account is created, let’s start giving it some permissions. Before we do that though, let’s verify what works and what doesn’t. I was able to log into my SharePoint servers without any changes, but I couldn’t do anything to SharePoint once I got in there. Here’s what happened when I try to run the SharePoint Management Console:


If I try to sneak into Central Admin I’m greeted warmly with this:


So we know this account really doesn’t have the permissions to do anything. Since we’re already in Central Admin let’s log in as a privileged user and take care of it first. The first step we need to take is to add our todd_admin account to the Farm Administrators group. In Central Admin this is under Security > Manage the farm administrators group. Central Admin is just a site collection, and all we’re doing is giving our todd_admin account permission to log into it. It looks like this:


No need to send yourself an email, you already know you’re in there. Now if you try to get into Central Admin as your admin account you get this:


Hurray! We’re almost there. You will find that while most of Central Admin is available to you, a few things still won’t work, like creating a new web application or service application. I’ll cover that later.

While getting into Central Admin is fun, we still can’t get in to where the real fun is, PowerShell. The key to fixing this is the PowerShell cmdlet Add-SPShellAdmin. This cmdlet does a couple of things. First, it adds our admin account to a database role (SharePoint_Shell_Access) that gives us permission to do things that require changes to the database. It also adds our account to a local group (WSS_ADMIN_WPG) on the SharePoint server to give us permissions to make changes there too. Because of that granularity you have to run Add-SPShellAdmin against every database you want it to change, and on all of your SharePoint servers. To meet the first requirement, and to show off a little, I used Get-SPDatabase to get all the databases in my farm, and then I piped it through Add-SPShellAdmin. It looks something like this:


That didn’t go well, did it? Like I said before, Add-SPShellAdmin makes changes to each database’s permissions, so the account you run it as has to have permission to do that. Even though sp_install has the securityadmin role on the SQL server, it doesn’t have permission to change this security. Before you run Add-SPShellAdmin make sure the account running it (in my case sp_install) either is in the db_owner group on each databsae, or is in the sysadmin role in SQL. I added sp_install to the sysadmin role and ran my command again:


Like they say, no news is good news. To verify it really worked I checked the local machine permissions and the database permissions. Local machine:


Good, good. Now SQL.


Yup, I’m there too. Let’s fire up PowerShell and see if I have any better luck.


I think that counts as a win.

From my screenshots you might think it’s all fixed and that nothing stands in the way of contoso\todd_admin and pure SharePoint administrative bliss. We’re close, we’re really, really close. There are a couple of stumbling blocks though. For instance, I still can’t create web applications or service applications. The option is just greyed out. Also, firing up Central Admin on the server or firing up PowerShell is problematic because they require the administrative token to open up, and todd_admin doesn’t have that. I was able to open Central Admin from my workstation (and let’s be honest, that’s probably where you should be doing it anyway) and I assume PowerShell remoting would have worked, but I didn’t try it. To get those last two pieces to work correctly I had to put todd_admin in the local admin group. I’m not proud of that, but it worked. Again, that was only necessary for that account to create new web apps and service apps, and to access PowerShell and Central Admin locally on the server.

There you have it. Now you know how to make a dedicated SharePoint admin account and you can stop logging in as sp_farm and sp_install.




Good Idea..

Hey Todd...
Thanks for the good idea, and better yet the steps to get it done.  I really appreciate all you do out there for us! 
 on 3/16/2011 11:42 PM

Nice article

Enjoyed reading this article, Todd. Thanks.

Though, I do have a question:

In the end you've added your account to the local Administrators anyway and because of that you're a member of WSS_ADMIN_WPG as well. Is the cmdlet Add-SPShellAdmin then still needed for every database? Or would it be sufficient to add your account to the SharePoint_Shell_Access role in the SharePoint_Config database? If I examine my content databases now, there is no such SharePoint_Shell_Access role and the application pool identity is the one that has db_owner rights. The sp_farm is not part of any role.
 on 3/17/2011 3:14 AM


Thanks Todd!   This is a very helpful reference and I appreciate you taking the time to document it with screen shots.
 on 3/17/2011 8:29 AM

Re: Good Idea..

Thanks. I'm glad it's helpful. :)

Todd O. KlindtNo presence information on 3/17/2011 8:33 AM

Re: Nice article

My account is a member of the local WSS_ADMIN_WPG  group because I ran Add-SPShellAdmin. That's one of the things that cmdlet does. You must run Add-ShellAdmin for every database you want your account to touch. If you just run it against the ConfigDB then you'll only be able to make changes there. You won't be able to do things like enumerate webs, or users, stuff like that. You need acccess to the content database itself for that.

The SharePoint_Shell_Access database role is created the first time Add-SPShellAdmin is run against a database. Out of the box it's not there. That's expected.

Todd O. KlindtNo presence information on 3/17/2011 8:36 AM

Re: Thanks!

My pleasure. Thanks for reading it and commenting.

Todd O. KlindtNo presence information on 3/17/2011 8:41 AM

Cool post

The PS (Add-SPShellAdmin) to add the is good, I've been doing it by hand and documenting the change.  Not ideal or reproducable so definately better to do it correctly.
 on 3/17/2011 11:58 AM


Hi Todd,

A couple of suggestions:
i always prefix service accounts with svc (eg svcSPFarm) in contrast to accounts that i can use to login locally (eg SPInstall, SPAdmin). That way you signal "dont ever use this account to log on locally on the box".

Another issue is when you use the SPShellAccess cmdlets and UAC is enabled, you will get weird errors even when running the command even as your install account. To work around this, use Run as Administrator when firing up PowerShell
Local admin (read more on my blogpost on SPShellAccess here )

Regarding the discussion on weather the admin account should be local admin or not: if your account will be used to add solutions (eg. Add-SPSolution) you will need local administrative rights -i have found no workarounds for this. Also "services on server" and certain security settings only shows up if your admin user is local admin (havent noticed issues related to webapp creation, but ill test that)

Good write up. I guess you finally got bored with me asking how to set this up ;-)

Anders Rask
 on 3/18/2011 6:53 AM

Re: Cool post

Oh goodness, doing it all by hand? That sounds horrible. Now I'm REALLY glad I wrote up this blog post. :)

Todd O. KlindtNo presence information on 3/18/2011 8:47 AM

Re: Suggestions

Hey Anders,
Thanks for your comments. I'm sure my readers will enjoy them. :)

Todd O. KlindtNo presence information on 3/18/2011 8:48 AM
1 - 10Next

Add Comment

Items on this list require content approval. Your submission will not appear in public views until approved by someone with proper rights. More information on content approval.


Body *

Today's date *

Select a date from the calendar.
Please enter today's date so I know you are a real person


Want a message when I reply to your comment? Put your Twitter handle here.