Meerdere online exemplaren of tenants

Modelgestuurde apps in Dynamics 365, zoals Dynamics 365 Sales en Customer Service, bieden u opties voor het gescheiden houden van uw gegevens en gebruikerstoegang. Voor de meeste bedrijven leidt het toevoegen en gebruiken van meerdere exemplaren in uw abonnement tot de juiste mix van functionaliteit en beheergemak. Bedrijven met geografisch gescheiden locaties kunnen overwegen meerdere tenants te gebruiken om licenties van elkaar te scheiden. Meerdere exemplaren kunnen gebruikers delen tussen exemplaren, meerdere tenants kunnen dat niet.

Notitie

Het concept en de werking van tenants en exemplaren lijkt op elkaar, maar verschilt tussen online en on-premises implementaties van Dynamics 365. Dit onderwerp is bedoeld voor beheerders van installaties.

Woordenlijst

Term Definitie
Tenant Voor modelgestuurde apps in Dynamics 365 is een tenant de account die u maakt in de Microsoft Online Services-omgeving wanneer u zich aanmeldt voor een abonnement. Een tenant bevat uniek geïdentificeerde domeinen, gebruikers, beveiligingsgroepen en abonnementen en kan meerdere exemplaren bevatten.

De tenant die voor u wordt gemaakt, heeft de domeinnaam <account>.onmicrosoft.com. Bijvoorbeeld contoso.onmicrosoft.com.
Exemplaar Als u een proefversie registreert of een abonnement aanschaft, wordt een productie-exemplaar gemaakt. Elk extra productie- of niet-productie-exemplaar (Sandbox) dat u toevoegt maakt een aparte en geïsoleerde organisatie binnen dezelfde tenant.

Een exemplaar heeft de URL-indeling: https://<URL-naam>.crm.dynamics.com. Bijvoorbeeld: https://contososales.crm.dynamics.com.
Multiregionaal exemplaar Een exemplaar in een andere regio dan waar uw tenant zich bevindt. Lokale exemplaren kunnen gebruikers in die regio een snellere gegevenstoegang bieden. Meer informatie: Multiregionale exemplaren toevoegen en bewerken
Abonnement Een abonnement bestaat uit de licenties en invoegtoepassingen die deel uitmaken van de proefversie of de betaalde service waarvoor u zich hebt aangemeld bij uw account. Abonnementen kunnen variëren in licentietype, prijs en einddatum.

Een abonnement kan bijvoorbeeld bestaan uit 100 licenties voor Dynamics 365 Professional en 10 licenties voor Dynamics 365 Enterprise.
Identiteit Het gebruikersaccount dat werd gebruikt om in te loggen bij modelgestuurde apps in Dynamics 365. U kunt deze identiteit ook gebruiken voor toegang tot andere Microsoft Online-services, zoals Office 365 of SharePoint Online. Beheerders kunnen bepalen of ze gebruikeridentiteitsbeheer tussen modelgestuurde apps in Dynamics 365 en on-premises Active Directory willen federaliseren.
Gebruikersaccount Een gebruikersaccount dat door een organisatie (werk, school, non-profit) wordt toegewezen aan een van de deelnemers (werknemer, student, klant) en dat via aanmelding toegang biedt tot een of meer van de abonnementen van de organisatie op Microsoft Cloud Service, zoals Exchange Online of modelgestuurde apps in Dynamics 365. Toegang tot een online service wordt geregeld door de licentie die aan de gebruikersaccount is toegewezen.

Gebruikersaccounts worden opgeslagen in de clouddirectory van een organisatie binnen Azure Active Directory, en worden doorgaans verwijderd wanneer de gebruiker de organisatie verlaat. Organisatorische accounts verschillen van Microsoft-accounts omdat ze worden gemaakt en beheerd door beheerders in de organisatie, niet door de gebruiker.
Beveiligingsgroep Als uw bedrijf meerdere exemplaren heeft, kunt u exemplaarbeveiligingsgroepen gebruiken om te bepalen welke gebruikers met een licentie toegang hebben tot een bepaald exemplaar. Meer informatie: Gebruikerstoegang tot exemplaren controleren: beveiligingsgroepen en licenties

Gebruik van meerdere exemplaren

