Home - Todd Klindt's home page
Creating Shared Hosting Solutions on Windows SharePoint Services 3.0
Prepared by
Microsoft Consulting Services, West Region
Monday, 19 February 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.
© 2007 Microsoft Corporation. All rights reserved.
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.1 Active Directory 16
4.1.1 Account creation mode 16
4.1.2 Domain account mode 16
4.2 SQL authentication 18
4.2.1 Configure SharePoint for SQL forms authentication 20
5 Multiple Tenancy 23
5.1 Active Directory 23
5.1.1 Account creation mode 23
5.1.2 Domain account mode 24
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.1 Account creation mode 36
7.1.2 Domain account mode 41
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.1 Why would you need to develop this? 73
14.2.2 How do you develop? 74
14.2.3 How do you debug? 77
14.3 Developing SharePoint Web applications 79
14.3.1 Why would you need to develop this? 79
14.3.2 How do you develop? 79
14.3.3 How do you debug? 83
14.4 Developing custom HTTP modules 84
14.4.1 Why would you need to develop this? 84
14.4.2 How do you develop? 85
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
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.
[pic]
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.
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 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 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. 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 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.
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.
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 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 Silo architecture
The most popular configuration in shared hosting (for 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 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.
[pic]
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 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.
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.
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.
[pic]
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.
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.
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.
5 Improvements in Windows SharePoint Services 3.0 scalable hosting mode over Windows SharePoint Services 2.0
(Excerpts from 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.
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 and you want to add a host-named site collection with the URL . The command would look like this:
stsadm.exe -o createsite
-url
-ownerlogin DOMAIN\username
-owneremail username@
-hhurl
Regular Internet service providers (ISPs) would configure their DNS servers to associate hoster. 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 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.
Also, host-named site collections cannot be used with the advanced extranet scenarios provided by alternate access mappings, such as SSL termination.
Authentication Modes
The new authentication model in Windows SharePoint Services 3.0 leverages the 2.0 authentication framework. The new model is a pluggable framework that provides easy integration for a number of providers into SharePoint.
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.
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.
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 2.0 authentication framework, you can easily create a custom user provisioning system and integrate forms-based authentication into Windows SharePoint Services 3.0.
2 Non-Active Directory or custom mode
Because Windows SharePoint Services 3.0 provides a pluggable framework that leverages 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.
Forms-Based Authentication
The new authentication model in Windows SharePoint Services 3.0 leverages the 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.
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 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.
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 will describe the customizations that were developed for a hosting solution. The customizations provide the scoping of users to their respective sites.
1 Active Directory
1 Account creation mode
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.
2 Domain account mode
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.
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.
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.
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.
There are a variety of ways to do this. provides an 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.
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.
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.
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.
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.
1 Active Directory
1 Account creation mode
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 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.
2 Domain account mode
Similar to the Active Directory account creation mode, using the domain account mode also relies on the 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 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.
[pic]
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 site named , 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.
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 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 2.0 SQL membership provider. This custom provider essentially allows , , , 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 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.” and “west.”, 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.” 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. 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.
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 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 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 .
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 , , 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 -ownerlogin litwareinc\owner -owneremail Owner_Email -hhurl
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("", "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 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 .
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 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 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 naderi@ -password pass@word1 -passwordquestion "Favorite Color" -passwordanswer Red -email naderi@
• Deleting a membership user:
MembershipSiteAdmin.exe -o deleteuser -appname SampleApps -userlogin naderi@
• Creating a site and application mapping:
MembershipSiteAdmin.exe -o createsite -appname SampleApps -ownerlogin AspNetSqlMembershipProvider:naderi@ -owneremail naderi@ -url -hhurl -sitetemplate STS#0
• Deleting a site and application mapping:
MembershipSiteAdmin.exe -o deletesite -url
• Enumerating the applications associated with a specified user:
MembershipSiteAdmin.exe -o enumapps -userlogin naderi@
Important: You will notice that the user name specified in all of these examples is naderi@. 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 .
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.
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.
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.
1 Account creation mode
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 now a deprecated feature. Although support will continue through version 3.0, account creation mode will not exist in version 4.0.
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.
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.
[pic]
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.
[pic]
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.
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.
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
-ownerlogin userB
-owneremail ryani@
-hhurl
–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.
[pic]
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.
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 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.
[pic]
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).
[pic]
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.
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 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 .
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.
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.
[pic]
Click the Change Password link to display the CreatePassword.aspx page.
[pic]
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.
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).
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.
[pic]
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 administrator@ –url –hhurl
HTTPS sites can be created for account creation mode, Active Directory – domain account mode, and Active Directory forms authentication.
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.
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.
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 "
• 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.
• 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.
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 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.
[pic]
By modifying the query string in the url, search results are returned.
[pic]
You will also notice that the results are http links and not https – as it should be.
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
// 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.
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.
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.
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.
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.
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.
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.
• 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 .
For additional information provided in the Upgrade Operations Guide, see Upgrading to Windows SharePoint Services version 3.
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:
[pic]
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, 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
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
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 -title [-description ]
2 Server administrator templates
The other 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). These will be created as site definitions, providing tighter integration and enhanced functionality within the Windows SharePoint Services 3.0 platform. They will require a server administrator to install. These templates are:
Absence Request and Vacation Schedule Management
Budgeting and Tracking Multiple Projects
Bug Database
Call Center
Change Request Management
Compliance Process Support Site
Contacts Management
Document Library and Review
Event Planning
Expense Reimbursement and Approval Site
Help Desk
Inventory Tracking
IT Team Workspace
Job Requisition and Interview Management
Knowledge Base
Lending Library
Physical Asset Tracking and Management
Project Tracking Workspace
Room and Equipment Reservations
Sales Lead Pipeline
3 Grouping of templates
To create compelling business applications, a hoster can combine one or more of these application templates to create a “packaged” offering. These templates can provide various functions that are grouped together according to the function they perform. For example, a hoster can create a package geared towards “Telephone Services” oriented businesses. They can create a Web site named thephone-. The thephone- can be any generic team site. Using this team site, multiple subsites can be created by using templates such as:
• OOF: Absence Request and Vacation template
• schedules: Schedule Management template
• timecard: Time card Management
• benefits: Employee Self Service Benefits
Alternatively, sites can be created by using subdomains of a top-level domain. For example, for thephone-, you can have blogs.thephone-, wiki.thephone-, and so on. However, for host-named sites, a DNS entry can only map to a top-level site collection; and each top-level site collection becomes an independent application, thereby giving rise to security and authentication issues.
There are two ways this issue can be solved:
1. By implementing a a façade layer across all top-level site collections to manage all site collections as a single site.
2. Implmented these solutions as subsite; but create a http module that maps blogs. to blogs and so on
4 Converting templates from Windows SharePoint Services 2.0 to Windows SharePoint Services 3.0
Microsoft has released tools and guidance as a “solution accelerator” to help customers attempt upgrades from some of the previous application templates for Windows SharePoint Services 2.0 to run on the new Windows SharePoint Services 3.0 platform. For information about the solution accelerator, see or
.
Next, we will present a list of all templates and categorize them. These categories can be samples of groupings of business applications that hosters can offer to their customers.
Other Deployment Issues in Hosting Scenarios
1 Active site count
One of the metrics that is of interest to hosters is the “Active Site Count”, as measured and reported by Netcraft. With Windows SharePoint Services 3.0, as is the case with all secured sites, Netcraft has an issue with accessing the sites, and therefore, cannot count them.
A site that is secured by using NTLM or Basic authentication does not get counted at all because an HTTP 401 or 403 error is returned. These sites will not be counted at all.
If Windows SharePoint Services 3.0 is using forms-based authentication, access to any site in the Web application is always directed to the same logon page. This is by design; wherein the validity of the URL is not confirmed until the user is authenticated. As all sites get mapped to the same common logon page, all sites get counted as 1 by Netcraft.
This issue is being discussed by Microsoft and Netcraft. If a workaround is found, it will be communicated to all hosters.
2 IIS reset
In Windows SharePoint Services 3.0, on IIS 6.0, any time a new Web application is created, IIS needs to be reset (by using the IISReset command). This is due to how access control lists (ACLs) are administered by IIS 6.0. In a shared hosting scenario, IISReset will cause all Web sites that are hosted on the server to be reset, which is not a desirable situation.
This problem is being researched by Microsoft.
3 Bandwidth measurement tools
Hosters care about bandwidth usage. However, in the current version of Windows SharePoint Services 3.0, there is not a good built in reporting mechanism for reporting bandwidth usage. There is an article on MSDN for 2.0 (unchanged for 3.0) that covers how to use the usage data provided by Windows SharePoint Services. To view this information, see .
Hosters are encouraged to access this download and modify it as needed.
4 People picker
In the hosted scenarios, if the hoster is using Active Directory in domain account mode and has structured Active Directory in the list account mode as describe in this document, the people picker does not restrict users based on the site or the OU they belong to. This is because the people picker is running in the context of the application pool account that has higher privileges. For the scoping to work properly, the hosters need to set the peoplepicker-onlysearchwithinsitecollection attribute at the Web application level. This attribute needs to be set to yes. Once this attribute is set, the users need to be added to the site collection programmatically.
A similar workaround exists to get forms-based authentication to work properly, where the domain\user in Active Directory needs to be added to the site collection as “Provider:user”.
In the hosted scenarios, if the hoster is using AD in Domain account mode and have structured the AD in the list-account mode as describe in this document, the people-picker does not restrict users based on the site or the OU they belong to. This is because the people picker is running in the context of the application pool account that has higher privilages. In order for the scoping to work properly, the hosters need to set the peoplepicker-onlysearchwithinsitecollection attribute at the web application level. This attribute needs to be set to “yes”. Once this attribute is set, the users need to be added to the site collection programmatically.
Below is how you can set peoplepicker attribute using stsadm. You can do all of these things programmatically as well.
1 PeoplePicker Options:
PeoplePicker is a property that can be set using stsadm command. To set properties, the stsadm command is as follows:
stsadm.exe -o setproperty -propertyname
The peoplepicker properties available are:
• peoplepicker-activedirectorysearchtimeout
• peoplepicker-distributionlistsearchdomains
• peoplepicker-onlysearchwithinsitecollection
• peoplepicker-searchadcustomquery
• peoplepicker-searchadforests
2 peoplepicker-activedirectorysearchtimeout
Allows you to configure the timeout when a query is issued to Active Directory (AD). For example, if you have 10 ADs to search and you do not want to let the user to wait too long, you could configure the timeout to be 10 seconds per AD.
The value of this property is an integer such as “30”. The default value is 30 seconds.
stsadm.exe -o setproperty -pn peoplepicker-activedirectorysearchtimeout –pv 30
3 peoplepicker-distributionlistsearchdomains
Restricts the search from a search distribution list to be from a specific subset of domains. For example, if we use the following command:
stsadm.exe -o setproperty -url -pn peoplepicker-distributionlistsearchdomains -pv corp.;ntdev.corp.
The result will restrict the search for DL to only be corp. and ntdev.corp.. If nothing was set, it will search all trusted domains or the domains listed in the configuration.
Note: The domain name should be DNS name instead of flat name.
4 peoplepicker-onlysearchwithinsitecollection
Displays only users that are members of the site collection.
Only users that are already added to the site collection are displayed in the People Picker. This prevents anyone from browsing your user directory through the People Picker.
For example, in a hosting scenario, we do not want to let the end users to be able to search users from Active Directory. We only want the end users be able to search users that are already in the site collection. But suppose the end user already knows the login name in Active Directory, we still allow end users to invite the user with fully qualified login name.
The following commands are used to configure this property:
Stsadm.exe -o setproperty –url –pn peoplepicker-onlysearchwithinsitecollection –pv yes
Stsadm.exe -o setproperty –url –pn peoplepicker-onlysearchwithinsitecollection –pv no
5 peoplepicker-searchadcustomquery
Allows the administrator to set the custom query that is sent to Active Directory.
For example, the admin could use the following command to search for the last name:
stsadm.exe -o setproperty -pn peoplepicker-searchadcustomquery -pn (sn={0}*)
6 peoplepicker-searchadforests
Allows a user to search from a second one-way trusted forests or domains.
By default SharePoint only talks to the domain controller for the domain in which we’re running. Therefore, if you want SharePoint to enumerate a list of users using PeoplePicker from a second forest or domain, you need to run the following command:
Stsadm.exe –o setproperty –pn peoplepicker-searchadforests –pv -url
The format of is a list of
forest:DnsName,LoginName,Password
or
domain:DnsName,LoginName,Password
separated by semicolon.
If they are trusted domains/forests, then it is not necessary to pass in the LoginName or Password, just in the format of
forest:DnsName
or
domain:DnsName
Development Guide
1 Developing custom SharePoint Web services
1 Why would you need to develop this?
The Windows SharePoint Services 3.0 Web service provided by the Microsoft.SharePoint.SoapServer namespace has numerous methods for accessing content on a site, including methods for working with lists or site data, as well as methods for customizing meetings, imaging, document workspaces, or search.
The Simple Object Access Protocol (SOAP) interfaces used in these services provide .NET developers with object models for creating solutions that work with Windows SharePoint Services 3.0 remotely from a client application or custom application. The interfaces are integrated with the server-side object models of the Windows SharePoint Services 3.0 assembly, and their design has been optimized to reduce the number of roundtrips transacted between the client computer and the server.
Most Web services provide their functionality through the /_vti_bin virtual directory, which maps to the \\Program Files\Common Files\Microsoft Shared\Web server extensions\12\ISAPI physical directory in the file system. The Administration Web service uses the /_vti_adm virtual directory, which maps to \12\ADMISAPI.
When these services do not meet your needs, you can develop custom Web services to provide access remotely to SharePoint content.
2 How do you develop?
The basic steps in creating a Web service for SharePoint are:
1. Create an Web service in Microsoft Visual Studio 2005.
2. Create a class library within the Web service that defines the programming logic for the Web service.
3. Generate and edit a static discovery file and a Web Services Description Language (WSDL) file.
4. Deploy the Web service files to the _vti_bin directory.
5. Create a client application to consume the Web service.
1 Create an Web service
1. Open Visual Studio 2005 and create a new Web site from the File menu.
2. In the Templates dialog box:
a. Select the Web Service template.
b. For location, select File System.
c. For language, select C#.
d. Name the service MyWebService.
2 Create a class library
1. In the same solution, add a C# class library project and name it MyWebServiceClass. Use this library for the Web service logic.
2. By default Class1.cs is created. Rename this class to MyService.cs. This changes the name of the class to MyService.
3. In the MyWebService project in App_Code folder is the Service.cs file. Open the file and copy all the using statements to the clipboard.
4. Go back to MyService.cs class in MyWebServiceClass project and replace all the using statements with the ones copied to the clipboard.
5. Switch back to the Service.cs file in the MyWebService project and copy the entire class including the attributes to the clipboard.
6. Go back to MyService.cs class in MyWebServiceClass project and replace the entire MyService class with the copy in the clipboard.
7. Change the name of the class to MyService from Service. Also change the constructor Service() to MyService().
8. For the Web service Namespace attribute change the default from to .
9. In Solution Explorer, select the MyWebServiceClass project and right-click to bring up the context menu. Select Properties. On the Signing tab, select Sign the Assembly.
10. Under the Choose a strong name key file drop-down menu, select New.
11. In the Create String Name Key dialog box, clear Protect my key file with password.
12. For Key File Name provide a name of MyWebServiceClass.snk and click OK to close the dialog box.
13. Right-click the project in Solution Explorer and add a reference to System.Web.Services.
14. Also add a reference to Microsoft.SharePoint.dll. You will find this in C:\Program Files\Common Files\Microsoft Shared\Web server extensions\12\ISAPI. You will need this for using the SharePoint object model.
15. The Web service class that we copied into our class library has a default HelloWorld() Web method. Change the name of it to GetWebInfo().
16. For the Web method, add the following code that uses SharePoint object model to query all sites and get some information.
StringBuilder sb = new StringBuilder();
try
{
SPFarm mySPFarm = SPWebService.ContentService.Farm;
SPServerCollection mySPServerCollection = mySPFarm.Servers;
SPWebService.ContentService.WebApplications;
//SPSecurity.RunWithElevatedPrivileges(delegate()
//{
if (mySPWebAppCollection != null)
{
foreach (SPWebApplication mySPWebApp in mySPWebAppCollection)
{
sb.Append("\nWebApplication: " + mySPWebApp.Name);
sb.Append("\n AppPool: " + mySPWebApp.ApplicationPool.Name + " (" + mySPWebApp.ApplicationPool.Status + ")");
SPContentDatabaseCollection mySPContentDBCollection = mySPWebApp.ContentDatabases;
sb.Append("\n # Content DBs: " + mySPContentDBCollection.Count);
foreach (SPContentDatabase mySPContentDB in mySPContentDBCollection)
{
sb.Append("\n Database Name: " + mySPContentDB.Name);
sb.Append("\n Database Server: " + mySPContentDB.Server);
sb.Append("\n DSN: " +
mySPContentDB.DatabaseConnectionString);
}
sb.Append("\n\n");
}
}
//});
}
catch (Exception ex)
{
return "Error: " + ex.Message;
}
return sb.ToString();
17. Add the following using statements to the class.
using Microsoft.SharePoint;
using Microsoft.SharePoint.Utilities;
using Microsoft.SharePoint.WebControls;
using Microsoft.SharePoint.Administration;
using System.Text;
18. Right-click the MyWebServiceClass project and build it.
19. Drag and drop the MyWebServiceClass.dll from the bin\debug folder to C:\WINDOWS\assembly.
20. Select the MyWebServiceClass.dll file in the C:\WINDOWS\assembly folder. Right-click the file and select Properties. Copy the public key token from here.
21. From MyWebService project under the App_Code folder, select the Service.cs file and delete it. You no longer need this.
22. Open the Service.asmx file and get rid of the CodeBehind file. Instead of code behind, you will use a separate assembly for the class.
23. In service.asmx change the class to refer to MyWebServiceClass.MyService. It should read as follows with the PublicKeyToken replaced with the one that has been copied to the clipboard.
3 Generate and edit a static DISCO & WSDL
1. In Windows Explorer, copy the Service.asmx file of your Web service to \\Program Files\Common Files\Microsoft Shared\Web server extensions\12\TEMPLATE\LAYOUTS.
2. Run Disco.exe at the Visual Studio command prompt from the LAYOUTS directory to generate .disco and .wsdl files. Run a command in the following format to generate the files in \LAYOUTS: disco . This will produce two files: service.disco and service.wsdl.
3. Rename service.wsdl to servicewsdl.aspx and service.disco to servicedisco.aspx.
4. To register namespaces of the Windows SharePoint Services object model, open both the disco and wsdl files and replace the opening XML processing instruction -- -- with instructions such as the following code sample.
5. In the disco file replace literal paths with code-generated paths, as shown in the following code sample.
6. In the wsdl file make similar changes for the element, as shown in the following code sample.
4 Deploy the Web service files
The _vti_bin folder is mapped to Program Files\Common Files\Microsoft Shared\Web server extensions\12\ISAPI. To deploy the Web service files:
1. Copy the three files named service.asmx, servicedisco.aspx, and servicewsdl.aspx from \\Program Files\Common Files\Microsoft Shared\Web server extensions\12\TEMPLATE\LAYOUTS to \\Program Files\Common Files\Microsoft Shared\Web server extensions\12\ISAPI.
5 Create a client application
1. From the File menu, add a Windows Application project to the solution and name it MyWebServiceTest.
2. Right-click this project in Solution Explorer and select Add Web Reference.
3. In the Add Web Reference dialog box, for URL type enter where is the name of your server, and then click the GO button.
4. Change the Web Reference Name to MyCustomService and click Add Reference.
5. In the default Form1, add a button control and change the Text property to read Invoke Web Service.
6. Change the name of the button control to buttonInvoke.
7. Double-click the button control to add code to its click event.
8. Add the code as shown in the following code sample.
try
{
MyCustomService.MyService myService = new MyWebServiceTest.MyCustomService.MyService();
myService.UseDefaultCredentials = true;
MessageBox.Show(myService.GetWebInfo());
}
catch (Exception ex)
{
MessageBox.Show(ex.Message);
}
9. Run the test application, and click the Invoker Web Service button. If everything is OK this will return a string of all Web sites and information about the content database using SharePoint object model through our custom Web service.
3 How do you debug?
Debugging the Web service entails three fundamental steps:
1. Set breakpoints.
2. Attach to the process.
3. Step into the code.
1 Setting breakpoints
1. Open Visual Studio and the MyWebServiceClass project.
2. Open the MyService.cs class.
3. Set breakpoint where desired.
2 Attaching to the process
1. Right-click the MyWebServiceTest project and click Debug.
2. Switch back to Visual Studio and select MyWebServiceClass project.
3. Attach to the process:
a. On the Debug menu, click Attach To Processes….
b. Select the Show process in all sessions check boxes.
c. Look for the w3wp.exe process and click Attach, and you are ready to debug.
3 Step into the code
1. Switch to the running MyWebServiceTest application.
2. Click the Invoke Web Service button. Execution will stop at the breakpoint that has been set.
3. Step through the code as required.
2 Developing SharePoint Web Parts
1 Why would you need to develop this?
Web Parts in Windows SharePoint Services 3.0 provide developers with a way to create user interface elements that support both customization and personalization. A site owner or a site member who has the appropriate permissions can customize a Web Parts Page by using a browser or Microsoft Office SharePoint Designer 2007 by adding, reconfiguring, and removing Web Parts.
The term customization implies that changes are seen by all site members. Individual users can further personalize a Web Parts Page by adding, reconfiguring, and removing Web Parts. The term personalization implies that these changes will be seen only by the user that made them. Developing custom Web Parts provides an easy and powerful way to extend SharePoint sites.
Some ways in which you can use custom Web Parts include the following:
• Creating custom properties you can display and modify in the user interface.
• Improving performance and scalability. A compiled custom Web Part runs faster than a script.
• Implementing proprietary code without disclosing the source code.
• Securing and controlling access to content within the Web Part. Built-in Web Parts allow any users with appropriate permissions to change content and alter Web Part functionality. With a custom Web Part, you can determine the content or properties to display to users, regardless of their permissions.
• Making your Web Part connectable, allowing Web Parts to provide or access data from other connectable Web Parts.
• Interacting with the object models that are exposed in Windows SharePoint Services 3.0. For example, you can create a custom Web Part to save documents to a Windows SharePoint Services 3.0 document library.
• Controlling the cache for the Web Part by using built-in cache tools. For example, you can use these tools to specify when to read, write, or invalidate the Web Part cache.
• Benefiting from a rich development environment with debugging features that are provided by tools such as Visual Studio 2005.
• Creating a base class for other Web Parts to extend. For example, to create a collection of Web Parts with similar features and functionality, create a custom base class from which multiple Web Parts can inherit. This reduces the overall cost of developing and testing subsequent Web Parts.
• Controlling the implementation of the Web Part. For example, you can write a custom server-side Web Part that connects to a back-end database, or you can create a Web Part that is compatible with a broader range of Web browsers.
Beginning with Windows SharePoint Services 3.0, the SharePoint Web Part infrastructure is designed and built to lie on top of the Web Part infrastructure. Web Parts that inherit from System.Web.UI.WebControls.WebParts.WebPart are fully supported in Windows SharePoint Services 3.0 (with the exception of user controls as generic Web Parts), and can be used not only in applications but also in Windows SharePoint Services 3.0 applications, whether Windows SharePoint Services is involved or not. The Windows SharePoint Services WebPart class is part of an infrastructure that was designed specifically for SharePoint sites, and Web Parts that inherit from this class can be used only in SharePoint sites.
When creating new Web Parts, you have the option of creating Web Parts that inherit from System.Web.UI.WebControls.WebParts.WebPart (recommended) or Microsoft.SharePoint.WebPartPages.WebPart. The Windows SharePoint ServicesWebPart class exists primarily for the purpose of backward compatibility (Web Parts written for Windows SharePoint Services 2.0 continue to work in Windows SharePoint Services 3.0 without modification), and to provide a small set of features that are not available in the System.Web.UI.WebControls.WebParts.WebPart class.
2 How do you develop?
Beginning with Windows SharePoint Services 3.0, the SharePoint Web Part infrastructure is built on top of the 2.0 Web Part infrastructure. Web Parts that derive from the WebPart class are completely supported in SharePoint. You should create Web Parts whenever possible.
For more information about choosing the best Web Part base class from which to derive, see Creating Web Parts in Windows SharePoint Services in this SDK. For more information about Web Parts, see the in the documentation.
The general process for writing a custom Web Part is:
1. Create an Web Part assembly.
2. Place your assembly in the bin or global assembly cache.
3. (Optional) If using the bin directory, set special security attributes.
4. Add your Web Part to the SafeControls List.
5. Create a .webpart file for your Web Part.
6. Add your Web Part to a page.
For the purposes of this document, we will walk through creating a basic Web Part.
1 Create an Web Part assembly
1. Start Visual Studio 2005 and create a C# class library. Name the project MyWebPart.
2. Rename the default class1.cs file to HelloWorldWebPart.cs. This will not only rename the file but also rename the class to HelloWorldWebPart.
3. Add a reference to System.web assembly.
4. Add a using statement; using System.Web.UI.WebControls.WebParts
5. Derive the HelloWorldWebPart class from WebPart.
6. Override the Render() method. For example, for HelloWorldWebPart, use the code shown in the following code sample.
using System;
using System.Collections.Generic;
using System.Text;
using System.Web.UI.WebControls.WebParts;
namespace MyWebPart
{
public class HelloWorldWebPart : WebPart
{
protected override void Render(System.Web.UI.HtmlTextWriter writer)
{
writer.Write("Hello, World!");
}
}
}
2 Place your assembly in the bin or GAC
For the purposes of this walk through, we will place the Web Part assembly in the \bin folder of the SharePoint Web site.
1. Right-click the MyWebPart project in the solution explorer and click Properties.
2. Select the Build tab on the properties page.
3. Set the Output Path to be the \bin folder of the SharePoint Web site.
4. Compile the solution. The Web Part assembly will be built in the \bin folder of the SharePoint Web site.
3 (Optional) If using the bin folder, set special security attributes
By default, code access security permissions for the bin directory are low; only pure execution is allowed. Although the sample in this walkthrough can run with the minimal trust level, in most cases you need to elevate these permissions to make your assembly run correctly, for example, if your Web Part requires access to the SharePoint object model.
There are two ways to elevate permissions:
• (Recommended) Create a new trust policy file, and point the Web.config file at the new file. This option is more complicated but it gives you a precise attribution of permissions for your Web Parts. For more information about trust policy files, see Microsoft Windows SharePoint Services and Code Access Security.
• Raise the net trust level of the bin directory. In the Web.config file in the Web application root, there is a tag called that has a default attribute of level="Windows SharePoint Services_Minimal". You can change this level to Windows SharePoint Services_Medium. While this option is simpler, it grants arbitrary new permissions you might not need and is less secure than creating a new trust policy file.
4 Register the Web Part as a safe control
1. Open Web.config from the application root of the SharePoint Web site.
2. Locate the section.
3. Add a entry for the Web Part developed.
5 Add the Web Part to the Team Site Gallery
1. Navigate to , where server is the name of the server where SharePoint is deployed.
2. Locate and select the MyWebPart.HelloWorldWebPart check box.
3. Click Populate Gallery to add the Web Part to the Team Site Gallery.
6 Add a Web Part to a page
1. Navigate to a page where you want to add the Web Part.
2. Click Site Actions and select Edit Page.
3. In the Web Part zone, click where you want to add the new Web Part, click Add Web Part.
4. From the list, select the MyWebPart.HelloWebPart Web Part.
5. Click Exit Edit Mode, and you are done.
You can also use project templates included in Visual Studio 2005 extensions for Windows SharePoint Services 3.0 to speed your Web Part development. For a detail description of this, see .
3 How do you debug?
Web Part assemblies are fundamentally Web controls. The high-level steps in debugging them are:
1. Set breakpoints.
2. Attach to the process.
3. Step into the code.
1 Setting breakpoints
1. Open Visual Studio and the Web Part solution.
2. Ensure that the Output Path of the solution is in the \bin folder of the Web site. If not, go to project properties and change the Output Path to be the \bin folder of the Web site.
3. Build the Web Part if not already built.
4. Ensure that the Web Part assembly is registered as a safe control in the Web.config for the Web site.
5. Set breakpoint where desired.
2 Attaching to the process
1. Set up the Web Part in any page in the SharePoint site.
2. Attach to the process.
a. On the Debug menu click Attach To Processes….
b. Select the Show process in all sessions check boxes.
c. Look for the w3wp.exe process and click Attach, and you are ready to debug.
3 Step into the code
1. Request the page with the target Web Part in it. When the page and the Web Part renders, depending on where you have set the breakpoint, the execution will stop and switch over to Visual Studio.
2. Step through the code as required.
3 Developing SharePoint Web applications
1 Why would you need to develop this?
The Microsoft.SharePoint and Microsoft.SharePoint.Administration namespaces provide types and members that can be used with lists and sites, as well as to manage a server or collection of servers that is running Windows SharePoint Services 3.0.
You can use the classes in these namespaces to gain access to all the other classes to work with lists and Web sites, to manage servers, and to manage the entire deployment. Starting with one of these classes, you can work through the object model to the class that you need to use. Developing a custom SharePoint Web application gives you complete freedom and flexibility in designing a Web site that can run under the SharePoint context and yet be designed outside of SharePoint.
The Visual Studio 2005 integrated development environment (IDE) offers the premier environment for customizing a Web site based on Windows SharePoint Services 3.0. You can create, for example, Windows applications, console applications, or class libraries, as well as Web applications (or Web sites) and Web services that implement the Windows SharePoint Services object model. You run code that uses namespaces of the Microsoft.SharePoint assembly on the server running the deployment, while applications that use SharePoint Web services run remotely from a client computer.
2 How do you develop?
The fundamental steps in creating a Web application to run under the context of SharePoint are:
1. Create the site project.
2. Customize the site to co-exist with SharePoint.
3. Add a reference to Microsoft.SharePoint.dll.
4. Add and modify the Web form to suit the need.
1 Create a Web site
1. To customize Windows SharePoint Services 3.0 through its object model or Web services, you must use Visual Studio 2005, not an earlier version.
2. Create a new Web site project under
a. For Language select C#.
b. For location, select File System and use \\Program Files\Common Files\Microsoft Shared\Web server extensions\12\TEMPLATE\LAYOUTS\ folder.
c. Name the site as MyWebSite and click OK. You can use the \\Program Files\Common Files\Microsoft Shared\Web server extensions\12\TEMPLATE\LAYOUTS\ as existing site and develop your custom .aspx pages here. We prefer to have our custom .aspx pages in a separate folder named MyWebSite.
d. For a detailed description of this, see .
2 Co-exist with SharePoint
For an application to co-exist with SharePoint, you must modify the Web.config file of the application. For more information, see . The steps are:
1. Exclude the path of the application from Windows SharePoint Services 3.0.
2. Clear out the handler used in Windows SharePoint Services, and specify the default handler for all pages.
3. Adjust the trust level.
4. Enable the session module.
An alternative method to do this, simply copy and overwrite the Web.config file from \\Program Files\Common Files\Microsoft Shared\Web server extensions\12\TEMPLATE\LAYOUTS\ to \\Program Files\Common Files\Microsoft Shared\Web server extensions\12\TEMPLATE\LAYOUTS\ MyWebSite.
3 Add a reference to Microsoft.Sharepoint.dll
To add a reference to the Microsoft.SharePoint assembly:
1. In Solution Explorer, right-click the MyWebSite project, and then click Add Reference on the shortcut menu.
2. On the .NET tab of the Add Reference dialog box, select Windows SharePoint Services in the list of components, and then click OK.
4 Add or modify a Web form
You can create a new form or modify the Default.aspx form or add another Web form. For the purposes of this walkthrough, we will modify the Default.aspx page that was created when we created the new Web site.
1. In Design view, use the Toolbox to add a label, and a button to Default.aspx. To open the Toolbox, click Toolbox on the View menu.
2. Open the code-behind file named Default.aspx.cs by double-clicking the button you created.
3. Add the using statements at the top of the file, as shown in the following code sample.
using Microsoft.SharePoint;
using Microsoft.SharePoint.Utilities;
using Microsoft.SharePoint.Administration;
using System.Text;
4. Add the following function to the class. The function uses SharePoint object model to query and fetch information about a SharePoint Web application.
protected void GetWebInfo()
{
StringBuilder sb = new StringBuilder();
try
{
SPFarm mySPFarm = SPWebService.ContentService.Farm;
SPServerCollection mySPServerCollection = mySPFarm.Servers;
SPWebApplicationCollection mySPWebAppCollection = SPWebService.ContentService.WebApplications;
if (mySPWebAppCollection != null)
{
foreach (SPWebApplication mySPWebApp in mySPWebAppCollection)
{
sb.Append("\nWebApplication: " + mySPWebApp.Name);
sb.Append("\n AppPool: " + mySPWebApp.ApplicationPool.Name + " (" + mySPWebApp.ApplicationPool.Status + ")");
SPContentDatabaseCollection mySPContentDBCollection = mySPWebApp.ContentDatabases;
sb.Append("\n # Content DBs: " + mySPContentDBCollection.Count);
foreach (SPContentDatabase mySPContentDB in mySPContentDBCollection)
{
sb.Append("\n Database Name: " + mySPContentDB.Name);
sb.Append("\n Database Server: " + mySPContentDB.Server);
sb.Append("\n DSN: " + mySPContentDB.DatabaseConnectionString);
}
sb.Append("\n\n");
}
}
}
catch (Exception ex)
{
Label1.Text = "Error: " + ex.Message;
}
Label1.Text = sb.ToString();
}
5. For the button event handler add the following code to invoke the GetWebInfo() function when the button is clicked.
6. To run the code added in the previous step and avoid receiving an access denied error message, the user executing the GetWebInfo() method must have Full Control permission.
7. Add the following code to the Button1_Click event handler, which uses the RunWithElevatedPrivileges method to grant the current user appropriate permissions.
SPSecurity.CodeToRunElevated elevatedGetWebInfo = new SPSecurity.CodeToRunElevated(GetWebInfo);
SPSecurity.RunWithElevatedPrivileges(elevatedGetWebInfo);
8. You are now ready to run the form. Save all your changes and navigate to the form by using the URL where is the name of your server.
9. When the form is rendered, click the button to get the Web information.
3 How do you debug?
The high level steps in debugging them are:
1. Set breakpoints.
2. Attach to the process.
3. Step into the code.
1 Setting breakpoints
1. Open Visual Studio and the Web site solution.
2. Set breakpoints where desired.
2 Attaching to the process
Attach to the process
1. On the Debug menu, click Attach to Processes….
2. Select the Show process in all sessions check boxes.
3. Look for the w3wp.exe process, and click Attach, and you are ready to debug.
3 Step into the code
1. You are now ready to run the form. Save all your changes and navigate to the form using the URL where is the name of your server. When the page request is processed, depending on where you have set the break point, the execution will stop and switch over to Visual Studio.
2. Step through the code as required.
4 Developing custom HTTP modules
1 Why would you need to develop this?
When you think of an application you generally think of a Web site with .aspx pages. In most situations, this is all that is required for developing a Web application. Yet there are situations where you want to tap into the underlying infrastructure of to provide custom handling of HTTP requests. The framework provides a flexible HTTP pipeline-based model that can be used to extend HTTP request processing – both preprocessing and postprocessing. Intercepting HTTP requests and providing custom hooks to alter the course of default action can be achieved by using HTTP modules.
An HTTP module is an assembly that is called on every request made to your application. HTTP modules are called as part of the request pipeline and have access to life cycle events throughout the request. HTTP modules give you the opportunity to examine incoming requests and take action based on the request. They also give you the opportunity to examine the outbound response and modify it.
HTTP modules are similar to ISAPI filters in that they run for all requests. However, they are written in managed code and are fully integrated with the life cycle of an application. They act as content filters and are integral part of .
Typical uses for HTTP modules include:
• Security. Because you can examine incoming requests, your HTTP module can perform custom authentication or other security checks before the requested page, XML Web service, or handler is called.
• Statistics and logging. Because HTTP modules are called on every request, you can gather request statistics and logging information in a centralized module, rather than in individual pages.
• Custom headers or footers. Because you can modify the outbound response, you can inject content such as custom header information into every page or XML Web service response.
• Redirection. Because you can intercept the incoming message and examine it, you can also take the decision of redirecting the URL.
2 How do you develop?
Developing a HTTP module is fairly straight forward. An HTTP module class implements the IHttpModule interface and typically will set up event handlers for preprocessing or postprocessing or both. You can create a custom HTTP module by creating a class that implements the IHttpModule interface and then registering it in the Web.config file. The general process for writing an HTTP module is:
1. Create a class that implements the IHttpModule interface.
2. Write a handler for the Init method. Your init method should initialize your module and subscribe to any application events you need. For example, you might subscribe to the EndRequest event if you want to append something to responses, or you might subscribe to the AuthenticateRequest event if you wish to perform custom authentication logic. For more information on application events, see Application Life Cycle Overview.
3. Write code for the events you have subscribed to.
4. Optionally implement the Dispose method if your module requires cleanup.
5. Register the module in the Web.config file.
1 Create a class that implements an IHttpmodule
1. Start Visual Studio 2005 and create a C# class library. Name the project MyHttpModule.
2. Rename the default class1.cs file to HelloWorldHttpModule.cs. This will not only rename the file, but also rename the class to HelloWorldHttpModule.
3. Add a reference to System.web assembly.
4. Add a using statement; using System.Web.
5. In your HelloWorldHttpModule, implement the interface IHttpModule.
2 Write a handler for Init()
1. In the Init() method add event handlers to the application object as required.
2. Use the BeginRequest for pre-processing and EndRequest for postprocessing.
3 Write event delegates
Implement the event handler delegates to do your processing.
4 Dispose of resources
Use the Dispose() method to cleanup resources as required.
5 Register the module in the Web.config file
1. Open the Web.config file from the application root of the SharePoint Web site.
2. Locate the section.
3. Add an entry for the HttpModule developed, as shown in the following code sample.
4. Add code for HelloWorldHttpModule, as shown in the following code sample.
using System;
using System.Collections.Generic;
using System.Text;
using System.Web;
namespace MyHttpModule
{
public class HelloWorldHttpModule : IHttpModule
{
#region IHttpModule Members
public void Dispose()
{
return;
}
public void Init(HttpApplication application)
{
application.BeginRequest += new EventHandler(application_BeginRequest);
application.EndRequest += new EventHandler(application_EndRequest);
}
void application_EndRequest(object sender, EventArgs e)
{
HttpApplication application = (HttpApplication)sender;
HttpContext context = (HttpContext)application.Context;
//
// add post-procesing logic here
//
return;
}
void application_BeginRequest(object sender, EventArgs e)
{
HttpApplication application = (HttpApplication)sender;
HttpContext context = (HttpContext)application.Context;
//
//add pre-processing logic here
//
return;
}
#endregion
}
}
3 How do you debug?
HttpModules are essentially .NET class libraries. The high-level steps in debugging them are:
1. Set breakpoints.
2. Attach to the process.
3. Step into the code.
1 Setting breakpoints
1. Open Visual Studio and the Web Part solution.
2. Ensure that the Output Path of the solution is in the \bin folder of the Web site. If not go to project properties and change the Output Path to be the \bin folder of the Web site.
3. Build the HttpModule if not already built.
4. Ensure that the Web Part assembly is registered as a safe control in the Web.config file for the Web site.
5. Set breakpoints where desired.
2 Attaching to the process
Attach to the process:
1. On the Debug menu click Attach To Processes….
2. Select the Show process in all sessions check boxes.
3. Look for the w3wp.exe process and click Attach, and you are ready to debug.
3 Step into the code
1. Request any page from the site where you added the HttpModule. When the page request is processed, depending on where you have set the break point, the execution will stop and switch over to Visual Studio.
2. Step through the code as required.
Appendix (from popular blogs)
To configure Active Directory to be in the list account mode, the following script can be used.
1 EnableListObjectMode.vbs
'*******************************************************************' THIS CODE AND INFORMATION IS PROVIDED TO YOU FOR YOUR REFERENTIAL
' PURPOSES ONLY, AND IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
' KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO
' THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A
' PARTICULAR PURPOSE, AND MAY NOT BE REDISTRIBUTED IN ANY MANNER.
'
' Copyright (c) 2006 Microsoft Corporation. All rights reserved.
'*******************************************************************
Dim sDomainDN
Dim configObjectDN
Dim configObject
Dim heuristics
Dim newHeuristics
' Bind to the root of the Domain
Set rootDSE = GetObject("LDAP://RootDSE")
' Get the default NamingContext
sDomainDN = rootDSE.Get("defaultNamingContext")
' Set AD to List Object Mode
configObjectDN = "LDAP://CN=Directory Service,CN=Windows NT,CN=Services,"
configObjectDN = configObjectDN & rootDSE.Get("configurationNamingContext")
Set configObject = GetObject(configObjectDN)
GetHeuristics
write "Current DSheuristics: " & heuristics
newHeuristics = Left(heuristics, 2)
newHeuristics = newHeuristics & Left("00", 2-Len(newHeuristics))
newHeuristics = newHeuristics & "1"
Write "New DSheuristics: " & newheuristics
If Len(heuristics) > 3 Then
newHeuristics = newHeuristics & Right(heuristics, Len(heuristics)-3)
End If
configObject.Put "dSHeuristics", newHeuristics
configObject.SetInfo
Function write(strToWrite)
WScript.Echo strToWrite
End Function
Sub GetHeuristics
On Error Resume Next
heuristics = configObject.Get("dSHeuristics")
If Err Then
If Err.Number = &H8000500D Then
' no error -- the dSHeuristics attribute was just unset
heuristics = ""
Else
WScript.Echo Err.Description
WScript.Quit(1)
End If
End If
End Sub
2 Setting up account creation mode – Screen shots
On the Installation Type page, click the Advanced button to continue.
[pic]
1. On the Server Type page, select Web Front End, and click Install Now.
2. When the installation completes, click the Close button.
3. The SharePoint Products and Technologies Configuration Wizard will launch automatically. Click Next.
4. An information dialog box will appear indicating that some services will be restarted during configuration. Click the Yes button.
5. On the Connect to a server farm page, select No, I want to create a new server farm and then click Next.
6. On the Configuration Database Settings page, enter the following:
• Database server:
• Database name:
• Username:
• Password:
7. Click the Next button.
8. Note: in a production environment
9. On the Configure SharePoint Central Administration page, select the Specify port number if you would like a specific port number. Otherwise, accept the defaults and click the Next button.
10. On the Completing the SharePoint Products and Technologies Configuration Wizard page, click the Advanced Settings button.
11. 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 the OK button.
12. On the Completion page, click Next.
13. The Configuration Successful page will appear. Click Finish to launch the Central Administration page.
14. When the Central Administration application launches, verify that you have installed Beta 2 Technical Refresh by navigating to Site Actions -> Site Settings.
[pic]
15. Create a new Web application by going to Application Management and clicking the Create or extend Web application link.
[pic]
16. On the next page, click Create a new Web application.
17. 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 under either select your Predefined security account, or specify the name of the account to be configured. Keep all other defaults, and click OK.
18. The Application Created page will appear.
19. While in Central Administration, navigate to the Operations tab. Select the Outgoing e-mail settings link.
20. On the Outgoing E-Mail Settings page, specify the SMTP server name and the From and Reply-to addresses. Then click OK.
3 What happened to Smigrate.exe? What if I only want to upgrade one site? What can I do now with Stsadm.exe?
The Three Upgrade Methods -
Gradual
You can choose individual sites to be upgrade when running both versions of the product on the same farm/server. This would give you control of choosing which sites are upgraded and when.
Database Attach
Back up and restore a site into its own database (steps referenced below in TechNet section) then attach the content database into the farm you want it to belong to.
In Place
You could make a copy of your entire environment (could be on a virtual server) then upgrade in place, finally delete all the sites you do not need. Not sure if that is useful. If you only want to upgrade a single site from a 2.0 farm to a 3.0 farm, the database attach is the easiest.
Migration
Some thought of the smigrate utility as being the tool for migrating subsites (also known as webs). You can now do full fidelity (including security) site collection and subsite backups with stsadm. For full usage type from your /bin directory.
stsadm -help export
[stsadm -o export -url URL -f filename]
stsadm -help import
[stsadm -o import -url URL -includesecurity]
(more details below)
The following is an edited snippet from the MSDN documentation:
Ways to Use the Content Migration APIs
There are three ways you can invoke the Content Migration APIs.
1. stsadm.exe
• Using the stsadm utility, you can use the import and export operations to migrate data.
2. SOAP
• You can use the ExportWeb and ImportWeb methods implemented in the Sites Web service to migrate data from a remote server.
3. Content Migration object model [The Richest if you have dev resources]
• The object model provides the most control over your data migration scenarios. Using the object model, you can migrate anything, from a Web site to an item in a list, or a single document in a library. You can choose whether to include information about security, versioning, user roles, and other metadata appropriate to the objects you are migrating. The Content Migration object model is implemented in the Microsoft.SharePoint.Deployment namespace.
The following is a snippet from TechNet:
Migrate content by using import/export
The import/export feature is based on the new Content Migration APIs. With import/export, you can migrate either subsites or entire site collections, and you can import a subsite into an existing site collection. Like the Smigrate.exe utility in the previous version, import/export requires that the site that you import to already exists. Note that import/export does not include some site settings, such as Recycle Bin state and alerts. For more information about what settings are preserved during import/export, see . To use import/export to migrate a site, you would use the following process:
|1.|Export the subsite or site collection (stsadm.exe -o export -url URL). |
|2.|In Central Administration, on the Manage Content Databases page, set all databases except the one that currently contains the |
| |subsite or site collection to offline. |
|3.|Create the site collection to contain the content you are importing (only if importing an entire site collection). |
|4.|Import the subsite or site collection (stsadm.exe -o import -url URL -includeusersecurity). |
| |The includeusersecurity parameter specifies that you want to import the security settings for the subsite or site collection. If |
| |you do not need the security settings, you can omit this parameter. |
Migrate content by using backup/restore
You could backup a site collection, then delete the site collection, set the manage content databases to take the current database offline (or set the capacity to the content database you want the site in so that it has more capacity than the other content databases, and then restore the site to original URL and that would get the site collection in the new database. The main thing to note is that this feature is at the site collection level so would not be an option for moving subsites around. This feature can restore a site collection to a new name and the site cannot already exist unless you are using the –overwrite option to restore over an existing site. To use backup/restore to migrate a site collection, you would use the following process:
|1.|Back up the subsite or site collection (stsadm.exe -o backup -url URL). |
|2.|In Central Administration, on the Manage Content Databases page, set the database that currently contains the subsite or site |
| |collection to offline. |
|3.|Restore the site collection (stsadm.exe -o restore -url URL). |
For more information about using backup/restore, see Office SharePoint Server 2007 Backup and Restore .
With Office SharePoint Server 2007, you can migrate sites, subsites, or specific lists/libraries or items/documents by using the content deployment capability. This method is as easy as specifying the content to deploy and the target for the deployment, and then starting the deployment process. For more information about content deployment, see the Content Deployment Administration section at RTM.
4 Capacity planning
A very through capacity planning data is presented at:
We encourage our readers to review the articles listed on TechNet.
5 Important references
Stsadm.exe command-line utility:
Setup.exe command-line reference:
Command-line reference for the SharePoint Products and Technologies Configuration Wizard:
Config.xml reference:
6 Feature comparisons in SharePoint Search versions
The following is from Mike Tag’s blog:
What is the difference in features in Windows SharePoint Services 3.0, Office SharePoint Server 2007, and Office SharePoint Server 2007 for Search?
One thing to note is that the Search in the three products are all based on the same Microsoft Search core indexing engine. However, there are differences between the three SharePoint search versions. This table does a comparison of features in the three products.
|Feature |Search in Windows SharePoint |Office SharePoint Server 2007 for |Enterprise Search in Office |
| |Services 3.0 |Search |SharePoint Server 2007 |
|What can be indexed |Local SharePoint content |SharePoint sites, Microsoft Exchange |SharePoint sites, Microsoft |
| | |Server content, file shares, Lotus |Exchange Server content, file |
| | |notes, custom content. |shares, Lotus notes, custom |
| | | |content, line-of-business (LOB)|
| | | |content. |
|Rich, relevant results |Yes |Yes |Yes |
|Alerts |Yes to all |Yes to all |Yes to all |
|RSS | | | |
|Did you mean? | | | |
|Collapsing of duplicates | | | |
|Best bets |No to all |Yes to all |Yes to all |
|Results removal, Query reports | | | |
|Search Center / Tabs |No |Search Center without Tabs |Search Center with Tabs |
|People search |No to all |Yes to all |Yes to all |
|Knowledge network | | | |
|Business Data Search |No |No |Yes |
|Query Web service | |
| |h.asmx | |smx |
|Security trimming of search |Yes; supports default security|Yes; supports default security |Yes; supports default and |
|results |trimming only |trimming only |custom security trimming |
|Query syntax |Windows SharePoint Services |Enterprise Search SQL Syntax Reference|Enterprise Search SQL Syntax |
| |3.0 Search SQL Syntax |Enterprise Search Keyword Syntax |Reference |
| |Windows SharePoint Services |Reference |Enterprise Search Keyword |
| |3.0 Search Keyword Syntax |Enterprise Search URL Syntax Reference|Syntax Reference |
| |URL syntax | |Enterprise Search URL Syntax |
| | | |Reference |
For more information, see this article in the Office SharePoint Server SDK:
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related searches
- school home page elementary
- xfinity home page install
- xfinity home page internet explorer
- fwisd home page for students
- xfinity home page or homepage
- xfinity home page and toolbar
- xfinity home page install for windows 10
- xfinity comcast home page website
- xfinity home page official windows 10
- comcast home page official site
- make xfinity my home page windows 10
- comcast xfinity home page email