My Sites and Host Named Site Collections

sharepoint.stackexchange https://sharepoint.stackexchange.com//questions/71043

Question

I want to go with the new recommendations for SP2013 to use one web application for the SharePoint farm. The full article is here on MSDN:

I don't understand how to set up My Sites with this approach - I used to have a separate web application for my sites.

MS says:

You need to use a custom solution for self-service site creation with host-named site collections.

My Sites utilize self-service site creation. Sure, I could pre-provision all my sites for my existing users, but when a new user joins the company I can't be sure that the users My Site will be manually provisioned by staff.

The same article states:

You can use host-named and path based site collections in the same web application.

and

When you use both types of site collections with My Sites, consider implementing your own provisioning process to create My Sites as host-named sites instead of path based sites.

Ok, so I can mix HNSC & path based site collections. What is the process like then? Would I just create an explicit path /my with a wildcard /personal path? Why would I need my own provisioning process then? What does that look like? I can attach a provisioning provider to a site template, but how can I utilize my own self-site creation process, or are they talking about using e.g. PowerShell to create a new site for each user? (Wictor Willen showed a way to create a global provisioning provider, I don't want global, I only want My Sites to work)

My question is as stated in the title: How do I set up My Sites in a HNSC web application as well as self service site creation? Microsoft says in the article it's best practice - tell me how.

Was it helpful?

Solution

The simple answer is: It just works. You can enable the self site creation feature using central administration (also set "Start a Site" to "be hidden from users"). You need a root site collection in the primary web app (even if the web app is not used and is only a container for HNSC) to set this in the central admin page. If you don't want a root site collection you can go the powershell way:

$wa = Get-SPWebApplication
$wa.SelfServiceSiteCreationEnabled = $true
$wa.ShowStartASiteMenuItem = $false
$wa.Update()

My demo farm did enable this setting automatically during the user profile service app creation. This setting will enable the mysite creation. This setting will still not allow you to use the default self site creation page on path based HNSC, but it helps with mysites.

The problem with this solution is you have "no" control on the database distribution for mysites. Typically you want to have a dedicated set for each type (mysite, portal, teams, projects, ...). But there is a workaround: HNSC are created using powershell only so the normal process could be to handle the database assignment at this phase for normal sites. So all content database have set the max sites allowed value to the current site count. Create your number of mysite databases and leave them "open" (max site count on default values). From here mysites will only go to the open (and therefor dedicated) mysite content databases. Not an ideal solution.

I could not find any supportability statements from Microsoft about this configuration. At first I though this is unsupported. But I've check this article and found no other statement:

Note: Self-service site creation only creates path based site collections. You cannot create host-named site collections with self-service site collections. Source: http://technet.microsoft.com/en-us/library/cc263483(v=office.15).aspx#section2

Original answer:

The simple answer to your question is NO. You are not able to use Host Named Site Collections (HNSC) and enable Self Site Creation. You did all the research already and I hope my answer will help others to understand the reasons and the impact.

First let me try to show you a "simple" solution to achieve the "custom" site provisioning. One way to solve the problem is as you already mentioned to pre-create the sites for existing users. From here you can create a scheduled task the will run a powershell each night to check the "domain users" group and check if all users have a mysite created. If not run the same script as in the initial phase and you are done. This is a overly simplified version. There could be a dedicated group for users that are allowed to use a mysite. This could me mixed with the permissions inside of the user profile service to allow only users within a dedicated ad group to have the mysite feature. You could react to an HR event from a SAP system to execute the script in a employee on-boarding process. A lot of details are possible. But in a simple approach with not that much users a lookup to the domain users group could be a good start.

I'm not sure if I could recommend this Microsoft Best Practice, because of all the "problems" and the differences between the SP2010 model. Why is Microsoft doing this? Because they are using it in the Office 365 solution and they operate a "REALLY" large farm or set of farms. At this scale they will have a lot of best practice and tooling around the limitations. The normal customer and even worst the poor admins will recreate all the tooling is they stick with the Microsoft Best Practice.

My personal opinion is to avoid host named site collections and stick with the traditional model. If you are an experienced SP2010 admin and know how to operate a set of web applications using AAM, dedicated user policies, multiple content databases per web app, old school wsp solutions and more you can create a perfect farm which will operate as good as a HNSC single web app farm. If you are all new and don't need custom solutions and stick with the app model... take the new route and create your farm the new way.

I'm currently involved in a PLA based solution from Microsoft Consulting Services and get to know all the joy of the MS Best Practices. All the know how of the "old" days don't apply. I can see the benefits of the approach but I see a lot of resistance from experienced SharePoint admins because they know all the customer requirements. If the internal customers are not willing to change their perception of SharePoint and the feature set available will all the best practices the team will have a hard time fighting all the feature requests the could be fulfilled on the old SP2010 farm within "minutes".

Here is a reference to the hardcore implementation in PLA:

OTHER TIPS

The following (brand new) article by Wictor Wilen might be helpful to you:

http://www.wictorwilen.se/sharepoint-specifying-content-database-for-new-site-collections-when-using-host-named-site-collections

He talks about how to create a custom site creation provider.

Licensed under: CC-BY-SA with attribution
Not affiliated with sharepoint.stackexchange
scroll top