Exemplaren zijn qua concept vergelijkbaar met een bedrijfsgebouw van meerdere verdiepingen, waarin verdiepingen zijn geordend naar bedrijfsfuncties. Beschouw elke verdieping in het gebouw als een toepassing (Verkoop/Service/Marketing, Leveranciersbeheer, Financieel beheer) en beschouw elke eenheid binnen een verdieping als een exemplaar voor een specifiek doel, zoals Productie, Training, Testen en Ontwikkeling.

Meerdere exemplaren als eenheden in een gebouw

Er zijn meerdere exemplaren nodig als scheiding vereist is van invoegtoepassingen, werkstromen of beheerresources die niet gemakkelijk kunnen worden gescheiden met behulp van business units.

Een installatie met meerdere exemplaren

Een doorsnee installatie heeft slechts één tenant. Een tenant kan een of meer exemplaren bevatten; een exemplaar is echter altijd gekoppeld aan één tenant.

Implementatie met één tenant

In dit voorbeeld worden twee exemplaren gebruikt voor drie teams: Verkoop, Marketing en Services.

Verkoop en Marketing delen een exemplaar zodat informatie over leads eenvoudig door beide kan worden gebruikt. Services heeft een eigen exemplaar zodat tickets en garanties apart kunnen worden beheerd van campagnes en andere verkoopgebeurtenissen.

U kunt gemakkelijk toegang tot een of beide exemplaren bieden. Verkoop en Marketing-gebruikers kunnen beperkt zijn tot hun exemplaar terwijl Service-gebruikers met uitgebreide toegang records voor ondersteuningsescalatie met betrekking tot accounts in beide exemplaren kunnen bijwerken.

Over één tenant met meerdere exemplaren:

  • Een tenant kan maximaal 50 -productie-exemplaren en maximaal 75 niet-productie-exemplaren (Sandbox) bevatten.

  • Elk exemplaar binnen de tenant krijgt een eigen SQL-database.

  • Gegevens worden niet tussen exemplaren gedeeld.

  • Opslagruimte wordt gedeeld tussen het primaire exemplaar en eventuele andere exemplaren.

  • Alle exemplaren voor één klanttenant worden ingesteld in de geografie waar de klant zich heeft aangemeld voor een account. Het gebruik van opslagruimte wordt opgeteld en bijgehouden in alle exemplaren die aan een klanttenant zijn gekoppeld.

  • U kunt afzonderlijke beveiligingsgroepen instellen voor alle exemplaren.

  • Een gebruiker met een licentie kan potentieel toegang krijgen tot alle exemplaren die aan de tenant zijn gekoppeld. De toegang wordt bepaald door het lidmaatschap van de exemplaarbeveiligingsgroep.

  • U kunt extra exemplaren aanschaffen door middel van de invoegtoepassing Additional Instance. Extra exemplaren kunnen alleen worden toegevoegd aan "betaalde" abonnementen, niet aan proefversies of Internal Use Rights (IUR). Als u uw abonnement via Volume Licensing hebt aangeschaft, moet u het extra exemplaar aanschaffen via uw Large Account Reseller (LAR). Meer informatie: Facturerings- en abonnementsondersteuning

  • U kunt geen bestaande proefversies of abonnementen samenvoegen met een extra exemplaar; in plaats daarvan moet u uw gegevens en aanpassingen verplaatsen.

Waarom meerdere exemplaren gebruiken?

Hieronder volgen veel voorkomende situaties waarin installaties met meerdere exemplaren worden gebruikt. Bekijk deze voorbeelden als u het installatietype kiest dat het best past bij de eisen van uw bedrijf.

Mastergegevensbeheer

In dit scenario maakt een "master"-gegevensset wijzigingsbeheer mogelijk via een centrale mastergegevensbron. Deze methode vereist dat de centrale mastergegevens zijn gesynchroniseerd met alle exemplaren zodat elk exemplaar toegang heeft tot de meest recente versie van de kerninformatie. De gewenste wijzigingen in de gegevens kunnen direct in het hoofdsysteem worden aangebracht. Gebruikers kunnen ook expliciet toegang tot het hoofdsysteem krijgen of de wijzigingen vastleggen in het lokale exemplaar, waarbij ze vervolgens worden doorgegeven aan het hoofdexemplaar.

