Multi-tenancy in SharePoint 2010

It’s not often that i’ve delved into an administration related post on this blog. In fact, it’s been a while since i’ve had to wear my administration hat having focussed on development for the most part of the last year and a half. This topic however was one particularly relevant to me and peaked my interest so I thought it worth while writing about.

Truth be told, I’m not the first to write about this topic. There is a tonne of information already out there, and some absolutely brilliant posts that i’ll reference in this article. The goal, as always, is to collate the best information about the topic and discuss it within the confines of the situation I was up against.

I’ll start with the back-story. This environment was one that hosted a relatively significant number of public facing websites on MOSS 2007 – between 10 and 15. Due to licensing restrictions this was primarily done with a single web front end and application server in a staging -> production content deployment model. While there were no obvious performance concerns raising their head, it was always a bit of a concern of mine.

When given the opportunity to architect the SharePoint 2010 environment I immediate dove into reading as many best practice articles as possible to suggest how the farm should be created. With 3 licenses to play with my suggestion was the relatively stock-standard 2 load balanced web front end servers with a stand alone application server, discarding the content deployment model which was no longer considered a best practice.

The true opportunity however was to ensure that the way we handled the multiple sites was done so in a way that would both suit the requirements of the environment and maximise performance. My main concerns were adhering to the capacity planning boundaries outlined in the Technet article SharePoint Server 2010 capacity management: Software boundaries and limits – most specifically the maximum of 10 application pools per server which I knew we would have been exceeding with our one-to-one map between web applications and application pools previously. Multi-tenancy using host named site collections immediately sprang to mind.

It was a model I had recently read about and thought potentially perfect for our situation. The article I read happens to be one of the best out there for understanding how to approach multi-tenancy in SharePoint 2010 – Spencer Harbar’s Rational Guide to Multi Tenancy with SharePoint 2010. It definitely got me excited about the possibilities.

Thinking that the solution had been found I went on to read a number of other quality articles that deserve to be mentioned in this post. Benjamin Athawes’ Multi-Tenancy in SharePoint 2010 using host-named site collections , Technet’s Plan for host-named site collections (SharePoint Server 2010) and Steve Peschka’s Enabling Multi Tenant Support in SharePoint 2010 Parts 1, 2 and 3 are all worth a read.

Perhaps the most important article I went on to read however was Kirk Evans’ What Every SharePoint Admin Needs to Know About Host Named Site Collections. It really helped to ram home what was and wasn’t possible with host named site collections, and it turns out a lot of the things I had hoped to do weren’t.

Initially I had planned to group related sites in a web application, and hence have a few web applications hosting multiple host named site collections. This seemed only possible however using multiple ports or multiple IP addresses, neither of which I wanted to impose on our infrastructure team (as a side note, Mark Arend points out another way in which this can be achieved in his article Host Named Site Collections (HNSC) for SharePoint 2010 Architects however that wasn’t an attractive option either). Regretfully, I thought that we could still manage using just the one web application on the default port.

More curve balls were thrown however when I saw that alternate access mappings weren’t available for host named site collections. This removed the ability to have multiple addresses for the public facing sites (of which some existed) and more critically prevented us from going down the recommended path of having an authenticated web application for content editing and an extended web application for anonymous public access. My hopes were dashed and I felt like I was back to square one.

Funnily enough, the available solution was also one of the simplest – multiple web applications using the same application pool. This way my concerns about breaching the 10 application pool boundary were allayed and the number of web applications we were dealing with fit comfortably under the best recommended guidance I could find regarding web application boundary’s – Spencer’s 3rd hand comment on Benjamin’s article Web [Application] limits in SP2010 – keep it low!.

My only remaining concern was the Service Application app pools, thinking that this could easily blow out the numbers. To this date i’m still not entirely sure if these application pools count towards the boundary limit (it seems they do not but I’m not 100% sure) – there are however some interesting articles available to read; Shannon Bray’s SharePoint and the Various Application Pools, Benjamin’s WFE Application Pool Limitations in SharePoint 2010 (Part 2) and Todd Klindt’s How to change the App Pool ID of a SharePoint 2010 Web Application. The latter article suggests using the same application pool for all of the Service Applications which seems the safest approach.

And so ended my introduction to multi-tenancy in SharePoint 2010. I must admit I was slightly dissapointed that I wasn’t able to stand over the infrastructure team’s shoulders and help implement host named site collections but reading some of the interesting and inspiring articles on the topic has at least motivated me to ensure I fire up a virtual environment and play around with it myself. If there was a moral to this article it would be that when faced with a multi-tenancy proposition, explore all of the options and read all of the material highlighted in this post to determine the best solution for your scenario.