Category: Licensing

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.

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:

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.

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”)

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.

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:

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).