AutoSPInstaller: Prepare Server Hardware, Software and System Accounts
This post is part of a series covering how to configure and run AutoSPInstaller, a set of scripts that can be used to automatically install SharePoint. In this post, we will look at the first step: preparing the server hardware and software that will run your farm and configuring the system accounts that will be used within the farm.
Update: This post has been running for years and the AutoSPInstaller team now has an official site with guides, Q&A and an automated, browser-based AutoSPInstaller GUI . You can find it at http://autospinstaller.com.
More posts in the series:
- Automated SharePoint Installations: Step-by-step (Overview)
- Prepare Server Hardware, Software and System Accounts
- Preparing the Base Media
- Prepare Server for Unattended Installation
- Prepare the Scripts
- Executing the Scripts, Post-Execution Tasks
Hardware Requirements
The following requirements must be fulfilled prior to the installation of SharePoint Server 2010 and 2013. There are many discussions on v-CPUs versus physical cores. These are the recommended setup from Microsoft and what I go with.
| Component | Minimum Requirement |
| Processor | 64-bit, four cores |
| RAM | 12-24 GB. Notes: 8gb can be used for evaluation or development environment but is not recommended for real-world usage. Single server deployment on SharePoint 2013 or deployment on server with SQL Server needs 24gb RAM. |
| Hard disk | 80gb for system drive. For databases, see Capacity management and sizing for SharePoint Server 2010 Capacity management and sizing for SharePoint Server 2013 From experience, I recommend 160gb for system drive and a separate 50gb drive for logs and search indexes. |
For full details see
Hardware and software requirements (SharePoint Server 2010)
Hardware and software requirements for SharePoint 2013
Software Requirements
The servers should be joined to the Active Directory domain and have a base Windows Server installation. Note that SharePoint 2010 does not support Windows 2012. I know there are hacks out there to make this work, but the bottom line is that this is not supported by Microsoft.
| Component | Minimum Requirement |
| OS | SharePoint 2010: Windows Server 2008 64-bit with SP2 or Windows Server 2008 R2 64-bit (recommended) SharePoint 2013: Windows Server 2008 R2 64-bit with SP1 or Windows Server 2012 (recommended) |
| OS Edition | Standard is customary for SharePoint servers. Will work with Standard, Enterprise, Data Center or Web Server with SP2. Clustered SQL servers require Enterprise edition. |
| Server Roles and Features | No features or roles installed. Note: Install base Windows with drivers only, the setup will take care of IIS and other components. |
| Database | SharePoint 2010: SQL Server 2005 with SP3 and Cumulative Update package 3 or SQL Server 2008 with SP1 and Cumulative Update 2 or SQL Server 2008 R2 (recommended) SharePoint 2013: SQL Server 2008 R2 with SP1 or SQL Server 2012 (recommended) |
For full details see
Hardware and software requirements (SharePoint Server 2010)
Hardware and software requirements for SharePoint 2013
System Accounts
Again, there are lots of discussions about how many accounts to use. As an overview, the installer account should have admin rights on SharePoint servers and the farm account, i.e. the main SharePoint system account, should not. This could lead to SharePoint having too much control of the servers and cause security risks. The configuration below uses many accounts but provide me with the breakup of rights that I like. It’s up to you.
For a minimal accounts configuration, you could for example use the SP_Service account for Cache Admin, Cache Reader, Excel, Visio and Performance Point. You could also use a generic SP_AppPool account for all application pools. Personally, I wouldn’t use less accounts than that.
These accounts must be created and passwords must be made available before installation begins. Naming standards are examples and may be changed to reflect internal policies.
| Account Type | Account Name | Rights/Notes |
| Install Account | SP_Install | Administrative rights on SharePoint servers. SQL roles DBCREATOR and SECURITYADMIN. Will be disabled after install is completed. |
| SQL Service Account | SQL_Service | If not already installed, domain account with no local rights above Domain User. |
| Farm Administrator | SP_Farm | No local rights or SQL rights above Domain User. |
| Application Pool | SP_PortalAppPool | One account per application. For example one per intranet, extranet and public website. Naming standard could be SPS_APP_POOL1 or SPS_APP_POOL_INTRANET. No local rights or SQL rights above Domain User. |
| My Site | SP_ProfilesAppPool | No local rights or SQL rights above Domain User. |
| Services | SP_Services | No local rights or SQL rights above Domain User. |
| Search Agent | SP_SearchService | No local rights or SQL rights above Domain User. |
| Search Crawl Access | SP_SearchContent | No local rights or SQL rights above Domain User. |
| Profile Access | SP_ProfileSync | No local rights or SQL rights above Domain User.
Important: Account needs “replicate changes” rights in Active Directory. For more info, see TechNet. For a script to test if the account was set up correctly, see my CodePlex site. |
| Cache Admin | SP_CacheSuperUser | No local rights or SQL rights above Domain User. |
| Cache Reader | SP_CacheSuperReader | No local rights or SQL rights above Domain User. |
| Excel Service Account | SP_ExcelUser | No local rights or SQL rights above Domain User. |
| Visio Service Account | SP_VisioUser | No local rights or SQL rights above Domain User. |
| Performance Point Service Account | SP_PerfPointUser | No local rights or SQL rights above Domain User. |
For more information see
Initial deployment administrative and service accounts (SharePoint Server 2010)
Initial deployment administrative and service accounts in SharePoint 2013