Windows Server 2019 su VMware: errore “domain isn’t available” — cause, troubleshooting e fix

Un solo Windows Server 2019 su VMware perde a tratti la connettività di dominio con errore “We can’t sign you in…”. In questa guida operativa trovi cause tipiche, verifiche mirate, script e fix stabili per eliminare i “domain drop‑off” senza dover ricorrere a riavvii.

Indice

Panoramica del problema

Scenario ricorrente: una VM con Windows Server 2019 in ambiente VMware presenta, in modo sporadico, la schermata di logon con l’errore:

“We can’t sign you in with this credential because your domain isn’t available …”

Il riavvio ripristina subito l’accesso con le stesse credenziali. Gli altri server virtuali non mostrano il sintomo. L’ora appare sincronizzata e i DNS “sembrano” corretti. Questo comportamento punta a un problema intermittente in una delle componenti critiche del percorso di autenticazione: rete, DNS, tempo, Secure Channel (Netlogon/Kerberos), hypervisor o driver.

Sintomi da osservare

Errore di accesso di dominio solo su un host specifico; altri membri del dominio OK.
Risoluzione DNS del DC talvolta fallisce o risponde lenta; ping con micro‑perdite.
Eventi di Netlogon e Kerberos a raffica vicino all’orario del problema.
Reset dello stato al riavvio o al riavvio del servizio Netlogon.
Nessuna modifica credenziali: stessa password funziona dopo reboot.

Cause comuni e come riconoscerle

La tabella seguente mappa le macro‑aree di rischio a test rapidi e indizi nei log.

Macro‑area	Motivo potenziale	Note di diagnostica rapida
Rete	Latenze o micro‑interruzioni tra la VM e i Domain Controller	Ping continuo / `pathping`; confronto RTT con altri server; log switch/port‑group per errori o flapping
DNS	Server DNS errati o mancata risoluzione del DC	`nslookup <dcFQDN>` dalla VM; verifica record SRV; `ipconfig /all` per ordinamento DNS
Tempo	Skew > 5 minuti tra server e DC	`w32tm /query /status`; controllare origine NTP e last sync
Secure Channel	Sessione Kerberos/Netlogon corrotta	`nltest /sc_query:<dominio>`; `Test-ComputerSecureChannel -Verbose`
Account computer	Password machine out‑of‑sync, oggetto AD danneggiato	Event ID 5722/5805; `Test-ComputerSecureChannel -Repair`; eventualmente re‑join al dominio
Cache credenziali	Mancato fallback alle credenziali memorizzate	Provare login offline con utente noto; policy “Interactive logon: Number of previous logons to cache”
Aggiornamenti/driver	Hotfix di rete o agent VMware obsoleti	Verificare Cumulative Update Windows e VMware Tools; controllare vNIC e offload
Hypervisor	NIC virtuale flapping, vMotion non allineato, policy port‑group	ESXi logs; eventi su vNIC; port‑group security (MAC address changes, forged transmits)

Procedura di troubleshooting consigliata

Di seguito una sequenza “fail‑safe” per isolare la causa senza interventi invasivi. Ogni step include il perché, il come e l’esito atteso.

Validare rete e DNS

Misurare connettività verso i DC (raddoppia con altri server per confronto): ping -t DC01 pathping DC01 Test-Connection DC01 -Count 200 -ComputerName DC01 -ErrorAction SilentlyContinue Atteso: zero packet loss; RTT stabile (< 2–3 ms in LAN). Ogni spike o perdita coincidente con il problema è un forte indizio di rete/host.
Verificare DNS in uso: ipconfig /all nslookup DC01.dominio.local nslookup -type=SRV ldap.tcp.dc._msdcs.dominio.local Atteso: solo DNS di dominio nelle interfacce, risoluzione SRV corretta, nessun DNS public/ISP.
Forzare l’ordine dei DNS (se necessario): Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 10.0.0.10,10.0.0.11

Controllare e riparare il Secure Channel

Il canale sicuro macchina‑dominio può rompersi per timeout, replay o password desincronizzata. Esegui:

