Die 10 häufigsten Azure Automation Fehler und wie man sie behebt

Wir prüfen Azure Automation Umgebungen bei Kunden in ganz Europa. Manche Wochen sehen wir denselben Fehler drei Mal bei drei verschiedenen Unternehmen. Das sind keine Einzelfälle. Das sind Muster.

Die gute Nachricht: Jeder einzelne dieser Fehler lässt sich beheben. Die meisten in weniger als einem Tag. Die schlechte Nachricht: Wer sie ignoriert, zahlt mit Ausfällen, Sicherheitslücken und instabilen Prozessen.

Hier sind die zehn häufigsten Azure Automation Fehler, die wir in echten Projekten finden. Sortiert danach, wie oft sie uns begegnen.

1. Immer noch AzureRM Module im Einsatz

Microsoft hat die AzureRM Module im Februar 2024 offiziell abgekündigt. Keine Sicherheitspatches mehr. Trotzdem finden wir sie jeden Monat in Produktivumgebungen.

Die Migration auf Az Module ist nicht nur eine Frage der Aktualität. AzureRM hat bekannte Kompatibilitätsprobleme mit PowerShell 7.x, das Azure Automation mittlerweile unterstützt. Wer bei AzureRM bleibt, sperrt sich in eine alternde Laufzeitumgebung mit bekannten Lücken ein.

So wird’s gelöst: Get-Module AzureRM* -ListAvailable über alle Automation Accounts laufen lassen. Jeden AzureRM-Aufruf durch das Az-Äquivalent ersetzen. Microsoft stellt einen Migrationsleitfaden bereit, der die Zuordnungen auflistet. Bei den meisten Cmdlets wird einfach AzureRM durch Az im Modulnamen ersetzt. Bei einigen wenigen haben sich Parameternamen geändert. Gründlich testen.

Aufwand: 1-3 Tage, je nach Anzahl der Runbooks.

2. Run As Accounts statt Managed Identity

Run As Accounts wurden im September 2023 deprecated. Neue kann man nicht mehr anlegen. Wer noch welche hat, sitzt auf einer tickenden Zeitbombe mit ablaufenden Zertifikaten.

Bei einem Finanzdienstleister hatten 14 Runbooks von einem einzigen Run As Account abgehangen. Das Zertifikat ist an einem Freitag Abend abgelaufen. Montag früh ging nichts mehr. Provisionierung, Reporting, Cleanup Jobs, alles tot.

So wird’s gelöst: Auf Managed Identity umstellen. System-assigned Managed Identity ist der einfachste Weg. Am Automation Account aktivieren, die nötigen RBAC-Rollen zuweisen, und Connect-AzAccount -ServicePrincipal durch Connect-AzAccount -Identity ersetzen. Fertig.

Für Runbooks, die auf Ressourcen in mehreren Tenants oder Subscriptions zugreifen müssen: User-assigned Managed Identity mit expliziten Scope-Zuweisungen verwenden.

→ Mehr dazu in unserem Guide: Sichere Azure Automation Architektur

3. Kein Error Handling in Runbooks

Das tut weh. Wir sehen Runbooks mit 200 Zeilen sequenziellen Befehlen ohne einen einzigen Try/Catch-Block. Wenn Schritt 47 fehlschlägt, steht eine kryptische Fehlermeldung im Job-Log und niemand weiß, in welchem Zustand die Umgebung jetzt ist.

Ein Runbook, das einen Benutzer anlegt, eine Lizenz zuweist und ein Postfach konfiguriert: Ohne Error Handling wird der Benutzer vielleicht erstellt, die Lizenz schlägt fehl, das Postfach wird nie eingerichtet. Ergebnis: Ein halb provisionierter User und kein Alert, der darauf hinweist.

