Der Zugriff auf die Power BI Artefakte - das sind Dashboards, Reports, Datasets, App-Workspaces ("Gruppen") und Apps ("Pakete") - wird unter dem Begriff Access Control zusammengefaßt.

Auf PowerBI.com stehen 3 Methoden für Access Control zur Verfügung. Die Auswahl der für das eigene Unternehmen passenden Option ist entscheidend für den reibungslosen Betrieb der produktiven Power BI Anwendung und für die Einhaltung von firmenspezifischen Compliance Regeln.

---------------------------------------------------------------------

Update vom 02.03.2018

Beachten Sie bitte das Update am Ende dieses Blogposts, da seit dem Erscheinen im September 2017 bereits zahlreiche Neuerungen zur Access Control auf PowerBI.com verfügbar geworden sind.

---------------------------------------------------------------------

Szenario

Wir verwenden einen sehr simplen Showcase auf Basis des (leicht adaptierten) Financial Sample Datasets mit den folgenden beiden Rollen:

• Power User = "Robert Lochner"
• End User = "Linearis Support"

Die beiden User gehören zum gleichen Office 365 Tenant und werden daher in Power BI als Personen innerhalb der eigenen Organisation angesehen. Die folgenden Kapitel sind in je einen Abschnitt für die Power User Perspektive und für die End User Perspektive geteilt. Weiters verwenden wir hauptsächlich die englischsprachigen Bezeichnungen, da diese allgemein gültiger sind.

Voraussetzungen

Bitte beachten Sie, daß für sämtliche hier beschriebenen Instrumente entweder  (1) sowohl der Power User als auch auch der End User eine Power BI Pro Subscription benötigen oder (2) die Anwendung in einer Power BI Premium Umgebung deployed sein muß. User mit einem Free Account können ihre Dasbhoards/Reports weder mit anderen teilen noch Einladungen anderer Power BI User annehmen.

1. Access Control über die Sharing-Funktion

Die Sharing-Funktion ist die offensichtlichste Methode, um Dashboards zu teilen. Allerdings handelt es sich um eine adhoc Funktion, für den Betrieb produktiver (größerer) Dashboard-Infrastrukturen mit größeren Benutzerzahlen eignet sich diese Methode nicht. Die Sharing-Funktion wird im folgenden anhand einer Anwendung im "My Workspace" beschrieben, diese steht aber genauso bei Anwendungen in "App-Workspaces" als zusätzliche adhoc Verteilungsfunktion zur Verfügung. Für den Enduser ist der Unterschied nur anhand der Besitzer-Information zu sehen, im ersten Fall ist das die Person und im zweiten Fall der App-Workspace.

1a. Power User Perspektive

Der Power User erstellt in Power BI Desktop ein Datenmodell samt Visualisierungen (= Reports) und startet mit dem Button "Veröffentlichen" das Deployment der Anwendung auf PowerBI.com auf den eigenen "My Workspace" und setzt damit den ersten Schritt von der Desktop-Anwendung zur Multi-User Applikation:

Kurze Zeit später scheint die neue Applikation auch auf Power BI.com im Abschnitt "My Workspace" des Power Users auf:

Jetzt muß aus zumindest einem Visual des Reports (aus PBI Desktop) ein Dashboard (auf PowerBI.com) erstellt werden, da die Sharing-Funktion nur in Dashboards (Link "Freigeben") zur Verfügung steht:

Hier kann jetzt sehr simpel über die Eingabe einer E-Mail Adresse ein User - aus dem eigenen Unternehmen oder von einem anderen - zum Dashboard eingeladen werden. Um einen viralen Effekt für Unternehmensdaten zu verhindern, empfehlen wir dringend, die Option "Empfängern das Freigeben des Dashboards erlauben" jedenfalls zu deaktivieren. Anstelle des Benachrichtungsmails kann auch der Dashboard-Link kopiert und über andere Kanäle (bspw. Chat) an den Empfänger geschickt werden. Wie eingangs erwähnt, muß auch der Empfänger ("End User") nicht nur über einen Power BI Account verfügen sondern auch über eine Power BI Pro Subscription.

