Azure Automation: PowerShell-Skripte zentral ausführen

Runbook-Typen und Runtime-Versionen

Textuelle PowerShell Runbooks bilden den Standard in Azure Automation und eignen sich besonders für Administratoren, die ihre ersten Schritte mit Runbooks machen. Im Kern handelt es sich um gewöhnliche PowerShell-Skripte, die nicht lokal auf dem Server laufen, sondern innerhalb der Azure-Automation-Umgebung oder auf einem sogenannten Hybrid Runbook Worker. Damit lassen sich wiederkehrende Aufgaben wie Bereinigung, Reporting oder Benutzerverwaltung zentral steuern, ohne dass manuell ein Skript gestartet werden muss.

Die Erstellung erfolgt über das Azure-Portal oder durch Import vorhandener Skripte. Ein typisches Beispiel ist ein Runbook, das regelmäßig temporäre Dateien löscht:

Get-ChildItem -Path "C:\Temp" -Recurse | Remove-Item -Force

Wird dieser Code als Runbook gespeichert und mit einem Zeitplan versehen, läuft die Bereinigung automatisiert zu den gewünschten Intervallen. Ebenso lassen sich Module wie Az.Storage oder Az.Compute einbinden, um Cloud-Ressourcen zu verwalten:

$vm = Get-AzVM -ResourceGroupName "RG1" -Name "TestVM"
Stop-AzVM -ResourceGroupName "RG1" -Name "TestVM" -Force

Mit solchen Befehlen können Administratoren VMs herunterfahren, Berichte erstellen oder Konten pflegen. Der Vorteil gegenüber der klassischen Aufgabenplanung liegt in der zentralen Verwaltung, der Integration in Azure-Dienste und der Möglichkeit, die Ausführung auch auf eigene Server auszuweiten.

Unterstützt werden PowerShell 5.1 und 7.4, diese sind in einem Automation Account parallel nutzbar. PowerShell 7.4 startet schneller als Workflows, benötigt keine Workflow-Semantik und passt für Cloud sowie Hybrid Worker auf Windows und Linux. Workflow-Runbooks bleiben an 5.1 gebunden, bieten Checkpoints und Parallelblöcke, starten aber langsamer und bringen Deserialisierungskomplexität. Python 3.10 steht als Alternative bereit, grafische Runbooks werden ausschließlich im Portal erstellt und eignen sich für visuelle Abläufe.

Runtime Environments und Module

In Azure Automation ist jede Laufzeitumgebung klar von anderen getrennt. Ein Runbook, das mit PowerShell 7.4 ausgeführt wird, greift ausschließlich auf Module zurück, die ebenfalls für Version 7.4 bereitstehen. Für Runbooks mit PowerShell 5.1 gilt das Gleiche. Standardmäßig ist in der 7.4-Umgebung das Az-Modul in Version 12.3.0 installiert. Abhängigkeiten werden bei der Ausführung geprüft, sodass fehlende Module zu Laufzeitfehlern führen können. Natürlich werden auch hier die jeweils aktuellen Modelle eingebunden, sobald diese zur Verfügung stehen.

Einige Einschränkungen sind zu beachten. In der 7.4-Laufzeitumgebung werden Modulaktivitäten nicht automatisch extrahiert. Die Integration mit Quellcodeverwaltung (Source Control) ist für 7.4 derzeit nur eingeschränkt nutzbar und signierte Runbooks werden in den Versionen ab 7.x nicht unterstützt. Für mehr Stabilität empfiehlt es sich, nur die tatsächlich benötigten Submodule zu importieren, beispielsweise beim Einsatz von Microsoft Graph. Ein typischer Modulimport in einem Runbook sieht so aus:

Import-Module -Name Microsoft.Graph.Authentication -RequiredVersion 2.15.0
Import-Module -Name Microsoft.Graph.Users -RequiredVersion 2.15.0
Connect-MgGraph -Identity
Get-MgUser -All

Dieses Beispiel verdeutlicht, dass gezielt nur bestimmte Module eingebunden werden und das Runbook damit eine saubere Umgebung für die gewünschten Verwaltungsaufgaben erhält.

Sichere Authentifizierung mit Managed Identity

Bei Azure Automation stehen zwei Varianten für Managed Identities zur Verfügung. Die systemseitig zugewiesene Identität ist fest mit dem jeweiligen Automation-Account verbunden und wird automatisch erstellt. Eine benutzerseitig zugewiesene Identität hingegen ist unabhängig vom Account, kann mehrfach genutzt und flexibel zugeordnet werden.

Die Rechtevergabe erfolgt über Azure-Rollen, die möglichst auf der kleinstmöglichen Ebene zugewiesen werden sollten. Für den Betrieb von virtuellen Maschinen reicht in der Regel eine passende Rolle auf Ressourcengruppenebene. Greift ein Runbook auf Microsoft Graph zu, müssen die benötigten Berechtigungen dem Service Principal der jeweiligen Identität einmalig erteilt werden:

# Anmelden an Azure mit System Assigned Identity
Disable-AzContextAutosave -Scope Process
Connect-AzAccount -Identity
$ctx = Set-AzContext -SubscriptionId "<SUB>"
 
# Anmelden am Microsoft Graph mit System Assigned Identity
Connect-MgGraph -Identity
# Erforderliche Berechtigungen zuvor per Admin Consent vergeben

Parameter, Ausgabe, Logging

Ein Runbook gibt Ausgaben entweder mit Write-Output oder direkt über die Pipeline zurück. Der Befehl Write-Host erzeugt dagegen keine sichtbare Ausgabe im Job-Protokoll. Jeder Runbook-Job erhält eine eindeutige ID und durchläuft die Phasen Warteschlange, Start und Ausführung. Protokolle erscheinen im Bereich Output, während Fehler separat unter Errors aufgeführt werden. Parameter werden wie in gewöhnlichen PowerShell-Skripten definiert. Im Testbereich wird die Entwurfsversion ausgeführt, während die Veröffentlichung die produktive Fassung eines Runbooks bereitstellt.

param(
  [string]$ResourceGroup,
  [string]$VmName
)
Disable-AzContextAutosave -Scope Process
Connect-AzAccount -Identity
$ctx = Set-AzContext -SubscriptionId "<SUB>"
Start-AzVM -Name $VmName -ResourceGroupName $ResourceGroup -DefaultProfile $ctx

Zeitsteuerung und Webhooks

Ein Runbook kann über Zeitpläne automatisch und wiederkehrend gestartet werden. Die dafür definierten Parameter sind fest mit dem Zeitplan verknüpft und lassen sich nur durch eine neue Verknüpfung anpassen. Alternativ kann ein Runbook über einen Webhook ausgelöst werden, der per HTTP-POST aufgerufen wird.

Ein Webhook ist eine spezielle Internetadresse, die ein Runbook direkt starten kann, sobald ein externer Dienst diese Adresse per HTTP-POST aufruft. Man kann sich das wie einen Auslöser von außen vorstellen: Ein Monitoring-Tool oder eine Anwendung sendet Daten an die Webhook-URL und Azure Automation verarbeitet diese sofort im Runbook. Die URL wird nach der Erstellung nur einmal angezeigt und ist zeitlich befristet gültig. Damit lassen sich Runbooks flexibel in andere Systeme einbinden, ohne dass ein Administrator manuell eingreifen muss. Die übermittelten Informationen stehen dem Runbook im Parameter WebhookData zur Verfügung.

Die zugehörige URL wird einmalig angezeigt, ist zeitlich begrenzt gültig und übergibt eingehende Daten an den Parameter WebhookData.

param([object]$WebhookData)
if ($WebhookData) {
  $body = ($WebhookData.RequestBody | ConvertFrom-Json)
  Write-Output "Aktion $($body.action) für $($body.target)"
} else {
  Write-Output "Manueller Start ohne Webhook"
}

