Come risolvere i problemi relativi alle condivisioni SYSVOL e Netlogon mancanti

  • Articolo

Questo articolo illustra la procedura per risolvere i problemi relativi alle condivisioni e Netlogon mancanti SYSVOL in Windows Server 2012 R2.

Si applica a: Windows Server 2012 R2, Windows Server 2008 R2 Service Pack 1
Numero KB originale: 2958414

Sintomi

SYSVOL e Netlogon le condivisioni non vengono condivise in un controller di dominio. Possono verificarsi anche i sintomi o le condizioni seguenti:

  • La sysvol cartella è vuota.
  • Il controller di dominio interessato è stato recentemente promosso.
  • L'ambiente contiene controller di dominio che eseguono versioni di Windows precedenti a Windows Server 2012 R2.
  • Replica DFS viene usata per replicare la SYSVOL cartella Share replicata.
  • Il servizio Replica DFS di un controller di dominio upstream è in stato di errore.

Causa

I controller di dominio senza SYSVOL condivisione non possono eseguire la replica in ingresso a causa dello stato di errore dei controller di dominio upstream (origine). Spesso , ma non solo, i server upstream hanno arrestato la replica a causa di un arresto dirty (ID evento 2213).

Risoluzione

Questa sezione contiene i metodi consigliati per la risoluzione dei problemi e la risoluzione delle condivisioni e Netlogon mancanti SYSVOL nei controller di dominio replicati tramite il servizio Replica DFS.

Il processo reinizializza Replica DFS se SYSVOL non viene condiviso nei controller di dominio in base a Come forzare una sincronizzazione autorevole o non autorevole per SYSVOL replicato da DFSR (ad esempio "D4/D2" per FRS). Non è necessario nella maggior parte dei casi e può causare la perdita di dati se eseguita in modo errato. Inoltre, impedisce di determinare la causa del problema e di evitare occorrenze future del problema.

Di seguito sono riportati i passaggi generali per analizzare le condivisioni mancanti. Determinare se il problema è causato da un'occorrenza occasionale o se i controller di dominio upstream non possono supportare la replica tramite Replica DFS.

L'eliminazione del database di Replica DFS dal volume non deve essere necessaria ed è sconsigliata. Replica DFS considera tutti i dati locali nel server come non autorizzati. Consentendo a Replica DFS di ripristinare correttamente il database (come indicato nell'evento 2213), l'ultimo writer vincerà comunque tutte le versioni in conflitto dei SYSVOL dati.

Passaggio 1: Valutare lo stato di Replica DFS in tutti i controller di dominio

