Importanza di Sysvol e netlogon condividi in Active Directory

Sysvol e netlogon condividi importanza in Active Directory

> Che cosa è sysvol e contenuti che include.
Sysvol è un componente importante di Active Directory. La cartella Sysvol è condivisa su un volume NTFS su tutti i controller di dominio in un determinato dominio. Sysvol viene utilizzato per fornire i criteri e gli script di accesso ai membri del dominio.

Per impostazione predefinita sysvol include 2 cartelle
1.Politiche – (Posizione predefinita- % SystemRoot% \ Sysvol \ Sysvol \ nome_dominio \ Politiche)
2.Scripts – (Default lcation – % SystemRoot% \ Sysvol \ Sysvol \ domain_name\Scripts)

Nota-Possiamo andare avanti e cambiare queste posizioni predefinite.

> Imprtance della quota Sysvol.
Sysvol contiene 2 cartelle, ovvero Criteri e script.

Criteri-Nella cartella Criteri esistono tutti i criteri di gruppo definiti in un dominio particluar. Consultare lo screenshot

Nota che puoi vedere che 3 GPT sono disponibili nello screenshot qui sopra. Quando si creano nuovi criteri di gruppo in Active directory, viene creato un set di cartelle nella cartella Criteri.
Per esempio-Sto creando una politica chiamata disabilita screen saver nel mio dominio e collegando tale politica al mio OU. Quando premo il pulsante Crea nuova politica in GPMC, creerà una cartella Nome GUID nella cartella Politiche che verrà associata per disabilitare screen saver GPO.

Per rendere questo semplice , Sopra la schermata ha 3 GPT che significano che 3 criteri di gruppo sono presenti nel test.dominio tld.
Quindi, quando si apportano modifiche a particolari oggetti Criteri di gruppo, le modifiche verranno eseguite nella cartella del nome GUID Assocaited in Sysvol.
Conclusione

L’importanza della cartella Sysvol è che contiene il GPT e ogni volta che un amministratore apporta modifiche a una qualsiasi delle politiche , le modifiche verranno impegnate nella cartella del nome GUID associato e quindi verranno replicate a tutti i controller di dominio.

> Metodi di replica Sysvol.
Sysvol può essere replicato a tutti i controller di dominio utilizzando Distributed File System Replication (DFS-R) se il livello funzionale del dominio Questo collegamento è esterno a TechNet Wiki. Si aprirà in una nuova finestra. è Windows Server 2008 o superiore, oppure viene replicato utilizzando File Replication System (FRS).
Per FRS, la pianificazione SYSVOL è un attributo associato a ciascun oggetto NTFRS Replica Set e a ciascun oggetto di connessione NTDS. FRS replica SYSVOL utilizzando gli stessi oggetti di connessione intrasite e pianificazione creati dal KCC per la replica di Active Directory. FRS utilizza due protocolli di replica per SYSVOL:
Connessione SYSVOL all’interno di un sito. La connessione è sempre considerata attiva; qualsiasi pianificazione viene ignorata e i file modificati vengono replicati immediatamente.

Collegamento SYSVOL tra siti. La replica di SYSVOL viene avviata tra due membri intersiti all’inizio dell’intervallo di 15 minuti, supponendo che la pianificazione sia aperta. La connessione viene trattata come una pianificazione di trigger. Il partner upstream ignora la sua pianificazione e risponde a qualsiasi richiesta del partner downstream. Quando la pianificazione si chiude, il partner upstream annulla la connessione solo dopo che i contenuti correnti del log in uscita, al momento del join, sono stati inviati e riconosciuti.

> Errore e problemi sysvol comuni.

A . Mancano le condivisioni Sysvol e Netlogon.

Prendi un senario, quando aggiungi un nuovo controller di dominio al tuo dominio e vedi che non ci sono cartelle sysvol e netlogon disponibili sul controller di dominio

