Operative Best Practices

Was du beachten solltest, bevor du eine DNS-Protokollkonvertierung unbeaufsichtigt auf produktiven Domänencontrollern laufen lässt.

For AI agents: a documentation index is available at /llms.txt; a markdown version of this page is available at /de/docs/06-operational-best-practices/index.md.

Ein Protokoll manuell zu konvertieren ist einfach. Es jede Nacht auf jedem Domänencontroller über Jahre hinweg laufen zu lassen, ohne dass jemand hinschaut, erfordert etwas Planung. Das sind die Punkte, die in der Praxis wichtig sind.

1. Konvertiere rotierte Protokolle, nicht das aktive

Aktiviere die Protokollrotation auf dem DNS-Server und konvertiere nur geschlossene Dateien. Das Modul kann das Protokoll lesen, in das der DNS-Server gerade schreibt, aber diese Datei ändert sich während der Konvertierung: die neuesten Einträge können fehlen und der letzte Eintrag kann abgeschnitten sein. Zwei Durchläufe liefern zwei unterschiedliche Ergebnisse.

Das Standardmuster überspringt die neueste Datei:

Get-ChildItem "C:\Administration\Logs\DNSServer\*.log" |
    Sort-Object LastWriteTime -Descending |
    Select-Object -Skip 1 |
    Convert-DNSDebugLogFile -ComputerName $env:COMPUTERNAME

Ein Kompromiss, den du kennen solltest: Bei einem Server mit geringem Datenaufkommen kann die Rotation länger als einen Tag dauern, sodass die Daten des aktuellen Tages erst nach der Rotation konvertiert werden. Passe die Rotationsgröße entsprechend an.

2. Plane es ein und gib dem Job eine passende Identität

Der Task Scheduler ist der übliche Ort dafür — täglich ist ein sinnvoller Standard. Eine vollständige Gruppenrichtlinien-Implementierung für Domänencontroller ist im GPO-gesteuerten Sammelbeispiel dokumentiert, und eine eigenständige Aufgabe im Scheduled Task Beispiel.

Drei Dinge bereiten hier oft Probleme:

  • Modulauffindbarkeit. Ein Task, der als SYSTEM mit -NoProfile läuft, sieht nur maschinenweite Modulpfade. Installiere das Modul maschinenweit oder füge einen expliziten Import-Module in die Task-Aktion ein.
  • Kultur. Das Konto, das den Task ausführt, hat möglicherweise nicht die gleiche Gebietsschema-Einstellung wie du beim interaktiven Test. Setze -InputCulture und -OutputCulture explizit, statt dich auf den Standard zu verlassen.
  • Netzwerkzugriff. Wenn Quelle oder Ziel ein UNC-Pfad sind, authentifiziert sich SYSTEM als Computerkonto. Erteile dem Computerkonto (oder der Gruppe Domain Controllers) Freigabe- und NTFS-Rechte oder führe den Task als dediziertes Dienstkonto aus.

3. Rotieren bei einer Größe, die du verarbeiten kannst

50–200 MB pro Datei halten die Konvertierung vorhersehbar und lassen einen nächtlichen Job innerhalb seines Zeitfensters abschließen. Eine Datei, die ewig wächst, tut das irgendwann nicht mehr. Siehe Performance.

4. Validier die ersten Ausgaben, bevor du automatisierst

Führe die Konvertierung manuell auf zwei oder drei echten Protokollen aus und öffne die CSV tatsächlich:

  • Sind die Zeitstempel korrekt — nicht Tag/Monat vertauscht? (Falls doch, setze -InputCulture.)
  • Passt das Trennzeichen zu dem, was dein Verbraucher erwartet?
  • Ist ComputerName ausgefüllt?
  • Sind die benötigten Kontexte vorhanden und die unnötigen herausgefiltert?

-WhatIf zeigt dir, welche Dateien ein Batch berühren würde, bevor es sie berührt:

Get-ChildItem "C:\Administration\Logs\DNSServer\*.log" |
    Convert-DNSDebugLogFile -RemoveSourceFile -WhatIf

