Sektion 48: Remediations: Selbstheilende Infrastruktur mit Intune

In Sektion 47 hast du Plattformskripts kennengelernt: Sie laufen einmal und danach nur wieder, wenn du etwas änderst. Für vieles reicht das. Aber manche Zustände gehen im Alltag immer wieder kaputt: Ein Dienst bleibt stehen, ein Registry-Wert wird überschrieben, ein Zertifikat läuft ab. Genau dafür gibt es Remediations, früher Proactive Remediations genannt.

Eine Remediation prüft einen Zustand nach Zeitplan immer wieder und repariert ihn bei Bedarf selbst. So fällst du nicht erst auf das Problem herein, wenn ein Ticket kommt. In dieser Sektion geht es um das Werkzeug selbst: Voraussetzungen, Lizenzen, Einstellungen, Zeitpläne, Remediations auf Knopfdruck und die Auswertung. Die zentralen Regeln zu Exitcodes, Ausgaben und Fehlerbehandlung stehen in den folgenden Abschnitten. Eine eigene Folgesektion dazu gibt es derzeit nicht.

Grundlagen: So funktioniert eine Remediation

Skriptpaket aus Erkennung und Korrektur

Eine Remediation ist ein Skriptpaket. Es besteht aus einem Erkennungsskript, optional einem Korrekturskript und ein paar Metadaten. Die Intune Management Extension (IME) aus Sektion 46 holt die Skripts aus Intune und führt sie auf dem Gerät aus. Der Ablauf ist immer gleich:

1. Das Erkennungsskript prüft den Zustand. Endet es mit exit 1, gilt das Problem als gefunden.
2. Nur dann startet das Korrekturskript und behebt das Problem.
3. Danach läuft die Erkennung erneut. So siehst du im Bericht, ob die Korrektur wirklich geholfen hat.

Wichtig: Nur exit 1 löst die Korrektur aus. Jeder andere Exitcode, auch eine leere Ausgabe, bedeutet für Intune „kein Problem gefunden“. Ein Paket darf auch nur ein Erkennungsskript enthalten. Das ist praktisch, wenn du erst einmal nur wissen willst, wie viele Geräte betroffen sind, bevor du automatisch eingreifst.

Remediation, Plattformskript oder Richtlinie?

• Konfigurationsprofil oder Settings Catalog: Gibt es die Einstellung dort, nimm das Profil. Es ist einfacher zu pflegen als ein Skript.
• Plattformskript: für einmalige Aufgaben, siehe Sektion 47.
• Remediation: wenn ein Zustand regelmäßig geprüft und bei Bedarf repariert werden soll, oder wenn du Werte von vielen Geräten einsammeln willst, die es in keinem Bericht gibt.
• Einen kompakten Praxisüberblick mit weiteren Beispielen findest du auch im Beitrag Intune Remediations: PowerShell-Skripte, die sich selbst heilen.

Voraussetzungen

Geräte

• Die Geräte sind mit Microsoft Entra ID verbunden (Entra joined) oder hybrid verbunden (Entra hybrid joined).
• Zusätzlich gilt eine dieser Bedingungen: Das Gerät ist in Intune registriert (MDM) und läuft mit Windows Enterprise, Professional oder Education. Oder es ist ein co-verwaltetes Windows-Gerät.

Lizenzen

Die Benutzer der Geräte brauchen laut Microsoft eine dieser Lizenzen:

• Windows Enterprise E3 oder E5 (enthalten in Microsoft 365 F3, E3 oder E5)
• Windows Education A3 oder A5 (enthalten in Microsoft 365 A3 oder A5)
• Windows Virtual Desktop Access (VDA) pro Benutzer

Bevor du Remediations zum ersten Mal nutzt, muss ein Intune-Dienstadministrator im Admin Center bestätigen, dass die Lizenzanforderungen erfüllt sind. Erst danach kannst du Remediations nutzen.

Berechtigungen

Für Remediations brauchst du Rechte in der Kategorie Gerätekonfigurationen. Wer Remediations bei Bedarf auf einzelnen Geräten starten soll, braucht zusätzlich die Berechtigung Run remediation unter den Remoteaufgaben. Wie du eigene Rollen baust, steht in der Übersicht zur rollenbasierten Zugriffssteuerung.

Regeln für die Skripts

