Archívum

Archive for the ‘Windows Server’ Category

Core server, FiberChannel és MPIO

augusztus 12, 2022 2 hozzászólás

Adott helyen abban kérték a segítségem, hogy egy három tagból álló Hyper-V fürt egyik kiszolgálóján valami nem kerek. A jelenség szerint a ClusterStorage-ba felcsatolt köteten belül nem látszanak a mappák, de ha adott VM-et oda akarunk mozgatni, akkor megjelenik a könyvtár, látszólag némi adattal, de a LiveMigration hibát dob.

A nyomozás során jó pár nehezítés jött szembe, hiszen a vason egy ingyenes (Core) Hyper-V futott, tehát a grafikus eszközöket (lokálisan) nem tudtam használni. Szerencsére annyi előnyöm volt, hogy tartományba léptetett gépről lévén szó, távolról a Server Manager segítségével pár dolgot grafikusan is meg tudtam mutatni a kollégáknak.

Azt elég hamar meg tudtuk nézni, hogy optikán (Fibre Channel) van összekötve a tárolóval, de a kiosztott LUN-ok többszörösen jelentek meg a lemezek között. Ilyenkor természetesen az MPIO a következő lépés, nos, azt is meg tudtuk nézni távolról, hogy telepítve van (de természetesen itt is lehetett volna a Powershell). A következő kérdés viszont az MPIO beállítása volt, ami már egy érdekesebb történet, hiszen grafikus felületen pár klikk, ebben az esetben viszont vagy a Powershell megfelelő utasításai, vagy egy “régi”, parancs-sori eszköz segíthet: mpclaim. Ennek is rengeteg kapcsolója van; amivel érdemes kezdeni (s esetünkben ez már segített is), az

mpclaim -r -i -a “”

Ezek után már szépen látszottak a lemezek, sőt, a fürtben is teljes tagú szereplőként tudott részt venni.

Power plan on server

július 13, 2022 Hozzászólás

Most egy banális, de annál nagyobb súlyú tervezési hiba miatt lett a piros gomb megnyomva.

Adva van egy cég, a szokásos két tartományvezérlővel, viszont észlelték, hogy időnként a két DC nem elérhető, leállított státuszban van. Ilyenkor mindig elindították, de egy ideig nem keresték a hiba okát (a miértet nem firtattam…). Amikor végül megelégelték, s segítséget kértek, kiderült a turpiság.

Első körben nézzük az eseménynaplót:


Kikerekedett a szemem. Nocsak. Egy kiszolgáló, ráadásul DC, elmegy aludni – ki engedte meg neki? Feltételezzük első körben, hogy nem egy spéci driver küldte aludni, hanem maga a rendszer, nézzük a “Power options” beállításokat. “High performance” opció volt kiválasztva, viszont egy érdekes sorral. Egy hagyományos, normális kiszolgálón ez így néz ki:


Az adott kiszolgálón viszont így:


Ezzel két probléma is van:

1. szerveren alapból nem elérhető

2. hiába módosítottam kézzel Never-re, egy idő után visszaállt 1h-ra – tehát itt valószínűleg GPO-ból van szabályozva.

Nézzük akkor a GPO-kat, mi vonatkozik a DC-kre. Sajnos kiderült, hogy a legrosszabb verzió, a Default Domain Policy lett piszkálva:


Ezzel szintén két probléma van:

1. MS-ajánlás, hogy nem szoktuk módosítani a Default policy-ket: volt már olyan segítségkérésem, hogy eltűntek/megsérültek az alap-GPO-k, s vissza kellett állítani őket nulláról, ilyenkor természetesen a változtatások elvesznek (jellemzően nincs dokumentálva, hogy milyen módosítások kerültek még bele).

2. ha már módosítjuk, akkor gondoljuk végig és teszteljük. Ha tényleg kell a teljes tartományra, attól még meg lehet úgy oldani (WMI; GPO-filtering – akár csoporttagság, akár Deny apply; GPO-linkelés csak adott OU-khoz, s még lehetne sorolni az opciókat), hogy kiszolgálókra (s főleg DC-kre!) ne legyen érvényes…


Wsus gondok Win 2022 upgrade után

szeptember 19, 2021 4 hozzászólás

