Migrating from path-based to host-named

site collectionsVili Bogdan

@vilibogdan

SPS Edmonton

About me• Consultant at • Have been working with SharePoint since 2007• Hold the MCSE: SharePoint and MCSD: SharePoint Applications

certifications, as well as the SharePoint 2010 certifications• Have been filling both IT Pro and Dev roles• Father of two young boys

Outline• Problems with path-based site collections• Advantages to host-named site collections• Disadvantages to host-named site collections• Planning a migration to host-named site collections• Migration steps, Recent migration experiences and gotchas• Resources

Microsoft (and the tech world) over the past 2 years

It is extremely tiring to keep up with the changes

Problems with path-based site collections• Only way to have sites available at different host names is to create

new web applications• Can quickly lead to exceeding the

threshold limit of 10 app pools per IIS server

• Higher resource usage (more app pools, more web apps)• More items to manage• IIS bindings• IIS logs• Web application settings

Advantages to host-named site collections• Less web applications to manage• Better resource utilization on the servers• “Resources are not used to support multiple application pools and web

applications”

• Can have a very large number of top level domain names in use• Can use a separate top-level URL for each site collection (e.g.

https://hr.contoso.com, https://legal.contoso.com, etc.)

• Can assign up to five URLs to host-named sites, including vanity URLs• Changing the URL for a site collection is easy• Set-SPSiteUrl, Remove-SPSiteUrl, Get-SPSiteUrl

Disadvantages to host-named site collections• Site collections and managed paths created using PowerShell• Some functionality doesn’t work with host-named site collections• E.g. Calendar overlays using calendars from a different site collection

• Can’t split groups of site collections into separate search content sources• Search will not work properly if you do not have a root site collection

created (path-based site collection)• Need custom solution for self-service site creation with host-named

site collections

Microsoft HNSC Recommendations• Host-named site collection architecture and deployment (SharePoint

2013)• https://technet.microsoft.com/en-us/library/cc424952.aspx

• Single web application for all site collections, including My Sites.• No mixing of host-named and path-based site collections, except for the root

site collection.

• Root site collection URL will be http://<servername> (or https://)• Search crawl account requires access to content through the Default

zone by using Integrated Windows authentication (NTLM or Kerberos)

Microsoft HNSC Recommendations (cont.)• Off-box SSL termination• Reverse proxy server must be capable of generating a custom HTTP header:

Front-End-Https: On• March 2013 PU is needed to enable apps in environments with

multiple zones

When path-based site collections are needed• Need to use Self-Service Site Creation feature• Off-box SSL termination is required, but reverse proxy cannot produce

the necessary custom HTTP header (Front-End-Https: On)• Use different application pools for the additional security they provide• Need to use different service application proxy groups

Environment details• 7 SharePoint servers: 3 Web fronts, 2 search, and 2 app• About 310 site collections• About 150 GB of content• Two larger site collections (one ~35 GB, the other ~22 GB)• A handful of site collections with their own managed metadata terms• 20-30 content types pushed from the content type hub• Custom “provisioning engine” for creating new site collections• A handful of full-trust solutions deployed

Planning a migration to HNSC• Take an inventory of the site collections in your environment:• Determine which site collections use private term sets (site-collection specific

managed metadata)• Identify search web parts

• Document web application-level settings on your existing web apps• Browser file handling settings• Throttling limits• SharePoint Designer Settings• Authentication providers

• Script most of migration steps and test in a non-production environment

Migration steps• Acquire SSL certificate(s) to cover the addresses you’ll be using• Cert issued by internal CA may be enough

• Run scripts to identify SC with managed metadata, search web parts• Back up your environment before starting the migration• Deploy SSL certificate• Create the web app to host the host-named site collections• Back up all site collections using Backup-SPSite• Restore site collections to the HNSC web app using the Restore-SPSite

cmdlet

Migration Steps• Re-bind site collections to their old MMS term groups• Change CT Hub Url in MMS• Re-publish content types from Content Type Hub• Run a full crawl• Set up HTTP to HTTPS redirection on IIS (or load balancer)• Modify search settings (web parts, result sources, etc.) that were

using path-based queries to use SSL addresses

Scripting• Script what makes sense:• Report first on usage of features

with potential problems• What can only be done by

scripting (no UI equivalent)• It may be acceptable to just

document the manual process and doing it manually

Part 1: Create the HNSC web app

Create HNSC web application

Create managed paths

Create root site collection

Pre-create the generic content databases

Part 2: Consolidate path-based web application

Back up existing path-based site collections

Restore site collections into HNSC

Part 3: Other manual work and cleanup

Additional work• Re-bind site collections to their old MMS term groups (scripted)• Change CT Hub Url in MMS (scripted)• Re-publish content types from Content Type Hub (scripted)• Run a full crawl• Set up HTTP to HTTPS redirection on IIS (or load balancer)• Modify search settings (web parts, result sources, etc.) that were

using path-based queries to use SSL addresses

Alternate approach – SPSite.Rename• February 2015 PU indicates the SPSite.Rename method can be used

to convert path-based to host-named site collections• Haven’t tested this approach yet• Todd Klindt (MVP) reports it works• API reference for SPSite.Rename indicates it CANNOT be used to

convert path-based to host-named site collections• Same API could be used to change the URL portion after the managed

path for a path-based site collection

Current engagement• All changes are operational tasks• Smaller changes at a time• Coordinate with other

departments (e.g. Communications)• Deploy, report/observe

behaviour and make adjustments

Resources• Host-named site collection architecture and deployment (SharePoint 2013) - https://

technet.microsoft.com/en-us/library/cc424952.aspx• What Every SharePoint Admin Needs to Know About Host Named Site Collections - http://

blogs.msdn.com/b/kaevans/archive/2012/03/27/what-every-sharepoint-admin-needs-to-know-about-host-named-site-collections.aspx

• Moving Path Based to Host Named Site Collections - http://blogs.msdn.com/b/kaevans/archive/2013/09/09/moving-path-based-to-host-named-site-collections.aspx

• How to Rename SharePoint 2013 Site Collections Without Prayer or Sobbing - http://toddklindt.com/blog/Lists/Posts/Post.aspx?ID=573

• February 10, 2015 update for SharePoint Foundation 2013 (KB2910928) - https://support.microsoft.com/en-us/kb/2910928

• SPSite.Rename method (MSDN) - https://msdn.microsoft.com/en-us/library/office/bb862114.aspx

Questions?