• Pro Mandant sind bis zu 200 Skriptpakete möglich.
• Die Skripts müssen in UTF-8 gespeichert sein. Lade die .ps1-Dateien hoch, statt sie im Browser zu bearbeiten. So bleibt die Kodierung sicher korrekt.
• Ist die Signaturprüfung aktiv, muss es UTF-8 ohne BOM sein. Das Skript läuft dann mit der Ausführungsrichtlinie des Geräts, unter Windows-Clients standardmäßig Restricted. Ohne Signaturprüfung läuft es mit Bypass, siehe about_Execution_Policies.
• Die Ausgabe darf höchstens 2.048 Zeichen lang sein.
• Keine Neustartbefehle in Erkennungs- oder Korrekturskripts.
• Keine Kennwörter, keine personenbezogenen Daten in den Skripts und keine Skripts, die personenbezogene Daten von Geräten einsammeln.

Integrierte Skriptpakete nutzen

Intune bringt zwei fertige Pakete mit, die du nur noch zuweisen musst: Update stale Group Policies (veraltete Gruppenrichtlinien aktualisieren) und Restart Office Click-to-run service (den Klick-und-Los-Dienst von Office neu starten). Das erste Paket ist für hybride Umgebungen gedacht, in denen Zertifikate oder Einstellungen noch per GPO kommen. Microsoft stellt eine Kopie davon auf der Seite PowerShell-Skripts für Remediations bereit, falls du die Schwelle von sieben Tagen ändern willst.

1. Im Intune Admin Center Geräte > Geräte verwalten > Skripts und Korrekturen öffnen und das integrierte Paket auswählen.
2. Eigenschaften wählen und neben Zuweisungen auf Bearbeiten klicken.
3. Gruppen zum Einschließen und Ausschließen festlegen, bei Bedarf Bereichstags setzen.
4. Über die drei Punkte neben der Zuweisung den Zeitplan anpassen und mit Überprüfen + speichern abschließen.

Die genauen Menübezeichnungen können je nach Spracheinstellung des Admin Centers leicht abweichen. Microsoft beschreibt die Schritte auf Englisch unter Devices > Manage devices > Scripts and remediations.

Ein eigenes Skriptpaket anlegen

Das Beispiel: ein Registry-Wert, der stimmen muss

Als Beispiel prüfen wir den Registry-Wert aus Sektion 47 dauerhaft: Unter HKLM:\SOFTWARE\Contoso soll Abteilung immer IT sein. Löscht oder ändert jemand den Wert, stellt die Remediation ihn beim nächsten Lauf wieder her. Das Erkennungsskript:

# Detect_Contoso_Abteilung.ps1 - Erkennungsskript
# exit 0 = alles in Ordnung, exit 1 = Problem gefunden (Korrekturskript startet)
$key  = 'HKLM:\SOFTWARE\Contoso'
$name = 'Abteilung'
$soll = 'IT'

try {
    $ist = (Get-ItemProperty -Path $key -Name $name -ErrorAction Stop).$name
    if ($ist -eq $soll) {
        Write-Output "OK: $name = $ist"
        exit 0
    }
    Write-Output "Abweichung: $name = $ist (erwartet: $soll)"
    exit 1
}
catch {
    Write-Output "Fehlt: $key\$name"
    exit 1
}

Ist der Wert korrekt, endet das Skript mit exit 0. Weicht er ab oder fehlt er ganz, endet es mit exit 1, und Intune startet die Korrektur. Die Ausgabe per Write-Output landet im Bericht. Halte sie kurz und gleichbleibend. Microsoft rät von Werten ab, die sich bei jedem Lauf ändern, etwa Zeitstempel.

Das passende Korrekturskript:

# Remediate_Contoso_Abteilung.ps1 - Korrekturskript
$key  = 'HKLM:\SOFTWARE\Contoso'
$name = 'Abteilung'
$soll = 'IT'

try {
    if (-not (Test-Path -Path $key)) {
        New-Item -Path $key -Force -ErrorAction Stop | Out-Null
    }
    New-ItemProperty -Path $key -Name $name -Value $soll -PropertyType String -Force -ErrorAction Stop | Out-Null
    Write-Output "Korrigiert: $name = $soll"
    exit 0
}
catch {
    Write-Error -Message "Korrektur fehlgeschlagen: $($_.Exception.Message)" -ErrorAction Continue
    exit 1
}

