Microsoft SharePoint Products and Technologies Administrators Pocket Consultant

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.

Software Requirements

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

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.

Security Accounts

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 (domain\SAfarm) 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 (domain\SAwss1) 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.

  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 (domain\SAwssn) If security is important to your organization, create an additional account for each Web application. For example, create multiple accounts, such as domain\SAwss2, domain\SAwss3, 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.

• 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.

SQL Server Security Accounts

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.