Power BI und Microsoft Fabric administrieren: Tenant-Einstellungen, Workspaces, Gateways und Refresh

Wie lassen sich Power BI und Microsoft Fabric administrieren, wenn immer mehr Workspaces, Berichte, Datenquellen und Gateways entstehen? Der zentrale Ansatz ist die Trennung von Tenant-Governance, Workspace-Verantwortung und technischem Datenbetrieb. Tenant Settings definieren, welche Funktionen verfügbar sind; Workspace-Rollen steuern Zusammenarbeit; Gateways und Credentials ermöglichen Datenzugriff; Monitoring und Lifecycle sorgen dafür, dass Inhalte auch nach Personalwechsel oder Quelländerungen weiter funktionieren.

Die Einbettung fertiger Berichte in SharePoint und Teams wird im Beitrag Power BI in SharePoint und Teams einbetten behandelt. Dieser Artikel konzentriert sich auf die administrative Plattformebene. Für Prozessdaten, die aus SharePoint, Power Apps und Power Automate in Berichte münden, ist Power Platform mit SharePoint der fachliche Anschluss.

Verwaltungsbereiche

Power BI und Fabric begrifflich einordnen

Power BI ist Teil der Microsoft-Fabric-Plattform und wird in Teilen über das Fabric Admin Portal verwaltet. Tenant Settings können sowohl Power-BI- als auch Fabric-Funktionen betreffen. Administratoren sollten deshalb prüfen, ob eine Einstellung nur die BI-Nutzung oder weitere Fabric-Workloads beeinflusst.

Nicht jede sichtbare Tenant-Einstellung ist eine harte Sicherheitsgrenze. Microsoft weist beispielsweise darauf hin, dass manche UI- oder Featureeinstellungen Governance unterstützen, aber bestehende Datenberechtigungen nicht ersetzen. Datenzugriff muss weiterhin über Workspace, Item, Semantic Model und Quelle abgesichert werden.

Rollenmodell

Bei Workspace-Rollen zählt im Zweifel die höchste wirksame Berechtigung aus allen Gruppenmitgliedschaften. Für alles, was über reines Anzeigen und Interagieren hinausgeht, werden in der Regel Pro- oder PPU-Rechte benötigt. Rollen und Lizenzmodell müssen daher immer zusammen geprüft werden.

Tenant-Administration

Fabric- oder Power-BI-Administratoren verwalten tenantweite Einstellungen, Kapazitäten, Workspacesichten und Governancefunktionen. Diese Rolle sollte nicht pauschal allen Berichtsentwicklern zugewiesen werden.

Workspace-Rollen

Power BI verwendet Rollen wie Admin, Member, Contributor und Viewer. Sie unterscheiden sich bei Verwaltung, Veröffentlichung und Konsum.

Grundprinzipien:

• Workspace Admins nur für verantwortliche Betreiber,
• Entwickler über Member oder Contributor passend zum Prozess,
• Konsumenten bevorzugt Viewer oder App-Zugriff,
• Gruppen statt vieler Einzelbenutzer,
• mindestens zwei aktive Workspace-Administratoren für kritische Bereiche.

Das Deaktivieren eines Entra-Benutzers entfernt nicht automatisch alle gespeicherten Workspace-Zugriffseinträge. Offboarding muss Power BI ausdrücklich berücksichtigen.

Workspace-Strategie

Workspaces sollten nicht pro Bericht spontan erstellt werden. Ein sinnvolles Modell richtet sich nach Eigentum, Datenbereich und Deployment:

• Fachbereichsworkspace,
• zentral verwalteter Enterprise-BI-Workspace,
• Entwicklung, Test und Produktion getrennt,
• Daten-/Semantic-Model-Workspace getrennt von Reporting, wenn erforderlich,
• persönliche Experimente in My Workspace nur ohne produktive Abhängigkeit.

Für jeden produktiven Workspace:

• fachlicher Eigentümer,
• technischer Betreiber,
• Administratorgruppe,
• Datenklassifikation,
• Kapazität und Lizenzmodell,
• Deploymentweg,
• Supportkontakt,
• Archivierungsdatum.

Tenant Settings kontrolliert verwalten

Tenant Settings lassen sich häufig gezielt auf Sicherheitsgruppen anwenden und wirken nicht immer sofort. Ein realistischer Rollout rechnet mit zeitversetzter Verarbeitung und prüft die Wirkung mit Testbenutzern. Wichtig bleibt die Einordnung: Diese Einstellungen unterstützen Governance, ersetzen aber keine Datenberechtigungen auf Workspace-, Item- oder Quellenebene.

Tenant Settings können oft für die gesamte Organisation oder ausgewählte Sicherheitsgruppen aktiviert werden. Neue Funktionen sollten nicht sofort global eingeschaltet werden.

Prüfprozess:

1. Zweck und betroffene Funktion dokumentieren.
2. Daten- und Compliancewirkung bewerten.
3. Lizenz- und Kapazitätswirkung prüfen.
4. Pilotgruppe definieren.
5. Einstellung nur für diese Gruppe aktivieren.
6. Audit, Nutzung und Supportfälle beobachten.
7. Entscheidung über breiteren Rollout treffen.