Das Korrekturskript ist idempotent: Es legt den Schlüssel nur an, wenn er fehlt, und setzt den Wert mit -Force. Bei einem Fehler schreibt es die Meldung in den Fehlerstream und endet mit Exitcode 1. Ob die Korrektur gewirkt hat, entscheidet am Ende aber die erneute Erkennung.

Paket im Admin Center erstellen

1. Geräte > Geräte verwalten > Skripts und Korrekturen öffnen und Skriptpaket erstellen wählen.
2. Unter Grundlagen Namen und Beschreibung eintragen. Das Feld Herausgeber ist mit deinem Namen vorbelegt und änderbar, die Version vergibt Intune selbst.
3. Unter Einstellungen Erkennungs- und Korrekturskript hochladen und die drei Schalter setzen (siehe unten).
4. Bereichstags setzen, falls du sie nutzt.
5. Unter Zuweisungen Gruppen auswählen, optional Filter nutzen, und den Zeitplan festlegen.
6. Mit Überprüfen + erstellen abschließen.

Laut Microsoft solltest du bei Ein- und Ausschlüssen keine Benutzer- und Gerätegruppen mischen. Wie Filter funktionieren, hast du in Sektion 45 gesehen.

Die drei Schalter in den Einstellungen

• Dieses Skript mit den Anmeldeinformationen des angemeldeten Benutzers ausführen: Nein heißt Systemkontext, Ja heißt Benutzerkontext. Für unser HKLM-Beispiel brauchst du Nein. Benutzerkontext nur, wenn du zum Beispiel etwas im Profil oder im Benutzerzertifikatsspeicher prüfst.
• Skriptsignaturprüfung erzwingen: Microsoft empfiehlt Nein. Aktivierst du sie, muss der Herausgeber im Speicher „Vertrauenswürdige Herausgeber“ des Geräts stehen, und die Ausführungsrichtlinie des Geräts gilt.
• Skript in 64-Bit-PowerShell ausführen: Für die Beispielskripts aus der Doku empfiehlt Microsoft Nein. Schreibt dein Skript aber nach HKLM:\SOFTWARE oder unter C:\Windows\System32, setz es auf Ja. Sonst landet der Wert per Umleitung unter WOW6432Node, genau wie bei den Plattformskripts in Sektion 47.

Zeitplan und Ablauf auf dem Gerät

Zeitplan pro Zuweisung

• Einmal: läuft genau einmal zu einem festen Datum und einer festen Uhrzeit.
• Stündlich: alle n Stunden, der Wert muss unter 24 liegen.
• Täglich: jeden Tag zu einer festen Uhrzeit.

Standardmäßig gilt die lokale Uhrzeit des Geräts. Mit UTC verwenden planst du in koordinierter Weltzeit. Ist ein Gerät zur geplanten Zeit aus, holt die IME den Lauf so bald wie möglich nach. Für Skripts, die nicht dringend sind oder viel Last erzeugen, empfiehlt Microsoft seltenere Läufe, etwa alle sieben Tage.

Wann das Gerät Richtlinien holt und berichtet

Die IME fragt neue oder geänderte Skriptpakete zu diesen Zeitpunkten ab:

• nach einem Neustart des Geräts oder des IME-Dienstes
• nach einer Benutzeranmeldung
• alle acht Stunden, gerechnet ab dem Start des IME-Dienstes. Anmeldungen verschieben diesen Takt nicht.

Auch die Berichte kommen nicht in Echtzeit. Läuft ein Paket einmalig, meldet das Gerät das Ergebnis direkt danach. Bei wiederkehrenden Paketen gilt ein Zyklus von sieben Tagen: In den ersten sechs Tagen meldet das Gerät nur Änderungen, der erste Lauf zählt als Änderung. Spätestens nach sieben Tagen kommt ein Bericht, auch ohne Änderung. Wundere dich also nicht, wenn ein Gerät im Bericht ein paar Tage alt aussieht.

Remediation bei Bedarf ausführen

Für den Support ist die Geräteaktion Run remediation praktisch. Sie ist laut Microsoft noch in der Vorschau. Damit startest du ein Skriptpaket sofort auf einem einzelnen Windows-Gerät, ohne auf den Zeitplan zu warten:

1. Geräte > Nach Plattform > Windows öffnen und das Gerät auswählen.
2. In der Übersicht über … die Aktion Run remediation (Vorschau) wählen.
3. Das Skriptpaket auswählen. Über View details siehst du vorher Skriptinhalt und Einstellungen.
4. Mit Run remediation starten.

• Das Paket muss in Intune vorhanden sein, aber nicht zugewiesen. Mit Bereichstags steuerst du, welche Pakete jemand sieht.
• Das Gerät muss online sein und Intune sowie den Windows-Pushbenachrichtigungsdienst (WNS) erreichen. Sonst kommt die Aktion nicht an.
• Die IME muss installiert sein. Das passiert automatisch, sobald dem Gerät oder Benutzer eine Win32-App, ein PowerShell-Skript oder eine Remediation zugewiesen ist.
• Pro Gerät läuft immer nur eine dieser Aktionen. Startest du mehrere kurz hintereinander, können sie sich gegenseitig überschreiben.

Praxis: Testen und auswerten

1. Den Ablauf lokal nachstellen

Bevor ein Paket an Geräte geht, teste es so, wie die IME es ausführt: im Systemkontext. Das folgende Skript spielt den Ablauf Erkennung, Korrektur und erneute Erkennung nach. Leg beide Skripts in den Ordner C:\Test und starte es in einer PowerShell, die als SYSTEM läuft (wie in Sektion 47 mit PsExec):

# Ablauf lokal nachstellen: Erkennung -> Korrektur -> erneute Erkennung
# In einer PowerShell als SYSTEM starten (z. B. psexec.exe -i -s powershell.exe)
Set-Location -Path 'C:\Test'

& powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\Detect_Contoso_Abteilung.ps1
$erkennung = $LASTEXITCODE
"Erkennung: Exitcode $erkennung"

if ($erkennung -eq 1) {
    & powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\Remediate_Contoso_Abteilung.ps1
    "Korrektur: Exitcode $LASTEXITCODE"

    & powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\Detect_Contoso_Abteilung.ps1
    "Erkennung nach Korrektur: Exitcode $LASTEXITCODE"
}

$LASTEXITCODE enthält den Exitcode des zuletzt gestarteten Programms, hier also den Wert aus exit 0 oder exit 1. Beim ersten Lauf auf einem Testgerät sollte die Erkennung 1 liefern, nach der Korrektur 0. Läuft die zweite Erkennung weiter auf 1, stimmt etwas mit dem Korrekturskript oder dem Kontext nicht.

2. Status im Admin Center prüfen

• Unter Skripts und Korrekturen siehst du pro Paket eine Übersicht zum Erkennungs- und Korrekturstatus.
• Gerätestatus zeigt die Details pro Gerät, inklusive der Ausgabe deiner Skripts. Deshalb lohnt sich eine kurze, aussagekräftige Ausgabe wie „Fehlt“ oder „Abweichung“.
• Mit Exportieren speicherst du die Ausgaben als CSV und kannst sie weiter auswerten oder teilen.
• Pro Gerät findest du alle zugewiesenen und bei Bedarf gestarteten Pakete unter Geräte > Nach Plattform > Windows > Gerät > Überwachen > Remediations.

Ein bekanntes Problem laut Microsoft: Filter wie „Autor“ oder „Status“ und der Export auf der Remediations-Seite berücksichtigen nur die bereits geladenen Pakete. Scroll also erst bis ans Ende der Liste, wenn du alles im Export haben willst.

3. HealthScripts.log auf dem Gerät lesen

Auf dem Gerät protokolliert die IME die geplanten Remediations in HealthScripts.log. Die Datei liegt mit den anderen IME-Logs unter C:\ProgramData\Microsoft\IntuneManagementExtension\Logs. Für einen schnellen Blick:

$log = 'C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\HealthScripts.log'

# Letzte Einträge der Remediations ansehen
Get-Content -Path $log -Tail 40

# Nach Fehlern suchen
Select-String -Path $log -Pattern 'error|fail|exit code' |
    Select-Object -Last 20 LineNumber, Line

Findest du dort nichts, sieh in IntuneManagementExtension.log nach, ob das Gerät die Richtlinie überhaupt bekommen hat. Für längere Analysen ist CMTrace.exe angenehmer als die Konsole.

Troubleshooting: Typische Probleme

Das Korrekturskript läuft nie

