1 24/04/2026 7 min

L’errore 20079 sul server DHCP non va trattato come un messaggio generico da ignorare: di solito segnala che il servizio non riesce a operare correttamente per un problema di autorizzazione, stato del servizio, configurazione incoerente o conflitto con l’ambiente di rete. In pratica, il server è presente, ma qualcosa impedisce al ruolo DHCP di erogare o pubblicare correttamente gli indirizzi.

La prima cosa utile è separare il problema in tre livelli: sistema operativo, servizio DHCP e integrazione con Active Directory o con la rete. Se non fai questa distinzione, rischi di cambiare opzioni a caso e perdere tempo su sintomi secondari. Un server DHCP può risultare “attivo” nel pannello, ma essere bloccato da autorizzazione mancante, scope non valido, NIC sbagliata, binding errato o database/servizio in stato incoerente.

Diagnosi pratica dell’errore 20079

Il caso più comune in ambito Windows Server è un DHCP che non riesce a partire correttamente o non riesce a servire richieste perché non è autorizzato in Active Directory, oppure perché la configurazione della rete non è compatibile con l’interfaccia su cui il servizio dovrebbe ascoltare. In ambienti non-AD, il problema tende a spostarsi su binding, firewall, conflitti di IP o servizio fermo dopo una modifica.

Prima di toccare la configurazione, verifica il layer corretto: il server risponde? il servizio è avviato? il ruolo è autorizzato? gli scope sono attivi? la scheda di rete usata dal DHCP ha un IP statico corretto? Queste sono le domande che separano una correzione rapida da una caccia al fantasma.

Verifiche immediate

  1. Controlla lo stato del servizio DHCP. Su Windows, apri PowerShell come amministratore e verifica il servizio:
    Get-Service DHCPServer

    Atteso: stato Running. Se è Stopped o Starting da troppo tempo, il problema è a monte del rilascio IP.

  2. Verifica se il server DHCP è autorizzato in Active Directory. Su un dominio Windows, usa:
    Get-DhcpServerInDC

    Atteso: il nome del server e l’IP corretti. Se il server non compare, o compare con un indirizzo errato, il servizio può non operare come previsto.

  3. Controlla gli eventi nel registro applicazioni e nel log DHCP. I percorsi tipici sono il Event Viewer e il log in C:\Windows\System32\Dhcp\DhcpSrvLog-*.log. Cerca errori di binding, autorizzazione, database o interfaccia non valida.

  4. Verifica che la scheda di rete del server abbia IP statico e gateway coerente. Su un DHCP server, una NIC con DHCP client attivo è una cattiva idea: può cambiare indirizzo e rompere autorizzazione, binding o reachability.
  5. Controlla che il firewall non stia bloccando UDP 67 e 68 sul server e che non ci sia un altro DHCP server in rete che risponde prima di te. Un secondo server non autorizzato può creare sintomi intermittenti e rendere l’errore difficile da leggere.

Se il server è in dominio, l’errore 20079 è spesso associato a un problema di autorizzazione o di registrazione nel contesto AD. Se il server è standalone, il focus si sposta su stato del servizio, binding e rete locale. Non dare per scontato che il messaggio significhi la stessa cosa in ogni scenario: il contesto cambia il significato operativo.

Ipotesi più probabili, in ordine

  1. Il server DHCP non è autorizzato in Active Directory. Falsificazione in meno di 5 minuti: esegui Get-DhcpServerInDC e confronta nome/IP del server con quelli reali. Se manca, il problema è quasi certamente lì.
  2. Il servizio DHCP è avviato ma non riesce a legarsi alla NIC corretta. Falsificazione rapida: verifica binding e IP della scheda, poi controlla gli eventi del servizio. Se il server ha più interfacce, una NIC sbagliata o una route anomala può bastare a rompere l’erogazione.
  3. Conflitto di rete o configurazione scope incoerente. Falsificazione rapida: controlla che lo scope sia attivo, che il range non sia fuori subnet e che non ci siano esclusioni troppo ampie. Un range errato può far sembrare il DHCP “rotto” quando in realtà non ha indirizzi validi da assegnare.

In ambienti più datati o con servizi migrati, entra anche in gioco il database DHCP. Se il servizio non parte dopo un crash o dopo una manutenzione, il database può essere corrotto o il journal non allineato. Non è il primo sospetto, ma va considerato se i controlli precedenti sono negativi.