Nach der erfolgten Freigabe kann über den den Reiter Zugriff überprüft werden, wer bereits mit welchen Rechten zum Dashboard berechtigt wurde:

Beachten Sie bitte, daß jeder User in seinem "My Workspace" immer der Besitzer ist, und zwar der einzige. Das Besitzer-Recht kann auch nicht übertragen werden kann (siehe die fehlenden "3 Punkte" beim "Besitzer" im Screenshot oben), beim Austritt eines Mitarbeiters aus dem Unternehmen muß der "My Workspace" gelöscht werden. Aus diesem Grund dürfen keine Enterprise Anwendungen im "My Workspace" eines bestimmten User betrieben werden.

Der User verfügt daher in seinem "My Workspace" immer über sämtliche Rechte für alle darin befindlichen Anwendungen und sieht auch immer sämtliche Daten, da eine eventuelle Row-Level-Security für den Besitzer nicht greift. Weiters folgt auch, daß ein User eine Anwendung aus PBI Desktop niemals in den "My Workspace" eines anderen Users deployen kann, da er dort nicht das Besitzer-Recht haben kann.

1b. End User Perspektive

Der End User - dieser wurde in unserer Demo bei PowerBI.com neu registriert - hat seinen eigenen "My Workspace", dieser ist mangels eigener Aktivitäten in Power BI noch komplett leer:

Das freigegebene Dashboard ist für den End User im Bereich Für mich freigegeben zu finden. Die Dashboards - in diesem Fall nur eines - können in der mittleren Pane nach Besitzer (= Freigeber) gefiltert werden. Das Dashboard kann durch den End User weder bearbeitet noch gelöscht werden, das Delete-Symbol im Bereich Aktionen dient lediglich zur End-User-seitigen Aufhebung der Mitgliedschaft an diesem Dashboard:

Durch Klick auf den Balken wird das Dashboard geöffnet, entsprechend der Freigabe durch den Power User fehlt hier die Option zum Re-Sharing des Dashboards (Verhinderung eines "viralen Effekts"):

Durch Klick auf ein Dashboard Visual - wie in Power BI üblich - gelangt der End User in den zugrundeliegenden Report. Auch hier sind die eingeschränkten Access Rights beispielsweise im Menü Datei zu sehen (und an der deaktivierten "Bericht Bearbeiten"-Funktion):

Beachten Sie bitte, daß ein eingeladener User immer nur Leserechte auf das Dashboard und den/die dahinterliegenden Reports bekommen kann. Der End User kann auch keine Visuals aus dem Report weder an dieses noch an eigene Dashboards pinnen, da hiefür kein Recht besteht. Der Zugriff auf das zugrundeliegende Dataset und damit beispielsweise auf die Möglichkeit, eine Datenaktualisierung anzustoßen, besteht ebenfalls nicht.

2. Access Control über "App-Workspaces"-Mitgliedschaften

Power BI App-Workspaces wurden im Mai 2017 eingeführt und lösen die bisherigen Groups schrittweise ab. Diese dienen zur organisatorischen Loslösung von Power BI Anwendungen von einzelnen Usern (bzw. deren "My Workspace") sowie zur - häufig abteilungsweisen - organisatorischen Strukturierung und Berechtigung der Power User. Zur Berechtigung der End User werden App-Workspaces indirekt verwendet, sie bilden nämlich die Basis für die unter Punkt 3 vorgestellten "Apps".

Heute sind die App-Workspaces noch 1:1 mit Office 365 Groups verbunden, sodaß hier besonders darauf geachtet werden muß, daß die dort aufgebauten Strukturen nicht durch Power BI konterkariert werden. Diese Verbindung soll laut Roadmap aber aufgehoben werden.