Python Runbooks werden nicht über Webhooks gestartet. Für sie bieten sich Zeitpläne oder API-Calls an.

Geteilte Ressourcen für Betrieb und Wiederverwendung

Anmeldeinformationen und Variablen werden zentral im Automation-Account verwaltet. Mit dem Cmdlet Get-AutomationPSCredential lassen sich gespeicherte PSCredential-Objekte abrufen. Variablen können mit Get-AutomationVariable gelesen und mit Set-AutomationVariable verändert werden. Für komplexere Datenstrukturen hat sich die Speicherung im JSON-Format als zuverlässig und flexibel erwiesen:

# Credential laden
$cred = Get-AutomationPSCredential -Name "svc-admin"
 
# Variable lesen und setzen
$conf = Get-AutomationVariable -Name "ReportRecipients"
Set-AutomationVariable -Name "LastRun" -Value (Get-Date).ToString("s")
 
# Komplexes Objekt als JSON speichern
$vmIds = (Get-AzVM -Status | Where-Object Location -eq "westeurope").Id
Set-AutomationVariable -Name "VmIdsJson" -Value ($vmIds | ConvertTo-Json)

Beispiele für praxisnahe Automatisierung

Ein Runbook zur Skalierung von virtuellen Maschinen passt deren Größe nach einem definierten Ablauf an. Zunächst wird die VM angehalten, anschließend wird die neue SKU zugewiesen und danach die Maschine wieder gestartet. Über Parameter lässt sich festlegen, ob die Skalierung nach oben oder unten erfolgen soll und welche Zielgröße verwendet wird. Im Jobstream erscheinen Statusmeldungen, die den Fortschritt der einzelnen Schritte und das Endergebnis dokumentieren:

param(
  [ValidateSet("ScaleUp","ScaleDown")] [string]$Mode,
  [string]$ResourceGroup,
  [string]$VmName,
  [string]$SizeUp = "Standard_D4s_v5",
  [string]$SizeDown = "Standard_B2ms"
)
Disable-AzContextAutosave -Scope Process
Connect-AzAccount -Identity
$ctx = Set-AzContext -SubscriptionId "<SUB>"
$targetSize = if ($Mode -eq "ScaleUp") { $SizeUp } else { $SizeDown }
Stop-AzVM -Name $VmName -ResourceGroupName $ResourceGroup -Force -DefaultProfile $ctx
$vm = Get-AzVM -Name $VmName -ResourceGroupName $ResourceGroup -DefaultProfile $ctx
$vm.HardwareProfile.VmSize = $targetSize
Update-AzVM -ResourceGroupName $ResourceGroup -VM $vm -DefaultProfile $ctx
Start-AzVM -Name $VmName -ResourceGroupName $ResourceGroup -DefaultProfile $ctx

Ein weiteres, typisches Beispiel ist ein Runbook zur Bereinigung von Verzeichnissen auf lokalen Servern. Dieses wird auf einem Windows Hybrid Runbook Worker ausgeführt. Der Worker ist zuvor mit dem Automation Account registriert und dadurch fest angebunden. Die Ausführung geschieht lokal auf dem Server, bleibt jedoch vollständig über Azure Automation steuerbar und wird zentral protokolliert.

# Zielpfade auf Hybrid Worker bereinigen
param([string]$Path = "C:\Temp", [int]$Days = 14)
Get-ChildItem -Path $Path -Recurse -ErrorAction SilentlyContinue |
  Where-Object { $_.LastWriteTime -lt (Get-Date).AddDays(-$Days) } |
  Remove-Item -Recurse -Force -ErrorAction Continue

