GPO Baseline v2602 ausrollen — aber richtig
Heruntergeladen, importiert, verknüpft — fertig? Weit gefehlt. Eine Security Baseline ist kein Selbstläufer. Wir zeigen, wie ihr v2602 sicher in die Produktion bringt, Drift erkennt und mit dem ISW GPO Analyzer Pro dauerhaft sauber bleibt.
Im März haben wir an dieser Stelle die Neuerungen der Windows Server 2025 Security Baseline v2602 vorgestellt: Sudo-Deaktivierung, drei neue NTLM-Audit-Policies, Druckerhärtung, ROCA-Schutz. Wer den Artikel noch nicht gelesen hat, findet ihn hier.
Heute geht es um den Teil, der in den meisten Anleitungen fehlt: Was passiert nach dem Download? Denn zwischen “Baseline importiert” und “Umgebung wirklich gehärtet” liegen in der Praxis Welten — Legacy-Anwendungen, die still sterben, GPO-Konflikte, die niemand bemerkt, und Drift, der sich über Wochen einschleicht.
Dieser Artikel zeigt euch den vollständigen Rollout-Prozess: von der Lab-Validierung über den stufenweisen Produktiv-Rollout bis zum dauerhaften Compliance-Monitoring mit dem ISW GPO Analyzer Pro.
“Baseline angewendet” bedeutet nicht “Baseline aktiv”. Bestehende GPOs mit höherer Priorität, lokale Registry-Overrides, WMI-Filter-Fehler oder schlicht falsch verknüpfte Richtlinien sorgen dafür, dass zahlreiche Baseline-Settings in der Praxis nie greifen — ohne dass jemand es merkt. Genau das macht regelmäßiges GPO-Auditing unverzichtbar.
Phase 1 — Download und Vorbereitung
Security Compliance Toolkit herunterladen
Die aktuelle Baseline v2602 (veröffentlicht am 23. Februar 2026) ist im Microsoft Security Compliance Toolkit verfügbar. Das Paket enthält:
Fertige GPO-Backup-Ordner für Domain Controller und Member Server — direkt importierbar via GPMC.
Vollständige Auflistung aller empfohlenen Settings — ideal für Change-Management und Auditor-Dokumentation.
Tool zum Anwenden/Exportieren lokaler Policies — unverzichtbar für Lab-Validierung ohne Domänenanbindung.
Microsoft-Tool zum Vergleich von Baseline vs. aktueller GPO-Konfiguration — gut als erster Schritt, aber begrenzt in Tiefe und Reporting.
# Schritt 1: Alle vorhandenen GPOs sichern (IMMER zuerst!)
$backupPath = “C:\GPO_Backups\$(Get-Date -Format ‘yyyy-MM-dd_HHmm’)”
New-Item -ItemType Directory -Path $backupPath -Force | Out-Null
Backup-Gpo -All -Path $backupPath
Write-Host “Backup gespeichert: $backupPath” -ForegroundColor Green
# Schritt 2: Baseline-GPO aus SCT-Paket importieren
$baselinePath = “C:\SCT\Windows Server 2025 Security Baseline – 2602\GPOs”
Import-GPO -BackupGpoName “MSFT Windows Server 2025 – Domain Controller” `
-Path $baselinePath `
-TargetName “ISW-Baseline-WS2025-DC” `
-CreateIfNeeded
Phase 2 — Lab-Validierung: Hier sparen viele die falsche Zeit
Die häufigsten Produktionsprobleme bei Baseline-Rollouts entstehen, weil die Lab-Phase übersprungen oder zu dünn besetzt wurde. Richtige Lab-Validierung bedeutet: Ihr spiegelt die Produktionsumgebung so genau wie möglich — gleiche Serverrollen, gleiche Drittanbieter-Agenten, gleiche Backup-Software.
Typische Sollbruchstellen der v2602-Baseline
| Baseline-Änderung | Mögliche Auswirkung | Testen mit |
|---|---|---|
| Sudo deaktiviert (MS + DC) | DevOps-Workflows, CI/CD-Pipelines, Admin-Skripte die sudo nutzen schlagen fehl | Alle Automatisierungs-Skripte und Deployment-Pipelines |
| NTLM-Auditing aktiviert | Erhöhtes Log-Volumen, SIEM-Kapazität prüfen; Legacy-Apps sichtbar die NTLM nutzen | Event Log Volumen messen, SIEM-Konfiguration anpassen |
| Druckerhärtung (RPC/Kerberos) | Drucker mit alten Treibern oder IPP/selbst-signierten Zertifikaten können ausfallen | Alle Druckermodelle im Netz, insbesondere Netzwerkdrucker mit eigenem Spooler |
| ROCA-Schutz (WHfB-Keys) | Windows Hello for Business-Anmeldungen mit betroffenen TPM-Schlüsseln werden blockiert | WHfB-Enrollment auf Testgeräten durchspielen |
| IE11 COM-Automation blockiert | Ältere Intranet-Anwendungen oder Reporting-Tools die IE via COM aufrufen brechen | Inventur aller Applikationen mit IE-Abhängigkeit |
Vor/Nach-Snapshot per PowerShell erstellen
Erstellt vor dem Baseline-Import einen vollständigen Snapshot der aktuellen GPO-Konfiguration — das ist eure Baseline gegen die Baseline:
$reportPath = “C:\GPO_Reports\$(Get-Date -Format ‘yyyy-MM-dd’)_Vorher”
New-Item -ItemType Directory -Path $reportPath -Force | Out-Null
Get-GPO -All | ForEach-Object {
Get-GPOReport -Guid $_.Id -ReportType Html `
-Path “$reportPath\$($_.DisplayName -replace ‘[\\/:*?””<>|]’,’_’).html”
}
Write-Host “$((Get-GPO -All).Count) GPO-Reports gespeichert in: $reportPath” -ForegroundColor Cyan
# RSoP für alle Server in einer Test-OU ermitteln
$testOU = “OU=Testserver,DC=contoso,DC=local”
Get-ADComputer -SearchBase $testOU -Filter * | ForEach-Object {
$rsopPath = “$reportPath\RSoP_$($_.Name).html”
Get-GPResultantSetOfPolicy -Computer $_.Name -ReportType Html `
-Path $rsopPath -ErrorAction SilentlyContinue
}
Phase 3 — GPO-Audit mit dem ISW GPO Analyzer Pro
An diesem Punkt stellt sich die entscheidende Frage: Greifen die Baseline-Settings wirklich? Genau hier stoßen die Microsoft-Bordmittel an ihre Grenzen. Der PolicyAnalyzer aus dem SCT vergleicht GPO-Objekte — aber er zeigt nicht, was am Ende tatsächlich auf einem Server angewendet wird. Konflikte, überlagernde Policies, GPO-Vererbung und WMI-Filter-Probleme bleiben unsichtbar.
Analyse aller GPOs auf Konflikte, Überlagerungen und ineffektive Settings
Sicherheitslücken-Erkennung: Deaktivierte Audits, schwache Passwort-Policies, unsichere Protokoll-Settings
Vererbungsanalyse: Wo wird welche GPO tatsächlich angewendet oder blockiert?
Leere und verwaiste GPOs identifizieren, die Verarbeitungszeit kosten
SYSVOL-Konsistenzprüfung: Replikationsprobleme zwischen Domain Controllern aufdecken
PDF- und HTML-Berichte für Audits, Compliance-Dokumentation und Management-Reporting
Was ihr nach dem Baseline-Rollout prüfen solltet
Nach dem Import der v2602-Baseline sind dies die kritischen Prüfpunkte, auf die der ISW GPO Analyzer Pro euch automatisch hinweist:
Wenn eine ältere “Corporate-Default”-GPO mit höherer Priorität auf die gleiche OU verknüpft ist, gewinnt sie — und überschreibt die Baseline-Settings. Ohne Analyse sieht man das nicht. Der ISW GPO Analyzer zeigt euch Konflikt-Settings mit Quellenangabe.
Die v2602-Baseline aktiviert NTLM-Auditing auf DC- und Member-Server-Ebene. Eine überlagernde GPO kann diese Settings still überschreiben — und ihr seht nie die NTLM-Events, die ihr für die spätere Enforcement-Entscheidung braucht.
Nach einem Rollout landet oft eine “MSFT Windows Server 2025 – Member Server”-GPO ohne aktive Verknüpfung im Schrank. Die GPO wird verarbeitet (kostet Zeit), wirkt aber nirgends. ISW GPO Analyzer Pro kennzeichnet solche toten GPOs automatisch.
Baseline-Imports erzeugen neue GPO-Objekte in AD und SYSVOL. Wenn SYSVOL-Replikation zwischen DCs hakt, landen die neuen Policies nur auf einem DC und werden für andere OUs nie angewendet. Ein klassischer stiller Fehler.
Phase 4 — Stufenweiser Produktiv-Rollout
Microsoft empfiehlt ausdrücklich: Keine “One GPO to rule them all”-Mentalität. Die Baseline ist ein Ausgangspunkt — keine Komplettlösung, die man blind in die Produktion drückt. Der bewährte Rollout-Pfad:
Baseline auf einer Handvoll wenig kritischer Server anwenden. GPO-Analyzer-Audit durchführen. NTLM-Events zählen, Log-Volumen messen. Helpdesk-Tickets aus dieser Gruppe engmaschig verfolgen.
File-Server und Infrastruktur-Server inkludieren, aber noch keine Domain Controller und SQL-Server. Ausnahmen dokumentieren — jede Exception bekommt einen Owner und ein 12-Monats-Review-Datum.
DCs immer zuletzt. Zweiten DC im Ring halten, der noch die alte Policy hat. Nach Anwendung: Kerberos-Authentifizierung testen, Replikation prüfen, Event Log auf Fehler scannen.
Regelmäßige Analyse-Runs: Hat jemand eine Baseline-Setting per lokalem Admin überschrieben? Wurde eine neue GPO mit falscher Priorität verknüpft? Baseline als lebendigen Prozess verstehen — nicht als einmaligen Deploy.
Die drei neuen NTLM-Audit-Policies — und was ihr damit macht
Die v2602-Baseline aktiviert drei NTLM-Audit-Policies, die als Vorbereitung für die spätere NTLM-Abschaltung dienen. Ihr solltet die generierten Events aktiv auswerten — denn sie zeigen euch, welche Anwendungen und Dienste ihr vor der Enforcement-Phase noch migrieren müsst.
| Policy | GPO-Pfad | Gilt für |
|---|---|---|
| Restrict NTLM: Audit Incoming NTLM Traffic | Security Options → Network Security | MS + DC |
| Restrict NTLM: Audit NTLM authentication in this domain | Security Options → Network Security | DC only |
| Network Security: Restrict NTLM – Outgoing NTLM traffic to remote servers | Security Options → Network Security | MS + DC |
$since = (Get-Date).AddDays(-7)
$events = Get-WinEvent -FilterHashtable @{
LogName = ‘Microsoft-Windows-NTLM/Operational’
StartTime = $since
} -ErrorAction SilentlyContinue
# Top-20 NTLM-Nutzer nach Häufigkeit
$events |
Group-Object { $_.Properties[0].Value } |
Sort-Object Count -Descending |
Select-Object Count, Name -First 20 |
Format-Table -AutoSize
# Export für Migration-Planung
$events |
Select-Object TimeCreated,
@{N=”Quelle”;E={$_.Properties[0].Value}},
@{N=”Ziel”;E={$_.Properties[1].Value}},
@{N=”Benutzer”;E={$_.Properties[2].Value}} |
Export-Csv “NTLM_Audit_$(Get-Date -Format ‘yyyy-MM-dd’).csv” `
-Encoding UTF8 -NoTypeInformation
Write-Host “NTLM-Audit exportiert.” -ForegroundColor Green
Ausnahmen richtig verwalten — und nicht vergessen
Nicht jede Baseline-Setting ist in jeder Umgebung sofort umsetzbar. Das ist normal — aber Ausnahmen müssen strukturiert verwaltet werden. Sonst wächst die “Exception-Liste” zur unsichtbaren Sicherheitslücke.
PROD-Computer-Security-Exception-[Ticket]-[Scope]Beispiel:
PROD-Computer-Security-Exception-T4711-PrintServerJede Exception-GPO erhält:
- Einen Owner — eine namentliche Person, die für die Ausnahme verantwortlich ist
- Ein Review-Datum — maximal 12 Monate, dann wird neu bewertet
- Eine Begründung im GPO-Kommentarfeld — damit Kollegen und Auditoren den Kontext verstehen
- WMI-Filter oder Item-Level-Targeting — damit die Exception nur auf die betroffenen Systeme wirkt, nicht auf die gesamte OU
Rollout-Checkliste: Security Baseline v2602
Fazit: Baseline ist kein Deploy — Baseline ist ein Prozess
Die v2602 ist Microsofts bisher deutlichstes Signal in Richtung NTLM-Abschaltung und Zero-Trust-Härtung. Wer jetzt damit anfängt — NTLM-Audit-Daten sammelt, GPO-Konflikte bereinigt, Ausnahmen strukturiert erfasst — ist in sechs Monaten in einer völlig anderen Position als Umgebungen, die erst dann beginnen, wenn Microsoft den Enforcement-Schalter umlegt.
Der ISW GPO Analyzer Pro ist dabei euer dauerhafter Kontrollpunkt: nicht nur für die Baseline, sondern für die gesamte GPO-Infrastruktur. Denn eine Baseline, die ihr einmal deployed und dann nie wieder prüft, ist in sechs Monaten keine Baseline mehr.
© 2026 IT-Service Walter — isw-adtools.de
Windows-Administration & IT-Sicherheit für Profis | Euskirchen