Sysvol és netlogon megosztás fontossága az Active Directory-ban
> mi a sysvol és tartalma.
a Sysvol az Active Directory fontos összetevője. A Sysvol mappa NTFS-köteten van megosztva egy adott tartomány összes tartományvezérlőjén. A Sysvol a házirend és a bejelentkezési parancsfájlok eljuttatására szolgál a tartomány tagjaihoz.
alapértelmezés szerint a sysvol 2 mappát tartalmaz
1.Házirendek – (alapértelmezett hely – %SystemRoot%\Sysvol\Sysvol\tartománynév\házirendek)
2.Scripts – (alapértelmezett lcation – % SystemRoot% \ Sysvol \ Sysvol \ domain_name \ Scripts)
Megjegyzés – ezeket az alapértelmezett helyeket megváltoztathatjuk.
> a Sysvol megosztás Imprintanciája.
a Sysvol 2 mappát tartalmaz, nevezetesen házirendeket és parancsfájlokat.
házirendek – a házirendek mappában minden olyan csoportházirend létezik, amely egy adott tartományban van meghatározva. Lásd a képernyőképet
ne feledje, hogy az 3 GPT-k a fenti képernyőképen érhetők el. Amikor új csoportházirendet hoz létre az active directory-ban, akkor a házirendek mappában létrehoz egy mappakészletet.
az Eg-hez-létrehozok egy Disable screen saver nevű házirendet a domainemben, és összekapcsolom ezt a házirendet az OU-val. Amikor megnyomom az új házirend létrehozása gombot a GPMC-ben, létrehoz egy GUID név mappát a házirendek mappában, amely a képernyővédő GPO letiltásához kapcsolódik.
ahhoz , hogy ezt az egyszerű, fenti screen shot van 3 GPT azt jelenti, 3 csoport házirendek vannak jelen teszt.tld domain.
tehát amikor bizonyos csoportházirend-objektumokat módosít,a módosítások a Sysvol alatt a társított GUID név mappába kerülnek.
következtetés
a Sysvol mappa fontossága a GPT , és amikor egy rendszergazda bármilyen módosítást hajt végre bármelyik házirendben , akkor a módosítások az assocated GUID name mappába kerülnek , majd az összes tartományvezérlőre replikálódnak.
> Sysvol replikációs módszerek.
a Sysvol az Elosztott fájlrendszer-replikáció (DFS-R) használatával minden tartományvezérlőre replikálható, ha a tartomány funkcionális szintje a TechNet Wikin kívül található. Új ablakban nyílik meg. Windows Server 2008 vagy újabb, vagy fájlreplikációs rendszer (FRS) használatával replikálódik.
FRS esetén a SYSVOL ütemezés egy attribútum, amely minden NTFRS replika Set objektumhoz és minden NTDS Connection objektumhoz kapcsolódik. Az FRS megismétli a SYSVOL-t ugyanazon intrasite kapcsolatobjektumok és ütemezés használatával, amelyet a KCC épített az Active Directory replikációhoz. Az FRS két replikációs protokollt használ a SYSVOL számára:
SYSVOL kapcsolat egy webhelyen belül. A kapcsolat mindig be van kapcsolva; minden ütemezést figyelmen kívül hagy, és a módosított fájlok azonnal replikálódnak.
SYSVOL kapcsolat a webhelyek között. A SYSVOL replikáció két intersite tag között kezdődik a 15 perces intervallum elején, feltételezve, hogy az ütemezés nyitva van. A kapcsolatot trigger ütemezésként kezelik. Az upstream partner figyelmen kívül hagyja az ütemtervet, és válaszol a downstream partner minden kérésére. Az ütemezés lezárásakor az upstream partner csak akkor szünteti meg a kapcsolatot, ha a kimenő napló aktuális tartalmát a csatlakozás időpontjában elküldték és NYUGTÁZTÁK.
> gyakori sysvol hiba és problémák.
A . A Sysvol és a Netlogon részvények hiányoznak.
Vegyünk egy senario – t , amikor új tartományvezérlőt adunk hozzá a tartományunkhoz, és azt látjuk, hogy a tartományvezérlőn nincs elérhető sysvol és netlogon mappa
megjegyzés-a Netlogon megosztás nem Netlogon nevű mappa a tartományvezérlőn . Valójában ez egy mappa, ahol az összes bejelentkezési szkript tárolódik. Tehát, mint már említettük, Script mappa alatt sysvol mappa fog működni Netlogon részesedése (Location – %SystemRoot%\sysvol\sysvol\<domain DNS név>\scripts)
ez elsősorban akkor fordul elő, ha a sysvol replikáció borken. Bizonyos esetekben új tartományvezérlő hozzáadása után a sysvol replikációja eltarthat egy ideig.(Körülbelül néhány órát kell várnia).
B. Journal Wrap Error
az FRS egy multi-master replikációs rendszer, amely gondoskodik a Sysvol tartalmának replikálásáról a tartomány összes DC-je között (normál adatokat is képes replikálni, de elsősorban a SYSVOL replikációja érdekel a blogbejegyzésben).
megfelelő gondossággal és karbantartással az SP2 utáni FRS a W2k3-On elég stabil és boldogan zümmög mindaddig, amíg nincs olyan külső állapot, mint például hálózati leállás vagy lemezproblémák, amelyek miatt lebomlik (feltételezve, hogy a replikált adatok nem teljesen alkalmatlanok a replikálásra .PST fájlok, profiladatok vagy gyakran változó tartalom).
a leggyakoribb FRS-probléma az, amikor Naplótörés történik; vessünk egy közelebbi pillantást arra, hogy mi történik a naplócsomagolás során a motorháztető alatt.
az FRS úgy működik, hogy rendelkezik egy belső adatbázissal, amely tartalmazza az összes replikált fájlt és mappát, és mindegyik egyedi globális azonosítóval (GUID) rendelkezik. A dababase tartalmaz egy mutatót az utolsó NTFS lemezművelethez (az USN naplóban/NTFS naplóban), amelyet az FRS szolgáltatás feldolgozott.
ha egy felhasználó megváltoztat egy fájlt vagy mappát a lemezen, a következő történik:
1) a műveletet az NTFS veszi fel, és bejegyzés történik az NTFS naplóban.
2) az FRS figyeli az NTFS napló változásait, és megjegyzi, hogy a fájl módosult.
3) az FRS nyilvántartást vezet az utolsó NTFS napló eseményről, amelyet feldolgozott, és ellenőrzi, hogy már feldolgozta-e.
4) Ha még nem dolgozta fel, akkor megvizsgálja, hogy ez egy fájl, amelyet replikálnia kell.
5) ha meg kell ismételni, akkor a fájl a szokásos szakaszolási, replikációs stb.
6) az FRS növeli az adatbázisában szereplő bejegyzést az általa feldolgozott NTFS napló eseményről, így nem veszi figyelembe újra.
most…egyszerűsítsük a dolgokat egy kicsit.
– a lemezünk egy fájlt és egy mappát tartalmaz (e:\Test és teszt.txt).
– NTFS naplónk mérete 10 bejegyzés (az alapértelmezett NTFS napló mérete RL-ben ~512 Mb az OS/SP szinttől függően).
– FRS adatbázisunk három bejegyzést tartalmaz
– > egy GUID E:\test
– > egy GUID E:\test\test.txt
-> hivatkozás az utolsó NTFS naplóbejegyzésre, amelyet feldolgoztunk (mondjuk #4)
normál műveletek:
– > valaki módosítja a tesztet.txt.
– > az NTFS napló #5-re frissül.
– > az FRS megjegyzi, hogy az NTFS folyóirat azt mondja, hogy változás történt a teszteléshez.txt és látja, hogy nem dolgozta fel ezt a változást.
– > Szakaszosítsa / replikálja és frissítse az FRS adatbázist, hogy tükrözze, hogy feldolgoztuk az NTFS naplóbejegyzést.
most egy rendszergazda leállítja az FRS szolgáltatást 30 percre.
– valaki 10 változtatást végez a teszteléshez.txt
o Az NTFS folyóirat 20-szor frissül, és most a 24. helyen van (ne feledje, hogy az utolsó 10 bejegyzés naplóméret-korlátja van, ezért körbe kell tekerni).
az O FRS le van állítva, így nem figyeli az NTFS napló naplóját.
ezen a ponton olyan változások vannak a lemezen, amelyekről az FRS nem tud. Az FRS még mindig ismeri az utolsó NTFS naplóbejegyzést, amelyet feldolgozott, és ezt a következő újraindításkor összehasonlítja az aktuális NTFS naplóval.
a következő alkalommal, amikor az FRS szolgáltatás elindul, látja, hogy elmulasztotta az NTFS műveleteket a lemezen (utoljára feldolgozta az NTFS 4.műveletet, de az NTFS napló most a 24. helyen van, és csak egy naplónk van, amely 10 bejegyzést tartalmaz, így hiányzik az 5-#14 művelet az adatbázisból.
ez az, amikor az FRS panaszkodik, hogy elérte a Naplócsomagolás állapotát, az NTFS Naplónapló körbefutott, és nem ismeri a lemezen lévő dolgok aktuális állapotát.
ennek hatása az érintett DC-re az, hogy az FRS nem állítja be az IsSysvolReady rendszerleíró kulcsot, hogy jelezze a Netlogon szolgáltatásnak, hogy minden rendben van, ezért a Sysvol nem lesz megosztva, és a DC nem tudja teljes mértékben hitelesíteni a felhasználókat, amíg a Journal Wrap feltétel meg nem oldódik.
a Sysvol manuális megosztása vagy az IsSysvolReady rendszerleíró kulcs 1-re állítása nem megfelelő módszer a probléma megoldására, és nem oldja meg a valódi problémát.
ahhoz, hogy az FRS helyreálljon egy Naplócsomagolásból, alapvetően a nulláról kell kezdenie, alaphelyzetbe kell állítania az FRS adatbázist, és el kell kezdenie számolni az NTFS naplót az aktuális értékekből.
ez azt jelenti, hogy:
– egy meglévő bejövő partner adatainak replikálása (d2 vagy nem hiteles FRS visszaállítási megközelítés).
– saját adatok hitelessé tétele, és mindenki más lemásolása tőled (a D4 vagy a hiteles FRS visszaállítási megközelítés).
a d2 megközelítés meglehetősen egyszerű végrehajtani, a követelmények azonban, hogy van egy jó hálózati kapcsolat a bejövő replikációs partner, és az idő fog függ az adatmennyiséget kell replikálni vs.a kapacitás a link
másrészt, ez nem mindig elegendő, és akkor találja magát, hogy kénytelen menni a d4 opciót.
fent a leggyakoribb hibák, ha figyelembe vesszük sysvol az Active Directory.
végül mik azok a lépések, amelyeket követhetünk, ha a fenti hibákat bekerítjük.
> hibaelhárítás Sysvol Hibaüzenetek
A . A Sysvol és a Netlogon részvények hiányoznak.
mint korábban említettem, probléma lehet a tartományvezérlők között megszakadt sysvol replikációval.
hogyan kényszeríthetem a Sysvol replikációt egy active directory-ban
az Ön újraindíthatja az FRS szolgáltatást az FRS replikáció kényszerítéséhez
az FRS szolgáltatás újraindításához indítsa el a szolgáltatásokat.msc a Start menü Futtatás opciójából
és indítsa újra az FRS szolgáltatást, és megkapja az 13516 eseményazonosítót az FRS eseménynaplóban.
Sysvol replikáció NTFRSUTL segítségével
ha egy active directory két tartományvezérlője között sysvol replikációt kíván kényszeríteni, akkor az alábbi
ntfrsutl FORCEREPL parancssori beállítással kényszerítheti a replikációt
az új ntfrsutl forcerepl paranccsal az előre meghatározott replikációs ütemezéstől függetlenül érvényesítheti a replikációt. Ez csak a tartományvezérlő Sysvol replika készletére vonatkozik.
ntfrsutl forcerepl /r /p
ez a parancs arra kényszeríti az FRS-t, hogy elindítson egy replikációs ciklust. Meg kell adnia a számítógépet, SetName és DnsName.
megjegyzés ebben a parancsban a következő helyőrzők használatosak:
= kapcsolódás a gépen található NtFrs szolgáltatáshoz.
= a replika készlet neve.
= a bejövő partner DNS-neve, ahonnan a replikációt kényszeríteni kell.
például:
ntfrsutl.exe forcerepl DestinationDC / r “Domain rendszer kötet (SYSVOL megosztás)” / p SourceDC.domain.com
ebben a példában az idézőjelek szükségesek a /r opció használatakor. Ha az idézőjelek nincsenek jelen, a parancs nem fog működni.
ha a fentiek nem segítenek, akkor
a legnépszerűbb módszer ennek megoldására az MS KB alatt található.
tünetek:
miután telepítette az Active Directory tartományi szolgáltatásokat egy új, teljes vagy csak olvasható Windows Server 2008-alapú tartományvezérlőre egy meglévő tartományban, a SYSVOL megosztás megjelenik. A NETLOGON megosztás azonban nincs jelen az új tartományvezérlőn.
Megjegyzés Ez a cikk nem alkalmazandó, ha mind a NETLOGON, mind a SYSVOL megosztások hiányoznak.
ok:
ez a probléma akkor fordul elő, amikor a Netlogon szolgáltatás nagyon gyorsan beolvassa a rendszerleíró adatbázisban a SysvolReady jelzőt. Ezután a Netlogon szolgáltatás megpróbálja megosztani a \Windows \ SYSVOL \ domain \ scripts mappát, mielőtt az NT fájlreplikációs szolgáltatás (NTFRS) létrehozná ezt a mappát.
megoldás:
figyelmeztetés súlyos problémák léphetnek fel, ha a Beállításszerkesztővel vagy más módszerrel helytelenül módosítja a beállításjegyzéket. Ezek a problémák szükségessé tehetik az operációs rendszer újratelepítését. A Microsoft nem tudja garantálni, hogy ezek a problémák megoldhatók. Módosítsa a rendszerleíró adatbázist saját felelősségére.
a probléma megoldásához állítsa a SysvolReady zászló beállításjegyzék értékét “0” – ra, majd vissza “1” – re a beállításjegyzékben. Ehhez kövesse az alábbi lépéseket:
– > kattintson a Start menü Futtatás parancsára, írja be a regedit parancsot, majd kattintson az OK gombra.
– > keresse meg a következő alkulcsot a beállításszerkesztőben:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
-> kattintson a jobb gombbal a sysvolready jelölőre, majd kattintson a Módosítás parancsra.
– > az Érték mezőbe írja be a 0 értéket, majd kattintson az OK gombra.
– > ismét a Részletek ablaktáblában kattintson a jobb gombbal a SysvolReady jelzőre, majd kattintson a Módosítás parancsra.
– > az Érték mezőbe írja be az 1 értéket, majd kattintson az OK gombra.
Megjegyzés: ennek hatására a Netlogon megosztja a SYSVOL-t, és a scripts mappa megjelenik.
További információ:
a “tünetek” szakaszban leírt probléma a következő esetben fordul elő:
az NTFRS először a következő helyre helyezi a módosításokat:
\ Windows \ SYSVOL \ domain \ DO_NOT_REMOVE_NtFrs_PreInstall_Directory
ezután az NTFRS értesíti a Netlogont a SYSVOL megosztásáról, ha a SysvolReady Flag beállításjegyzék bejegyzést “1-re állítja.”
ezután az NtFrs áthelyezi és átnevezi a fájlokat az 1.lépésben említett helyről a következő mappába:
\Windows\SYSVOL\domain
ha azonban a Netlogon szolgáltatás nagyon gyorsan beolvassa a rendszerleíró adatbázisban található SysvolReady Flag bejegyzést, a Netlogon szolgáltatás megpróbálja megosztani a \Windows\SYSVOL\domain\scripts mappát, mielőtt az NTFRS létrehozza ezt a mappát. Ezért a NETLOGON megosztás nem jön létre.
B . Journal Wrap Error
ha Journal wrap hiba lép fel, akkor beállíthatunk egy blurflag értéket D2-re egy tartományvezérlő beállításjegyzékében, ahol a Journal wrap error események keletkeznek. Ezzel a tartományvezérlő kiírja a már meglévő mappákat, és megkezdi az új tartalom replikálását az egyik FRS replikációs partnerétől.
vagy
beállíthatjuk a blurflag-ot D4-re, amely pontosan ellentétes a fentiekkel . Ez azt jelenti , hogy amikor D4 – et állít be egy pertikuláris tartományvezérlőn, annak adatai szerzői jogként fognak működni , eredmény, a tartomány összes tartományvezérlője replikálódik a Tartományvezérlőtől, ahol ez a blurflag D4
Megjegyzés-A BlurFlag D4-re állítása az utolsó lehetőség, az esetek 90% – át a blurflag D2-re történő beállításával oldják meg.
| hirdetési cikkek | Windows GYIK |
|---|