Share via

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

  • Article

 

Applies to: SharePoint Server 2013, SharePoint Foundation 2013

In this article:

  • About host-named site collections

  • About host headers

  • Create a web application for host-named site collection

  • 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

  • Configure Search for host-named site collections

  • Convert standard site collection to HNSC

  • Guidelines for using host-named site collections

  • Guidelines for using path-based site collections

Microsoft SharePoint Server 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 Server 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 Server 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 Server 2010 Web applications do not scale as well as SharePoint Server 2010 site collections. SharePoint Server 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.

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 Server 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. You can apply host header bindings to the IIS Web sites in the other zones of your Web application. You can then use the Default zone with host-named site collections while you use alternate access mapping functionality in the other zones for path-based site collections.

Important

To ensure that both types of site collections are accessible to users, do not put host header bindings on the IIS Web site that is assigned to the Default zone of your Web application.

Create a Web application for host-named site collections

If you do not intend to configure two or more IIS Web sites that share the same port number on the same server, create a Web application in the Default zone that does not apply a host header binding at the IIS Web site level.

To create a Web application that can contain host-named site collections:

  • Verify that you meet the following minimum requirements: See Add-SPShellAdmin.

    You also need to be a member of the local Administrators group on the computer running Windows PowerShell. In addition, some procedures require membership in the SQL Server fixed server roles dbcreator and securityadmin.

  • On the Start menu, click All Programs.

  • Click Microsoft SharePoint 2010 Products.

  • Click SharePoint 2010 Management Shell.

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

    New-SPWebApplication -Name "HNSC01" -ApplicationPool ContosoAppPool -ApplicationPoolAccount (Get-SPManagedAccount "DOMAIN\jdoe")

Create multiple Web applications with host-named site collections

To run multiple Web applications on the same server and port in combination with host-named site collections, different IP addresses must be assigned to the Web applications. This makes it possible to run multiple Web applications on the same server and port. This type of deployment requires that you add IP addresses to the Web servers and configure the network router to point host names to the IP address of its Web application.

Note

A Web application can be created without the host header. If you create a Web application that does not have a host header, you cannot create multiple Web applications with host-named site collections on the same Web server.

