Diagnosticare la replica AD DS con repadmin

La replica multi-master di AD DS fallisce spesso in modo silenzioso: gli oggetti (utenti, password, GPO) divergono tra domain controller senza errori evidenti. Il primo comando diagnostico e’ repadmin /replsummary, che restituisce una vista aggregata con i delta massimi e la percentuale di fallimenti per DC di origine e destinazione. Per scendere nel dettaglio si usa repadmin /showrepl su ogni DC, che elenca lo stato per ogni naming context e i codici di errore (spesso legati a DNS o RPC), mentre repadmin /queue mostra l’arretrato in ingresso. dcdiag aggiunge test di salute su servizi, SYSVOL e ruoli FSMO.

Confermato il problema, si forza la replica con repadmin /syncall /AdeP (tutti i partner) o repadmin /replicate fra due DC. Attenzione ai due scenari-trappola: lo USN rollback (event ID 2095), tipico dopo il ripristino improprio di uno snapshot di VM, che congela la replica in uscita del DC coinvolto; e i lingering object, oggetti riapparsi su un DC rimasto offline oltre la tombstone lifetime, da rimuovere con repadmin /removelingeringobjects e prevenire attivando la strict replication consistency. Il criterio e’ netto: si diagnostica in sola lettura e si forza la replica solo dopo aver escluso rollback e lingering object.

Recupero da problemi di boot con WinRE

Se un server non completa il boot, dopo alcuni tentativi falliti Windows carica automaticamente il WinRE (Windows Recovery Environment). Le opzioni chiave: Startup Repair ripara BCD e file di boot danneggiati ed e’ la prima scelta a basso rischio; il Command Prompt offre interventi mirati con bootrec (/fixboot, /rebuildbcd, /scanos) e bcdedit quando la corruzione e’ nota; System Image Recovery ripristina un’immagine bare-metal, ultima risorsa perche’ sovrascrive il volume. Verifica con reagentc /info che WinRE sia abilitato: se e’ disabilitato non esiste alcun ambiente di ripristino.

Su un domain controller la logica cambia: per riparare AD si entra in DSRM (Directory Services Restore Mode), non nella Safe Mode normale. Un ripristino dello system state con wbadmin start systemstaterecovery e’ per default non-authoritative: il DC si riallinea replicando dai partner. Per riportare in vita oggetti cancellati e propagarli serve invece un authoritative restore con ntdsutil, che alza il version number degli oggetti cosi’ da vincere sulla replica.

Event forwarding e connettivita’ ibrida

Il Windows Event Forwarding (WEF) centralizza i log su un collector senza agenti di terze parti, appoggiandosi a WinRM (winrm quickconfig) e configurato con wecutil; gli eventi arrivano nel log Forwarded Events. La scelta di design e’ tra subscription collector-initiated, in cui il collector interroga un set piccolo e statico di sorgenti note, e source-initiated, in cui sono le sorgenti a inviare verso il collector configurate via Group Policy: quest’ultima scala meglio con molti client o con macchine in DMZ. In scenario ibrido si inoltra invece verso Azure Monitor tramite l’Azure Monitor Agent e le Data Collection Rule, che filtrano gli eventi lato origine.

Per i problemi di connettivita’ ibrida conviene isolare il layer: Test-NetConnection verifica raggiungibilita’ e porta, mentre per i server Azure Arc azcmagent check valida gli endpoint richiesti, spesso bloccati da proxy o ispezione TLS. Per la performance, usa un Data Collector Set in Performance Monitor o Get-Counter, e in ambiente ibrido VM Insights per una baseline correlata. Ricorda che AZ-801 (passing score 700/1000) verra’ ritirato il 30 settembre 2026: verifica sempre la documentazione Microsoft aggiornata.

Trappole tipiche d’esame

  • Replica ferma dopo ripristino di uno snapshot di VM → controlla lo USN rollback: l’event ID 2095 lo segnala; la replica in uscita resta congelata finche’ il DC non viene ripristinato correttamente, e forzarla con repadmin non basta.
  • Oggetti riapparsi dopo che un DC e’ stato offline a lungo → lingering object, non replica lenta: rimuovili con repadmin /removelingeringobjects e abilita la strict replication consistency; una sync forzata li propagherebbe soltanto.
  • Ripristino di utenti cancellati che devono propagarsi → authoritative restore in DSRM: un normale system state recovery e’ non-authoritative e la replica ri-cancellerebbe gli oggetti; serve ntdsutil per alzarne la versione.
  • Molti client da monitorare o macchine in DMZ → subscription source-initiated: la collector-initiated richiede di enumerare ogni sorgente e non scala; la source-initiated si distribuisce via GPO.
  • Server Arc che non invia dati e non risponde ai comandi → verifica gli endpoint con azcmagent check, non riavvii ciechi: il blocco e’ quasi sempre proxy, firewall o ispezione TLS sugli endpoint Azure richiesti.
  • WinRE che non parte per riparare il boot → controlla reagentc /info: se WinRE e’ disabilitato nessuna recovery automatica si avvia e va riabilitato, oppure si avvia da supporto di installazione.