Archívum

Posts Tagged ‘FRS’

Replikációs módszer – újra

június 19, 2019 Hozzászólás

Nem kellett sokat várni, s máris egy másik helyen jött elő az előző cikkemben jelzett probléma – sőt, most egy kicsit összetettebb módon.

A környezetről annyit érdemes tudni, hogy szintén nem egy “zöldmezős” beruházás (valljuk be, elég ritkák az ilyenek 😊 ). Van két tartományvezérlő, amit a korral haladva “görgettek” előre, így Windows Server 2019-re lettek frissítve. A replikációk csont nélkül lezajlottak, így nem is gondoltak semmi problémára, amíg nem olvasták a cikkem (bár elég lett volna eseménynaplókat nézni 😊 ).

Ahhoz, hogy ez a része is rendben legyen, megpróbáltak áttérni az új módszerre – viszont a Windows Server 2019-es egyik bug-jára futottak. Ugyanis amikor az első Win2019-es tartományvezérlő bekerül a csapatba, egy ellenőrzés nem történik meg (személy szerint merem remélni, hogy később ez javítva lesz): milyen replikációs metódus van használatban. Amennyiben még FRS-t használnak az adott helyen, NE engedje előléptetni a kiszolgálót tartományvezérlőnek.

Amennyiben (mint jelen esetben) nincs ilyen ellenőrzés, a DFSR-re történő áttérés hibákba fog ütközni (csak a Win2019 esetén, s többi DC esetén megfelelően végrehajtódik). Egyelőre hivatalosan annyit lehet tenni, hogy minden Win2019-es tartományvezérlőt lefokozni, majd teljes, sikeres áttérés után ismét előléptetni.

Vagy természetesen már tervezési fázisban, ha tudjuk, hogy ilyen tartományvezérlőket akarunk, betervezni az áttérést még előléptetések előtt.

Egy apró „fejlődési” hiányosság

május 30, 2019 1 hozzászólás

Nemrég egy sérült AD-t kellett rendbetennem. Most nem térek ki, hogy a két sérült AD-partíció javítása sem volt egyszerű (az külön megérne egy cikket), helyette az AD-hoz tartozó file-replikációt veszem górcső alá.

Aki még nem foglalkozott vele, annak kezdem az elejével. A tartományvezérlők a feladatuk elvégzése során elég sok feladatot kezelnek – pl. tudjuk, hogy az egész AD egy jó, működőképes DNS nélkül nem ér semmit. No de a DNS nem minden. Ritkán, de előfordul, hogy maga az AD-adatbázis sérül meg (ez tartalmazza a partíciókat), illetve még egy fontos része van: a házirendeket és scripteket tartalmazó Sysvol mappa replikációja.

Ez a replikáció két módon történhet. Egyrészt van a régi, “hagyományos” NT-korszakbeli LAN Manager Replication Service-t váltó FRS (File Replication Service), másrészt az új, 2003 R2-ben bevezetett, de 2008-ban kiteljesedő DFSR (DFS Replication). Manapság, ha új tartományt építünk, alapértelmezés szerint ez utóbbi lesz használva, de régebbről “görgetett” tartományok esetén is tudunk váltani (ehhez minimum 2008-as tartományi-szint szükséges). Sőt, Windows Server 2016 RS3 (1709)-től már az FRS egyáltalán nem támogatott.

Az áttérés nem nehéz, arra érdemes figyelnünk, hogy mindig legyen szinkronban a tartományunk (amennyiben egyik DC nem értesül adott áttérési műveletről, utólag megpróbálja “utolérni” a többieket – akkor van gond, ha bármilyen hiba bekövetkezik).

Visszatérve, a jelzett helyen elég gáz helyzet volt. Mivel nem akartam/akarták a teljes AD-t újrahúzni (jogosan), a már említett adatbázis javítása után következett a replikáció helyretétele. Igen ám, de ekkor derült ki, hogy még FRS-t használnak, így ezt a vonalat elengedve, az a döntés született, hogy akkor most térünk át DFSR-re. Általánosságban a javaslat az, hogy előbb a hibákat hárítsuk el, s egy egészséges környezetben változtassunk – de jelenlegi helyzet egyike a ritka kivételeknek, ahol ezt könnyebb volt meglépni.

A két replikációs módszer összehasonlítását már megtette más – én arra próbálok mindenkit rávenni, hogy egy hozott/kapott, de akár saját “görgetett” tartomány esetén is, amennyiben lehetséges, lépje meg ezt a lépést. Erre utal a cím is, hogy a cég fejlődik, az AD séma változik – de tervezzük bele a replikáció váltását is, egy hibakeresés esetén saját magunk munkáját is megkönnyítve 😉

Kategóriák:General, Windows Server Címkék: , ,

AD-replikáció problémák

január 7, 2016 1 hozzászólás

Az egész úgy kezdődött, hogy adott cégnél a kollégák első alkalommal próbálták használni a GPMC-t Win10-ről. Amikor adott házirendet próbáltak megnyitni, pontosabban annak GPP részét, akkor az alábbi 0x80070041 kódú hibaüzenettel szembesültek:

GPO-error

Nem értették a dolgot, hiszen egyrészt a házirend-ág teljesen használható volt, másrészt látszólag minden rendben volt a két DC között (AD Sites&Services-el kért replikáció nem jelzett hibát, repadmin /showrepl szintén jó értékeket mutatott). Arra gondolva, hogy ez valószínűleg kliens-oldali gond, a kért házirend-módosítást megoldották egy másik adminisztratív gépről, majd napirendre tértek a dolog felett.

Mondhatni szerencsére, nem sok idő elteltével egy másik probléma is felmerült: nevezetesen, hogy egy kliens-gépen nem futott le egy szintén házirendben beállított parancsállomány. A próbálkozások során megpróbálták közvetlenül megnyitni a házirendet, s kézzel lefuttatni – ekkor derült ki, hogy azon a tartományvezérlőn, amelyiken hitelesített a kliens, a Sysvol tartalma nem egyezett meg a másik tartományvezérlőn található tartalommal, többek között hiányzott a kérdéses batch-állomány is.

A nyomozás során tisztáztuk az előzményeket is: a tartomány egy régi, 2000-es tartományról lett folyamatosan migrálva (most 2008 R2-es DC-k vannak), de a tartomány szintje 2003-ason van, ezért értelemszerűen a replikációra még FRS-t használnak, nem DFSR-t, így az eseménynaplóban ezt érdemes ellenőrizni. Nos, nem kellett sokat keresni, az FRS naplójában ott virított az Ntfrs 13568-as hiba, amiből kiderül a turpiság: a Wrap Journal sérült. A hibaüzenet mellett ugyanakkor ott van a megoldás is, amelynek során egy teljes szinkronizációt hajtottunk végre, így a két Sysvol mappa egyforma lett, így a kérdéses parancsállomány is átkerült – öröm, boldogság :).

Utólag elmondták, hogy ezzel egy másik, régóta hajszolt problémára is pont került: időnként a kliensek nem csatolták fel a GPP-ben hozzájuk rendelt meghajtókat. Ezt is rengeteget keresték, de mivel a replikációt rendben levőnek gondolták, a gpresult eredménye pedig azt mutatta, hogy a házirend érvényesül, nem tudtak merre indulni…

Kategóriák:Windows Server Címkék: , ,