Chosing between CRM Online Multiple Instances and Multiple Tenants

In larger CRM Online deployments with complex structures of departments, regions, development/test environments etc you'll often want to consider seperate instances. But should these seperate instances go in the same tenant or in multiple tenants?

Whats a "tenant"?

A Microsoft Online Services tenant is an instance of Online Services created in Microsoft data centers that contains uniquely identified domains, users, security groups and subscriptions.

Whats an "instance"?

Whenever CRM Online (CRMOL) service is provisioned on a tenant for the first time, a default CRMOL instance is created. A CRMOL instance is similar to what is known as an organization in CRM On-Premises. Each additional CRMOL instance that you add creates a separate and isolated Microsoft Dynamics CRM organization on the same tenant.

Why would you need multiple instances of CRM Online if data segregation can be achieved using business units and role-based forms, you might ask? Well, multiple instances could come in handy when segregation of plugins/workflows/admin resources are required which cannot be easily isolated using business units in CRM. You can read more about the use case in the article "Multiple Instances in CRM Online - whats the use case?".

 

Single Tenant Deployment

A typical Online Service deployment includes one tenant only. A tenant can include one or more CRMOL instances; however, a CRMOL instance is always associated with a single tenant

Important about single tenant and instances

• A tenant can include up to 50 CRMOL instances
• In a single tenant deployment, a licensed CRMOL user can access all the CRMOL instances associated with the tenant:
• Additional instances is purchased via the Additional Instance Add-On (Additional instances can only be added to "paid" subscriptions - not trials or IURs). If you purchased your CRM Online subscription through Volume Licensing, you must go through your LAR to purchase the Additional Instance
• Existing trials and/or subscriptions cannot be merged onto an Additional Instance; instead, you will need to move your data and customizations
• Storage is shared across the primary subscription and any purchased Additional Instances
• Separate security groups can be set up for each Additional Instance
• All instances for a single customer will be setup in the same data center and storage consumption is aggregated and tracked across all the instances attached to a customer subscription
  x
  
  Fig 1: Single Tenant Deployment

 

Multi-Tenant Deployment

As an alternative to a single tenant with multiple instances, you can consider a multi-tenant deployment, which in some cases will be a better option for you if you need segregation. For a multi tenant deployment, you'll need a Multi-Tenant Amendment.

Differences between the Additional Instance Add-On and the Multi-Tenant Amendment.

• Additional Instance Add-On
  This is a subscription add-on, which allows your company to share users and data across your various CRMOL instances (ie. production, dev, test). They keyword here is “share”. You purchase this for $549/month per additional Instance.
  x
• Multi-Tenant Amendment:
  This is an actual amendment to the Volume License (VL) agreement in which you want to purchase X number of licenses, but manage each of those instances completely separately, where users and data are not shared. An example would be if your company wanted to split up your licenses between completely separate divisions (or geo locations) in which you do not share users or data across those instances/tenants

 Important about multi-tenant and instances

• In a multi tenant scenario, a licensed CRMOL user associated with a tenant can only access one or more CRMOL instances mapped to the same tenant. To access another tenant a user would need a separate license (currently $44/month) and a unique set of login credentials for that tenant.
• Each Tenant will require tenant administrator(s) with unique login credentials, and each tenant affiliate will manage its tenant separately in the administrator console
• Licenses cannot be reassigned between tenant enrollments. An enrolled affiliate can use license reduction under one enrollment and add licenses to another enrollment to facilitate this
• An Active Directory user should not be synchronized with more than one tenant (see additional notes at the end of this article)
  x
   
   Fig 2: Multi-Tenant Deployment

 

To sum things up

• Economics - An instance is priced at a price approximately 12 times the price for a CRM Online user
• Credentials - Every instance under the same tenant can be accessed by a user using the same set of login credentials. In a multi-tenant a user would need a separate set of login credentials
• Segregation - Data and user segregation can be obtained in a lot of ways, including business units, role-based forms, security groups - in multiple instances, as well as multiple tenants

 

See also

