# Operational Best Practices > What to get right before you let a DNS log conversion run unattended on production domain controllers. --- LLMS index: [llms.txt](/llms.txt) --- Converting a log by hand is easy. Running it every night on every domain controller, for years, without anyone looking at it, is the part that needs a bit of design. These are the points that matter in practice. ## 1. Convert rotated logs, not the active one Enable log rollover on the DNS server and convert only closed files. The module *can* read the log DNS Server is currently writing to, but that file changes underneath the conversion: the newest entries may be missing and the last record may be truncated. Two runs produce two different results. The standard pattern skips the newest file: ```powershell Get-ChildItem "C:\Administration\Logs\DNSServer\*.log" | Sort-Object LastWriteTime -Descending | Select-Object -Skip 1 | Convert-DNSDebugLogFile -ComputerName $env:COMPUTERNAME ``` Trade-off to be aware of: on a low-volume server, rollover may take longer than a day, so the current day's data stays unconverted until the file rolls. Size the rollover threshold accordingly. ## 2. Schedule it, and give the job an identity that works Task Scheduler is the usual home for this — daily is a sensible default. A full Group Policy implementation for domain controllers is documented in the [GPO-driven collection example](../examples/gpo-driven-collection/), and a standalone task in the [Scheduled Task example](../examples/scheduletask/). Three things bite people here: - **Module discoverability.** A task running as `SYSTEM` with `-NoProfile` only sees machine-wide module paths. Install the module machine-wide, or add an explicit `Import-Module` to the task action. - **Culture.** The account running the task may not have the locale you tested with interactively. Set `-InputCulture` and `-OutputCulture` explicitly instead of relying on the default. - **Network access.** If the source or the target is a UNC path, `SYSTEM` authenticates as the computer account. Grant share and NTFS rights to the computer account (or the `Domain Controllers` group), or run the task as a dedicated service account. ## 3. Rotate at a size you can process 50–200 MB per file keeps conversions predictable and lets a nightly job finish inside its window. One file that grows forever eventually does not. See [Performance](../04-performance/). ## 4. Validate the first outputs before you automate Run the conversion manually on two or three real logs and actually open the CSV: - Are the timestamps correct — not day/month swapped? (If they are, set `-InputCulture`.) - Does the delimiter match what your consumer expects? - Is `ComputerName` populated? - Are the contexts you need present, and the ones you do not need filtered out? `-WhatIf` shows you which files a batch would touch before it touches them: ```powershell Get-ChildItem "C:\Administration\Logs\DNSServer\*.log" | Convert-DNSDebugLogFile -RemoveSourceFile -WhatIf ``` ## 5. Decide what happens to processed logs A job that simply converts "every log except the newest" will reprocess the same files every night. That is robust and simple, but it overwrites outputs and can push duplicate rows into whatever ingests them. Pick one: - move processed `.log` files to an archive folder - delete them with `-RemoveSourceFile` once you trust the pipeline - make the downstream collector deduplicate Whichever you choose, write it down — this is the detail that confuses the next administrator. ## 6. Plan storage and retention Compression (`-CompressOutput`) usually reduces the CSV by 90 % or more, but volume still accumulates. Estimate from your actual query rate and your retention obligation, and set an end date for the data instead of letting it grow indefinitely. `-OutputType Statistic` is worth considering for long retention: daily rollups are tiny and often answer the trend questions that old row-level data was being kept for. ## 7. Treat the output as sensitive Parsed DNS logs describe your internal name structure and who looked up what. That is more revealing than most infrastructure logs, and depending on your jurisdiction it may count as personal data. - Restrict NTFS and share permissions on the output folders. - Do not drop CSVs on a general-purpose file share "temporarily". - Include DNS log data in your retention and deletion policy, not just your backup policy. - Compressed output is smaller, not protected — use encryption or access control where it matters. ## 8. Keep header validation on The default check that a file really is a DNS debug log costs nothing and prevents a mistyped path from producing thousands of nonsense rows. Use `-SkipHeaderValidation` only for genuinely unusual formats — and note that the command refuses to combine it with `-RemoveSourceFile` for exactly this reason. ## 9. Monitor the job, not just the server An unattended conversion that quietly stops is worse than no conversion, because the gap is only noticed when someone needs the data. - Watch for non-zero error output; the GPO reference implementation deliberately throws when `$Error.Count -gt 0` so the task reports failure. - Alert on the scheduled task's last result code, not just on whether the task exists. - Check that output files are actually appearing with recent timestamps. - Watch free disk space on both the log volume and the output target. Common causes of a failed run — access denied, corrupt logs, invalid headers — are covered in [Troubleshooting](../08-troubleshooting/). ## 10. Document the workflow Where logs are written, when the job runs, which parameters are used, where output goes, who consumes it, and how long it is kept. Six lines in your operations wiki. It is what makes the setup auditable and hand-overable.