Test-ComputerSecureChannel -Verbose
nltest /sc_query:DOMINIO
nltest /dsgetdc:DOMINIO

Esiti:

OK: sposta l’attenzione su rete/DNS/tempo.
KO: prova la riparazione senza reboot: Test-ComputerSecureChannel -Repair -Verbose nltest /sc_reset:DOMINIO Reset-ComputerMachinePassword -Server DC01 Se fallisce, esegui rejoin al dominio (staccare/riaggiungere, preservando SID e membership dove possibile).

Analizzare i log in modo mirato

Apri Event Viewer e concentra la ricerca negli ultimi 30‑60 minuti dal guasto:

Registro Sistema: Netlogon (5719, 5722), DNS‑Client, Time‑Service (129, 131).
Registro Sicurezza: Kerberos pre‑authentication failed, KDCERRPRINCIPAL_UNKNOWN.

Filtra via PowerShell per rapidità:

$since = (Get-Date).AddHours(-2)
Get-WinEvent -FilterHashtable @{LogName='System'; ID=5719,5722,5805,129} | Where-Object TimeCreated -ge $since | Format-Table TimeCreated, Id, ProviderName, Message -Auto
Get-WinEvent -FilterHashtable @{LogName='Security'; ProviderName='Microsoft-Windows-Security-Kerberos'} | Where-Object TimeCreated -ge $since | Select-Object TimeCreated, Message

Sincronizzare l’orario

Skew oltre ~5 minuti rompe Kerberos. Allinea alla gerarchia di dominio:

w32tm /config /syncfromflags:DOMHIER /update
w32tm /resync
w32tm /query /status
w32tm /query /source

Se la VM prende tempo dall’hypervisor e anche dal dominio, possono verificarsi “salti”. Evita doppie origini: consenti la sincronizzazione NTP da dominio per i membri e, per il PDC Emulator, da una fonte esterna autorevole.

Aggiornare software di base

Windows Update: installa l’ultimo Cumulative Update per Server 2019.
VMware Tools: aggiorna alla versione più recente supportata dall’host ESXi.
Tipo di vNIC: preferisci VMXNET3 a E1000 per stabilità e performance. Se già VMXNET3, verifica le opzioni offload (LSO, RSS, Checksum) e prova a disabilitare temporaneamente le offload per diagnosticare.

Monitorare la salute dei Domain Controller

Esegui dai DC:

dcdiag /v /c /e /q
repadmin /replsummary
repadmin /showrepl *

Controlla saturazioni CPU/memoria del DC, code di replica e reachable‑ness dai siti.

Verificare impostazioni di alimentazione e hypervisor

Imposta High performance sul piano energetico della VM.
Nel driver della vNIC disabilita “Allow the computer to turn off this device to save power”.
Controlla nel port‑group VMware le policy di sicurezza: MAC Address Changes, Forged Transmits, Promiscuous Mode coerenti con vMotion e con eventuali funzioni di alta disponibilità.
Correla gli orari di snapshot/backup/vMotion con le finestre del guasto.

Mitigazioni immediate

Azione rapida	Quando usarla
Riavvio programmato di Netlogon `net stop netlogon && net start netlogon`	Quando l’accesso fallisce ma un reboot completo non è desiderabile o impatta servizi
Login con credenziali memorizzate	Garantisce accesso d’emergenza per raccogliere log e avviare fix
Script di monitoraggio	Scheduled Task che logga ogni 5 minuti l’esito di `nltest /sc_query` per individuare pattern

Script pronti all’uso

Verifica end‑to‑end e riparazione del Secure Channel

# Esegui in PowerShell come amministratore
$Domain = (Get-WmiObject Win32_ComputerSystem).Domain
Write-Host "Dominio rilevato: $Domain"
$sc = Test-ComputerSecureChannel -Verbose -ErrorAction SilentlyContinue
if (-not $sc) {
  Write-Warning "Secure Channel KO. Provo la riparazione..."
  try {
    Test-ComputerSecureChannel -Repair -Verbose -ErrorAction Stop
    nltest /sc_query:$Domain
    Write-Host "Secure Channel riparato."
  } catch {
    Write-Error "Riparazione fallita: $($_.Exception.Message). Valuta rejoin."
  }
} else {
  Write-Host "Secure Channel OK."
}

