Transcript SPS Edmonton 2015x

Migrating from path-based to
host-named site collections
Vili 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-everysharepoint-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-tohost-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/enus/library/office/bb862114.aspx
Questions?