In questo articolo vedremo come forzare una sincronizzazione autorevole e non autorevole per la replica sysvol con replica DFSR.
Come eseguire una sincronizzazione non autorevole della replica di sysvol con replica DFSR
Aprire lo strumento ADSIEDIT.MSC, modificare il valore e l’attributo del nome distinto (DN) su ciascuno dei controller di dominio (DC) che si desidera rendere non autorevoli:
CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=u0026lt;the server nameu003e,OU=Domain Controllers,DC=u0026lt;domainu003ennmsDFSR-Enabled=FALSEForzare la replica di Active Directory in tutto il dominio.
Eseguire il seguente comando da un prompt dei comandi con privilegi elevati sugli stessi server impostati come non autorevoli:
DFSRDIAG POLLADNel registro eventi DFSR verrà visualizzato l’ID evento 4114 che indica che la replica sysvol non viene più eseguita.
Sul DN non autorevole, impostare msDFSR-Enabled=TRUE.
Forzare la replica di Active Directory in tutto il dominio.
Eseguire il seguente comando da un prompt dei comandi con privilegi elevati sugli stessi server impostati come non autorevoli:
DFSRDIAG POLLADNel registro eventi DFSR verranno visualizzati gli ID evento 4614 e 4604 che indicano che la replica sysvol è stata inizializzata.
Come forzare una sincronizzazione autorevole della replica sysvol con replica DFSR
Impostare il tipo di avvio del servizio Replica DFS su Manuale e arrestare il servizio su tutti i controller di dominio nel dominio.
Nello strumento ADSIEDIT.MSC, modificare il seguente DN e due attributi del controller di dominio che si desidera rendere autorevole (preferibilmente l’emulatore PDC, che di solito è il più aggiornato per i contenuti di replica sysvol):
CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=u0026lt;the server nameu003e,OU=Domain Controllers,DC=u0026lt;domainu003ennmsDFSR-Enabled=FALSEnmsDFSR-options=1Modificare il seguente DN e il singolo attributo su tutti gli altri controller di dominio del dominio:
CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=u003ceach other server nameu003e,OU=Domain Controllers,DC=u003cdomainu003e nnmsDFSR-Enabled=FALSEForzare la replica di Active Directory in tutto il dominio e confermare il successo su tutti i controller di dominio.
In seguito avviare il servizio DFSR sul controller di dominio impostato come autorevole.
Nel registro eventi DFSR verrà visualizzato l’ID evento 4114 che indica che la replica sysvol non viene più eseguita.
Sempre sul DN impostato come autorevole, impostare msDFSR-Enabled=TRUE.
Forzare la replica di Active Directory in tutto il dominio e confermare il successo su tutti i controller di dominio.
Eseguire il seguente comando da un prompt dei comandi con privilegi elevati sullo stesso server impostato come autorevole:
DFSRDIAG POLLADNel registro eventi DFSR verrà visualizzato l’ID evento 4602, che indica che la replica sysvol è stata inizializzata.
Avviare il servizio DFSR negli altri controller di dominio non autorevoli. Nel registro eventi DFSR dei controller di dominio non autorevoli verrà visualizzato l’ID evento 4114 che indica che la replica sysvol non viene più eseguita su ciascuno di essi.
Modificare il seguente DN e il singolo attributo su tutti i controller di dominio non autorevoli:
CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=u0026lt;each other server nameu003e,OU=Domain Controllers,DC=u0026lt;domainu003e nnmsDFSR-Enabled=TRUEEseguire il seguente comando da un prompt dei comandi con privilegi elevati su tutti i controller di dominio non autorevoli:
DFSRDIAG POLLADRiportare il servizio DFSR al suo tipo di avvio originale (Automatico) in tutti i controller di dominio autorevoli e non autorevoli.
FAQ – Domande Frequenti
Qual è la differenza principale tra sincronizzazione autorevole e non autorevole?
La sincronizzazione autorevole forza la sovrascrittura degli oggetti nella directory di destinazione, anche se sono stati modificati dopo l’ultima replica. Quella non autorevole invece applica solo le modifiche mancanti, preservando le modifiche più recenti nella directory di destinazione.
Quando dovrei usare una sincronizzazione autorevole?
È utile in scenari di ripristino di emergenza, migrazione di dati critici, o quando si è certi che i dati nel server di origine siano quelli corretti e debbano sovrascrivere eventuali modifiche locali.
La sincronizzazione non autorevole può causare perdita di dati?
No, poiché replica solo le modifiche mancanti senza sovrascrivere oggetti aggiornati nella destinazione. Tuttavia, potrebbe lasciare inconsistenze se oggetti identici hanno subito modifiche diverse nei due server.
Come posso verificare lo stato della sincronizzazione dopo l’operazione?
Usa il comando repadmin /showrepl o controlla i log nell’Event Viewer sotto Applications and Services Logs > Directory Service.
È possibile annullare una sincronizzazione autorevole?
No, una volta eseguita, le modifiche sono permanenti. Si consiglia un backup preliminare (snapshot o ntdsutil) prima di procedere.
Altre info utili
Se si imposta il contrassegno autorevole in un controller di dominio, è necessario sincronizzare in modo non autorevole tutti gli altri controller di dominio presenti nel dominio.
In caso contrario, verranno visualizzati conflitti nei controller di dominio, originati da qualsiasi controller di dominio in cui non è stata impostata l’autenticazione/non autenticazione e il servizio DFSR è stato riavviato. Ad esempio, se tutti gli script di accesso sono stati eliminati accidentalmente e una copia manuale di essi è stata inserita di nuovo nel titolare del ruolo dell’emulatore PDC, rendendo il server autorevole e tutti gli altri server non autorevoli garantirebbe le operazioni riuscite e impedirebbe i conflitti.
Se si rende autorevole un controller di dominio, è preferibile impostare l’emulatore PDC come autorevole, poiché il contenuto della replica SysVol in genere è più aggiornato.
L’utilizzo del contrassegno autorevole è necessario solo per forzare la sincronizzazione di tutti i controller di dominio. Se si ripristina solo un controller di dominio, è necessario renderlo non autorevole e non toccare gli altri server.
In questo articolo si tiene conto di un ambiente con 2 controller di dominio per pura semplicità di descrizione. Nel caso in cui nel dominio fossero presenti più controller di dominio interessati, espandere i passaggi per includerli tutti.
Si presuppone inoltre che sia possibile ripristinare eventuali dati eliminati, sovrascritti, danneggiati, ecc. nel caso in cui si tratti di uno scenario di ripristino di emergenza su tutti i controller di dominio nel dominio.
📬 Iscriviti alla nostra newsletter per rimanere aggiornato con le ultime novità e guide pratiche sul mondo dell’informatica! Non perdere nessun aggiornamento importante!
💬 Hai domande o bisogno di chiarimenti? Lascia un commento qui sotto e saremo felici di aiutarti!
Commenta per primo