• New Feature: Multiple Instances in the upcoming release of CRM Online - link
• Using Multi-tenancy in Microsoft Dynamics CRM 2011 to Address Challenges in Enterprise Business Environments - link
• Quick Guide to Creating a Trial on CRM Online - link
• What is a Windows Azure AD tenant? - link
• Directory Integration - link
• Configure filtering for directory synchronization - link
• How to Synchronize CRM Online with your Active Directory - link

 

Additional Notes On Deploying and Managing Multiple Tenants

You can sync your on-premises Active Directory with multiple tenants if

1. You have multiple forests, and Forest A has DirSync server A and tenant A, and Forest B has DirSync server B and tenant B

   -Or-
   x

2. You have a single forest, and the forest has DirSync servers A and B and DirSync servers A and B are configured with domain and/or OU filtering so they never attempt to sync the same objects across the multiple tenants! (tenants A and B receive sync from DirSync servers A and B, respectively) 

For #2, if JoeUser@contoso.com is in the Sales OU, and DirSync Server A syncs the Sales OU to tenant A, while DirSync Server B does NOT sync the Sales OU to tenant B, then this will work fine.

Else, if JoeUser@contoso.com is in the Users OU, and DirSync Server A syncs the Users OU to tenant A, while DirSync Server B DOES sync the Users OU to tenant B, then this will NOT work, and you will have object conflicts.

Constraints 

Customers wanting to deploy and manage multiple tenants need to be aware of constraints that will apply to such configuration, including

• Each tenant must have its own namespaces: UPN or SMTP namespaces cannot be shared across tenants
• If an on-premises Exchange Organization exists, you cannot split this organization across multiple tenants
• A consolidated Global Address List will not be available, except if explicitly managed downstream from the synchronization
• Cross-tenant collaboration will be limited to Lync Federation and Exchange Federation features
• SharePoint access across tenants may not be possible. While this may be solved with Partner Access, the user experience is disrupted and licensing aspects apply
• You must apply explicit Filtering in each Instance of the DirSync Client to avoid cross contamination of accounts between tenants
• There can be no duplicate accounts across the tenants/partitions in the on premises Active Directory
• A single domain can only be federated with one tenant

Learn more

Setting up Active Directory Synchronization, Federation and Single Sign On is a multi step process. To learn more, you might want to check out these walk-throughs from our Ignite site

• Installing and Configuring Active Directory Synchronization
  In this guide, you'll see how to synchronize your on-premises and cloud-based organizations using Active Directory synchronization.
• Preparing Your Environment for Active Directory Federation Services
  In this guide, you'll see how to prepare your organization to install and configure Active Directory Federation Services.
• Installing and Configuring Active Directory Federation Services
  In this guide, you'll see how to enable single sign-on access in your organization using Active Directory Federation Services.
• Adding and Verifying Federated Domains
  In this guide, you'll see how to add a custom domain to Office 365 and then convert it to a federated domain.

Comments

• Anonymous
  January 01, 2003
  Awesome article!

• Anonymous
  January 01, 2003
  https://technet.microsoft.com/en-us/library/dn722373.aspx

• Anonymous
  June 20, 2013
  Great article!

• Anonymous
  June 26, 2013
  Hi Jesper, Thanks for the knowledge sharing about managing and deploying multiple tenants!

• Anonymous
  June 26, 2013
  thanks for sharing Jesper. I'm already sharing this w/my customers.

• Anonymous
  July 11, 2014
  Do all instances on a tenant share resources such as CPU, Memory, etc...?

• Anonymous
  February 05, 2015
  The terms instance and tenant here are actually explained backwards. An instance is equivalent to the deployment for on-premises or a subscription for CRM online. A tenant on the other hand is a member of an instance. A tenent is similar to someone who rents an apartment that is in an apartment complex hence the use of the word tenant which denotes an occupant. A tenent can move from one apartment complex to another just as a CRM tenent or organization can be moved from one CRM instance to another.

• Anonymous
  October 16, 2015
  Can multiple tenants be combined into one tenant in CRM 2015? If so, what are the broad steps/approach to do it?
  

• Anonymous
  October 16, 2015
  no