Pár napja publikus lett a Windows 2022 (pl. VLSC*), de az “éles” ismerkedésünk nem indult valami jól. Az egy dolog, hogy szűz telepítésnél hogyan viselkedik, de tudjuk, hogy puding próbája az evés – így mondjuk például egy in-place upgrade már jobban kimutatja a problémákat. Természetesen a felmerülő kérdéseket nem szabad általánosítani, hiszen a helyi sajátosságok is közrejátszanak, majd a jövő megmutatja, hogy ez valóban lokális gond volt-e.

Adott cégnél próbálták ki az upgrade-et egy 2019-ről. Maga a telepítés sikeresen lezajlott, de utána máris kellett a segítségem, ugyanis pl. a Wsus upgrade-je sikertelen lett. Maga a hibaüzenet nem ismeretlen az IT-sok világa előtt, hiszen láttunk már ilyent:

Fatal Error: The schema version of the database is from a newer version of WSUS than currently installed. You must either patch your WSUS server to at least that version or drop the database.

Előbb természetesen megnéztem az adatbázis-verziót meg a post-Wsus konfigban szereplő verziót – egyezett (ellenkező esetben az alábbi parancsot érdemes lefuttatni):

C:\Program Files\Update Services\Database\UpdateSchemaVersion.sql

Mivel nem akartak sokat foglalkozni ezzel az adott cégnél, kérték, hogy akkor nulláról indítsuk. Így előbb megpróbáltam simán adatbázis törléssel (SQL Management Studio-ból) és ismételt létrehozással (anno máshol nem WID volt, így a jegyzeteimben ott volt még a szögletes zárójelbeli kiegészítés):

wsusutil.exe postinstall [SQL_INSTANCE_NAME=server\SQLEXPRESS]

Majd, amikor (látszólag) ez sem vezetett eredményre, letöröltük a WID instance-t és a WSUS szerepkört, majd újraindítás után újratelepítettük. Itt már biztossá vált, hogy nem ezzel volt baj, hiszen a WSUS konzol félig-betöltése továbbra is megmaradt.

A rend azután állt helyre, miután a 4GB memória növelésre került. Az eredeti elképzelés szerinti feladatokra lehet, hogy elég volt anno ez a mennyiség, de megnézve az aktuális terheltséget, szükség volt a +1GB-ra, főleg a kezdeti szinkronizációhoz (elég szűkös erőforrásokkal rendelkeznek…).

*VLSC: Ott is nagy változások történnek, hiszen az MS igyekszik kivezetni a “sima” fiókok használatát s “céges” fiókok irányába terelni. Ez részben jogos, hiszen általában a licenszek adott céghez/cégekhez kötődnek, így abban a cégben létre lehet hozni egy új felhasználót – még ha nem is kap licenszt igénylő postafiókot; ugyanakkor véleményem szerint ennek a műveletnek a szükségessége kaphatott volna nagyobb visszhangot.

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

DNS zónák

január 26, 2021 Hozzászólás

Egy “nagytakarítás” során adott helyen felmerült, hogy az ADUC-ban miért látszanak egyes DNS-zónák, mások meg miért nem? Egyáltalán miért vannak ott?

Nos, kezdjük azzal, hogy AD-integrált zónák lévén mindenképp az AD-ban kell tárolódjanak, tehát bizonyos AD-kezelő eszközökkel látnunk kell őket. S bár abban “igazuk” volt, hogy a képen látható (és néhány, nem látható) zónák AD-integráltak, de nem mindegy, hogy kinek is replikálunk zónán belül.

Amennyiben Windows 2000-kompatibilis integráció lesz a kiválasztott, akkor megjelenik az ADUC-ban is (a szokásos DNS-kezelőn kívül), ellenkező esetben (szintén DNS-kezelőn kívül) csak ADSIEdit segítségével látjuk, csatlakozva a DC=DomainDNSZones,DC=tartomany,DC=hu partícióra (vagy, ha a legfelső opció, akkor értelemszerűen a DC=ForestDNSZones,DC=tartomany,DC=hu partícióra).

Mivel adott cégnél már nem volt szükség Windows-2000 kompatibilitásra, így át tudtuk állítani, s már nem zavarta őket, “eltűnt” (hétköznapi ember többet használ ADUC-ot, mint ADSIEdit-et 🙂 )

A tesztelés fontossága

december 2, 2020 1 hozzászólás

Adott helyen megkértek, hogy néhány fürtöt nézzünk át közösen, valamint azokon minimális módosításokat szeretnének. Ahogy haladtunk előre a munkával, dőltek ki a csontvázak a szekrényből, de a legnagyobb az utolsó fürt esetén jött elő.

