Multiple zones for host named site collections in SP2013

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.

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.

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:

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.

You deserve a beer. The multiple IP solution to zones in HNSCs is genius. Zones are so important for bringing along all the tools that still require windows auth while still providing claims support for modern day use. Keep up the great work!

I need to extend a site collection not just the root one.. I created a "dummy" Root Site Collection that has Mixed Auth. The I created several HNSC. I need Extended Access to the individual HNSC's not to the root. Example:

You set unique URLs for each of your HNSC using the Set-SPSite command I have there in step 2. So the root site collection you set up the auth against the zone you want to use (such as Internet), then when you set an "internet" URL using Set-SPSite for the HNSC that will dictate the authentication (keeping in mind that you need IIS to route it correctly as per my points in step 3). So yes what you are asking for is completely possible – but it's fiddly to set up and worth considering if HNSC is really the best approach.

I would ask why you need both – surely if you can use HTTPS that should be the preference? But in any case, you should be able to achieve the desired outcome by adding the HTTPS binding to your main web app, and then using Set-SPSiteURL to tell SharePoint that the second URL for the site is HTTPS based.

I have a follow up question regarding HNSCs using HTTP/HTTPS. How does this work when we add apps (er- add-ins) into the mix? If my web application is configured to use http://portal.contoso.com, and my app domain is “http://sharepointapps.contoso.com”, how do I configure this so that “https://portal.contoso.com” uses “https://sharepointapps.contoso.com”. We already have the binding for the HNSCs all setup, but can’t figure out how to get the app domain to follow suit.

I've just started working with HNSCs and we're about to go-live with one and so I was testing setting a second URL on the same SC:

Default: internet.DMZDomain.com

Internet: www2.PublicDomain.com

But found that search results only picked up the default URL, so links to results only ever came back with the one FQDN, regardless of which URL you used to access the site.

So I dropped in a Server Name mapping in Search, to map default URL onto the Internet URL and did a full crawl. But now search only returns links to the Internet URL…

Back in the good old days, AANs seemed to handle this much better.

Have I missed something? Is there a way to still do this with HNSCs?

Once we go live it wont matter, I can replace the URL completely, but longer term, I can see us using multiple security Zones, with different URLs, against the same SC and search just isn't going to like that.

Yea while this approach gives you the ability to do multiple zones against HNSC's, the reality of the matter is that I tend to avoid HNSC where I will be doing more complex things with zones and extensions in favour of the traditional approaches. Things can absolutely get messy pretty quickly if you have a more complex scenario so if there isn't a specific need to have the HNSC in a scenario with extensions then give it a miss and stick with what works.

How can I set AAM for HNSC ? I have everything on port 443. My objective is to have HTTP redirected to HTTPS for my HNSC. I just don’t see how it can be done with HNSC, but with regular web applications no problem.

How are you doing your direction to HTTPS? The exact same setup should be possible as you can for normal web apps, but if you can let me know how you are doing the redirection I might be able to provide more information.

Hi Brian , thanks for this post is very useful, My situation is a little different, i have one web application that contains two sites collections created with managed path, i want to set a unique URL and different authentication providers for each site collection, by using the host named sites collections (HNSC), Example:

web application: http://host header, with default zone (one zone is defined for the web application)
site collection 1 : http:// url1 ( completely different with the URL of the web application) , and Authentication provider =Anonymous+FBA.
Site collection 2: http://URL2 ( with the same domain name of site collection 1) , and Authentication provider= Windows NTLM.

If your web app has Windows authentication as it’s only option for the default zone, and an extension to another zone that uses only Anon+FBA you could get close to this. Site collection 1 will have the two URLs assigned to the site like the post here explains, but you can just use the default zone URL that you create the site with as one you don’t ever use or advertise. It gets complex pretty quickly messing around with this though so I would still consider multiple web apps (and share an app pool to keep resources down if you can) as a way to simplify configuration.