• Guide, Sistemi Operativi
• 18 Luglio 2026

Chi amministra Active Directory conosce il concetto di replica multi-master: ogni Domain Controller può ricevere modifiche e replicarle agli altri DC del dominio.

Esistono però alcune operazioni che, per evitare conflitti e garantire la coerenza del database di Active Directory, devono essere eseguite da un solo Domain Controller alla volta. Per questo motivo Microsoft ha introdotto i Flexible Single Master Operations (FSMO), oggi chiamati anche Operations Master Roles.

I ruoli FSMO sono cinque:

• 2 ruoli a livello di Forest:
  Schema Master e Domain Naming Master
• 3 ruoli a livello di Domain:
  RID Master, PDC Emulator e Infrastructure Master

Dove vengono collocati i ruoli FSMO?

Quando viene creato un nuovo dominio Active Directory, tutti e cinque i ruoli FSMO vengono assegnati automaticamente al primo Domain Controller promosso nella foresta.

Questa configurazione è perfettamente normale e, nella maggior parte delle infrastrutture di piccole e medie dimensioni, non esiste alcuna necessità di distribuire i ruoli su server differenti.

Solo in ambienti particolarmente estesi, caratterizzati da numerosi Domain Controller o da specifici requisiti di disponibilità, può essere opportuno spostare alcuni ruoli FSMO su altri server per semplificare la gestione o migliorare la resilienza dell’infrastruttura.

Nella maggior parte degli ambienti non ci si accorge nemmeno della loro esistenza… almeno finché il server che li ospita non diventa indisponibile.

Figura 1: Comandi che consentono di identificare rapidamente i Domain Controller che ospitano i cinque ruoli FSMO

Prima di analizzare nel dettaglio ciascun ruolo, la tabella seguente riassume l’ambito di utilizzo, il livello di criticità e le conseguenze della sua indisponibilità.

Schema Master

Lo Schema Master è l’unico Domain Controller autorizzato a modificare lo schema di Active Directory.

Fortunatamente le modifiche allo schema sono molto rare e avvengono principalmente durante:

• installazione di Exchange Server;
• estensioni dello schema;
• introduzione di nuove versioni di Windows Server.

Se questo ruolo non è disponibile gli utenti continueranno ad autenticarsi normalmente e Active Directory continuerà a funzionare senza problemi.

L’unica limitazione sarà l’impossibilità di effettuare modifiche allo schema fino al ripristino del ruolo.

 

Prima di poter gestire il ruolo Schema Master è necessario registrare lo snap-in di Active Directory Schema eseguendo il comando regsvr32.exe schmmgmt.dll

Dopo la registrazione, aprire una console MMC vuota (mmc.exe), selezionare File > Add/Remove Snap-in… e aggiungere lo snap-in Active Directory Schema. Infine, fare clic con il tasto destro sul nodo Active Directory Schema e scegliere Operations Master… per visualizzare il Domain Controller che detiene il ruolo ed eventualmente trasferirlo a un altro server tramite il pulsante Change.

Figura 2: Registrazione dello snap-in Active Directory Schema e trasferimento del ruolo Schema Master

Domain Naming Master

Il Domain Naming Master gestisce la creazione e la rimozione di domini e application partition all’interno della forest.

Anche questo ruolo viene utilizzato molto raramente.

Se il server che ospita il ruolo non è disponibile:

• non sarà possibile creare o eliminare nuovi domini nella forest;
• il funzionamento quotidiano degli utenti e dei Domain Controller non subirà alcun impatto.

Figura 3: Il ruolo Domain Naming Master viene amministrato tramite la console Active Directory Domains and Trusts.

RID Master

Ogni oggetto di Active Directory possiede un SID (Security Identifier) univoco.

Per garantire che due Domain Controller non generino lo stesso SID, il RID Master distribuisce blocchi di Relative ID (RID) ai vari DC. Senza questo meccanismo due Domain Controller potrebbero assegnare lo stesso SID a oggetti differenti, compromettendo l’univocità degli identificatori di sicurezza e causando potenziali problemi di autorizzazione all’interno del dominio.

Ogni Domain Controller riceve quindi un pool di RID da utilizzare autonomamente e, quando viene creato un nuovo utente, computer o gruppo, utilizza uno dei RID disponibili nel proprio pool locale senza dover contattare ogni volta il RID Master.

Il SID e il Relative ID (RID)

Ogni SID (Security Identifier) è composto da una parte comune, che identifica il dominio, e da un Relative ID (RID) finale che identifica in modo univoco l’oggetto all’interno del dominio.

