Rational Guide to Multi Tenancy with SharePoint 2010, Part Two: Planning your Deployment

Print | posted on Wednesday, June 09, 2010 7:22 PM

Introduction

In the first part of my Rational Guide to Multi Tenancy with SharePoint 2010 article, I walked through the problem space and discussed the features of SharePoint 2010 that enable multi tenant environments. This can be seen as the “overview” (or perhaps “marketing” :)). As promised this is part two, the idea of which is to walk through how to set it all up along with some general recommendations.

Before we get started, I’d urge you to review Part One. The concepts are very important to grasp before diving in and provisioning stuff. I assume you have read Part One!

Secondly, there is some staggering misinformation out there about multi tenancy in SharePoint 2010. As always the steps here are verified and tested repeatedly for RTM. I however do things in the best order to explain them, you may need to tweak things based upon your requirements. I’ve also contrived a scenario to enable me to cover all the bases as it were. Also, this is SharePoint, your mileage may vary :)

It’s very important to understand that there is no single feature in the product that delivers a multi tenant solution. Like many things in SharePoint, it’s a collection of features that together deliver the functionality. For multi tenancy this is increased as it requires a solid understanding of other core aspects, most notably Service Applications with which there are tight dependencies and also a very wide range of deployment scenarios. This wide range of scenarios makes multi tenancy in SharePoint 2010 an extremely exciting and powerful space, but the flip side is you need solid architectural planning and design. I assume you understand (properly) service applications.

And lastly, multi tenancy in SharePoint 2010 is most definitely a “version 1” area. There are rough edges and gotchas to be aware of. It doesn’t take much thought to figure out who and what is the primary driver for this capability. Bear that in mind as you consider your approach to building multi tenant solutions with SharePoint 2010.

Now, as much as I wanted to post this as a single article, it’s just too big. There’s too much to discuss and there’s way too much script. I’m not a fan of downloadable documents for this stuff. Whilst that protects my content to a degree I have but a singular goal, to get the best information to as many as possible. Now that doesn’t mean I won’t come after you if you steal my content, but it does mean I am now doing this as a longer series of articles. Hopefully this makes it more easily consumable.

The articles are (links will be added as they come on line):

1. Feature and Capability Overview
2. Planning your Deployment (this article)
3. Example Scenario and what Multi Tenancy brings to the party
4. Configuring the base Infrastructure
5. Configuring Partitioned Service Applications
6. Provisioning Tenants
7. Testing the Functionality

Planning Your Deployment

Before we get started we need to plan our deployment! :) No really, it’s quite important. If you want a Multi Tenant configuration wizard you’ll be waiting for a long time. It’s just not a good idea anyway, as it’s not likely that two environments will be the same.

I know some of you will be thinking at this point, “man, I wish this dude would get on with it and show me the PowerShell”. But no dice. I cannot stress enough this ain’t no button or slider you tweak, you have to know what you are doing and PLAN.

There are lots of options, and there is no single best way. If someone is telling you “this is the right way” they are not the type of SharePoint practitioner you need.

We of course need to consider many of the same aspects that we would for any SharePoint deployment. However for a multi tenant scenario some things are paramount:

• Where will we host customer site collections?
  A dedicated Web Application per tenant, or all tenants in one. Refer to part one for more on this compromise. As a general recommendation a single web application is best (scale). Although I’d also recommend separating authenticated and anonymous services across web applications. We also need to consider My Sites, which is predominantly a scale issue. To some degree this logical architecture design follows the same patterns as any other SharePoint deployment, but in other areas it does not.
  
  Take Self Service Site Creation (SSC). This is required to enable Tenant Admins to create new site collections. SSC is a web app scoped setting. It’s on or off. If we have a single web app, then all tenants are able to create site collections.  
  