• Das Erkennungsskript endet nicht mit exit 1. Ein return oder ein Skript ohne Exitcode reicht nicht.
• Die Datei ist nicht in UTF-8 gespeichert oder wurde im Browser bearbeitet und dabei beschädigt.
• Die Signaturprüfung ist aktiv, aber das Skript ist nicht signiert, mit BOM gespeichert oder der Herausgeber ist dem Gerät nicht bekannt.

Remediations lassen sich nicht anlegen oder laufen nicht

• Die Lizenzbestätigung durch einen Intune-Dienstadministrator fehlt.
• Das Gerät ist nur registriert und nicht Entra joined oder hybrid joined, oder es läuft mit Windows Home.
• Der Dienst IntuneManagementExtension läuft nicht. Das prüfst du mit Get-Service -Name IntuneManagementExtension.
• Seit der Zuweisung sind noch keine acht Stunden vergangen und das Gerät wurde nicht neu gestartet. Ein Neustart des IME-Dienstes beschleunigt den Abruf.

Korrigiert, aber das Problem kommt immer wieder

• Etwas anderes setzt den Wert zurück, etwa eine GPO, ein Konfigurationsprofil oder eine App. Die Remediation behandelt dann nur das Symptom. Such die Ursache und lass Remediation und Richtlinie nicht gegeneinander arbeiten.
• Der Wert landet wegen des 32-Bit-Hosts unter WOW6432Node, die Erkennung prüft aber den 64-Bit-Zweig, oder umgekehrt. Beide Skripts laufen mit derselben 64-Bit-Einstellung des Pakets.

Best Practices

• Erst nur mit einem Erkennungsskript starten und zählen, wie viele Geräte betroffen sind. Dann die Korrektur ergänzen.
• Nur die Pakete zuweisen, die ein Gerät wirklich braucht. Jedes Skript startet PowerShell und kostet CPU und Akku.
• Zeitpläne so selten wie möglich und so oft wie nötig. Für unkritische Prüfungen reicht oft ein Lauf alle sieben Tage.
• Kurze, gleichbleibende Ausgaben ohne Zeitstempel, damit die Berichte lesbar bleiben.
• Mit einer Pilotgruppe starten, dann den Rollout ausweiten.
• Gibt es eine Richtlinie für die Einstellung, nutz die Richtlinie. Remediations sind für das, was Profile nicht abdecken.

Fazit

Remediations machen aus einmaligen Skripts eine dauerhafte Kontrolle: Erkennen, korrigieren, erneut prüfen, und das nach Zeitplan auf allen zugewiesenen Geräten. Die Technik ist schnell eingerichtet. Die meiste Arbeit steckt in den Voraussetzungen, den passenden Einstellungen und einer Erkennung, die zuverlässig 0 oder 1 liefert. Wenn du die Berichtszyklen kennst, wunderst du dich auch nicht mehr über Statuswerte, die ein paar Tage alt sind.

Zusammenfassend für deinen Workflow:

• Lizenzen und Geräte-Voraussetzungen prüfen, Lizenzbestätigung einmalig erledigen.
• Erkennungs- und Korrekturskript schreiben, lokal als SYSTEM testen.
• Paket mit passendem Kontext und 64-Bit-Einstellung anlegen, einer Pilotgruppe zuweisen, Zeitplan sinnvoll wählen.
• Gerätestatus, CSV-Export und HealthScripts.log auswerten.

Die vorstehenden Punkte zu Exitcodes, Ausgaben und Fehlerbehandlung sind die Grundlage, damit eine Remediation zuverlässig erkennt und sauber repariert. Eine eigene Folgesektion dazu gibt es derzeit nicht. Einen Überblick über alle Sektionen findest du auf der Seite Intune-Kurs.

Quellen

• Microsoft Learn: Verwenden von Korrekturmaßnahmen (Remediations)
• Microsoft Learn (englisch, aktuellere Fassung): Use Remediations to detect and fix support issues
• Microsoft Learn: PowerShell-Skripts für Remediations
• Microsoft Learn: Grundlegendes zur Microsoft Intune Management Extension
• Microsoft Learn: Filter in Microsoft Intune
• Microsoft Learn: Rollenbasierte Zugriffssteuerung in Microsoft Intune
• Microsoft Learn: Dateisystemumleitung (File System Redirector)
• Microsoft Learn: about_Execution_Policies

↑ Zur Kursübersicht: Intune-Kurs (alle Sektionen)