5. Entscheide, was mit verarbeiteten Protokollen passiert

Ein Job, der einfach „jede Datei außer der neuesten“ konvertiert, verarbeitet dieselben Dateien jede Nacht erneut. Das ist robust und einfach, überschreibt aber Ausgaben und kann doppelte Zeilen in die nachgelagerte Verarbeitung bringen.

Wähle eine Option:

  • verschiebe verarbeitete .log-Dateien in einen Archivordner
  • lösche sie mit -RemoveSourceFile, sobald du der Pipeline vertraust
  • lasse den nachgelagerten Collector Duplikate entfernen

Was auch immer du wählst, schreib es auf — das ist die Kleinigkeit, die den nächsten Administrator verwirrt.

6. Plane Speicher und Aufbewahrung

Komprimierung (-CompressOutput) reduziert die CSV meist um 90 % oder mehr, aber das Volumen wächst trotzdem. Schätze anhand deiner tatsächlichen Abfragerate und deiner Aufbewahrungspflicht und setze ein Enddatum für die Daten, anstatt sie unbegrenzt wachsen zu lassen.

-OutputType Statistic ist für lange Aufbewahrung einen Blick wert: tägliche Rollups sind winzig und beantworten oft die Trendfragen, für die alte Zeilen-Daten aufbewahrt wurden.

7. Behandle die Ausgabe als sensibel

Geparste DNS-Protokolle beschreiben deine interne Namensstruktur und wer was abgefragt hat. Das ist aufschlussreicher als die meisten Infrastrukturprotokolle und kann je nach Rechtslage als personenbezogene Daten gelten.

  • Beschränke NTFS- und Freigabeberechtigungen auf die Ausgabeordner.
  • Lege CSVs nicht „temporär“ auf einem allgemeinen Dateifreigabeordner ab.
  • Beziehe DNS-Protokolldaten in deine Aufbewahrungs- und Löschrichtlinie ein, nicht nur in deine Backup-Policy.
  • Komprimierte Ausgaben sind kleiner, aber nicht geschützt — nutze Verschlüsselung oder Zugriffskontrolle, wo es wichtig ist.

8. Lass die Header-Validierung an

Die Standardprüfung, ob eine Datei wirklich ein DNS-Debug-Protokoll ist, kostet nichts und verhindert, dass ein falsch eingegebener Pfad Tausende Unsinn-Zeilen erzeugt. Verwende -SkipHeaderValidation nur für wirklich ungewöhnliche Formate — und beachte, dass der Befehl genau aus diesem Grund die Kombination mit -RemoveSourceFile verweigert.

9. Überwache den Job, nicht nur den Server

Eine unbeaufsichtigte Konvertierung, die stillschweigend stoppt, ist schlimmer als keine Konvertierung, weil die Lücke erst bemerkt wird, wenn jemand die Daten braucht.

  • Achte auf Fehlerausgaben ungleich Null; die GPO-Referenzimplementierung wirft absichtlich einen Fehler, wenn $Error.Count -gt 0 ist, damit der Task einen Fehler meldet.
  • Alarmiere anhand des letzten Ergebniscodes des geplanten Tasks, nicht nur danach, ob der Task existiert.
  • Prüfe, ob Ausgabedateien tatsächlich mit aktuellen Zeitstempeln erscheinen.
  • Überwache freien Speicherplatz sowohl auf dem Protokolllaufwerk als auch am Ausgabeziel.

Häufige Ursachen für einen fehlgeschlagenen Lauf — Zugriff verweigert, beschädigte Protokolle, ungültige Header — sind in Troubleshooting behandelt.

10. Dokumentiere den Ablauf

Wo Protokolle geschrieben werden, wann der Job läuft, welche Parameter verwendet werden, wohin die Ausgabe geht, wer sie konsumiert und wie lange sie aufbewahrt wird. Sechs Zeilen in deinem Operations-Wiki. Das macht die Einrichtung auditierbar und übergabefähig.