1a. Power User Perspektive

Die Erstellung eines App-Workspace erfolgt sehr einfach:

Wichtig sind die beiden Optionen:

• Öffentlich heißt, daß alle Mitglieder der Gruppe - diese kann aus Office 365 stammen und Mitglieder zugewiesen bekommen haben - Zugriff auf die Dashboards usw. erhalten. Privat heißt, daß die Mitglieder in Power BI aktiv erfasst (und gepflegt) werden müssen. Diese Einstellung kann später nicht mehr geändert werden. Wir empfehlen, im Zweifel die Option Privat zu verwenden, da damit die Members jederzeit autonom auf Ebene des App-Workspaces gepflegt werden können.
• Können bearbeiten und Können nur anzeigen ... das klingt zwar selbsterklärend, entscheidet aber auch über die Wirksamkeit einer eventuell im Dataset definierten Row-Level-Security. Die Row-Level-Security wirkt im App-Workspace nämlich nur, wenn die Option Können nur anzeigen verwendet wird, und dann wiederum nur für die als Member (nicht: Admin) definierten Mitglieder (siehe weiter unten).

Anschließend werden die Mitglieder durch Eingabe der E-Mail Adressen hinzugefügt, externe Mail-Adressen können hier standardmäßig nicht berechtigt werden (dies kann aber über die Office 365 Settings der Gruppe gelockert werden, siehe dazu unten):

Nach dem Erzeugen des App-Arbeitsbereichs kann dieser über den Befehl Arbeitsbereich bearbeiten administriert werden und - ganz wichtig - die Administrator-Rolle(n) festgelegt werden. Es muß zumindest einen Administrator geben, es können aber auch mehrere sein. Alle anderen Benutzer sind automatisch Mitglied, es gibt also nur zwei Rollen auf Ebene der App-Workspaces. Mit dieser Funktion kann also bei personellem und/oder organisatorischem Wechsel die Admin-Rolle übertragen werden, die Dashboards stecken dann nicht im "My Workspace" eines ausgetretenen früheren Mitarbeiters fest ...

Nach der Anlage des neuen App-Workspace mit den gewünschten Zugriffsberechtigungen wird das Datenmodell aus PBI Desktop vom Power User neuerlich deployed, dieses Mal aber nicht in den "My Workspace" sondern in den soeben angelegten "DEMO App-Arbeitsbereich":

Beachten Sie bitte, daß ein Benutzer in der Administrator-Rolle immer sämtliche Daten sieht, da eine eventuelle Row-Level-Security für den Admin (ebenso wie für den Besitzer beim "My Workspace") keinesfalls greift. Für die Members wirkt die RLS nur dann, wenn die Gruppe mit der Option Können nur anzeigen definiert wurde.

1b. End User Perspektive

Es braucht jetzt kein Sharing , alle im App-Workspace berechtigten User erhalten sofort Zugriff auf sämtliche Dashboards und Reports über die "normale Navigation". Je nach Konfiguration (siehe oben) kann damit ein Bearbeitungsrecht für die Dashboards und Reports verbunden sein (allerdings nur für alle "Mitglieder" oder gar keinen, eine Differenzierung pro User ist nicht möglich) bis hin zum Zugriffsrecht auf das Dataset für weitere Administratoren.

Hat ein User nicht die Rolle Admin sondern Member, dann scheint der App-Workspace zwar in der Deployment-Liste von PBI Desktop auf, das Deployment selbst ist dann aber nicht möglich:

Beachten Sie bitte, daß sobald der Power User Änderungen am Datenmodell und/oder den Visualisierungen vornimmt, diese mit der Änderung / mit dem neuerlichen Deployment sofort für alle berechtigten User verfügbar sind. Eventuelle Fehler oder ungetestete Neuerungen schlagen damit sofort auf alle Mitglieder des App-Workspace durch. Daher sollten App-Workspaces für die Berechtigung der Power User, nicht aber für die Berechtigung der End User genutzt werden.

