Team Member Lizenz: Workaround Custom App Zugriffslimitierung (4/4)

Wie eingangs erwähnt, werden Benutzer mit TML fortan keinen Zugriff haben mehr auf benutzerdefinierte Model-driven Apps sowie die Standard Hub Apps der Hauptprodukte wie z.B. Customer Service, Sales und Project Service Automation. Diese Limitierung ist sehr drakonisch und weitreichend, wo sie doch typische TML Anwendungsfälle wie z.B. kleine hochspezialisierte Fachanwendungen (in Form von Model-driven Apps) untersagt. Damit trifft Microsoft eine scharfe Abgrenzung zur generischen PowerPlatform mit deren eigenständiger PowerApp Lizenzierung. Stattdessen führt Microsoft in der 2020 RW1 eigens für Team Members drei neue Model-driven Apps ein, bei welchen es sich sich jeweils um stark reduzierte und TML-kompatible Alternativen ihrer entsprechenden Hub Apps handelt.

Im Falle der Customer Service Team Member App richtet sich diese jedoch meiner Meinung nach nicht an unternehmens-interne Benutzer, wie man erwarten würde, sondern sie ist standardmässig so konfiguriert, dass sie für den eigentlichen unternehmens-externen (End-)Kunden geeignet ist, um quasi einen Self-service Anwendungsfall abzubilden. Vermutlich deswegen wird sie auch nicht standardmässig installiert, sondern muss vom D365 Administrator explizit installiert werden.

Glücklicherweise können die drei Team Member Apps gecustomized werden, sodass also wie gewohnt je nach Anwendungsbereich individuelle App Experiences implementiert werden können, solange hierbei die Team Member Lizenzbedingungen erfüllt werden.

Doch sollte einem Nebensatz im License Guide besondere Aufmerksamkeit gewidmet werden:

“… Customization [of the standard Team Member Apps] is only allowable if it does not result in a change to core purpose of the specified scenario …”

D365 License Guide, Stand 02/2020

Dieser Vermerk ist zwar sehr schwammig formuliert und lässt somit viel Raum zur freien Interpretation, doch dürfte klar sein worauf Microsoft hinaus möchte.

Abbildung 1: Eigenschaften der Model-driven App “Sales Team Member”; Eindeutiger Name sowie folglich der Deeplink der App können nicht modifiziert werden

Team Member Lizenz: Get ready! (3/4)

Herstellen Team Member Lizenzkompatibilität

Nachdem nun feststeht welche Systembenutzer konform mit der TML sind und welche nicht, stellt sich die nächste entscheidende Frage: für welche Benutzer/-gruppen kommt dieser Lizenztyp überhaupt infrage? Und weiter: Wie können diese “kompatibel” mit dem Team Member Lizenztyp gemacht werden?

Kurzfassung: Es müssen spezialisierte, mit der TML konforme, Benutzerrollen konzipiert werden (1) und anschliessend entsprechende Sicherheitsrollen implementiert werden (2).

Konzeption

Es gibt hierbei keine Musterlösung, vielmehr ist dieser Reviewprozess so individuell wie die möglichen kundenspezifischen Anwendungsbereiche von Dynamics 365 selbst. Dabei hilfreich ist ein gut dokumentiertes Sicherheitskonzept, welches neben den eher technischen Sicherheitsrollen insbesondere auch typische Benutzerrollen (Personas) im Kontext Ihrer Dynamics 365 Lösung beschreibt. Letztere sind Grundlage für eine erste grobe Kosten-Nutzen-Rechnung, um die zu erwartenden Aufwände für Review und Rekonzeption des Sicherheitskonzepts den möglichen Einsparungen durch die günstigeren TML gegenüber zu stellen. Trotz möglicher Einsparungen von bis zu 80% pro Benutzer, lohnen umfangreiche Rekonzeptionsmassnahmen am Sicherheitskonzept sowie dessen Implementierung meist nur ab einer gewissen (höheren) Benutzerzahl.

Bei der Suche nach Optimierungspotenzial können folgende offensichtliche Indikatoren zur ersten Orientierung dienen:

  • Anzahl Benutzer
  • Anzahl Vollzugriffe auf Entities je Benutzer

 Mit dem Tool “Team License Checker” haben wir im vorherigen Kapitel als Schwellenwert “15” angegeben, um einen ersten raschen Überblick zu bekommen welche Benutzerkonten denn das Maximum überschreiten und daher nicht konform mit der TML sind. Erhöhen wir diesen Schwellenwert nun z.B. auf “250”, so ergibt sich ein präziseres Bild der Situation:

Abbildung 3: Alle Systembenutzer mit Details

Wir sehen nun, wie viele Entitätsberechtigungen (exkl. der laut License Guide zulässigen Standardentitäten) konkret jeder einzelne Benutzer besitzt und folglich wie viele Benutzer aktuell in-/kompatibel mit der TML sind. Von hier aus können nun weitere Überlegungen angestellt werden.

Nachfolgend zur Hilfestellung eine Frageliste mit wesentlichen Punkten:

  • Benötigen tatsächlich alle Benutzer mit dieser Sicherheitsrolle Vollzugriff auf die definierten Entitäten?
  • Wie häufig machen die Benutzer Gebrauch von ihren erweiterten Zugriffsrechten?
  • Um wie viele Entitäten müsste der Vollzugriff reduziert werden, um unterhalb der maximal 15 zulässigen Entitätsvollzugriffe zu bleiben?
  • Sind alle übrigen Team Member Lizenzbedingungen ebenfalls umsetzbar für möglichen Benutzerrollen? (s. D365 Licence Guide, Abschnitt B)
  • Gibt es neben der Team Member Lizenz noch weitere Lizenzarten, die zum Zugriffsprofil einzelner Benutzer passen und gleichzeitig kostengünstiger sind?

Eine weitere konzeptionelle Limitierung ergibt sich zudem indirekt über die in Kapitel 3 behandelte Limitierung “Workaround Custom App Zugriffslimitierung”: pro Dynamics 365 Business App (Customer Service, Sales oder Project Service Automation) steht nur eine einzige Team Member App zur Verfügung. Das bedeutet, dass einer der Hauptvorteile von Model-driven Apps, nämlich das Erstellen von schlanken hochspezialisierten “Mini-Fachanwendungen”, nur bedingt ausgenutzt werden kann. Denn zwar kann mehr als eine Benutzerrolle konzipiert und implementiert werden, doch müssen sich all diese eine einzige Model-driven App “teilen”. Anstatt reduzierter scharf abgegrenzter “Mini-Fachanwendungen”, müsste die eine Team Member App entsprechend umfangreich ausgestattet werden, um die Anforderungen aller in ihr vereinten Benutzerrollen abzubilden.

Abbildung 4: Stark vereinfachter Lizenz Matchplan; Als Restricted Entities (z.B. Anfrage, Wissensartikel, SLA usw.) gelten alle produkt-spezifischen Entities für die eine Dynamics 365 Lizenz erforderlich ist ➡ Weiterführende Details

Implementierung

Wurden spezialisierte Benutzerrollen bzw. Personas identifiziert und deren benötigte Zugriffsrechte definiert, kann die Implementierung erfolgen. Der Einfachheit halber empfiehlt sich in diesem Fall pro Persona eine eigene Sicherheitsrolle, welche gründlich und so schlank wie möglich konfiguriert wird. Denn bei der Prüfung und Durchsetzung der Team Member Lizenzbestimmungen zieht Microsoft Dynamics 365 die Sicherheitsrollen heran, welche einem Benutzer zugewiesen wurden oder welche er als Mitglied eines Teams geerbt hat. Eine einzige Unachtsamkeit wie bspw. ein Schreib-Privileg zu viel, führt zum Verstoß gegen die Lizenzbestimmung.

Es muss daher vom Systemadministrator bzw. Customizer sichergestellt werden, dass 

  1. Sicherheitsrollen exakt so konfiguriert werden wie im Sicherkonzept definiert (Achtung auf jedes einzelne Privileg!)
  2. Benutzer nur exakt eine Sicherheitsrolle bekommen, welche ihrer Rolle bzw. Persona laut Sicherheitskonzept entspricht
  3. Benutzer je nach verwendeter Team Member App die dazugehörige vordefinierte Sicherheitsrolle bekommen, um überhaupt Zugriff auf ebendiese zu erhalten  (am Beispiel der “Sales Team Member App” wäre das die Sicherheitsrolle “Sales Team Member”)

Team Member Lizenz: Bist du ready? (2/4)

Prüfen auf Team Member Kompatibilität

Um für einen Benutzer zu prüfen ob dieser konform zur TML ist, muss geprüft werden über welche Sicherheitsrollen/-privilegien dieser verfügt und in welchem Umfang er hierdurch Zugriff auf Standard- und Custom Entitäten erlangt.

 Konkret müssen hierzu alle Rollenzuweisungen und -vererbungen (via Teammemberships) bestimmt werden, um anschliessen deren verschiedenen Privilegmatrizen zu addieren. Dies kann entweder manuell erfolgen oder ein 3rd-party Tool wie bspw. das XrmToolbox Plugin “Team Member License Checker” benutzt werden. Letzteres wird vom Autor dieses Handouts als vertrauenswürdig eingestuft, wird daher an dieser Stelle auch empfohlen, weil es die Privilegprüfungen teils automatisch und somit weniger fehleranfällig durchführt. Außerdem bietet es nützliche Zusatzinformationen.

Abbildung 1: XrmToolbox Dialog “Team Member License Checker”. 1) Warnungsschwellenwert Anzahl Custom Entitäten, 2) Nur Verstösse anzeigen 3) zu ignorierende Publisher-Präfixe (per Default werden MS-interne Präfixe ignoriert, da Systemstandard)

Nachdem als Schwellenwert bei der Berechnung von (Custom) Entities mit Vollzugriff der Wert 15 eingetragen und der Berechnungsvorgang mit einem Klick auf “Run” gestartet wurde, kann das Ergebnis wie folgt aussehen:

Abbildung 2: XrmToolbox Dialog “Team Member License Checker”. 1) zu ignorierende Publisher-Präfixe 2) Anzahl (Custom) Entities mit Vollzugriff 3) Vollständige Liste der Entitäten mit Lese-/Vollzugriff des selektierten Users

Die Auswertung der Ergebnisse gestaltet sich nun recht einfach. In der Ergebnisliste ist nun pro Systembenutzer einfach abzulesen ob er stand heute innerhalb des Maximums von 15 Entitätszugriffen liegt oder dieses überschritten hat und somit nicht konform mit der Team Member Lizenzbestimmung ist. 

Wichtig: hierbei zählen sowohl Custom als auch Standard Entities, für welche der betreffende Benutzer Vollzugriff besitzt. Ausserdem ganz interessant, zu sehen wie viele Entitäten jeweils pro Publisher-Präfix darunter fallen und welche Entitäten es genau für einen beliebigen Benutzer sind (hierzu einfach die Zeile des Benutzers selektieren).

Besonderheiten der Dynamics 365 Team Member Lizenz (1/4)

Bereits im Oktober 2018 kündigte Microsoft weitreichende Änderungen der preislich sehr attraktiven Team Member Lizenzen (TML) an. Auch wenn diese geänderten Lizenzbestimmungen bereits seit ihrer Ankündigung galten, unternahm Microsoft bisher keine Massnahmen um die Einhaltung ebendieser aktiv in den D365 Organisationen zu überprüfen und ggf. durch restriktive Eingriffe auch konsequent durchzusetzen. Dies wird sich jedoch schon bald ändern, denn Microsoft hat einen verbindlichen Stichtag kommuniziert, an welchem die geänderten Team Member Lizenzbestimmungen endgültig in kraft treten und auch aktiv durchgesetzt werden: und zwar beginnend am 01.04.2020. [efn_note] Im Februar 2020 kommunizierte Microsoft an ausgewählte Bestandskunden eine weitere Grace Period, in welcher bis Ende Juni 2020 noch keine konkrete Restriktionen greifen. Dies gilt nicht für alle D365 Lizenzen, daher besprechen Sie Ihre aktuelle Lizenzsituation unbedingt im Detail mit Ihrem Ansprechpartner der Isolutions AG. [/efn_note]

Hier gehts zum Dynamics 365 Lizenzierungsguide

Stand: Februar 2020

Nachfolgend werden einige Auswirkungen der Team Member Lizenzänderung behandelt und mögliche Handlungsempfehlungen ausgesprochen. Dabei handelt es sich um die beiden wesentlichen Themen “Nutzung von Model-driven Apps” sowie “Entitätszugriffsrechte”. Neben diesen beiden Themen gibt es noch zahlreiche weitere Lizenzbedingungen deren Behandlung jedoch den Rahmen dieses Handouts sprengen würden, weswegen jedem interessierten Leser dringend angeraten sei (insbesondere Anhänge A, B und D) den oben verlinkten License Guides zu konsultieren.


Ich werde zunächst einige Auswirkungen der Team Member Lizenzänderung erläutern und mögliche Handlungsempfehlungen aussprechen. Dabei handelt es sich um die beiden wesentlichen Themen Nutzung von Model-driven Apps sowie Entitätszugriffsrechte. Neben diesen beiden Themen gibt es noch zahlreiche weitere Lizenzbedingungen deren Behandlung jedoch (im Moment noch) den Rahmen dieser angedachten Artikelserie sprengen würden, weswegen jedem interessierten Leser dringend angeraten sei (insbesondere Anhänge A, B und D) den oben verlinkten License Guide zu konsultieren.

Auswirkungen

 Zunächst einmal werden Benutzer, denen eine Team Member Lizenz (TML) zugeordnet ist, keinen Zugriff mehr haben auf folgende Apps:

BezeichnungHerkunft Bemerkung
Customer Service (CS)StandardModel-driven App
Sales (SFA)StandardModel-driven App
Project Service Automation (PSA)StandardModel-driven App
<beliebige>CustomKein Zugriff auf jedwede benutzerdeifnierte App; egal ob Model-driven oder Canvas

