Multiplexing in Dataverse und Dynamics 365
Multiplexing ist ein Lizenzthema, das in Dataverse-Projekten häufig erst spät auffällt, weil es weder im Code-Review noch im Test sichtbar wird. Dieser Beitrag erklärt die Definition, die typischen Auslöser und die Konsequenzen für die Architektur.
Definition
Section titled “Definition”Microsoft definiert Multiplexing als den Einsatz von Hard- oder Software, um Verbindungen zu bündeln, Informationen umzuleiten oder die Anzahl der Nutzer beziehungsweise Geräte zu reduzieren, die direkt auf einen Dienst zugreifen.
Die zentrale Regel: Multiplexing reduziert die Anzahl der benötigten Lizenzen nicht. Jeder Nutzer und jedes Gerät, das Daten aus Dynamics 365 oder Dataverse liest oder schreibt, benötigt eine passende Lizenz. Das gilt unabhängig davon, ob der Zugriff direkt über die Oberfläche oder indirekt über eine zwischengeschaltete Anwendung erfolgt. Eine gebündelte Verbindung über ein Service-Konto verschiebt die technische Sichtbarkeit des Zugriffs, nicht die Lizenzpflicht.
Wie Multiplexing entsteht
Section titled “Wie Multiplexing entsteht”Multiplexing ist meist nicht beabsichtigt, sondern ergibt sich aus üblichen Integrationsmustern:
- Ein Service-Konto (non-interactive user) greift über die Web-Service-Schicht auf Dataverse zu, während mehrere Personen die dahinterliegende Anwendung nutzen.
- Eine Middleware oder ein eigenes Portal liest Daten aus Dataverse und stellt sie Nutzern bereit, die selbst keinen Dynamics-Zugang haben.
- Ein Integrationsfluss über Power Automate, Azure-Integration oder eine eigene Anwendungsschicht bewegt Daten zwischen CRM und ERP.
In diesen Fällen registriert das System genau einen technischen Zugriff. Für die Lizenzierung zählen jedoch die Personen, die die Daten tatsächlich nutzen.
Typische Szenarien
Section titled “Typische Szenarien”Datenintegration zwischen CRM und ERP
Section titled “Datenintegration zwischen CRM und ERP”Ein Vertriebsmitarbeiter legt einen Kunden in Dynamics 365 an. Teile dieser Daten fließen in ein ERP-System (zum Beispiel SAP oder Dynamics 365 Finance & Operations), werden dort qualifiziert und zurückgespielt. Die ERP-Nutzer greifen damit indirekt auf die CRM-Daten zu und benötigen je nach Datenart eine entsprechende Lizenz.
Automatisierte Datenbewegung
Section titled “Automatisierte Datenbewegung”Wenn Power Automate Daten aus Dataverse exportiert und wieder importiert, sind die Endnutzer, die diese Daten anschließend einsehen oder bearbeiten, lizenzpflichtig. Maßgeblich ist, ob es sich um eingeschränkte oder uneingeschränkte Daten handelt und ob der Zugriff direkt oder indirekt erfolgt.
Eigene App oder Portal vor Dataverse
Section titled “Eigene App oder Portal vor Dataverse”Eine selbst entwickelte Web-App oder ein Portal, das über eine API auf Dataverse zugreift, hebt die Lizenzpflicht nicht auf. Interne Nutzer, die Dynamics-Daten über diese Zwischenschicht konsumieren, müssen lizenziert sein, auch wenn sie nicht als Dynamics-Nutzer angelegt sind.
Eingeschränkte und uneingeschränkte Daten
Section titled “Eingeschränkte und uneingeschränkte Daten”Nicht jeder indirekte Zugriff erfordert eine volle Dynamics-365-Lizenz. Diese Unterscheidung ist für die Architektur relevant:
- Indirekter Zugriff auf eingeschränkte (restricted) Tabellen, also die klassischen Dynamics-365-Entitäten, erfordert eine Dynamics-365-Lizenz.
- Bei ausschließlicher Arbeit mit uneingeschränkten Daten (Custom- beziehungsweise Power-Platform-Tabellen) kann eine Power-Platform-Lizenz ausreichen.
Zwei Beispiele aus der Microsoft-Guidance verdeutlichen den Unterschied:
- Ein Nutzer exportiert über Power Platform D365-Daten und stellt sie Kollegen zur Verfügung, die diese nur ansehen. Erforderlich ist eine Power-Lizenz, keine D365-Lizenz.
- Dieselben Kollegen bearbeiten die Daten, und die Änderungen fließen nach Dataverse zurück. In diesem Fall ist zusätzlich eine D365-Lizenz erforderlich, weil die D365-Daten indirekt verändert werden.
Ausnahme: manuelle Neueingabe
Section titled “Ausnahme: manuelle Neueingabe”Ein angemessen lizenzierter Nutzer darf Informationen von nicht lizenzierten Personen manuell neu eingeben (rekey). Sobald ein automatisierter Prozess diese Übertragung übernimmt, greift die Lizenzpflicht wieder.
Technische Durchsetzung
Section titled “Technische Durchsetzung”Seit dem 1. April 2024 führt Microsoft zusätzliche In-Product-Checks ein, die die tatsächliche Nutzung mit den Nutzungsrechten abgleichen, sowohl in der Oberfläche als auch auf der API-Ebene. Multiplexing ist damit nicht mehr ausschließlich ein Audit-Thema, sondern wird zunehmend technisch geprüft.
Hinweise für die Architektur
Section titled “Hinweise für die Architektur”- Datenpfade früh klären: Entscheidend ist, welche reale Person am Ende der Kette steht, nicht der technische Aufbau.
- Keine Microsoft-Komponente als primären Speicherort für exportierte Daten verwenden, da dies zusätzliche Lizenz- und Kapazitätsfolgen auslösen kann.
- Eingeschränkte und uneingeschränkte Tabellen bewusst trennen, um indirekte Zugriffe auf die jeweils passende Lizenzklasse zu begrenzen.
- Service-Konten nicht als Schlupfloch behandeln. Die Lizenzen für die Personen hinter dem Konto sind einzuplanen.
- Im Zweifel den aktuellen Licensing Guide prüfen, da sich die Regeln ändern.
Zusammenfassung
Section titled “Zusammenfassung”Eine technische Integration reduziert die Lizenzkosten nicht, sondern verschiebt nur, an welcher Stelle der Zugriff sichtbar wird. Wer Multiplexing bereits in der Konzeptphase berücksichtigt, vermeidet spätere Nachforderungen.
Dieser Beitrag fasst die Microsoft-Lizenzregeln zu Multiplexing für Dataverse und Dynamics 365 zusammen und dient der Orientierung. Er ersetzt keine verbindliche Lizenzberatung. Maßgeblich ist der jeweils aktuelle Microsoft Licensing Guide.