Vereisen dat wijzigingen centraal worden aangebracht kan leiden tot gecentraliseerd wijzigingsbeheer. Antifraudecontroles kunnen bijvoorbeeld worden uitgevoerd om te zorgen dat wijzigingen alleen door een centraal team worden aangebracht en niet door lokale teams die van een wijziging kunnen profiteren, bijvoorbeeld een wijziging van kredietlimieten. Dit zou een tweede niveau van wijzigingsautorisatie en -verificatie opleveren waarmee wordt voorkomen dat één persoon of een groep personen die nauw samenwerken, fraude kunnen plegen. Een aanvraag doorsturen naar een ander, onafhankelijk team kan bescherming tegen mogelijke fraude opleveren.

Beveiliging en privacy

Verschillen in regionale, bijvoorbeeld Europese (EU) of nationale wetgeving kunnen leiden tot variaties in vereisten voor het beveiligen van gegevens of het onderhouden van gegevensprivacy in verschillende regio's of landen in een installatie. In sommige gevallen maken wetgevende/regelgevende beperkingen het illegaal om gegevens buiten de grenzen van een land of regio te hosten en dit is met name erg belangrijk in bepaalde bedrijfssectoren.

Denk bijvoorbeeld aan beperkingen in de gezondheidszorg ten aanzien van het delen van patiëntgegevens. Sommige EU-verordeningen vereisen dat gezondheidsinformatie die is verzameld over personen die zich in de EU bevinden, alleen wordt onderhouden en gedeeld binnen EU-grenzen, terwijl soortgelijke gegevens die worden verzameld over personen in de Verenigde Staten (VS), binnen Amerikaanse grenzen moet worden bewaard. Zo zijn er ook in de banksector beperkingen op het delen van klantgegevens. In Zwitserland is bijvoorbeeld regelgeving van kracht die het illegaal maakt om klantgegevens buiten hun nationale grenzen te delen.

Schaalbaarheid

Eén exemplaar van kan meegroeien met het bedrijf van een klant, met uiterst hoge gegevensvolumes of complexiteitsniveaus, maar er zijn andere overwegingen. In omgevingen met extreme volumes en/of intensief gebruik van Serviceplanning kan het vergroten van de schaal van SQL Server te dure en te moeilijk te beheren infrastructuur vereisen.

Er zijn veel scenario's waarin er een natuurlijke functionele splitsing bestaat in capaciteitsvereisten. In zulke gevallen kan het delegeren van werklast door schaalvergrotingsscenario's te maken die zijn gebaseerd op deze functionele splitsingen, grotere volumes mogelijk maken met behulp van basisinfrastructuur.

Een exemplaar toevoegen aan uw abonnement

Zie Een exemplaar aan uw abonnement toevoegen voor informatie over het toevoegen van een exemplaar aan uw abonnement.

Een installatie met meerdere tenants

Wereldwijde bedrijven met verschillende regionale of landmodellen kunnen tenants gebruiken om rekening te houden met variaties in aanpak, marktomvang of naleving van juridische en regulatorische beperkingen.

Implementatie met meerdere tenants

Dit voorbeeld omvat een tweede tenant voor Contoso Japan.

Gebruikersaccounts, identiteiten, beveiligingsgroepen, abonnementen, licenties en opslagruimte kunnen niet onder tenants worden gedeeld. Aan elke specifieke tenant kunnen meerdere exemplaren zijn gekoppeld. Gegevens worden niet gedeeld tussen exemplaren of tenants.

