Betydelsen av Sysvol och netlogon dela i Active Directory

Sysvol och netlogon dela betydelse i Active Directory

> vad är sysvol och innehåll det innehåller.
Sysvol är en viktig komponent i Active Directory. Sysvol-mappen delas på en NTFS-volym på alla domänkontrollanter i en viss domän. Sysvol används för att leverera policyn och inloggningsskripten till domänmedlemmar.

som standard innehåller sysvol 2 mappar
1.Policyer – (standardplats – %SystemRoot%\Sysvol\Sysvol\domain_name\Policies)
2.Scripts – (standard lcation- % SystemRoot% \ Sysvol \ Sysvol\domain_name\Scripts)

Obs – Vi kan gå vidare och ändra dessa standardplatser.

> Imprtance av Sysvol aktie.
Sysvol innehåller 2 mappar, nämligen policyer och skript.

principer – under mappen principer finns alla grupppolicyer som definieras i en particluar-domän. Se skärmdumpen

Observera att du kan se 3 GPT är tillgängliga i ovanstående skärmdump. När du skapar en ny grupprincip i active directory skapas en uppsättning mapp under mappen principer.
för Eg-jag skapar en Policy som heter disable screen saver i min domän och länkar den policyn till min OU. När jag slår skapa ny policy-knapp i GPMC kommer den att skapa en GUID – namnmapp under Policies-mappen som kommer att associeras för att inaktivera skärmsläckare GPO.

för att göra detta enkelt har ovanstående skärmbild 3 GPT som betyder att 3 grupppolicyer finns i testet.tld domän.
så när du gör ändringar i vissa grupprincipobjekt som ändringar kommer att begås till Assocaited GUID namnmapp under Sysvol.
slutsats

betydelsen av SYSVOL-mappen är att den håller GPT , och när en administratör gör några ändringar i någon av policyerna , kommer ändringarna att begås till assocated GUID name-mappen och sedan kommer de att replikeras till alla domänkontrollanter.

> SYSVOL replikeringsmetoder.
Sysvol kan replikeras till alla domänkontrollanter med distribuerad Filsystemreplikation (DFS-R) om domänfunktionalitetsnivån den här länken är extern till TechNet Wiki. Det öppnas i ett nytt fönster. är Windows Server 2008 eller senare, eller det replikeras med File Replication System (FRS).
för FRS är SYSVOL-schemat ett attribut som är associerat med varje NtFrs-replika Set-objekt och med varje NTDs-anslutningsobjekt. FRS replikerar SYSVOL med samma intrasite-anslutningsobjekt och schema byggt av KCC för Active Directory-replikering. FRS använder två replikationsprotokoll för SYSVOL:
SYSVOL-anslutning inom en webbplats. Anslutningen anses alltid vara på; något schema ignoreras och ändrade filer replikeras omedelbart.

SYSVOL-anslutning mellan webbplatser. SYSVOL-replikering initieras mellan två intersite-medlemmar i början av 15-minutersintervallet, förutsatt att schemat är öppet. Anslutningen behandlas som ett utlösningsschema. Uppströmspartnern ignorerar sitt schema och svarar på alla förfrågningar från nedströmspartnern. När schemat stängs, kopplar uppströmspartnern upp anslutningen först efter att det aktuella innehållet i den utgående loggen, vid tidpunkten för anslutningen, har skickats och bekräftats.

> vanliga sysvol-fel och problem.

A . Sysvol och Netlogon aktier saknas.

ta ett senario när du lägger till en ny domänkontrollant till din domän och du ser att det inte finns någon sysvol och netlogon – mapp tillgänglig på domänkontrollanten

Obs-Netlogon Share är inte en mapp som heter Netlogon på domänkontrollanten . Det är faktiskt en mapp där alla inloggningsskript lagras. Så som nämnts ovan , Skriptmapp under sysvol mapp kommer att fungera som Netlogon aktie (plats- % SystemRoot% \ sysvol \ sysvol \ <domän DNS-namn>\skript)

detta sker främst om sysvol replikering borken. I vissa fall efter att du har lagt till en ny domänkontrollant kan SYSVOL-replikering ta lite tid.(Ungefär måste du vänta i några timmar).

B. Journal Wrap Error

FRS är ett multi-master replikeringssystem som tar hand om att replikera innehållet i Sysvol mellan alla DC i domänen (det kan också replikera normala data men vi är främst intresserade av Sysvol-replikering i blogginlägget).
med korrekt skötsel och underhåll är post-SP2 FRS på W2k3 ganska stabil och glatt surrar så länge det inte finns ett externt tillstånd som ett nätverksavbrott eller diskproblem som får det att bryta ner (förutsatt att de data du replikerar inte är helt olämpliga för att replikera som .PST-filer, profildata eller innehåll som ändras ofta).
den vanligaste FRS frågan är där en Journal Wrap inträffar; låt oss ta en närmare titt på vad som händer under en Journal Wrap under huven.
hur FRS fungerar är att den har en intern databas som innehåller alla filer och mappar som den replikerar och var och en av dessa har ett unikt globalt ID (GUID). Dababase innehåller också en pekare till den senaste NTFS-diskoperationen (i USN Journal/NTFS Journal) som FRS-tjänsten behandlade.