Leider hat derzeit jeder User das Recht zur Anlage von App-Workspaces, dieses Recht kann derzeit nicht auf bestimmte User eines Unternehmens beschränkt werden.

Exkurs I: Power BI App-Workspaces und 10 GB Kapazität

Grundsätzlich stehen jedem Power BI User (Free oder Pro) 10 GB Kapazität zur Verfügung, gemeint ist damit der My Workspace.

Zusätzlich stehen aber mit jedem App-Workspace (nur für Pro User verfügbar) weitere 10 GB Kapazität pro App-Workspace zur Verfügung, die "Firmen-Kapazität" kann also grundsätzlich mit App-Workspaces massiv erweitert werden. Ob es hier eine technische Grenze oder eine fair-use Regel pro Tenant gibt, ist uns nicht bekannt, es scheint aber, als ob hier beliebige Kapazitäten zur Verfügung stehen.

Wichtig ist aber auch die Nebenbedingung, daß ein einzelnes Dataset (= Anwendung) in der Pro Lizenzierung nicht mehr als 1 GB haben kann. Folglich können pro Workspace mindestens 10 Datasets (= Anwendungen) mit bis zu 1 GB (komprimierter) Größe betrieben werden.

Für Power BI Premium gelten andere Grenzwerte für die Datasetgröße und die App-Workspace Kapazität.

Quellen:

community.powerbi.com/t5/Integrations-with-Files-and/Power-BI-pro-Clarification-on-10-GB-limit/td-p/94721

radacad.com/step-beyond-the-10gb-limitation-of-power-bi (Skalierungsmöglichkeiten mit Tabular Model on-prem und Azure)

radacad.com/directquery-live-connection-or-import-data-tough-decision (Info zu 1 GB und 10 GB Limits)

Exkurs II: Power BI App-Workspaces und Power BI Premium Kapazitäten

Ein App-Workspace kann einer Power BI Premium Kapazität zugewiesen werden, damit sind App-Workspaces der technische-organisatorische Anknüpfungspunkt für Power BI Premium. Die Folge ist, daß sämtliche Anwendungen in diesem App-Workspace auf dezidierter Hardware-Kapazität betrieben werden und die End User lediglich einen Power BI Free Account benötigen.

Exkurs III: Power BI App-Workspaces und Office 365 Groups

Laut Roadmap soll dies zwar demnächst geändert werden, aber heute sind App-Workspaces in Power BI gleichzeitig auch Office 365 Groups. Und auch umgekehrt: bereits bestehende Office 365 Groups werden in Power BI - entsprechend der Mitgliedschaft eines Users - automatisch in Power BI als App-Workspaces übernommen. Das wird in manchen Fällen nützlich sein, in vielen aber störend, da hier rasch zu viele Anforderungen auf einmal erfüllt werden sollen.

Der Konnex wird auch in Power BI etwa 30 Minuten nach der Anlage eines App-Workspaces sichtbar, da jeder App-Workspace auch einen Kalender, ein OneDrive for Business Verzeichnis usw. erhält und die entsprechenden Zugriffslinks auch in Power BI angezeigt werden:

Immerhin: wird ein App-Workspace gelöscht, dann wird auch die zugehörige Office 365 Group automatisch mitgelöscht. Da derzeit jeder User das Recht zur Anlage von App-Workspaces hat, besteht derzeit das große Risiko, daß durch unüberlegtes Anlegen von Power BI App-Workspaces die Office 365 Gruppenorganisation "überschwemmt" wird. Dies muß durch organisatorische Maßnahmen bei der Einführung von Power BI bestmöglich verhindert werden.

3. Access Control über "Apps"-Mitgliedschaften

"Power BI Apps" dienen dazu, sämtliche Dashboards, Reports und Datasets in einem App-Workspace als Paket für die jeweiligen End User in einem sehr einfachen "Standard-Berechtigungsverfahren" bereitzustellen und auch die laufenden Updates und Weiterentwicklungen der Dashboards und Reports organisatorisch zu handhaben.