• How will we store customer site collections?
  All in one content database is not a good idea. Nothing to do with multi tenant, it’s just whack! :) When adding multi tenant into the mix it’s even more stupid. We need to be able to scale, and therefore we will be using many content databases.
  
  However, watch out for some markitecture that says “don’t have more than one tenant per content database”, or “if a tenant spans content databases, then only that tenant should be in each content database”. Whilst this sounds great, it’s untenable (no pun intended). Forget about being able to upgrade or backup/restore on a per tenant basis. It just doesn’t work like that. It’s a architectural wet dream.
  
  The reality is if we constrained tenants to specific content databases, we loose the ability to use Tenant Administration to create new Site Collections and will seriously impact the ability to use My Sites. Besides, there is nothing wrong with having more than one tenant in a content database, the problem is when you have too many site collections in a content database.
   
• Will we use regular addressing or host named site collections?
  Both will work just fine. This one really does depend on the specific scenario you are targeting.
  
  For an on premise deployment where you are looking at multi tenant for chargeback or other governance aspects, regular addressing will work great. This is the way I usually demo it, because it’s much simpler to configure and doesn’t distract from the key message. But watch out! Doing this you can very quickly hit the performance implications of too many managed paths. Consider the following scenario:
  1. 1 Web Application (http://www.wereallin.net/)
  2. We wish to provide a Content Type Gallery, a eDiscovery hub, MySites and a Tenant Admin for each customer
  3. We wish to allow customers to create Site Collections
  Right there, that’s seven managed paths, and a couple are "deep":
  1. /customername
  2. /customername/cthub
  3. /customername/edisc
  4. /customername/mysites
  5. /customername/mysites/personal
  6. /customername/admin
  7. /customername/sites
  Seven managed paths per customer. You see the problem? The magic number (aka software boundary) for managed paths per Web Application is 20. We can have more but the more we have the worse things perform. We absolutely cannot have 100s. So this has scale implications.
  
  Host Named Site collections on the other hand provide excellent support for vanity URL namespaces and allow managed paths to be shared across all host named site collections. There are a couple minor drawbacks, but they are very minor indeed. This means we need six managed paths, and how many customers we have doesn’t matter in this respect. Therefore I am strongly recommending you use Host Named Site Collections.
  
• Will we make use of a services farm?
  We can do published multi tenant service applications if we want to, but think long and hard about it. There has to be a very good pay off for all the extra complexity. If you are SharePoint online you may think about a Services farm. If you are someone else, I caution you against it. I may post more in depth material on this topic at a later date. For now it distracts from the topic. So that’s enough for now.
  
• Where will we store our users?
  In Active Directory. This one is easy! Sure you could use something else, but why why why? :) You must have AD for your farm anyway, and it’s the best. Sorry, it’s just the way it is. You also want to ensure that customer1 users are not visible to customer2 and vice versa right? That’s kinda a key requirement for multi tenancy. And guess what – we more or less require AD for that. So use AD and put down the “open credential store” pipe.
  
  Also, and this is of critical importance, how we store our users is paramount. There are implicit restrictions on how Subscriptions and OUs are “linked”. The people picker and user profile import are hooked up to OUs and that defines how we store our tenant users in AD. It doesn’t mean it doesn’t scale. I really don’t have time to debunk myths about AD or OU scalability, if you need that, go Bing a AD MCM or someone :) It’s how it works, deal with it.
  
• Not all Service Applications are created equal
  Yup, get used to it. The teams that built the SAs implemented them the way they thought was best. There is significant inconsistency. This must be considered before diving in. You must know what scripts or cmdlets are doing and the eccentricities of the various service applications.
  
• Custom Code
  Unless the product functionality meets your needs exactly you are looking at extending the Tenant Admin site, and you probably will need a “hosting control panel”. Do you have what it takes? Or do you have a vendor to help. A vendor that can meet the quality bar required. Not a little deal at all here. Be very wary of SharePoint ISVs, most of them are downright terrible in terms of quality.
  

I’m sure I’ve probably missed a few things, but these are the main consideration areas with regards to the deployment of multi tenancy environments with SharePoint 2010. I may update this from time to time as other things crop up. Remember this is pretty new stuff for most folks. In the next article I will detail my example scenario and show you what multi tenancy brings to the party in terms of the various service applications. Stay tuned!

.