Installation Considerations for Windows SharePoint Services 2.0

There are certain choices that you must make either before or during your installation of Microsoft Windows SharePoint Services. Some of these choices, such as the database type you use, can be changed later without causing a lot of extra work. Other choices, such as the user account mode you will use, cannot be changed unless you uninstall and reinstall Windows SharePoint Services. If you are installing Windows SharePoint Services in a large scale environment, such as a server farm, it is critical that you make the right choices at the very beginning. Be sure that you carefully consider the following before you install Windows SharePoint Services.

Note

If you are upgrading from SharePoint Team Services 1.0 from Microsoft, there are additional options to consider before installing. For more information, see Upgrade Considerations (Windows SharePoint Services 2.0).

Choosing a User Account Mode

When you install Windows SharePoint Services, you must choose which user account mode you want to use. Windows SharePoint Services can work with either of the following user account modes:

  • Domain account mode   This mode is used inside organizations to grant users with existing Microsoft Windows domain accounts access to Windows SharePoint Services.

  • Active Directory account creation mode   This mode is used by Internet Service Providers to create unique user accounts for customers in Microsoft Active Directory directory service. These accounts can then be assigned to groups in Windows SharePoint Services to grant customers the appropriate level of access.

You cannot mix user account modes in Windows SharePoint Services. Rather, you must choose only one of the user account modes listed above. The difference between these two modes is the method you use to create user accounts. In Domain account mode, you use existing Windows domain user accounts. In Active Directory account creation mode, accounts are automatically created in the Active Directory organizational unit you specify. Regardless of the user account mode you choose, you use the same methods to manage users of a site. You add them to the site using their existing domain or Active Directory accounts, and then assign them to site groups to give them the rights they need to use the site.

After you install Windows SharePoint Services, you cannot change the user account mode. This is because the user account you specify during the install process affects how the configuration database for your server or server farm is created, and you cannot change user account modes after creating the configuration database.

Note

If you use Microsoft SQL Server 2000 Desktop Engine (Windows) (WMSDE) as your database, the configuration database is created when you install Windows SharePoint Services. If you use SQL Server 2000 or SQL Server 2005 as your database, the configuration database is created after you install Windows SharePoint Services. For more information about user account modes, see Managing Users and Cross-Site Groups (Windows SharePoint Services 2.0).

  • When you are in Active Directory account creation mode, there are certain administrative tasks that are unavailable in the HTML Administration pages. For example, you cannot create a top-level Web site, you cannot enable Self-Service Site Creation, and you cannot add a user to a site from the Central Administration pages. To perform these actions in Active Directory account creation mode, you must use the command line or the object model. For more information, see Using the Object Model to Manage Windows SharePoint Services 2.0.

  • The Minimum Password Age group policy on the domain controller must be set to 0 days. Failure to do so will result in users being unable to change their passwords, unless they have administrator rights on the server. For information on setting the Minimum Password Age group policy, see Microsoft Windows Server 2003 online help.

Choosing a Database Type

Windows SharePoint Services stores all site data and content, plus server configuration information in a database that you specify during setup. Windows SharePoint Services supports the following databases:

  • Microsoft SQL Server 2000, Service Pack 3 or later, or SQL Server 2005   SQL Server includes many tools for managing database processes, such as backup and restore. When using SQL Server 2000 or SQL Server 2005, you can configure multiple back-end database servers to store as much content as you need and balance the load across the database servers.

  • Microsoft SQL Server 2000 Desktop Engine (Windows) (WMSDE) Service Pack 3 or later   WMSDE has only a small subset of the features available with SQL Server 2000 and SQL Server 2005. For example, WMSDE does not include tools for backing up and restoring the database, and does not support full text search.

    Note

    Windows SharePoint Services, prior to SP2, includes WMSDE with Service Pack 3.

    Note

    Windows SharePoint Services Service Pack 2 includes WMSDE with Service Pack 4.

    Note

    Windows Server 2003, Web Edition and x64-based editions of Windows Server 2003 require the full version of SQL Server 2000 or SQL Server 2005 rather than WMSDE.

    Note

    The x64-based edition of Windows Server 2003 R2 supports both WMSDE SP4, SQL Server 2000 SP3 or later, and SQL Server 2005.

You choose which type of database to use when you install Windows SharePoint Services. By default, Windows SharePoint Services installs WMSDE during setup when you use the Typical option. If you have SQL Server, either on the same computer or on a separate computer, you can choose the Server Farm option, which does not install WMSDE. Then, after Windows SharePoint Services is installed, you can connect to the SQL Server database to continue configuring Windows SharePoint Services.

