Installation Considerations for Windows SharePoint Services

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

There are certain choices that you must make either before or during your installation of Microsoft. 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 . If you are installing 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 .

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 .

Choosing a User Account Mode

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

  • Domain account mode

    This mode is used inside organizations to grant access to users with existing Microsoft Windows domain accounts.

  • Active Directory account creation mode

    This mode is used by Internet Service Providers to create unique accounts for customers in Active Directory directory service.

You cannot mix modesyou must choose either Domain account mode or Active Directory account creation mode. The difference between these two modes is the method you use to create user accounts. In Domain account mode, you use existing domain user accounts. In Active Directory account creation mode, accounts are automatically created in the Active Directory organizational unit you specify. In either mode, 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.

The choice between user account modes is a one-time-only choice, because it affects how the configuration database for your server or server farm is created. You cannot change user account modes after creating the configuration database, and this step is either part of installation (if installing with Microsoft SQL Server 2000 Desktop Engine (Windows) (WMSDE 20)), or one of the first choices you make after installation (if using SQL Server computer).

For more information about user account modes, see Managing Users and Cross-Site Groups .


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

  • 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 2003 Server online help.

Choosing a Database Type

relies on a database to store all site data and content, plus server configuration information. can work with either of the following databases:

  • Microsoft SQL Server 2000 Service Pack 3

    SQL Server includes many tools for managing database processes, such as backup and restore, and allows you to use multiple back-end database servers to store as much content as you need and balance the load across the servers.

  • Microsoft SQL Server 2000 Desktop Engine (Windows) (WMSDE), Service Pack 3

    WMSDE 2000 has only a small subset of the features available with SQL Server. For example, WMSDE does not include tools for backing up and restoring the database, and only allows you to use a limited amount of storage space.

    Note: , Web Edition, requires the full version of Microsoft SQL Server rather than WMSDE.

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

Note: Using WMSDE may be more secure than using SQL Server, because WMSDE cannot be connected to remotely.

If you install 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 database.

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

Choosing an Authentication Type for SQL Server

If you choose to use SQL Server with , you must also choose the authentication method to use for connections between and the SQL Server 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 an Internet Information Services (IIS)application pool to connect to the SQL Server database. The username and password are not sent between servers, but are abstracted through the IIS application pool.

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

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 Security Model . For more information about authentication methods for SQL Server 2000, see the SQL Server 2000 documentation.

About WMSDE and Authentication Types

When you install with the default settings, WMSDE is also installed to provide database support. By default, the authentication for connections between and WMSDE is set to Windows authentication.

During setup, the password for the system administrator (sa) account for WMSDE is set to a random string. This password is not stored by . 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.

Because the sa password created during setup is not stored, you cannot log in as the sa account to change this password 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.

Caution: 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) introduced application pools in IIS 6. With application pools, you can use an isolated process to run your Web applications. Each application pool has unique credentials on the server, so you can identify which applications are performing which actions. If that application fails, it does not affect other applications that are also running.

supports the new application pool model in IIS 6. 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.

  • 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 . If you do so, however, you lose the security and failure protection measures that multiple application pools help provide. Applications running on one virtual server can potentially read or write data from another virtual server's application, and if one virtual server fails, they all fail.

  • Separate application pools for each virtual server hosting Web sites

    With separate application pools for each virtual server, you gain the security and failure protection measures that application pools help provide. If one virtual server fails, it does not affect the others. And no application running in a unique application pool can read another application's data if the application is on another virtual server. However, separate application pools create more complexity in management, since unique domain accounts must be created and maintained for each application pool.

  • "Shared" application pools for all virtual servers hosting the same Web sitesIn 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 servers, each of which has at least one virtual server that hosts the same Web site (, you can use the same application pool 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 account.

You specify the application pool to use for your administrative virtual server when you install to a server and set the configuration database. You specify any other application pools to use when you extend a virtual server on that server. For more information about application pools, see the IIS 6.0 Help system.

In situations where there is an extremely heavy load and large numbers of simultaneous users, you should consider the following special configuration steps for the content virtual servers.

  • Use a specially-configured domain account for the application pool account.

    When the account is created, ensure that the domain account is configured with the host name for the virtual server (for example, or http://virtualserver) and that the host name is registered as a Service Principal Name (SPN) for the account on the Kerberos domain. If there are multiple host names represented by this virtual server, each host name must be registered as a Service Principal Name with this account. For more information about registering Service Principal Names for specific accounts in a Kerberos domain, see the topic Delegating authentication in the Windows Server 2003 Help system.

  • Change the IIS authentication method to be Negotiate/NTLM Authentication.

    By default, Windows SharePoint Services configures virtual servers with Integrated Windows authentication. Note that you must be using Active Directory to use Negotiate/NTLM.

You can use a script to change to Negotiate/NTLM authentication.

Change to Negotiate/NTLM authentication

  1. Open a command prompt windows and change to the \inetpub\adminscripts directory.

  2. Run the following command:

    cscript adsutil.vbs get w3svc/##/NTAuthenticationProviders

    Where ## is the virtual server ID number (1 for the default virtual server) to verify the current authentication setting. The following string should be returned:

    ntauthenticationproviders: (STRING) "NTLM"
  3. Run the following command to change to Negotiate/NTLM:

    cscript adsutil.vbs set w3svc/##/NTAuthenticationProviders "Negotiate,NTLM"

    Where ## is the virtual server ID number (1 for the default virtual server).

Verifying that FrontPage 2002 Server Extensions are not Running on Port 80

If you are installing with the default options (you are not using remotesql=yes ), verify that FrontPage 2002 Server Extensions from Microsoft are not installed and running on the virtual server on port 80 before you install. (If you upgraded from Windows 2000 to , 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 . 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 . If you are not using the site, you can simply unextend the virtual server, and then install . For more information about backing up and restoring Web sites, see Migrating and Upgrading Web Sites .

Related Topics

For more information about installing , see the following topics: