IT Do-It-Yourself: Automatyzacja restartu usług po awarii w Windows

Automatyzacja restartu usług po awarii w Windows – PowerShell w praktyce

W środowiskach produkcyjnych stabilność usług systemowych jest kluczowa. Awaria usługi może prowadzić do przestojów, błędów aplikacji lub utraty danych. PowerShell oferuje wiele sposobów na automatyzację reakcji na takie sytuacje – od prostych restartów po zaawansowane monitorowanie.

1. Ustawienia odzyskiwania usługi (Recovery Options)

Windows pozwala skonfigurować automatyczne działania po awarii usługi (np. restart) w zakładce „Odzyskiwanie” w konsoli usług. PowerShell nie ma natywnego cmdletu do zarządzania tymi ustawieniami, ale można użyć sc.exe:

sc.exe failure "Spooler" reset= 86400 actions= restart/60000/restart/60000/""/60000

reset= 86400 – reset licznika awarii po 1 dniu (86400 sekund)
actions= – kolejno: restart po 60 sek., restart po 60 sek., brak działania po 60 sek.

Można to zautomatyzować za pomocą funkcji PowerShell:

function Set-ServiceRecovery {
    param (
        [string]$ServiceName,
        [int]$ResetTime = 86400,
        [string]$Actions = "restart/60000/restart/60000/""/60000"
    )
    sc.exe failure $ServiceName reset= $ResetTime actions= $Actions
}
Set-ServiceRecovery -ServiceName "Spooler"

2. Monitorowanie cykliczne – skrypt PowerShell

Możesz stworzyć prosty skrypt, który cyklicznie sprawdza stan usługi i restartuje ją, jeśli jest zatrzymana:

$serviceName = "Spooler"
$service = Get-Service -Name $serviceName

if ($service.Status -ne "Running") {
    Restart-Service -Name $serviceName -Force
}

Taki skrypt można uruchamiać co kilka minut przez Harmonogram zadań Windows.

3. Harmonogram zadań + dziennik zdarzeń

Możesz utworzyć zadanie, które reaguje na konkretne zdarzenie w dzienniku systemowym, np. Event ID 7031 (awaria usługi). Harmonogram może uruchamiać skrypt PowerShell w odpowiedzi na to zdarzenie.

4. WMI + PowerShell – reakcja na zmianę stanu

Za pomocą WMI (Windows Management Instrumentation) możesz nasłuchiwać zmian stanu usług, reagując niemal natychmiast, gdy tylko usługa przestanie działać:

Register-WmiEvent -Query "SELECT * FROM __InstanceModificationEvent WITHIN 10 WHERE TargetInstance ISA 'Win32_Service' AND TargetInstance.State != 'Running'" -Action {
    Restart-Service -Name $Event.SourceEventArgs.NewEvent.TargetInstance.Name
}

5. Watchdog w tle – własny serwis monitorujący

Możesz stworzyć własny „watchdog” – skrypt działający w tle, który monitoruje usługę i reaguje na jej awarię. Poniżej przykład prostego skryptu:

Przykład: Watchdog monitorujący usługę „Spooler”

# Watchdog.ps1 – prosty monitoring usługi
$ServiceName = "Spooler"
$LogPath = "C:\Logs\watchdog.log"

function Log {
    param ($msg)
    $timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
    Add-Content -Path $LogPath -Value "$timestamp - $msg"
}

while ($true) {
    try {
        $service = Get-Service -Name $ServiceName
        if ($service.Status -ne "Running") {
            Log "Usługa '$ServiceName' nie działa. Próba restartu..."
            Restart-Service -Name $ServiceName -Force
            Log "Usługa '$ServiceName' została zrestartowana."
        } else {
            Log "Usługa '$ServiceName' działa poprawnie."
        }
    } catch {
        Log "Błąd: $_"
    }
    Start-Sleep -Seconds 60
}

Jak uruchomić jako usługę:

Użyj narzędzia NSSM – Non-Sucking Service Manager (https://nssm.cc/) do uruchomienia skryptu jako usługi Windows.
Skrypt będzie działał w tle i logował działania do pliku.

6. Rozwiązania korporacyjne

W większych środowiskach warto rozważyć dedykowane, komercyjne platformy:

System Center Operations Manager (SCOM) – zaawansowane monitorowanie i automatyczne akcje.
Intune + PowerShell scripts – w środowiskach zarządzanych przez Microsoft Endpoint Manager.
Zabbix/Nagios – zewnętrzne monitorowanie z akcjami naprawczymi (często zintegrowane z własnymi skryptami).

IT Do-It-Yourself

Manu

Automatyzacja restartu usług po awarii w Windows