For those who haven’t heard of host named site collections, the short version of what they are is that rather than having multiple web applications in a SharePoint farm for sites with different URLs (such as teams.contoso.com and then projects.contoso.com for example) you can have a single web application that will use the full URL to identify a site (including the host header) rather than just the path (such as “/” or “/sites/site1”). If you’re not familiar with the concept there is a good write up on TechNet that covers off all the details that I recommend you read (see: Host-named site collection architecture and deployment (SharePoint 2013)).
One of the things that changes when we use host named site collections (or HNSC for short) is the way we look at extending web applications and multiple URLs. Under the path based site collection approach we can simply extend the relevant web application if we need to implement different authentication settings, or use alternate access mappings if we just need it to respond ot a different URL. The problem with alternate access mappings is that they apply to the web applications URL, not the URL of your HNSC’s, so they can’t be used. We can however still create multiple URLs for sites that are create as HNSC’s using some PowerShell commands to get there, and that’s going to be the focus of this post.
1. Creating host named site collections
This is fairly well documented in the TechNet article I’ve mentioned above, but I’ll include the step here for the sake of completeness. Once you have your web application set up to create HNSC’s in you can create a new HNSC with the following PowerShell command.
New-SPSite 'http://portal.contoso.com' -HostHeaderWebApplication 'http://<servername>' -Name 'Portal' -Description 'Customer root' -OwnerAlias 'contoso\administrator' -language 1033 -Template 'STS#0'
In this example portal.contoso.com is the URL of our site collection, and the http://servername reference is going to be the URL of the web application we created (which can be completely different). This will give us the site collection, and as long as we have the web application and appropriate DNS entries set up we can now browse through to the site.
2. Adding a second URL for the site
Now let’s say that I want to make the portal available under a different URL, something like http://public.contoso.com. For the time being let’s assume that the URL is the only change we need to make and we can use the same authentication settings of the main HNSC web application. Adding the second URL in this scenario is actually quite simple and can be done through the following PowerShell command.
Set-SPSiteUrl (Get-SPSite 'http://portal.contoso.com') -Url 'http://public.contoso.com' -Zone Internet
Once this is done (and again when appropriate DNS entries are in place) the site will now respond to both URLs, treating the new “public” URL as being in whichever zone we have specified (in this example I have used Internet).
3. Changing authentication options for the new URL
Now I’ll lay out the conditions here in that when you are planning web applications, site collections and authentication options that as always you give it the right level of planning and understand the impact of changes. I say that because under host named site collections any changes you make to the authentication settings of the main web application will apply to all the site collections that the web application is responsible for. So the change I’m making here could impact other sites, so just be aware of that and plan accordingly. Now on to what I want to do – let’s now assume that I want to allow only anonymous access to the public URL i created there, while allowing NTLM through the original portal URL. This is where things can get a little tricky – if we think about what we need SharePoint to be doing here we are asking it to tell IIS to have two web applications set up and that both of them could respond to any URL (so won’t have a host header in their binding). IIS can’t allow this as it uses the bindings to identify where each request should go to, so if you try to extend the main HNSC web application without a host header you will find that you get an error.
In order to get this working we need to have some mechanism to allow IIS to identify the difference between a URL designed to hit the default zone and the new extension we want to create – one of the better options here that will allow the most flexibility here is going to be around setting up unique IP addresses. If each WFE server is set up to have multiple IP addresses (which could be achieved through the use of multiple network adaptors, or multiple IP addresses set on the one NIC using Windows NLB for load balancing on top of that for example, there are a few ways of getting to this) we can then use the incoming IP addresses to distinguish things in IIS. In this scenario I would make sure that the DNS entry for ‘portal.contoso.com’ pointed to one of the IP addresses on the WFE server, and ‘public.contoso.com’ would point to a second IP address. This setup now gives us what we need to uniquely distinguish the incoming requests – but SharePoint can’t set this up in IIS for us so there is some manual intervention required for this approach.
To get SharePoint to create the extension we need to give it a host header value – what you set here is somewhat irrelevant as you can (and will) remove this later in IIS. Once SharePoint has extended the web application for you and you can see the extra site in IIS you can now go in and manually edit the bindings used. What we need to configure is that the main web application’s binding should be listening on only the first IP address, with no host header (and HTTP/S selected as appropriate) and then in the extended one we can then remove the host header (by just using * to tell it to listen to all host headers) and then specify that it should only listen to requests that come to the second IP address. Now IIS can tell which requests should go to which IIS site, which SharePoint can then use to distinguish between the web applications and know which authentication providers are at play here. Remember this manual change will need to be made on all web front end servers in the farm.
Lucky for us this process is somewhat simple to script through PowerShell as well – and is also documented in the TechNet article I linked at the top of this post. We can modify the bindings of the IIS website using a script that looks like this:
# add empty binding to webapp on IP 192.168.10.20
New-WebBinding -Name 'webapp' -IPAddress '192.168.10.20' -HostHeader ''
# remove existing binding webapp.contoso.com from existing web application
Get-WebBinding -Name 'webapp' -HostHeader 'webapp.contoso.com' | Remove-WebBinding
What about apps in multiple zones?
If your SharePoint site needs to make use of the new app framework there are some additional steps that need to be taken, which I may look to cover off in a future post, but I’ll talk briefly to a couple of points about this here. Firstly, when we first launched SP2013 we did not support apps having different app urls for different zones, they would all have to run through the default zone. This was however changes in the March 2013 public update so that you can specify different app URLs for different zones through PowerShell commands. So if you are considering this approach the first step would be ensuring that you have at least that update installed (any CU or service pack after that update is fine as well).
But that is about the extent of this – so we can use multiple URLs and multiple zones with specific site collections in a host named site collection model through the steps described above. Again I’ll stress though that if you are considering host named site collections (either for a new set up or to migrate your existing sites to this model) have a read of that TechNet article I mentioned as it is quite detailed in its instructions on how to configure and run a farm with this sort of set up.