Power BI Apps sind - entgegen dem ersten Eindruck - nicht nur etwas für große Unternehmen sondern sollten generell verwendet werden, um End User zu berechtigen. Obwohl das Konzept der Power BI Apps grundsätzlich gut ist, sind heute leider noch ein paar sehr störende "Umständlichkeiten" mit dieser Verteiltechnik verbunden (kein Push möglich, verwirrende Navigation). Aber das wird sich hoffentlich noch entwickeln.

"Power BI Apps" wurden im Mai 2017 eingeführt und lösen die "Content Packages" (deutsch "Inhaltspakete") schrittweise ab. Die bisherigen Content Packages durch die neuen Apps zu ersetzen, geht sicherlich in die richtige Richtung, da die Content Packages so viele Freiheitsgrade für den einzelnen User geboten haben, daß das organisatorische Chaos damit in gewisser Weise vorprogrammiert war. Derzeit gibt es die alten Content Packages noch parallel zu den neuen Apps, diese sollten aber nicht mehr verwendet werden.

1a. Power User Perspektive

Power BI Apps können mit dem Button "App veröffentlichen" auf "App-Workspace" Ebene erstellt werden (nicht aber für Dashboards im "My Workspace" eines einzelnen Users):

Im ersten Schritt wird ein Erläuterungstext und eine Signalfarbe für die App festgelegt ...

... im nächsten Schritt erfolgt die sehr wichtige Info, daß alle Dashboards, Reports und Datasets des App-Workspaces in die App aufgenommen werden. Eine Selektion ist ist hier leider nicht möglich. Es kann ein bestimmtes Dashboard / ein bestimmter Report als Landingpage festgelegt werden, davon raten wir aber eher ab, da die Navigation dann für die End User schwieriger wird (zur Demo machen wir das aber trotzdem hier). Falls die Auswahl "Keine" getroffen wird, wird dem User eine Liste der verfügbaren Artefakte gezeigt.

Zuletzt erfolgt die Zuordnung der berechtigten User:

Mit dem Button Fertig stellen wird die App fertig gestellt:

Eine sehr wertvolle Eigenschaft der Apps ist die Eigenschaft, daß Änderungen an den Datasets, Reports und Dashboards im zugrundeliegenden App-Workspace nicht automatisch in die App durchgereicht werden. Erst wenn der Ersteller der App - dieser ist deren Besitzer - die App zur Bearbeitung aufruft und erneut freigibt, werden die Änderungen an die End User verteilt.

Unklar ist (mir) derzeit, wie die Besitzer-Rolle einer App - beispielsweise nach dem Austritt eines Mitarbeiters - auf einen anderen User übertragen werden kann. Das Administrator-Recht im zugrundeliegenden App-Workspace führt derzeit (leider) nicht dazu, daß die App auch von einem anderen User bearbeitet werden könnte. Möglicherweise ein Bug ...

1b. End User Perspektive

Derzeit bekommen die berechtigten End User die App aber leider nicht im Push-Verfahren zugestellt, sondern jeder einzelne Benutzer muß die App relativ umständlich seinem Power BI Account hinzufügen. Die Idee dahinter ist gut, in der Praxis wird dies vermutlich aber sehr oft scheitern. Dieser Punkt steht erfreulicherweise bereits auf der Roadmap und wird hoffentlich sehr bald in ein Push-Verfahren geändert.

Die Aktivierung einer App durch den End User erfolgt derzeit - wie gesagt sehr umständlich - über den Bereich Apps in der Navigationsleiste links, dann dem Button App abrufen und dann die Auswahl aus dem AppSource Dialog:

Das Dashboard bzw. der Report auf der Landingpage sieht wie gewohnt aus, die Bearbeitungsfunktionen sind wie schon zuvor bei den App-Workspaces deaktiviert, da es sich bei Apps immer um einen Read-Only Zugang handelt. Sehr unintuitiv finde ich den Zugang zu den Artefakten rechts oben ...

... hier ist für mich unverständlich, warum dieser Overview nicht über die Navigation links dargestellt werden kann (das sieht ja sehr sehr ähnlich aus).  Wie auch immer, man landet dann in diesem Schirm:

Anders als beim App-Workspace ist neben den Dashboards und Reports auch das Dataset für die "Analyze with Excel" sowie die "Quick Insights" verfügbar, die Connections sind aber für End User unzugänglich und die Aktualisierung kann ebenfalls nur durch App-Workspace Administratoren angestoßen bzw. Zeitpläne konfiguriert werden.

Zusammenfassung und Best Practices

Wir möchten folgende Best Practices ableiten, um aus einem "unkontrollierten Haufen" einzelner Power-BI-Accounts eine nachhaltige Enterprise BI Applikation aufzubauen.

1. Methoden Mix

Die 3 Methoden für Access Control sollten nicht beliebig gemischt werden, da sonst sehr schnell ein sehr unübersichtlicher Zustand eintritt. Unsere empfohlene Standardmethode:

1. die Sharing-Funktion für temporäre adhoc Einladungen insbesondere im My Workspace zu verwenden (für den Empfänger im Bereich "Für mich freigegeben" abrufbar)
2. über App-Workspaces den Zugriff für die Power User zu regeln und (für den Empfänger im Navigationsbereich "Workspaces" abrufbar)
3. für die Verteilung an die End User ausschließlich "Power BI Apps" zu verwenden (für den Empfänger im Navigationsbereich "Apps" abrufbar)

Alle 3 Sharing-Methoden führen zu einem Read-Only Zugang für den Empfänger, einzige Ausnahme bilden App-Workspaces die mit der Option Members can edit konfiguriert wurden.

2. Sharing

• Es ist dringend von der Aktivierung der "Re-Sharing" Option abzuraten, da ein unkalkulierbarer viraler Effekt der Weiterverteilung dann nicht mehr verhindert werden kann
• Beachten Sie bitte, daß ein eingeladener User immer nur Leserechte auf das Dashboard und den/die dahinterliegenden Reports bekommen kann. Der End User kann auch keine Visuals aus dem Report weder an dieses noch an eigene Dashboards pinnen, da hiefür kein Recht besteht. Der Zugriff auf das zugrundeliegende Dataset und damit beispielsweise auf die Möglichkeit, eine Datenaktualisierung anzustoßen, besteht ebenfalls nicht.

3. My Workspace

• Der My Workspace eines bestimmten Nutzers (und auch nicht einer Office-Mailadresse) sollte keinesfalls für produktive Anwendungen genutzt werden sondern ausschließlich für Sandbox- und adhoc Anwendungen eines Users (aber auch nicht für private Analysen).
• Der User verfügt daher in seinem „My Workspace“ immer über sämtliche Rechte für alle darin befindlichen Anwendungen und sieht auch immer sämtliche Daten, da eine eventuelle Row-Level-Security für den Besitzer nicht greift. Weiters folgt auch, daß ein User eine Anwendung aus PBI Desktop niemals in den „My Workspace“ eines anderen Users deployen kann, da er dort nicht das Besitzer-Recht haben kann.
• Die Einhaltung von Compliance Regeln muß organisatorisch/vertraglich sichergestellt werden, da jeder User in seinem My Workspace unbeschränkbare Rechte hat. Beim Austritt eines Mitarbeiters muß sichergestellt werden, daß keine produktiven Anwendungen des Unternehmens im My Workspace laufen (und auch keine privaten) und daß alle eventuell aufrechten Sharings garantiert beendet werden.

4. App-Workspaces

