A megszokás/kényelem nagy úr vs 1903
A (várhatóan következő hónapban) megjelenő 1909 előtt (ami “csak” egy szervízcsomag lesz), összefoglalom a környezetemben tapasztalt véleményeket a 1903-al kapcsolatosan.
- MS-nél is rájöttek, hogy telepítés után az elsők között van a 1709-ban bevezetett “People” eszköztár kikapcsolása, szinte senki nem használja. Ezt így szerencsére száműzték. Hogy ne maradjunk “kikapcsolandó” nélkül, megkaptuk a keresés opciót, most a legtöbb ügyfelet az zavarta, annak kiiktatása volt az első kérelmek között
- elég sokan megszerették a bejelentkezési képernyő változó, valóban minőségi háttereit. Nos, az aktuális verzióban ez alapból homályos (mondjuk az okát nem igazán értem) – szerencsére ez is könnyen orvosolható, a Settings/Personalization/Colors/Transparency effects menüpont Off-ra állításával (vagy GPO, vagy registry – ki melyiket szereti). Ez természetesen mást is érint, erre érdemes figyelni.
- végül, de nem utolsó sorban a cikk címét inspiráló képesség, a már Windows 7-ben létező “Plan brightness” (nem összetévesztendő az “Adaptive brightness” funkcióval, mi arról szól, hogy egy érzékelő segítségével a környezet fényerejét mérve a kijelző megvilágítása is automatikusan változik). Előbbi lehetőség viszont azt teszi lehetővé, hogy kétféle képernyő-fényerőt lehet beállítani: egyet, amikor áramba van csatlakoztatva az eszköz, s egy másodikat, amikor akkumulátorról üzemel (ez ugye a telepről való működés idejének kitolása végett). Nos, ez megszűnt, mostantól egy fényerőnk van. Igen, tudom, hogy a “Notifications”-höz kikerült a szabályozó csúszka, meg léteznek Fn+Fx billentyűkombinációk – de az mégsem ugyanaz, mint ahogy beavatkozás nélkül ez automatikusan változott. Igen, azt is tudom, hogy néhány felhasználót zavart, hogy a két említett fényerő nem volt egyforma – de ők legalább ízlés szerint beállíthatták, akár maximálisra mindkét értéket. De most megszűnt ennek a lehetősége is – amit azért is furcsállok, mert akárhogy vesszük, a hordozható eszközök aránya jelentősen nőtt…
AD és O365
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 🙂
Replikációs módszer – újra
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
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 😉
Egy rossz tervezés
Mivel máshol is belefutottam, gondoltam leírom, hátha van, aki legalább ezt olvasva észbe kap… Volt egy projekt, amelyben a segítségem kérték, egy teljes migrációt kellett végrehajtani a régi szerverekről az újakra. A kliens ugyanakkor nem minden fázist adott át, többek között a mentést és annak beállítását házon belül tervezte megoldani.
A sikeres migráció végéig még mindig nem döntötték el, hogy milyen módszerrel, milyen adattárolóra, milyen rendszerességgel fog történni a mentés. Abban egyetértettünk, hogy ez mindenképp szükséges, de mivel továbbra is saját maguk akarták kivitelezni, nem erőltettem a dolgot.
Szerencsére most nem azzal folytatom, hogy egy kripto-vírusos támadás után nem volt hova nyúlni. Viszont egy másik dolog következett be: a levelező-kiszolgálónak szánt lemezek teltek meg. Az előre egyeztetett elképzelés szerint nem körkörös loggolást használnak (ha lehet, amúgy sem ez a javasolt), ez viszont azzal jár, hogy ha nincs teljes mentés (s itt külön cikk lehetne a mentések típusairól, a piacon található mentőszoftverek módszereinek elnevezéséről), akkor a naplók csak gyűlnek. Ha nem monitorozzuk (akár külön szoftverrel, ami riaszt, akár manuálisan), az emailezési szokásoktól függően elég hamar meg tudják tölteni a rendelkezésre álló területet – amikor is a levelezés megáll. Vannak ugyan beépített korlátok az Exchange-ben, hogy bizonyos szint alá ne engedje megtelni a lemezt, de ezen korlátok elérésekor is lehetnek kellemetlenségeink az email-forgalomban. Helyette a javaslat az, hogy minden esetben tervezzük meg a mentést is (adott cégnél “csak” a levelezés állt le, mert az adatoknak, adatbázisoknak volt elég hely – de azok mentése is szükséges!).
Sajnos még mindig nem mindenhol fordítanak kellő figyelmet a mentésekre. Lehetne azt mondani, hogy cégmérettől függ – de nem igaz. Egy kis cégnél is láttam helyesen beállított mentést – ez a (magyarországi viszonylatban) közepes cég viszont nem rendelkezett ilyennel. Amikor felhívtak, hogy nem megy a levelezés, s megtaláltuk a “hiba” okát, fokozottan jeleztem nekik, hogy ez miből eredt, újból megígérték, hogy beállítják a mentést – majd bizonyos idő múlva, amikor ismét megkerestek, ugyanezzel a problémával, akkor már szerencsére hajlottak rá, hogy közösen átbeszéljük és kivitelezzük a végleges megoldást.
Send connector gondolatok
Bár mostanában kicsit el vagyok havazva néhány nagyobb migrációval, egy-két apró segítségkérés megoldását próbálom beszorítani az időmbe.
Egyik helyen kértek, hogy nézzem át a levelezés beállításait, ugyanis egy redundánsra elképzelt környezetben pont a redundancia hiányzott – konkrétan sem a levélküldés, sem a levélfogadás nem működött, külső partnerek irányába. A DAG működött, tehát a kliensek tudtak csatlakozni a postafiókhoz, belső levélküldés rendben volt, de szerették volna, ha valóban magas rendelkezésre állást alakítunk ki.
A fogadás témakörét néhány alapbeállítás hiánya (másodlagos MX, tűzfal-beállítás) kimerítette, a küldésnél viszont akár ennek, de leginkább ennek a cikknek az olvasása hiányzott. Létezett ugyan két Send connector, mindegyiknél a “Source” szervereknél ki volt töltve az elképzelt konfiguráció alapján – ettől függetlenül, amikor az elsődleges kiszolgálót leállítottuk, a küldés továbbra is az “ő” küldési csatlakozóján akart kimenni. Természetesen a kiszolgáló leállított állapotában az sem tud küldeni, így a levelek csak gyűltek – az ügyfél és a kollégák pedig értetlenkedtek.
A megoldást többféle módon próbálták megtalálni, ezekből szemezek.
Egyrészt, minden csatlakozón kipróbálták a “Scoped send connector” bekapcsolását. Nos, ez valóban az egyik helyes megoldás, bizonyos feltételekkel: amennyiben a tartományban ki vannak alakítva telephelyek, megfelelő ip-címtartománnyal, s a levelező-kiszolgálók különböző telephelyek tagjai. Ebben az esetben ugyanis csak a saját telephely (és a “Scope” által nem védett) küldési csatlakozóit látja a kiszolgáló, nem fogja használni a “másik” csatlakozóját. Jelen esetben nem volt telephelyes kialakítás, így ennek a pipának a ki/be kapcsolt állapota semmit nem jelentett.
A másik próbálkozás a súlyozásra (költség) irányult. Nos, itt hivatkozok vissza az előbbi cikkre – ugyanis tekintettel arra, hogy a fő telephelyhez elképzelt csatlakozó költsége kisebb volt, mint a második telephelyé, mindig ő lett a kiválasztott. Az, hogy a kiszolgáló épp nem működött, nem zavarta az Exchange-t… Amint egyenlő költséget állítottunk be, a kiválasztási folyamat továbblépett, lehetővé téve a második kiszolgáló csatlakozójának használatát.
Egy másik megoldás, amit mondjuk nem próbáltak, az MX-rekordok alapján történő küldés (ez ugye akkor járható, ha nem DNS-alapú címkeresés történik, hanem smart host-nak küldik). Ekkor felvesszük minkét smart-hostot 1-1 A rekordba, majd azonos névvel, de különböző súlyozással felvesszük a két MX rekordot (egyik mutat egyik A rekordra, másik a másikra).
A megoldások sora tovább folytatódhat, de gondolatébresztőnek ennyi elég…
