12

We’ve all been there assigning all accounts to install SharePoint. Specifically we use a setup account (SP_Install) and a farm administrator account (SP_Farm). When we install signed in to the server with SP_Install and run AutoSPInstaller with the same account a lot of things happen. The services Timer Service and Central Admin runs as SP_Install and not SP_Farm as it should. The same goes for the beloved User Profile Synchronization Service which also runs as SP_Install and not SP_Farm as it should.

Spence Harbar have the same opinion when he says:

. . . think of this like the SharePoint “setup” user, which is often promoted as a “best practice” but is nothing of the sort.

I’ve started running AutoSPInstaller signed in to the server and running as administrator with the Farm Administrator Account (SP_Farm) and everything gets to be where I want it to be.

Do we really REALLY need the setup account (SP_Install)?

1
  • just a side note here, this also could be due to the configuration of AutoSPInstaller. The numerous times I've used it, I've never had a run-in with the Setup account running CA or the timer service, the farm account did that upon installation.
    – Mike
    Commented Dec 21, 2015 at 17:02

4 Answers 4

6
+50

Short answer, no. You don't need it. It's just a super, no bars account that all the rest of the accounts' permissions are designated from. As part of the "best practice" its one of those accounts that Microsoft suggests to set everything up with the least-privileged account security model.

AutoSPInstaller is a great tool I still rely on today, but running it on the SPFarm account would give all the permissions to SPFarm, which I wouldn't bat an eye at.

The Setup user account is used to run the following:

  • Setup
  • SharePoint Products Configuration Wizard

Source: Initial deployment administrative and service accounts in SharePoint 2013

3
  • In other words I should use SP_Install to install SharePoint using AutoSPInstaller and not install any service applications or web applications since SP_Install will act as SP_Farm in that case?
    – Benny Skogberg
    Commented Dec 19, 2015 at 9:38
  • Find me a reference to your statement, and you're worth the bounty! And it doesn't have to be MS.com site :-)
    – Benny Skogberg
    Commented Dec 21, 2015 at 16:48
  • 1
    Other than this, technet.microsoft.com/en-us/library/ee662513.aspx I find most references explain setup accounts are for use of just setup and running psconfig, which would be then done by the farm account if you don't use the install account. Notice the "we recommend the least-privileged administration" note at the bottom. But let me digress, I always install using the SPInstall account. In other words, I wouldn't recommend it, but I'm saying SharePoint doesn't require it.
    – Mike
    Commented Dec 21, 2015 at 16:57
5

The sp_install user should only be used to execute the base/initial installation of SharePoint. The sp_farm account is used after the setup in the SharePoint Configuration Wizard. And after that all Services should run under SP_Farm Account as expected.

I don't know if you can separate the accounts in the AutoSPInstaller but i am sure it will be ok to only use the SP_Farm Account.

1
  • 2
    Thank you STORM! I know this is the case installing without AutoSPInstaller, and I'm not sure if I can configure it the way I want. But the question is - do we really need the setup account? For what purpose should we use it? I'm not sure I have an answer here . . .
    – Benny Skogberg
    Commented Dec 17, 2015 at 11:50
4

I've always intalled my SP farms with SPInstall (often named SPAdmin in my cases). When prompted by the setup program for the account to run the farm with, I enter SPFarm. After that, everything is usually configured OK, i.e. SP Timer, CA pool, etc. run Under SPFarm.
I then use SPInstall (aka SPAdmin) to log on the machine and administrate SP (i.e. access CA and PowerShell). This prevents you from logging with SPFarm witch may be a bad practice.

3
  • Nice! So you're not using AutoSPInstaller and get permissions right directly. I'm beginning to think that AutoSPInstaller is the real issue here.
    – Benny Skogberg
    Commented Dec 20, 2015 at 12:16
  • Yup, I don't use AutoSPInstaller: I don't think it is needed, and it may indeed introduce bias in the installation. Nothing like understanding what happens exactly :) But you still can use scripts to provision application services, so that DB names keep good.
    – Evariste
    Commented Dec 20, 2015 at 14:44
  • 1
    Also, not using AutoSPInstaller gives you the opportunity to document/screenshot precisely what you've done to install your farm. Anyone else, even without AutoSPInstaller knowledge and XML understanding, can get it.
    – Evariste
    Commented Dec 20, 2015 at 14:46
0

If you are going to quote Spence Harbar on the farm account, be sure to read all of his blogs:

You don’t need to log on as the Farm Account ever to get UPS (or anything else) working. Logging on as the Farm Account is a very, very bad idea and you shouldn’t be doing it. from http://www.harbar.net/articles/sp2010ups2.aspx.

So no, you should not log in with the SP_Farm account. As I read it from the post you reference is that you don't need a specific sharepoint install account. Any account with enough permissions (local admin & domain user) will do. But not the Farm account.

For me it's just a matter of easy maintenance. You don't need to worry about which user will have the right permissions to administer the SharePoint farm. No need to worry on who has the right permissions to use PowerShell etc.

I've used AutoSPInstaller before and it respects the user account best practice. I log into the server with the install account, run AutoSPInstaller and configure it to use the relevant service accounts. I've never seen it that it would run services under the install account.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.