Come risolvere i problemi relativi alle condivisioni SYSVOL e Netlogon mancanti

In questo articolo viene illustrata la procedura per risolvere i problemi relativi alle condivisioni e mancanti SYSVOL Netlogon 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 seguenti sintomi o condizioni:

  • La sysvol cartella è vuota.
  • Il controller di dominio interessato è stato alzato di livello di recente.
  • L'ambiente contiene controller di dominio che eseguono versioni Windows precedenti a Windows Server 2012 R2.
  • Replica DFS viene utilizzato per replicare la SYSVOL cartella replicata di condivisione.
  • Il servizio Replica DFS di un controller di dominio upstream si trova in uno stato di errore.

Causa

I controller di dominio senza condivisi non possono replicare in ingresso perché i controller di dominio SYSVOL upstream (di origine) sono in uno stato di errore. Spesso (ma non solo a), i server upstream hanno interrotto la replica a causa di un arresto dirty (ID evento 2213).

Risoluzione

In questa sezione sono contenuti i metodi consigliati per la risoluzione dei problemi e la risoluzione delle condivisioni mancanti nei controller di dominio replicati utilizzando SYSVOL Netlogon il servizio Replica DFS.

Il processo reinizializza Replica DFS se non è condiviso nei controller di dominio in base a Come forzare una sincronizzazione autorevole o non autorevole per SYSVOL replicato da SYSVOL DFSR (come "D4/D2" per FRS). Nella maggior parte dei casi non è necessario e può causare la perdita di dati se eseguita in modo non corretto. 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 una singola occorrenza o se i controller di dominio upstream non sono in grado di supportare la replica tramite Replica DFS.

L'eliminazione del database di Replica DFS dal volume non deve essere necessaria ed è sconsigliata. Fa sì che Replica DFS consideri non autorevoli tutti i dati locali nel server. Consentendo a Replica DFS di ripristinare il database normalmente (come indicato nell'evento 2213), l'ultimo writer continuerà a vincere 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 , hanno registrato di recente un evento Error e quanti controller di dominio sono SYSVOL in uno stato di errore. Seguire questa procedura.

  • Verificare la SYSVOL condivisione

    È possibile verificare manualmente se è condiviso o controllare ogni controller di SYSVOL dominio utilizzando 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 una query su WMI. È possibile eseguire una query su tutti i controller di dominio nel dominio per la cartella replicata di SYSVOL condivisione utilizzando WMI come segue:

    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:
    0 = Non inizializzato
    1 = Inizializzato
    2 = Sincronizzazione iniziale
    3 = Ripristino automatico
    4 = Normale
    5 = In errore

    Nota

    A seconda delle condizioni di un controller di dominio, potrebbe non essere possibile segnalare un valore di stato e indicare nessuna istanza disponibile.

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

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

  • Controllare la configurazione di Freshness del contenuto

    Determinare se Replica DFS ha attivato la protezione della disponibilità del contenuto nei controller di dominio interessati. L'opzione Content Freshness è abilitata Windows Server 2012 controller di dominio (e versioni successive) per impostazione predefinita. Tuttavia, può anche essere abilitato manualmente nei Windows Server 2008 R2.

    Per valutare se l'freshness del contenuto è abilitato, MaxOfflineTimeInDays l'impostazione verrà impostata su 60. Se l'freshness 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 una 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 interrotta perché la replica non è riuscita più a lungo del MaxOfflineTimeInDays parametro.

Passaggio 2 - Preparare i controller di dominio in uno stato di errore

  • Installare gli aggiornamenti appropriati

    Per tutti i controller di dominio che eseguono Windows Server 2008 R2, installare innanzitutto gli aggiornamenti di Replica DFS per evitare la perdita di dati e risolvere i problemi noti. È consigliabile utilizzare 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 SYSVOL dei dati

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

    A seconda della situazione, i file dei criteri potrebbero essere spostati in PreExisting o Conflict ed Deleted. I contenuti PreExisting e Conflict e Deleted verranno eliminati se la sincronizzazione iniziale viene eseguita più volte in un server. Eseguire il backup dei dati in queste posizioni per evitare perdite di dati.

Passaggio 3 - Ripristino di 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 ambienti con due controller di dominio