• Enterprise Anwendungen werden immer über App-Workspaces strukturiert, da damit die Besitzer-Rolle vom einzelnen Benutzer entkoppelt wird und die Zugriffsrechte fein-granularer als beim Sharing gesteuert werden können. App-Workspaces dienen einerseits zur organisatorischen Strukturierung der Power User, andererseits sind App-Workspaces die Basis für die Freigabe an End User über die Power BI Apps.
• App-Workspaces sollten im Zweifel mit der Option Private angelegt werden, damit die Members frei definiert bzw. später nachjustiert werden können.
• App-Workspaces sollten immer mit der Option Members can only view Power BI Content angelegt werden, da sonst keine Row-Level-Security für die Mitglieder des App-Workspaces (= Power User) wirken kann.
• App-Workspaces sind auch gleichzeitig Kapazitätseinheiten mit je 10 GB Kapazität bzw. werden über die App-Workspaces Power BI Premium Kapazitäten an konkrete Anwendungen zugewiesen.

5. Power BI Apps

• Die Verteilung der Dashboards, Reports und Datasets an die End User sollte immer über Power BI Apps erfolgen, auch wenn diese heute noch einige schmerzende Schwachstellen haben. Selbst bei kleinen Benutzerzahlen ist dies sinnvoll, da mit den Apps ein standardisiertes Berechtigungsverfahren (mit wenig Fehlerquellen) sowie ein sehr nützlicher Update-Modus zur Verfügung steht.
• Da Power BI Apps (derzeit) zwingend alle Artefakte von genau 1 App-Workspace verteilen, müssen die App-Workspaces schon nach Gesichtspunkten der späteren Verteilung gestaltet werden.
• Power BI Apps wurden im Mai 2017 eingeführt und lösen die Content Packages (deutsch "Inhaltspakete") ab. Derzeit gibt es die alten Content Packages noch parallel zu den neuen Apps, diese sollten aber nicht mehr verwendet werden.

Fazit und Verbesserungsmöglichkeiten

Im Bereich der Access Control sind in den mittleren Zukunft noch deutliche Änderungen zu erwarten, einerseits wegen der diesbezüglich ohnehin kommunizierten Roadmap, andererseits wegen der noch zahlreich vorhandenen (im Beitrag genannten) Schwachstellen sowie der nach unserer Ansicht noch nicht ausgereiften Usability. 

Problematisch sind derzeit aus unserer Sicht folgende Bereiche:

• App-Workspaces und Apps: derzeit hat jeder User das Recht hat, App-Workspaces (mit angeschlossenen Office 365 Groups) und Apps zu erzeugen. Das birgt das Risiko von chaotischen Strukturen ...
• App-Workspaces: jeder App-Workspace erzeugt gleichzeitig eine Office 365 Group, sodaß hier besonders darauf geachtet werden muß, daß die dort aufgebauten Strukturen nicht durch Power BI konterkariert werden. Diese Verbindung soll laut Roadmap aber aufgehoben werden.
• App-Workspaces: angeblich funktioniert bei App-Workspaces das Berechtigen von AAD-Gruppen nicht (bei Apps hingegen schon), dazu haben wir aber keine gesicherten Informationen.
• Apps: Die Besitzer-Rolle für "Apps" kann offenbar nicht übertragen werden. Das Administrator-Recht im zugrundeliegenden App-Workspace führt derzeit (leider) nicht dazu, daß die App auch von einem anderen User bearbeitet werden könnte. Möglicherweise ein Bug …
• Apps: derzeit müssen alle Dashboards, Reports und Datasets des App-Workspaces in die App aufgenommen werden, eine Selektion ist ist hier leider nicht möglich. --- Behoben mit dem November 2017 Update ---
• Apps: derzeit müssen die End User die App selbst aus dem AppSource-Store "abholen, es fehlt ein Push-Verfahren existiert nicht. --- Behoben mit dem February 2018 Update ---
• Apps: es fehlt die E-Mail Subscription Funktion --- Behoben mit dem November 2017 Update ---
• Apps: sehr unintuitiv finde ich den Navigation zu den Artefakten rechts oben … hier ist für mich unverständlich, warum dieser Overview nicht über die normale Navigation links erreicht werden kann sondern eine eigene "App Navigationslogik" geschaffen wurde.
• Navigation allgemein: die Navigation zwischen My Workspace, App-Workspaces, Für-mich-Freigegeben und Apps ist nach unserer Erfahrung für ungeübte Power BI User nicht gerade selbsterklärend.

