De Enterprise Edition van Microsoft Dynamics CRM 4.0 biedt zgn. multi-tenancy ondersteuning waarmee meerdere exemplaren van Microsoft Dynamics CRM binnen een partitie gerealiseerd kunnen worden.

Dit betekent dat een aantal compleet verschillende organisaties met hun eigen rapporten, workflows, aanpassingen en schema's kunnen worden gerealiseerd op dezelfde hardware, dus dezelfde fysieke servers en dezelfde database servers en IIS websites.

Dit lijkt een  wondermiddel dat alle vraagstukken omtrent beheersbaarheid oplost. Onderstaand een afbeelding van een dergelijke oplossing.

Dit lijkt logisch, omdat elke organisatie haar eigen fysieke database krijgt op de gedeelde SQL Server of bijvoorbeeld haar eigen SQL Reporting Services-map.Dit model werkt echter perfect als die verschillende organisaties deel uit maken van verschillende team-of afdelings-oplossingen. Dit is immers waarvoor multi-tenancy is ontworpen.

Hoewel het waar is dat elke organisatie (of huurder) zijn eigen database krijgt, gebruiken ze allemaal dezelfde organisatie-eenheid (OU) en Active Directory-groepen, en zullen ze allen hetzelfde platform delen. Dit betekent dat dezelfde asynchrone service en IIS-website zal worden verdeeld onder organisaties.

De front-end-servers zijn in staat om om verschillende organisaties door middel van een aparte URL te hosten. De CRM-server kijkt vervolgens naar de root directory naar de naam van de organisatie.Omdat het dezelfde website wordt gebruikt voor meerdere organisaties zal, als u aangepaste code heeft als onderdeel van uw oplossing, deze worden gedeeld door beide organisaties. Beide verwijzen namelijk naar hetzelfde fysieke bestand op de schijf.

In een situatie waarbij er sprake is van een ontwikkel, test- en een acceptatieomgeving kan dit een ernstig probleem zijn mocht u bepaalde zaken willen isoleren. Stel dat  Build 11 van uw oplossing momenteel wordt ontwikkeld, terwijl Build 9 in UAT (gebruikers acceptatie testen) is. Als u vervolgens probeert om uw multi-tenancy omgeving te gebruiken om uw probleem op te lossen, zal u uw harde schijf willen isoleren om e.e.a. te bewerkstellingen. In dergelijke situaties kan onderstaande structuur oplossing bieden.

In dat model kunnen gebruikers inloggen middels een URL die er als volgt uitziet:

Middels dit model gebruik je drie aparte front-end servers, waarbij drie verschillende organisaties worden gehost, met drie verschillende codes op schijf. Aangezien alle front-end-servers worden beschouwd als een onderdeel van dezelfde deployment, beginnen de moeilijkheden zich enigszins verder stroomafwaarts voor te doen.

Het wordt namelijk echt een uitdaging, als uw oplossing gebruik maakt gebruik van asynchrone plug-ins of workflows, want terwijl u wel kunt bepalen welke servers uw gebruikers gebruiken, kunt u niet bepalen welke asynchrone service het proces zal uitvoeren.Dit komt omdat alle asynchrone services werken op een round-robin manier waardoor er geen sprake is van isolatie van één of meerdere CRM servers.

Bovendien is het zo, dat u versie conflicten krijgt als uw aangepaste code, welke aanwezig is op de harde schijf op de server, wordt gerund door dit asynchroon proces. Het is belangrijk op te merken dat het grootste deel van deze uitdagingen alleen ontstaan wanneer u aangepaste code inzet op de harde schijf.Als uw oplossing simpel is en alleen aanpassingen (schema's, formulieren, opvattingen, enzovoort), workflows en rapporten gebruikt, zult u geen problemen met de aanpak in bovenstaande afbeelding.

Dus wanneer is multi-tenancy interessant? Multi-tenancy was oorspronkelijk ontworpen voor het oplossen van een hardware-probleem met betrekking tot de hosting van meerdere afzonderlijke huurders in een productie omgeving, en doet dit ook erg goed. Multi-tenancy zie je dus vooral bij gehoste versies van CRM-waaronder Microsoft Dynamics CRM Online.