Noch ein praxisnahes Beispiel ist ein Runbook, das mithilfe von Microsoft Graph deaktivierte Benutzerkonten ausliest, ohne dass dafür eine interaktive Anmeldung erforderlich ist. Damit dieses Szenario funktioniert, muss die verwendete Managed Identity mit den passenden Graph Application Permissions ausgestattet werden, typischerweise Directory.Read.All oder User.Read.All. Zusätzlich sind die Module Microsoft.Graph.Authentication und Microsoft.Graph.Users im Automation Account bereitzustellen, damit die Abfragen technisch ausgeführt werden können. Ein solches Runbook lässt sich einsetzen, um regelmäßig eine Liste nicht mehr verwendeter Konten zu erstellen und die Ergebnisse im Output-Stream oder in einer zentralen Variablen abzulegen. Damit wird die Kontenverwaltung automatisiert und Sicherheitsrisiken durch verwaiste Identitäten lassen sich schneller erkennen.

# Deaktivierte Benutzer ermitteln
Connect-MgGraph -Identity
$users = Get-MgUser -All -Filter 'accountEnabled eq false' -Property displayName,userPrincipalName
$users | Select-Object displayName, userPrincipalName | ForEach-Object {
  Write-Output "$($_.displayName) $($_.userPrincipalName)"
}

Hybrid Runbook Worker auf eigenen Servern

Die Ausführung auf Hybrid Workern bringt Automatisierung in das eigene Netzwerk. Runbooks laufen zielgerichtet auf dem Worker und greifen auf lokale Ressourcen zu. Updates, Diensterneuerungen, Inventarisierung, Dateiauslieferung oder Hyper-V-Aufgaben werden so zentral angeschoben. Die Laufzeit dieser lokalen Jobs taucht nicht in der Cloud-Minutenabrechnung auf. Workflow und grafische Runbooks sind auf Linux-Workern nicht vorgesehen. Textuelle PowerShell Runbooks funktionieren plattformübergreifend, sofern die benötigten Module auf dem Worker vorhanden sind.

Grenzen und bekannte Besonderheiten

Einige Funktionen, die Administratoren aus der lokalen PowerShell kennen, stehen in Azure Automation nicht oder nur eingeschränkt zur Verfügung. So schlägt beispielsweise Start-Job -Credential fehl, da Runbooks keine benutzerdefinierten Anmeldeinformationen für Jobs verarbeiten können. Auch direkte Zugriffe auf interne Dateipfade sind nicht zuverlässig, da sich die Backend-Infrastruktur ändern kann. Child-Runbooks werden nicht mit der Punktnotation (.\child.ps1) aufgerufen, sondern müssen über Start-AzAutomationRunbook gestartet werden.

Beim Einsatz des Moduls ExchangeOnlineManagement ab Version 3 ist zu beachten, dass zusätzlich die Module PowerShellGet und PackageManagement explizit bereitgestellt werden müssen, da sonst Fehler auftreten können. In der Runtime-Version 7.4 fehlen derzeit sowohl die Möglichkeit zur Signierung von Runbooks als auch eine vollständige Integration in Source Control.

Workflow-Runbooks sind weiterhin nur mit PowerShell 5.1 nutzbar, starten langsamer und liefern deserialisierte Objekte zurück, was die Weiterverarbeitung erschwert. Für moderne Szenarien, in denen parallele Abläufe benötigt werden, reicht in der Regel ein Runbook mit Runtime 7.4 aus. Mit den dort verfügbaren Sprachmitteln wie ForEach-Object -Parallel oder dem parallelen Aufruf von Cmdlets lässt sich Parallelität effizienter und mit weniger Komplexität als in der Workflow-Syntax umsetzen.

Vergleich mit Windows Aufgabenplanung

Der Task Scheduler bleibt eine kostenfreie Minimalvariante auf Einzelsystemen. Sicherheit entsteht erst durch restriktive NTFS-Rechte auf Skriptordnern. Ohne Schutz droht Privilege Escalation, sobald Aufgaben mit erhöhten Rechten laufen. Parameter wie -ExecutionPolicy Bypass gelten pro Task und umgehen keine Unternehmensrichtlinien. Azure Automation liefert dagegen zentrale Orchestrierung, Identitäten ohne Geheimnisverwaltung, strukturierte Logs und saubere Trennung von Entwurf und Produktion. In gemischten Landschaften lohnt die Kombination. Legacy-Aufgaben bleiben lokal, neue Abläufe ziehen in Runbooks um.

