In this chapter:
Installing the First Windows SharePoint Services Server in the Farm 26
Installing the First SharePoint Server 2007 Server in the Farm 37
Upgrading Windows SharePoint Services to SharePoint Server 48
Before inserting the installation media and choosing Next, take the time to understand the different options available to you in the setup wizard. If you make the wrong selection during setup, it could mean a complete uninstall and reinstall of the binaries. In addition, making good choices in the beginning will make it considerably easier to scale SharePoint products. The following decisions must be made before installing SharePoint products:
Choose a SQL Server type During installation you will have the option either to install all components (including SQL Server Express Edition) on a single computer or to choose a dedicated SQL Server installation for the databases. Choose the SQL Server Express Edition option only when you are sure that you will not scale to a server farm in the future. Although scaling to a server farm is technically possible, migrating SharePoint products from SQL Server 2005 Express Edition to SQL Server Enterprise or Standard is a tedious task.
Use either host headers or assigned IP addresses Host headers ease installation and reduce administrative overhead, but assigning IP addresses strengthens your overall security posture. Assigning an individual IP address for every Web application simplifies your logs and allows for separate firewall rules.
Process security isolation Depending on the level of security your organization requires, you may choose to install with one or several accounts for Internet Information Services (IIS) application pools and database access. It is much easier to install with separate accounts in the beginning than it is to change and isolate application pools later.
Assign administrators You must define the administrative roles and separation of duties. If you wish to granularly define administrative roles, pay close attention to the details of service accounts and groups. If you are in a small organization, consider using a dedicated farm account for all administrative tasks.
Create a site template for the Web application root When creating your first Web application (other than a Shared Services Provider or My Sites dedicated Web application), it is wise to create a site collection in the root. This site can be modified, but the site definition cannot be changed, so give careful consideration to the template type. Many SharePoint Server 2007 implementations use Portal templates when creating the root site collection.
This chapter covers Microsoft Windows SharePoint Services 3.0 and SharePoint Server 2007 deployments, whether using Internet Information Services (IIS) host headers or assigned IP addresses. When neither Windows SharePoint Services nor SharePoint Server is stated, the material applies to both software products.
At a minimum, before installation, sketch out your design, including IIS configuration, SQL Server databases, accounts, administrators, and any other pertinent data you will need. Microsoft Office Visio is a very helpful tool when designing and maintaining server farms with multiple Web applications, IIS servers, and SQL Server databases. In addition, verify that you have met the minimum hardware requirements and have created all Active Directory accounts, if using Active Directory for authentication, before beginning the installation wizard.
Before you can install SharePoint products and technologies, you need to install the following foundational components:
Windows Server 2003 (any edition) SP1 or later
Fresh install of IIS 6.0 or later (install before ASP.NET 2.0 or 3.0)
SMTP Server (if implementing mail-integrated document libraries)
ASP.NET 2.0
ASP.NET 3.0
Note
You cannot install Windows SharePoint Services or SharePoint Server in Basic or Standalone mode when using Windows Server 2003 Web Edition.
If possible, always install Windows SharePoint Services or SharePoint Server on a freshly installed Windows Server. Using servers that previously hosted other applications, or were imaged and had the SID changed, has proven to be a bad idea.
Before starting the installation wizard for any SharePoint product, create all the accounts required for installation. If you require program isolation within Windows SharePoint Services or SharePoint Server, you must create an application pool identity account for every Web application created. If yours is a low-security implementation, you can create a single application pool identity to be shared by multiple Web applications. When planning for enhanced security, create IIS application pool process accounts that correspond with the SQL Server security accounts for their respective Web applications. The following list describes the basic accounts needed to install SharePoint products and gives suggested service account names:
Setup account The account used for installing SharePoint products should be a domain user account if using Active Directory for authentication, and a member of the local administrator's group on every farm server. It should also have the following rights in the SQL Server:
SQL Server Logins
SQL Security Admin
Database (DB) Creator
Server farm account (domainSAfarm) Put the server farm account in Active Directory when possible, and do not use it for installation. The server farm account can be used for all application pools in an unsecured installation. This use makes account management and administration easier, but reduces the ability to isolate users and processes. The server farm account is granted server permissions automatically during setup, but the following permissions must pre-exist in SQL Server:
SQL Server Logins
SQL Server Admin
SQL Server DB Creator
DBO (Database Owner) for all databases
First Web application account (domainSAwss1) If you don't want to create an account for every Web application, strongly consider creating at least one account for all Web applications to share.
Note
Best Practices Always use a dedicated account for the Central Administration IIS application pool.
This account requires the following SQL Server permissions:
Database Owner for content databases associated with the Web application
Read/Write access to the associated Shared Services Provider (SSP) database (SharePoint Server only)
Read access to the configuration database
Additional Web application accounts (domainSAwssn) If security is important to your organization, create an additional account for each Web application. For example, create multiple accounts, such as domainSAwss2, domainSAwss3, or any naming convention you choose, as long as it is consistent.
Shared Services Provider accounts (SharePoint Server only) The SSP IIS application pool and SSP service should use the same authentication account, but it must be different from the server farm or other Web application accounts. This account requires the following SQL Server permissions:
DBO for the SSP content database
Read/Write to the SSP content database
Read/Write to associated content databases (associated Web applications)
Read from the configuration database
Read from the Central Administration database
Although creating multiple application pools and corresponding accounts enhances your security posture, it is important to note that creating each additional application pool adds another W3wp.exe process, thereby consuming additional memory. If you have installed using the minimum recommended hardware, you must either configure with fewer application pools or increase the memory in your server.
Important
Each application pool process account must be a member of the Local Administrators group on every server in the farm.
Windows SharePoint Services search service This account can be a local account or domain account. If you are using SharePoint Server, you need only one server running Windows SharePoint Services search for indexing the Help files.
Windows SharePoint Services content access The account used for Windows SharePoint Services content access should have the ability to crawl all data in your environment. For ease of administration, it can be the same account that is used for the Windows SharePoint Services search service.
SharePoint Server Search service account This account can be the same account used for either Windows SharePoint Services search or your server farm account. Most installations use the server farm account.
SharePoint Server Search content access The default content access account should have wide-reaching access to your content. Often, this account has only Read-Only privileges across much of an enterprise. For ease of administration, this account should not expire or at least should expire infrequently because you must reset the service password when the password changes.
SharePoint Server user profile import account If you have multiple forests, isolated administrative access among domains, or a third-party Lightweight Directory Access Protocol (LDAP) provider, you must provide an account for importing accounts.
SharePoint Server Excel Calculation Services unattended service account For default source access to Excel Calculation Services data, use the SSP account for IIS and database access. If security is of paramount concern in your organization, change this account to one that does not have database access.
Creating SQL Server security accounts is done very similarly to creating your other SharePoint accounts. In many circumstances these accounts are the same ones used for creating Web applications, thereby essentially isolating similar processes and providing enhanced security. You may modify these accounts to fit your situation, but be careful when restricting access between Web applications and their databases, as unexpected negative behavior is possible when modifying access. The following are recommended settings when installing SQL Server and creating security access accounts:
SQL Server 2005 Express Edition (Basic, Stand-alone)
Verify that the default accounts created and used during setup are Local Administrators.
The Network Service account must be a System Administrator in SQL Server.
SQL Server Standard or Enterprise Editions
The SQL Server setup account (setupadmin in SQL Management Studio) should be a domain account if possible. However, when installing Windows SharePoint Services in a workgroup, the SQL Server setup account can be a local account.
Installing Windows SharePoint Services or SharePoint Server in a workgroup environment using local authentication accounts is beyond the scope of this book. For ease of installation and administration, use Active Directory for user and services authentication. For more information on the topic, browse:http://www.microsoft.com/technet/prodtechnol/office/sharepoint/default.mspx.
The SQL Server service account should be a domain account and should not be the same account used for the Central Administration application pool identity. This account does not need to be a domain administrator. Although it is possible to use SQL Security for authentication, only consider doing so in highly customized environments with experienced developers on staff.