Windows Server 2025 / Come verificare la replica AD e i proprietari dei ruoli FSMO

Per controllare i Servizi di dominio Active Directory (AD DS), esamini la replica con Repadmin e verifichi separatamente i titolari dei cinque ruoli FSMO (Flexible Single Master Operations, operazioni a master singolo flessibile). La replica distribuisce le modifiche della directory, mentre i ruoli assegnano particolari operazioni a un controller designato. Aggiungere DC2 o spegnere DC1 non trasferisce automaticamente questi ruoli.

Delimitare il problema di replica

Nel laboratorio, DC1 e DC2 devono essere già stati promossi nel dominio ad.example.test e utilizzare DNS interno funzionante. Replicano le partizioni di dominio, configurazione e schema, oltre alle partizioni applicative DNS comprese nel rispettivo ambito di replica. Partner e tempi possono variare tra partizioni. I file di FS1 e i lease DHCP non vengono copiati tra i server per il solo fatto di essere controller di dominio.

Se un oggetto presenta valori diversi, annoti prima il controller interrogato, l’attributo, il valore e l’ora della modifica. Può ripetere la prova reversibile della descrizione illustrata nell’aggiunta di DC2, selezionando esplicitamente ogni controller e ripristinando il valore originale. Confronti il risultato con la diagnosi Microsoft degli errori di replica: una sola query subito dopo una modifica non distingue una propagazione ancora in corso da un guasto persistente.

Controllare la replica in sola lettura

Apra Windows PowerShell come amministratore su DC1 o DC2 con un account autorizzato a interrogare la directory. Da un PC di gestione servono gli strumenti di amministrazione remota del server (RSAT) per AD DS, inclusi Repadmin e il modulo ActiveDirectory, oltre ad accesso al dominio e DNS corretto. Esegua queste query in sola lettura; non inizi forzando sincronizzazioni o modificando le connessioni di replica.

repadmin /replsummary
repadmin /showrepl DC1
repadmin /showrepl DC2
Get-ADReplicationFailure -Target 'ad.example.test' -Scope Domain

In repadmin /replsummary controlli il numero di errori rispetto ai tentativi e l’intervallo massimo dall’ultima replica riuscita. Uno zero senza tentativi recenti e contesto temporale non dimostra lo stato complessivo del servizio. /showrepl DC1 e /showrepl DC2 mostrano la replica in ingresso al rispettivo destinatario: esamini partizione, partner sorgente, ultimo tentativo, ultimo successo e codice di errore per valutare entrambe le direzioni del laboratorio. Get-ADReplicationFailure raccoglie gli errori associati ai controller del dominio indicato. Una query riuscita che non restituisce oggetti di errore non dimostra, da sola, che tutti i dati coincidano.

Se DC2 era spento intenzionalmente per manutenzione, registri la circostanza e verifichi di nuovo la replica dopo il suo ritorno. Il semplice avvio del server non conferma che i dati siano tornati coerenti. Per errori persistenti, correli codice e orario con DNS del partner, rete e chiamata di procedura remota (RPC), orologio, autenticazione, servizi ed eventi Directory Service. Non disattivi il firewall in modo generalizzato. Un controller isolato da molto tempo richiede un piano di ripristino che consideri età e coerenza della directory prima della riconnessione.

Comprendere i cinque ruoli FSMO

Due ruoli valgono per l’intera foresta e tre per ciascun dominio. Un controller può ricoprire più ruoli senza essere l’unico server che permette l’accesso agli utenti. La descrizione ufficiale dei ruoli FSMO ne chiarisce l’ambito:

L’indisponibilità di un titolare non interrompe necessariamente tutte le funzioni nello stesso momento. Per esempio, un controller può ancora creare account usando il proprio pool RID, ma deve contattare il master RID per ottenerne un altro; le modifiche dello schema richiedono il master schema. Alcuni accessi ancora funzionanti non provano quindi che tutti i ruoli siano disponibili e non giustificano ignorare il guasto.

Confrontare i titolari effettivi

Le query sui titolari richiedono gli stessi strumenti e il corretto contesto di dominio. Netdom query usa il dominio del computer se non viene specificato diversamente. Get-ADForest e Get-ADDomain consentono di indicare il server interrogato. Questi comandi leggono l’assegnazione e non trasferiscono ruoli.

netdom query fsmo
Get-ADForest | Select-Object SchemaMaster,DomainNamingMaster
Get-ADDomain | Select-Object PDCEmulator,RIDMaster,InfrastructureMaster

Esegua le tre query nel contesto del dominio del laboratorio. netdom query fsmo elenca i cinque titolari; Get-ADForest seleziona i due ruoli di foresta e Get-ADDomain i tre di dominio. In una nuova foresta creata inizialmente su DC1, i ruoli normalmente restano lì finché non vengono riassegnati. Registri i nomi effettivi senza supporre che la promozione di DC2 li distribuisca. Per confrontare DC1 e DC2, aggiunga a Get-ADForest e Get-ADDomain prima -Server DC1 e poi -Server DC2, prima della pipeline. Con Netdom specifichi /domain:ad.example.test e /server:DC1, ripetendo con /server:DC2 prima di fsmo. Annoti orario ed errori. Una differenza richiede l’esame di replica e contesto; l’elenco dei titolari non certifica la raggiungibilità o la disponibilità operativa dei server.

Distinguere trasferimento e acquisizione forzata

Il trasferimento ordinario è indicato per la manutenzione pianificata quando il titolare corrente funziona e comunica con la destinazione. L’acquisizione forzata (seizure) è invece una decisione di ripristino quando il trasferimento non è possibile e il vecchio titolare non può rientrare senza una procedura adeguata. Prima di modifiche reali, consulti il processo di trasferimento e acquisizione dei ruoli FSMO e i requisiti per la gestione di ogni ruolo.

• Prima di un trasferimento, confermi ruolo, ambito, titolare e destinazione corretti, stato di entrambi i controller, replica e backup. I permessi di lettura non equivalgono a quelli di trasferimento: per i ruoli di dominio servono Domain Admins, per la denominazione del dominio Enterprise Admins; per lo schema verifichi i requisiti relativi a Schema Admins ed Enterprise Admins nella guida ufficiale.
• Dopo il trasferimento, controlli i titolari dai controller coinvolti, la replica della partizione interessata e le funzioni dipendenti. Il solo cambiamento del nome nell’elenco non prova che il nuovo titolare sia operativo.
• Se sposta l’emulatore PDC del dominio radice della foresta, riveda il server che usa la fonte oraria esterna autorizzata e la continuità della gerarchia temporale. Non configuri tutti i controller come riferimenti indipendenti senza un progetto.
• L’acquisizione forzata richiede un piano per il vecchio titolare e la pulizia dei metadati. Il master RID comporta precauzioni aggiuntive contro identificatori duplicati. Non ricolleghi la vecchia macchina né ne ripristini il backup senza seguire il procedimento di recupero applicabile.

Il risultato di questa esercitazione è una registrazione dello stato di replica per controller e partizione, insieme ai cinque titolari effettivi e ai rispettivi ambiti. In presenza di problemi, conservi codici, orari e contesto per la diagnosi prima di cambiare ruoli. Le query non modificano la configurazione e non richiedono operazioni di annullamento; non occorre spegnere controller, forzare la replica o acquisire ruoli per completare la verifica.