Recently we created our first set of SharePoint 2013 sites using Host Named Site Collections. To get a quick refresher on this you should really read the following article by Kirk Evans (@kevans) to get a bit up to speed. You can find it here.
We had an interesting after effect for our users once we did this that I thought I would let everyone else know about.
Originally we had our SharePoint 2010 sites setup under path based site collections with the structure of http://webapp/sitecollection. This has been working out great for us so far, but many of our sites that we first created as sub sites in a site collection have grown to a size where we really needed to separate them out onto their own site collection and content database since they showed signs of only getting larger (like bigger than 50GB).
Since this is a bit trickier than simply doing a backup-spsite because since these were subsites, we had to use export-spweb to break them out of the site collection and then use import-spweb to move them into a new Host Named Site Collection (HNSC) named http://sitecollection.webapp.
Once we created our HNSC through PowerShell and finished the import-spweb to bring the sub site into the new site collection, we started getting calls from users about not being able to log into the new site. Once I logged into a user’s machine to see what the issue was I saw what was happening.
When the user went to the new HSNC 2013 site for the first time, they were being prompted to log in with a username like this:
Normally the users were used to seeing:
Once I corrected their login back to domain\username, then the prompt would go away and they could get into the site and they would not see the prompt any longer. Since this new naming was different from our standard domain I had to go into the user’s browser and make sure the new site was under their local intranet settings in their browser so the credentials could be passed properly.
Our long term fix for this was to roll out a group policy object to all the users of the site that added this new url to their local intranet section of their browser so their credentials would pass properly. Since implementing this GPO, we haven’t seen users having issues getting to the new site.
I hope this post helps anyone else who runs into this issue going forward.