Nota – Netlogon Share non è una cartella denominata Netlogon Sul controller di dominio . In realtà è una cartella in cui sono memorizzati tutti gli script di accesso. Quindi , come accennato in precedenza, cartella Script sotto cartella sysvol agirà come Netlogon share ( Posizione – % SystemRoot% \ sysvol \ sysvol\ < nome DNS del dominio> \ scripts)

Questo si verifica principalmente se la replica sysvol borken. In alcuni casi , dopo aver aggiunto un nuovo controller di dominio, la replica di sysvol potrebbe richiedere del tempo.(Approssimativamente è necessario attendere alcune ore).

B. Journal Wrap Error

FRS è un sistema di replica multi-master che si occupa di replicare il contenuto di Sysvol tra tutti i DC nel dominio (può anche replicare i dati normali, ma siamo principalmente interessati alla replica di Sysvol nel blog).
Con una cura e una manutenzione adeguate, Post-SP2 FRS su W2k3 è piuttosto stabile e ronza felicemente finché non c’è una condizione esterna come un’interruzione di rete o problemi al disco che lo causano (supponendo che i dati che stai replicando non siano completamente inadatti per la replica come .File PST, dati del profilo o contenuti che cambiano frequentemente).
Il problema FRS più frequente è dove si verifica un involucro di giornale; diamo un’occhiata più da vicino a ciò che accade durante un involucro di giornale sotto il cofano.
Il modo in cui FRS funziona è che ha un database interno che contiene tutti i file e le cartelle che sta replicando e ognuno di questi ha un ID globale univoco (GUID). Il dababase contiene anche un puntatore all’ultima operazione del disco NTFS (nel Journal USN/Journal NTFS) elaborata dal servizio FRS.

Se un utente modifica un file o una cartella su un disco, si verifica quanto segue:
1) l’operazione viene rilevata da NTFS e viene effettuata una voce nel Journal NTFS.
2) FRS monitora il Journal NTFS per le modifiche e nota che è stata apportata una modifica a quel file.
3) FRS mantiene un record dell’ultimo evento NTFS Journal che ha elaborato e controlla se lo ha già elaborato.
4) Se non lo ha già elaborato, esamina se si tratta di un file che dovrebbe replicare.
5) Se deve essere replicato, il file entra nel normale processo di staging, replica, ecc.
6) FRS incrementa la voce nel suo database sull’evento NTFS Journal che ha elaborato in modo che non lo consideri di nuovo.

