What might be overseen when HNSC, reverse proxy and off-box SSL termination needs to be configured


Since SharePoint Server 2013 we have a new way to create a Site Collection, called Host-Named-Site-Collection. The benefit with those HNSC is that you do not need to play with extended websites and AAM settings.

First “surprise” is that there is no user-interface to create a HNSC. Looking around and we have to use PowerShell.

Step 1: Any SiteCol needs a WebApp, do it through the UI; http://contoso-sp is the name and use port 80.

Step 2: Run PowerShell to create the HNSC:

# Now create the HNSC
$wa = Get-SPWebApplication “http://contoso-sp”
$user = "contoso\administrator"
New-SPSite http://hnsc.contoso.com -HostHeaderWebApplication $wa -Name “HNSC-Team-Site” -Description “HNSC TeamSite for Extranet Only” -OwnerAlias $user -Language 1033 -Template “STS#0” 

I found that AAM does not need an entry, but what else I have to configure? Link-Translation on the reverse proxy? In the past that was not allowed or not supported.

This TechNet article should explain everything: https://technet.microsoft.com/en-us/library/cc424952.aspx Host-named site collection architecture and deployment (SharePoint 2013)

We read: The device that terminates the SSL connection, such as a reverse proxy server, must be capable of generating a custom HTTP header: Front-End-Https: On. This is the same custom header that Outlook Web Access (OWA) uses: Front-End-Https: On/Off.

OK, our proxy admin knows that setting because Exchange OWA need it to use SSL, but OWA itself will get the un-encrypted requests.

Step 3: The Reverse proxy Admin configured the proxy to publish the HNSC into the Internet.

Now the first tests will be made, Windows Users with Internet Explorer are able to get to the new HNSC. Testing with other operating systems on tablets, Phone might work or not.

Troubleshooting: Checking the TechNet article from top.

We read:

This recommended configuration in the diagram includes the following elements:

  • One application pool for site collections.

  • One web application for site collections that is hosted inside the one application pool.

  • A root site collection (http://SP1).

It means we need a “standard” root site collection for the WebApp and we can do that through the UI and by PowerShell. But why? Reading further:

Root site collection and search - A root site collection is required to crawl content in a web application. A root site collection can be a site collection that users cannot access.

Step 4: We created a TeamSite on the root.

Now the HNSC should not contain only a root site, also some SubSites. Created few SubSites. Again we see issues with devices trying to navigate to a SubSite. Troubleshooting tells us that the direct access (no proxy between client and server) to the SharePoint server works. There might be something wrong between the Client and SharePoint Server?

Read more in the TechNet article:

URL mapping - Use Windows PowerShell commands to manage URLs (Set-SPSiteURL, Remove-SPSiteURL, Get-SPSiteURL).

And:

The protocol used for a host-named site collection depends on the value of the Url parameter that you specified when you used the Set-SPSiteURL cmdlet to map the URL to a particular zone: http or https. Ensure that the IIS bindings for the web application, SSL certificates, reverse proxy configuration, and any other configuration necessary is complete.

Therefore I may need another setting, similar to the AAM I configured for Path-based SiteCols? Looking for an Example in the TechNet article:

Set-SPSiteUrl (Get-SPSite 'http://teams.contoso.com') -Url 'http://teamsites.contoso.com' -Zone Intranet

Does this mean it is necessary when having already http://hnsc.contoso.com and Front-End-Https: On ? Yes it is necessary, because SharePoint needs somewhere to know each FQDN (Full Qualified Domain Name) and Port, the Server is responsible to answer in the right way.

Step 5: Run PowerShell command:

Set-SPSiteUrl (Get-SPSite 'http://hnsc.contoso.com') -Url 'https://hnsc.contoso.com' -Zone Extranet

Now all clients are able to work with the new HNSC published by reverse-proxy server.

 

Summary:

HNSC is quite new and there are a lo of possible things we can do with that “feature”. The TechNet article explains almost everything and for some steps there are also Examples available. It is a human thing to may oversee some things to do, a lot of content but I need only few things from the whole description. I ran into a similar situation and wanted to share my experience with you.

Please read that article very careful, mark everything what “could be” important and remove it from your list when you are really sure. At the end you may have a step by step guide and will have more fun when setting it up.

Hint:

My examples in this post are just examples and may differ from those you can use, FQDNs, used account names, Zones…

Comments (2)

  1. Dave M says:

    So client can now go through the LB using https with SSL set as off box (terminates on LB). SharePoint configured with http.

    OK - here's the issue. What stops anyone going to the WFE directly with http, any way you like, form anywhere  avoiding the load balancers?

    for example a client changes his local hosts file so DNS points to WFE, not LB - he can then connect to site using http and thus not using SSL.

  2. Firewall configuration might be able to help here. For troubleshooting it sometimes can help when people with permissions access the WFE direct through http.

Skip to main content