# Practical usage in a Domain Environment (GPO-driven collection and conversion) > This example demonstrates how to implement a GPO-driven workflow for collecting and converting DNS debug logs on domain controllers. --- LLMS index: [llms.txt](/llms.txt) --- This document outlines a practical, end-to-end example of running DNSServer.DebugLogParser in an Active Directory domain environment, focused on converting Windows DNS Server debug logs on domain controllers. This example is accompanied by a [ZIP archive][gpo-zip], which provide the policy artifacts used to implement the workflow described here. The most relevant artifacts are backup manifest, GPO report, Files.xml, Set-DNSServerDebugLogging.ps1, and ScheduledTasks.xml. ## Scenario - Multiple domain controllers (DCs) host the DNS Server role. - DNS debug logging is enabled and configured consistently on each DC via a scheduled task (writing log files to `C:\Administration\Logs\DNSServer`). - A centrally managed process converts logs into CSV for: - security analytics - operational reporting - troubleshooting - compliance/retention ## Target outcomes - Consistent conversion settings across all DCs - Predictable output location and naming - Optional compression to reduce storage footprint - Optional statistics outputs for quick daily rollups - Minimal host-side risk, with explicit rerun and cleanup considerations ## Suggested architecture ### Collection model: local convert + central pull 1. Each DC writes DNS debug logs to disk with rollover enabled. 2. Each DC converts rotated `*.log` files into a data CSV and statistics CSVs, then compresses the outputs into `*.zip` on a schedule (Task Scheduler). 3. Outputs are written next to the log files so the pipeline stays simple. 4. A central server collects the `*.zip` outputs, for example via file share ingestion, scheduled copy, SIEM forwarder, or an agent-based collector. This model minimizes network reads of large raw log files and keeps parsing close to the data. ## GPO workflow The workflow is implemented through Group Policy (computer configuration) to ensure consistent settings across all domain controllers. Reference implementation included in this repository (GPO report): - Archive/report name: `T0-C-Analytics-DNSDebugLogging` - Backup ID: `{2B6F16BC-0E7C-4787-83D7-2854FED882EE}` - GPO link target: `corp.company.com/Domain Controllers` - Item filter (used for both file deployment and scheduled tasks): only applies if `C:\Windows\System32\dns.exe` exists ### 1) Prerequisites (folders + module) The provided backup assumes these folders already exist. Add separate GPP items if you want the deployment to create them automatically: - `C:\Administration\Scripts` - `C:\Administration\Logs\DNSServer` The provided backup also assumes [Convert-DNSDebugLogFile][convert-dnsdebuglogfile] is already available on the DCs. The conversion task starts Windows PowerShell 5.1 with `-NoProfile` and does not import the module explicitly, so the module must be installed in a machine-wide Windows PowerShell module path that is visible to `LocalSystem`. Recommended approaches: - Install DNSServer.DebugLogParser on the DCs. For example, from PowerShell Gallery (if policy allows). - Deploy the module via internal repo / file share so it is discoverable in `$env:PSModulePath` - Add an explicit `Import-Module` to the task action if you want deterministic loading behavior ### 2) Deploy the debug logging configuration script (GPP Files) The GPO deploys the script: - Source (in SYSVOL via GPP): `%GptPath%\Preferences\Files\Set-DNSServerDebugLogging.ps1` - Target (on each DC): `C:\Administration\Scripts\Set-DNSServerDebugLogging.ps1` This is implemented in the GPP Files preference item in Files.xml. ### 3) Scheduled task: configure DNS debug logging The GPO creates a scheduled task named `Set-DNSServerDebugLogging`. - Security context in the supplied backup: `SYSTEM` with logon type `S4U` - Trigger in the supplied backup: daily (start boundary `2025-03-01T00:00:01`) - Action in ScheduledTasks.xml: - `powershell.exe -ExecutionPolicy RemoteSigned -command " & { C:\Administration\Scripts\Set-DNSServerDebugLogging.ps1 }"` - Working directory: `C:\Administration\Scripts` The linked Set-DNSServerDebugLogging.ps1 script configures DNS debug logging via `Get-DnsServerDiagnostics` / `Set-DnsServerDiagnostics` and (notably): - Enables logging to file + rollover - Writes to: `C:\Administration\Logs\DNSServer\DnsDebugLog_._.log` - Uses a 10 MB rollover size per file - Captures primarily query-related activity (queries + notifications + updates + question transactions) and excludes full packet logging ### 4) Scheduled task: convert rotated debug logs to compressed CSV The GPO creates a scheduled task named `Convert-DNSDebugLogs`. - Security context in the supplied backup: `SYSTEM` with logon type `InteractiveToken` - Trigger in the supplied backup: daily (start boundary `2026-01-01T00:30:00`) - Working directory: `C:\Administration\Logs\DNSServer` - Action in ScheduledTasks.xml (formatted for readability): ```powershell 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 ``` Design notes: - `Select-Object -Skip 1` intentionally avoids processing the newest (active) log file. [Convert-DNSDebugLogFile][convert-dnsdebuglogfile] is able to read a log that DNS Server currently has open, but that file changes while it is being read: the output can miss the newest entries or end with a truncated record, and two runs do not produce identical results. Skipping the active file keeps the scheduled output reproducible. - That means current data is exported only after rollover; on low-volume DCs, the active log may stay unprocessed for more than a day. Lower the rollover size if that delay is too long for your use case. - Because [Convert-DNSDebugLogFile][convert-dnsdebuglogfile] defaults `-OutputFile` to “same folder, same name, `.csv`”, outputs land next to the `*.log` inputs. - With `-CompressOutput`, each processed log produces a `*.zip` and the intermediate CSVs are removed. - Unless you archive or delete processed `*.log` files, later runs will reprocess every non-active log again. - The task throws if `$Error.Count -gt 0` to signal a failed run. ### 5) Central ingestion Options (pick one): - File share ingestion: DC writes (or copies) `C:\Administration\Logs\DNSServer\*.zip` to `\\fileserver\share\dns\$env:COMPUTERNAME\...` (grant share and NTFS rights to the DC computer accounts or the Domain Controllers group if the task runs as `SYSTEM`) - Pull model: central job reads `\\dc\C$\Administration\Logs\DNSServer\*.zip` (least preferred; requires admin shares) - Agent forwarder: SIEM / log pipeline that ships the `*.zip` outputs ## Operational considerations - Least privilege: tasks run as `SYSTEM`; ensure the local folders are writable and that any UNC targets grant access to the computer account if used. - Signing policy: both tasks use `-ExecutionPolicy RemoteSigned`; sign or unblock the deployed script and module according to your policy. - Disk usage: `-CompressOutput` helps significantly, but this workflow does not remove source logs; plan retention and cleanup. - Re-processing behavior: unless you archive or delete processed logs, the conversion task will process every non-active `*.log` file again on later runs. This is simple and robust, but it can overwrite outputs and create duplicate downstream ingestion if your collector does not deduplicate. - Multi-DC consolidation: `-ComputerName $env:COMPUTERNAME` is included so consolidated datasets remain traceable. Note that `-ComputerName` only labels the output — it performs no remote connection. - Network shares: [Convert-DNSDebugLogFile][convert-dnsdebuglogfile] can read source logs from SMB/UNC paths, but converting locally and shipping the compressed results stays the better pattern for large raw logs. If you do use a UNC path, remember that a task running as `SYSTEM` authenticates on the network as the computer account and needs share plus NTFS rights there. - Date format: `-OutputCulture sv-SE` is used deliberately so timestamps are written as `2026-01-20 23:00:16`. That format is read without a hint by SQL Server, Power BI and most import tooling, regardless of the locale of the DC that produced the log. - Validation: header validation remains enabled because the task does not use `-SkipHeaderValidation` (recommended). ## Validate and adapt (using the ZIP) Use the [ZIP archive][gpo-zip] as the reference implementation, then align the following aspects to your environment: - Target scope: which DCs / OUs receive the policy - Execution identity: confirm both scheduled tasks use the intended logon type (`S4U` vs `InteractiveToken`) or normalize them to your standard - Folder creation: decide whether `C:\Administration\Scripts` and `C:\Administration\Logs\DNSServer` are pre-staged elsewhere or should be created by additional GPP items - Paths: confirm `C:\Administration\Scripts` and `C:\Administration\Logs\DNSServer` match your standards - Retention: decide whether to keep raw logs and for how long (especially if enabling cleanup options) - Ingestion: confirm where CSV/ZIP outputs are written and how they are collected centrally If you want to validate the exact GPO configuration without importing it, the authoritative sources in this repo are: - manifest.xml for backup metadata - gpreport.xml for the human-readable full report - Files.xml for file deployment - Set-DNSServerDebugLogging.ps1 for script content - ScheduledTasks.xml for scheduled tasks [convert-dnsdebuglogfile]: ../commands/convert-dnsdebuglogfile/ [gpo-zip]: ../gpo/T0-C-Analytics-DNSDebugLogging.zip