Ora simplify semplifichiamo un po ‘ le cose.
– Il nostro disco contiene un file e una cartella (e:\Test e prova.txt).
– Il nostro journal NTFS ha una dimensione di 10 voci(la dimensione predefinita del journal NTFS in RL è ~512 Mb a seconda del livello OS / SP).
– Il nostro database FRS contiene tre voci
– > un GUID per E:\test
– > un GUID per E:\test\test.txt
-> Un rinvio all’ultima voce del diario NTFS che abbiamo elaborato (diciamo #4)

Operazioni normali:
– > Qualcuno apporta una modifica al test.txt.
– > Il Journal NTFS viene aggiornato al numero 5.
– > FRS nota che il giornale NTFS dice che è stata apportata una modifica al test.txt e vede che non ha elaborato quel cambiamento.
– >Stage / Replicare e aggiornare il database FRS per riflettere che abbiamo elaborato quella voce di diario NTFS.

Ora, un amministratore interrompe il servizio FRS per 30 minuti.
– Qualcuno apporta 10 modifiche al test.txt
o Il journal NTFS viene aggiornato 20 volte ed è ora al numero 24(ricorda che abbiamo un limite di dimensione del registro delle ultime 10 voci, quindi è necessario avvolgerlo).
o FRS viene arrestato in modo che non stia monitorando il registro del Journal NTFS.

A questo punto, abbiamo modifiche sul disco di cui FRS non è a conoscenza. FRS conosce ancora l’ultima voce di diario NTFS che ha elaborato e la confronterà con la rivista NTFS corrente al successivo riavvio.
La prossima volta che il servizio FRS si avvia, vede che ha perso le operazioni NTFS sul disco (ha elaborato l’ultima operazione NTFS #4 ma il Journal NTFS è ora al #24 e abbiamo solo un registro che risale a 10 voci quindi mancano le operazioni #5-#14 dal database.
Questo è quando FRS si lamenta di aver raggiunto uno stato di avvolgimento del journal, il registro del Journal NTFS si è avvolto e non conosce lo stato corrente delle cose sul disco.
L’impatto di ciò su un DC interessato è che FRS non imposterà la chiave di registro IsSysvolReady per indicare al servizio Netlogon che tutto va bene, Sysvol non verrà quindi condiviso e il DC non sarà in grado di autenticare completamente gli utenti fino a quando la condizione di Wrap del Journal non sarà stata risolta.
La condivisione manuale di Sysvol o l’impostazione della chiave di registro IsSysvolReady su 1 non sono metodi validi per risolvere questo problema e non risolvono il problema reale.
Affinché FRS possa recuperare da un wrap Journal, dovrai fondamentalmente ricominciare da zero e ripristinare il database FRS e iniziare a contare il Journal NTFS dai valori correnti che ha.

Ciò significa:
– Replica nei dati da un partner in entrata esistente (l’approccio di ripristino FRS d2 o non autorevole).
– Rendere i propri dati autorevoli e lasciare che tutti gli altri replicare da voi (il d4 o autorevole FRS restore approccio).

L’approccio d2 è abbastanza semplice da eseguire, i requisiti sono tuttavia che hai una buona connessione di rete con il partner di replica in entrata e il tempo che ci vorrà dipende dalla quantità di dati da replicare rispetto alla capacità del collegamento
D’altra parte, questo potrebbe non essere sempre sufficiente e puoi trovarti costretto ad andare con l’opzione d4.

Sopra sono gli errori più comuni quando si considera sysvol in Active Directory.

Infine quali sono i passi che possiamo seguire quando questi errori sopra sono encouted.

> Risoluzione dei messaggi di errore Sysvol

A . Mancano le condivisioni Sysvol e Netlogon.

Come ho detto prima potrebbe essere un problema con la replica di sysvol interrotta tra i controller di dominio.

Come posso forzare la replica Sysvol in una active directory

È possibile riavviare il servizio FRS per forzare la replica FRS

Per riavviare il servizio FRS, avviare i servizi.msc dall’opzione Esegui nel menu Start
E riavvia il servizio FRS e otterrai l’ID evento 13516 sul registro eventi FRS questo assicurerà che lo stato FRS sia corretto.

la replica di Sysvol attraverso NTFRSUTL

Se si desidera forzare la replica di sysvol tra due controller di dominio active directory, quindi, utilizzare la procedura riportata di seguito

NTFRSUTL FORCEREPL-Line Opzione per Forzare la Replica

È possibile utilizzare il nuovo ntfrsutl forcerepl per imporre la replica indipendentemente dalla pianificazione di replica predefiniti. Questo è implementato solo per il controller di dominio Sysvol replica set.

ntfrsutl forcerepl /r /p

Questo comando costringe FRS ad avviare un ciclo di replica. È necessario specificare il Computer, SetName e DnsName.

Nota In questo comando vengono utilizzati i seguenti segnaposto:
= Connessione con il servizio NtFrs su questa macchina.
= Il nome del set di repliche.
= Il nome DNS del partner in entrata da cui forzare la replica.

Ad esempio:

ntfrsutl.exe forcerepl DestinationDC /r “Volume del sistema di dominio (condivisione SYSVOL)” / p SourceDC.domain.com

Le virgolette in questo esempio sono necessarie quando si utilizza l’opzione /r. Se le virgolette non sono presenti, il comando non funzionerà.

Se sopra non aiuta,

Il metodo più popolare per risolvere questo problema è sotto MS KB.

SINTOMI:

Dopo aver installato Active Directory Domain Services su un nuovo controller di dominio basato su Windows Server 2008 completo o di sola lettura in un dominio esistente, è presente la condivisione SYSVOL. Tuttavia, la condivisione NETLOGON non è presente sul nuovo controller di dominio.

Nota Questo articolo non si applica se mancano entrambe le condivisioni NETLOGON e SYSVOL.

CAUSA:

Questo problema si verifica quando il servizio Netlogon legge il flag SysvolReady nel registro molto rapidamente. Quindi, il servizio Netlogon tenta di condividere la cartella\Windows \ SYSVOL \ domain \ scripts prima che il servizio di replica file NT (NTFRS) crei questa cartella.

SOLUZIONE:

Attenzione Se si modifica il registro di sistema in modo errato utilizzando l’Editor del Registro di sistema o utilizzando un altro metodo, potrebbero verificarsi gravi problemi. Questi problemi potrebbero richiedere la reinstallazione del sistema operativo. Microsoft non può garantire che questi problemi possano essere risolti. Modificare il registro a proprio rischio.

Per risolvere questo problema, impostare il valore del registro di flag SysvolReady su “0” e quindi su “1” nel registro. Per fare ciò, attenersi alla seguente procedura:
->Fare clic su Start, fare clic su Esegui, digitare regedit e quindi fare clic su OK.
->Individuare la seguente sottochiave nell’Editor del Registro di sistema:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
– >Nel riquadro dettagli, fare clic con il pulsante destro del mouse sul flag SysvolReady, quindi fare clic su Modifica.
– >Nella casella Dati valore, digitare 0, quindi fare clic su OK.
– >Di nuovo nel riquadro dettagli, fare clic con il pulsante destro del mouse sul flag SysvolReady, quindi fare clic su Modifica.
– >Nella casella Dati valore, digitare 1, quindi fare clic su OK.
Nota Questo farà sì che Netlogon condivida SYSVOL e sarà presente la cartella scripts.

ULTERIORI INFORMAZIONI:

Il problema descritto nella sezione “Sintomi” si verifica nel seguente scenario:
NTFRS prima inserisce le modifiche nella seguente posizione:
\Windows\SYSVOL\domain \ DO_NOT_REMOVE_NtFrs_PreInstall_Directory
Quindi, NTFRS notifica a Netlogon di condividere SYSVOL impostando la voce di registro del flag SYSVOL su “1.”
NTFRS sposta e rinomina i file dalla posizione menzionata nel passaggio 1 alla seguente cartella:
\Windows \ SYSVOL \ domain
Tuttavia, se il servizio Netlogon legge molto rapidamente la voce del flag SysvolReady nel registro di sistema, il servizio Netlogon tenta di condividere la cartella \Windows\SYSVOL\domain\scripts prima che NTFRS crei questa cartella. Pertanto, la condivisione NETLOGON non viene creata.

B . Journal Wrap Error
Se si verifica un errore Journal wrap, possiamo impostare un valore blurflag su D2 nel registro di sistema su un controller di dominio in cui vengono generati eventi di errore Journal wrap. In questo modo il controller di dominio scaricherà le cartelle preesistenti e inizierà a replicare nuovi contenuti da uno dei suoi partner di replica FRS.

O

Possiamo impostare blurflag su D4 che fa esattamente l’opposto di sopra . Che è , quando si imposta D4 su un perticular controller di dominio suoi dati potranno agire come Autorevole , Risultato, tutti i controller di dominio nel dominio replicherà dal controller di Dominio in cui questo blurflag è impostato su D4

Nota – Impostazione BlurFlag a D4 è l’ultima opzione , il 90% dei casi sarà risolto impostando blurflag a D2.

Articoli PUBBLICITARI FAQ di Windows

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.