If you install Windows SharePoint Services on a single server with WMSDE, anticipating only light usage of your Web sites, and later find that you require more database power, you can migrate your data to a SQL Server 2000 or SQL Server 2005 database.

For more information about changing database types after installation, see Migrating from WMSDE to SQL Server 2000 (Windows SharePoint Services 2.0) and Migrating from WMSDE to SQL Server 2005 (Windows SharePoint Services 2.0). For more information about databases and architecture, see Windows SharePoint Services 2.0 Architecture.

Choosing an Authentication Type for SQL Server

If you choose to use SQL Server with Windows SharePoint Services, you must also choose the authentication method to use for connections between Windows SharePoint Services and the SQL Server database or databases. You can use either Windows authentication or SQL Server authentication for these connections.

  • Windows authentication is more secure, because it depends on the domain credentials for a Microsoft Internet Information Services (IIS) application pool to connect to the SQL Server database. The user name and password are not sent between servers, but are abstracted through the IIS application pool.

    Note

    Using a domain user account might require additional steps to add a Service Principal Name (SPN) to the account. Information about adding a Service Principal Name (SPN) to a domain user account is available in Using Integrated Windows Authentication with Windows SharePoint Services 2.0 and the Microsoft Knowledge base article 832769: How to configure a Windows SharePoint Services virtual server to use Kerberos authentication.

    Note

    When SQL Server is installed, and Windows Authentication is selected, SQL Server 2005 will use Kerberos, by default. For Windows SharePoint Services to connect to SQL Server 2005, in this case, the Service Principal Name (SPN) for the SQL server service must be registered under the Windows domain account running SQL Server 2005.

  • SQL Server authentication is less secure than Windows authentication, because the username and password for the database administrator account are sent from server to server in unencrypted format when you connect to the database.

You make the database authentication choice after installation, when you connect to the SQL Server databases for the first time.

For more information about security, see Windows SharePoint Services 2.0 Security Model. For more information about authentication methods for SQL Server, see the SQL Server 2000 and SQL Server 2005 documentation.

About WMSDE and Authentication Types

When you install Windows SharePoint Services with the typical settings, WMSDE is installed to provide database support. Windows SharePoint Services uses the authentication method specified in the IIS metabase, which is Integrated Windows Authentication, by default. Integrated Windows Authentication contains both Kerberos v5 authentication and NTLM authentication methods. The authentication method that is used when Windows SharePoint Services connects to WMSDE is determined by the value of the NTAuthenticationProviders metabase property in IIS. If this property is not set (is null) or is set to Negotiate,NTLM then Kerberos authentication is used, otherwise NTLM is used. For more information about Integrated Windows Authentication, see the Integrated Windows Authentication topic in the IIS 6.0 Administrator Guide.

Note

In earlier versions (prior to Service Pack 2), installing Windows SharePoint Services would change the authentication method to NTLM for all virtual servers. Windows SharePoint Services Service Pack 2 no longer changes the default authentication method to NTLM.

SA Password

During setup, the password for the system administrator (sa) account for WMSDE is set to a random string, which is not stored by Windows SharePoint Services. If you want to use SQL Server authentication or mixed authentication for connecting to the databases in WMSDE and you are going to use the sa account for the connection, you must first change the sa password.

Note

Integrated Windows authentication is recommended, because it is more secure than mixed authentication.

Because the sa password created during setup is not stored, you cannot log in as the sa account to change this password. Instead, you must be authenticated as a member of the system administrator (sysadmin) role for WMSDE. By default, the administrators of the local computer are added to the sysadmin role for WMSDE (which also includes the sa account), and have full administrative access to WMSDE, including the ability to change the sa password.

Warning

Be sure that you do not remove the local administrators from this role or you will not be able to change the sa password. If you remove all users except sa from the sysamin role, without changing the sa password, the WMSDE instance will be unusable.

Choosing an IIS Application Pool Configuration

Internet Information Services (IIS) 6.0 introduced application pools, which enable you to choose whether to run each Web application in a separate application pool (which is served by a worker process), run all applications in the same shared application pool, or a combination of the two. Each application pool runs using unique security credentials, which enables you to specify the security privileges that are granted to all applications running in a particular application pool. Another benefit of application pools, is that if an application fails while running in a separate application pool, the crashed application does not affect other applications that are also running in other pools.

