Share via

Plan for host-named site collections (SharePoint Foundation 2010)

  • Article

 

Applies to: SharePoint Foundation 2010

In this article:

  • About host-named site collections

  • About host headers

  • Create a host-named site collection

  • Programmatically create a host-named site collection

  • Use managed paths with host-named site collections

  • Expose host-named sites over HTTP or SSL

  • Configure SSL for host-named site collections

  • Use host-named site collections with off-box SSL termination

Microsoft SharePoint Foundation 2010 supports both path-based and host-named site collections. The primary difference between path-based and host-named site collections is that all path-based site collections in a Web application share the same host name (DNS name), and each host-named site collection in a Web application is assigned a unique DNS name.

Path-based site collections provide a corporate hosting solution with all site collections sharing the same host name of the Web application. In a path-based deployment, you can have a single site collection at the root of the Web application and additional site collections under managed paths within the Web application.

Host-named site collections provide a scalable Web hosting solution with each site collection assigned to a unique DNS name. In a Web hosting deployment, each host-named site collection has its own vanity host name URL, such as http://customer1.contoso.com, http://customer2.contoso.com, or http://www.customer3.com.

SharePoint Foundation 2010 provides two significant improvements to host-named site collections: the ability to use managed paths with host-named site collections, and the ability to use off-box SSL termination with host-named site collections.

About host-named site collections

Web hosters provide customers with Web server space to host their own Web sites. In a path-based SharePoint Foundation 2010 environment, these sites would typically be assigned to https://www.contoso.com/sites/customer1, https://www.contoso.com/sites/customer2, and so on. However, Web hosting customers typically want to have their Web sites available at a vanity domain name, such as http://customer1.contoso.com, http://customer2.contoso.com, and so on.

One way to support this customer request is to provide each customer with their own Web application and assign the customer’s unique DNS name to the Web application. However, SharePoint Foundation 2010 Web applications do not scale as well as SharePoint Foundation 2010 site collections. SharePoint Foundation 2010 supports host-named site collections as an alternative to creating individual Web applications for each customer. Host-named site collections can scale to thousands of site collections because they can all exist within a single Web application and still offer vanity naming capability.

Because host-named site collections have a single URL, they do not support alternate access mappings and are always considered to be in the Default zone. If you need to support site collections responding to multiple host-name URLs, consider using path-based site collections with alternate access mappings instead of host-named site collections.There are several additional configuration options to consider when provisioning a new SharePoint Foundation 2010 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"). Also consider specifying site quotas on each newly provisioned site collection.

About host headers

Host headers refer to the portion of the HTTP protocol that tells the Web server the DNS name of the site that the client is connecting to. You can apply host headers at two different levels in SharePoint Foundation 2010:

  • The Web application (IIS Web site) level

  • The site collection level

It's important to understand the distinction between these two levels. Host headers at the IIS Web site level are only intended for path-based site collections. Host headers at the site collection level are only intended for host-named site collections. In most cases, applying a host header binding at the IIS Web site level makes it impossible to access host-named site collections through the IIS Web site. This is because IIS will not respond to requests for host names that differ from the host header binding.

Path-based site collections and host-named site collections can co-exist in the same Web application and can exist in multiple Web applications. To ensure that both types of site collections are accessible to users, do not put host header bindings on the IIS Web site assigned to the Default zone of your Web application, if you have host-named site collections in that Web application. You can apply host header bindings to the IIS Web sites in the other zones of your Web application. This enables you to use the Default zone with host-named site collections while allowing you to use alternate access mapping functionality in the other zones for path-based site collections.

You can manually modify host header bindings on the IIS Web site from the IIS Manager, but this is not recommended. Any changes you make using the IIS Manager will not be recorded in SharePoint Foundation 2010. If SharePoint Foundation 2010 tries to provision an IIS Web site on another computer in the farm for the same Web application and zone, the original host header binding is used instead of the modified binding. 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.

Create a host-named site collection

You must use Windows PowerShell to create a host-named site collection. You cannot use the SharePoint Foundation 2010 Central Administration Web application to create a host-named site collection, but you can use Central Administration to manage the site collection after you have created it.

You can create a host-named site collection by using the Windows PowerShell New-SPSite cmdlet with the -HostHeaderWebApplication parameter, as shown in the following example:

  1. To create a host-named site collection using Windows PowerShell, verify that you meet the following minimum requirements: See Add-SPShellAdmin.

  2. On the Start menu, click All Programs.

  3. Click Microsoft SharePoint 2010 Products.

  4. Click SharePoint 2010 Management Shell.

  5. From the Windows PowerShell command prompt (that is, PS C:\>), type the following:

New-SPSite http://host.header.site.url -OwnerAlias DOMAIN\username - 
HostHeaderWebApplication https://servername

This creates a host-named site collection with the URL http://host.header.site.url in the SharePoint Foundation 2010 Web application with the URL https://servername.

Programmatically create a host-named site collection

In addition to using the Windows PowerShell to create host-named sites, you can use the SharePoint Foundation 2010 object model. The following code sample creates the host-named site collection with the URL http://host.header.site.url in the SharePoint Foundation 2010 Web application with the URL https://servername:

SPWebApplication webApp = SPWebApplication.Lookup(new
Uri("https://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);

SharePoint Foundation 2010 ships with a set of Web services for various user and administrative tasks. One of these administrative tasks is creating a new site collection. The CreateSite Web service 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.

Use managed paths with host-named site collections

SharePoint Foundation 2010 adds support for managed paths with host-named site collections. Hosters can provide multiple site collections to the same customer with each site collection sharing the customer’s unique host name but differentiated by the URL path after the host name.

Managed paths for host-named site collections are different from managed paths for path-based site collections. Managed paths for host-named site collections do not apply to path-based site collections; nor do managed paths for path-based site collections apply to host-named site collections. Managed paths created for host-named site collections are available to all host-named site collections within the farm regardless of which Web application the host-named site collection is in. You must create a root host-named site collection for a host name before you can create a managed path host-named site collection for that host name.

You can create a managed path for use with host-named site collections by using the Windows PowerShell New-SPManagedPath cmdlet with the -HostHeader parameter, as shown in the following example:

New-SPManagedPath pathname -HostHeader

A host-named site collection created at a managed path is shown in the following example:

New-SPSite http://host.header.site.url/pathname/sitename -OwnerAlias DOMAIN\username -HostHeaderWebApplication https://servername

Expose host-named sites over HTTP or SSL

Host-named site collections will use the same protocol scheme as the public URL in the Default zone of their Web application. If you wish to provide the host-named site collections in your Web application over HTTP, ensure that the public URL in the Default zone of your Web application is an HTTP-based URL. If you wish to provide host-named site collections in your Web application over SSL, ensure that the public URL in the Default zone of your Web application is an HTTPS-based URL.

Unlike an earlier version, SharePoint Foundation 2010 does not support a host-named site collection using both HTTP- and SSL-based URLs simultaneously. If some host-named site collections need to be available over HTTP while other host-named site collections need to be available over SSL, separate the host-named site collections into two different Web applications dedicated for that type of access. In this scenario, HTTP host-named site collections should be in a Web application dedicated for HTTP access and SSL host-named site collections should be in a Web application dedicated for SSL access.

Configure SSL for host-named site collections

In hosting scenarios, hosters can configure a single Web application with SSL and then create multiple host-named site collections within that Web application. To browse to a site over SSL, a server certificate has to be installed and assigned to the IIS Web site. Each host-named site collection in a Web application will share the single server certificate assigned to the IIS Web site.

Hosters need to acquire a wildcard certificate or subject alternate name certificate and then use a host-named site collection URL policy that matches that 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 customers require unique second-level domain names for their sites, the hoster has to create multiple Web applications rather than multiple host-named site collections.

To configure SSL for host-named site collections, enable SSL when creating the Web application. This will create an IIS Web site with an SSL binding instead of an HTTP binding. After the Web application is created, open IIS Manager and assign a certificate to that SSL binding. You can then create site collections in that Web application.

Use host-named site collections with off-box SSL termination

Because SharePoint Foundation 2010 uses the public URL in the Default zone of the Web application to determine whether host-named site collections will be rendered as HTTP or SSL, you can now use host-named site collections with off-box SSL termination. There are 3 requirements to use SSL termination with host-named site collections:

  • The public URL in the Default zone of the Web application must be an HTTPS-based URL.

  • The SSL terminator or reverse proxy must preserve the original HTTP host header from the client.

  • If the client SSL request is sent to the default SSL port (443), then the SSL terminator or reverse proxy must forward the decrypted HTTP request to the front-end Web server on the default HTTP port (80). If the client SSL request is sent to a non-default SSL port, then the SSL terminator or reverse proxy must forward the decrypted HTTP request to the front-end Web server on the same non-default port.

To use host-named site collections with off-box SSL termination, configure your Web application as you normally would for SSL termination and ensure that it meets the requirements described above. In this scenario, SharePoint Foundation 2010 will render links of its host-named site collections in that Web application using HTTPS instead of HTTP.