This article describes the administrative and service accounts required for deploying SharePoint Server 2010 and is a part of a series describing the complete installation of SharePoint Server 2010 on Windows Server 2008 R2 and SQL Server 2008 R2. Using the right accounts to install SharePoint is important independent of the kind of environment: development, staging, integration, test or production or what else.
The best thing about a SharePoint deployment in a least privilege scenario is the amount of accounts you need to manually create and assign permission. It's exactly one the setup account or setup administrator. Of course to completely install SharePoint we need a lot more accounts but luckily we don't have to assign permissions by hand. The rest of the needed accounts will get it's permissions by the setup account.
In a production environment you usually have a SQL Server service account to run the SQL Server, a domain administrator and Windows server administrator. To keep things simple and easy the setup administrator will be SQL Server administrator (sysadmin), domain administrator and Windows server administrator. This way I can use the same account for all administrative tasks I have to do in my development environment.
With SharePoint 2010 comes a new feature: managed accounts. A managed account is an Active Directory domain user. The thing that makes it to a managed account is the fact that the credentials are managed by and stored within SharePoint. If your Active Directory Domain Policy requires a user to frequently change it's password a managed account can be used to meet this requirement.
You can also stick with the solution for SharePoint 2007 where you needed to mark a user in Active Directory with the following properties: "User cannot change password" and "Password never expires". I still use this for my development environment.
It would be great if you leave a comment or join the discussion at the end of the post.
You can also go back to the beginning of the series were you can find an overview of the complete series and of course the farm topology and the deployment scenario.
Install SharePoint 2010 - Administrators and Developers Edt. 
See 12 steps you won't find in this article...
Please have a look at
Active Directory required accounts
It is strongly recommended to create domain accounts and use them as service accounts. You need to create at least the following accounts in Active Directory:
| Account type |
Account name |
| SQL Service |
sqlSvcAcc |
| Setup Admin |
spAdmin |
| Farm Account |
spFarmAcc |
Difference to SharePoint 2007
Service accounts in SharePoint 2007 needed 2 properties when they were created in Active Directory:
-User cannot change password and
-Password never expires.
This isn’t necessary with SharePoint 2010 since we now have managed accounts capable of password expiration and automatic change.
So in my development environment I will choose the options “User cannot change password” and “Password never expires”.
Assign permission
You need to assign permission only to the SharePoint 2010 setup administrator.
SQL Server service account
You don’t need to assign permissions since they are assigned during installation of SQL Server 2008.
The SQL Server service account is used to run SQL Server and should be a domain account.
Setup administrator
You need to manually assign permissions.
The setup administrator is used to install SharePoint 2010.
The SharePoint 2010 setup administrator has to be a member of the administrators group on every server SharePoint should be installed.
The SharePoint 2010 setup administrator needs to have the securityadmin and dbcreator role. The sysadmin role is assigned if you decide during SQL Server 2008 installation that your SharePoint 2010 setup administrator should be the SQL admin.
I decided to do so in my Hyper-V development environment.
Farm account
You don’t need to assign permissions since they are automatically assigned by the SharePoint 2010 setup administrator.
The farm account is used for the following things [1]:
- “Configure and manage the server farm.”
- “Act as the application pool identity for the SharePoint Central Administration Web site.”
- “Run the Microsoft SharePoint Foundation Workflow Timer Service.”
Resources
Here are the resources used in this article:
Next steps