Windows SharePoint Services supports the new application pool model in IIS 6.0. When you configure your server or your server farm, you can choose from the following options:

  • One application pool for the administrative virtual server   The administrative virtual server must always have its own, separate application pool. If a domain account is used with SQL Server, the account must also be configured with Security Administrator and Database Creator roles in SQL Server.

  • Shared application pools for all virtual servers hosting Web sites   You can choose to use the same application pool for all other virtual servers you use in Windows SharePoint Services. If you do so, however, you lose the ability to set security individually for each virtual server. You also lose the failure protection measures that running each application in a separate application pool helps to provide. For example, applications running on one virtual server can potentially read or write data from another virtual server's application, and if one virtual server fails, all virtual servers in the shared application pool will fail.

  • Separate application pools for each virtual server hosting Web sites   With separate application pools for each virtual server, you gain the ability to set security individually for each virtual server and the failure protection measures described earlier. If one virtual server fails, it does not affect the others. And no application running in a separate application pool can read another application's data if the application is on another virtual server. However, separate application pools create more complexity in server administration, since unique domain accounts must be created and maintained for each application pool.

  • Shared application pools for all virtual servers hosting the same Web sites   In a server farm environment, you can also choose to use the same application pool accounts for any virtual servers that are hosting the same Web sites. For example, if your server farm has three IIS servers, each of which has at least one virtual server that hosts the same Web site (for example, https://www.contoso.com/site), you can use the same application pool security account for all of the virtual servers hosting that site. This way, you only need to remember one set of credentials for that group of Web sites, and you can perform tasks across a set of virtual servers in your server farm.

    Note

    If you choose this configuration, you must be sure to use a domain account for the application pool security account. Using a domain account for the application pool security account requires additional steps to ensure that a Service Principal Name (SPN) is added to the account. Information about adding a Service Principal Name (SPN) to a domain user account is available in Using Integrated Windows Authentication with Windows SharePoint Services 2.0 and the Microsoft Knowledge Base article 832769, How to configure a Windows SharePoint Services virtual server to use Kerberos authentication (https://go.microsoft.com/fwlink/?LinkID=76570&clcid=0x409).

About Security for Application Pools Accounts

Application pools in IIS 6.0 can be configured to use predefined security accounts or configurable security accounts.

Each virtual server can be configured to support either Kerberos or NTLM authentication by setting the NTAuthenticationProviders property in the IIS 6.0 metabase. Virtual servers extended with Windows SharePoint Services inherit their authentication methods from IIS. By default, the NTAuthenticationProviders property is not set in the metabase, which means that authentication defaults to Kerberos authentication.

Earlier versions of Windows SharePoint Services (prior to Service Pack 2) set the NTAuthenticationProviders property in the IIS metabase to NTLM when creating the SharePoint Central Administration virtual server or when extending a virtual server with Windows SharePoint Services. This meant that existing sites which relied on Kerberos authentication would no longer work after Windows SharePoint Services was installed.

Windows SharePoint Services Service Pack 2 allows you to select either Kerberos authentication or NTLM authentication when extending a virtual server with Windows SharePoint Services. If NTLM is not selected then no changes are made to the IIS metabase and Kerberos authentication is used. If the IIS 6.0 metabase had previously been modified to NTLM, the NTAuthenticationProviders property in the metabase will need to be changed to Negotiate,NTLM for Kerberos authentication to be used.

You can set the NTAuthenticationProviders property for a virtual server either from the SharePoint Central Administration or the stsadm.exe command-line utility. A new optional parameter <-exclusivelyusentlm> is available for use with stsadm.exe. If this optional parameter is not used, the virtual server is not modified and retains the original authentication configuration.

Note

After a virtual server has been extended from the SharePoint Central Administration page you must use the IIS command line utility, adsutil.vbs, to modify the NTAuthenticationProviders Metabase property in IIS. Instructions for doing this can be found in the Microsoft Knowledge Base article 832769, How to configure a Windows SharePoint Services virtual server to use Kerberos authentication (https://go.microsoft.com/fwlink/?LinkID=76570&clcid=0x409).

Note

Additional information about Command Line Operations can be found in the Reference section of the Windows SharePoint Services Administrators Guide.

If you want to use Kerberos authentication, you must perform additional steps to configure a Service Principal Name (SPN). For more information about viewing and changing the NTAuthenticationProviders property in the IIS 6.0 metabase and configuring a Service Principal Name (SPN), see Using Integrated Windows Authentication with Windows SharePoint Services 2.0 and the Microsoft Knowledge Base article 832769, How to configure a Windows SharePoint Services virtual server to use Kerberos authentication (https://go.microsoft.com/fwlink/?LinkID=76570\&clcid=0x409).

Installing Windows SharePoint Services SP2 On Windows Server 2003 R2

Windows SharePoint Services SP2 is available as part of Windows Server 2003 R2. You do not need to download Windows SharePoint Services if you are running Windows Server 2003 R2. Rather, you can install it by using one of the following methods:

  • Configure Your Server Wizard   Supports the Typical option only.

  • Windows Components Wizard   Supports both the Typical and Server Farm options.

There are other things to install and configure, however, before you install Windows SharePoint Services on Windows Server 2003 R2.

  • You must configure Windows Server 2003 R2 as a Web server by installing IIS.

    Note

    IIS 6.0 installs as part of the default installation of Windows Server 2003 Web Edition.

    Using Manage Your Server or the Configure Your Server Wizard, click Add or Remove a Role, and then click Application Server Role to install IIS 6.0.

  • Install Microsoft ASP.NET 2.0, Microsoft ASP.NET 1.1, or both.

    With Windows SharePoint Services SP 2, you can run either ASP.NET 1.1, ASP.NET 2.0, or both at the same time (side by side). ASP.NET 2.0 and ASP.NET 1.1 are included with 32-bit versions of Windows 2003 Server R2. ASP.NET 2.0 is included and ASP.NET 1.1 is available as a download for x64-based versions of Windows 2003 Server R2. After you download ASP.NET 1.1, you must install ASP.NET 1.1 and configure IIS before it is available to Windows SharePoint Services. For the download location of ASP.NET 1.1, see Installation Points for Windows SharePoint Services 2.0. For information about installing ASP.NET 1.1, ASP.NET 2.0, and configuring IIS, see Installing and Configuring ASP.NET (Windows SharePoint Services 2.0).

After the items listed above are installed and configured, you can install Windows SharePoint Services.

  • Assign SharePoint Services as a role

    To perform a typical installation of Windows SharePoint Services, use Configure Your Server Wizard to assign SharePoint Services as a role for the server. This will install Windows SharePoint Services and WMSDE. You might be prompted for the source files which are located on second CD. If the source files are available on your network, you can also browse to the network location where the setupsts.exe is located.

    You can use the Windows Components Wizard to install Windows SharePoint Services by using either the Typical option or the Server Farm option. To use SQL Server 2000 or SQL Server 2005 as your database, you must use the Server Farm option, when installing Windows SharePoint Services.

    Note

    For other installation options, see the Deployment Scenarios section of the Windows SharePoint Services Administrator's Guide.

Installing Windows SharePoint Services on x64-Based Operating Systems

Windows SharePoint Services SP2 has been certified to run on x64-based versions of Windows Server 2003. Installing Windows SharePoint Services SP2 is similar to installing on 32-bit versions, with the following exceptions:

  • IIS must be configured for 32-bit emulation mode, either at the time of installation or at a later time by using the adsutil.vbs IIS administration utility from the command line.

  • x64-based editions supports both Typical installation as well as server farm installations.

  • Applications requiring ASP.NET 1.1 will require downloading, installing, and configuring IIS.

    For the download location of ASP.NET 1.1, see Installation Points for Windows SharePoint Services 2.0. For information about installing and configuring ASP.NET 1.1 and ASP.NET 2.0, see Installing and Configuring ASP.NET (Windows SharePoint Services 2.0).

Verifying that FrontPage 2002 Server Extensions Are Not Running on Port 80

If you are installing Windows SharePoint Services with the default (Typical) option, verify that FrontPage 2002 Server Extensions from Microsoft are not installed and running on the default virtual server on port 80 before you install. Otherwise, the virtual server will not be extended when you install Windows SharePoint Services.

Note

If you upgraded from Windows 2000 to Windows Server 2003, FrontPage 2002 Server Extensions were installed by default to port 80.

If FrontPage 2002 Server Extensions are using port 80, and you are using the site on that virtual server, you must back up the site to preserve your data, and then unextend the virtual server by using Microsoft SharePoint Administrator before installing Windows SharePoint Services. After installation, you can restore the site to a different virtual server to continue using FrontPage 2002 Server Extensions, or to the same virtual server to upgrade it to Windows SharePoint Services. If you are not using the site, you can simply unextend the virtual server, and then install Windows SharePoint Services. For more information about backing up and restoring Web sites, see Migrating and Upgrading Web Sites (Windows SharePoint Services 2.0).

See Also

Concepts

Preparing Front-End Web Servers for Windows SharePoint Services 2.0
Installing and Configuring ASP.NET (Windows SharePoint Services 2.0)
Single Server Deployment (Windows SharePoint Services 2.0)
Remote SQL Server Deployment (Windows SharePoint Services 2.0)
Server Farm Scalable Hosting Mode Deployment (Windows SharePoint Services 2.0)
Configuring Two Virtual Servers to Host the Same Content (Windows SharePoint Services 2.0)
Separate Active Directory Directory Service Organization Unit Deployment (Windows SharePoint Services 2.0)
Performing a Quiet Installation (Windows SharePoint Services 2.0)