Ez egy SQL-clusternek nevezett szolgáltatás volt. Az addigi tapasztalatok alapján, no meg a normális emberi gondolkodás szerint is, az első lépés az volt, hogy jelen állapotában teszteljük a működését. Ez azt jelentette, hogy a szolgáltatást a fürt egyik tagjáról átbillentsük a másikra. Nos, “természetesen” elhasalt. Ideiglenesen visszaállítottuk, s elkezdtük a hibakeresést, ami egy számomra teljesen szokatlan helyzetet mutatott ki: nem egy beállítás, nem egy pipa okozta a gondot, hanem az SQL-szerver telepítés hiánya. Előbbit még mondjuk így-úgy meg lehet magyarázni, hogy időközben állítódott el (persze, magától 😛 ), de egy egész SQL-telepítést? Ugye tanfolyamokon szoktunk viccelni, amikor idő szükséges, hogy semmi gond, addig telepítsünk egy SQL-t. Tudjuk jól, hogy nem 2 másodperc. S tudjuk jól, hogy legtöbb ember grafikus varázslóval megy rajta végig, akár telepítés, akár eltávolításról van szó. Szóval egy ilyen, rengeteg paramétert igénylő eltávolítást szerintem nem lehet “véletlenül” végrehajtani. De akkor mi történt?

Nos, valószínűleg emberi mulasztás. Lehet, hogy rohamtempóban kellett felhúzni a fürtöt, s nem volt idő a másik tagra telepíteni az SQL-t. Vagy valamilyen hiba következett be a telepítés során, amire elfelejtettek visszatérni. Vagy tudatlanság miatt: nem tudták, hogy mindkét kiszolgáló kell rendelkezzen telepített SQL-el. Vagy… lehetne sorolni a különböző forgatókönyveket.

A legnagyobb hiba viszont a végén van: átadás előtt tesztelni kellett volna. Hogy valóban átbillen-e, hogy valóban jól működik. S ha igen, csak akkor átadni használatra, ha nem, akkor jelezni, hogy pillanatnyilag működőképes, de NEM fürt. Ezáltal az érintettek is tudták volna, hogy mi is van a motorháztető alatt. Mi lett volna, ha mindez “élesben” derül ki, amikor az addig használt kiszolgáló ilyen-olyan okokból kifolyólag kidől?

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

Saját CA által kiállított tanúsítványok vs böngészők

október 7, 2020 Hozzászólás

Nem új keletű a történet háttere, de gondolom az új Edge bevezetésével mind több helyen elő fog jönni, ezért úgy döntöttem, elébe megyek a dolgoknak.

Adott cégnél felmerült, hogy az eddigi http alapú intranet kommunikációt áthelyezik https-re. Ennek érdekében első körben történt egy CA-bevezetés, majd a kiszolgálóra igényeltek egy web-kiszolgálói tanúsítványt.

A tesztelés során kiderült, hogy azok, akik IE vagy “régi” Edge-ről töltik be az oldalt, nem tapasztalnak gondokat, viszont akik Chrome vagy Chromium alapú Edge-ből, azoknak

ERR_CERT_COMMON_NAME_INVALID

hibaüzenettel, a Firefox-ból vonulóknak pedig egy

SEC_ERROR_UNKNOWN_ISSUER

üzenettel kedveskedik a rendszer.

Itt akkor felmerült a kérdés: most akkor mi van? Jó a tanúsítvány vagy nem? Illetve miért függ egy tanúsítvány megítélése a böngészőtől?

Nos, Firefox esetén a böngészőnek saját tanúsítvány-tára (is) van, de esetében mondhatni könnyű dolgunk van: egy házirend segítségével megadjuk, hogy a böngésző az oprendszertől kérje el a megbízható tanúsítványok listáját. S tudjuk, hogy a CA automatikusan lekerült a gépekhez, tehát ez nem lehet gond (erre amúgy másodlagos bizonyíték az is, hogy az MS régebbi böngészői sem reklamálnak). Itt “csak” egy dolog nem teljesen világos számomra: miért szükséges, hogy egyes programok (pl. Adobe, Java, stb) saját tanúsítványtárat használjanak? Értem én, hogy így akár szolgáltatásonként külön tanúsítványt lehet használni – de személy szerint ezt már túlzásnak érzem…

A Chrome / Chromium alapú Edge esetében a megértéshez szükséges a Google böngészőjének működését figyelembe venni. Kb. 3 éve ugyanis a Chrome nem fogadja el a belső CA-k által kiállított tanúsítványokat, csak akkor, ha azok rendelkeznek érvényes SAN-mezővel. Ezzel a gondolattal lehet vitatkozni, ugyanis elvileg az RFC előírja, hogy másodlagos opcióként a CN-t is ellenőrizni kell – de ez figyelmen kívül van hagyva. Egy ideig egy registry-kulccsal lehetett egy kerülő-megoldást alkalmazni, viszont ezt a lehetőséget is már rég megszüntették. Jelen esetben megoldásként az a döntés született, hogy rendben, akkor létrehoznak egy új, célnak megfelelő tanúsítvány-sablont, majd azzal igényelnek tanúsítványt. Ennek szétszedése (Cert, Key, CA) már gond nélkül lezajlott, majd az élesítés után már valóban nem reklamált a böngésző. De hogy mit tesznek azok a cégek, ahol tömegesen használnak web-kiszolgálókat, saját CA-val, s tömegesen akarják lecserélni a tanúsítványokat az újabb sablonból eredőnek – hát, lehet, hogy nem mindenki lesz boldog.

VM nem indul automatikusan

szeptember 25, 2019 Hozzászólás

Adott helyen felmerült a kérdés, hogy egy adott VM miért nem indul el automatikusan, amikor a host-ot újraindítják. A srácok nem igazán értették, ezért a mélyebb megértéshez elővettük az Application naplót, konkrétabban a Microsoft/Windows/Hyper-V-Worker/Admin eseménytárat, abban az alábbi megjelenő 4 hibaüzenetet (időrendi sorrendben alább):

12162: ‘VM’: Failed to configure ‘D:\Hyper-V\Virtual Hard Disks\VM.vhdx’: The storage where the virtual hard disk is located does not support virtual hard disk sharing.

12140: ‘VM’: Failed to open attachment ‘D:\Hyper-V\Virtual Hard Disks\VM.vhdx’. Error: ‘A virtual disk support provider for the specified file was not found.’ (7864368). (Virtual machine ID 6DF70F48-0492-4F78-B6D1-4A6BE05DA167)

12010: ‘VM’ Microsoft Emulated IDE Controller (Instance ID 83F8638B-8DCA-4152-9EDA-2CA8B33039B4): Failed to Power on with Error ‘A virtual disk support provider for the specified file was not found.’ (0xC03A0014). (Virtual machine ID 6DF70F48-0492-4F78-B6D1-4A6BE05DA167)

12030: ‘VM’ failed to start. (Virtual machine ID 6DF70F48-0492-4F78-B6D1-4A6BE05DA167)

Ami furcsa, hogy mivel Gen1-es gép boot-lemezéről van szó, ezért értelemszerűen csak IDE-s vezérlő jöhet szóba, s természetesen arra is van kötve (virtual hard disk sharing pedig csak scsi csatoló esetén jöhet szóba). Ugyanakkor feltűnhet, hogy a másik hibaüzenet az, hogy nem találja az állományt.

Akkor gondoljuk végig. Amennyiben kézzel indítjuk a virtuális gépet, akkor csont nélkül elindul – tehát az állomány létezik, van elég jogosultság hozzáférni. Nézzük, akkor melyik köteten van, valamint van-e még másik VM boot ugyanitt: igen, van, az pedig automatikusan el is indul.

Igen ám, de a kötet milyen lemezen van? Nos, egy iscsi LUN-ról beszélünk, tehát még az is lehet, hogy azért nem találja a kötetet (s ezzel együtt az állományt), mert még nincs felcsatolódva, amikor elindul a VM. Ennek az elméletnek igazolása után meg is fejtettük a dolgot, egy kérdés maradt még hátra: ha ez így van, akkor a másik VM (ugyanerről a kötetről) miért indul el? Erre megkaptuk a választ, amint belenéztünk a beállításokba: azért, mert az 120sec-es időkésleltetéssel volt indítva.

A probléma feltárva, a megoldást már a srácokra bíztam (ezt is késleltetik, átteszik másik kötetre, stb), pipa 🙂

AD és O365

július 31, 2019 1 hozzászólás

Aktuális történetem szintén AD-ról szó, bár ez érdekes módon most Exchange-problémából indult. Igen, természetesen tudom, hogy az Exchange az AD-ra épül – de azért mégis két külön termék.