So wird’s gelöst: Jede relevante Operation in Try/Catch wrappen. $ErrorActionPreference = 'Stop' an den Anfang jedes Runbooks setzen, damit auch nicht-terminierende Fehler tatsächlich gefangen werden. Strukturierte Ausgaben loggen, damit man nachvollziehen kann, wo genau etwas schiefgelaufen ist.

$ErrorActionPreference = 'Stop'

try {
    $user = New-AzADUser -DisplayName $DisplayName -UserPrincipalName $UPN
    Write-Output "ERFOLG: Benutzer $UPN erstellt"
} catch {
    Write-Error "FEHLER: Benutzer $UPN konnte nicht erstellt werden - $($_.Exception.Message)"
    throw
}

→ Wie ein vollständig automatisierter Onboarding-Prozess aussieht: Mitarbeiter-Onboarding automatisieren

4. Hardcodierte Zugangsdaten in Runbooks

Wir wünschten, das wäre selten. Ist es nicht. Mindestens einmal im Quartal finden wir Passwörter, API-Keys oder Connection Strings direkt im Runbook-Code.

Manchmal sind es „temporäre“ Credentials aus einem Proof of Concept, die es in die Produktion geschafft haben. Manchmal wusste jemand einfach nichts von Azure Key Vault. So oder so: Jeder mit Reader-Zugriff auf den Automation Account kann sie sehen.

So wird’s gelöst: Azure Key Vault für alle Secrets verwenden. Die Managed Identity des Automation Accounts mit Get-Berechtigung auf Key Vault Secrets verbinden. Credentials zur Laufzeit abrufen:

$secret = Get-AzKeyVaultSecret -VaultName "MyVault" -Name "APIKey" -AsPlainText

Für Werte, die sich selten ändern (Tenant IDs, Ressourcennamen): Automation Variables mit aktivierter Verschlüsselung sind akzeptabel. Aber alles Sensitive gehört in den Key Vault.

→ Alles über sichere Credential-Verwaltung: Azure Automation Security Best Practices

5. Keine Modul-Versionierung

„Letzte Woche hat’s noch funktioniert“ ist der Schlachtruf von Teams, die ihre Modulversionen nicht pinnen.

Azure Automation erlaubt den Import von Modulen, aktualisiert sie aber nicht automatisch. Die Kehrseite: Wenn man aktualisiert, bricht man möglicherweise bestehende Runbooks. Wir haben Umgebungen gesehen mit Az.Accounts 2.7 neben Az.Storage 5.x, das Az.Accounts 2.12+ erwartet. Das Ergebnis: Zufällige Fehler, die nur bei bestimmten Runbooks auftreten.

So wird’s gelöst: Modulversionen dokumentieren. Eine Manifestdatei in der Quellcodeverwaltung pflegen, die jedes Modul mit Version auflistet. Module bewusst aktualisieren, gegen die eigenen Runbooks testen, und das Update auf alle Automation Accounts gleichzeitig ausrollen. Am besten: Modul-Updates mit einem eigenen Runbook automatisieren, das Kompatibilität prüft, bevor es Änderungen anwendet.

6. Keine Source Control Integration

Runbooks direkt im Azure Portal bearbeiten fühlt sich schnell an. Bis jemand die Änderungen eines Kollegen überschreibt. Bis man einen Rollback braucht und es keine History gibt. Bis ein Audit fragt, wer wann was geändert hat.

So wird’s gelöst: Den Automation Account mit GitHub oder Azure DevOps verbinden. Azure Automation hat eine eingebaute Source Control Integration. Jede Runbook-Änderung geht über einen Pull Request. Man bekommt History, Reviews und Rollback-Fähigkeit. Die Einrichtung dauert 30 Minuten.

Für Teams, die bereits Azure DevOps nutzen: Der CI/CD-Pipeline-Ansatz funktioniert noch besser. Branch pushen, Tests laufen lassen, auf einen Staging Automation Account deployen, validieren, dann in Produktion übernehmen.

7. Netzwerkanforderungen des Hybrid Workers ignoriert