Logger per intercettare drop intermittenti

# C:\Scripts\Monitor-SecureChannel.ps1
$Domain = (Get-WmiObject Win32_ComputerSystem).Domain
$Log = "C:\Logs\sc_monitor.csv"
New-Item -ItemType Directory -Force (Split-Path $Log) | Out-Null
$ts = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
$ok = (nltest /sc_query:$Domain) -join " " -match "trusted DC name|status 0"
$line = "{0},{1},{2}" -f $ts, $env:COMPUTERNAME, ($(if ($ok) {'OK'} else {'KO'}))
Add-Content -Path $Log -Value $line

Crea un’attività pianificata che esegue lo script ogni 5 minuti; al primo KO, attiva un Custom Task che raccoglie log (netsh trace, eventi) per analisi forense.

Traccia di rete circolare al bisogno

netsh trace start capture=yes report=no tracefile=C:\Traces\NetLogon.etl
REM ... riprodurre il problema ...
netsh trace stop

Cosa catturare durante il guasto

Output di: nltest /sc_query:DOMINIO nltest /dsgetdc:DOMINIO klist ipconfig /all w32tm /query /status Resolve-DnsName ldap.tcp.dc._msdcs.DOMINIO
Eventi Windows (System, Security) nell’ultimo ±10 minuti.
Pacchetti: netsh trace o pktmon se preferisci built‑in; filtra per Kerberos (port 88), LDAP (389/636), SMB (445), RPC (135, 49152+).
Timeline VMware: vMotion, snapshot, backup, host maintenance.

Approfondimenti chiave per un fix definitivo

Cache delle credenziali

Assicurati che la policy Interactive logon: Number of previous logons to cache non sia impostata a 0 sul server. Valore tipico: 10. Questo consente accessi d’emergenza per interventi correttivi anche se un DC non è momentaneamente raggiungibile.

E1000 vs VMXNET3

E1000 è emulato e può evidenziare instabilità sotto stress o in combinazione con specifici driver. VMXNET3 è paravirtualizzato, più efficiente e stabile. Se cambi tipo di vNIC, pianifica una finestra e verifica l’IP è statico e coerente; dopo il cambio riconfigura le Advanced Properties (RSS, LSO) e testa.

Offload e funzionalità avanzate

In casi sporadici, offload come Large Send Offload, Checksum Offload o RSS possono interagire male con firewall/IDS/EDR o device fisici. Per diagnosi, prova a disabilitarle temporaneamente sulla vNIC e verifica se i drop scompaiono; se sì, riabilita selettivamente.

Policy del port‑group e vMotion

Se il port‑group impone restrizioni su MAC o trasmissioni, un vMotion può generare un breve disallineamento di MAC/IP percepito come “flapping”. Verifica che MAC Address Changes e Forged Transmits siano coerenti con la tua policy di sicurezza e con le esigenze del cluster.

Checklist rapida operativa

Verifica	Comando/azione	Esito atteso	Se fallisce
Reachability DC	`ping -t DC01`, `pathping DC01`	0% loss, RTT stabile	Indagare rete/host, ESXi logs, port‑group
SRV e FQDN DC	`nslookup -type=SRV ldap.tcp.dc._msdcs.DOM`	Lista DC corretta	Correggere DNS sulla NIC, controllare zone
Secure Channel	`Test-ComputerSecureChannel`	True	`-Repair` o `nltest /sc_reset`, rejoin
Tempo	`w32tm /query /status`	Source = DOMHIER; skew < 5m	`w32tm /config ...` e `/resync`
Netlogon	`net stop netlogon && net start netlogon`	Autenticazione ripristinata	Raccogli log, valuta rejoin
Driver/Tools	CU Windows, VMware Tools, vNIC VMXNET3	Componenti aggiornati	Test con offload disabilitate
DC health	`dcdiag`, `repadmin` (su DC)	Nessun errore critico	Risolvi replica, carico, DNS DC