Determinare se è stato rilevato un arresto dirty (ID evento 2213) in uno dei controller di dominio. È possibile che il secondo controller di dominio sia in attesa di completare l'inizializzazione di SYSVOL . Il motivo è che, dopo la promozione, registra 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'freshness 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'evento anti-evento 4604), seguire l'articolo How to force an authoritative and non-authoritative synchronization for DFSR-replicated SYSVOL (like "D4/D2" for FRS) per impostare il primo controller di dominio come autorevole. Non è necessario configurare il secondo controller di dominio come non autorevole, perché è già in attesa di eseguire la sincronizzazione iniziale.

    In caso contrario, se il secondo controller di dominio è integro e SYSVOL condiviso, eseguire la procedura seguente:

    1. Eseguire il backup SYSVOL di tutto il contenuto 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 nel secondo controller di SYSVOL dominio dal primo controller di dominio. In caso contrario, tutti i dati esistenti presenti nel primo controller di dominio non presenti nel secondo verranno eliminati nelle cartelle PreExisting e Conflict ed Deleted.

    3. Impostare il primo controller di dominio come non autorevole 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 sia registrato un ID evento 4114 per indicare che l'appartenenza è disabilitata.

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

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

    Se il primo controller di dominio si trova nello stato ID evento 2213 e il secondo controller di dominio non ha mai completato l'inizializzazione dopo la promozione e l'aggiornamento del contenuto non è stato attivato. Eseguire la procedura seguente:

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

    2. Dopo la ripresa della replica, verrà logato un ID evento 4602 che indica che Replica DFS ha inizializzato la cartella replicata e l'ha specificata come SYSVOL 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, la segnalazione SYSVOL ha completato l'inizializzazione.

    In caso contrario, se il primo controller di dominio si trova nello stato 2213 e il secondo controller di dominio è integro ( è condiviso), eseguire il metodo WMI sul SYSVOL ResumeReplication primo controller di dominio. Verrà logato l'ID evento 2214 al completamento del ripristino dell'arresto dirty.

Per ambienti con tre o più controller di dominio

Determinare se è stato rilevato un arresto dirty e se Replica DFS è sospesa in qualsiasi controller di dominio (ID evento 2213). È possibile che un controller di dominio sia in attesa di completare l'inizializzazione dopo SYSVOL la promozione. Verrà logato 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'freshness del contenuto è abilitato e sono presenti tre o più controller di dominio nel dominio.

    La protezione aggiornamento contenuto registra un ID evento 4012 che indica che la replica è stata interrotta perché la replica nella cartella non è riuscita per più tempo del MaxOfflineTimeInDays parametro. Per reinizializzare Replica DFS nei controller di dominio interessati, seguire le istruzioni in How to force an authoritative and non-authoritative synchronization for DFSR-replicated SYSVOL (like "D4/D2" for 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 (come "D4/D2" per FRS) per inizializzare completamente SYSVOL . È l'unica situazione per impostare un server Replica DFS come autorevole. Verificare che il controller di dominio configurato come autorevole abbia la copia più aggiornata di tutti i SYSVOL contenuti.

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

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

    2. Impostare i controller di dominio come non autorevoli disabilitando l'appartenenza, come descritto in How to force an authoritative and non-authoritative synchronization for DFSR-replicated SYSVOL (like "D4/D2" for FRS). È necessario conoscere la topologia di replica ed è necessario uscire da un controller di dominio integro selezionando i partner diretti, quindi ripristinando altri controller di dominio downstream e così via. Verrà registrato l'ID evento 4144 per confermare che l'appartenenza è disabilitata. Assicurarsi che tutti i controller di dominio che richiedono il ripristino registrino l'evento. Potrebbe essere necessario forzare la replica di Active Directory ed eseguire il comando su ogni controller di dominio per rilevare rapidamente dfsrdiag pollad l'appartenenza disabilitata.

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

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

    Se la protezione dell'freshness del contenuto non viene attivata, eseguire il metodo ResumeReplication WMI nei controller di dominio interessati. È necessario conoscere la topologia di replica ed è necessario uscire da un controller di dominio integro selezionando i partner diretti, quindi ripristinando altri controller di dominio downstream e così via. Dopo la ripresa della replica, Replica DFS registra gli eventi 2212, 2218 e 2214 (a indicare che Replica DFS ha inizializzato la cartella SYSVOL replicata).

Prevenzione delle occorrenze future del problema

Verificare se i registri eventi applicazioni e di sistema segnalano spesso operazioni di ripristino del database ESENT, problemi di prestazioni del disco o entrambi. I registri eventi in genere coincidono con arresti imprevisti del sistema, con l'arresto non corretto di Replica DFS 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 ulteriori indagini. È inoltre possibile contattare il Servizio Supporto Tecnico Clienti Microsoft per valutare l'integrità del sistema e il comportamento di Replica DFS.

Gestione controllo servizi utilizza il tempo di timeout predefinito di 20 secondi per l'arresto di un servizio. In alcune implementazioni complesse di Replica DFS, questo valore di timeout potrebbe essere troppo breve e Replica DFS si interrompe 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 utilizzato per concedere a Replica DFS più tempo per il commit delle modifiche al database durante l'arresto. Per ulteriori informazioni, vedere l'articolo Si riceve l'ID evento DFSR 2212 dopoil riavvio del servizio DFSR.

Dopo aver ripristinato Replica DFS di , è necessario monitorare attentamente l'integrità di Replica DFS nell'ambiente per SYSVOL evitare questo scenario. È consigliabile esaminare regolarmente i registri eventi di Replica DFS, raccogliere i rapporti di integrità di Replica DFSe raccogliere lo stato della replica (utilizzando la query WMI nella sezione Verifica stato replica DFS in Passaggio 1 - Valutare lo stato di Replica DFS in tutti i controller di dominio).