To create a Web application for a host-named site collection:

  • Add a new virtual IP address to the existing Web server.

    Add a virtual IP address to each Web server in the farm.

  • To create a Web application by using Windows PowerShell, verify that you meet the following minimum requirements: See Add-SPShellAdmin.

  • On the Start menu, click All Programs.

  • Click Microsoft SharePoint 2010 Products.

  • Click SharePoint 2010 Management Shell.

  • Create the Web application. From the Windows PowerShell command prompt (that is, PS C:\>), type the following:

    New-SPWebApplication -Name "HNSC01" -Port 80 -HostHeader http://HNSC01.contoso.com -URL -ApplicationPool ContosoAppPool -ApplicationPoolAccount (Get-SPManagedAccount <server>\<user>)

    Repeat this step to create all the Web applications that you require.

  • To change IP address on IIS by using Windows PowerShell, verify that you meet the following minimum requirements: Microsoft.Web.Administration Namespace (https://msdn.microsoft.com/en-us/library/microsoft.web.administration(VS.90).aspx).

    Note

    The IP bindings must be applied on all servers which will host the Web application. Set the sleep command to 60 seconds to make sure that the IP bindings are set to all servers in the farm before the existing host header on the Web application is removed. Remote scripting can be used for this job.

  • Use the following commands to add unique IP bindings to each of the Web applications that you created and then remove the host header binding from these Web applications.

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

    Import-Module WebAdministration
# add empty binding to HNSC01 on IP 192.168.10.20
New-WebBinding -Name "HNSC01" -IPAddress "192.168.10.20" -HostHeader '' 
Sleep 60
# remove existing binding HNSC01.contoso.com from existing web application
Get-WebBinding -Name "HNSC01" -HostHeader "HNSC01.contoso.com" | Remove-WebBinding

Create a host-named site collection

You must use Windows PowerShell to create a host-named site collection. You cannot use the SharePoint Server 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://portal.contoso.com" -HostHeaderWebApplication "http://HNSC01.contoso.com" -Name "Portal" -Description "Customer portal" -OwnerAlias "contoso\administrator" -language 1033 -Template "STS#0"

This creates a host-named site collection with the URL http://host.header.site.url in the SharePoint Server 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 Server 2010 object model. The following code sample creates the host-named site collection with the URL http://host.header.site.url in the SharePoint Server 2010 Web application with the URL https://servername:

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

Note

All limitations for managed paths on host-named site collections apply for path-based site collections.

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

Remove an existing managed path use by using the Windows PowerShell Remove-SPManagedPath cmdlet, as shown in the following example:

Remove-SPManagedPath pathname -HostHeader

Note

A managed path can be removed by using Windows PowerShell even if a site collection exists. If a managed path is removed the site collection can no longer be accessed. To access the existing site collection the managed path must be recreated by using Windows PowerShell.

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.

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 Server 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 Server 2010 will render links of its host-named site collections in that Web application using HTTPS instead HTTP.

Configure Search for host-named site collections

All host-named site collections in a Web application can be searched only if a root site collection is in place. The root site collection can be created automatically when the host-named site collection is created. The root site collection does not need to be created by using Windows PowerShelland does not need to have the HostHeaderWebApplication parameter set.

The following example shows an empty site collection that is created on the root site collection:

New-SPSite "http://HNSC01.contoso.com" -HostHeaderWebApplication "http://HNSC01.contoso.com" -Name "Portal" -Description "Portal on root" -OwnerAlias "contoso\administrator" -language 1033 -Template "STS#0"

Only the root site collection appears in the content source. Although the host-named site collection does not appear in the content source, by default each host-named site collection is automatically crawled.

Note

As a best practice, have a root site collection in place that users cannot access.

If you have a SharePoint farm that has multi-crawl target front-end Web servers (WFEs), set up a search crawl for the farm by enabling the crawl target feature. In this case, the host header site collections are not crawled by using the crawl target WFEs. Instead, the search uses Domain Name System (DNS) to resolve the crawl target WFEs.

Note

By default, the crawl target feature is not used for host header site collections. This feature is controlled by the search application setting AllowHostHeaderCrawlTarget.

The following scenario describes the effect of this issue:

  • You check out a binary large object (BLOB) file from a document library in a SharePoint Server 2010 site.

  • You make changes to the file and save the file.

  • You select the Undo Check Out option to cancel the checkout.

  • You save the file as a minor version.

    In this scenario, the page of the BLOB file that uses CSS styles cannot be rendered.

To resolve this issue, apply the SharePoint Server 2010 Cumulative Update Server Hotfix Package (MOSS server-package): December 31, 2010.

Convert standard site collections to host-named site collections

Standard site collections can be converted to host-named site collections and host-named site collections can be converted to standard site collections, only through backup and restore by using Windows PowerShell. Site collections cannot be converted by using the SharePoint Central Administration Web site or by using Windows PowerShell 2.0 commands to attach and detach, or mount and dismount content databases.

The following example converts a standard site collection to a host-named site collection:

Backup-SPSite -Identity 'http://portal.contosoOld.com' -Path 'c:\Backup\portalContoso.bak' -Force -UseSQLSnapShot

Restore-SPSite -Identity 'http://portal.contoso.com' -Path 'c:\Backup\portalContoso.bak' -DatabaseName 'portal_content' -Force -HostHeaderWebApplication 'http://HNSC01.contoso.com' -Confirm:$false

Guidelines for using host-named site collections

The following is a summary of the considerations and guidelines for using host-named site collections.

  • Alternate Access Mappings are not supported for host-named site collections.

  • Host-named site collections are created by using Windows PowerShell.

  • Managed paths are shared across all hosting Web applications. Managed paths for use with host-named site collections must be created by using Windows PowerShell.

  • If a managed path that is used with a host-named site collection is removed by using Windows PowerShell, the host-named site collections under the managed path that was removed can no longer be accessed. To access the host-named site collections that were under a managed path, the manage path must be recreated.

  • If an existing Web application has a host header binding set, IIS will not return pages from the host-named site collection until the binding is removed from IIS.

  • A host-named site collection can be searched only if it is on a root host-named site collection.

  • Standard site collections can be converted to host-named site collections and host-named site collections can be converted to standard site collections, only through backup and restore by using Windows PowerShell.

Guidelines for using path-based site collections

The following is a summary of the considerations and guidelines for using path-based site collections.

  • Use path-based site collections if you want the additional security provided by multiple Web applications that use separate application pools.

  • You must use the self-service site creation feature that is included with SharePoint Server to create path-based site collections.

    MySite should be created as a path-based site or a custom solution should be provided.

  • Unique wild card inclusions are required within a Web application.

    You can create unique wild card inclusions for each Web application, but wildcard inclusions are shared across all host-named sites.

See Also

Other Resources

Resource Center: Architecture Design for SharePoint Server 2010