Dein SQL-Server steht noch im Serverraum. SharePoint läuft On-premises. Der File-Server ist seit Jahren bewährt — und niemand rührt ihn an. Das ist Realität in vielen KMU. Und das ist völlig in Ordnung.
Das Problem entsteht, wenn du anfängst, Power Automate zu nutzen: Du willst Genehmigungsworkflows bauen, Daten aus deiner lokalen Datenbank in Teams-Notifications einbauen oder automatisch Dateien vom lokalen File-Server verarbeiten. Aber Power Automate läuft in der Cloud. Und deine Daten? Die stecken hinter der Firewall.
Die gute Nachricht: Microsoft hat genau dafür eine Lösung — den On-premises Data Gateway. Und sie ist einfacher einzurichten, als du vielleicht denkst.
Was ist der On-premises Data Gateway?
Der On-premises Data Gateway ist ein Windows-Dienst, den du auf einem lokalen Server (oder einer dedizierten VM) installierst. Er dient als Brücke zwischen deinen Cloud-Diensten — Power Automate, Power BI, Power Apps, Azure Logic Apps — und deinen lokalen Datenquellen.
Das Entscheidende an der Architektur: Der Gateway baut ausgehende Verbindungen zur Azure Service Bus Relay auf. Das bedeutet:
- Keine eingehenden Ports müssen in der Firewall geöffnet werden
- Die Verbindung geht vom Gateway nach draußen zu Azure — nicht umgekehrt
- Deine Firewall-Regeln bleiben unverändert
Abb.: Der On-premises Data Gateway als Brücke zwischen Cloud Flow und lokalen Daten
Der Ablauf ist dabei immer gleich: Dein Cloud Flow in Power Automate sendet eine Anfrage → Azure Relay leitet sie weiter → der Gateway auf deinem lokalen Server empfängt sie → der Gateway fragt die lokale Datenquelle ab → das Ergebnis geht denselben Weg zurück. Alles verschlüsselt, alles über ausgehende HTTPS-Verbindungen.
Die aktuellste Version ist das April 2026 Release (Version 3000.314). Neu in dieser Version: das Admin-triggered Auto-Update ist jetzt allgemein verfügbar (GA). Admins können Gateway-Updates damit zentral aus dem Power Platform Admin Center anstoßen — kein manuelles Anfassen des Servers mehr nötig.
Wichtig: Microsoft unterstützt nur die letzten 6 monatlichen Releases. Wer seinen Gateway länger nicht aktualisiert hat, riskiert, dass Verbindungen schlicht nicht mehr funktionieren. Das ist einer der häufigsten Fehler in der Praxis.
Welche Datenquellen unterstützt der Gateway?
Der Gateway öffnet die Verbindung — aber die eigentliche Arbeit machen die Connectoren. Folgende Datenquellen kannst du über den On-premises Data Gateway in Power Automate nutzen:
Datenbanken:
- SQL Server ⚠️ (Premium-Connector — siehe Lizenz-Hinweis unten)
- Oracle
- PostgreSQL
- MySQL
- Teradata
- IBM DB2
- IBM Informix
- Apache Impala
Microsoft-Dienste:
- SharePoint (On-premises) — jetzt mit HTTP und HTTPS
- BizTalk Server
Dateien & Sonstiges:
- File System
- HTTP with Microsoft Entra ID
SAP:
- SAP ERP
Das sind die Connectoren, die explizit den Gateway-Einsatz unterstützen. Für die meisten KMU sind SQL Server, SharePoint On-premises und File System die drei relevantesten — und alle drei funktionieren stabil über den Gateway.
Die 4 Setup-Schritte
Kommen wir zum Kern: Wie richtest du den Gateway ein? Es sind vier Schritte, und wenn du sie in der richtigen Reihenfolge gehst, ist das Setup in einer halben Stunde erledigt.
Schritt 1: Gateway herunterladen und installieren
Lade den Gateway vom Microsoft Power Platform Admin Center oder direkt von aka.ms/on-premises-data-gateway-installer herunter. Installiere ihn auf einem Windows-Server (oder einer Windows-VM), der dauerhaft erreichbar ist — nicht auf deinem Arbeits-Laptop.
Voraussetzungen:
- Windows 10 / Windows Server 2016 oder neuer
- .NET Framework 4.8 oder höher
- Mindestens 4 GB RAM (8 GB empfohlen für Produktivumgebungen)
- Der Server muss dauerhaft online und erreichbar sein — Gateway-Verbindungen fallen aus, wenn der Rechner schläft oder offline geht
Während der Installation meldest du den Gateway mit deinem Arbeits- oder Schulkonto (Microsoft 365-Konto) an. Dieses Konto wird der erste Gateway-Administrator.
Schritt 2: Netzwerk und Firewall konfigurieren
Der Gateway kommuniziert ausgehend über HTTPS (Port 443) und zusätzlich über Azure Service Bus (Port 5671 und 5672) für die Relay-Verbindung. Prüfe, dass folgende ausgehenden Verbindungen erlaubt sind:
*.servicebus.windows.net(Port 443, 5671, 5672)*.frontend.clouddatahub.net(Port 443)login.windows.netundlogin.microsoftonline.com(Port 443)
In den meisten KMU-Umgebungen funktioniert das out of the box, weil ausgehende HTTPS-Verbindungen in der Regel erlaubt sind. Falls dein Unternehmen einen ausgehenden Proxy nutzt, musst du diesen im Gateway-Konfigurator eintragen.
Schritt 3: Gateway-Admins hinzufügen
Nach der Installation erscheint der Gateway im Power Platform Admin Center unter portal.azure.com → Power Platform → Daten → Gateways (oder direkt unter admin.powerplatform.microsoft.com).
Hier kannst du weitere Administratoren hinzufügen — sinnvoll, wenn nicht nur du den Gateway verwalten sollst. Unterscheide dabei zwischen zwei Rollen:
- Gateway-Administrator: Kann den Gateway verwalten, Verbindungen anlegen und andere Admins hinzufügen
- Gateway-Benutzer: Kann vorhandene Verbindungen nutzen, aber keine neuen anlegen
Gerade in Teams mit mehreren Power-Automate-Nutzern ist es sinnvoll, den Gateway-Admins bewusst zu wählen — nicht jeder braucht vollen Zugriff.
Schritt 4: Verbindung in Power Automate herstellen
Jetzt kommt der Teil, den deine Nutzer täglich sehen. In Power Automate (make.powerautomate.com):
- Neuen Flow erstellen oder bestehenden öffnen
- Einen Schritt mit einem Gateway-fähigen Connector hinzufügen (z.B. SQL Server)
- Beim Anlegen der Verbindung: „Connect via on-premises data gateway” auswählen
- Den installierten Gateway aus der Dropdown-Liste wählen
- Verbindungsdetails eingeben (Server, Datenbank, Authentifizierung)
Die Verbindung wird jetzt über deinen lokalen Gateway geroutet. Im Flow selbst ändert sich nichts — er verhält sich genauso wie eine Cloud-basierte SQL-Verbindung, nur eben auf deinen lokalen Server.
Standard-Mode vs. Personal-Mode — wann was?
Der Gateway gibt es in zwei Varianten:
| Standard-Mode | Personal-Mode | |
|---|---|---|
| Nutzer | Multi-User (ganzes Team) | Einzelner Benutzer |
| Services | Power Automate, Power Apps, Power BI, Logic Apps | Nur Power BI |
| Installation | Server/VM (dauerhaft online) | Eigener Rechner |
| Empfehlung | Produktiv, Teams, KMU | Nur für Power BI Einzelnutzer |
Die Empfehlung für KMU ist eindeutig: Standard-Mode. Der Personal-Mode ist auf Power BI beschränkt und für Einzelpersonen gedacht, die lokal entwickeln. Für den Betrieb von Power-Automate-Flows im Team kommt nur der Standard-Mode in Frage.
Lizenz-Hinweis: SQL Server ist Premium
Bevor du anfängst zu bauen, ein wichtiger Punkt zur Lizenzierung: Der SQL Server-Connector ist ein Premium-Connector.
Das bedeutet: Ein reiner Microsoft 365 Business-Plan reicht nicht aus. Du brauchst entweder:
- Power Automate per User Plan (~15 €/Nutzer/Monat)
- Power Automate per Flow Plan (~100 €/5 Flows/Monat)
- Eine Power Platform-Lizenz (die SQL Server bereits einschließt)
Wenn du also planst, aus Power Automate auf eine lokale SQL-Datenbank zuzugreifen, muss das Budget für Power Automate Premium eingeplant sein. Andere Connectoren wie File System oder SharePoint (OnPrem) können je nach Lizenzmodell anders bewertet werden — hier lohnt eine kurze Prüfung im Microsoft 365 Admin Center oder direkt mit einem Partner.
SharePoint On-premises ist übrigens kein Premium-Connector — hier reicht oft ein Standard-Lizenzplan aus.
Typische Fallstricke — und wie du sie vermeidest
In der Praxis gibt es drei Fehler, die immer wieder auftauchen:
1. Veraltete Gateway-Version Microsoft unterstützt nur die letzten 6 monatlichen Releases. Wer seinen Gateway 6+ Monate nicht aktualisiert hat, riskiert Verbindungsabbrüche ohne klare Fehlermeldung. Lösung: Aktiviere das neue Admin-triggered Auto-Update (verfügbar seit April 2026 als GA-Feature) oder trage die monatliche Prüfung in deinen Patch-Rhythmus ein.
2. Firewall-Sperren für Azure Service Bus
Viele IT-Teams öffnen HTTPS auf Port 443, vergessen aber die Ports 5671 und 5672 für Azure Service Bus. Der Gateway startet scheinbar korrekt, aber Verbindungen schlagen im Flow fehl. Prüfe die ausgehenden Regeln explizit für *.servicebus.windows.net.
3. Falsche Adminrechte bei der Installation Der Gateway-Dienst muss mit einem Dienstkonto laufen, das lokale Adminrechte auf dem Server hat und Netzwerkzugriff auf die Datenquellen besitzt. Wer den Gateway mit einem User-Account ohne ausreichende Rechte installiert, bekommt entweder keine Verbindung oder intermittierende Fehler. Erstelle ein dediziertes Dienstkonto — der Aufwand lohnt sich.
Bonus-Tipp: Teste den Gateway immer zuerst mit einer einfachen Testverbindung im Power Platform Admin Center, bevor du komplexe Flows baust. Dort siehst du direkt, ob der Gateway online ist und Verbindungen annimmt.
Fazit: Hybrid ist kein Hindernis mehr
Der On-premises Data Gateway ist ausgereift, gut dokumentiert und — sobald man die 4 Schritte kennt — in unter einer Stunde produktiv. Die Architektur (ausgehende Verbindung, kein Portöffnen) macht ihn auch in sicherheitsbewussten Umgebungen einsetzbar.
Wenn du M365 produktiv nutzt und noch On-premises-Daten hast: Du musst nicht warten, bis alles in der Cloud ist. Du kannst jetzt anfangen.
Nächster Schritt: Hybrid-Setup gemeinsam planen
Du willst wissen, ob der Gateway die richtige Lösung für dein spezifisches Setup ist? Welche Connectoren du brauchst, welche Lizenz passt, und wie das Deployment in deiner Umgebung aussieht?
Buch ein kostenloses Erstgespräch — wir schauen uns gemeinsam an, wo der Gateway Sinn macht und was der schnellste Weg zu deinem ersten produktiven Hybrid-Flow ist.
👉 Erstgespräch buchen — Walther IT Consulting
Quellen: Microsoft Learn — On-premises data gateway (Stand: 2025-06-25) · Microsoft Fabric Blog — April 2026 Gateway Release