\n<\/p>\n
<\/h2>\n
<\/p>\n
Host header webapps in SharePoint 2010<\/h2>\n
For the readers not already familiar with host headers, we\u2019ll start with a bit of history. Previous version of SharePoint have been constantly redesigned, as we all know so well. Building towards Office 365 \/ SharePoint Online, Microsoft had to overcome some challenges serving multiple customers from the same farm.<\/p>\n
To be able to share a farm, Microsoft introduced the notion of site subscriptions <\/em>in SharePoint 2010. This was an evolution of something called \u201cscalable hosting mode\u201d which was in the product since SharePoint 2003. A site subscription is a 1-n relation between a subscription and site collections. Together with subscription aware<\/em> service applications, this allows us to provide seemingly \u201cseparate\u201d environments to multiple tenants within a single farm. \u201cSeparate\u201d, since they still share things on a technical level.<\/p>\n <\/p>\n But what about the site collection URL\u2019s? Traditionally, a path-based<\/em> SharePoint URL pointing to a site collection consists of the following parts (figure 1):<\/p>\n This imposes a problem, since Microsoft wanted to give tenants the option to configure their own URL\u2019s, instead of having to use a predetermined one. So for that purpose, they introduced the host header web application. Within the host header web application, we can create site collections which have their own URL bound to them. This is done via PowerShell by specifying the HostHeaderWebApplication parameter for New-SPSite:<\/p>\n Listing 1: Creating a host named site collection in SharePoint 2010<\/em><\/p>\n So now we can run multiple sites within the same web application, all having different URL\u2019s. Cool!<\/p>\n <\/p>\n Microsoft doesn\u2019t have a brilliant track record when it comes to naming things. In my opinion this is another example of how things can become confusing. The important things to know are:<\/p>\n But fine; whether is host header or host name, the goal is to provide site collections with their own URL\u2019s, instead of using the web applications\u2019 URL.<\/p>\n <\/p>\n There is a pretty elaborate article on how to set up host named site collections on TechNet[i], so I\u2019ll won\u2019t go into details in this article. The basic steps are:<\/p>\n <\/p>\n Alongside the above mentioned per-site collection URL\u2019s, we can also create host named site collections with a managed path. This too can only be done via PowerShell, with the New-SPManagedPath cmdlet specifying the \u2013HostHeader parameter.<\/p>\n Suppose you want to create portal.consoto.com\/departments\/marketing, you would configure:<\/p>\n <\/p>\n As said in the introduction, Microsofts official advice is now to use host named site collection by default. Also, they advise us to place those site collections in one single web application. The reason behind this is quite simple: they use the same approach themselves in Office 365. That automatically means it\u2019s the best tested option by default, and Microsoft will invest more time into making it work brilliantly opposed to the traditional method of creating site collections (which is not used within Office 365).<\/p>\n A second advantage is that a host named site collection is very portable. Since the URL is now bound to the site collection, you can move the entire thing without changing the URL of the content. So users can view their pages, lists and documents regardless of the web application or farm the site collection is in. That also implies you can move sites towards the cloud and back without users even noticing the difference. That is, of course, based on the assumption you\u2019ve got things like authentication set up properly. And moving stuff to the cloud is what Microsoft likes.<\/p>\n But is it all truly amazing, or are there considerations to be made?<\/p>\n <\/p>\n To start with; there\u2019s migration. Companies coming from SharePoint 2010 will probably not have an architecture with host named site collections. So moving towards this architecture means you\u2019ll have to rethink your URL\u2019s and some of them will most likely change, breaking content links.<\/p>\n Also, your IT decision makers might wonder: what\u2019s the real benefit here? Apart from the testing and commitment already mentioned, your sites are just as fine without their own host name. Sure, some of the new bits in 2013 will not work without hacking, like the request management service. But for most companies, the functionality they use on a day-to-day basis will be just fine. So one might wonder: why go through all the trouble?<\/p>\n <\/p>\n There\u2019s also the matter of governance. A web application comes with settings. For instance; there\u2019s a link between a web application and the service application proxy group it\u2019s using. So when your requirements are dictating different sites need different service application instances; one web application isn\u2019t feasible. You can easily check out the settings per web application in Central Administration to make a list of governance issues when it comes to using a single web application.<\/p>\n Also, your company might have processes in place which automate the site creation workload. When there is a self-service system facilitating the creation of site collections, take into account that this will need to be changed as well.<\/p>\n <\/p>\n Another issue arises when you want to make use of SSL certificates. It is possible to use SSL, but that requires we make use of wildcard certificates (*.contoso.com). Host named site collections would have to be named site1.contoso.com, site2.contoso.com, etc. to pass the browser validation. Think of your sites in SharePoint online, which are hosted on https:\/\/tenant.sharepoint.com<\/a>, where *.sharepoint.com will be the wildcard SSL certificate used.<\/p>\n When you want to use more than one certificate for different second level domain names, creating multiple web application is the only option you\u2019ve got.<\/p>\n <\/p>\n Using alternate access mappings on web application level becomes pointless when you’re using host named site collections. Since each site collection is bound to a URL, the AAM configured on the web application level don’t really matter any more. Instead, the Set-SPSiteUrl Powershell cmdlet can be used to add more than one URL to the same site collection. This requires good planning and I would advise only using it when you’ve got a real good reason to.<\/p>\n <\/p>\n As so often with SharePoint, it\u2019s a matter of: it depends. It depends whether you want to spend the time setting this up. Whether you want to use the 2013 bits which require this architecture. Whether you need the governance of settings which you cannot get with this architecture. Whether you care about Microsoft testing this and telling us \u201cit\u2019s the future\u201d. Etcetera.<\/p>\n There\u2019s a lot of speculation about the future of SharePoint. And although Microsoft is pushing the cloud, many believe that on-premises will be getting its share of loving at the upcoming SPC in 2014. So maybe the traditional web application model won\u2019t be so deprecated after all, who knows? But for newly built SharePoint 2013 installations, it might be worthwhile at least considering the option of host named site collections.<\/p>\n <\/p>\n For everyone who considers implementing host named site collections, I recommend the following articles:<\/p>\n With SharePoint 2013, Microsoft claims we need to rethink our architecture. Host named site collections are the way to go, and preferably all within the same web application. But what are host named site collections and what do we need to take into account when setting this up? Update. Check out\u00a0part 2, detailing how to<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","jetpack_publicize_message":"","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","enabled":false}}},"categories":[34],"tags":[7,76,39],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p3KFR1-kh","_links":{"self":[{"href":"http:\/\/blog.repsaj.nl\/index.php\/wp-json\/wp\/v2\/posts\/1257"}],"collection":[{"href":"http:\/\/blog.repsaj.nl\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/blog.repsaj.nl\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/blog.repsaj.nl\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"http:\/\/blog.repsaj.nl\/index.php\/wp-json\/wp\/v2\/comments?post=1257"}],"version-history":[{"count":0,"href":"http:\/\/blog.repsaj.nl\/index.php\/wp-json\/wp\/v2\/posts\/1257\/revisions"}],"wp:attachment":[{"href":"http:\/\/blog.repsaj.nl\/index.php\/wp-json\/wp\/v2\/media?parent=1257"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/blog.repsaj.nl\/index.php\/wp-json\/wp\/v2\/categories?post=1257"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/blog.repsaj.nl\/index.php\/wp-json\/wp\/v2\/tags?post=1257"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}SharePoint URL\u2019s<\/h3>\n
![\"Siegmund_Host](\"http:\/\/blog.repsaj.nl\/wp-content\/uploads\/2014\/07\/Siegmund_Host-Named-Site-Collections_01.jpg\")
<\/a><\/p>\n\n
New-SPSite \u201chttp:\/\/portal.contoso.com\u201d -HostHeaderWebApplication \u201chttp:\/\/HNSC01.contoso.com\u201d -Name \u201cPortal\u201d -Description \u201cCustomer portal\u201d -OwnerAlias \u201ccontoso\\administrator\u201d -language 1033 -Template \u201cSTS#0\u201d\r\n<\/pre>\n
What\u2019s in a name?<\/h3>\n
\n
Setting it up<\/h2>\n
\n
Managed paths<\/h3>\n
\n
Microsofts’ advise<\/h2>\n
Migration<\/h3>\n
One webapp, bye bye governance?<\/h3>\n
SSL<\/h3>\n
Alternate Access Mappings<\/h3>\n
Conclusion: it depends<\/h2>\n
Recommended reads<\/h3>\n
\n
\nhttp:\/\/technet.microsoft.com\/en-us\/library\/cc424952(v=office.15).aspx<\/a><\/li>\n
\nhttp:\/\/blogs.msdn.com\/b\/kaevans\/archive\/2012\/03\/27\/what-every-sharepoint-admin-needs-to-know-about-host-named-site-collections.aspx<\/a><\/li>\n
\nhttp:\/\/blogs.msdn.com\/b\/markarend\/archive\/2012\/05\/30\/host-named-site-collections-hnsc-for-sharepoint-2010-architects.aspx<\/a><\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"