Runbook consigliato

Durante il guasto: prova login con credenziali memorizzate; se entri, salva immediatamente Get-WinEvent e avvia netsh trace.
Se il server è bloccato: preferisci riavvio Netlogon al reboot completo; raccogli comunque eventi post‑ripristino.
Se il problema è ricorrente: attiva il logger nltest schedulato per 48‑72 ore; incrocia con timeline VMware.
Se isolato a una sola VM: valuta re‑creazione dell’oggetto computer AD o deploy di una nuova VM e migrazione workload.

Consigli di hardening senza introdurre falsi positivi

Abilita Credential Guard e protezioni LSASS solo dopo la stabilizzazione della connettività.
Evita di disabilitare IPv6 indiscriminatamente; se non usato, assicurati che non esistano record o binding che lo richiedano.
Documenta data/ora di ogni disconnessione e correlale con snapshot, backup, vMotion e manutenzioni.

FAQ veloci

Perché un semplice riavvio “risolve” (ma solo per poco)?

Il reboot azzera sessioni Netlogon/Kerberos, rinnova la password del canale sicuro se scaduta e riallinea servizi di rete. Se però l’origine è rete/DNS/hypervisor, il problema si ripresenta. Individua la causa radice, non fermarti al sintomo.
Quando rifare il join al dominio?

Se Test-ComputerSecureChannel -Repair e nltest /sc_reset falliscono, l’oggetto computer o la sua password sono fuori sincronia. Un rejoin pulito è spesso il fix più rapido; ricordati di preservare membership e diritti di servizio.
Conviene passare a VMXNET3?

Sì: garantisce minore overhead e migliore stabilità rispetto a E1000. Pianifica il cambio (potrebbe creare un nuovo NIC GUID) e riapplica DNS statici, metriche e policy.
Come verifico se è davvero il DNS?

Durante il guasto esegui nslookup DC01.dominio.local e la query SRV. Se falliscono o impiegano molto, è un problema DNS (indirizzi, ordine, reachability, firewall).
Posso convivere con il problema usando credenziali cache?

Solo come misura temporanea per entrare e raccogliere evidenze. La cache non sostituisce la connettività verso il DC per servizi (Kerberos, SMB, GPO) e può creare divergenze di policy.

Raccomandazioni finali

Se il problema resta confinato a una singola VM dopo i controlli: ricrea l’oggetto computer in AD o deploy una nuova VM e migra ruoli/servizi.
Abilita il monitoring del Secure Channel (script schedulato) per catturare il momento del drop.
Conserva un registro cronologico degli eventi di disconnessione e delle attività VMware collegate.
Stabilizza prima rete/DNS/tempo; solo dopo applica hardening (Credential Guard, protezioni LSASS) per evitare falsi allarmi.

Appendice: comandi utili

ipconfig /all
Get-DnsClientServerAddress
Resolve-DnsName DC01
nltest /dsgetdc:DOMINIO
nltest /sc_query:DOMINIO
Test-ComputerSecureChannel -Verbose
Reset-ComputerMachinePassword -Server DC01
klist purge
w32tm /query /status
w32tm /config /syncfromflags:DOMHIER /update
w32tm /resync
net stop netlogon && net start netlogon
Get-WinEvent -FilterHashtable ...
dcdiag /v /c /e /q  (su DC)
repadmin /replsummary  (su DC)

In sintesi

Seguendo la procedura proposta si arriva, nella stragrande maggioranza dei casi, a una di queste tre radici: collegamento di rete instabile, Secure Channel corrotto o mismatch di configurazione tra hypervisor e guest. Ognuna ha una via d’uscita precisa, riproducibile e senza reboot come unica scorciatoia.

Convalida rete/DNS/tempo, ripara il canale sicuro, aggiorna Tools/driver e allinea il port‑group. Se il problema resta legato a quella specifica VM, considera la ricreazione dell’oggetto computer o un redeploy pulito: spesso è il modo più rapido per tornare a uno stato affidabile e mantenibile.