Stattdessen wird es beginnend mit der Version 2020 Release Wave 1 im Systemstandard drei neue Model-driven App geben, welche eigens für TML bestimmt sind und diesen vom Administrator auch zugänglich gemacht werden können. Bei diesen handelt es sich jeweils um stark reduzierte und TML-kompatible Alternativen ihrer entsprechenden Hub Apps:

Customer Service Team Member 
Sales Team Member 
Project Resource Hub 

Ferner werden die Zugriffsberechtigungen auf Entitäten und sonstige Systemfunktionen limitiert. Hierzu werden alle Sicherheitsrollen herangezogen welche einem Benutzer entweder direkt zugewiesen wurden oder die er im Rahmen einer Teammitgliedschaft “geerbt” hat. Im wesentlichen wird hierbei unterschieden zwischen Lesen (Read) und Vollzugriff (Create, Update, Delete usw.). Lese-Zugriff ist unlimitiert sodass ein Team Member weiterhin lesend auf alle Entitäten zugreifen kann welche ihm seine zugewiesenen Sicherheitsrollen erlauben. Vollzugriff ist für Team Members fortan nur noch für bestimmte Standardentitäten möglich, insbesondere:

 Aktivitätenactivitypointer
Ankündigungenbusinessunitnewsarticle
Kontaktecontact
Notizenannotation
Persönliche Ansichtenuserquery

Von der Lizenzbeschränkung ausgenommene Standardentities

Zusätzlich ist Team Membern der Vollzugriff auf maximal 15 Custom Entities erlaubt. Als Custom Entity zählen alle Entitäten welche nicht Teil des Systemstandards sind, also von Microsoft im Rahmen eines Dynamics 365 Moduls entwickelt und verwaltet werden. Hierbei ist zu beachten, dass ebenfalls Entitäten aus Lösungen von 3rd-party Anbietern (ein prominentes Beispiel wäre das Produkt MscrmAddons DocumentsCorePack) als Custom Entity zählen, sowie auch Business Process Flows (besteht technisch aus separater Entity).

Achtung: Wird bei einem Systembenutzer eine der oben genannten Limitierungen überschritten, z.B. aufgrund einer Unachtsamkeit bei der Konfiguration einer Sicherheitsrolle (ein Privileg zu viel), so gilt dieser als nicht-konform mit der TML.

Handlungsempfehlungen

Der Übersichtlichkeit wegen habe ich die Empfehlungen in separate Folgeartikel gegliedert und so auch den ersten Grundstock für eine Artikelserie zum allgemeinen Überthema “Lizenzierung” gelegt. In dieser Serie will ich zukünftig diverse Themen aufgreifen und möglichst praxisnah erörtern.

  1. Prüfen auf Team Member readiness
  2. Herstellen von Team Member Kompatibilität
  3. Workaround Custom App Zugriffslimitierung
  4. Auswirkungen auf CDS Storage
  5. Gotchas der PowerApp Lizenzierung

Schlusswort

Das Thema Lizenzierung rund um Dynamics 365 und die gesamte Power Platform ist mittlerweile derart komplex und vielschichtig geworden, dass es meiner Meinung nach einer separate Beraterrolle bedarf, die quasi die Brücke zwischen technischen Implementierungsaspekten und den umfangreichen Lizenzbestimmung mit all ihren Zwischentönen bildet. Ob Microsoft seine Lizenzmodelle auch zukünftig derart grundlegend überarbeitet, halte ich für eher unwahrscheinlich, da es sich bei den jüngsten Änderungen doch viel mehr um längst überfällig Adaptionen an die ganzheitliche Plattformvision im Cloud Kontext handelt. Als wahrscheinlicher sehe ich eher die stetige fein-/justierung der Lizenzmodelle im Zuge der Weiterentwicklungen der zahlreichen Dienste und Features.

Eine fundierte Prüfung ob vorhandene Dynamics 365 Lizenzen optimiert und somit dauerhaft Kosten eingespart werden können (man berücksichtige auch die Rekonzeptionsmassnahmen), gestaltet sich, wie zuvor gesehen, komplexer als man ursprünglich vermuten würde. Es bedarf hierzu einer sehr differenzierten Betrachtung und eines umfassenden Verständnisses der License Guides von Dynamics 365 sowie der Power Platform mitsamt ihrer diversen “lizenzphilosophischen” Nebensätze. Klarheit sollte jedoch auch über die (konzeptionellen) Grenzen von Team Member Lizenzen herrschen:  

Auszug “Team Members” aus Dynamics 3665 License Guide (Stand: Februar 2020)