Version 1.2.1.0 of the documentation is no longer actively maintained. The site that you are currently viewing is an archived snapshot.

Praktische Anwendung in einer Domänenumgebung (GPO-gesteuerte Sammlung und Konvertierung)

Dieses Beispiel zeigt, wie ein GPO-gesteuerter Workflow zur Sammlung und Konvertierung von DNS-Debug-Protokollen auf Domänencontrollern implementiert wird.

For AI agents: a documentation index is available at /llms.txt; a markdown version of this page is available at /v1.2.1.0/de/docs/examples/gpo-driven-collection/index.md.

Dieses Dokument beschreibt ein praktisches, durchgängiges Beispiel für den Einsatz von DNSServer.DebugLogParser in einer Active Directory-Domänenumgebung, mit Fokus auf die Konvertierung von Windows DNS-Server-Debug-Protokollen auf Domänencontrollern.

Dieses Beispiel wird von einem ZIP-Archiv begleitet, das die Richtlinien-Artefakte enthält, die zur Umsetzung des hier beschriebenen Workflows verwendet werden.
Die wichtigsten Artefakte sind das Backup-Manifest, der GPO-Bericht, Files.xml, Set-DNSServerDebugLogging.ps1 und ScheduledTasks.xml.

Szenario

  • Mehrere Domänencontroller (DCs) hosten die DNS-Serverrolle.
  • DNS-Debug-Protokollierung ist aktiviert und wird auf jedem DC über eine geplante Aufgabe einheitlich konfiguriert (Schreiben der Protokolldateien nach C:\Administration\Logs\DNSServer).
  • Ein zentral verwalteter Prozess konvertiert die Protokolle in CSV für:
    • Sicherheitsanalysen
    • Betriebsberichte
    • Fehlerbehebung
    • Compliance/Aufbewahrung

Zielsetzungen

  • Einheitliche Konvertierungseinstellungen auf allen DCs
  • Vorhersehbarer Speicherort und Namensgebung der Ausgaben
  • Optionale Komprimierung zur Reduzierung des Speicherplatzbedarfs
  • Optionale Statistik-Ausgaben für schnelle tägliche Zusammenfassungen
  • Minimales Risiko auf dem Host mit expliziten Wiederholungs- und Bereinigungsmaßnahmen

Vorgeschlagene Architektur

Sammelmodell: lokale Konvertierung + zentrale Abholung

  1. Jeder DC schreibt DNS-Debug-Protokolle mit aktivierter Roll-over-Funktion auf die Festplatte.
  2. Jeder DC konvertiert die rotierten *.log-Dateien in eine Daten-CSV und Statistik-CSVs und komprimiert die Ausgaben dann zeitgesteuert (Task Scheduler) in *.zip.
  3. Die Ausgaben werden neben den Protokolldateien abgelegt, damit die Pipeline einfach bleibt.
  4. Ein zentraler Server sammelt die *.zip-Ausgaben, z. B. über Dateifreigabe, geplante Kopie, SIEM-Forwarder oder einen agentenbasierten Collector.

Dieses Modell minimiert Netzwerkzugriffe auf große Rohprotokolle und hält die Verarbeitung nahe an den Daten.

GPO-Workflow

Der Workflow wird über Gruppenrichtlinien (Computerkonfiguration) implementiert, um konsistente Einstellungen auf allen Domänencontrollern sicherzustellen.

Referenzimplementierung in diesem Repository enthalten (GPO-Bericht):

  • Archiv-/Berichtsname: T0-C-Analytics-DNSDebugLogging
  • Backup-ID: {2B6F16BC-0E7C-4787-83D7-2854FED882EE}
  • GPO-Ziel: corp.company.com/Domain Controllers
  • Filter für Elemente (für Datei-Bereitstellung und geplante Aufgaben): gilt nur, wenn C:\Windows\System32\dns.exe vorhanden ist

1) Voraussetzungen (Ordner + Modul)

Das bereitgestellte Backup setzt voraus, dass diese Ordner bereits existieren. Füge separate GPP-Elemente hinzu, wenn die Bereitstellung sie automatisch erstellen soll:

  • C:\Administration\Scripts
  • C:\Administration\Logs\DNSServer

