Over meerdere online omgevingen of tenants
De apps voor klantbetrokkenheid (Dynamics 365 Sales, Dynamics 365 Customer Service, Dynamics 365 Field Service, Dynamics 365 Marketing) bieden u opties om uw gegevens en gebruikerstoegang te scheiden. Voor de meeste bedrijven leidt het toevoegen en gebruiken van meerdere Power Platform-omgevingen tot de juiste mix van functionaliteit en beheergemak. Bedrijven met aparte entiteiten die mogelijk map en licenties willen scheiden kunnen overwegen meerdere tenants te gebruiken. Meerdere omgevingen zijn toegankelijk voor alle gebruikers in de tenant. Meerdere tenants moeten andere tenantgebruikers uitnodigen als gastgebruikers om ze toegang te verlenen.
Gebruik van meerdere omgevingen
Omgevingen 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 omgeving voor een specifiek doel, zoals productie, Training, Testen en Ontwikkeling.
Er zijn meerdere omgevingen nodig als scheiding vereist is van gegevens, invoegtoepassingen, werkstromen of beheerresources die niet gemakkelijk kunnen worden gescheiden met business units.
Een installatie met meerdere omgevingen
Een doorsnee klant heeft slechts één tenant. Een tenant kan een of meer omgevingen bevatten; een omgeving is echter altijd gekoppeld aan één tenant.
In dit voorbeeld worden twee omgevingen gebruikt voor drie teams: Verkoop, Marketing en Services.
Verkoop en Marketing delen een omgeving zodat informatie over leads eenvoudig door beide kan worden gebruikt. Services heeft een eigen omgeving zodat tickets en garanties apart kunnen worden beheerd van campagnes en andere verkoopgebeurtenissen.
U kunt gemakkelijk toegang tot een of beide omgevingen bieden. Verkoop en Marketing-gebruikers kunnen beperkt zijn tot hun omgeving terwijl Service-gebruikers met uitgebreide toegang records voor ondersteuningsescalatie met betrekking tot accounts in beide omgevingen kunnen bijwerken.
Over één tenant met meerdere omgevingen:
Elk omgeving binnen de tenant krijgt een eigen SQL-database.
Gegevens worden niet tussen omgevingen gedeeld.
Zie Microsoft Dataverse-opslagcapaciteit voor informatie over hoe opslag wordt gedeeld tussen omgevingen.
Omgevingen in een enkele tenant worden standaard gemaakt in de geografische regio waar de klant zich heeft aangemeld voor een account. Bovendien kan de maker van de omgeving ervoor kiezen om de omgeving in een andere geografische regio te maken. Toegestane geografische regio's worden weergegeven voor de gebruiker om uit te kiezen. In bepaalde omstandigheden moeten gebruikers alle regio's die door Power Platform worden ondersteund, kunnen zien of selecteren.
Het gebruik van opslagruimte wordt opgeteld en bijgehouden in alle omgevingen die aan een klanttenant zijn gekoppeld.
U kunt afzonderlijke beveiligingsgroepen voor omgevingen instellen als u wilt bepalen wie een omgeving kan zien en openen.
Een gebruiker met een licentie kan potentieel toegang krijgen tot alle omgevingen die aan de tenant zijn gekoppeld. De toegang wordt bepaald door het lidmaatschap van de omgevingbeveiligingsgroep.
Waarom meerdere omgevingen gebruiken?
Hieronder volgen veel voorkomende situaties waarin installaties met meerdere omgevingen 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 omgevingen zodat elke omgeving 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 de lokale omgeving, waarbij ze vervolgens worden doorgegeven aan de hoofdomgeving.
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/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 omgeving 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 omgeving toevoegen aan uw abonnement
Zie Omgevingen maken en beheren voor informatie over het toevoegen van een omgeving aan uw tenant.
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.
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 omgevingen zijn gekoppeld. Gegevens worden niet gedeeld tussen omgevingen 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 omgevingen die aan diezelfde tenant zijn toegewezen. Als een gebruiker toegang wil krijgen tot een andere tenant, moet hij of zij worden uitgenodigd als gastgebruiker en moet mogelijk een afzonderlijke licentie worden toegewezen.
Elke tenant vereist een of meer Microsoft Power Platform-beheerders met unieke aanmeldreferenties en elke tenantrelatie beheert de tenant apart in de beheerdersconsole.
Meerdere omgevingen 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 omgeving 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 omgevingen 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.