Praktyczne zastosowanie w środowisku domenowym (kolekcja i konwersja sterowana przez GPO)
For AI agents: a documentation index is available at /llms.txt; a markdown version of this page is available at /pl/docs/examples/gpo-driven-collection/index.md.
Ten dokument przedstawia praktyczny, kompleksowy przykład uruchomienia DNSServer.DebugLogParser w środowisku domeny Active Directory, skupiając się na konwersji dzienników debugowania serwera DNS Windows na kontrolerach domeny.
Do tego przykładu dołączony jest archiwum ZIP, które zawiera artefakty polityki używane do wdrożenia opisanego tutaj przepływu pracy.
Najważniejsze artefakty to manifest kopii zapasowej, raport GPO, Files.xml, Set-DNSServerDebugLogging.ps1 oraz ScheduledTasks.xml.
Scenariusz
- Wiele kontrolerów domeny (DC) pełni rolę serwera DNS.
- Debugowanie DNS jest włączone i spójnie skonfigurowane na każdym DC za pomocą zadania zaplanowanego (zapisujące pliki dziennika do
C:\Administration\Logs\DNSServer). - Centralnie zarządzany proces konwertuje dzienniki do formatu CSV dla:
- analityki bezpieczeństwa
- raportowania operacyjnego
- rozwiązywania problemów
- zgodności/przechowywania danych
Cele
- Spójne ustawienia konwersji na wszystkich DC
- Przewidywalna lokalizacja i nazewnictwo plików wyjściowych
- Opcjonalna kompresja w celu zmniejszenia zajętości miejsca
- Opcjonalne statystyki dla szybkich podsumowań dziennych
- Minimalne ryzyko po stronie hosta, z wyraźnym uwzględnieniem ponownego uruchomienia i czyszczenia
Sugerowana architektura
Model zbierania: lokalna konwersja + centralne pobieranie
- Każdy DC zapisuje dzienniki debugowania DNS na dysku z włączonym przełączaniem plików.
- Każdy DC konwertuje obrócone pliki
*.logna dane CSV i statystyki CSV, a następnie kompresuje wyniki do*.zipwedług harmonogramu (Harmonogram zadań). - Wyniki zapisywane są obok plików dziennika, aby uprościć przepływ.
- Centralny serwer zbiera pliki
*.zip, np. przez udostępnianie plików, zaplanowane kopiowanie, przekazywanie do SIEM lub kolektor oparty na agencie.
Ten model minimalizuje odczyty sieciowe dużych surowych plików dziennika i utrzymuje analizę blisko danych.
Przepływ pracy GPO
Przepływ pracy jest realizowany przez zasady grupy (konfiguracja komputera), aby zapewnić spójne ustawienia na wszystkich kontrolerach domeny.
Referencyjna implementacja zawarta w tym repozytorium (raport GPO):
- Nazwa archiwum/raportu:
T0-C-Analytics-DNSDebugLogging - ID kopii zapasowej:
{2B6F16BC-0E7C-4787-83D7-2854FED882EE} - Cel linku GPO:
corp.company.com/Domain Controllers - Filtr elementów (używany zarówno do wdrażania plików, jak i zadań zaplanowanych): stosuje się tylko, jeśli istnieje
C:\Windows\System32\dns.exe
1) Wymagania wstępne (foldery + moduł)
Dostarczona kopia zapasowa zakłada, że te foldery już istnieją. Dodaj osobne elementy GPP, jeśli chcesz, aby wdrożenie tworzyło je automatycznie:
C:\Administration\ScriptsC:\Administration\Logs\DNSServer
Dostarczona kopia zakłada również, że Convert-DNSDebugLogFile jest już dostępny na DC. Zadanie konwersji uruchamia Windows PowerShell 5.1 z -NoProfile i nie importuje modułu jawnie, więc moduł musi być zainstalowany w ścieżce modułów Windows PowerShell widocznej dla LocalSystem. Zalecane podejścia:
- Zainstaluj DNSServer.DebugLogParser na DC, np. z PowerShell Gallery (jeśli polityka na to pozwala).
- Wdróż moduł przez wewnętrzne repozytorium / udział plików, aby był wykrywalny w
$env:PSModulePath - Dodaj jawny
Import-Moduledo akcji zadania, jeśli chcesz mieć deterministyczne ładowanie
2) Wdróż skrypt konfigurujący debugowanie DNS (GPP Files)
GPO wdraża skrypt:
- Źródło (w SYSVOL przez GPP):
%GptPath%\Preferences\Files\Set-DNSServerDebugLogging.ps1 - Cel (na każdym DC):
C:\Administration\Scripts\Set-DNSServerDebugLogging.ps1
Jest to zaimplementowane w elemencie preferencji GPP Files w Files.xml.
3) Zadanie zaplanowane: konfiguracja debugowania DNS
GPO tworzy zadanie zaplanowane o nazwie Set-DNSServerDebugLogging.
- Kontekst bezpieczeństwa w dostarczonej kopii:
SYSTEMz typem logowaniaS4U - Wyzwalacz w dostarczonej kopii: codziennie (start
2025-03-01T00:00:01) - Akcja w ScheduledTasks.xml:
powershell.exe -ExecutionPolicy RemoteSigned -command " & { C:\Administration\Scripts\Set-DNSServerDebugLogging.ps1 }"- Katalog roboczy:
C:\Administration\Scripts
Powiązany skrypt Set-DNSServerDebugLogging.ps1 konfiguruje debugowanie DNS za pomocą Get-DnsServerDiagnostics / Set-DnsServerDiagnostics i (co ważne):
- Włącza logowanie do pliku + przełączanie plików
- Zapisuje do:
C:\Administration\Logs\DNSServer\DnsDebugLog_<COMPUTERNAME>.<Domain>_.log - Ustawia rozmiar przełączania na 10 MB na plik
- Rejestruje głównie aktywność związaną z zapytaniami (zapytania + powiadomienia + aktualizacje + transakcje zapytań) i wyklucza pełne logowanie pakietów
4) Zadanie zaplanowane: konwersja obróconych dzienników debugowania do skompresowanego CSV
GPO tworzy zadanie zaplanowane o nazwie Convert-DNSDebugLogs.
- Kontekst bezpieczeństwa w dostarczonej kopii:
SYSTEMz typem logowaniaInteractiveToken - Wyzwalacz w dostarczonej kopii: codziennie (start
2026-01-01T00:30:00) - Katalog roboczy:
C:\Administration\Logs\DNSServer - Akcja w ScheduledTasks.xml (formatowana dla czytelności):
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
Uwagi projektowe:
Select-Object -Skip 1celowo pomija najnowszy (aktywny) plik dziennika. Convert-DNSDebugLogFile potrafi czytać dziennik, który DNS Server aktualnie otworzył, ale ten plik zmienia się podczas czytania: wynik może pominąć najnowsze wpisy lub zakończyć się obciętym rekordem, a dwa uruchomienia nie dają identycznych rezultatów. Pomijanie aktywnego pliku zapewnia powtarzalność wyników zaplanowanego zadania.- Oznacza to, że bieżące dane są eksportowane dopiero po przełączeniu; na DC o niskim natężeniu ruchu aktywny dziennik może pozostać nieprzetworzony przez ponad dzień. Zmniejsz rozmiar przełączania, jeśli to opóźnienie jest zbyt długie dla Twojego zastosowania.
- Ponieważ Convert-DNSDebugLogFile domyślnie ustawia
-OutputFilena „ten sam folder, ta sama nazwa,.csv”, wyniki trafiają obok plików*.log. - Z
-CompressOutputkażdy przetworzony dziennik generuje*.zip, a pośrednie pliki CSV są usuwane. - Jeśli nie archiwizujesz ani nie usuwasz przetworzonych plików
*.log, kolejne uruchomienia ponownie przetworzą każdy nieaktywny dziennik. - Zadanie zgłasza błąd, jeśli
$Error.Count -gt 0, aby sygnalizować niepowodzenie.
5) Centralne pobieranie
Opcje (wybierz jedną):
- Pobieranie przez udział plików: DC zapisuje (lub kopiuje)
C:\Administration\Logs\DNSServer\*.zipdo\\fileserver\share\dns\$env:COMPUTERNAME\...(przyznaj prawa do udziału i NTFS kontom komputerów DC lub grupie Domain Controllers, jeśli zadanie działa jakoSYSTEM) - Model pull: centralne zadanie czyta
\\dc\C$\Administration\Logs\DNSServer\*.zip(najmniej preferowane; wymaga udziałów administracyjnych) - Agent forwarder: SIEM / pipeline logów przesyłający pliki
*.zip
Uwagi operacyjne
- Najmniejsze uprawnienia: zadania działają jako
SYSTEM; upewnij się, że lokalne foldery są zapisywalne i że ewentualne cele UNC przyznają dostęp kontu komputera, jeśli są używane. - Polityka podpisywania: oba zadania używają
-ExecutionPolicy RemoteSigned; podpisz lub odblokuj wdrożony skrypt i moduł zgodnie z polityką. - Wykorzystanie dysku:
-CompressOutputznacząco pomaga, ale ten przepływ nie usuwa źródłowych dzienników; zaplanuj retencję i czyszczenie. - Zachowanie przy ponownym przetwarzaniu: jeśli nie archiwizujesz ani nie usuwasz przetworzonych dzienników, zadanie konwersji będzie ponownie przetwarzać każdy nieaktywny plik
*.logprzy kolejnych uruchomieniach. To proste i niezawodne, ale może nadpisać wyniki i tworzyć duplikaty w dalszym przetwarzaniu, jeśli kolektor nie deduplikuje. - Konsolidacja wielu DC:
-ComputerName $env:COMPUTERNAMEjest dołączone, aby zbiory danych pozostały śledzone. Uwaga:-ComputerNametylko oznacza wynik — nie wykonuje połączenia zdalnego. - Udziały sieciowe: Convert-DNSDebugLogFile potrafi czytać źródłowe dzienniki z ścieżek SMB/UNC, ale lokalna konwersja i przesyłanie skompresowanych wyników pozostaje lepszym wzorcem dla dużych surowych dzienników. Jeśli używasz ścieżki UNC, pamiętaj, że zadanie działające jako
SYSTEMuwierzytelnia się w sieci jako konto komputera i potrzebuje praw do udziału i NTFS. - Format daty:
-OutputCulture sv-SEjest używany celowo, aby znaczniki czasu zapisywały się jako2026-01-20 23:00:16. Ten format jest odczytywany bez wskazówek przez SQL Server, Power BI i większość narzędzi importu, niezależnie od lokalizacji DC, który wygenerował dziennik. - Walidacja: walidacja nagłówka pozostaje włączona, ponieważ zadanie nie używa
-SkipHeaderValidation(zalecane).
Walidacja i dostosowanie (z użyciem ZIP)
Użyj archiwum ZIP jako implementacji referencyjnej, a następnie dostosuj następujące aspekty do swojego środowiska:
- Zakres docelowy: które DC / OU otrzymują politykę
- Tożsamość wykonania: potwierdź, że oba zadania zaplanowane używają zamierzonego typu logowania (
S4UvsInteractiveToken) lub ujednolić je do standardu - Tworzenie folderów: zdecyduj, czy
C:\Administration\ScriptsiC:\Administration\Logs\DNSServersą przygotowane gdzie indziej, czy mają być tworzone przez dodatkowe elementy GPP - Ścieżki: potwierdź, że
C:\Administration\ScriptsiC:\Administration\Logs\DNSServerodpowiadają Twoim standardom - Retencja: zdecyduj, czy zachować surowe dzienniki i na jak długo (szczególnie jeśli włączasz opcje czyszczenia)
- Pobieranie: potwierdź, gdzie zapisywane są wyniki CSV/ZIP i jak są centralnie zbierane
Jeśli chcesz zweryfikować dokładną konfigurację GPO bez importowania, autorytatywne źródła w tym repozytorium to:
- manifest.xml dla metadanych kopii zapasowej
- gpreport.xml dla czytelnego raportu
- Files.xml dla wdrożenia plików
- Set-DNSServerDebugLogging.ps1 dla zawartości skryptu
- ScheduledTasks.xml dla zadań zaplanowanych