Microsoft Consulting Services, West Region

Creating Shared Hosting Solutions on Windows SharePoint Services 3.0

Prepared by

星期二, 20 二月 2007

Version .1.0

Prepared by

Mannan Mohammed, Sr. Architect

Saivendra Kayal, Principal Consultant

David Gorgone, Sr. Consultant II

Lisa Takahashi, Consultant II

Contributors

Hyder Ali

Bob Sutton This file does not collect any personal information.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, email address, logo, person, place or event is intended or should be inferred.

Microsoft, Outlook, SharePoint, Windows, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners. Table of Contents

1 Introduction...... 1

2 Deployment Architectures...... 5

2.1 Stand-alone server architecture...... 5

2.2 Silo architecture...... 6

2.3 Hosting farm with shared SQL back-end servers...... 8

2.4 Scalable hosting farm...... 9

2.5 Improvements in Windows SharePoint Services 3.0 scalable hosting mode over Windows SharePoint Services 2.0...... 10

3 Authentication Modes...... 13

3.1 Active Directory...... 13

3.1.1 Account creation mode...... 13

3.1.2 Domain account mode...... 13

3.2 Non-Active Directory or custom mode...... 14

4 Forms-Based Authentication...... 15

4.2 SQL authentication...... 18

4.2.1 Configure SharePoint for SQL forms authentication...... 20

5 Multiple Tenancy...... 23

5.2 Non-Active Directory or custom mode...... 27

6 Site Provisioning...... 29 6.1 Provisioning host-named site collections...... 31

6.2 Additional steps to provision host-named site collections in SQL authentication mode...... 32

7 User Management...... 36

7.1 User Provisioning...... 36

7.1.3 Non-Active Directory custom authentication mode...... 44

7.2 Resetting passwords...... 44

8 HTTPS...... 46

8.1 Configuring HTTPS for host-named site collections...... 46

8.2 Issues...... 47

9 Search...... 48

9.1 Configuring Search with Basic Authentication:...... 48

9.2 Configuring Search for HTTPS sites...... 50

9.3 Configuring Search for Forms Based Authentication with Custom Authentication Provider:...52

10 Configuring HTTPS for Host-Named Site Collections...... 53

10.1 Issues...... 53

11 Migration from 2.0 to 3.0...... 54

11.1 In-place upgrade...... 54

11.2 Gradual upgrade...... 54

12 The “Fabulous 40” Application Templates...... 56

12.1 Site administrator templates...... 57

12.2 Server administrator templates...... 58

12.3 Grouping of templates...... 59

12.4 Converting templates from Windows SharePoint Services 2.0 to Windows SharePoint Services 3.0...... 60

13 Other Deployment Issues in Hosting Scenarios...... 61 13.1 Active site count...... 61

13.2 IIS reset...... 61

13.3 Bandwidth measurement tools...... 61

13.4 People picker...... 62

PeoplePicker Options:...... 62

13.4.1 peoplepicker-activedirectorysearchtimeout...... 63

13.4.2 peoplepicker-distributionlistsearchdomains...... 63

13.4.3 peoplepicker-onlysearchwithinsitecollection...... 64

13.4.4 peoplepicker-searchadcustomquery...... 64

13.4.5 peoplepicker-searchadforests...... 65

14 Development Guide...... 66

14.1 Developing custom SharePoint Web services...... 66

14.1.1 Why would you need to develop this?...... 66

14.1.2 How do you develop?...... 66

14.1.3 How do you debug?...... 71

14.2 Developing SharePoint Web Parts...... 73

14.2.3 How do you debug?...... 77

14.3 Developing SharePoint Web applications...... 79

14.3.3 How do you debug?...... 83

14.4 Developing custom HTTP modules...... 84

14.4.3 How do you debug?...... 88 15 Appendix (from popular blogs)...... 89

15.1 EnableListObjectMode.vbs...... 89

15.2 Setting up account creation mode – Screen shots...... 91

15.3 What happened to Smigrate.exe? What if I only want to upgrade one site? What can I do now with Stsadm.exe?...... 94

15.4 Capacity planning...... 97

15.5 Important references...... 98

15.6 Feature comparisons in SharePoint Search versions...... 99 1 Introduction

Microsoft® Windows® SharePoint® Services 3.0 builds on the Microsoft Windows Server 2003 operating system and database services to support requirements for creating Web sites that can serve as team sites for workgroups or as large enterprise portal solutions. Windows SharePoint Services 3.0 platform services provide security-enhanced, scalable, reliable, and high- performance capabilities that are outlined in the following figure.

Figure 1: Components of Windows SharePoint Services 3.0

In addition, Windows SharePoint Services 3.0, a feature of Windows Server 2003, implements the collaboration features of the 2007 release of Microsoft Office SharePoint Products and Technologies:

 Document collaboration

 Wikis and blogs

 Really Simple Syndication (RSS) support

 Discussions

 Project task management

 Contacts, calendars, and tasks

 E-mail integration

 Integration with the 2007 Microsoft Office system client applications

 Offline support for SharePoint lists and document libraries, using Microsoft Office Outlook 2007 as the offline client application.

1 In addition, Windows SharePoint Services 3.0 provides key capabilities and features that make it a very attractive solution to become a platform to offer shared hosting services that are geared towards small and medium businesses. These capabilities include:

 Custom authentication. Windows SharePoint Services 3.0 uses the provider model to integrate with any authentication store. Windows SharePoint Services 3.0 integrates with the SQL membership provider that ships with ASP.NET 2.0. This provider, distributed as source code in MSDN, can be extended to integrate with other authentication stores such as Lightweight Directory Access Protocol (LDAP), Microsoft .NET Passport, or proprietary single sign-on (SSO) solutions.

 Forms-based authentication. In conjunction with the custom authentication providers, Windows SharePoint Services 3.0 redirects users to a logon form, where in the user gets prompted for credentials. With the use of the ADProvider that ships with ASP.NET 2.0, this new mode of authentication can even replace the dialog box that was used with Basic authentication (over HTTPS).

 Host-named site collections. This feature allows for a DNS entry to be mapped to a site collection within a Web application. There can be thousands of site collections inside a single Web application. This is the most scalable configuration of Windows SharePoint Services 3.0 and is tailored for hosting needs.

 Tight integration with Office (even in non-Active Directory modes). Windows SharePoint Services 3.0 now has a tighter integration with the 2007 Microsoft Office system, even with non-Active Directory modes. For this integration to work, users need to select the Persist session information check box, and then Office will work with credentials provided by using forms-based authentication.

 New built-in application templates. Application templates are custom scenarios for the Windows SharePoint Services 3.0 platform, tailored to address the needs and requirements of specific business processes or sets of tasks in organizations of any size. In Windows SharePoint Services 3.0, in addition to the sites such as team sites, meeting workspaces, document workspaces, etc., that are geared towards office collaboration, a new set of application templates for blogs, wikis, photo albums, etc., is provided.

2 These templates are geared towards small and medium businesses and hosting scenarios.

 “Fabulous 40” templates. By end of Q1-FY07, Microsoft will release a set of 40 new application templates for Windows SharePoint Services 3.0. These templates will offer solutions for scenarios such as Help Desk, Project Site, Knowledge Base, Employee/HR, etc., to address specific customer needs and business requirements. Twenty of the templates will be “site administrator templates” and available in English only. These templates will be easy for site administrators to install in a template gallery without requiring server administration access. The remaining 20 will be “server administrator templates” and available in 11 languages (English, French, Italian, German, Spanish, Portuguese, Japanese, Chinese Simplified, Chinese Traditional, Korean, and Hebrew). The site definitions provide a tighter integration and enhanced functionality within Windows SharePoint Services 3.0, but will require a server administrator to install.

For the hosting market, Windows SharePoint Services 3.0 offers a clear differentiator for the Windows platform. Offering “intranet” solutions that allow small and medium business customers to not only share documents, but also to collaborate by using wikis and blogs, will be key to growing market share and creating value-added services.

Microsoft engaged with more than a dozen international hosting partners after the Beta 2 Technical Refresh release of Windows SharePoint Services 3.0 and helped create shared offers on Windows SharePoint Services 3.0. This white paper captures the key areas of learning from this pilot program, and is geared towards facilitating an independent software vendor (ISV) or hoster to create an offer on Windows SharePoint Services 3.0 in a short amount of time.

In the following sections, we will outline the different deployment options available for Windows SharePoint Services 3.0 and present some the issues that were faced by hosters in the pilot program. Most of the issues encountered could be avoided by preemptive guidance, which is provided in this white paper. Some issues will require a workaround, which was developed by Microsoft Consulting Services and provided to the hosters. Excerpts of the workarounds will be

3 presented in this paper, whereas the full solutions for the workarounds will be made available as part of a download . In spite of our best efforts, there are some issues that do not have any solutions in place and will require the product team to address them in the next major release of Windows SharePoint Services (service pack or full release). We will present these issues so that hosters can avoid them if at all possible.

4 2 Deployment Architectures

Windows SharePoint Services 3.0 can be installed on a wide range of configurations that varies from a single server configuration to a large farm of servers. In each of the configurations, the workloads can be distributed across the hardware. In this white paper, we will focus on the three primary components of Windows SharePoint Services 3.0, namely Windows SharePoint Services application (Web application), Search (including crawling and indexing), and Storage (for data, as well as configuration information). We will present only the most popular configurations for hosting scenarios.

Irrespective of the hardware architecture, Windows SharePoint Services 3.0 can be installed and configured independently. We will therefore present only the hardware architectures, and then discuss the software configurations in the subsequent sections.

2.1 Stand-alone server architecture

In this configuration, the hoster installs all components of Windows SharePoint Services on a single server. The server might optionally be part of a domain. All features of Windows SharePoint Services 3.0 are available in this scenario. However, there is no scalability or availability built into the configuration. Windows SharePoint Services 3.0 ships with its own Microsoft SQL Server 2000 Desktop Engine (Windows) (WMSDE) database, which can get installed on the server. The normal limits of WMSDE are removed, and Windows SharePoint Services 3.0 can support as many users as the hardware constraints can support (up to hundreds of customers). However, note that only Windows SharePoint Services 3.0 can interface with WMSDE. Other tools such as SQL Development Explorer, etc., cannot be used for managing WMSDE.

Just as with Microsoft Windows SharePoint Services 2.0 and Microsoft Office SharePoint Portal Server 2003, the free database used in a default installation is not the same for both a Windows SharePoint Services 3.0 default installation and a Microsoft Office SharePoint Server 2007 default installation. The version used for Office SharePoint Server 2007 is the standard version of Microsoft SQL Server 2005 Express Edition and has the standard restriction of a maximum

5 4 gigabyte (GB) size for a database. However, the version used by Windows SharePoint Services 3.0 is (again, just as Windows SharePoint Services 2.0) a special "Windows" version, which does not have this maximum database size restriction.

The Windows SharePoint Services 3.0 version compared to the Windows SharePoint Services 2.0 WMSDE does support Search, because the search used in Windows SharePoint Services 3.0 is a cut-down version (single site only) of the search used by Office SharePoint Server 2007 and no longer SQL Server Full-Text Search.

Note that management tools such as SQL Server Management Studio Express are blocked from attaching to this database engine. Users can use only the osql command-line utility.

From a hoster standpoint, the most attractive feature of this option is the lack of licensing costs for the database. However, in the long run, as the numbers of customers go from hundreds to thousands, a single-server architecture will have a higher total cost of ownership (TCO) in terms of managing individual servers. Therefore, hosters will mostly use this configuration during the prototyping or start-up stage to minimize costs, and then typically consider one of the other configurations before going into full production or supporting a large customer base.

2.2 Silo architecture

The most popular configuration in shared hosting (for ASP.NET applications) is to have a front-end Web server being served by a SQL back-end server. In some instances, multiple front-end Web servers can be served by a single SQL back- end server. Hosters typically serve about 2,000 customers (or whatever the server threshold might be) with a single pair of front-end Web server/SQL back- end server. As the number of customers approaches the server threshold, the hosters will bring up an additional pair to handle the new customers. Basically, the capacity grows as each pair is added. The hosters use a combination of host headers, multiple IP addresses, and creative DNS mappings to distribute loads.

Windows SharePoint Services 3.0 supports this exact configuration. The hoster can install the Web application along with search components on the front-end

6 Web servers and configure a SQL Server computer to store the SharePoint configuration, as well as content databases. As additional capacity is needed, the hosters can add a new pair or optionally add just a new front-end Web server to the existing SQL back-end server, or create a farm of front-end Web servers. This option provides the hosters with the ability to scale up or scale out as needed, as well as provides the ability to manage SQL Server computers by using traditional tools and techniques. Each pair is configured to be a “silo” and can be managed independently. This architecture is illustrated in the following figure.

Figure 2: Example of silo architecture

In this configuration, you will need both the front-end Web server and the SQL back-end servers to be part of an Active Directory directory service domain. Domain users are also required to configure the SharePoint servers, as well as SQL services. Note that while Active Directory is required for the servers, Windows SharePoint Services 3.0 can still use any form of authentication for its users (the most popular are still Active Directory or SQL-based custom authentication that ships as part of ASP.NET 2.0). If the SQL-based custom authentication is used, the hosters might opt to configure a stand-alone SQL Server computer that serves as a user repository for all authentication needs.

If multiple front-end Web servers are served by a single SQL back-end server, each front-end Web server is configured as a stand-alone Windows SharePoint Services server. On the SQL Server computer, there will be multiple configuration databases, one for each Web application that is configured on the front-end Web server.

7 While Windows SharePoint Services 3.0 can support thousands of users and customers on a single front-end Web server/SQL back-end server pair, this is not the most optimal configuration for Windows SharePoint Services 3.0. However, as the hosters are most familiar with this architecture for their shared hosting environments, it is becoming a very popular choice. However, there are some drawbacks to this approach which are described in the following paragraphs.

One of the most popular usage scenarios for Windows SharePoint Services 3.0 is to use it as a document repository on the Web, to facilitate collaboration. Because all documents (and any other content) are stored in a SQL database, the size of the SQL database will grow very rapidly. In this architecture, it will be difficult to add new capacity to the SQL back-end servers because the hosters will run into physical limitations of the hardware (stand-alone servers). In addition, as multiple silos are added, over a period of time, the customers might end up on multiple servers, in which case the user and customer management will become difficult. Therefore, this configuration might be used as long as the customer base is small (in thousands). However, as the customer base grows large (in tens of thousands), the hosters should consider a hosting farm that has a shared SQL back-end server or a scalable hosting farm that has both shared SQL back-end servers and front-end Web servers.

2.3 Hosting farm with shared SQL back-end servers

This architecture is a simple extension of the silo architecture described the previous paragraphs, wherein multiple front-end Web servers are configured to use a single SQL cluster that has a storage area network (SAN) device (or some other form of extensible, shared storage). The SQL cluster can be active-active or active-passive. In this architecture, each front-end Web server is configured with its instance of Windows SharePoint Services 3.0 (i.e., each front-end Web server will have its own configuration database in the SQL Server computer). Much like in the silo architecture, the front-end Web servers are added incrementally, on demand, as soon as the number of customers reaches a predetermined threshold. This architecture is illustrated in the following figure.

8 Figure 3: Example of hosting farm architecture

As the SQL Server computer is shared, it needs to be a high-end computer, such as quad-processor server with 4 GB or more of RAM. Hosters will get enhanced performance if they invest in 64-bit servers for the SQL cluster. (The capacity planning numbers might be released shortly by Microsoft.)

The advantage of this approach is that the disk storage can be optimized. The shared SQL SAN can support multi-terabytes of data and shared capacity can be added on an as-needed basis.

Note that the Search Service is configured individually on each of the Windows SharePoint Services servers.

2.4 Scalable hosting farm

Scalable hosting farm architecture refers to a set of “load balanced” front-end Web servers going against a SQL cluster. This configuration is the most scalable configuration. However, it is a bit more complex to set up. Instructions to set up the load balanced farms are provided as part of SharePoint documentation.

In this configuration, there is a single instance of a Windows SharePoint Services 3.0 Web application that is serving tens of thousands of customers. Hosters can still create multiple Web applications if they choose to do so. These Web applications can share the same configuration databases (and be configured as an additional zone for an existing application), or a completely new instance of the configuration database can be created.

Note that Search can be configured on a single server (or multiple servers) to serve the entire farm.

9 As each component of Windows SharePoint Services 3.0 is shared in this architecture, this configuration provides the most efficient use of resources and can support tens of thousands of customers. This is also the most popular configuration for large enterprise customers that have more than 100,000 employees. However, in the hosting space, this architecture is still being evaluated.

2.5 Improvements in Windows SharePoint Services 3.0 scalable hosting mode over Windows SharePoint Services 2.0

(Excerpts from http://wss.collutions.com/pages/Windows SharePoint Services %20v3%20FAQ.aspx)

Scalable hosting mode had some limitations in Windows SharePoint Services 2.0. The first limitation was that you had to specify whether or not you wanted to use scalable hosting mode when creating the SharePoint configuration database by using the -hh parameter. Once selected, this setting could never be changed.

The second limitation was that scalable hosting mode limited you to extending only one Internet Information Services (IIS) Web site with SharePoint. We did not support extending any additional IIS Web sites with SharePoint when this mode was enabled.

The third limitation was that only Windows SharePoint Services 2.0 supported scalable hosting mode. SharePoint Portal Server 2003 did not support this mode.

In Windows SharePoint Services 3.0, there are several improvements. First, this feature is no longer exposed through a "mode." In other words, you no longer need to specify whether you want to use host-named site collections when creating the configuration database. Instead, you can now just specify whether site collections should be host-named or path-based when creating the site collection itself.

Second, you can now have host-named site collections on multiple Web applications, so you are no longer limited to extending just one IIS Web site with SharePoint. In fact, you can have a mix of path-based and host-named site collections on the same Web application.

10 Finally, we have expanded host-named site collection support to include other Office Server applications, including portal sites.

As with Windows SharePoint Services 2.0, you must use the stsadm.exe createsite command to create host-named site collections.

You add the following parameter to that operation to indicate that it should be host-named instead of path-based:

-hhurl

Where is one of the URLs assigned to the "target" Web application in alternate access mappings (Start -> Control Panel -> Administrative Tools -> SharePoint 3.0 Central Administration -> Operations -> Alternate access mappings).

For example, let us say you have a Web application named www.example.com and you want to add a host-named site collection with the URL http://hoster.example.com. The command would look like this:

stsadm.exe -o createsite -url http://hoster.example.com -ownerlogin DOMAIN\username -owneremail [email protected] -hhurl http://www.example.com

Regular Internet service providers (ISPs) would configure their DNS servers to associate hoster.example.com with the appropriate IP address. For your own testing, you can just edit your %WINDOWS%\system32\drivers\etc\hosts file to associate host-named site collections with the IP address of your SharePoint server. Once this is done, you can browse to http://hoster.example.com to access your site.

Host-named site collections can be used with both HTTP and Secure Sockets Layer (SSL) if you create them on the default port. If you create them on a non- default port, each individual host-named site collection can be only HTTP or only SSL, depending on which URL you entered with the -url parameter in the createsite command.

11 Also, host-named site collections cannot be used with the advanced extranet scenarios provided by alternate access mappings, such as SSL termination.

12 3 Authentication Modes

The new authentication model in Windows SharePoint Services 3.0 leverages the ASP.NET 2.0 authentication framework. The new model is a pluggable framework that provides easy integration for a number of providers into SharePoint.

3.1 Active Directory

By default, Active Directory is the standard user store for Windows SharePoint Services 3.0. Using Active Directory, there are two modes that are available for adding users: account creation mode and domain account mode.

3.1.1 Account creation mode

Active Directory account creation mode is popular with hosters because of its ability to create unique accounts for customers. By configuring SharePoint in this mode, Windows SharePoint Services 3.0 will automatically create Active Directory accounts for new users. You must enable Active Directory account creation mode when you first configure Windows SharePoint Services 3.0. When you use Active Directory account creation mode, you cannot use existing domain accounts. Instead, new accounts are created whenever you add users. The new users are notified of their accounts and password through e-mail.

This mode requires that an Active Directory organizational unit (OU) be created, and all users that are created in this mode will end up in a single OU. There are security issues because of this and it is one of the reasons that this mode is being deprecated in Windows SharePoint Services 3.0 and will no longer exist in future versions.

3.1.2 Domain account mode

Domain account mode is used mainly within organizations that use Microsoft Windows domain accounts. This mode is recommended for hosters that have Active Directory skills, as well as the infrastructure in place. Unlike account creation mode, there is no user provisioning system. However, because Windows SharePoint Services 3.0 now leverages the ASP.NET 2.0 authentication

13 framework, you can easily create a custom user provisioning system and integrate forms-based authentication into Windows SharePoint Services 3.0.

3.2 Non-Active Directory or custom mode

Because Windows SharePoint Services 3.0 provides a pluggable framework that leverages ASP.NET 2.0 authentication, any user data store can be implemented. Currently, providers that are included are SQL, LDAP, and Active Directory. This new capability has become popular with hosters who want to create low-cost offers. It also provides the capability to easily integrate forms authentication, a feature that hosters have been asking for in Windows SharePoint Services 2.0. Like domain account mode, a custom user provisioning system will need to be created.

14 4 Forms-Based Authentication

The new authentication model in Windows SharePoint Services 3.0 leverages the ASP.NET 2.0 authentication framework. The new model is a pluggable framework provides easy integration for a number of providers. The current providers are SQL, LDAP, and Active Directory. Any of these providers can be configured when forms authentication is specified in SharePoint.

ASP.NET membership supports facilities for:

 Creating new users and passwords.

 Storing membership information (user names, passwords, and supporting data) in Microsoft SQL Server, Active Directory, or an alternative data store.

 Authenticating users who visit your site. You can authenticate users programmatically, or you can use the ASP.NET logon controls to create a complete authentication system that requires little or no code.

 Managing passwords, which includes creating, changing, and resetting them. Depending on membership options you choose, the membership system can also provide an automated password-reset system that takes a user-supplied question and response.

 Specifying a custom membership provider, which allows you to substitute your own code to manage membership and maintain membership data in a custom data store.

ASP.NET role supports facilities for:  Creating roles and assigning users to those roles.  Managing users that belong to those roles. For instance, in SharePoint, you can grant access to a role and add or remove users from the role. This eliminates the need to grant access to individual members.  Authorizing access to specific areas of the application by defining which role will have access. The following sections describe the configurations that are included for the Active Directory and SQL membership providers. Subsequent sections of this document

15 will describe the customizations that were developed for a hosting solution. The customizations provide the scoping of users to their respective sites.

In Windows SharePoint Services 3.0, forms-based authentication will not work with account creation mode. This is because forms-based authentication expects users to be in the format of “Provider:user”, while the account creation mode adds users as “Domain\user”. For forms-based authentication to work, the user in the format of “Provider:user” should be added to the site collection. Because there is no clean way of performing this action, we recommend forms-based authentication not be used with account creation mode. Also note that account creation mode is a deprecated feature of Windows SharePoint Services 3.0. It is supported through version 3.0. However, the product teams recommend customers plan to move off of it at their earliest convenience.

This section discusses enabling the Active Directory membership provider within Windows SharePoint Services 3.0.

There are three configuration files that need to be modified. These configuration files belong to the SharePoint Central Administration Web site, the SharePoint Web application, and the stsadm.exe command-line utility.

1. Open the Web.config files for both the Web application and the Central Administration application, and add the following ConnectionStrings element immediately after the ConfigSections element:

Note: In the above the example, the connection string is pointing to the Users OU.

2. Add the following in the system.web section:

Note: You will need to specify the appropriate connectionUsername and connectionPassword that has full access to the Users OU as described in the connection string above.

4.1.2.1 Configure SharePoint for Active Directory forms authentication

Once the Web.config files have been modified, follow the following steps.

1. Open Central Administration, and click Application Management.

2. Click Authentication Providers. Ensure that you are working on the correct Web application.

3. Click the Windows link. By default, SharePoint enables Windows as the membership provider name.

4. On the Edit Authentication page, in the Authentication Types section, select the Forms option.

5. In the Membership provider name text box, enter the name of your Web application’s membership provider. Based on the membership section above, the name would be MyADMembershipProvider.

6. In the Role Manager Name text box, enter the name of your Web application’s role provider.

7. Click the Save button.

17 Note: The stsadm.exe tool also needs to be configured for forms authentication. To do so, create an stsadm.exe.config file such as shown in the following code sample and deploy it to the stsadm.exe folder located in C:\Program Files\Common Files\Microsoft Shared\Web server extensions\12\BIN.

4.2 SQL authentication

To begin working with the SQL membership provider, you will need to create the SQL database.

1. Create the aspnetdb database. From a Visual Studio 2005 command prompt, run the following command: aspnet_regsql –A all –E Where -A all specifies to add all provider features, and -E specifies Windows authentication to connect to SQL Server.

2. Add users to the SQL database.

18 There are a variety of ways to do this. ASP.NET provides an ASP.NET Web site administration tool to set up and manage users. You can also write your own application to manage users by using the membership and role application programming interfaces (APIs).

3. Configure the SQLMembershipProvider for a given Web application.

4. Once the SQL database has been implemented, modify the Web.config files for both the Web application and Central Administration. The ConnectionString element should point to your SQL database. It should be placed in the Configuration section of the Web.config, as shown in the following code sample.

The Membership and Rolemanager elements should be placed in the system.web section of the Web.config file. Important attributes to note are the name and connectionStringNames. The name attribute values contain the default SQL membership provider and role provider names. The connection string values need to be consistent with what is specified in the connectionString section. In this case, it is localSqlMembershipDatabase. The applicationName attribute contains the name of the application and is used to identify users that are specific to that application, as shown in the following code sample.

19 description="Stores and retrieves membership data from the Microsoft SQL Server database" type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

If you plan to provide a custom logon page, make sure that the appropriate section has been modified. Otherwise, SharePoint’s default logon will be used, as shown in the following code sample.

4.2.1 Configure SharePoint for SQL forms authentication

Once the Web.config files have been modified, follow the following steps.

1. Open Central Administration, and click Application Management.

2. Click Authentication Providers. Ensure that you are working on the correct Web application.

3. Click the Windows link. By default, SharePoint enables Windows as the membership provider name.

4. On the Edit Authentication page, in the Authentication Types section, select the Forms option.

20 5. In the Membership provider name text box, enter the name of your Web application’s membership provider. Based on the membership section above, the name would be AspNetSqlMembershipProvider.

6. In the Role Manager Name text box, enter the name of your Web application’s role provider.

7. Click the Save button.

Note: The stsadm.exe tool also needs to be configured for forms authentication. To do so, create an stsadm.exe.config file such as shown in the following code sample and deploy it to the stsadm.exe folder located in C:\Program Files\Common Files\Microsoft Shared\Web server extensions\12\BIN.

22 5 Multiple Tenancy

The ability to host multiple public Web sites, each with its own domain name, on a single installation of Windows SharePoint Services 3.0 will allow hosters to maximize customers on a given implementation. There are various challenges that exist today when trying to host multiple domains on a single Web server. As shipped, Windows SharePoint Services 3.0 does not provide tools to scale out to high numbers of public-facing Web sites of different domains to the degree that many hosters want to provide offerings for. To enable Windows SharePoint Services 3.0 to increase capacity and really scale at an Internet level, we have researched different configurations to extend the standard Windows SharePoint Services 3.0 capabilities. Using Active Directory and SQL Server 2005 as the two main membership directories, we have put together guidance to increase site capacity on a single Windows SharePoint Services 3.0 implementation.

On a standard installation of Windows SharePoint Services 3.0, membership groups are scoped at the Web application level (the IIS virtual server level). This means that a user named "John" who has been granted access to a site (on a single Web application) will be able to log on to all sites on that Web application. While he will not have access granted to those sites, he will still have a valid logon because the authentication form is shared by each site. This becomes not only a potential security concern, but also an issue when the owner of a different site would like to have a different user named “John” as a site member. The user “John” has already been taken by the first owner and is not available. Plus, there can be confusion when using the Windows SharePoint Services 3.0 people-picker utility (a Web control that allows a user to search for other users) with a site configured for forms-based authentication.

There are various places in a SharePoint site where a site owner or another site user needs to find another user. Windows SharePoint Services 3.0 provides a people-picker utility to search for users based on keywords. This people picker has some issues when working with forms-based authentication and the various

23 providers. Specifically, for the Active Directory providers, the default behavior is to return users in the form of “Domain\username”. These users, if selected, cannot log on to the site by using forms authentication. It is important to understand that users must be added to sites by using the naming convention of :. For example, if you want to add a user named John Smith, you will need to add the user specified with the provider such as “ADProvider:john_smith”. Do not add users where the domain name appears such as “DOMAIN\john_smith”. While this is technically the same account in Active Directory, it is a completely different account according to Windows SharePoint Services 3.0. More importantly, this domain-specified user will not be able to log on by using forms authentication. Only users added by using the provider naming convention can use forms authentication. This information is useful to have in an FAQ for site owners and administrators, or anyone else who might add users to a site through Windows SharePoint Services 3.0.

Similar to the Active Directory account creation mode, using the domain account mode also relies on the ASP.NET 2.0 Active Directory membership provider to enable forms-based authentication. The behavior of the SharePoint site and the authentication process is the same for both modes of Active Directory. As shipped, Windows SharePoint Services 3.0 provides no way to create Active Directory users when using the domain account mode, so we have built a sample application and user interface to provide this functionality inside a site (see the User Provisioning section for more details on this sample).

New installations of Windows SharePoint Services 3.0 using Active Directory are encouraged to use the domain account mode to host users. In this mode, there are no specific Windows SharePoint Services 3.0 requirements of Active Directory in regards to setting up OUs, groups, or users. For many enterprises, this is not an issue because their Active Directory structure has been created prior to the introduction of SharePoint. In the hosting environment, there are recommendations and best practices for setting up Active Directory to work with Windows SharePoint Services 3.0 by using forms-based authentication.

Supporting multiple users on a single implementation of Windows SharePoint Services 3.0 means enabling a secure and scalable hosting model in Active

24 Directory that maps to multiple SharePoint sites. To allow fine-grained security to individual sites, Active Directory must be set up to allow the List Object property to be visible and available. To set Active Directory to List Object mode, we have included a VBScript file named “EnableListObjectMode.vbs” that can set this property. The source code for this script is also included in the appendix of this document. The usage is simply:

cscript EnableListObjectMode.vbs

Note: Setting the dsHeuristics attribute to 001 enables List Object mode.

The following is a sample design in Active Directory that will help to support segregation of those users in conjunction with the sample code Web services provided.

To enable this in our sample scenario, we have created an Organizational Unit (OU) named Hosting. It is in this OU where all of the users for a hosting scenario will be created. As illustrated in the screen shot, each SharePoint site has its own sub-OU under the Hosting node. Inside each site OU, each user will be created and placed in a group named “ Users”. To properly secure this environment for multiple users across various sites you want to make sure that each user in Contoso, for example, cannot get any information about users in other sites or in other OUs outside of the Contoso OU. To accomplish this, a few basic security settings must be configured.

Once you have created the initial Hosting OU, you must make sure that Authenticated Users (any user on any Windows SharePoint Services site) can read from this OU.

25 This should be a manual step when the Hosting OU is created, if not already configured in Active Directory. You might also want to manually remove access for Authenticated Users on the following standard Active Directory containers:

 Builtin

 Computers

 Domain Controllers

 ForeignSecurityPrincipals

 Infrastructure

 System

 Users

The following steps around security and setting up the site OUs will be automatically completed in the sample Web services when creating a new site or new user, but here are the steps that are happening behind the scenes.

When a new site is created through the Web services, a site OU will automatically be created under the Hosting OU. For example, when we create a

26 site named www.Contoso.com, we will also create a child OU named “Contoso”. We will also create the site owner as a user in this OU. We will also create a user group named Contoso Users to store this and all other users. Each new user created for this site will live in this Contoso OU and be a member of the Contoso Users group. Now we can enable this group to have the appropriate read access on this Contoso OU. In addition, we must remove read access for the Authenticated Users. The net effect of these two operations means that no other users (in ADatum, for example) will have read access into users of Contoso. It also grants only Contoso users this read access. Security should be set for “This object only” with List Object allow access, and also “This object and all child objects” with List Contents, Read All Properties, and Read Permissions.

These settings above are automatically set by the Web service when a new SharePoint site is created.

5.2 Non-Active Directory or custom mode

Many of these issues are still problematic on non-Active Directory membership stores as well. To represent such a platform that many hosters might use, let us look at using SQL Server 2005 as a membership store for SharePoint sites. Using the ASP.NET 2.0 SQL membership provider we can enable forms authentication with SharePoint sites. The main problem here is that this membership provider is scoped at the Web application level. Users must be unique across all SharePoint sites in that Web application (or virtual server in IIS). This becomes very confusing for site owners who are trying to create new users when they receive an error message that a user already exists with that name, yet they surely have not created one yet.

To solve this problem and to enable Windows SharePoint Services 3.0 to scale to many more sites on a single Web application, we have created a custom membership provider built on top of the ASP.NET 2.0 SQL membership provider. This custom provider essentially allows www.ADatum.com, www.Contoso.com, www.Fabrikam.com, etc., to exist as separate site collections within a single SharePoint Web application. Each site is uniquely separated, and users of one site cannot see another. This configuration allows SharePoint to host thousands of domains in a single Web site. The custom SQL membership provider scopes

27 users down to a group of one or more sites named an Application. An Application has a one-to-many relationship to SharePoint sites. Users can be created and given permissions to access one or more individual sites within a SharePoint Web application. When a user is created, the user is associated with a SQL- based “Application” instead of just a site. You can then add one or more SharePoint sites to that Application grouping, and each user in the Application can access any site in that group. This is particularly useful for related sites or sites that are owned by the same customer. One example is when a customer (site owner) creates SharePoint sites named “east.contoso.com” and “west.contoso.com”, both inside the “litwareinc” application. Users are then associated with the “contoso” application, so they can potentially log on to either of the two Web sites. They will not need two separate accounts, and the site owner simply has to grant read (or higher) access to a single account on both sites.

One of the challenges with using forms-based authentication and the provider model is that adding users to sites is not as intuitive as it could be. As the site owner of a SQL-based membership site, a customer might want to add an existing user to a new site. In the example above, the same site owner also purchases a new site named “north.litwareinc.com” and wants to add the same user “John” with author permissions on this new site. Windows SharePoint Services 3.0 providers a people-picker interface for adding users where the site owner can search for keywords such as “john” and it will return the account options. Because John is a member of the “litwareinc” application, he will be available to the north.litwareinc.com Web site.

To assist with the creation of users and applications, we have a sample command-line utility specifically for working with SQL-based membership repositories and deals with the Application idea to separate SharePoint sites. The next section discusses site provisioning and includes additional details on the MembershipSiteAdmin.exe tool.

28 6 Site Provisioning

The ability to provide a fast and automated provisioning experience for the customer can help reduce the required time, resources, and risk of user error. One key aspect that can benefit from automation is the process of creating a new site. Many hosting companies have a control panel application that presents their customers with various options including signing up for a new Web site. Windows SharePoint Services 3.0 site provisioning can be integrated directly into the control panel application in various ways.

We have provided sample Web services for Windows SharePoint Services 3.0 site provisioning that can be integrated directly into an existing application. These Web services provide an example of using Windows SharePoint Services 3.0 in a hosting scenario that has Active Directory as the back-end user repository with forms-based authentication on the front end. A recommended configuration of Active Directory will help hosters scale Windows SharePoint Services 3.0 for multiple sites on a single implementation and domain. Guidance is provided on how to build, install, and use these sample Web services to integrate this functionality into custom provisioning applications.

Here are the sample Web methods that are provided that can be integrated into a hosting console application:

 CreateNewSiteNewOwner. This method creates a new SharePoint site and also creates a new Active Directory user to be the owner of that site. This method would be used when a new site and a new owner should be created at the same time.

 CreateNewSiteExistingOwner. This method creates a new SharePoint site and uses an existing Active Directory user as the site owner. This method can be used when the user already has a valid account on another site (already in Active Directory), but they are to be the owner of another new SharePoint site.

 AddNewUserToSite. This method creates a new user in Active Directory and adds this user to an existing SharePoint site. You can use this method

29 when you want to create a new end user to access a running SharePoint site. Typically, the site owner will trigger this process from a control panel application or a link or Web Part on their SharePoint site.

 AddUserToSite. This method adds an existing user in Active Directory to an existing SharePoint site. This method will most likely be used the least, but if the site owner knows that a user already exists on another site, and would like to add this user to his or her own SharePoint site, this method can be called.

While these examples are specific to Active Directory, they can be extended or modified to work with other back-end membership repositories such as SQL Server.

It is important to understand the security issues surrounding the process of calling a Web service from another Web application (such as a hosting console application). Because these Web methods (functions in the sample Web services) require elevated privileges to complete the provisioning tasks, they should be installed in the Administration section of Windows SharePoint Services 3.0. You can put these Web services in the Central Administration directory of Windows SharePoint Services 3.0, and they will be running in the context of other Windows SharePoint Services administrative functions. Specifically, they will be running in the application pool named “SharePoint Central Administration 3.0”. This should be running under the identity of an administrator user as specified in the Windows SharePoint Services 3.0 installation instructions. The Web services have been designed to run in this same context requiring administrative access to Active Directory and to Windows SharePoint Services 3.0. This directory is configured to run with authentication set up for Integrated Windows authentication only. The best way to call into a Web service with this configured is from the Microsoft platform (Windows form application where you pass administrator credentials or an ASP.NET Web application, which can be configured for anonymous as long as the application pool that hosts it has valid credentials that can be passed back to the Web services). For additional information on passing credentials to these Web services, see http://msdn2.microsoft.com/en-us/library/bfazk0tb.aspx.

30 6.1 Provisioning host-named site collections

Windows SharePoint Services 3.0 allows multiple domains to exist in a single SharePoint Web application. In Windows SharePoint Services 2.0, this was named scalable hosting mode. This mode allows http://www.ADatum.com, http://www.Contoso.com, etc., to exist as separate site collections within one Web application. The feature is also available in Windows SharePoint Services 3.0, and can be used in a variety of different ways. For console operation, a new site can be created by using the stsadm.exe command-line tool. The following command creates a new site off of the root site:

Stsadm -o createsite -url http://www.Contoso.com -ownerlogin litwareinc\owner -owneremail Owner_Email -hhurl http://rootsite

In addition to using the command-line tool to create sites, you can use the Windows SharePoint Services 3.0 object model to achieve the same results. The following code sample creates the same site:

SPGlobalAdmin globalAdmin = new SPGlobalAdmin();

SPSiteCollection sites = globalAdmin.VirtualServers[0].Sites;

SPSite oSite = null;

oSite = sites.Add("http://www.Contoso.com", "Site_Title", "Site_Description", 1033, "STS#0", "LITWAREINC\owner", "Owner_Display_Name", "Owner_Email", "LITWAREINC\secondaryowner, "Secondary_Owner_Display_Name", "Secondary_Owner_Email", true);

Many developers are familiar with the fact that Windows SharePoint Services 3.0 ships with a set of Web services for various user and administrative tasks. One of those administrative tasks is creating a new site. There is an issue with the CreateSite Web method, because it does not support the creation of host-named site collections. There are a few options to work around this. Developers can write their own Web service wrapping the API sample code as shown previously. There are several additional configuration options to consider when provisioning a new SharePoint site. Specifying the appropriate site template during site creation will determine which preconfigured Web Parts and other user interface elements are available on the new site. In a hosting scenario, you will probably want to select either a team site template (value of “STS#0” when creating the

31 site), or a blank site with no Web Parts or prebuilt lists (value of “STS#1”). In addition, you can offer one of the “Fabulous 40” templates when they become available.

In a hosting environment, it might be a good idea to specify site quotas on each newly provisioned SharePoint site. While this feature is not included in the sample Web services, it can be added, and you can create a quota template based on predetermined limits, which can be used in future site provisioning. For more information on creating a quota template, see http://technet2.microsoft.com/Office/f/?en-us/library/c2eda191-1814-423b- 882f-1fdafe9df6c91033.mspx.

6.2 Additional steps to provision host-named site collections in SQL authentication mode

Working with the SQL membership provider in a hosting scenario requires some additional steps to properly set up and use a host-named site collections. In general, when you create any SharePoint site, you need to specify a user who will be the site owner. This implies that the owner user already exists in your membership directory. To simplify this and other tasks surrounding the SQL membership provider, we have put together a sample utility called the MembershipSiteAdmin.exe tool. This is a command-line tool that that manages how sites and users are created, deleted, and mapped to applications that help with the following tasks:

 Create a user in the SQL membership database.

 Delete a user in the SQL membership database.

 Create a SharePoint site.

 Delete a SharePoint site.

 Enumerate all the applications associated with a specified user (or check if a user already exists in the system and in any other application).

The command-line tool completes the actions described above by calling custom stored procedures, calling the membership provider API, and wrapping the stsadm.exe tool. This requires that stsadm.exe have a configuration file created and available. The process of creating or deleting a SharePoint site is handled by

32 the stsadm.exe tool, and not part of this application (it is handed off to stsadm.exe to complete). The part of the operation that we are concerned with is the mapping between the desired application name and the fully qualified domain name (FQDN) of the SharePoint site. To do this, we call the appropriate custom stored procedure:

aspnet_Sitemaps_CreateMapping (takes as input an application name and an FQDN)

aspnet_Sitemaps_DeleteMapping (takes as input an FQDN)

Creating and deleting users in the SQL membership repository is done by using the ASP.NET membership service API (System.Web.Security.Membership). We simply call the Membership.CreateUser method or the Membership.DeleteUser method to complete those actions. The provider that is used by the membership service is specified in the App.config file (MembershipSiteAdmin.exe.config) for this custom command-line tool. We are using the shipping SQL provider to complete these tasks, and we manually specify the application name we intend to connect to this user. There is no need to use the custom provider we built because we are not doing the actual authentication from a Web application such as Windows SharePoint Services 3.0. The MembershipSiteAdmin.exe.config file should point to the default location for the stsadm.exe file. If you have installed SharePoint in another location, you will need to update this application setting. Refer to this section of the MembershipSiteAdmin.exe.config file and change the highlighted portion as needed:

Here are examples on using each feature:

 Creating a membership user in a specified application:

MembershipSiteAdmin.exe -o createuser -appname SampleApps -login [email protected] -password pass@word1 -passwordquestion "Favorite Color" -passwordanswer Red -email [email protected]

33  Deleting a membership user:

MembershipSiteAdmin.exe -o deleteuser -appname SampleApps -userlogin [email protected]

 Creating a site and application mapping:

MembershipSiteAdmin.exe -o createsite -appname SampleApps -ownerlogin AspNetSqlMembershipProvider:[email protected] -owneremail [email protected] -url http://www.fabrikam.com -hhurl http://moss.litwareinc.com -sitetemplate STS#0

 Deleting a site and application mapping:

MembershipSiteAdmin.exe -o deletesite -url http://www.fabrikam.com

 Enumerating the applications associated with a specified user:

MembershipSiteAdmin.exe -o enumapps -userlogin [email protected]

Important: You will notice that the user name specified in all of these examples is [email protected]. We recommend that you use a unique user name (or user logon) across the entire Web application. So while security boundaries will be based on the application name, you should provide each new user with a unique name for increased security. To check if a user already exists, you can run with the “enumapps” option, and if that user exists anywhere in the database, the name of an application will be returned. This is a great way to verify you have a database-wide unique user name.

This command-line tool provides some simple console output to indicate the success or failure of a particular task. A user running these various administrative tasks should be familiar with the database structure to help troubleshoot any issues that might arise during any of these routine tasks. For more information on the database structure used by the SQL authentication providers, see

34 http://msdn.microsoft.com/asp.net/downloads/providers/default.aspx? pull=/library/en-us/dnaspp/html/asp2prvdr02.asp.

As specified previously, there is an additional table that has been added to the database named “aspnet_Sitemaps”. You might want to become familiar with this as well. Feel free to explore the aspnetdb database by using the Microsoft SQL Server Management Studio. Be careful not to modify the data unless you know exactly what you are doing. In general, it is a good idea to use the command-line tool to remove users and data.

35 7 User Management

User management is a concern for both the hosting company, and the site owner who might be a customer of the hosting company. The hosting company needs a secure location to store user accounts that will log on to each SharePoint site. The site owner also needs to worry about users specific to the sites they own. For both parties, the issues of user creation, deletion, password changes, and security restrictions need to be addressed.

7.1 User Provisioning

Creating new users in your membership repository will be essential for end users to access individual SharePoint sites. For most hosters, users will be stored in a database (such as Microsoft SQL Server 2005), or another LDAP directory. Much of the sample source code included shows examples of working with SQL Server or Active Directory as the main user repository for SharePoint site users. These samples show how you can integrate user provisioning directly into each SharePoint site so that site owners can create new users for their SharePoint sites.

When using forms-based authentication with Active Directory as the membership directory for SharePoint site users, there are two different modes that can be configured. Windows SharePoint Services 3.0 can be installed in a special mode named account creation mode. Used mainly by hosting organizations, this mode allows ISPs to automatically create sites and add users for customers. Customers are then able to log on to their site and invite others to collaborate. The invitations are sent automatically with a description of the site along with a link to the site, and the user name and password.

To install SharePoint in account creation mode, it is required that an Active Directory OU exist for all users. As sites are created, and users invited, SharePoint will put all users into a single OU. Unfortunately, there are issues around using a single OU. This is the main reason that account creation mode is

36 now a deprecated feature. Although support will continue through version 3.0, account creation mode will not exist in version 4.0.

7.1.1.1 Configuring Windows SharePoint Services in account creation mode

Active Directory account creation mode enables Windows SharePoint Services 3.0 to automatically create accounts for new users. A specific Active Directory OU must be created for all users who are provisioned through this mode. New accounts are created based on a user’s e-mail address. The e-mail address is used to send an invitation to the user. The user’s e-mail will contain the site URL, and the user name and password for the site.

7.1.1.2 Create an Active Directory organization unit

Prior to installing Windows SharePoint Services 3.0 in account creation mode, create the OU that will be used to contain users that are created by SharePoint. To do this, launch Active Directory Users and Computers.

37 In the Organization unit box, enter the name that you would like to use, and then click OK. The new OU will appear under the Active Directory domain.

7.1.1.3 Configuring Windows SharePoint Services in account creation mode

The following is a concise checklist of the installation procedure. Refer to the appendix of this document for a step-by-step screen shot version.

1. Install Windows SharePoint Services 3.0 with Server Farm options.

2. Once the initial installation is complete run the SharePoint Products and Technologies Configuration Wizard.

3. On the Connect to a server farm page, select No, I want to create a new server farm, and then click Next.

4. Configure the database settings add more information as needed.

5. On the Configure SharePoint Central Administration page, select the Specify port number if you want a specific port number. Otherwise, accept the defaults and click Next.

6. On the Completing the SharePoint Products and Technologies Configuration Wizard page, click the Advanced Settings button.

7. The Advanced Settings page will allow you to enable Account Creation Mode. Select the Enable Active Directory Account Creation Mode check box. Once the check box has been checked, enter the Active Directory Domain and the Organization Unit that was created earlier. Click OK.

8. On the Completion page, click Next.

38 9. The Configuration Successful page will appear. Click Finish to launch the Central Administration page.

10. Create a new Web application by going to Application Management and clicking on Create or extend Web application link.

11. On the next page, click Create a new Web application.

12. On the Create New Web Application page, select Create a new IIS Web site in the IIS Web Site section. In the Application Pool section, either select your Predefined security account, or specify the name of the account to be configured. Keep all other defaults, and click OK.

13. While in Central Administration, navigate to the Operations tab. Select the Outgoing e-mail settings link.

14. On the Outgoing E-Mail Settings page, specify the SMTP server name and the From and Reply-to addresses. Then click OK.

7.1.1.4 Create SharePoint site collections

At this point, you are now ready to create the top-level site. Use the stsadm.exe command-line tool to create a site.

Stsadm.exe –o createsite

–url

-ownerlogin

[-ownername ]

[-lcid ]

[-sitetemplate ]

[-title ]

[-description ]

[-hostheaderwebapplicationurl ]

[-quota ]

The following command creates a new site.

Stsadm -o createsite

-url http://www.contoso.com

-ownerlogin userB

-owneremail [email protected]

39 -hhurl http://moss

–sitetemplate STS#0

On a successful completion, the user will receive an e-mail invitation for the new site. Within the e-mail, the user will receive the user name and password to log on to the site.

7.1.1.5 Using the stsadm getproperty operations

The stsadm getproperty operation is useful when the configured values need to be obtained. Use the following syntax:

Stsadm –o getproperty –pn

The following property names pertain to the account creation mode.

 createadaccounts. Contains a value specifying which user account mode has been configured. "Yes" indicates that you are in Active Directory account creation mode, "no" indicates that you are in domain account mode.

 adaccountdomain. Specifies the Active Directory domain name to use for user accounts in Active Directory account creation mode.

 adaccountou. Specifies the organizational unit to use for user accounts in Active Directory account creation mode.

40 7.1.2 Domain account mode

Account creation mode is now a deprecated feature in Windows SharePoint Services 3.0, so new installations requiring the use of Active Directory as the membership repository should not use this feature. Instead, the default mode most installations use is the domain account mode. This mode is most often used and is the best option when using integrated authentication in an organization. However, this mode can still be used with an Internet authentication scheme by using forms-based authentication. Domain account mode is the default installation of Windows SharePoint Services 3.0, and there are no special instructions required outside of installing Windows SharePoint Services 3.0 in your environment. That means that there is no required OU that SharePoint knows about for authenticated users.

In previous chapters, we have discussed the setup of Active Directory for multiple tenancy. Once Active Directory has been set up, and the ASP.NET 2.0 Active Directory Membership Provider is configured, sites and users can be created by using this membership model. We have provided sample code in the form of Web Parts, Web pages, and Windows SharePoint Services 3.0 features that provide a simple user interface to allow an administrator to create a new user in the membership repository and automatically add that user as a reader to the SharePoint site. Individual users can change their own passwords when visiting a SharePoint site. These new features are integrated directly into the Windows SharePoint Services 3.0 drop-down menus and Site Settings options by using Windows SharePoint Services 3.0 features. The sample features to provide these user provisioning capabilities can be accessed at each SharePoint site when the features have been installed. Navigate to your SharePoint site, and log on as a site owner. Click the Site Actions button, and select Site Settings. This will load the Site Settings page, and you should see a new link named "Create User" in the Users and Permissions column.

41 Click the Create User link to go to the CreateUser.aspx page. This will allow you to create a new user in your current authentication provider repository and also on your current site (configured as a reader at first which you can change later).

42 On this page, you can enter the basic information to create a new user such as first name, last name, user name, e-mail address, and password. The default setting is for the page to create a random password for you and automatically send it via e-mail it to the user, so the site owner will never see it. You can clear this option and specify a desired password which will also be sent via e-mail to the user. The user will want to change this initial password after they first log on.

In addition to these Web pages exposed directly on the SharePoint site, we have also provided Web services that can create and add users to a SharePoint site. These Web services contain Web methods for user creation and handle most of steps to properly secure users in Active Directory. You might want to use these Web services (or the sample code included) to programmatically create users in Active Directory.

43 7.1.3 Non-Active Directory custom authentication mode

If you choose to use a different membership repository other than Active Directory, you can still enable forms-based authentication to SharePoint sites. Each authentication zone can have a pluggable, custom authentication provider in addition to the default support for Windows Basic, Digest, NTLM, Forms, and Kerberos authentication methods. This provider model is based on the ASP.NET 2.0 authentication provider architecture. In addition to various prebuilt providers (SQL Server and Active Directory), custom providers can be built to use any number of custom membership directories or systems. For more information about building custom providers, see http://msdn.microsoft.com/library/default.asp?url=/library/en- us/dnpag2/html/PAGExplained0002.asp.

If you are using SQL Server 2005 as your membership provider, and you are using the custom membership provider described in the associated sample code, you can use the Hosting Provisioning Features sample Web pages and features to enable user provisioning. Refer to the steps and screen shots in the Active Directory Domain Account Mode section for information on how the user creation process works for a site owner. If you are using a custom membership provider, you can use the source code for these Web Parts and pages to enable user creation in your own membership repository.

7.2 Resetting passwords

As with most Web sites that use user names and passwords, it can be extra work for the site owner or Web designer to enable self-service password resetting. This is not a feature of Windows SharePoint Services 3.0, but we have included sample code for a Web Part and hosting page to enable self-service password resets for both Active Directory and SQL-based membership users.

The Hosting Provisioning Feature sample set includes a feature that adds the ability to change passwords directly in the Welcome drop-down menu on a SharePoint site. Once an end user is logged on to a site, the user can click the Welcome drop-down menu and select the Change Password option.

44 Click the Change Password link to display the CreatePassword.aspx page.

This page enables a user to enter an old password, enter a new password, and confirm that new password. The password is then immediately changed for the next time the user logs on to the site. While this sample only works with Active Directory or SQL membership users, it can be extended through custom code to work with your own custom provider and membership store.

45 8 HTTPS

To configure HTTPS, a certificate needs to be applied to the Web site at an IIS Web site. Therefore, HTTPS can only be configured at the Web application level in Windows SharePoint Services 3.0. In hosting scenarios, the hosters can configure a single Web application with HTTPS and then create multiple host- named site collections within that Web application. Each Web site is technically sharing a single certificate. However, if the requirement is to apply a unique certificate per site, the hoster will need to create Web applications (which by definition do not scale as high as site collections in Windows SharePoint Services 3.0).

8.1 Configuring HTTPS for host-named site collections

Configuring HTTPS is a matter of enabling SSL on the Create Web application page. SharePoint will automatically assign a port number to the Web application or you can specify a specific number if you choose to do so.

Once the Web application has been created, open IIS manager and assign a certificate. Create site collections as usual, making sure that you specify the port number for both the –url and –hhurl parameters of the stsadm –o createsite command.

Stsadm –o createsite –ownerlogin litwareinc\administrator –owneremail [email protected] –url https://www.Contoso.com:443 –hhurl https://moss:443

46 HTTPS sites can be created for account creation mode, Active Directory – domain account mode, and Active Directory forms authentication.

8.2 Issues

The customizations that were done to the SQL membership providers do not support SSL, neither do they support creating site collections on any port other than port 80. Additional enhancements are required to both the MembershipSiteAdmin tool and the SQLSiteProvider to provide these capabilities.

47 9 Search

Search in Windows SharePoint Services 3.0 is designed to work only with NTLM. More specifically, the index component in Search requires NTLM. Therefore, in order for Search to be used with any other authentication mechanism, there are certain workarounds that are needed.

This implies that search will work in Account Creation and Domain Account modes, if these modes are configured with NTLM. To configure search in either of these two modes, start the search service then, ensure that the content database is associated with the Search Server. Wait for the content to be crawled and then initiate a search query to see results. SSL can be enabled on these sites and search will automatically work. This is the default configuration, whereby each NTLM Web site points to its own content database.

In situations where the Web Application’s authentication is configured for something other than NTLM ( ie. Forms authentication, Basic authentication, Kerberos authentication …etc…) you will need to configure two zones. The Default zone must be configured with NTLM, and then the Web app should be extended to another zone for the non NTLM authentication mode.

9.1 Configuring Search with Basic Authentication:

Windows SharePoint Services 3.0 Search does not work when a site is configured to use basic authentication. For host-named site collections, use the following steps to get this working:

Steps:

 Open SharePoint Central Administration Web site

 Click Application Management.

 Click "Create or extend Web application"

 Click "Create a new Web application "

48  Select "Create a new IIS Web site". Set the Port to 80.

 Set options as needed.

 Click OK

 Return to the Application Management Page.

 Click "Create or extend Web application"

 Click "Extend an existing Web application"

 Select the Web Application that was just created.

 Select "Create a new IIS Web site"

 Set the Port field to 80.

 Enter "temp" in the Host Header field.

 Set Zone to "Internet" (or whatever you'd like the zone which uses Basic to be, just make note of it.)

 Set other options as needed.

 Click OK

 Click "Authentication Providers"

 Click "Internet" (or whicever zone you picked above)

 Set the Zone to use Basic Authentication, click OK.

 Open the Internet Information Services manager.

 Right-click on the Web site we created first and select Properties. (by default is labeled "Sharepoint - 80")

 click "Advanced"

 Double Click the Default entry in the "Multiple Identities for this Web site" section.

49  Select the "correct" IP address to be used by the Windows SharePoint Services search box for indexing. (which uses NTLM)

 click OK, then click OK.

 Right click on the Web site which was created 2nd and select Properties. (by default this site is labled SharePoint -temp80)

 Click "advanced".

 doubleclick the entry which has the host header value of "temp".

 Remove Temp from the Host Header field.

 Select the "correct" IP address for Basic site.

 Click OK, then OK again.

At this point, we are ready to create our first host-named site collection, however we need to ensure that the server running the Windows SharePoint Services Search service resolves the IP address to the NTLM IP before we create this site. This can be done with either a split DNS architecture or just using the hosts. file on that server. Once that is configured, use "STSADM -o Createsite" with the -hostheaderwebapplicationurl parameter to create the site.

To add more host-named site collections, simply add the DNS/Hosts file entry on the search machine, then use STSADM to create the site.

If anonymous access is desired, it must be configured on the "Default" Zone, even if users are browsing via the Internet zone, as Host-Named site collections always take that setting from the Default Zone.

9.2 Configuring Search for HTTPS sites In some situations, there may be a need to extend an http Web application to an https Web application and have search results returned for both. This scenario

50 arose with hosters who had customers that want to move from http to https sites and couldn’t afford the overhead of doing a backup/restore for each customer’s site. Although this is an unsupported scenario, it can be made to work. The issue arises from the https site. Once the http site has been converted to an https site, the search from the https site fails. The two urls are shown below. The http site returns results, while the https site doesn’t.

By modifying the query string in the url, search results are returned.

You will also notice that the results are http links and not https – as it should be.

51 The workaround for the above issue involves developing an HttpModule that replaces the https in the query string, as well as redirects the search result links to https. A sample http module can be found below: using System; using System.Collections.Generic; using System.Text; using System.Web; using System.Web.Configuration; using System.Configuration; using System.Diagnostics; namespace SearchMapper { public class Mapper : IHttpModule { #region IHttpModule Members public void Dispose() { return; }

public void Init(HttpApplication context) { context.BeginRequest += new EventHandler(context_BeginRequest); }

void context_BeginRequest(object sender, EventArgs e) { System.Web.HttpApplication Appl = (System.Web.HttpApplication)sender; HttpContext cntx = Appl.Context;

// if the path is /_layouts/searchresults.aspx, // modify the query string if (cntx.Request.Url.AbsolutePath == "/_layouts/searchresults.aspx") { string query = cntx.Request.Url.Query; query = query.Replace("?", ""); query = query.Replace("https", "http"); cntx.RewritePath(cntx.Request.Url.AbsolutePath, "", query); }

// Implementation to be done by hosters // if url is http://fqdn // change url to https and redirect the request

#endregion }

In order for this http module to be used by Sharepoint, it needs to be compiled and deployed to the GAC. The Web.config for the Web Application should be modified by adding a new element ( as shown below ) to the httpModules section. Ensure that the PublicKeyToken matches the assembly that has been installed in the GAC.

Eventhought the search was conducted on a site with https, the results are returned with http urls (not https). In order to fix this problem, you can create a new http module that maps the http urls to https urls. The shell of the http module is similar to the sample given above.

9.3 Configuring Search for Forms Based Authentication with Custom Authentication Provider:

Search in Windows SharePoint Services does not work with FBA and custom authentication providers. At the point of writing this white paper, we are still investigating workarounds for Search to work with Custom Authentication Providers using FBA. If a workaround is found, it will be communicated separately.

53 10 Configuring HTTPS for Host-Named Site Collections

Configuring HTTPS is a matter of enabling SSL on the Create Web application page. Windows SharePoint Services 3.0 will automatically assign a port to the Web application. However, you can change it to whatever port you want. Once the Web application has been created, open IIS manager and assign a certificate.

Create sites as usual, making sure that you specify the port number for both the –url and –hhurl parameters of the stsadm –o createsite command.

HTTPS sites can be created for account creation mode, Active Directory – domain account mode, and Active Directory forms authentication.

10.1 Issues

The customizations that were done to the SQL membership providers do not support SSL, neither do they support creating site collections on any port other than port 80. Additional enhancements are required to both the MembershipSiteAdmin tool and the SQLSiteProvider to provide these capabilities.

As shipped, Search for Windows SharePoint Services 3.0 will not work when HTTPS is configured. For a workaround, see the section on Search.

54 11 Migration from 2.0 to 3.0

Windows SharePoint Services 3.0 provides two options to upgrade from Windows SharePoint Services 2.0 to Windows SharePoint Services 3.0: in-place and gradual. An in-place upgrade is used to upgrade all SharePoint sites at once. A gradual upgrade allows selected sites to be upgraded. The following sections describe each method.

11.1 In-place upgrade

 Windows SharePoint Services 2.0 is overwritten with Windows SharePoint Services 3.0, and the content databases are changed. This means that an in-place upgrade is an irreversible process, without the option of rolling back to the previous version.

 The original Windows SharePoint Services 2.0 sites cannot be viewed after the upgrade.

 All sites are unavailable to site visitors during the upgrade.

 Site visitors continue to use the same URLs after the upgrade.

11.2 Gradual upgrade

 For larger deployments of Windows SharePoint Services 3.0, a gradual upgrade is the best option because it allows the administrator who is performing the upgrade to control how many site collections to upgrade at one time. In this way, large deployments of Windows SharePoint Services 2.0 can be upgraded gradually while hosting previous version sites.

 As each group of site collections is upgraded, the data in the groups is copied from the original database to a new database before the data is upgraded to Windows SharePoint Services 3.0. The original Windows SharePoint Services 2.0 data is maintained in the original database until the server administrator explicitly deletes it. Because of this, upgraded sites can be easily rolled back to the previous version, if necessary.

 All sites are available to site visitors during the upgrade.

55  The upgrade process redirects the original URLs to the upgraded version of the sites. This way, users can continue to use the same URLs that they used before the upgrade. For a high-level workflow process of the upgrade, see http://office.microsoft.com/en-us/sharepointtechnology/HA100773421033.aspx.

For additional information provided in the Upgrade Operations Guide, see Upgrading to Windows SharePoint Services version 3.

56 12 The “Fabulous 40” Application Templates

Application templates are custom scenarios for the Windows SharePoint Services 3.0 platform tailored to address specific business processes or sets of tasks. These application templates are tailored to address the needs and requirements for specific business processes or sets of tasks for organizations of any size. While these applications also provide a starting point for partners and developers looking to build deeper Windows SharePoint Services 3.0 solutions. A sample application template that can be used to create a portal site for a “Sales Team” is as follows:

Microsoft will release a new set of application templates for Windows SharePoint Services 3.0. Some of the previous scenarios, such as Help Desk, Project Site,

57 Knowledge Base, and the Employee/HR templates, have been significantly improved to incorporate and highlight new capabilities in Windows SharePoint Services 3.0. New scenarios were also added to address customer and partner requests. Some examples include call center, supporting the compliance process, inventory and asset tracking, and sports league. The new set of templates will make use of Windows SharePoint Services 3.0 capabilities, preconfigured with Office SharePoint Designer, such as workflows, wikis, Gantt task charts, portal sites, master pages, and document management.

To learn more about templates and to download them, see http://www.microsoft.com/technet/windowsserver/sharepoint/wssapps/v3templ ates.mspx

12.1 Site administrator templates

Forty new application templates are coming soon for Windows SharePoint Services 3.0. Twenty of the templates will be “site administrator templates” and available in English only. These templates will be easy for site administrators to install in a template gallery without requiring server administration access. The English-only site administrator templates are:

 Board of Directors

 Classroom Management

 Clinical Trial Initiation and Management

 Competitive Differentiation Site

 Discussion Database

 Emergency Management for Government Agencies

 Employee Activities Site

 Employee Self-Service Benefits

 Employee Training Scheduling and Materials

 Equity Research

 Manufacturing Process Management

 Marketing Campaign Planning and Execution

 New Product Development

 New Store Opening

58  Product Portfolio and Profitability Management

 Request for Proposal

 Sports League

 Team Work Site

 Timecard Management

 Vendor Performance Rating

In order for these templates to be available to the end customer, they will need to be downloaded separately, so that they can be saved on the customer’s hard disk. Instead, the server administrater (at the hoster) can make these templates (.stp) files available to their customers by executing the following command:

stsadm.exe -o addtemplate -filename