Before jumping into the actual installation, there are two important preparation items that we need to cover. Understanding and completing the preparation steps will ensure that your installation goes smoothly, preventing you from having to reformat your servers and start all over again. These two preparation items are:
- Understanding the SharePoint installation process, including the farm, server roles, and requirements
- Creating the necessary service accounts
Understanding the SharePoint Installation
SharePoint 2010 is different from other Microsoft server systems, and the installation steps reflect its uniqueness. The installation and configuration process is broken up into many steps. Knowing these steps, being prepared with the necessary input, and understanding the output are the keys to success. SharePoint also has its own set of terms and definitions. The broad terms that apply to SharePoint as a whole are introduced here. This section covers these areas:
- The farm
- The three server roles found in a SharePoint farm
- SharePoint’s hardware and software requirements
Understanding the Farm
SharePoint 2010 has been designed to scale from just a few users to tens of thousands. In terms of server counts, this can be just one or dozens. In SharePoint, a farm consists of all servers that share a configuration database, and they collectively provide the content and services needed.
Although it is easy to add and remove servers from the farm and adjust a server’s services, the servers and their farm are very tightly connected, like a close-knit family. The configuration database is the brain and heart of the farm. In many ways it seems alive, and there are synchronization jobs that run that are analogous to a heartbeat.
SharePoint’s farm is so close, literally, that you normally cannot separate the servers across a wide area network (WAN). For example, the network latency between a web server and a database server should be no more than 1 millisecond, something that’s nearly impossible to do as you add network distance and the usual switches and routers into the mix. In other words, all the farm servers should be co-located in the same datacenter.
You may be wondering, “How do I scale SharePoint to support global or multi-national companies?” A short answer for now is that this process usually involves setting up multiple farms, one in each major region. This topic is more thoroughly covered in Chapter 5, “Scaling and High Availability.”
Understanding Server Roles
Within the farm, there are three primary roles that a server can have. In very small farms (e.g., one or two servers), these roles will be shared on the same machine. As the farm expands, they often become more dedicated. Before installing SharePoint and creating the farm, we recommend that you define the servers and their roles. Although the roles are somewhat adaptable, it’s best to know up-front in order to avoid rework.
The three roles are web front end (WFE) server, application server, and database server. The basic communication between these roles and the browser client is depicted in Figure 1.1.
Figure 1.1: Communication between browser and server roles
Web Front End The web front end (WFE) is a web server, based on Internet Information Services (IIS), that receives direct HTTP (or HTTPS) requests from end user or client applications. A request could be from the browser for a web page or it could be a web service request from a client like Microsoft Word. Multiple WFE servers can be used with load balancing as covered in Chapter 5.
Application Server An application server also runs IIS, but it is configured differently than WFE servers. Specifically, it runs designated service applications (these are introduced in Chapter 4, “Creating Service Applications”). An application server may run services such as index (part of search) or Office Web Apps. Application servers receive their requests from the WFE servers, not directly from client machines. Multiple application servers can be used and automatically provide fault tolerance and load-balancing capabilities.
Database Server Database servers run Microsoft SQL Server and form the data tier for SharePoint. These servers receive requests from both WFE and application servers. SharePoint 2010 uses many types of databases, including a configuration database and multiple content and service application databases. SharePoint supports clustered SQL servers, database mirroring, and multiple SQL servers to provide scalability and fault tolerance. Details are covered in Chapter 5.
NOTE While it’s easy to classify servers in these three roles, they sometimes overlap in functionality. In particular, it is common to run certain service applications on WFE servers for performance reasons. Other than this exception, these roles are distinct.
Understand SharePoint Requirements
Since SharePoint scales out to multiple servers across each server role, you do not need super-powerful, scaled-up servers. Selecting the right number of CPU cores and amount of memory depends on many factors and is still as much of an art as it is a science. This concept is expanded on in more detail in Chapter 5. Table 1.1 lists the recommended minimum requirements that you must meet for each server role, assuming it will be for production use.
Table 1.1: Hardware requirements
NOTE A development or evaluation environment can function with less CPU and memory. At an absolute minimum, you should have two cores and 4 GB of RAM.
Estimating the amount of disk space needed can be much harder and is based directly on how much content is stored. For a WFE, the amount of space needed is relatively fixed and 80 GB is a comfortable amount. An application server, in particular a server running a query component (used with search), may have additional local space requirements. Estimating disk space needed for a query server is covered in Chapter 5. Estimating disk space needed for a database server depends on the amount of content stored in SharePoint. To calculate the space needed, see the article “Storage and SQL Server Capacity Planning and Configuration” at http://technet.microsoft.com/en-us/library/cc298801.aspx.
Table 1.2 describes SharePoint’s software requirements. The most notable point to keep in mind is that SharePoint requires 64-bit operating systems (OSs) and SQL servers.
Table 1.2: Software requirements
| Component | Minimum Version Required |
| Operating system | 64-bit Windows Server 2008 with SP2 64-bit Windows Server 2008 R2 |
| SQL Server | 64-bit SQL Server 2005 SP3 and CU3 64-bit SQL Server 2008 with SP1 and CU2 (or CU5+) 64-bit SQL Server 2008 R2 |
| Active Directory | Functional level should be Windows Server 2003 |
In addition to these requirements, SharePoint will install a number of prerequisites during the installation process, as explained in the “Installing Prerequisites” section later in this chapter. To learn more about the hardware and software requirements, see
NOTE While not supported for production use, SharePoint 2010 can be installed on top of Windows Vista or Windows 7. This is commonly done for a development environment. To learn more on how to build a development environment on these operating systems, see http://msdn.microsoft.com/en-us/library/ee554869.aspx and http://blogs.msdn.com/b/cjohnson/archive/2010/10/28/announcing-sharepoint-easy-setup-for-developers.aspx.
Understanding the Creation of Service Accounts
This section covers the service accounts that must be created prior to starting the SharePoint installation. Just as with other server applications, service accounts are the Active Directory (AD) domain accounts that each service uses. Since SharePoint provides a multitude of services, a number of service accounts are needed. Which ones you need depend on which services you use. This section covers the minimum necessary accounts for a basic installation. As you learn more about service applications in Chapters 4, 7, 8 and 9, others are introduced.
Table 1.3 introduces the three accounts that are needed for installation.
Table 1.3: Service accounts needed for installation
| Account Type | Purpose | Details and Permissions |
| Install account | Account used to install SharePoint and create or join a farm | Domain account Local administrator on each WFE and application server Has a login to database server with dbcreator and securityadmin server role permissions |
| SQL Server service account | Account used to run MSSQLSERVER engine service | Domain account (recommended) Permissions to UNC Path where farm backup is stored |
| Farm account (aka database access account) | Creates databases and runs key farm services | Domain account |
| Application Pool account(s) | Executes requests received by a web application | Domain account Used when creating web applications; see Chapter 2 |
The permissions listed in Table 1.3 are the minimum permissions that must be manually granted. SharePoint or the OS will automatically grant additional permissions. When creating your service accounts, here are the security best practices you should follow:
- When creating these accounts in AD, it is best to store them along with other service accounts in a separate organizational unit (OU).
- Consistently follow a naming convention for your accounts. For example, name each account starting with “SP.”
- SharePoint can detect accounts whose passwords are about to expire and automatically change the passwords for you. (This is covered in more detail in Chapter 14, “Managing Security.”) If your security policy requires password expiration, it is best to follow that and you can rest knowing that SharePoint makes this process easy to manage.
- Configure these service accounts following the “principle of least privilege,” meaning that you do not grant additional permissions other than the minimum that are needed.