Why all these service accounts?
I’ve started getting this question a LOT lately. I dug around for a few hours to see what I could find and I was shocked that I couldn’t find anything at all. That doesn’t mean there is nothing out there but really shocking to see that it didn’t come up in the first few pages of BING.
So the million dollar question:
Why do I need all of these SharePoint Service Accounts to run SharePoint?
I’m going to attempt to answer just that today. The short answer is you don’t need all those accounts, but you should read all of this article. The other day I was asked; how long does it take to install SharePoint? The answer I had really shocked the curious. “Well that depends really, do you want to do it the ‘Seldom right, wrong way…. The Right Wrong way, or the Right RIGHT way’”?
The fact of the matter is that there are, in my eyes 3.5 ways to install SharePoint:
1) The Seldom Right, Wrong way: (Stand Alone Server)This is usually for use in development environments. Demo boxes or SandBoxes.
a. Stand alone with a Database on the same box
2) The Right Wrong way:(Complete Farm using the Service Application Wizard) This is when you install SharePoint you build out a great farm but when you do the installation and subsequently the configuration you install all of your Service Applications (or a portion of) using the Service Application wizard.
3) The Right Right way: (Full install and create Service Applications manually) *Also Best Practice* This is where you get through the easy configuration and decline to run the Service Application wizard. You then manually create all of your Service Applications, using specific Service Accounts, Web Apps and Databases.
Woah, wait a second Eric. Are you saying the other ways are wrong? Why are they even available to the installer?
Short answer is that there are COMPLETELY VALID REASONS to do any of the previously mentioned methods of install. The fact that they can ever be considered wrong has everything to do with the plan for the instance by the enterprise.
Ok Eric, you have my attention. Why do I need to spend the time to create all of these service accounts. (and you better make it good because I know I can run SharePoint off of a single account).
Fair enough, let’s go at this in a Pro’s and Cons format. Cons first.
Takes forever: If your company has an IT side that manages AD and the turnaround time for creating these accounts and giving them permissions takes a week. Well yeah that stinks
Management: You or said I.T. dept has to now manage these accounts. The passwords etc.
Multiple Points of FAILURE: This is one way to look at the same coin. A point we’ll make in the pro’s. But it is true to an extent. More accounts you have the more chances something goes bad with one and a service goes down.
Updates: One of the larger con’s is that you need to consider when doing updates or patches that span multiple service account driven applications. And the account you are using to apply the patch doesn’t have domain admin access to apply patches.
Overall you just need to be conscious of the separation that you’re striving to achieve in having multiple accounts can in fact do its job VERY well and keep you from doing updates correctly.
Separation of Data: When it comes down to the nitty gritty and there needs to be “physical” boundaries between data you’ll want to use different service accounts. Think about search content access, user profile data etc.
Custom Database Names: This is a roundabout way pro for using separate service accounts and really is a point towards not using the Service Application wizard. It goes hand in hand that by not using the wizard you can use your own service account for the application and therefore being able to name the databases that get created when configuring specific Service Applications.
Custom Web App Names: Same as above, not using the wizard and using your own service accounts lets you dictate what names most Web Apps are called as well as what services run under them.
Multiple Points of REDUNDENCY: This is that flip side of the same coin we talked about above. Just as multiple accounts could be failure points. They are also redundancy levels. Think if you had all your services running under the same service account. What if that account went bad, password expired etc. All your services go down. Now think if you had all your proper service accounts structured out maybe just search goes down but the rest of your farm and access to its features is still up.
Managed Accounts: With the new feature of managed accounts in SharePoint 2010 we can now, as the great entrepreneur Ron Popeil says: “Set it ANNNNND forget it”! We can now set SharePoint to manage the passwords of our Service Accounts (yes that can be scary) but some of that risk is taken out of needing to worry about the passwords.
Least Privileges: This basically means that you can manage and control the exact level of permissions that SharePoint can operate under. Feel free to search on “SharePoint Least Privileges” it will give you a good understanding of just how lean you can run SharePoint and still have all things work correctly.
That’s really it in a nut shell. Do I think you should setup SharePoint using the recommended Service accounts? In a word, YES!
It will save you headaches, heartaches and long nights that are associated with permission based problems with SharePoint. Take the extra 2-3 hours to setup the accounts and the extra few hours (to days) setting up SharePoint the “RIGHT RIGHT” way.
So now when someone ask’s do we really need to create all these accounts for SharePoint. You’ll be able to answer them with pro’s and con’s of doing so. Many tell you the how and what for Service Accounts. Now you know the why.
and part 2 (the lengthy part) located here http://technet.microsoft.com/en-us/library/cc678863.aspx
|Hide Search Box in SharePoint Online
Updated: May 9, 2013
|So you want to brew beer
Updated: April 30, 2013
|The Sponsor role in SharePoint Saturday
|Windows Azure for SharePoint – Its Free!
|The Microsoft Surface Tested
Updated: February 10, 2013
|2012 PFE SPC Meet and Greet
|Building a Sitting - Standing desk
Updated: October 3, 2012
Updated: September 27, 2012