Soluzione consigliata passo-passo

  1. Metti in sicurezza lo stato attuale prima di cambiare qualcosa. Esporta la configurazione DHCP e annota IP, scope, opzioni e autorizzazione. Su Windows puoi usare:
    netsh dhcp server export C:\temp\dhcp-backup.txt all

    Questo non risolve il problema, ma ti dà un rollback pratico se devi correggere scope o ripristinare opzioni.

  2. Verifica e, se necessario, ripristina l’autorizzazione del server in AD. Se il server non compare in Get-DhcpServerInDC, aggiungilo dal contesto corretto o dal pannello di gestione DHCP. Dopo la correzione, riavvia il servizio e ricontrolla gli eventi.
  3. Controlla l’IP della NIC del server. Deve essere statico, nella subnet corretta e coerente con il gateway e il DNS interni. Se il server ha più NIC, disabilita temporaneamente quelle non necessarie per capire se il servizio sta bindando sull’interfaccia sbagliata. Questa è una prova reversibile e spesso chiarisce il quadro in pochi minuti.
  4. Apri il console DHCP e verifica che lo scope sia Active, non Inactive. Controlla anche che il range non sia esaurito e che le esclusioni non coprano tutto il pool. Se il lease pool è vuoto, il server può sembrare guasto mentre in realtà non ha più indirizzi da assegnare.
  5. Controlla i log di sistema per errori specifici. Se trovi riferimenti a database, riavvia il servizio dopo aver verificato che non ci siano processi bloccati e che il file dhcp.mdb o i log associati non siano corrotti. Se il database è sospetto, lavora con copia e backup, non direttamente sul file in produzione.
  6. Se sospetti un conflitto con un altro DHCP server, fai una verifica di rete dal segmento interessato. Un modo semplice è osservare i lease e i log client, o usare un test su una macchina del segmento per vedere chi risponde alle richieste DHCP. Se emergono più risposte, il problema non è solo il tuo server: hai un rogue DHCP da isolare.
  7. Riavvia il servizio solo dopo aver raccolto i dati utili. Il comando è semplice:
    Restart-Service DHCPServer

    Se il restart fallisce, gli eventi successivi sono più informativi del tentativo stesso. Se invece parte, verifica subito che il server torni a rilasciare lease e che il log non continui a generare errori.

Se lavori da GUI, il percorso è più lineare: apri DHCP da Server Manager, espandi il server, controlla IPv4, lo stato degli scope e la sezione di autorizzazione. Il vantaggio del pannello è che ti mostra subito la coerenza tra server, scope e opzioni senza passare da più comandi. Però, quando devi dimostrare la causa, il log e i comandi restano più affidabili della sola vista grafica.

Controlli finali e rollback

  1. Conferma che il servizio sia attivo e stabile:
    Get-Service DHCPServer

    Atteso: Running senza restart loop.

  2. Conferma che il server sia presente in AD:
    Get-DhcpServerInDC

    Atteso: nome e IP corretti del server in elenco.

  3. Verifica che uno o più client ottengano lease validi e che il lease appaia nella console DHCP. Se i client ricevono IP ma non gateway o DNS, il problema è nelle opzioni di scope, non nel servizio base.
  4. Controlla il registro eventi nelle ultime 15-30 minuti per escludere ricomparsa dell’errore 20079 o errori correlati. Se il messaggio torna, non fermarti al riavvio: la causa è ancora presente.
  5. Rollback: se una modifica a NIC, scope o autorizzazione ha peggiorato il problema, ripristina il backup esportato con netsh dhcp server import o reimposta la configurazione precedente dal pannello. Se hai disabilitato interfacce secondarie, riattivale solo dopo aver verificato quale binding è corretto.

Un dettaglio che spesso viene trascurato: il DHCP non fallisce sempre in modo “totale”. Può servire alcuni segmenti e fallire su altri, soprattutto se hai più scope, più VLAN o più NIC. Per questo i test devono essere fatti dal segmento reale dell’utente, non solo dal server stesso.

Se l’errore 20079 compare dopo una migrazione, dopo un restore o dopo una modifica di rete, il sospetto principale è una discrepanza fra configurazione salvata e contesto attuale. In quel caso la strada corretta è riallineare autorizzazione, binding e scope, non forzare riavvii ripetuti.

Assunzione operativa: il server è Windows Server in ambiente di produzione o quasi-produzione; i controlli indicati sono pensati per ridurre il blast radius e distinguere un problema di autorizzazione da uno di rete o configurazione.