La parte iniziale del SID è quindi identica per tutti gli utenti, i gruppi e i computer appartenenti allo stesso dominio, mentre il RID viene assegnato dal Domain Controller utilizzando uno dei valori disponibili nel pool ricevuto dal RID Master.

È importante notare che i RID non sono necessariamente consecutivi. La presenza di valori apparentemente “saltati” è del tutto normale e può dipendere dalla creazione e successiva eliminazione di oggetti o dall’utilizzo dei RID da parte di Domain Controller differenti.

Figura 4: Ogni oggetto di Active Directory possiede un SID univoco, composto dal SID del dominio e da un Relative ID (RID)

Se il RID Master non è disponibile non succede immediatamente nulla. Ogni Domain Controller continuerà infatti a utilizzare il pool di RID già assegnato.

Il problema compare solo quando un DC esaurisce il proprio pool: da quel momento non sarà più possibile creare nuovi utenti, gruppi o computer fino al ripristino del ruolo o all’assegnazione del ruolo RID Master a un altro Domain Controller.

PDC Emulator

Il PDC Emulator è probabilmente il ruolo FSMO più importante.

Svolge numerose funzioni fondamentali, tra cui:

• sincronizzazione dell’ora per il dominio;
• gestione immediata delle modifiche alle password;
• elaborazione di alcune operazioni legate alle Group Policy;
• riferimento principale per numerose attività amministrative.

Il PDC Emulator del dominio radice della foresta rappresenta il riferimento temporale per tutti gli altri sistemi. Generalmente viene configurato per sincronizzare l’orario con una sorgente NTP esterna affidabile, mentre gli altri Domain Controller sincronizzano il proprio orologio con il PDC Emulator e i client Windows sincronizzano automaticamente l’ora con il Domain Controller che li autentica.

Questa gerarchia garantisce che tutti i sistemi del dominio mantengano un orario coerente, requisito fondamentale per il corretto funzionamento di Kerberos, della replica di Active Directory e di numerosi servizi di sicurezza.

Se il PDC Emulator diventa indisponibile il dominio continua normalmente a funzionare, ma possono comparire diversi problemi:

• ritardi nella propagazione delle password appena cambiate;
• problemi di sincronizzazione dell’orario;
• possibili anomalie nella gestione delle Group Policy;
• difficoltà in alcune attività amministrative.

Per questo motivo è il ruolo FSMO che richiede maggiore attenzione in caso di guasto.

Figura 5: Il comando w32tm /monitor permette di verificare lo stato della sincronizzazione dell’ora tra i Domain Controller e di identificare il PDC Emulator, che rappresenta il riferimento temporale per l’intero dominio

Infrastructure Master

L’Infrastructure Master mantiene aggiornati i riferimenti agli oggetti appartenenti ad altri domini della forest.

Questo ruolo è realmente importante solo negli ambienti multi-domain.

In una foresta composta da un solo dominio il suo impatto è praticamente nullo.

Anche negli ambienti con più domini, la sua indisponibilità non provoca problemi immediati: nel tempo potrebbero però verificarsi riferimenti non aggiornati tra oggetti appartenenti a domini differenti.

Quali ruoli FSMO sono davvero critici?

Sebbene tutti i ruoli FSMO abbiano un’importanza specifica, non tutti hanno lo stesso impatto sull’operatività quotidiana di Active Directory.

Il PDC Emulator è senza dubbio il ruolo più critico, poiché interviene nella sincronizzazione dell’ora, nella gestione delle modifiche alle password e in numerose attività amministrative. Un’indisponibilità prolungata di questo ruolo può quindi causare problemi percepibili dagli utenti e dagli amministratori.

Anche il RID Master merita particolare attenzione. Sebbene la sua assenza non produca effetti immediati, un’interruzione prolungata potrebbe impedire la creazione di nuovi utenti, gruppi e computer una volta esauriti i pool di RID assegnati ai Domain Controller.

Gli altri tre ruoli (Schema Master, Domain Naming Master e Infrastructure Master) vengono invece utilizzati solo in circostanze particolari e, nella maggior parte degli ambienti, la loro indisponibilità temporanea non influisce sul normale funzionamento del dominio.

Infrastructure Master e Global Catalog: una limitazione ormai quasi superata

Per molti anni una delle raccomandazioni più note di Microsoft era quella di non collocare il ruolo Infrastructure Master su un Domain Controller configurato come Global Catalog, almeno negli ambienti con più domini.

Il motivo era legato al funzionamento dell’Infrastructure Master, che ha il compito di mantenere aggiornati i riferimenti agli oggetti appartenenti ad altri domini della foresta. Poiché un Global Catalog possiede già una replica parziale degli oggetti di tutti i domini, non era in grado di rilevare correttamente alcune modifiche ai riferimenti cross-domain, rendendo di fatto inutile il lavoro dell’Infrastructure Master.

Oggi questa limitazione è diventata quasi irrilevante. Nella maggior parte degli ambienti moderni tutti i Domain Controller sono configurati come Global Catalog e, inoltre, con l’introduzione del Cestino di Active Directory (Active Directory Recycle Bin) il meccanismo di aggiornamento dei riferimenti è stato modificato, eliminando di fatto questa dipendenza.

Di conseguenza:

• in una foresta con un solo dominio il problema non si pone, poiché l’Infrastructure Master non gestisce riferimenti verso altri domini;
• nelle foreste multi-domain in cui tutti i Domain Controller sono anche Global Catalog, il ruolo può essere ospitato indifferentemente su qualsiasi server;
• solo in scenari particolari, con più domini e Global Catalog presenti solo su alcuni Domain Controller, può ancora avere senso seguire la raccomandazione storica e mantenere l’Infrastructure Master su un Domain Controller che non sia anche Global Catalog.

Per questo motivo, sebbene questa raccomandazione sia ancora presente nella documentazione Microsoft, nella maggior parte delle infrastrutture Active Directory moderne non rappresenta più un aspetto di cui preoccuparsi. È però utile conoscerne l’origine, soprattutto quando si amministrano ambienti legacy o si consultano documentazioni meno recenti.

Trasferimento dei ruoli RID Master, PDC Emulator e Infrastructure Master

I ruoli RID Master, PDC Emulator e Infrastructure Master vengono gestiti dalla console Active Directory Users and Computers. Per accedere alla finestra di gestione è sufficiente fare clic con il tasto destro sul nome del dominio e selezionare Operations Masters….

La finestra è suddivisa in tre schede, una per ciascun ruolo. In ogni scheda viene visualizzato il Domain Controller che attualmente detiene il ruolo e, se la console è connessa a un altro DC, è possibile trasferire il ruolo facendo clic sul pulsante Change.

Nota: prima di eseguire il trasferimento è necessario collegare la console al Domain Controller che dovrà diventare il nuovo proprietario del ruolo selezionando Action > Change Domain Controller….

Figura 6: La console Active Directory Users and Computers consente di visualizzare e trasferire i ruoli RID Master, PDC Emulator e Infrastructure Master tramite la finestra Operations Masters

Cosa succede se un server con ruoli FSMO viene riavviato?

Nella maggior parte dei casi non succede assolutamente nulla.

Un riavvio programmato di pochi minuti non crea problemi, perché quasi tutti i ruoli FSMO vengono utilizzati solo occasionalmente e gli altri Domain Controller continuano a lavorare normalmente.

L’unica eccezione è rappresentata dal PDC Emulator, che potrebbe causare piccoli ritardi nella gestione delle password o della sincronizzazione dell’ora durante il periodo di indisponibilità.

Cosa succede se il server viene perso definitivamente?

Se il Domain Controller che ospita uno o più ruoli FSMO non potrà più essere recuperato, non sarà possibile eseguire un normale trasferimento (Transfer). In questo scenario è necessario sequestrare (Seize) i ruoli FSMO su un altro Domain Controller.

Attenzione: il Seize deve essere eseguito solo quando si è certi che il vecchio Domain Controller non verrà più rimesso in servizio. Se il server dovesse tornare online continuando a ritenersi proprietario del ruolo FSMO, potrebbero verificarsi gravi inconsistenze nell’infrastruttura di Active Directory.

Maggiori informazioni sono disponibili alla pagina Transfer or seize Operation Master roles – Windows Server | Microsoft Learn

Nel nostro esempio il PDC Emulator è ospitato da DC1, ormai non più raggiungibile. Da DC2 è possibile eseguire il sequestro del ruolo utilizzando l’utilità NTDSUTIL.

Aprire un prompt dei comandi con privilegi amministrativi ed eseguire:

Dopo aver verificato la connessione al nuovo Domain Controller, il comando seize pdc richiederà una conferma prima di assegnare definitivamente il ruolo a DC2.

Figura 7: Operazione di seizing su un ruolo di Active Directory

Dopo la conferma, NTDSUTIL tenta inizialmente di eseguire un trasferimento del ruolo. Se il Domain Controller originale è ancora raggiungibile, il trasferimento viene completato automaticamente e il sequestro non è necessario, come evidenziato dal messaggio:

FSMO transferred successfully – seizure not required.

Se invece il server che ospitava il ruolo è realmente indisponibile, il trasferimento fallirà e NTDSUTIL procederà con il sequestro (Seize) del ruolo, assegnandolo al Domain Controller al quale ci si è precedentemente connessi.

Figura 8: NTDSUTIL tenta sempre un trasferimento del ruolo prima di eseguire il Seize. Se il Domain Controller originale è ancora disponibile, il ruolo viene trasferito automaticamente e il sequestro non viene eseguito

Nota: nello screenshot il server DC1 era ancora raggiungibile. Per questo motivo NTDSUTIL ha completato un Transfer anziché un vero Seize, come confermato dal messaggio “FSMO transferred successfully – seizure not required.” Per simulare un vero sequestro è necessario che il Domain Controller proprietario del ruolo sia spento o definitivamente irraggiungibile.

Attenzione: Transfer e Seize non sono la stessa operazione.

• Transfer → il Domain Controller proprietario del ruolo è ancora disponibile.
  
• Seize → il Domain Controller è definitivamente irrecuperabile.
  

Al termine dell’operazione è possibile verificare che il PDC Emulator sia stato correttamente assegnato al nuovo server eseguendo netdom query fsmo oppure Get-ADDomain | Select PDCEmulator

Figura 9: Verifica del nuovo proprietario del ruolo PDC Emulator

Cosa fare se il vecchio Domain Controller viene recuperato

Dopo aver eseguito un Seize di uno o più ruoli FSMO, il Domain Controller originario non deve essere semplicemente riacceso.

Se il server dovesse tornare online continuando a ritenersi proprietario del ruolo FSMO, potrebbero verificarsi inconsistenze nell’infrastruttura di Active Directory. Per questo motivo Microsoft raccomanda di eseguire il Seize solo quando si è certi che il Domain Controller originale sia definitivamente irrecuperabile.

Importante: dopo un’operazione di Seize, il Domain Controller originale non deve essere rimesso in servizio così com’è. Se il server viene recuperato, è consigliabile demotarlo” (si può dire?) e promuoverlo nuovamente a Domain Controller (oppure reinstallarlo) prima di reintegrarlo nell’infrastruttura Active Directory. In questo modo si evita qualsiasi rischio di inconsistenze nella gestione dei ruoli FSMO.

Best Practices per la gestione dei ruoli FSMO

Nella maggior parte delle infrastrutture Active Directory la gestione dei ruoli FSMO è estremamente semplice. Seguire alcune buone pratiche consente però di evitare problemi durante le attività di manutenzione o in caso di guasto di un Domain Controller.

• Non spostare i ruoli FSMO senza una reale necessità. Nelle infrastrutture di piccole e medie dimensioni è perfettamente normale che tutti e cinque i ruoli siano ospitati dallo stesso Domain Controller.
• Prestare particolare attenzione al PDC Emulator. È il ruolo con il maggiore impatto sull’operatività quotidiana del dominio e merita un monitoraggio costante, soprattutto per quanto riguarda la sincronizzazione dell’ora.
• Eseguire sempre un Transfer quando il Domain Controller è ancora disponibile. Il Seize deve essere considerato una procedura di emergenza, da utilizzare esclusivamente quando il server che ospita il ruolo è definitivamente irrecuperabile.
• Verificare periodicamente la distribuzione dei ruoli FSMO. Comandi come netdom query fsmo, Get-ADDomain e Get-ADForest consentono di controllare rapidamente quale Domain Controller ospita ciascun ruolo.
• Documentare la posizione dei ruoli FSMO. In ambienti con più Domain Controller è buona norma mantenere aggiornata la documentazione dell’infrastruttura, così da velocizzare le attività di troubleshooting e disaster recovery.
• Evitare di concentrare i ruoli FSMO su un Domain Controller poco affidabile o destinato a frequenti manutenzioni.

Conclusioni

I ruoli FSMO rappresentano un meccanismo fondamentale di Active Directory per gestire quelle operazioni che non possono essere replicate in modalità multi-master.

La buona notizia è che la perdita temporanea della maggior parte dei ruoli non interrompe il funzionamento del dominio. L’unico ruolo davvero critico nella quotidianità è il PDC Emulator, mentre gli altri entrano in gioco solo durante specifiche operazioni amministrative o in scenari particolari.

Conoscere il compito di ogni ruolo permette di affrontare con maggiore tranquillità sia una manutenzione programmata sia il ripristino di un Domain Controller dopo un guasto.