Hybrid Runbook Workers müssen mit Azure Automation kommunizieren. Das bedeutet ausgehend HTTPS (Port 443) zu bestimmten Azure-Endpunkten. Wir haben Deployments gesehen, die still fehlschlugen, weil eine Firewall-Regel den ausgehenden Traffic zu *.azure-automation.net blockiert hat.

Die Symptome sind verwirrend. Jobs werden in die Warteschlange gestellt, starten aber nie. Oder sie starten und hängen endlos. Die Logs zeigen nichts Brauchbares, weil der Worker nicht zurückmelden kann.

So wird’s gelöst: Vor dem Deployment eines Hybrid Workers die Netzwerkkonnektivität verifizieren. Microsoft publiziert die benötigten URLs und IP-Bereiche. Explizit testen:

Test-NetConnection -ComputerName "eus2-jobruntimedata-prod-su1.azure-automation.net" -Port 443

DNS-Auflösung nicht vergessen. In Umgebungen mit eigenen DNS-Servern kann es vorkommen, dass der Hybrid Worker Azure-Endpunkte nicht korrekt auflöst. Wir haben Stunden damit verbracht, „Konnektivitätsprobleme“ zu debuggen, die sich am Ende als DNS herausgestellt haben.

8. Kein Monitoring und keine Alerts bei fehlgeschlagenen Jobs

Der stille Killer. Ein Runbook schlägt jede Nacht fehl. Drei Wochen lang. Niemand merkt es, weil niemand Alerts eingerichtet hat. Wenn es dann auffällt, ist der Schaden längst da: Drei Wochen verpasste Bereinigungen, veraltete Daten oder kaputte Prozesse.

So wird’s gelöst: Mindestens eine Azure Monitor Alert-Regel für fehlgeschlagene Automation Jobs erstellen. Das dauert fünf Minuten:

1. Automation Account > Überwachung > Warnungen
2. Neue Warnungsregel erstellen
3. Signal: „Total Jobs“ mit Dimension „Status = Failed“
4. Aktionsgruppe: E-Mail, Teams Webhook oder was auch immer das Team monitort

Für kritische Runbooks: Ein „Heartbeat“-Muster einbauen. Wenn das Runbook seit X Stunden nicht erfolgreich gelaufen ist, Alert auslösen. Sich nicht nur auf Failure-Alerts verlassen. Denn wenn der Schedule kaputt geht, läuft der Job gar nicht mehr, und ein Failure-Alert feuert nicht für etwas, das nie ausgeführt wurde.

9. Falsche PowerShell Version (5.1 vs 7.x)

Azure Automation unterstützt sowohl PowerShell 5.1 als auch 7.x Laufzeiten. Die sind nicht austauschbar. Module, die für eine Version kompiliert wurden, funktionieren auf der anderen möglicherweise nicht. Syntax, die in 7.x funktioniert (ternäre Operatoren, Null-Coalescing), wirft in 5.1 Fehler.

Wir haben Teams gesehen, die ein Modul für die 7.2-Runtime importiert haben und sich wunderten, warum ihr 5.1-Runbook es nicht findet. Die Modul-Galerien sind pro Laufzeitversion getrennt.

So wird’s gelöst: Einen Standard festlegen. Für neue Runbooks: PowerShell 7.x. Schneller, leistungsfähiger und im Einklang mit Microsofts Roadmap. Bestehende 5.1-Runbooks: Schrittweise migrieren. Nicht mischen, es sei denn, es gibt einen konkreten Grund (manche Legacy-Module laufen nur auf 5.1).

Beim Modulimport prüfen, dass man in die richtige Runtime importiert. Das Azure Portal zeigt das klar an, aber bei Terraform- und ARM-Templates kann es uneindeutig sein.

10. Nicht lokal testen vor dem Deployment

„Ich teste das einfach in der Cloud“ klingt vernünftig, bis das Runbook die falsche Resource Group löscht. Oder 5.000 E-Mails verschickt. Oder 6 Stunden läuft und das Fair-Share-Limit erreicht.