Over meerdere tenants:

  • In een scenario met meerdere tenants kan een gebruiker met een licentie, die aan een tenant is gekoppeld, slechts toegang hebben tot een of meer exemplaren die aan diezelfde tenant zijn toegewezen. Om toegang te krijgen tot een andere tenant heeft een gebruiker een aparte licentie en een unieke set aanmeldreferenties voor die tenant nodig.

    Als gebruiker A bijvoorbeeld een account heeft om toegang te krijgen tot tenant A, kan deze gebruiker op basis van zijn of haar licentie toegang krijgen tot alle exemplaren die zijn gemaakt binnen tenant A - als dat door de beheerder wordt toegestaan. Als gebruiker A toegang moet krijgen tot exemplaren binnen tenant B, heeft hij of zij een extra licentie nodig.

  • Elke huurder vereist een tenantbeheerder met unieke aanmeldreferenties en elke tenantrelatie beheert de tenant apart in de beheerdersconsole.

  • Meerdere exemplaren binnen een tenant zijn zichtbaar vanuit de interface als de beheerder toegang heeft.

  • U kunt geen licenties opnieuw toewijzen tussen tenantinschrijvingen. Een ingeschreven relatie kan onder één inschrijving licentiereductie gebruiken en aan een andere inschrijving licenties toevoegen om dit mogelijk te maken.

  • On-premises Active Directory-federatie kan niet met meer dan één tenant tot stand worden gebracht, tenzij u domeinen van het hoogste niveau hebt die u moet federaliseren met verschillende tenants (bijvoorbeeld Contoso.com en Fabricam.com).

Waarom meerdere tenants gebruiken?

Functionele lokalisatie

Dit scenario doet zich vaak voor in organisaties met overlappende maar afzonderlijke functionele vereisten. Dit zijn enkele veel voorkomende voorbeelden:

  • Organisaties met verschillende zakelijke divisies, elk met een verschillende markt of werkmodel.

  • Wereldwijde bedrijven met regionale of landmodellen die verschillen, kunnen tenants gebruiken om rekening te houden met variaties in aanpak, marktomvang of naleving van juridische en regulatorische beperkingen.

    In dit soort bedrijfsomgevingen heeft een organisatie vaak gezamenlijke sets functionaliteit die specifieke regio's, landen of bedrijfsgebieden mogelijk maken met een zekere mate van lokalisatie op het gebied van :

  • Informatieverzameling. Het vastleggen van de 'ZIP code' in de Verenigde Staten komt bijvoorbeeld overeen met het vastleggen van de 'Post Code' in het Verenigd Koninkrijk.

  • Formulieren, werkstromen

Fysieke distributie

Voor bedrijfsoplossingen die gebruikers moeten ondersteunen die fysiek over grote afstanden verspreid zijn, met name voor wereldwijde distributies, is het gebruik van één exemplaar mogelijk niet geschikt vanwege de implicaties (zoals WAN-latentie) die het gevolg zijn van een infrastructuur waarmee veel gebruikers verbinding maken, wat grote gevolgen kan hebben voor de gebruikerservaring. Het distribueren van exemplaren om gebruikers meer lokale toegang te geven, kan WAN-gerelateerde problemen verkleinen of oplossen, omdat de toegang plaatsvindt via kortere netwerkverbindingen.

Een distributie met meerdere tenants toevoegen onder Volume Licensing

Voor een installatie met meerdere tenants hebt u een Multi-Tenant Amendment nodig. Een Multi-Tenant Amendment is een amendement op de Volume License-overeenkomst die wordt gebruikt om licenties aan te schaffen. Neem contact op met uw Microsoft-vertegenwoordiger of -reseller om het amendement te verkrijgen.

Beperkingen van meerdere tenants

Beheerders die meerdere tenants willen installeren en beheren, moeten rekening houden met het volgende:

  • Gebruikersaccounts, identiteiten, beveiligingsgroepen, abonnementen, licenties en opslagruimte kunnen niet onder tenants worden gedeeld.

  • Één domein kan slechts met één tenant worden gefederaliseerd.

  • Elke tenant moet een eigen naamruimte hebben; UPN- of SMTP-naamruimten kunnen niet door tenants worden gedeeld.

  • Als een on-premises Exchange-organisatie bestaat, kunt u deze organisatie niet splitsen over meerdere tenants.

  • Een geconsolideerde globale adreslijst zal niet beschikbaar zijn, behalve indien expliciet downstream van de synchronisatie beheerd.

  • Samenwerking tussen tenants wordt beperkt tot Lync federatie en Exchange federatiefuncties.

  • SharePoint-toegang tussen tenants kan onmogelijk zijn. Hoewel dit mogelijk met partnertoegang kan worden opgelost, wordt de gebruikerservaring verstoord en kunnen licentieoverwegingen gelden.

  • Er kunnen geen dubbele accounts zijn tussen de tenants of partities in de on-premises Active Directory.