Mithilfe der Microsoft Power Platform werden Unternehmen befähigt, Applikationen auch ohne tiefergehende Programmierkenntnisse zu erstellen. Microsoft selbst nennt zahlreiche Anwendungsfälle, in denen die Plattform sowohl von Usern ohne Programmierkenntnisse als auch von erfahrenen Entwicklern verwendet wurde. So können die sogenannten „Citizen Developer“ bestimmte Geschäftsprozesse in Unternehmen selbstautomatisieren.
Problemstellung
So unterschiedlich die Use Cases in ihrer Komplexität auch sind, beschränken sie sich jedoch nahezu ausschließlich auf die Interaktion mit externen Systemen, die bereits in der Cloud sind. In den Use Cases von Microsoft interagieren die PowerApps z.B. mit Office365, Apps in der Azure Cloud, externen APIs und Online-Datenbanken.
Die Interaktion mit On-Premises-Ressourcen beschränkt sich dabei auf On-Prem-Datenbanken, die durch die Verwendung des On-Premises-Datagateways an die Microsoft Cloud Services angeschlossen werden können.
Doch was ist, wenn man PowerShell-Skripte auf einem On-Premises-Server aus der PowerApp triggern möchte? Ein neuer Anwendungsfall hierfür wäre z.B. eine Onboarding-App, die es ermöglicht, neue User im Active Directory anzulegen. Die Frage, die hier beantwortet werden muss, lautet: Wie baut man eine sichere Kommunikation zwischen dem lokalen On-Prem-Server und der Microsoft Cloud auf?
Lösung
Die folgende Grafik soll grob und abstrakt visualisieren, wie wir dieses Problem lösen wollen:
Wir legen das PowerShell-Skript, welches alle notwendigen Befehle enthält (z.B. um neue AD-User anzulegen), in der Azure Cloud ab. Dort kann es einerseits von der PowerApp gefunden und gestartet werden, andererseits kann der On-Premises-Server darauf über TCP Zugreifen.
Der Grundgedanke ist einfach: Wann immer die PowerApp den Startschuss gibt, soll der On-Premises-Server das Skript downloaden und lokal ausführen.
Man könnte an dieser Stelle meinen, dass hierfür ein komplexer Mechanismus entwickelt werden muss, bei dem der On-Premises-Server durch Polling in der Azure Cloud ständig prüft, ob der „Startschuss“ der PowerApp bereits gekommen ist. Dem ist allerdings nicht so. Es gibt bereits fertige Werkzeuge und Software, die Microsoft uns genau für diesen Zweck vorgibt: Azure Automation, Runbooks und der Hybrid Runbook Worker.
Azure Automation ist eine Azure Ressource, die in erster Linie verwendet wird, um Azure Ressourcen (wie z.B. VMs) automatisch und zentral zu verwalten.
Ein besonders wichtiges Feature dieser Ressource ist die Möglichkeit, sogenannte Runbooks zu schreiben. Ein Runbook kann ein PowerShell- oder Python-Skript sein. Es kann einerseits innerhalb von Azure ausgeführt werden, um z. B. Azure Ressourcen zu löschen, VMs auszuschalten oder andere Automatisierungen zu übernehmen.
Es kann andererseits aber auch statt in Azure auf einem Hybrid Worker ausgeführt werden. Ein Hybrid Worker kann dann ein On-Prem-Server sein, auf dem der On-Premises Hybrid Worker installiert wurde. Dies ist ein Dienst, der dafür zuständig ist, sich vom On-Prem-Server mit der Azure Cloud zu verbinden und auf Änderungen oder Befehle zu warten. Wie genau dies funktioniert, wird später im Detail beschrieben. Zunächst ist es nur wichtig, den Grundaufbau und die benötigten Ressourcen zu verstehen.
Ebenfalls wichtig für unseren Anwendungsfall ist, dass ein Runbook auch von einer PowerApp oder einem Flow über einen bereits vorhandenen Konnektor gestartet werden kann.
Zusammengefasst wissen wir nun, dass wir mit Azure Automation Runbooks (PowerShell-Skripte) erzeugen können. Diese können aus einer PowerApp über einen vorhandenen Konnektor getriggert werden. Ebenso kann konfiguriert werden, dass ein Runbook nicht in Azure ausgeführt wird, sondern lokal auf einem On-Prem-Server, auf dem ein Hybrid-Worker läuft.
Daraus ergibt sich für unseren Use Case folgende detailliertere Systemstruktur:
Die PowerApp sendet über den Automation-Konnektor den Befehl, ein bestimmtes Runbook auszuführen. Gleichzeitig prüft der Hybrid Worker auf dem On-Premises-Server in regelmäßigen Zeitabständen, ob ein solcher Befehl bereits in der Azure Cloud angekommen ist. Sobald er erkennt, dass ein bestimmtes Runbook nun ausgeführt werden soll, lädt er es runter und führt es lokal im Kontext eines vorkonfigurierten lokalen Users aus.
Ausgaben und Fehlermeldungen eines so ausgeführten Jobs werden an die Automation-Ressource zurückgegeben und sind dort weiterhin geloggt und auch für die PowerApp verfügbar.
Selbstverständlich lassen sich Runbooks auch parametrisieren. Parameter, wie z.B. der Name des Users, der neu angelegt werden soll, können also aus einem Textfeld in der PowerApp an das Runbook weitergegeben werden.
Nachdem wir nun einen Eindruck gewonnen haben, was genau das Endsystem können soll, können wir uns dem Detail widmen und betrachten, wie genau dies umgesetzt werden kann.
Hierfür werden wir zunächst alle Ressourcen in der Azure Cloud vorbereiten. Anschließend werden wir den lokalen On-Premises-Server mit einem Hybrid-Worker ausstatten, damit dieser auf die Cloud-Ressourcen zugreifen kann. Zum Schluss werden wir einen PowerAutomate-Flow implementieren, der die Ausführung der Runbooks auf unserem On-Prem-Server triggert.
Beiträge dieser Serie
- PowerApps nutzen, um PowerShell-Skripte remote auf lokalen On-Premises-Servern auszuführen | Teil 1
- PowerApps nutzen, um PowerShell-Skripte remote auf lokalen On-Premises-Servern auszuführen | Teil 2
- PowerApps nutzen, um PowerShell-Skripte remote auf lokalen On-Premises-Servern auszuführen | Teil 3
- PowerApps nutzen, um PowerShell-Skripte remote auf lokalen On-Premises-Servern auszuführen | Teil 4
Lesetipp
Kennen Sie schon unsere Whitepaper? Laden Sie sich diese doch einfach zur Inspiration herunter:
Wenn Sie schon jetzt Ideen haben und nicht wissen, wo sie beginnen sollen: Unsere Microsoft 365-Experten unterstützen Sie gerne dabei, schon morgen mit Ihren smarten Lösungen zu beginnen. Wir freuen uns auf Ihren Anruf oder eine Nachricht über unser Kontaktformular.