So wird’s gelöst: Zuerst lokal testen. Dieselben Az Module auf der eigenen Workstation installieren. Mit Connect-AzAccount und persönlichen Credentials (auf eine Dev-Subscription beschränkt) verbinden. Die Runbook-Logik als normales PowerShell-Skript ausführen.

Für Runbooks, die vom Hybrid Worker Kontext oder Automation-spezifischen Features abhängen: Einen Test-Automation-Account erstellen. Der kostet nichts im Leerlauf. Dort deployen, ausführen, validieren, dann in Produktion übernehmen.

Man wird nicht jeden Fehler lokal finden. Manche Bugs zeigen sich nur in der Automation Sandbox. Aber die offensichtlichen erwischt man, bevor sie die Produktion erreichen.

Das Muster hinter diesen Fehlern

Wenn man die Liste nochmal durchgeht, haben die meisten Fehler eine gemeinsame Ursache: Azure Automation wird als simples Scripting-Tool behandelt statt als Produktionsplattform.

Runbooks betreiben Geschäftsprozesse. Sie provisionieren Benutzer, synchronisieren Daten, räumen Ressourcen auf und setzen Compliance durch. Wenn sie ausfallen, fallen Geschäftsprozesse aus.

Die eigene Automation-Umgebung verdient dieselbe Sorgfalt wie jedes andere Produktivsystem. Quellcodeverwaltung. Tests. Monitoring. Security Reviews. Das ist kein Overhead. Das ist Versicherung.

FAQ

Wie oft sollte man Azure Automation Module aktualisieren?

Modulversionen vierteljährlich prüfen. Sicherheitsupdates sofort einspielen. Bei Feature-Updates: Zuerst gegen die eigenen Runbooks in einem Staging-Account testen, bevor man sie in Produktion anwendet. Niemals Module in Produktion automatisch aktualisieren ohne Test.

Können AzureRM und Az Module parallel laufen?

Technisch ja, aber besser nicht. Sie verursachen Konflikte bei gemeinsamen Abhängigkeiten und unvorhersehbares Verhalten. Komplett auf Az Module migrieren. Microsoft stellt Tooling bereit, um AzureRM-Nutzung in den eigenen Runbooks zu identifizieren.

Was ist das Fair-Share-Limit in Azure Automation?

Cloud-Sandbox-Runbooks sind auf 3 Stunden Laufzeit begrenzt. Wenn ein Runbook mehr braucht, auf einem Hybrid Runbook Worker ausführen, der hat kein Zeitlimit. Bei lang laufenden Aufgaben: Die Arbeit in kleinere Runbooks aufteilen und mit einem übergeordneten Runbook orchestrieren.

Wie migriert man von Run As Accounts zu Managed Identity?

System-assigned Managed Identity am Automation Account aktivieren. RBAC-Rollen zuweisen, die den Berechtigungen des Run As Accounts entsprechen. Den Authentifizierungsblock in den Runbooks von Connect-AzAccount -ServicePrincipal -CertificateThumbprint ... auf Connect-AzAccount -Identity umstellen. Jedes Runbook einzeln testen.

PowerShell 5.1 oder 7.x für neue Runbooks?

PowerShell 7.x für alle neuen Entwicklungen. Schneller, unterstützt moderne Sprachfeatures und passt zur Microsoft-Roadmap. 5.1 nur verwenden, wenn eine harte Abhängigkeit auf ein Modul besteht, das nicht portiert wurde.

---

Kommen Ihnen einige dieser Punkte bekannt vor? Wir optimieren Azure Automation Umgebungen für Unternehmen in ganz Europa. Von schnellen Audits bis zum kompletten Neuaufbau: Wir kennen die Probleme und den schnellsten Weg zu einer stabilen Umgebung.

Kontakt aufnehmen und über Ihre Automation-Umgebung sprechen.