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)

Beware of Dynamics 365 Web API: When attribute and entity have same names

With increasing maturity of the OData Web API exposed by Dynamics 365 CE/CRM its adoption does also steadily increase. From my perspective especially from JavaScript client codes. While the Web API doubtlessly has its sweetspots, it also comes with a lot of pitfalls and limitations (yet) we must get comfortable with and become aware of.

One of these pitfalls which I want to recall today, was already covered back in 2017 by Tip #970: When attribute and entity collide and goes like this:

While (technically) the CRM platform allows an attribute to have the same name as the entity it is defined on, the OData Web API is not capable of handling this and simple throws an “Could not find a property” HTTP 400 error.

Keep in mind when designing the entity model: Avoid naming collisions by never giving an attribute the same schema name as its parent entity.

CRM Online does arbitrarily reduce batch request size / How to intelligently adjust batch size of ExecuteMultipleRequest when request limit is hit

As most of you know, yesterday the Microsoft Azure platform and several of its services/resource types like VSTS and Dynamics 365 were affected by outages and connectivity issues.

I have been affected by this since I was performing regression and penetation tests on a Azure-hosted integration system to a Dynamics 365 system which had its go-live last week. The aforementioned outages manifested as miscellanous network connectivity issues/timeouts and several CRM organization services not responding.

However, one effect caught my attention:

In our custom developed CRM/ERP integration system we make heavy use of ExecuteMultipleRequests and thus, of course, know all restrictions, particularities and limitations inside out. Especially regarding the maximum batch size (ImportSetting.BatchSize), I thought to be aware of. To be more precise, CRM Online by default has a fixed limit of 1000 Organization Requests that may be — simply said — “bundled” into a single ExecuteMultipleRequest and then are executed together in a single physical request to the CRM organization.

Yesterday however, I noticed that many ExecuteMultipleRequests suddenly began to raise service faults saying that the maximum batch size is exceeded which turned on the alert lamps in my mind. Since I conducted the tests and the used fixtures/data by myself and thus know them, and the fact that we used a maximum of 999 requests per ExecuteMultipleRequest, I could surely exclude the reason for these faults to be on our side.

This leads me to the conclusion, the Microsoft could automatically decrease the maximum batch size limit in Dynamics 365 Online organizations in situations where they need to reduce pressure/resource consumption in their cloud landscape. I did not find similar reports on the interweb yet, but will keep this in my backhead for clarification at given time.

Did you encounter a similar behaviour?

Solution

As a solution I wrote a simple proof-of-concept for a mechanism that “intelligently” lowers the number of organization requests put into a single ExecuteMultipleRequest when it attempts a service fault related to MatchBatchSize transgressions. Funny detail: It needs no privileged user account for retrieving a deployment setting but instead uses the “MaxBatchSize” value contained in the service fault detail data object.