om en användare ändrar en fil eller mapp på en disk, händer följande:
1) åtgärden hämtas av NTFS och en post görs i NTFS-journalen.
2) FRS övervakar NTFS-journalen för ändringar och noterar att en ändring har gjorts i den filen.
3) FRS registrerar den senaste NTFS-Journalhändelsen som den behandlade och kontrollerar om den redan har bearbetat den.
4) om det inte har bearbetat det redan ser det ut om det är en fil som den ska replikera.
5) om den ska replikeras går filen in i den normala processen för iscensättning, replikering etc.
6) FRS ökar posten i sin databas om NTFS-Journalhändelsen som den har bearbetat så att den inte kommer att överväga den igen.

nu … låt oss förenkla saker lite.
– vår disk innehåller en fil och en mapp (e:\Test och testa.txt).
– vår NTFS journal har en storlek på 10 poster (Standard NTFS Journal storlek i RL är ~512 Mb beroende på din OS/SP nivå).
– vår FRS-databas innehåller tre poster
– > en GUID för E:\test
– > en GUID för E:\test\test.txt
– > en hänvisning till den senaste NTFS-journalposten vi behandlade (låt oss säga #4)

normala operationer:
– > någon gör en ändring för att testa.txt.
– > NTFS-tidskriften uppdateras till # 5.
– > FRS konstaterar att NTFS journal säger att en förändring har gjorts för att testa.txt och det ser att det inte har bearbetat den förändringen.
– >steg / replikera och uppdatera FRS-databasen för att återspegla att vi har bearbetat den NTFS-journalposten.

nu stoppar en administratör FRS-tjänsten i 30 minuter.
– någon gör 10 ändringar för att testa.txt
O NTFS Journal uppdateras 20 gånger och är nu på #24 (kom ihåg att vi har en loggstorleksgräns för de senaste 10 posterna så därför måste vi linda runt).
O FRS stoppas så att den inte övervakar NTFS-Journalloggen.

vid denna tidpunkt har vi ändringar på disken som FRS inte är medveten om. FRS känner fortfarande till den senaste NTFS-journalposten som den behandlade och den kommer att jämföra detta med den aktuella NTFS-journalen nästa gång den startar om.
nästa gång FRS-tjänsten startar ser den att den har missat NTFS-operationer på disken (den senast bearbetade NTFS-operation #4 men NTFS-journalen är nu på #24 och vi har bara en logg som går tillbaka 10 poster så vi saknar operationer #5 – #14 från databasen.
det här är när FRS klagar på att det har nått ett Journalomslag, NTFS-Journalloggen har lindats runt och det vet inte det aktuella läget på disken.
effekten av detta på en påverkad DC är att FRS inte kommer att ställa in issysvolready-registernyckeln för att indikera för Netlogon-tjänsten att allt är bra, Sysvol kommer därför inte att delas ut och DC kommer inte att kunna autentisera användare helt förrän Journal Wrap-tillståndet har lösts.
att manuellt dela ut Sysvol eller ställa in registernyckeln IsSysvolReady till 1 är inte giltiga metoder för att lösa problemet och tar inte upp det verkliga problemet.
för att FRS ska återhämta sig från en Journalomslag måste du i princip börja om från början och återställa FRS-databasen och börja räkna NTFS-journalen från de aktuella värdena den har.

detta betyder antingen:
– replikera i data från en befintlig inkommande partner (D2 eller icke-auktoritativ FRS-återställningsmetod).
– gör dina egna data auktoritativa och låt alla andra replikera från dig (D4 eller auktoritativa FRS restore-metoden).

D2-metoden är ganska enkel att utföra, kraven är dock att du har en bra nätverksanslutning med den inkommande replikationspartnern och den tid det tar är beroende av mängden data som ska replikeras jämfört med länkens kapacitet
å andra sidan kanske det inte alltid är tillräckligt och du kan hitta dig själv att tvingas gå med D4-alternativet.

ovan är de vanligaste felen när du överväger sysvol i Active Directory.

slutligen vilka steg vi kan följa när ovanstående fel är encoutered.

> felsökning Sysvol felmeddelanden

en . Sysvol och Netlogon aktier saknas.

som jag nämnde tidigare kan det vara ett problem med sysvol-replikering bruten mellan domänkontrollanter.

hur kan jag tvinga Sysvol-replikationen i en active directory

du kan starta om FRS-tjänsten för att tvinga FRS-replikationen

för att starta om FRS-tjänsten, starta tjänster.msc från alternativet Kör på Start-menyn
och starta om FRS-tjänsten så får du Händelse-ID 13516 på FRS-händelseloggen.

SYSVOL-replikering via NTFRSUTL

om du vill tvinga SYSVOL-replikering mellan två domänkontrollanter i en active directory, använd sedan proceduren nedan

Ntfrsutl FORCEREPL kommandoradsalternativ för att tvinga replikering

du kan använda det nya kommandot ntfrsutl forcerepl för att genomdriva replikering oavsett det fördefinierade replikationsschemat. Detta genomförs endast för domänkontrollanten Sysvol replika set.

ntfrsutl forcerepl /r /p

detta kommando tvingar FRS att starta en replikationscykel. Du måste ange datorn, SetName och DnsName.

Obs! i det här kommandot används följande platshållare:
= Anslut till NtFrs-tjänsten på den här maskinen.
= namnet på replikuppsättningen.
= DNS-namnet på den inkommande partnern för att tvinga replikering från.

till exempel:

ntfrsutl.exe forcerepl DestinationDC / r ”Domänsystemvolym (SYSVOL-andel)” / p SourceDC.domain.com

citattecken i det här exemplet krävs när du använder alternativet /r. Om citattecken inte finns, kommer kommandot inte att fungera.

om ovan inte hjälper då,

mest populära metoden för att lösa detta är under MS KB.

symptom:

när du har installerat Active Directory Domain Services på en ny fullständig eller skrivskyddad Windows Server 2008-baserad domänkontrollant i en befintlig domän finns SYSVOL-resursen. Netlogon-aktien finns dock inte på den nya domänkontrollanten.

Obs Denna artikel gäller inte om både Netlogon-och SYSVOL-aktier saknas.

orsak:

det här problemet uppstår när Netlogon-tjänsten läser Sysvolready-flaggan i registret mycket snabbt. Sedan försöker Netlogon-tjänsten att dela ut mappen\Windows\SYSVOL\domain \ scripts innan NT File Replication Service (NTFRS) skapar den här mappen.

lösning:

Varning allvarliga problem kan uppstå om du ändrar registret felaktigt med hjälp av Registerredigeraren eller med en annan metod. Dessa problem kan kräva att du installerar om operativsystemet. Microsoft kan inte garantera att dessa problem kan lösas. Ändra registret på egen risk.

för att komma runt det här problemet, Ställ in SysvolReady-flaggregistervärdet till ”0” och sedan tillbaka till ”1” i registret. Gör så här:
– > klicka på Start, klicka på Kör, skriv regedit och klicka sedan på OK.
– >leta upp följande undernyckel i Registerredigeraren:
HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Netlogon \ Parameters
– >högerklicka på sysvolready-flaggan i informationsfönstret och klicka sedan på Ändra.
– > skriv 0 i rutan värdedata och klicka sedan på OK.
– >igen i informationsfönstret högerklickar du på sysvolready-flaggan och klickar sedan på Ändra.
– > skriv 1 i rutan värdedata och klicka sedan på OK.
Obs Detta kommer att orsaka Netlogon att dela ut SYSVOL, och mappen skript kommer att vara närvarande.

mer INFORMATION:

problemet som beskrivs i avsnittet ”symptom” uppstår i följande scenario:
NTFRS sätter först ändringar på följande plats:
\ Windows \ SYSVOL \ domain \ DO_NOT_REMOVE_NtFrs_PreInstall_Directory
sedan meddelar NTFRS Netlogon att dela ut SYSVOL genom att ställa in SysvolReady-flaggregisterposten till ” 1.”
NtFrs flyttar sedan och byter namn på filer från den plats som nämns i steg 1 till följande mapp:
\Windows\SYSVOL\domain
men om Netlogon-tjänsten läser sysvolready-Flaggposten i registret mycket snabbt, försöker Netlogon-tjänsten att dela ut mappen \Windows\SYSVOL\domain\scripts innan NTFRS skapar den här mappen. Därför skapas inte NETLOGON-aktien.

B . Journal Wrap Error
om Journal wrap error inträffar kan vi ställa in ett blurflag-värde till D2 i registret på en domänkontrollant där Journal wrap error-händelser genereras. Genom att göra detta domänkontrollant kommer dumpa befintliga mappar och börja replikera nytt innehåll från en av dess FRS replikering partners.

eller

vi kan ställa in blurflag till D4 som gör exakt motsatsen till ovan . Det vill säga när du ställer in D4 på en pertikulär domänkontrollant kommer dess data att fungera som författande , resultatet kommer alla domänkontrollanter i din domän att replikera från domänkontrollanten där denna blurflag är inställd på D4

Obs – Inställning av BlurFlag till D4 är det sista alternativet , 90% fall kommer att lösas genom att ställa in blurflag till D2.

ANNONSARTIKLAR vanliga frågor om Windows

Lämna ett svar

Din e-postadress kommer inte publiceras.