SPSiteUrl’s in SharePoint 2013
One of the new capabilities introduced with SharePoint 2013 are SPSiteUrl’s. So what is it exactly, what can you do with it and why is it so cool?
Host Named Site Collections – a glance behind
Back in 2006 SharePoint 2007 introduced the concept of Host Named Site Collections. Normally, when building sites we could specify a host name on the Web Application. Should we need to add other hosts we could extend the Web Application to one of four zones and with that add other host names. Site Collections would be then created underneath the Web Application either on an explicit or a wildcard path. There is a limitation with regard to how many Web Applications you can have on a farm, so from the scalability perspective working with Web Applications is not a great story. So in order to extend the scale of websites with their own hosts, SharePoint 2007 introduced the concept of Host Named Site Collections where you could specify a host name, other than the one of the Web Application, on the Site Collection-level.
Although Host Named Site Collections in SharePoint 2007 and SharePoint 2010 improved the scalability, they had one serious limitation: you could define only one host name which was always associated with the Default Zone. Should the underlying Web Application be extended and using other Zones with their own authentication settings or policies, we weren’t able to make use of any of that in Host Named Site Collections.
SharePoint 2013 SPSiteUrl’s
One of the new capabilities introduced with SharePoint 2013 are the SPSiteUrl’s. SharePoint 2013 allows us to define multiple hosts on every Host Named Site Collection. When defining a URL it’s always mapped to a Zone which are the same as for a Web Applications. And although there are still only 5 Zones, you can define multiple URL’s for every Zone. The great thing is that SharePoint 2013 is quite clever in how it deals with Zones and SPSiteUrl’s. If you associate an SPSiteUrl with a Zone which hasn’t been defined on the Web Application, it will be mapped to the Default Zone’s settings. If you however map it to a Zone that has been defined, all settings of that Zone will apply to that particular URL when requesting the Site Collection.
Managing SPSiteUrl’s is straight-forward and can be done using PowerShell. Three new cmdlets have been introduced for us to view, add/edit and remove SPSiteUrl’s, respectively Get-SPSiteUrl, Set-SPSiteUrl and Remove-SPSiteUrl. The great thing is that the way SPSiteUrl’s have been implemented, you can modify any of the URL’s at all times including the one you used for creating the Host Named Site Collection.
Why should you care?
The introduction of SPSiteUrl’s is great news for a few reasons. First of all we can now leverage the Zone settings of the Web Application in Host Named Site Collections. One scenario that you could think of here is having two Zones on a public-facing website: one mapped to an HTTPS URL and one to HTTP. You could map the HTTP Zone to a URL that doesn’t allow authentication and should users want to login to the site they would have to use the HTTPS URL.
Another usage scenario that you could think of is adding additional host names on a public-facing website to increase the number of concurrent downloads. By default a web browsers makes up to 5 requests in parallel to the same host. By adding additional host names to your site, such as www2.mavention.nl, you can serve a number of files using that URL having your website load faster.
Summary
Back in SharePoint 2007 and 2010 we could use Host Named Site Collections to work around the scalability limitations. The downside was the inability to benefit of the Zones configuration of the Web Application. Using the SPSiteUrl’s capability introduced with SharePoint 2013 we can now associate multiple host headers with a single Site Collection and those host headers can be mapped to Zones defined on the Web Application.