Microsoft anbinden: Power BI, SQL, ADLS, Fabric und Purview
Konkrete Anbindungswege und Grenzen statt eines vermeintlichen Connectors für alle Microsoft-Produkte.
Quellen- und Prüfstand: 15. Oktober 2026. OpenMetadata-Anleitungen beziehen sich auf die verlinkte Dokumentation 2.0.x. Einrichtungsschritte und Voraussetzungen vor Einsatz mit Server-, Runner- und Connector-Version abgleichen. Redaktionell geprüft; keine Verbindung zu einem Kundensystem durchgeführt.
Welcher Microsoft-Bestand soll sichtbar werden?
Ein Power-BI-Bericht, eine SQL-Tabelle und eine Datei in ADLS sind verschiedene Objekte. Microsoft Entra ID liefert die Identität; die Daten- und Metadatenrechte werden zusätzlich im jeweiligen Dienst vergeben. Purview und Fabric enthalten selbst Governance-Funktionen, die nicht durch das Einlesen von Berichtsnamen automatisch nach OpenMetadata übertragen werden.
| Bestand | Vorgehen | Was gesondert nachgewiesen werden muss |
|---|---|---|
| Power BI Service | Dashboard-Service PowerBI | Workspaces, Berichte, Modelle, Tabellenzuordnung und unterstützte Detailmetadaten |
| SQL Server lokal | MSSQL-Database-Service | Runner-Netz, Treiber, Leserechte, View-Definitionen und optional Query-Historie |
| Azure SQL | AzureSQL-Database-Service | Endpunkt, Firewall/Private Endpoint, ODBC und unterstützte Anmeldung |
| ADLS Gen2 | ADLS-Datalake-Connector | Storage-Konto, Container/Prefix, Format, Leserechte und gewünschte Schema-Erkennung |
| Fabric | BI-Objekte über PowerBI; Datenobjekte über einen für den konkreten Endpunkt bestätigten Weg | Kompatibilität je SQL-Endpunkt, Lakehouse, Shortcut und API; kein pauschales „alles unterstützt“ |
| Microsoft Purview | Eigenen Data Map-/Governance-Bestand inventarisieren und Austausch explizit entwerfen | Connector/API-Abdeckung, führender Owner, Begriffe, IDs und Konfliktauflösung |
Power BI: Pilot mit Service Principal
Die nachfolgende Aussage zu Admin-Consent gilt für den beschriebenen read-only-Admin-API-Weg, nicht pauschal für jede Entra-App oder jeden Microsoft-Dienst. Microsoft-Tenant-Einstellungen und tatsächliche Connector-Abdeckung bleiben getrennte Nachweise. Teilabgleich 23.10.2026: Microsoft Service Principals und PowerBI-Connector 2.0.x.
- Workspace-ID, Report-ID und zugehöriges semantisches Modell notieren. Ein Modell außerhalb des gewählten Workspaces muss beim Scope berücksichtigt werden.
- Entra-Anwendung und technische Identität mit Tenant-ID, Client-ID und dem vorgesehenen Secret-/Rotationsverfahren bereitstellen.
- Admin- oder Non-Admin-API-Weg bewusst wählen. Für den Admin-Weg richtet der Fabric-Administrator den Zugriff auf die passenden read-only Admin APIs und die Metadatenscans ein. Für den Non-Admin-Weg benötigt die Identität den passenden Workspace-Zugriff.
- Die Microsoft-Anleitung für Service Principals verwenden. Microsoft weist beim read-only Admin-Weg darauf hin, dass auf der App keine Power-BI-Berechtigungen mit erforderlichem Admin-Consent gesetzt sein dürfen. Nicht wahllos zusätzliche Application Permissions hinzufügen.
- Für detaillierte Modellmetadaten sowie DAX/Mashup-Ausdrücke die relevanten Scanning-Einstellungen getrennt prüfen. Mehr Scope bedeutet auch Zugriff auf mehr Metadaten.
- In OpenMetadata Dashboard Services → PowerBI, Service
powerbi_prod, Tenant-/Client-Daten und den gewählten API-Modus konfigurieren. Workspace-Filter auf den Pilot begrenzen. - Verbindung testen, Metadata-Agent starten und Bericht/Modell gegen die erwarteten IDs prüfen. Datenbankservices für Upstream-Verbindungen zuvor einlesen und zuordnen.
Die OpenMetadata-Anleitung 2.0.x nennt weitere Voraussetzungen, darunter die Lizenzbedingung, und führt Dataflows sowie Usage-Ingestion unter dieser Authentifizierung als nicht unterstützt. Diese Grenzen nicht mit den allgemeinen Fähigkeiten der Microsoft-Scanner gleichsetzen. Prüfen, was die eingesetzte Connector-Version tatsächlich übernimmt.
Azure SQL und lokaler SQL Server
Für AzureSQL Datenbank-FQDN, Port, Datenbank, ODBC-Treiber und erlaubten Netzwerkpfad des Runners festlegen. TLS-Zertifikatsprüfung und verwendete Authentifizierung passend konfigurieren. Zuerst nur das Pilotschema einlesen.
Für SQL Server folgt die lokale Datenbankanleitung. Tabellen sichtbar zu haben beweist noch keine View-Definitionen oder Query-Historie. Dafür sind zusätzliche dokumentierte Rechte notwendig.
ADLS, OneLake und Fabric
Beim ADLS-Connector einen eigenen Service mit Storage-Zugang, Container und Prefix anlegen. Ein kleines Verzeichnis mit bekannten CSV-/Parquet-/JSON-Strukturen verwenden. Schema-Erkennung kann Inhalt lesen; Profiling und Beispieldaten separat entscheiden. Ein Container-Listing allein beweist keine Tabellen-Lineage.
OneLake ist nicht pauschal mit jedem ADLS-Connector identisch kompatibel. Für Fabric prüfen wir den konkreten Endpoint, die unterstützte Anmeldung, SQL-Dialekt beziehungsweise Dateizugriff und die Abbildung im eingesetzten Connector. Nicht nachgewiesene Fabric-Objekttypen bleiben als Integrationslücke sichtbar.
Purview zusammen mit OpenMetadata
Für jedes gemeinsame Objekt klären, welches System Definition, Owner und Klassifikation führt. Eine Mapping-Tabelle hält Purview-ID, OpenMetadata-FQN, Quellsystem-ID und Änderungsrichtung fest. Ohne explizit getesteten Import/API-Prozess keinen bidirektionalen Standardabgleich versprechen. Die Einordnung der nativen Microsoft-Kataloge hilft bei der Bestandsentscheidung.
Abnahme: Ein Finanzbericht zeigt dasselbe Modell, dieselbe physische Tabelle und dieselbe Owner-Entscheidung in allen verwendeten Oberflächen. Nicht abgebildete Ausdrücke, Dataflows oder Shortcuts werden benannt und geplant.
OpenMetadata: practical system connections
Part 4 of 7
View series