# Pratiche Operative Consigliate > Cosa fare bene prima di lasciare che una conversione di log DNS venga eseguita in modo automatico sui controller di dominio di produzione. --- LLMS index: [llms.txt](/llms.txt) --- Convertire un log manualmente è facile. Farlo ogni notte su ogni controller di dominio, per anni, senza che nessuno lo controlli, è la parte che richiede un po’ di progettazione. Questi sono i punti che contano nella pratica. ## 1. Converti i log ruotati, non quello attivo Abilita il rollover dei log sul server DNS e converti solo i file chiusi. Il modulo *può* leggere il log su cui il DNS Server sta attualmente scrivendo, ma quel file cambia durante la conversione: le voci più recenti potrebbero mancare e l’ultima riga potrebbe essere troncata. Due esecuzioni producono due risultati diversi. Lo schema standard salta il file più recente: ```powershell Get-ChildItem "C:\Administration\Logs\DNSServer\*.log" | Sort-Object LastWriteTime -Descending | Select-Object -Skip 1 | Convert-DNSDebugLogFile -ComputerName $env:COMPUTERNAME ``` Un compromesso da tenere a mente: su un server a basso volume, il rollover può richiedere più di un giorno, quindi i dati del giorno corrente restano non convertiti finché il file non ruota. Dimensiona la soglia di rollover di conseguenza. ## 2. Pianificalo e assegna al job un’identità che funzioni Task Scheduler è la soluzione abituale — una frequenza giornaliera è un buon default. Un’implementazione completa tramite Group Policy per i controller di dominio è documentata nell’[esempio di raccolta guidata da GPO](../examples/gpo-driven-collection/), e un task standalone nell’[esempio di Scheduled Task](../examples/scheduletask/). Tre cose creano problemi qui: - **Rilevamento del modulo.** Un task che gira come `SYSTEM` con `-NoProfile` vede solo i percorsi dei moduli a livello macchina. Installa il modulo a livello macchina o aggiungi un `Import-Module` esplicito all’azione del task. - **Localizzazione.** L’account che esegue il task potrebbe non avere la stessa localizzazione con cui hai testato interattivamente. Imposta esplicitamente `-InputCulture` e `-OutputCulture` invece di affidarti al default. - **Accesso di rete.** Se la sorgente o la destinazione è un percorso UNC, `SYSTEM` si autentica come account computer. Concedi i permessi di condivisione e NTFS all’account computer (o al gruppo `Domain Controllers`), oppure esegui il task con un account di servizio dedicato. ## 3. Ruota a una dimensione che puoi gestire 50–200 MB per file mantiene le conversioni prevedibili e permette a un job notturno di finire entro la finestra prevista. Un file che cresce all’infinito alla fine non ce la fa. Vedi [Performance](../04-performance/). ## 4. Valida i primi output prima di automatizzare Esegui la conversione manualmente su due o tre log reali e apri effettivamente il CSV: - Le timestamp sono corrette — non invertite giorno/mese? (Se lo sono, imposta `-InputCulture`.) - Il delimitatore corrisponde a quello che il tuo consumatore si aspetta? - `ComputerName` è valorizzato? - I contesti di cui hai bisogno sono presenti, e quelli inutili filtrati? `-WhatIf` ti mostra quali file un batch toccherebbe prima di toccarli: ```powershell Get-ChildItem "C:\Administration\Logs\DNSServer\*.log" | Convert-DNSDebugLogFile -RemoveSourceFile -WhatIf ``` ## 5. Decidi cosa fare con i log processati Un job che semplicemente converte "tutti i log tranne il più recente" rielaborerà gli stessi file ogni notte. È robusto e semplice, ma sovrascrive gli output e può inserire righe duplicate in chi li consuma. Scegli una delle seguenti opzioni: - sposta i file `.log` processati in una cartella di archivio - cancellali con `-RemoveSourceFile` una volta che ti fidi della pipeline - fai deduplicare il collector a valle Qualunque scelta tu faccia, annotala — è il dettaglio che confonde il prossimo amministratore. ## 6. Pianifica spazio e conservazione La compressione (`-CompressOutput`) di solito riduce il CSV del 90% o più, ma il volume si accumula comunque. Stima in base al tuo reale tasso di query e all’obbligo di conservazione, e imposta una data di fine per i dati invece di lasciarli crescere indefinitamente. `-OutputType Statistic` vale la pena considerarlo per conservazioni lunghe: i rollup giornalieri sono piccoli e spesso rispondono alle domande di trend per cui si tenevano i dati a livello di riga. ## 7. Tratta l’output come sensibile I log DNS analizzati descrivono la tua struttura interna dei nomi e chi ha cercato cosa. Questo è più rivelatore della maggior parte dei log infrastrutturali e, a seconda della tua giurisdizione, può essere considerato dato personale. - Limita i permessi NTFS e di condivisione sulle cartelle di output. - Non lasciare i CSV su una condivisione generica "temporaneamente". - Includi i dati dei log DNS nella tua policy di conservazione e cancellazione, non solo nella policy di backup. - L’output compresso è più piccolo, non protetto — usa crittografia o controllo accessi dove serve. ## 8. Mantieni attiva la validazione dell’intestazione Il controllo predefinito che verifica che un file sia davvero un log di debug DNS non costa nulla e previene che un percorso digitato male produca migliaia di righe senza senso. Usa `-SkipHeaderValidation` solo per formati davvero insoliti — e nota che il comando rifiuta di combinarlo con `-RemoveSourceFile` proprio per questo motivo. ## 9. Monitora il job, non solo il server Una conversione non sorvegliata che si ferma silenziosamente è peggio di nessuna conversione, perché il gap si nota solo quando qualcuno ha bisogno dei dati. - Controlla l’output di errore non nullo; l’implementazione di riferimento GPO genera un errore quando `$Error.Count -gt 0` così il task segnala il fallimento. - Allerta sul codice risultato dell’ultimo task schedulato, non solo sull’esistenza del task. - Verifica che i file di output compaiano effettivamente con timestamp recenti. - Controlla lo spazio libero su disco sia sul volume dei log che sulla destinazione di output. Cause comuni di un’esecuzione fallita — accesso negato, log corrotti, intestazioni non valide — sono trattate in [Troubleshooting](../08-troubleshooting/). ## 10. Documenta il flusso di lavoro Dove vengono scritti i log, quando gira il job, quali parametri usa, dove va l’output, chi lo consuma e per quanto tempo viene conservato. Sei righe nella tua wiki operativa. È ciò che rende la configurazione verificabile e trasferibile.