Weiterführende, aber in diesem Beitrag nicht behandelte Varianten zur Access Control

Auf Besonderheiten bei der Access Control auf PowerBI.com von Personen außerhalb der eigenen Organisation sind wir in diesem Beitrag ebenso wenig eingegangen wie auf Besonderheiten in Zusammenhang mit der Publish to Web Option.

Alternativ zur Access Control auf PowerBI.com kann der Zugang für die User zu Dashboards und Reports auf PowerBI.com mit einem SharePoint Portal oder mit Individualanwendungen unter Verwendung von Power BI Embedded sehr indviduell gestaltet werden. Bei Verwendung des Power BI Report Server (= on-premise Serverinstallation) sind die dort vorgesehene Access Control bzw. die Möglichkeiten zum Embedding zu evaluieren. Diese Alternativen haben wir in diesem Beitrag nicht behandelt.

Quellen

Sharing: powerbi.microsoft.com/en-us/documentation/powerbi-service-share-unshare-dashboard
App-Workspace: powerbi.microsoft.com/en-us/guided-learning/powerbi-service-manage-your-group-in-power-bi-and-office-365
App: powerbi.microsoft.com/en-us/blog/distribute-to-large-audiences-with-power-bi-apps (-> Roadmap am Ende des Beitrags)
App: powerbi.microsoft.com/en-us/documentation/powerbi-service-what-are-apps
App: angryanalyticsblog.azurewebsites.net/index.php/2017/05/11/power-bi-content-workflow-with-apps
Whitepaper: powerbi.microsoft.com/en-us/documentation/powerbi-admin-power-bi-security/
Whitepaper: blog.crossjoin.co.uk/2017/06/20/white-paper-on-planning-a-power-bi-enterprise-deployment/

---------------------------------------------------------------------

Update vom 02.03.2018

Seit dem Erscheinen dieses Blogposts sind folgende wichtige Neuerungen verfügbar geworden:

February 2018 Update:

• Automatically install apps  (Quelle) = "Push" Distribution ist jetzt möglich :)

November 2017 Update (Quelle)

• Selective publish for Power BI apps = es müssen nicht mehr alle Artefakte (Dashboards, Reports, Datasets) eines App-Workspaces in eine App aufgenommen werden :)
• External user distribution with Azure Active Directory B2B (mehr ...)
• Improved workspace management with Premium
• E-mail subscriptions for apps (mehr ...) = jetzt können auch App Empfänger die E-Mail Subscription nutzen
• Granular control for Publish to Web = Publish to Web ist jetzt keine "Alle oder Keiner"-Funktion mehr sondern das Recht dazu kann selektiv auf bestimmte Benutzer(gruppen) vergeben werden

Neue Quellen:

• Distribution mit Apps: docs.microsoft.com/de-de/power-bi/service-create-distribute-apps
• App-Workspace: docs.microsoft.com/en-us/power-bi/service-manage-app-workspace-in-power-bi-and-office-365
• Webinar zu 6-teiliger Blogserie auf radacad.com: Simple Dashboard Sharing, Publish To Web, Embed in SharePoint Online, Power BI Embedded, Power BI Workspaces, Power BI Apps, Power BI Content Packs (Zusammenfassung All in One)
• File Size: powerbi.microsoft.com/en-us/blog/announcing-power-bi-premium-support-for-larger-datasets/

---------------------------------------------------------------------