Change from multiple web applications to Host Named Site Collections in an existing farm


This is far simpler than one might think and will help you align to the SharePoint Product Line Architecture as well as to how Office 365 - SharePoint Online is configured.

NB: TEST THIS ON YOUR DEV OR TEST ENVIRONMENT FIRST

You must schedule downtime during this process and whilst I have tested this extensively all actions are at your own risk.

Make sure you have some PowerShell experience or understanding as Host Named Site Collections can only be managed from PowerShell.

Pre-Steps Required:

  1. Perform a full farm backup
  2. Back-up all Site Collections using the backup-spsite PowerShell command e.g. backup-spsite http://intranet.contoso.com -path c:\backup\intranet.bak
    REPEAT this for each Site Collection in your farm except for Central Admin
  3. Now comes the risky part and it is at your own risk so test the process first.
    Once ALL Site Collection back ups have completed successfully 
    Delete all Site Collections and Web Applications from SharePoint Central Admin (DO NOT DELETE THE CENTRAL ADMIN WEB APPLICATION OR SITE COLLECTION)
    NB: You cannot restore a Site Collection backup onto a farm where you backed up the original Site Collection whilst it still exists as the Site Collection ID will ORPHAN your existing Site Collection (You have to remove the site collection you want to restore first)
  4. Create a new default web application on port 80 and name it "Default" with no Host header specifying a new content database (Use your own naming convention) e.g. WSS_Content_DEFAULT
  5. Create a new Site collection on the new "Default" web application and name it "Default Root" (This must not be edited or used for any Site Collection)
  6. Create new Content databases under the new default web application naming each database according to which Site Collections you would like to create in them e.g. WSS_Content_Intranet, WSS_Content_HR, WSS_content_BI

Restore-Steps Required

  1. Open PowerShell ISE as Administrator i.e. "Run as Admin" and use the following example to restore each Site Collection to their new respective databases
    e.g. Restore-SPSite 'http://intranet.contoso.com' -HostHeaderWebApplication 'http://default.contoso.com' -DatabaseName "WSS_Content_Intranet" -Path C:\backup\intranet.bak

  2. Go to DNS and ensure that you have an entry for each URL you have specified using the above command and make sure it is pointing to your Network Load Balancer or to your Web Front End Server if you only have one
    If you are using a Network Load Balancer (Hardware or Software) then you need to make sure that it is configured to direct traffic to your Web Front End Servers and the IP used in DNS must be the Network Load Balancer IP address.

Once all Site Collections have been restored through PowerShell and all DNS entries for all URL's have been added then you have completed your migration from individual web applications to Host Named Site Collections.

Depending on your network DNS replication may take some time but if you would like to hurry it along simply open a command prompt as admin on your PC and run IPConfig /FlushDNS and it will force the replication to happen on your PC.

In order to use Host Named Site Collections correctly you may only have 1 Web Application with all Site Collections residing under it as Host Named Site Collections.

This will also allow you to make use of the new Request Management Service in SharePoint 2013 which is designed for use with 1 web application.

What you will also notice is that we do not touch IIS and we do not add host headers in IIS at all.

We also do not add Alternate Access Mappings in SharePoint either so it simplifies management in one way and complicates it in another because it can only be managed via PowerShell.

Comments (4)

  1. Hi Greg,you can create a new web application, create a base Site collection (not to be used) and then start creating your new site Collections as host named under the new web application. This however means that you still can't make use of the Request
    Management Service and also means that your farm is not following the SharePoint PLA, yet. It is a good starting point though and you could start moving the remaining Site collections over one by one.

  2. G. Jones says:

    Scott- Awesome article and something we have been looking at potentially implementing!

    Question in thinking this through, if we wanted to leave what we have as is, are we able to start mid-stream with the host named site collection model? For example, lets suppose we have a web app for Team Sites and we are going to be setting up a new web app
    for hosting the Intranet. Could we leave the Team Site web app configuration alone for now and spin up the new web app for Intranet leveraging this host named site collection model? Or is this an all or nothing flip?

    Thanks!
    Greg

  3. G. Jones says:

    Thanks Scott! Is Request Management Service tied directly to this type of architecture? I had issues with enabling Request Management Service initially in our enterprise farm and had to back off using the service, currently off in our farm. I'm curious
    if the reason it didn't work is because it requires this specific configuration?

    Thanks,
    Greg

  4. Hi Greg, I can only tell you that RM is really designed for one web app for an Intranet. The basic premise is that there are no host headers in IIS and IIS recognizes the request as a SharePoint one and hands it off. I would say , Yes, to your question.

Skip to main content