Sysvol og netlogon andel betydning i Active Directory
> hvad er sysvol og indhold det indeholder.
Sysvol er en vigtig komponent i Active Directory. Sysvol-mappen deles på en NTFS-lydstyrke på alle domænecontrollere i et bestemt domæne. Sysvol bruges til at levere politik og logon scripts til domænemedlemmer.
som standard indeholder sysvol 2 mapper
1.Politikker – (standard placering – %SystemRoot%\Sysvol\Sysvol\domain_name\politikker)
2.Scripts – (standard lcation – %SystemRoot%\Sysvol\Sysvol\domain_name\Scripts)
Bemærk-Vi kan gå videre og ændre disse standardplaceringer.
> Imprtance af Sysvol Share.
Sysvol indeholder 2 mapper nemlig politikker og Scripts.
politikker – under mappen politikker findes alle gruppepolitikker, der er defineret i et particluar-domæne. Se skærmbilledet
Bemærk, at du kan se 3 GPT ‘ er er tilgængelige i ovenstående skærmbillede. Når du opretter en ny gruppepolitik i din active directory, oprettes der et sæt mapper under mappen politikker.
for Eg-Jeg opretter en politik kaldet Deaktiver pauseskærm i mit domæne og forbinder denne politik til min OU. Når jeg trykker på Opret ny politikknap i GPMC , opretter den en guid-Navnemappe under mappen politikker, som vil blive tilknyttet for at deaktivere pauseskærm GPO.
for at gøre dette simpelt har ovenstående skærmbillede 3 GPT ‘ er , der betyder, at 3 gruppepolitikker er til stede i test.TLD domæne.
så når du foretager ændringer i bestemte gruppepolitiske objekter, vil ændringer blive forpligtet til Assocaited GUID-navnemappe under Sysvol.
konklusion
betydningen af Sysvol-mappen er , den holder GPT , og når en administrator foretager ændringer i nogen af politikkerne , vil ændringerne blive forpligtet til assocated GUID name folder, og så vil de blive replikeret til alle domænecontrollere.
> Sysvol-replikationsmetoder.
Sysvol kan replikeres til alle domænecontrollere ved hjælp af distribueret Filsystemreplikation (DFS-R), hvis domænefunktionsniveauet dette link er eksternt til TechNet. Det åbnes i et nyt vindue. er vinduer Server 2008 eller højere, eller det replikeres ved hjælp af File Replication System (FRS).
for FRS er SYSVOL-tidsplanen en attribut, der er knyttet til hvert ntfrs-Replikasætobjekt og til hvert NTDs-Forbindelsesobjekt. FRS replikerer SYSVOL ved hjælp af de samme intrasite-forbindelsesobjekter og tidsplan bygget af KCC til Active Directory-replikation. FRS bruger to replikationsprotokoller til SYSVOL:
SYSVOL-forbindelse inden for et sted. Forbindelsen anses altid for at være tændt; enhver tidsplan ignoreres, og ændrede filer replikeres med det samme.
SYSVOL forbindelse mellem steder. SYSVOL-replikation initieres mellem to intersite-medlemmer i starten af 15-minutters intervallet, forudsat at tidsplanen er åben. Forbindelsen behandles som en triggerplan. Opstrømspartneren ignorerer sin tidsplan og reagerer på enhver anmodning fra nedstrømspartneren. Når tidsplanen lukker, den opstrøms partner unjoins forbindelsen først efter det aktuelle indhold af udgående log, på tidspunktet for join, er blevet sendt og anerkendt.
> fælles sysvol fejl og problemer.
a . Sysvol og Netlogon aktier mangler.
tag en senario , når du tilføjer en ny domænecontroller til dit domæne, og du ser, at der ikke er nogen sysvol – og netlogon-mappe tilgængelig på domænecontrolleren
Bemærk-Netlogon Share er ikke en mappe med navnet Netlogon på domænecontroller . Faktisk er det en mappe, hvor alle logon scripts er gemt. Så som nævnt ovenfor , Script mappe under sysvol mappe vil fungere som Netlogon share (placering – %SystemRoot%\sysvol\sysvol\<domain DNS name>\scripts)
dette sker hovedsageligt, hvis sysvol replikation borken. I nogle tilfælde , efter at du har tilføjet en ny domænecontroller, kan sysvol-replikation tage noget tid.(Ca. Du skal vente i nogle timer).
B. Journalindpakningsfejl
FRS er et multi-master replikationssystem, der tager sig af at replikere indholdet af Sysvol mellem alle DC ‘ er i domænet (det kan også replikere normale data, men vi er primært interesserede i Sysvol-replikation i blogindgangen).
med ordentlig pleje og vedligeholdelse er Post-SP2 FRS på 2K3 ret stabil og lykkeligt nynner sammen, så længe der ikke er en ekstern tilstand som et netværksafbrydelse eller diskproblemer, der får det til at bryde ned (forudsat at de data, du replikerer, ikke er helt uegnede til at replikere som .PST-filer, profildata eller indhold, der ændres ofte).
det hyppigste FRS-problem er, hvor en Journalindpakning opstår; lad os se nærmere på, hvad der sker under en Journalindpakning under hætten.
den måde, FRS fungerer på, er, at den har en intern database, der indeholder alle de filer og mapper, den replikerer, og hver af disse har et unikt globalt ID (GUID). Dababasen indeholder også en markør til den sidste NTFS-diskoperation (i USN Journal/NTFS Journal), som FRS-tjenesten behandlede.
hvis en bruger ændrer en fil eller mappe på en disk, sker følgende:
1) handlingen hentes af NTFS, og der indtastes en post i NTFS-kladden.
2) FRS overvåger NTFS-kladden for ændringer og bemærker, at der er foretaget en ændring af den pågældende fil.
3) FRS registrerer den sidste NTFS-Journalhændelse, som den behandlede, og kontrollerer, om den allerede har behandlet den.
4) hvis det ikke allerede har behandlet det, ser det på, om det er en fil, som den skal replikere.
5) Hvis den skal replikeres, går filen ind i den normale proces med iscenesættelse, replikering osv.
6) FRS øger posten i sin database om NTFS-Journalhændelsen, som den har behandlet, så den ikke overvejer den igen.
nu…lad os forenkle tingene lidt.
– vores disk indeholder en fil og en mappe (e:\Test og prøve.tekst).
– vores NTFS journal har en størrelse på 10 poster (standard NTFS Journal størrelse i RL er ~512 Mb afhængigt af dit OS/SP niveau).
– vores FRS database indeholder tre poster
– > en GUID til E:\test
– > en GUID for E:\test\test.
– >en henvisning til den sidste NTFS-journalpost, vi behandlede (lad os sige #4)
normale operationer:
– > nogen foretager en ændring for at teste.TST.
– > NTFS Journal er opdateret til #5.
– > FRS bemærker, at NTFS journal siger, at der er foretaget en ændring for at teste.og det ser, at det ikke har behandlet denne ændring.
->trin/Repliker og opdater FRS-databasen for at afspejle, at vi har behandlet den NTFS-journalpost.
nu stopper en administrator FRS-tjenesten i 30 minutter.
– nogen foretager 10 ændringer for at teste.
O NTFS Journal opdateres 20 gange og er nu på #24 (husk, at vi har en logstørrelsesgrænse for de sidste 10 poster, så derfor skal vi ombrydes).
o FRS er stoppet, så det ikke overvåger NTFS Journal log.
på dette tidspunkt har vi ændringer på disken, som FRS ikke er opmærksom på. FRS kender stadig den sidste NTFS-journalpost, den behandlede, og den vil sammenligne dette med den aktuelle NTFS-Journal, næste gang den genstarter.
næste gang FRS-tjenesten starter, ser den, at den har savnet NTFS-operationer på disken (den sidst behandlede NTFS-operation #4, men NTFS-journalen er nu på #24, og vi har kun en log, der går tilbage 10 poster, så vi mangler operationer #5 – #14 fra databasen.
dette er, når FRS klager over, at den har nået en Journalombrydningstilstand, NTFS-Journalloggen er pakket rundt, og den kender ikke den aktuelle tilstand af ting på disken.
virkningen af dette på en berørt DC er, at FRS ikke indstiller IsSysvolReady-registreringsnøglen til at indikere for Netlogon-tjenesten, at alt er godt, Sysvol vil derfor ikke blive delt ud, og DC vil ikke være i stand til at godkende brugere fuldt ud, før Journalombrydningstilstanden er løst.
manuel deling af Sysvol eller indstilling af IsSysvolReady-registreringsnøglen til 1 er ikke gyldige metoder til løsning af dette problem og løser ikke det virkelige problem.
for at FRS kan komme sig fra en Journalindpakning, skal du dybest set starte fra bunden og nulstille FRS-databasen og begynde at tælle NTFS-journalen fra de aktuelle værdier, den har.
dette betyder enten:
– replikering af data fra en eksisterende indgående partner (D2 eller ikke-autoritativ FRS-gendannelsesmetode).
– gør dine egne data autoritative og lad alle andre replikere fra dig (D4 eller autoritativ FRS restore tilgang).
D2-tilgangen er ret enkel at udføre, kravene er dog, at du har en god netværksforbindelse med den indgående replikeringspartner, og den tid, det tager, afhænger af mængden af data, der skal replikeres vs. kapaciteten på linket
på den anden side er dette muligvis ikke altid tilstrækkeligt, og du kan finde dig selv tvunget til at gå med D4-indstillingen.
ovenfor er de mest almindelige fejl, når du overvejer sysvol i Active Directory.
endelig hvad er de trin, vi kan følge, når ovenstående fejl er encoutered.
> fejlfinding Sysvol fejlmeddelelser
a . Sysvol og Netlogon aktier mangler.
som jeg nævnte før, kan det være et problem med sysvol replikation brudt mellem domænecontrollere.
Hvordan kan jeg tvinge Sysvol-replikationen i en active directory
din kan genstarte FRS-tjenesten for at tvinge FRS-replikationen
for at genstarte FRS-tjenesten skal du starte tjenester.msc fra indstillingen Kør i menuen Start
og genstart FRS-tjenesten, så får du Event ID 13516 på FRS event log dette vil sikre, at FRS-status er fin.
Sysvol-replikation gennem NTFRSUTL
hvis du vil tvinge sysvol-replikation mellem to domænecontrollere i en active directory, skal du bruge nedenstående procedure
Ntfrsutl Forcerepl-Kommandolinjemulighed til at tvinge replikation
du kan bruge den nye ntfrsutl forcerepl-kommando til at håndhæve replikation uanset den foruddefinerede replikeringsplan. Dette er kun implementeret for domænecontrolleren Sysvol replika sæt.
ntfrsutl forcerepl /r /p
denne kommando tvinger FRS til at starte en replikationscyklus. Du skal angive computeren, SetName og DnsName.
Bemærk I denne kommando bruges følgende pladsholdere:
= Opret forbindelse til ntfrs-tjenesten på denne maskine.
= navnet på replikasættet.
= DNS – navnet på den indgående partner til at tvinge replikation fra.
for eksempel:
ntfrsutl.forcerepl DestinationDC / r “domæne System volumen (SYSVOL share)” / p SourceDC.domain.com
anførselstegnene i dette eksempel er påkrævet, når du bruger indstillingen /r. Hvis anførselstegnene ikke er til stede, fungerer kommandoen ikke.
hvis ovenstående ikke hjælper så,
mest populære metode til at løse dette er i nedenstående MS KB.
symptomer:
når du har installeret Active Directory Domain Services på en ny fuld-eller skrivebeskyttet Server 2008-baseret domænecontroller i et eksisterende domæne, er SYSVOL-aktien til stede. NETLOGON-aktien er dog ikke til stede på den nye domænecontroller.
Bemærk Denne artikel gælder ikke, hvis både NETLOGON-og SYSVOL-aktier mangler.
årsag:
dette problem opstår, når Netlogon-tjenesten læser SysvolReady-flagget i registreringsdatabasen meget hurtigt. Derefter forsøger Netlogon-tjenesten at dele mappen \Sysvol\domain\scripts, før NT File Replication Service (NTFRS) opretter denne mappe.
løsning:
Advarsel der kan opstå alvorlige problemer, hvis du ændrer registreringsdatabasen forkert ved hjælp af Registreringseditor eller ved hjælp af en anden metode. Disse problemer kan kræve, at du geninstallerer operativsystemet. Microsoft kan ikke garantere, at disse problemer kan løses. Ændre registreringsdatabasen på egen risiko.
for at løse dette problem skal du indstille værdien SysvolReady Flag-registreringsdatabasen til “0” og derefter tilbage til “1” i registreringsdatabasen. Følg disse trin for at gøre dette:
->Klik på Start, klik på Kør, skriv regedit, og klik derefter på OK.
->Find følgende undernøgle i Registreringseditor:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
->Højreklik på flaget SysvolReady i detaljeruden, og klik derefter på Rediger.
->skriv 0 i feltet Værdidata, og klik derefter på OK.
->Højreklik på flaget SysvolReady i detaljeruden, og klik derefter på Rediger.
->skriv 1 i feltet Værdidata, og klik derefter på OK.
Bemærk Dette vil få Netlogon til at dele SYSVOL ud, og mappen scripts vil være til stede.
flere oplysninger:
problemet, der er beskrevet i afsnittet “symptomer”, forekommer i følgende scenarie:
NTFRS sætter først ændringer på følgende placering:
\vinduer\SYSVOL\domæne \ DO_NOT_REMOVE_NtFrs_PreInstall_Directory
derefter meddeler NTFRS Netlogon at dele SYSVOL ved at indstille SysvolReady Flag-registreringsdatabasen til “1.”
NTFRS flytter og omdøber derefter filer fra det sted, der er nævnt i trin 1, til følgende mappe:
\vinduer\SYSVOL\domæne
men hvis Netlogon-tjenesten læser sysvolready-flagposten i registreringsdatabasen meget hurtigt, forsøger Netlogon-tjenesten at dele mappen \vinduer\SYSVOL\domæne\scripts, før NTFRS opretter denne mappe. Derfor oprettes NETLOGON-aktien ikke.
B . Journalindpakningsfejl
hvis der opstår Journalindpakningsfejl, kan vi indstille en blurflag-værdi til D2 i registreringsdatabasen på en domænecontroller, hvor Journalindpakningsfejlhændelser genereres. Ved at gøre dette domænecontroller vil dumpe de allerede eksisterende mapper og begynde at replikere nyt indhold fra en af sine FRS replikering partnere.
eller
vi kan indstille blurflag til D4, hvilket gør nøjagtigt modsat ovenstående . Det vil sige , når du indstiller D4 på en pertikulær domænecontroller, fungerer dens data som forfatter , resultat, alle domænecontrollere i dit domæne replikeres fra domænecontrolleren, hvor denne blurflag er indstillet til D4
Bemærk – Indstilling af BlurFlag til D4 er den sidste mulighed, 90% sager løses ved at konfigurere blurflag til D2.
| ANNONCEARTIKLER | vinduer ofte stillede spørgsmål |
|---|