Architecting SharePoint Products and Technologies for Operating System Topologies

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

Published: June 9, 2004

This is a sample chapter from the Microsoft SharePoint Products and Technologies Resource Kit. You can obtain the complete resource kit (ISBN 0-7356-1881-X), which includes a companion CD-ROM, from Microsoft Press.

On This Page

Specific Requirements for Server and Client
Authentication
Administrative Rights
User Account Mode
Controlling Access to Sites
Active Directory–Dependent Features
Summary

Specific Requirements for Server and Client

The latest versions of Microsoft SharePoint Products and Technologies have specific requirements for software and for domain membership. Both Microsoft Office SharePoint Portal Server and Microsoft Windows SharePoint Services must be installed on Microsoft Windows Server 2003, and most, but not all, configurations require that the server running either of these applications be a member of a domain. Of course, all features are available if the domain is a Windows Server 2003 domain, but what if a network environment does not have a Windows Server 2003 domain? In a Microsoft Windows NT domain environment, SharePoint Products and Technologies have much of the same functionality.

Server Requirements

Although all configurations of Windows SharePoint Services must be installed on a Windows Server 2003 server, not all configurations require a domain. Single-server Windows SharePoint Services installations can be installed on servers that are not members of a domain. In all other configurations, all servers—such as those in a server farm—must be members of the same domain.

SharePoint Portal Server requires domain membership for all servers in all configurations. Installing and operating a computer running SharePoint Portal Server is not supported if the server is a member of a workgroup. However, any domain type can work. This means that SharePoint Portal Server is supported on Windows Server 2003 servers that are members of a Microsoft Windows NT 4.0, Windows 2000, or Windows Server 2003 domain.

Client Requirements

Regardless of the type of client that connects to SharePoint Products and Technologies, the features that are available are the same. However, these features can be implemented differently based on the capabilities of the different browsers. Any Windows, Macintosh, or UNIX client can use the available features, provided the client runs the following software:

  • Microsoft Internet Explorer 5.01 with Service Pack 2

  • Internet Explorer 5.5 with Service Pack 2

  • Internet Explorer 6

  • Internet Explorer 5.2 or later for Macintosh

  • Netscape Navigator version 6.2 or later

A client program such as Microsoft Office 2003 is not necessary for browsing but is required if the user contributes to documents on a website. For example, if a Word document exists on a site and a user would like to edit that document, Microsoft Word 2003 is required to edit the document directly from the site.

Authentication

Authentication is the process used to validate the user account that is attempting to gain access to a website or network resource. Authentication for Windows SharePoint Services websites is handled by Internet Information Services (IIS). Windows SharePoint Services uses the authentication method you specify for a virtual server in IIS to control authentication for all top-level websites and subsites of that virtual server. Windows SharePoint Services works with the following authentication methods in IIS:

  • Anonymous authentication

  • Basic authentication

  • Integrated Windows authentication

  • Certificate authentication (using Secure Sockets Layer)

All these methods are available regardless of the type of domain to which the front-end servers belong.

Administrative Rights

Two sets of users are allowed to perform administrative functions for Windows SharePoint Services: members of the administrators group for the local server computer and members of the SharePoint administrators group. The SharePoint administrators group is a domain group that is registered with Windows SharePoint Services. The SharePoint administrative group is not created by default. The user who installs Windows SharePoint Services can create this group during installation, and it can contain a domain group, local user, or domain user.

Members of this domain group can perform Central Administration tasks without having to be given administrator rights to the local server computer. This is particularly useful in a server farm, because you can grant rights across the server farm rather than individually for each computer in the server farm. This is also useful for applications that call the administrative object model for Windows SharePoint Services. If the application process can be configured to run as a member of the SharePoint administrators group, it can create new sites, modify quota values for sites, and so on.

There are some operations that members of the local administrator’s group can perform that members of the SharePoint administrator’s group cannot perform. These tasks include:

  • Configuring the SharePoint Central Administration virtual server

  • Enabling full-text search

  • Extending virtual servers in Windows SharePoint Services

  • Managing content databases (i.e., changing properties, etc.)

  • Managing paths (inclusions/exclusions)

  • Running the stsadm.exe command-line utility

  • Setting the configuration database properties

  • Setting the default content database server

  • Setting the SharePoint Administration Group

  • Removing Windows SharePoint Services from a virtual server

