Implementing Multi-tenancy Infrastructure with SharePoint 2013 (SAAS) – Part 2: Planning for Deployment

– The Step by Step Guidance for Creating SharePoint 2013 Based Multi-Tenant Infrastructure,   Part 2 Planning for Deployment –   

Planning Your Deployment

Seems you are continuing to read from Part 1 of my Article Series.

For sure you will need few days to test the entire Multi-Tenant functionality properly. All the below perspectives are entirely depends on the Product Knowledge and the past experience. Performance is ofcource a major concern as this isn’t a generic setup where a single Web Application and few Site collections will serve requests. In this case we are talking about a Hosting Vendor who will be Providing a Stable, reliable and well performing SharePoint online service for its Clients.

It’s also goes more deeper when we think of Intranet Scenarios. Customer may host their Web Portal or may be Intranet Portal. Intranets needs robust environments as it will be heavy with lots of Services and content. Performance, Storage and Security is a big concern here.

However, there’s no environment stays static so you might need to scale up-out based on the utilization of resources. Specially the storage you won’t be able to stick to the initial when it becomes popular. So the improvements has to be done for sure.

You need to read more on SharePoint Hosting Guides given by Microsoft as I stated in the Part 1.

Test (POC)

Prior to the Production Deployment, It would be a great idea to run this and try out in a POC (Proof of Concept) Setup. A Single Server would be sufficient but multi-Server environment is ideal so you get the real world experience. Unlike generic SharePoint Farm deployment, Multi-tenant Farms are more tricky. You need to Plan a lot which is extremely goes in to the deep dive as down as Hardware, Software, SharePoint Services Allocation, Service Segregation across Servers, Performance Considerations such as Storage (IOPS), Security Requirements (Publishing Through Proxies) etc..

Hosting Tenants – Where the customer Tenants (site Collections) will sit on.

A Single Web Application for all the Site Collections (Tenants) ? Or a dedicated Web Application for Each ?. Well, This thing is entirely depends on how far you will go. Microsoft Does not recommends to Host more than 20 Web Applications per farm. This is a threshold not a Limitation. Yet it is considerable since you are not supposed to exceed the recommended level in these kind of critical real world scenarios.

Planning Backend for Tenants

Basic Idea of this is, whether we are isolating our customer’s site collections Databases or not.

Single Content Database for all ? Not a good idea. Data isolation is a prime concern when we talk about Multi-tenancy and a Dedicated Content DB per tenant would be ideal. When it comes to the scaling perspective, Isolated DB is ideal.

Site Collections and Database Limitations and Recommendations

Isolation is all about Site Collections and Databases. You have to go through Software Boundaries and Limits for SharePoint 2013 during your planning.

Active Directory Perspective

The Isolation also comes from Active Directory side when we talk about Security. Tenant A (Customer A) should not be able to see the users of Tenant B (Customer B). When a user of Tenant A trying to Search another user through the People picker, he should be only able to see the result within his tenant. This is a Security practice which will be implemented via Active Directory Organizational Units (OU).



Where we store our Users is not a matter here. Yes you got it right ! We can use the Active Directory as I have shown in the diagram above. You could use somewhere else to store the users but you got the best place to store them, why somewhere else is depends on your requirements. I would straight go with AD through dedicated OU Concept which is too easy and centralized. I will only need to look after the AD Objects so the windows authentication is way smarter.

URL Considerations

The other Key point to make decision is, URL. How you are going to let your customers to access the site. There are two choices as 1. Ordinary Addressing and 2. HostHeader Site Collections.

Also there can be below possibilities. In this scenario we have to consider that we will provide all these for our customers.

  1. Allowing Customers to Create Site Collections under their root
  2. We Will provide Content Type Hub, My Sites, Tenant Administration Site

E.g. scenario – Above features may depends on the level of Subscription (feature packs you are setting for the tenant). Yet you need to make sure how these sub site collections are addressed. Take below sample scenario to get an understanding.

