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.

 New-SPSite 'https://portal.contoso.com' -HostHeaderWebApplication 'https://<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 https://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 https://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 'https://portal.contoso.com') -Url 'https://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:

 Import-Module WebAdministration
# add empty binding to webapp on IP 192.168.10.20
New-WebBinding -Name 'webapp' -IPAddress '192.168.10.20' -HostHeader '' 
Sleep 60
# 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.

Comments

• Anonymous
  August 07, 2014
  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!

• Anonymous
  November 19, 2014
  Hey Brian, I'll get together with brother John and buy you a beer(s) to say thanks mate!.  My woe began when I had to have the default zone authenticating with WIN/ntlm only, crawl is so pedantic; and the web application's HNSC off-springs required to authenticate to OVD using (OOTB) FBA.Great exercise, now to tell the client to hand over a handful of (precious) IP addresses.Good stuff, see you soon!

• Anonymous
  February 04, 2015
  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:http://spdev = Root Site Collectionhttp://intranet.domain.com 1st HNSChttp://teamsites.domain.com 2nd HNSCI need the extend http://intranet.domain.com Site Collection so I can access is with Windows Auth instead on Mixed.. Is that possible? Thanks

• Anonymous
  February 04, 2015
  The comment has been removed

• Anonymous
  March 29, 2015
  Matt,  I need to add https for a HNSC set up for http.  Can this be accomplished without creating a new web app?  I need one web app to support both http and https.  

• Anonymous
  March 30, 2015
  Hi Bob,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.

  • Anonymous
    March 15, 2016
    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.Any advice would be greatly appreciated.
    • Anonymous
      March 15, 2016
      Check out this article which talks about apps and AAMs/host header sites. It might be able to shine some light on things.

• Anonymous
  August 10, 2015
  Great article Brian. 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. Thanks Craig

• Anonymous
  August 18, 2015
  Hi Craig, 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.

• B

• Anonymous
  August 23, 2015
  Really? <sigh> So all this advice from MS about using HNSC all the time, isn't really the full story? Is there some solid/updated guidance around what are the scenarios where we shouldn't be using HNSCs?  Because two URLs on a single site collection can't be that unusual. Thanks for taking the time to respond! Craig

• Anonymous
  September 28, 2015
  thans for the post Brian I wish i saw this earlier than this morning. it would have saved me a night sleep :)

• Anonymous
  March 31, 2016
  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.

  • Anonymous
    April 17, 2016
    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.

• Anonymous
  May 07, 2016
  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.Is it possible? and how i can achieve this configuration? Thanks

  • Anonymous
    May 11, 2016
    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.