Plan for host-named site collections (Windows SharePoint Services)
Updated: April 23, 2009
Applies To: Windows SharePoint Services 3.0
Topic Last Modified: 2009-04-15
In this article:
Windows SharePoint Services 3.0 supports both host-named site collections and path-based site collections. Host-named site collections provide a scalable hosting solution with distinct host names for each site collection. This means that host-named site collections have a single host-name URL. By deploying host-named site collections you can map WINS or DNS entries to site collections in Web applications.
Path-based site collections provide a corporate hosting solution with distinct host names for each Web application. In a path-based deployment, site collections are mapped to a managed path that is subordinate to the Web application. Path-based site collections and host-named site collections can exist in the same Web applications, and Web applications can contain thousands of site collections.
Path-based site collections support alternate access mapping with several different zones, each of which can have distinct WINS-mapped or DNS-mapped URLs.
Host-named site collections enable Windows SharePoint Services 3.0 to use host header names, instead of paths, to determine the site collections that users access and the content returned in response to user requests. Creating a host-named site collection enables you to host multiple site collections with vanity URLs for users. Windows SharePoint Services 3.0 automatically attempts to crawl newly created host-named site collections, if the Windows SharePoint Services 3.0 content database is associated with a Windows SharePoint Services 3.0 search instance.
For information about configuring host-named site collections with forms authentication, see Prepare to crawl host-named sites that use forms authentication.
For information about configuring host-named site collections with Basic authentication, see Prepare to crawl host-named sites that use Basic authentication.
Host-named site collections enable you to create multiple root-level site collections within a Web application. For example, administrators for hosting organizations use host-named site collections to create multiple domain-named sites. Windows SharePoint Services 3.0 allows you to have multiple domains in a single Web application. In Windows SharePoint Services 2.0, this was referred to as scalable hosting mode. Scalable hosting mode supports the placing of multiple domains, such as http://www.adatum.com, http://www.contoso.com, and so on, as separate site collections within the same Web application. In Windows SharePoint Services 3.0, host-named site collections provide the same scalable hosting functionality.
If you need to support path-based site collections responding to multiple host-name URLs, consider using alternate access mappings instead of host-named site collections. For more information about alternate access mappings, see Plan alternate access mappings (Windows SharePoint Services).
You can have host-named site collections on multiple Web applications. You can extend multiple IIS Web sites with Windows SharePoint Services 3.0. Host-named site collections support portal sites.
You can create a new site by using the stsadm.exe command-line tool. You cannot use the Windows SharePoint Services 3.0 Central Administration Web application to create a host-named site collection.
Use the stsadm.exe createsite command to create a site collection, and add the following parameter to that operation to indicate that it should be host-named instead of path-based:
-hhurl <Web application URL>
For example, if you have a Web application named www.contoso.com and you want to add a host-named site collection with the URL http://hoster.contoso.com, use the following command:
stsadm.exe -o createsite -url http://hoster.contoso.com -ownerlogin contoso\siteowner -owneremail firstname.lastname@example.org -hhurl http://www.contoso.com
Internet service providers (ISPs) configure their DNS servers to associate http://hoster.contoso.com with the appropriate IP address. For testing, you can edit your \system32\drivers\etc\hosts file to associate host-named site collections with the IP address of a server running Windows SharePoint Services 3.0. When this is configured, you can browse to http://hoster.example.com to access your site.
If you want to change the URL of a host-named site collection after it has been created, use the following command:
stsadm.exe -o renamesite
This command is available in the Windows SharePoint Services 3.0 hotfix. For more information about using the stsadm.exe -o renamesite command, see Renamesite: Stsadm operation (Windows SharePoint Services).
You do not have to specify whether you want to use host-named site collections when you create the configuration database. You can specify whether a site collection should be host-named or path-based when you create the site collection.
In addition to using the command-line tool to create host-named sites, you can use the Windows SharePoint Services 3.0 object model. The following code sample creates the same site, http://hoster.contoso.com:
SPWebApplication webApp = SPWebApplication.Lookup(new Uri("http://www.contoso.com")); SPSiteCollection sites = webApp.Sites; SPSite Site = null; Site = sites.Add("http://hoster.contoso.com", "Site_Title", "Site_Description", 1033, "STS#0", "contoso\owner", "Owner_Display_Name", "Owner_Email", "contoso\secondaryowner, "Secondary_Owner_Display_Name", "Secondary_Owner_Email", true);
You can apply host headers at two different levels:
The Web application (IIS Web site) level
The site collection level
In most cases, applying a host header at the Web application level makes it impossible to access host-named site collections. This is because IIS will not respond to requests with host names that differ from the setting in IIS. However, you can accomplish this if you configure the IIS Web site of the Default zone without a host header, and only apply host headers to the IIS Web sites in the other zones. This allows you to use the Default zone with host-named site collections, which are considered to be in the Default zone, while allowing you to use alternate access mapping functionality in the other zones for path-based site collections.
To apply host headers at the Web application (IIS Web site) level:
On the Central Administration home page, click Application Management.
On the Application Management page, in the SharePoint Web Application Management section, click Create or extend Web application.
On the Create or Extend Web Application page, in the Adding a SharePoint Web Application section, click Create a new Web application.
On the Create New Web Application page, in the IIS Web Site section, configure the host headers for your new Web application by typing the URL you want to use to access the Web application in the Host Header box.
The host header value specifies the binding to create for the IIS Web site and ensures that IIS only responds to requests sent to the specified host header. You can manually modify IIS bindings from the IIS Manager, but this is not recommended. Any changes you make using the IIS Manager will not affect Windows SharePoint Services 3.0. If Windows SharePoint Services 3.0 tries to provision an IIS Web site on another computer in the farm for the same Web application and zone, the binding specified on the Create New Web Application page is used. If you want to modify an existing binding for an IIS Web site, remove the Web application from the zone and then re-extend the Web application into the zone with the binding you want to use.
Windows SharePoint Services 3.0 ships with a set of Web services for various user and administrative tasks. One of these administrative tasks is creating a new site. The CreateSite Web method does not support the creation of host-named site collections. A workaround for this issue is to write a Web service that wraps the API sample code.
There are several additional configuration options to consider when provisioning a new Windows SharePoint Services 3.0 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 a hosting environment, consider specifying site quotas on each newly provisioned Windows SharePoint Services 3.0 Web site. Although support for site quota templates is not included in the sample Web services, you can add site quotas and use them to create a site quota template based on predetermined limits.
Working with the SQL membership provider in a hosting scenario requires some additional steps to properly configure and manage a host-named site collection. When you create any site, you need to specify a user who will be the site owner. This implies that the owner already exists as a user in your membership directory. To simplify this and other SQL membership provider tasks, use the MembershipSiteAdmin.exe tool.
|For information about downloading the MembershipSiteAdmin.exe tool, see SharePoint SQL site provider Sample Source Code http://www.codeplex.com/SharePointHosters/Release/ProjectReleases.aspx?ReleaseId=5097|
MembershipSiteAdmin.exe is a command-line tool for managing 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 Windows SharePoint Services 3.0 site.
Delete a Windows SharePoint Services 3.0 site.
Enumerate all the applications associated with a specified user, or check if a user already exists in the system or in any other application.
The process of creating or deleting a Windows SharePoint Services 3.0 site is performed by stsadm.exe. To accomplish this, stsadm.exe must have an available configuration file. MembershipSiteAdmin.exe calls custom stored procedures and the membership provider API, and wraps the stsadm.exe tool. MembershipSiteAdmin.exe maps the application name to the fully qualified domain name (FQDN) of the Windows SharePoint Services 3.0 site by calling one of the following custom stored procedures:
aspnet_Sitemaps_CreateMapping takes an application name and an FQDN as input
aspnet_Sitemaps_DeleteMapping takes an FQDN as input
You can create and delete users in the SQL membership repository by using the ASP.NET membership service API (System.Web.Security.Membership). MembershipSiteAdmin.exe calls the Membership.CreateUser method or the Membership.DeleteUser method to complete this process. The provider that is used by the membership service is specified in the App.config file (MembershipSiteAdmin.exe.config) for MembershipSiteAdmin.exe. MembershipSiteAdmin.exe uses the shipping SQL membership provider to perform these tasks, and specifies the application name to connect to the user. The MembershipSiteAdmin.exe.config file should point to the default location for the stsadm.exe file. If you have installed Windows SharePoint Services 3.0 in another location, you will need to update this application setting. Refer to the following section of the MembershipSiteAdmin.exe.config file:
<appSettings> <add key="stsadmPath" value="C:\Program Files\Common Files\Microsoft Shared\Web server extensions\12\BIN\" /> </appSettings>
You can expose host-named site collections over both HTTP and HTTPS protocols if you create the site collections on the default port. If you create site collections on any other port, each individual host-named site collection can be either HTTP or HTTPS exclusively, depending on which URL you entered with the -url parameter of the createsite command. You cannot use host-named site collections with the advanced extranet scenarios provided by alternate access mappings, such as SSL termination.
You can obtain search results over both protocols by creating one Web application for HTTP and one for HTTPS. Search will use the protocol scheme of the public URL assigned to the Default zone of the Web application to determine the type of protocol scheme that host-named site collections use. If you want the host-named site collection to be searchable over HTTP, put it in the HTTP Web application. If you want the host-named site collection to be searchable over HTTPS, put it in the HTTPS Web application.
Before configuring HTTPS, a certificate has to be applied to an IIS Web site. Therefore, HTTPS can only be configured at the Web application level in Windows SharePoint Services 3.0. In hosting scenarios, 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. Hosters need to acquire a wildcard certificate and then use a host-named site collection URL policy that matches that wildcard certificate. For example, if a hoster acquires a *.contoso.com wildcard certificate, the hoster has to generate host-named site collection URLs such as https://site1.contoso.com, https://site2.contoso.com, and so on, to enable these sites to pass browser SSL validation. However, if the requirement is to apply a unique certificate for each site, the hoster has to create multiple Web applications. Web applications are not as scalable as site collections in Windows SharePoint Services 3.0.
To configure HTTPS for host-named site collections, you must enable SSL on the Central Administration Create New Web Application page. Windows SharePoint Services 3.0 automatically assigns a port number to the Web application, but you can manually specify a different port number.
HTTPS sites can be created for account creation mode, Active Directory – domain account mode, and Active Directory forms authentication.
After the Web application is created, open IIS Manager and assign a certificate. Then create site collections and, if you are using a non-default port, make sure to specify the port number for both the –url and –hhurl parameters of the stsadm.exe –o createsite command, as shown in the following example:
stsadm.exe -o createsite -ownerlogin contoso\administrator -owneremail email@example.com -url https://www.hoster.contoso.com:443 -hhurl https://www.contoso.com:443
This topic is included in the following downloadable book for easier reading and printing:
See the full list of available books at Downloadable books for Windows SharePoint Services.