User Account Mode

When you install Windows SharePoint Services, you must choose which mode you want to use to allow users access to Windows SharePoint Services sites. Windows SharePoint Services can work with two modes: domain account mode and Active Directory account creation mode. Domain account mode is used inside organizations to grant access to users that have existing Windows domain accounts. Active Directory account creation mode can be used by Internet service providers to create unique accounts for customers using the Active Directory directory service.

In domain account mode, you use existing domain user accounts. If you choose Active Directory account creation mode, you are choosing to have accounts 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 by 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 one of the first choices made during installation when using Microsoft SQL Server. If Windows Microsoft SQL Server 2000 Desktop Engine (WMSDE) is used, the account creation mode is set to domain account mode and cannot be changed.

In a Windows 2000 or Windows Server 2003 domain, Windows SharePoint Services can use Active Directory account creation mode. In a Windows NT domain, the domain account mode is needed.

Controlling Access to Sites

Windows SharePoint Services provides the ability to control site access through the use of site groups. Site groups let you specify which of your users can perform specific actions in your site. For example, a user who is a member of the Contributor site group can add content to Windows SharePoint Services lists, such as the Task list, or a document library.

Because SharePoint Portal Server is designed to work in an Active Directory environment, some functionality for administrative tasks is unavailable. When adding a user to the portal site by clicking Add Users on the Manage Users page, the Select Users And Groups – Web Page Dialog dialog box should appear. However, this feature does not work with Windows NT domains. This dialog box searches for and adds users to the site. As a work-around try the following steps:

  1. On the Site Settings page, in the General Settings section, click Manage users.

  2. On the Manage Users page, click Add Users.

  3. In the Step 1: Choose Users section, type the name of the user or users to add in the Users box.

    (Enter names in the format DomainName\UserName. For more than one user, separate each user name with a semicolon character [;].)

  4. In the Step 2: Choose Permissions section, select the check boxes next to the site groups to which the users are to be added, and then click Next.

  5. In the Step 3: Confirm Users section, verify the e-mail address, user name, and display name information of the user or users.

  6. In the Step 4: Send E-mail section, select the Send the following e-mail to let these users know they’ve been added check box to notify users. Type a message to include, if needed.

  7. Click Finish.

Active Directory–Dependent Features

Some features available in SharePoint Portal Server are dependent on Active Directory. Although most features can still be used in a Windows NT environment, they will need to be configured manually. The features that work with Active Directory include user profiles and audience compilation.

The user profiles feature in SharePoint Portal Server populates a database of user profiles by importing the profiles from Active Directory. Without an Active Directory environment, the accounts must be typed into the user profiles database. This can be done in the Manage User Profile page in the Central Administration site. Also, when an audience is compiled in an Active Directory environment, rules are used as filters against the profile database to create a subset of users. Because not all profile information is imported into the SharePoint Portal Server profile database, Active Directory is checked during an audience compilation if any additional information is needed. Without Active Directory the information is limited to what is manually entered into the user profiles database.

Active Directory Application Mode

The new Active Directory Application Mode (ADAM) lets you run Active Directory as an application in your Windows Server 2003 domains. An application can use Active Directory Application Mode to store “private” directory data (data that is relevant only to the application) in a local directory service, perhaps on the same server as the application, without requiring any additional configuration to the network operating system (NOS) directory. ADAM can support directory-enabled applications running in Microsoft Windows NT 4.0 domains. Because ADAM works with the Windows-integrated security infrastructure, it can also authenticate users from Windows NT 4.0 domains.

Currently SharePoint Products and Technologies does not integrate with Active Directory Application Mode. This is because ADAM does not provide actual logon tokens, but instead provides only LDAP names. SharePoint Portal Products and Technologies requires logon tokens for authentication.

Summary

Upgrading your domains and forests to Windows Server 2003 domains and forests with Active Directory is the optimal way of getting the maximum functionality out of Windows Server 2003. However, not all network environments have a Windows Server 2003 domain. SharePoint Products and Technologies can be installed into a Windows NT domain with the loss of only some features. Many features still work, but require a manual configuration to function with Active Directory.