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:

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