Adott egy elég nagy szervezet, több tartománnyal, több Exchange kiszolgálóval. Egyes helyeken a levelezést már kiszervezték O365-be, míg más tartományok maradtak a hagyományos Exchange-verziónál (ami ráadásul most van migráció alatt, egy újabb verzió kerül bevezetésre – de jelen esetben ez lényegtelen).

A gond ott merült fel, hogy bizonyos tartományokból nem lehetett másik tartománybeli felhasználóknak emailt küldeni, „A postaláda címzettjének nincs postaláda-adatbázisa.” hibaüzenettel eldobta – s itt most csak a „belső” („testvér”) tartományokra gondolok.

Szokás szerint a helyzet nem volt ennyire egyszerű, ugyanis első információk szerint csak egy tartomány volt, amelyik nem tudott a cél-tartományba küldeni, miközben minden más irányba csont nélkül kimentek a levelek.

Kezdjük az elejével. A hibaüzenet alapján látszott, hogy a cél-tartományban (amelyik ráadásul O365-be költözött) nem történt meg minden lépés a migráció során, konkrétan a felhasználók TargetAddress címe nem lett kitöltve. Ha ez viszont igaz, akkor miért csak egy tartományból pattannak vissza a levelek? Utánajárva, letesztelve, kiderült, hogy ez csak feltételezés volt – ugyanis máshonnan nem küldtek levelet a cél-tartományba, ezért feltételezték, hogy akkor mindenki rendben tud küldeni. Amint másik „testvér” próbált emailt küldeni, természetesen ott is jelentkezett a hiba.

Rendben, akkor tehát a megoldás a TargetAddress kitöltése. A kollégák elvégezték a feladatot, majd újabb tesztek következtek. Nos, ekkor már valóban teljesült az előző állítás: csak egy (az eredetileg is jelzett) tartományból voltak sikertelenek a küldések, a többiek rendben tudtak küldeni.

Pontosabban, az előző mondatom sem teljes. Ugyanis ki kell egészíteni egy „általában” szócskával a mondat első felét. Volt, amikor sikeresen megérkezett a levél, volt, amikor nem (s ebben az esetben ugyanezzel a hibaüzenettel akadt el). Ugyanattól a feladótól, ugyanannak a címzettnek.

A nyomozás során újra átnéztem minden beállítást, értéket. ADSIEdit volt egyik fő eszközöm, de mindegyre meggyőződtem róla, hogy bármelyik DC-re is csatlakozom a hibás tartományból, annak GC partíciója (hiszen az tartalmazott infót a testvér-tartományról) helyes értékeket ad vissza a címzettről.

Aki ismer, tudja, hogy nem adom fel egykönnyen. Nos, ebben az esetben is elég komolyan foglalkoztatott a történet, szinte éjjel is ezzel aludtam 🙂

A megoldást egy véletlen hozta el. A „hibás” tartományban a kollégák felvettek egy új felhasználót, email-fiókkal, ahogy illik – de röviddel rá eltűnt a postaláda. Jelezték felém, hogy a Bermuda-háromszög ide költözött, így megkértek, hogy próbáljam én helyretenni a fiókot. Amikor elkezdtem utánajárni, akkor egy hirtelen ötlettől vezérelve megpróbáltam RDP-vel rámenni a DC-kre. Egyikre csont nélkül csatlakoztam, a másik… hát az elfogadta a név/jelszót, de utána nem történt semmi. A kollégát kértem, hogy próbálja ő – neki sem sikerült. A furcsa az volt, hogy mmc-vel, adsiedit-el csont nélkül tudtam rá csatlakozni. Kértem, hogy mindegy, milyen módon (ha lehet, „rendesen”, ha nem, akkor bárhogy) indítsák újra a DC-t – s utána érdekes módon minden megjavult.

Utólag persze könnyű okosnak lenni. A hibás email-küldés azért volt véletlenszerű, mert annak függvényében, hogy melyik DC-től kérdezte le a címzettet, kapott/nem kapott jó adatot. Igen, ennek ellentmond az, hogy a rossz DC is már tartalmazta a jó címet (hiszen más módon lekérdeztem tőle), de hogy mitől volt mesebeli (adott is, meg nem is; működött is, meg nem is)… A szokásos „indítsd újra” megtette a hatását 🙂

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

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: , ,