Valutare quanti controller di dominio non condividono SYSVOL, hanno registrato di recente un evento Error e quanti controller di dominio si trovano in uno stato di errore. Seguire questa procedura.

  • Verificare la SYSVOL condivisione

    È possibile controllare manualmente se SYSVOL è condiviso o controllare ogni controller di dominio usando il comando net view:

    For /f %i IN ('dsquery server -o rdn') do @echo %i && @(net view \\%i | find "SYSVOL") & echo

  • Controllare lo stato di Replica DFS

    Per controllare lo stato di Replica DFS nei controller di dominio, è possibile eseguire query su WMI. È possibile eseguire query su tutti i controller di dominio nel dominio per la SYSVOL cartella Condividi replicata usando WMI come indicato di seguito:

    For /f %i IN ('dsquery server -o rdn') do @echo %i && @wmic /node:"%i" /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo WHERE replicatedfoldername='SYSVOL share' get replicationgroupname,replicatedfoldername,state

    I state valori possono essere uno qualsiasi dei seguenti:
    0 = Non inizializzato
    1 = Inizializzato
    2 = Sincronizzazione iniziale
    3 = Ripristino automatico
    4 = Normale
    5 = In Errore

    Nota

    A seconda della condizione di un controller di dominio, potrebbe non riuscire a segnalare un valore di stato e indicare che non sono disponibili istanze.

  • Controllare la presenza di errori o avvisi recenti nei log eventi

    Se i controller di dominio non segnalano che la SYSVOL cartella Condivisione replicata è in uno stato 4 (normale), controllare il registro eventi di tali controller di dominio per valutarne la condizione. Esaminare ogni controller di dominio per individuare errori o avvisi recenti nel registro eventi di Replica DFS, ad esempio l'ID evento di avviso 2213 che indica che Replica DFS è attualmente in pausa.

  • Controllare la configurazione di Aggiornamento contenuto

    Determinare se replica DFS ha attivato la protezione della freschezza del contenuto nei controller di dominio interessati. Aggiornamento contenuto è abilitato nei controller di dominio Windows Server 2012 (e versioni successive) per impostazione predefinita. Tuttavia, può anche essere abilitato manualmente nei server Windows Server 2008 R2.

    Per valutare se l'aggiornamento del contenuto è abilitato, l'impostazione MaxOfflineTimeInDays verrà impostata su 60. Se l'aggiornamento del contenuto è disabilitato, MaxOfflineTimeInDays verrà impostato su 0. Per controllare MaxOfflineTimeInDays, eseguire il comando seguente:

    wmic.exe /node:%computername% /namespace:\\root\microsoftdfs path DfsrMachineConfig get MaxOfflineTimeInDays

    Per eseguire query su tutti i controller di dominio nel dominio, eseguire il comando seguente:

    For /f %i IN ('dsquery server -o rdn') do @echo %i && @wmic /node:"%i" /namespace:\\root\microsoftdfs path DfsrMachineConfig get MaxOfflineTimeInDays

    Per ogni controller di dominio abilitato per l'aggiornamento del contenuto, valutare se Replica DFS ha registrato un ID evento 4012 che indica che la replica della cartella è stata arrestata perché la replica non è riuscita più a lungo del MaxOfflineTimeInDays parametro .

Passaggio 2: Preparare i controller di dominio in stato di errore

  • Installare gli aggiornamenti appropriati

    Per tutti i controller di dominio che eseguono Windows Server 2008 R2, installare prima gli aggiornamenti di Replica DFS per evitare la perdita di dati e risolvere i problemi noti. È consigliabile usare la versione più recente di Replica DFS. Vedere Elenco degli hotfix attualmente disponibili per le tecnologie DFS (Distributed File System) per la versione più recente di Replica DFS.

  • Eseguire il backup dei SYSVOL dati

    Eseguire un backup dei SYSVOL dati (se presente) in ogni controller di dominio. I backup possono essere una copia file del contenuto in un percorso sicuro o, potrebbe essere un backup che usa il SYSVOL software di backup.

    A seconda della situazione, è possibile spostare i file dei criteri in PreExisting o Conflict e Deleted. Se la sincronizzazione iniziale viene eseguita più volte in un server, i contenuti preesistentie in conflitto ed eliminati verranno eliminati. Eseguire il backup dei dati in queste posizioni per evitare la perdita di dati.

Passaggio 3: Ripristinare Replica DFS nei controller di dominio nello stato di errore

In base al numero di controller di dominio nel dominio, selezionare il metodo appropriato per ripristinare il servizio Replica DFS.

Per gli ambienti con due controller di dominio