Web Application – Root (

Tenant URL – /TenantA

Other Sub Site Collections






Per Tenant There going to be Lots of site collections where each stands there for a specific purpose. This is a hassle to manage with path based concept isn’t it ?. And the critical point is, Performance. Having lots of Managed Paths in a single Web Application will give you performance overhead. The recommended number of Managed paths per Web Application is 20. we can ofcource exceed the number and go for more in here but more you have will more overhead on performance.

Host-header Site Collection is the ideal way to achieve this point. Except few minor drawbacks, it gives excellent capability over the each site collection you can have multiple managed Paths. Even though the Site Collections sits on a single Web Application, doesn’t matter the number of Managed paths (in terms of Web Application wise) per web Application because you are dealing with a separate host-header Site Collection. I would recommend to go with Host Header Site Collections at this point.

Custom Stuff

Why Not !. having a Centralized service portal which allows users to visit and create a tenant themselves will be a handy thing just like Microsoft’s O365. having an armed super-duper backend to run the provisioning of tenants through automated scripts etc.. There’s lot more to talk on this thing so for now let me finish what I started under this topic.


Stay Tuned for Part 3 – 6 soon to be Published !

—————— Part 3 – Functionality Tech Preview (What It Really Gives You) ———————————-

—————— Part 4 – Deploying Core Infrastructure (Platform) ————————————————–

—————— Part 5 – Creating Partitioned Service Applications ————————————————-

—————— Part 6 – Creating Tenants and Do some real stuff ————————————————-


Step by Step Article Series for Creating SharePoint 2013 Based Multi-Tenant Private Cloud Infrastructure

Overview of the Concept

The title explains it very well. However the multi-tenancy is all about providing subscription based Sites and Services on top of a centralized single platform. Multi-tenancy is a Cloud Concept mostly holds by Hosting providers such as Microsoft (SharePoint Online) ,FPWEB, Rackspace etc.… But what about your own SharePoint Private Cloud for your specific needs? Sounds Great and that’s where we going ahead with this article series.

Very Simply – Web Hosting with a Unique Space with Isolated Data and Security provided by Centralized and Shared Set of Infrastructure. The Tenants I’m defining here as the Unique Space where the Infrastructure stands as SharePoint.

SharePoint is really capable of Providing subscription based Sites which are completely data and security is isolated. Each customer will have their own Space with isolated security and data which technically known in the multi-tenancy perspective as the ‘partition mode’.

It was there even in earlier versions such as Office SharePoint Server 2007. In This article I’m listing the steps to create a multi-tenancy platform on top of SharePoint 2013. Deployments scenarios of platform like this is not really a common thing like generic SharePoint Deployments, It will only find by specific set of audience who does Hosting.

Concept Overview in SharePoint Perspective


Technical Briefing

When it comes to Implementation, take a look at below describing which takes you through the technical facts of SharePoint Multi-tenancy.


Like you can see in the above diagram, there’s a single SharePoint Infrastructure which Shares set of Services (only few are mentioned here, there are lot more) through partition mode capability. A single (or may be many) web application holds multiple number of Site Collections (ultimately Tenants) with uniquely partitioned database from the SQL Backend. each customer (Target company or set of audience) will get a unique set of Sites which are ultimately called as a tenant. Below are the provided sites for each Customer, each will get three different site collection under the main which are sits for a specific purpose.

  1. Main Site Collection – The main Portal which end Users will work on.
  2. Admin Site – The Administration Site for each tenant with limited set of features. The highest level is still managed by the hosting Farm’s Central Administration.
  3. CTHUB – Content Type Hub.
  4. My Site – Personal Site Host

What’s Common and What’s Unique

Ofcource we talk about a centralized Infrastructure with Shared Services here isn’t it? So yes, the Common things are the Features of SharePoint Such as sites | User Profiles | Searching | and so on. Whatever the features used across tenants are Common at this perspective.

And, Data and Permissions are the main Unique facts. Each tenant can be uniquely Permitted for a set of Administrators and Users who are only permitted for that particular tenant. And unique Data can be reside in particular tenant where nothing exposed across the other Tenants or Farm.

Prime Considerations

a. Data Isolation

Isolating Each Customer’s Data is the prime fact here. Though every single tenant ultimately sits in a single shared infrastructure, Isolation of Data is very important.

b. Security and Customizations

Customer 1 Should not be able to Access Customer 2’s Site or see their Data nor they can do any customizations on other’s. True isolation is all about addressing this particular key factor which SharePoint nicely does.

c. Manageability and Administration

Customers should be able to manage their tenant within their scope without bothering hosting provider. The admin Portal for each tenant nicely addresses this requirement which allows tenant admins to manage User profiles | Search feature and so on in tenant level.

d. Address Spaces and Accessibility

Each Customer should be able to access their portal with their own web address. External Mappings of SharePoint caters this.

e. Tenant Sites (Member Sites) and URL Namespaces

Two Possibilities are there in this perspective. We can either have a tenant per web application or site collection. Creating tenant per web application will make web.config available for each tenant but there are key facts to be taken for considerations.

  1. Limitation of number of Web Application Per Farm.
  2. This make a high overhead on administering and maintaining. Performance is one of the key importance so this isn’t really a recommended approach when it comes to large deployments. May be if you are not going beyond 10 tenants.

Host Header Site Collections

This is the room allows us to store more and keep watching in a simple way other than traditional. With host header Site Collections, we can have multiple root level sites with independent top level domains within a single Web Application. Host header site collections have been there for quite long now. Improved a lot with SharePoint 2010 and now acts a giant role in the arena. Hats off for this awesome ability which plays one of the prime role here.

Addressing Different Scenarios within a single Infrastructure

When we have an Multi-tenant SharePoint Infrastructure, that doesn’t mean you cannot do traditional things within it. For an example if you try to create a new Service Application in a traditional way not partitioned, you can do so. And also generic web applications are too. Kind of a Hybrid scenario I was talking about. So even if you deploy multi-tenant Platform it’s yet capable of acting on traditional way too. Pretty cool !

Tenant Administration

Tenant Admin Site is created by a hidden default SharePoint 2013 template. Via this Site, Administrators of tenants are allowed to manage their subscription with defined set of administrative features. Looks like SharePoint Central Administration Site but only with defined set of features. They cannot simply play around with Root stuff but most of the key requirements are addressed here.

Changes in 2013 and What to be Considered

Not a big deal but as you are aware, there are number changes in SharePoint 2013 compare to 2010.

Service Applications Partitioning and Databases

Service applications are Partitioned to serve Data Partitioning. This will use a Single Database to Serve multiple tenants. There are some Service applications which are cannot be Partitioned and some can be partitioned but no Data Saving. We Need to create both Service application and Application Proxy and doing this possible but only with PowerShell which is ultimate steering wheel in the SharePoint Highway !

Based on SharePoint 2013 RTM. Below are the list of Service Applications that can be partitioned and stored tenant Data.

  • Search Service
  • Secure Store Service
  • Word Automation
  • Project
  • User Profiles
  • Managed Metadata
  • Business Data Connectivity

These Service Applications cannot be partitioned neither can be stored Data of tenants

  • State Service Application
  • Access Database Services
  • Visio Graphics Service
  • Word Viewing Service Application
  • PowerPoint Service Application
  • Excel Calculation Service
  • PerformancePoint
  • FAST for SharePoint (No longer in 2013 nor further)
  • Below ones are could store tenant data but doesn’t support Partitioning (Site Collections level-Readily Associated with Site Collection )
  • Usage and Health Data Collection
  • Web Analytics

Site Subscription and Feature Packs Involvement

Site Subscription is the Key of the Main Door here. Site Subscription is a Logical Set of Site Collections that can share Data, Features and Services. Site collections of Tenants are Grouped with a Specific Unique ID which called as the Subscription ID. This ID is used to Associate Data, Features and Services with each Tenant. This is the Core of the SharePoint Multi-Tenancy. Subscription Service Application is entirely responsible of storing Subscriptions of each tenant and their ID Accordingly and Map the Site Collections with Services and features. So taking care very much on this guy is very important after the deployment which comes as a part of administration and maintenance.

Feature Packs also acts a Key role here. Feature packs are group set of features that enabled for tenants to use. This is the key which defines the functionalities of SharePoint that which to use and which not to. We can use these sets to control the feature enablement across the tenants. very useful when it comes to requirements such as budgetary and starter level ones so we can simply lock down some set of features which are not included in to the particular subscription. This is incredible !!

This can be only performed via PowerShell or Object model which again you don’t get any UI.

Compatibility across the Editions and Versions

Multi-tenancy is possible with all the Editions but the only limitation is features. As you know foundation has the minimum set of feature and capabilities and standard bit more included and Enterprise is fully armed with all. However all these editions are compatible for multi-tenancy.

SharePoint 2010 (All Three Editions are Supported)

Foundation – Supported

Standard – Supported

Enterprise – Supported

SharePoint 2013

Foundation – Supported

Standard – Supported

Enterprise – Supported

Configuration Steps


On SharePoint Server

SharePoint Binaries are Installed (ofcource the Product prerequisites are prior to binaries)

On SQL Server

SQL Server Instance Installed with required Service accounts and can be opened from SQL Studio

Do not run the Product/farm Configuration Wizard after Installing Binaries. The Script will do this for you.


Stay Tuned for the Part 2…


Part 2 is here