Das Backup setzt außerdem voraus, dass Convert-DNSDebugLogFile bereits auf den DCs verfügbar ist. Die Konvertierungsaufgabe startet Windows PowerShell 5.1 mit -NoProfile und importiert das Modul nicht explizit, daher muss das Modul in einem maschinenweiten Windows PowerShell-Modulpfad installiert sein, der für LocalSystem sichtbar ist. Empfohlene Vorgehensweisen:

  • Installiere DNSServer.DebugLogParser auf den DCs, z. B. aus der PowerShell Gallery (wenn Richtlinie dies erlaubt).
  • Stelle das Modul über ein internes Repository / Dateifreigabe bereit, sodass es in $env:PSModulePath auffindbar ist.
  • Füge der Aufgabenaktion ein explizites Import-Module hinzu, wenn du ein deterministisches Ladeverhalten möchtest.

2) Bereitstellung des Debug-Logging-Konfigurationsskripts (GPP Dateien)

Die GPO stellt das Skript bereit:

  • Quelle (im SYSVOL via GPP): %GptPath%\Preferences\Files\Set-DNSServerDebugLogging.ps1
  • Ziel (auf jedem DC): C:\Administration\Scripts\Set-DNSServerDebugLogging.ps1

Dies ist im GPP-Dateielement in Files.xml implementiert.

3) Geplante Aufgabe: DNS-Debug-Logging konfigurieren

Die GPO erstellt eine geplante Aufgabe namens Set-DNSServerDebugLogging.

  • Sicherheitskontext im bereitgestellten Backup: SYSTEM mit Anmeldetyp S4U
  • Trigger im Backup: täglich (Startzeitpunkt 2025-03-01T00:00:01)
  • Aktion in ScheduledTasks.xml:
    • powershell.exe -ExecutionPolicy RemoteSigned -command " & { C:\Administration\Scripts\Set-DNSServerDebugLogging.ps1 }"
    • Arbeitsverzeichnis: C:\Administration\Scripts

Das verlinkte Set-DNSServerDebugLogging.ps1-Skript konfiguriert DNS-Debug-Logging über Get-DnsServerDiagnostics / Set-DnsServerDiagnostics und insbesondere:

  • Aktiviert Protokollierung in Datei + Roll-over
  • Schreibt nach: C:\Administration\Logs\DNSServer\DnsDebugLog_<COMPUTERNAME>.<Domain>_.log
  • Verwendet eine Roll-over-Größe von 10 MB pro Datei
  • Erfasst hauptsächlich abfragebezogene Aktivitäten (Abfragen + Benachrichtigungen + Updates + Frage-Transaktionen) und schließt vollständige Paketprotokollierung aus

4) Geplante Aufgabe: konvertiere rotierte Debug-Protokolle in komprimierte CSV

Die GPO erstellt eine geplante Aufgabe namens Convert-DNSDebugLogs.

  • Sicherheitskontext im Backup: SYSTEM mit Anmeldetyp InteractiveToken
  • Trigger im Backup: täglich (Startzeitpunkt 2026-01-01T00:30:00)
  • Arbeitsverzeichnis: C:\Administration\Logs\DNSServer
  • Aktion in ScheduledTasks.xml (zur besseren Lesbarkeit formatiert):
Get-ChildItem .\*.log |
  Sort-Object lastwritetime, Name -Descending |
  Select-Object -Skip 1 |
  Convert-DNSDebugLogFile `
    -ComputerName $env:COMPUTERNAME `
    -Delimiter ';' `
    -OutputType Both `
    -ContextFilter Packet `
    -OutputCulture sv-SE `
    -CompressOutput