Determinare se è stato rilevato un arresto dirty (ID evento 2213) in entrambi i controller di dominio. È possibile che il secondo controller di dominio sia in attesa di completare l'inizializzazione di SYSVOL. Il motivo è che, dopo l'innalzamento di livello, registrerà un evento 4614 che indica che Replica DFS è in attesa di eseguire la replica iniziale. Inoltre, non registra un evento 4604 che segnala che Replica DFS ha inizializzato SYSVOL.

  • Se l'aggiornamento del contenuto è abilitato in entrambi i controller di dominio

    Se il secondo controller di dominio attende di eseguire la sincronizzazione iniziale (evento 4614 registrato senza l'anti-evento 4604), seguire come forzare una sincronizzazione autorevole e non autorevole per SYSVOL replicato da DFSR (ad esempio "D4/D2" per FRS) per impostare il primo controller di dominio come autorevole. Non è necessario configurare il secondo controller di dominio come non autorizzato, perché è già in attesa di eseguire la sincronizzazione iniziale.

    In alternativa, se il secondo controller di dominio è integro ed SYSVOL è condiviso, seguire questa procedura:

    1. Eseguire il backup di tutti i SYSVOL contenuti del primo controller di dominio.

    2. Valutare se i dati del secondo controller di SYSVOL dominio sono aggiornati. In caso contrario, è possibile copiare i file aggiornati SYSVOL nel secondo controller di dominio dal primo controller di dominio. In caso contrario, tutti i dati esistenti presenti nel primo controller di dominio non presenti nel secondo andranno nelle cartelle PreExisting e Conflict and Deleted .

    3. Impostare il primo controller di dominio come non autorizzato disabilitando l'appartenenza per Come forzare una sincronizzazione autorevole e non autorevole per SYSVOL replicato da DFSR (ad esempio "D4/D2" per FRS). Verificare che venga registrato un ID evento 4114 per indicare che l'appartenenza è disabilitata.

    4. Abilitare l'appartenenza del primo controller di dominio e attendere gli eventi 4614 e 4604 che segnalano il completamento della sincronizzazione iniziale. Se necessario, ripristinare tutti i file aggiornati da PreExisting al percorso originale.

  • Se l'aggiornamento del contenuto non è abilitato o attivato in entrambi i controller di dominio

    Se il primo controller di dominio è nello stato id evento 2213 e il secondo controller di dominio non ha mai completato l'inizializzazione dopo che è stato promosso e la freschezza del contenuto non è stata attivata. Seguire questa procedura:

    1. Eseguire il ResumeReplication metodo WMI nel primo controller di dominio come indicato nell'evento 2213.

    2. Dopo la ripresa della replica, verrà registrato un ID evento 4602 che indica che Replica DFS ha inizializzato la SYSVOL cartella replicata e l'ha specificata come membro primario.

    3. Eseguire il dfsrdiag pollad comando nel secondo controller di dominio per attivarlo per completare la sincronizzazione iniziale (ID evento 4614). Al termine della sincronizzazione iniziale, viene registrato l'ID evento 4604 e la segnalazione SYSVOL ha completato l'inizializzazione.

    In alternativa, se il primo controller di dominio è nello stato 2213 e il secondo controller di dominio è integro (SYSVOL è condiviso), eseguire il ResumeReplication metodo WMI nel primo controller di dominio. Registra l'ID evento 2214 al completamento del ripristino di arresto dirty.

Per gli ambienti con tre o più controller di dominio

Determinare se è stato rilevato un arresto dirty e se Replica DFS è in pausa in qualsiasi controller di dominio (ID evento 2213). È possibile che un controller di dominio sia in attesa di completare l'inizializzazione di dopo l'innalzamento di SYSVOL livello. Verrà registrato un evento 4614 che indica che Replica DFS è in attesa di eseguire la replica iniziale. Inoltre, non registra un evento 4604 che segnala che Replica DFS ha inizializzato SYSVOL.

  • Se l'aggiornamento del contenuto è abilitato e nel dominio sono presenti tre o più controller di dominio.

    La protezione dell'aggiornamento del contenuto registrerà un ID evento 4012 che indica che la replica è stata arrestata perché la replica nella cartella non è riuscita più a lungo del MaxOfflineTimeInDays parametro. Per reinizializzare Replica DFS nei controller di dominio interessati, seguire le istruzioni riportate in Come forzare una sincronizzazione autorevole e non autorevole per SYSVOL replicato da DFSR ,ad esempio "D4/D2" per FRS.

    Se tutti i controller di dominio hanno registrato l'evento 4012 e il relativo stato è 5, seguire le istruzioni in Come forzare una sincronizzazione autorevole e non autorevole per SYSVOL replicato da DFSR (ad esempio "D4/D2" per FRS) per inizializzare SYSVOLcompletamente . È l'unica situazione in cui impostare un server replica DFS come autorevole. Assicurarsi che il controller di dominio configurato come autorevole disponga della copia più aggiornata di tutti i SYSVOL contenuti.

    In alternativa, se uno o più controller di dominio bloccano la replica a causa dell'aggiornamento del contenuto, ognuno di essi deve essere ripristinato in modo non autorevole. attenersi alla seguente procedura:

    1. Eseguire il backup di tutti i SYSVOL contenuti dei controller di dominio. In genere, le modifiche ai criteri vengono eseguite nell'emulatore PDC, ma non sono garantite. Tutti i dati presenti nei controller di dominio ripristinati che non corrispondono ai partner verranno inseriti nella cartella PreExisting o Conflict and Deleted o in entrambi.

    2. Impostare i controller di dominio come non autorizzati disabilitando l'appartenenza, come descritto in Come forzare una sincronizzazione autorevole e non autorevole per replica dfsr SYSVOL (ad esempio "D4/D2" per FRS). È necessario essere a conoscenza della topologia di replica ed è necessario eseguire il fanout da un controller di dominio integro selezionando i partner diretti, quindi recuperando altri controller di dominio downstream e così via. L'ID evento 4144 verrà registrato per verificare che l'appartenenza sia disabilitata. Assicurarsi che tutti i controller di dominio che richiedono il log di ripristino registrino l'evento. Potrebbe essere necessario forzare la replica di Active Directory e quindi eseguire il dfsrdiag pollad comando in ogni controller di dominio per rilevare rapidamente l'appartenenza disabilitata.

    3. Abilitare l'appartenenza e attendere che gli eventi 4614 e 4604 segnalano il completamento della sincronizzazione iniziale. Ripristinare tutti i file necessari dal backup o da PreExisting e Conflict e Deleted in base alle esigenze.

  • Se l'aggiornamento del contenuto non è abilitato o attivato e sono presenti tre o più controller di dominio nel dominio

    Se la protezione dall'aggiornamento del contenuto non viene attivata, eseguire il ResumeReplication metodo WMI nei controller di dominio interessati. È necessario essere a conoscenza della topologia di replica ed è necessario eseguire il fanout da un controller di dominio integro selezionando i partner diretti, quindi recuperando altri controller di dominio downstream e così via. Dopo la ripresa della replica, Replica DFS registrerà gli eventi 2212, 2218 e quindi 2214 (indicante che Replica DFS ha inizializzato la SYSVOL cartella replicata).

Prevenzione di occorrenze future del problema

Controllare se i log eventi di sistema e applicazione segnalano spesso operazioni di ripristino del database ESENT, problemi di prestazioni del disco o entrambi. I log eventi in genere coincidono con arresti imprevisti del sistema, con replica DFS che non si arresta normalmente o errori del sottosistema del disco. Valutare la possibilità di aggiornare i driver del sistema, installare gli aggiornamenti appropriati nel sottosistema del disco o contattare il produttore dell'hardware del sistema per approfondire le indagini. È anche possibile contattare il Servizio Supporto Tecnico Clienti Microsoft per valutare l'integrità del sistema e il comportamento di Replica DFS.

Service Control Manager (SCM) usa il timeout predefinito di 20 secondi per arrestare un servizio. In alcune implementazioni complesse di Replica DFS, questo valore di timeout potrebbe essere troppo breve e Replica DFS si arresta prima della chiusura del database appropriato. Al riavvio del servizio, Replica DFS rileva questa condizione e quindi esegue il ripristino del database. WaitToKillServiceTimeout può essere usato per concedere a Replica DFS più tempo per il commit delle modifiche apportate al database durante l'arresto. Per altre informazioni, vedere l'articolo Si riceve l'ID evento DFSR 2212 dopo il riavvio del servizio DFSR.

Dopo aver ripristinato Replica DFS di , l'integrità di SYSVOLReplica DFS deve essere monitorata attentamente nell'ambiente per evitare questo scenario. È consigliabile esaminare regolarmente i log eventi di Replica DFS, raccogliere report sull'integrità di Replica DFS e raccogliere lo stato della replica usando la query WMI nella sezione Controllare lo stato di Replica DFS in Passaggio 1 - Valutare lo stato di Replica DFS in tutti i controller di dominio.