In der Praxis ist es entscheidend, die Parameter in PowerShell korrekt zu setzen, da sonst Skripte nicht wie erwartet laufen. Ein klassisches Szenario ist die Aufgabenplanung unter Windows. Dort wird im Feld Programm/Script der Pfad zur PowerShell-Engine angegeben, also etwa C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe. Im Feld Argumente werden die Parameter übergeben.

Für ein sicheres und unbeaufsichtigtes Ausführen sollte man -NoProfile -NonInteractive -ExecutionPolicy Bypass -File "C:\Skripte\Temp-Leeren.ps1" angeben. Damit wird sichergestellt, dass keine Benutzereinstellungen geladen werden, die Ausführung nicht auf Benutzereingaben wartet und die lokale ExecutionPolicy nicht blockiert.

Auch unter PowerShell 7 läuft das Prinzip gleich. Hier genügt der Aufruf von pwsh.exe -NoProfile -NonInteractive -ExecutionPolicy Bypass -File "C:\Skripte\Job.ps1". Besonders der Parameter -ExecutionPolicy Bypass ist relevant, da er die Ausführung nur für diesen einen Prozess zulässt, ohne das System dauerhaft zu verändern.

Für Runbooks in Azure Automation gibt es andere Einstiegspunkte. Sollen diese über Webhooks von externen Diensten ausgelöst werden, geschieht dies über einen HTTP-POST. Ein Beispiel ist der Befehl Invoke-WebRequest -Method POST -Uri $WebhookUrl -Body ($payload | ConvertTo-Json) -ContentType 'application/json'. Die URL wird beim Erstellen des Webhooks bereitgestellt und muss gut geschützt werden, da jeder mit Kenntnis dieser Adresse das Runbook auslösen könnte.

Wenn Runbooks untereinander verschachtelt sind, dürfen sie nicht per Punktnotation geladen werden. Stattdessen wird Start-AzAutomationRunbook verwendet. Ein typisches Beispiel lautet:

Start-AzAutomationRunbook -ResourceGroupName "RG1" -AutomationAccountName "AA1" -Name "MeinRunbook" -Parameters @{ VmName = "VM01"; ResourceGroup = "RG1" }

Auf Wunsch kann die Ausführung auf einen bestimmten Hybrid Worker gelenkt werden, indem zusätzlich der Parameter -RunOn angegeben wird.

Für die Anmeldung innerhalb von Runbooks wird in der Regel die Managed Identity des Automation Accounts genutzt. Zunächst wird mit Disable-AzContextAutosave -Scope Process verhindert, dass ein Kontext zwischengespeichert wird. Danach erfolgt die Anmeldung über Connect-AzAccount -Identity. Soll zusätzlich Microsoft Graph eingebunden werden, bietet sich Connect-MgGraph -Identity an. Auf diese Weise lassen sich sowohl Azure-Ressourcen als auch Objekte in Microsoft 365 automatisiert steuern, ohne dass interaktive Anmeldungen erforderlich sind.

Fazit

Die PowerShell gewinnt mit Azure Automation an Reichweite. Ein Runbook bündelt Skript, Identität, Laufzeit und Protokoll zu einer betreibbaren Einheit. Zeitpläne, Webhooks und API führen die Auslösung zusammen. Variablen, Credentials und dedizierte Runtimes sorgen für reproduzierbare Ausführung. Hybrid Worker schließen den Weg ins eigene Netz. Das Kostenmodell bleibt planbar, die freien Minuten genügen für viele regelmäßige Aufgaben. Wer heute PowerShell produktiv nutzt, erhält damit eine tragfähige Automatisierungsplattform von Cloud bis Serverraum.