Besonders relevant sind Einstellungen zu:

• Erstellen von Workspaces,
• externem Teilen und Gastzugriff,
• Export und Download,
• Publish to web,
• Service Principals und Admin APIs,
• Fabric-Workloads,
• Copilot- oder KI-Funktionen,
• benutzerdefinierten Visuals.

„Publish to web“ und ähnliche öffentliche Freigabefunktionen benötigen eine besonders strenge Bewertung, weil sie Inhalte außerhalb normaler Benutzerberechtigungen zugänglich machen können.

Lizenz- und Kapazitätsmodell

Ersteller und Empfänger benötigen je nach Freigabe- und Kapazitätsmodell unterschiedliche Lizenzen. Power BI Pro, Premium Per User und Fabric- beziehungsweise Premium-Kapazitäten bieten unterschiedliche Möglichkeiten. Ein PPU-Workspace ist dabei nicht gleichbedeutend mit einer dedizierten Premium- oder Fabric-Kapazität. Diese Unterscheidung sollte vor jeder breiten Verteilung ausdrücklich getestet werden.

Vor einer Bereitstellung muss geprüft werden:

• Wer erstellt und veröffentlicht?
• Wer konsumiert?
• Liegt der Workspace in einer geeigneten Kapazität?
• Benötigen externe Gäste eigene Lizenzen?
• Werden PPU-Funktionen verwendet?
• Welche Kosten entstehen bei wachsender Nutzerzahl?

Lizenzannahmen sollten vor jedem größeren Rollout gegen die aktuelle Microsoft-Dokumentation geprüft werden.

On-premises Data Gateway

Nur Gateway-Administratoren können neue Datenquellen am Gateway anlegen. Zusätzlich muss der jeweilige Nutzer oder Dienst an der konkreten Datenquelle berechtigt sein. Nach einer Neuveröffentlichung des Semantic Models ist oft erneut zu prüfen, ob Gateway und Datenquelle noch korrekt zugeordnet sind.

Ein Gateway verbindet den Cloud-Dienst mit lokalen Datenquellen. Für produktive Nutzung sollte kein einzelner Arbeitsplatzrechner als unbetreuter Gatewayhost dienen.

Ein belastbares Gatewaykonzept umfasst:

• Server oder geeignete dauerhafte Hosts,
• Gateway-Cluster für Verfügbarkeit,
• mehrere Administratoren,
• dokumentierten Recovery Key,
• Patch- und Updateverfahren,
• Servicekonto und Datenquellencredentials,
• Netzwerkfreigaben zu Microsoft-Diensten,
• Monitoring von Dienst und Ressourcen,
• Wiederherstellungstest.

Datenquelle exakt abgleichen

Gateway-Zuordnung kann scheitern, wenn Server- oder Datenquellennamen im Semantic Model anders angegeben sind als in der Gateway-Datenquelle. Hostname, Instanzname und gegebenenfalls IP müssen konsistent sein.

Credentials und Eigentum

Scheduled Refresh hängt oft von gespeicherten Credentials ab. Werden persönliche Konten verwendet, kann ein Passwortwechsel, MFA-Änderung oder Austritt den Refresh stoppen.

Für produktive Datenquellen:

• geeignetes Identitätsmodell wählen,
• least-privileged Datenbankrechte vergeben,
• mehrere Gatewayadministratoren benennen,
• Credential-Rotation dokumentieren,
• Secret- oder Zertifikatsablauf überwachen,
• Verantwortlichen für jede Datenquelle führen.

Datenaktualisierung verwalten

Auch der Refresh selbst hängt vom Kapazitätsmodell ab. Häufigkeit, parallele Verarbeitung und mögliche Pausen geplanter Aktualisierungen unterscheiden sich je nach Kapazität und Nutzung. Verantwortliche sollten deshalb Fehlermeldungen, Nutzungsdaten und Besuchsdaten gemeinsam im Blick behalten.

Power BI unterscheidet verschiedene Verbindungs- und Aktualisierungsmodelle. Bei importierten Daten lädt ein Refresh neue Daten in das Semantic Model. DirectQuery oder Live Connection verhalten sich anders und benötigen gegebenenfalls ebenfalls ein Gateway.

Für jeden produktiven Refresh dokumentieren:

• Semantic Model,
• Quellensystem,
• Verbindungsmodus,
• Gateway und Datenquelle,
• Zeitplan,
• erwartete Dauer,
• fachliche Aktualitätsanforderung,
• Benachrichtigungsempfänger,
• Rückfall bei Ausfall.

Refresh-Monitoring

Ein Bericht kann erreichbar sein und trotzdem veraltete Daten anzeigen. Monitoring muss daher den letzten erfolgreichen Refresh und die fachliche Aktualität der Daten prüfen.

Bei Fehler:

1. Refresh History öffnen.
2. Fehlerzeitpunkt und Meldung sichern.
3. Gatewaystatus prüfen.
4. Credentials kontrollieren.
5. Quellsystemverfügbarkeit prüfen.
6. Schema- oder Dateipfadänderungen untersuchen.
7. Desktop-Refresh mit vergleichbarer Konfiguration testen.
8. nach Korrektur manuellen Refresh starten.
9. fachlichen Datenstand validieren.

Typische Fehlerbilder

Refresh funktioniert in Desktop, aber nicht im Service

Mögliche Ursachen:

• Gateway fehlt oder ist falsch zugeordnet,
• Datenquelle nutzt abweichenden Hostnamen,
• Credentials fehlen,
• dynamische oder nicht unterstützte Quelle,
• lokale Datenschutz- oder Netzwerkeinstellungen unterscheiden sich.

Diagnose: Power BI Desktop auf dem Gatewayhost kann helfen, Datenquelle und Netzwerk einzugrenzen. Danach Gatewaymapping und Semantic-Model-Einstellungen prüfen.

Bericht zeigt keine aktuellen Daten, obwohl Refresh „erfolgreich“ war

• Quelle selbst ist nicht aktuell,
• Abfrage filtert neue Daten aus,
• Zeitzone oder inkrementelle Logik ist falsch,
• Bericht nutzt ein anderes Semantic Model,
• Cache oder Tile ist noch nicht aktualisiert.

Maßnahme: fachlichen Datenwert in Quelle, Semantic Model und Bericht vergleichen.

Workspace besitzt nur einen Administrator

Beim Austritt kann niemand Rollen, Gatewaybindung oder Deployment verwalten.

Korrektur: Adminzugriff über Gruppen und mindestens zwei Verantwortliche. Offboarding in den Benutzerlebenszyklus aufnehmen.

Kostenloser Benutzer kann Bericht nicht öffnen

Workspace, Kapazität, Rolle und Lizenzmodell passen nicht zur Freigabe.

Diagnose: Inhalt und zugrunde liegendes Semantic Model müssen in geeigneter Kapazität liegen; Empfängerrolle und Lizenzbedingungen prüfen.

Tenant Setting wurde global aktiviert

Eine neue Export- oder Freigabefunktion steht unerwartet allen Benutzern zur Verfügung.

Rückfall: Einstellung auf vorherigen Zustand setzen und künftig über Pilot-Sicherheitsgruppe einführen. Bereits exportierte oder öffentlich freigegebene Inhalte separat untersuchen.

Content-Lifecycle und Deployment

Produktive Inhalte sollten nicht ausschließlich in My Workspace oder direkt in Produktion entwickelt werden.

Ein kontrollierter Ablauf:

1. Entwicklung in eigenem Workspace,
2. Quellcode beziehungsweise PBIX/PBIP und Parameter versionieren,
3. Review und Test,
4. Deployment Pipeline oder automatisierten Prozess verwenden, wenn passend,
5. Abnahme in Test,
6. Freigabe in Produktion,
7. Release dokumentieren,
8. vorherige Version für Rollback behalten.

Deployment Pipelines verschieben Metadaten zwischen Stufen, ersetzen aber keine Prüfung von Datenquellen, Credentials und Umgebungsparametern.

Externe Freigaben

Externe Benutzer benötigen passende Entra-B2B-Konfiguration, Power-BI-Tenant-Einstellungen und Lizenzierung. Zugriff auf einen Report kann auch Zugriff auf zugrunde liegende Datenmodelle oder freigegebene Inhalte implizieren.

Vor Freigabe:

• fachlichen Zweck,
• Datenklassifikation,
• Empfängeridentität,
• Lizenz,
• Ablaufdatum,
• Exportrechte,
• regelmäßige Access Review festlegen.

Regelmäßiger Betriebsplan

• Workspaces ohne zwei Admins,
• persönliche Workspaces mit produktiven Abhängigkeiten,
• fehlgeschlagene Refreshes,
• Gateways offline oder veraltet,
• Datenquellen ohne Eigentümer,
• externe Freigaben,
• Tenant-Setting-Änderungen,
• ungenutzte oder doppelte Semantic Models,
• Kapazitätsauslastung,
• verwaiste Deployment Pipelines und Apps,
• Lizenz- und Serviceänderungen.

Wenn Berichte in M365-Arbeitsbereichen sichtbar werden sollen, schließt Power BI in SharePoint und Teams einbetten direkt an. Für Datenflüsse und DLP auf der Low-Code-Seite ergänzt Power Platform administrieren die Governance-Sicht.

So bleibt die BI-Plattform trotz wachsender Berichtszahl verlässlich

Power BI und Fabric werden beherrschbar, wenn Tenant Settings gruppenbasiert eingeführt, Workspaces klar verantwortet und Datenquellen als technische Betriebsobjekte behandelt werden. Gateways besitzen Redundanz, Refreshes werden überwacht und Inhalte durchlaufen Entwicklung, Test und Produktion. Damit bleiben Berichte aktuell und zugänglich, auch wenn Entwickler, Passwörter oder Quellsysteme wechseln.