Designhinweise:

  • Select-Object -Skip 1 vermeidet absichtlich die Verarbeitung der neuesten (aktiven) Protokolldatei.
  • Das bedeutet, aktuelle Daten werden erst nach dem Roll-over exportiert; bei DCs mit geringem Volumen kann die aktive Protokolldatei mehr als einen Tag unberührt bleiben.
  • Da Convert-DNSDebugLogFile standardmäßig -OutputFile auf „gleicher Ordner, gleicher Name, .csv“ setzt, landen die Ausgaben neben den *.log-Eingaben.
  • Mit -CompressOutput erzeugt jede verarbeitete Protokolldatei eine *.zip und die Zwischen-CSV-Dateien werden entfernt.
  • Sofern du verarbeitete *.log-Dateien nicht archivierst oder löschst, werden spätere Läufe jede nicht-aktive Protokolldatei erneut verarbeiten.
  • Die Aufgabe wirft einen Fehler, wenn $Error.Count -gt 0 ist, um einen fehlgeschlagenen Lauf zu signalisieren.

5) Zentrale Aufnahme

Optionen (eine auswählen):

  • Dateifreigabe-Aufnahme: DC schreibt (oder kopiert) C:\Administration\Logs\DNSServer\*.zip nach \\fileserver\share\dns\$env:COMPUTERNAME\... (gewähre Freigabe- und NTFS-Rechte für die DC-Computer-Konten oder die Gruppe Domänencontroller, falls die Aufgabe als SYSTEM läuft)
  • Pull-Modell: zentraler Job liest \\dc\C$\Administration\Logs\DNSServer\*.zip (am wenigsten bevorzugt; erfordert Admin-Freigaben)
  • Agent-Forwarder: SIEM / Log-Pipeline, die die *.zip-Ausgaben versendet

Betriebliche Überlegungen

  • Least Privilege: Aufgaben laufen als SYSTEM; stelle sicher, dass die lokalen Ordner beschreibbar sind und dass eventuelle UNC-Ziele Zugriff für das Computerkonto gewähren, falls verwendet.
  • Signierungsrichtlinie: Beide Aufgaben verwenden -ExecutionPolicy RemoteSigned; signiere oder hebe die Blockierung für das bereitgestellte Skript und Modul gemäß deiner Richtlinie auf.
  • Speicherplatz: -CompressOutput hilft erheblich, aber dieser Workflow entfernt die Quellprotokolle nicht; plane Aufbewahrung und Bereinigung.
  • Wiederverarbeitungsverhalten: Sofern du verarbeitete Protokolle nicht archivierst oder löschst, verarbeitet die Konvertierungsaufgabe bei späteren Läufen jede nicht-aktive *.log-Datei erneut. Das ist einfach und robust, kann aber Ausgaben überschreiben und doppelte nachgelagerte Aufnahmen erzeugen, wenn dein Collector nicht dedupliziert.
  • Multi-DC-Konsolidierung: -ComputerName $env:COMPUTERNAME ist enthalten, damit konsolidierte Datensätze nachvollziehbar bleiben.
  • Validierung: Header-Validierung bleibt aktiviert, da die Aufgabe -SkipHeaderValidation nicht verwendet (empfohlen).

Validieren und anpassen (mit dem ZIP)

Nutze das ZIP-Archiv als Referenzimplementierung und passe dann folgende Aspekte an deine Umgebung an:

  • Zielumfang: welche DCs / OUs die Richtlinie erhalten
  • Ausführungsidentität: bestätige, dass beide geplanten Aufgaben den vorgesehenen Anmeldetyp verwenden (S4U vs. InteractiveToken) oder normalisiere sie auf deinen Standard
  • Ordnererstellung: entscheide, ob C:\Administration\Scripts und C:\Administration\Logs\DNSServer woanders vorab bereitgestellt oder durch zusätzliche GPP-Elemente erstellt werden sollen
  • Pfade: bestätige, dass C:\Administration\Scripts und C:\Administration\Logs\DNSServer deinen Standards entsprechen
  • Aufbewahrung: entscheide, ob Rohprotokolle behalten werden und wie lange (besonders bei Aktivierung von Bereinigungsoptionen)
  • Aufnahme: bestätige, wo CSV/ZIP-Ausgaben geschrieben werden und wie sie zentral gesammelt werden

Wenn du die genaue GPO-Konfiguration ohne Import validieren möchtest, sind die maßgeblichen Quellen in diesem Repo: