Aki szeret elmélyedni a részletekben, annak ajánlom a figyelmébe ezt a word doksit: az összes olyan sémamódosítást tartalmazza, melyeket a 2003-as verzió óta az Exchange okozott, beleértve magának az Exchange-nek a belépését is a címtárba.
Category: active directory
EmployeeID vagy EmployeeNumber? Szerinted mindegy?
A válasz: NEM. Ha igen lenne, talán létre se jött volna ez a cikk.
De kezdjük az elején.
Kb. másfél éve építettünk egy elég nagy rendszert (AD/Exchange). Az ügyfél azzal az igénnyel állt elő, hogy az Active Directory-ba későbbi felhasználásra kerüljön bele a HR rendszerben használt egyedi azonosító.
Körülnéztem, hogy mit lehetne erre használni, és arra jutottam, hogy van két attribútum: Az EmployeeID és az EmployeeNumber. Nagyjából pénzfeldobással az elsőre esett a választás.
Az AD feltöltése kapcsán némi PowerShell scriptel ez kitöltésre is került.
Azt nem tudom, hogy az elmúlt időben használták-e ezt valamire, de két napja előjött az igény, hogy az EmployeeID jelenjen meg az Outlookban, a címlistában (GAL/OAB).
Az ügyfél azt is kibogarászta, hogy az Exchange-ben van egy Details Template Editor, amivel a kliens oldalon pl. a GAL-ban tárolt felhasználók tulajdonságlapjának megjelenését lehet beállítani (ez számomra újdonság volt, de mindig tanul az ember). A probléma csak az, hogy itt a választható attributumok között nem találta meg az EmployeeID-t.
Keresgélve ezt találtam:
http://blogs.technet.com/b/exchange/archive/2010/03/10/3409495.aspx
Ebből az derül ki (amit alapból is sejtettem), hogy egy AD attribútum, akkor jelenhet meg a GAL-ban, ha benne van a GC-ben. Tehát fogtam magam és bekapcsoltam, hogy az EmployeeID megjelenjen a GC-ben.
Három órával később az ügyfél jelentkezett, hogy a Details Template Editorban még mindig nem látja az EmployeeID-t.
Ma reggel ránéztem, és tényleg nincs ott. Újabb google. Az eredmény:
http://exchangepedia.com/2008/06/modifying-display-templates-and-additional-attributes.html
http://mostlyexchange.blogspot.hu/2005/03/adding-attributes-to-exchange-details.html
Tehát rövden:
Csak olyan AD attribútum jelenhet meg a Details Template-ben aminek van mAPIID-ja. Az EmployeeID-nak nincs, az EmployeeNumber-nek meg van. Remek.
Két megoldás kínálkozik. Vagy átpakoljuk az összes EmployeeID-t az EmployeeNumber-be, vagy az EmployeeID-nak csinálunk mAPIID-t.
Az első egy rövid PowerShell script, a második pedig egy kőkemény hegesztés, ami ráadásul nem is támogatott…
Az állandóan kinyírt rekord esete
Telefon az ügyféltől: nem tudja, mi van, de hülyén viselkedik az Exchange. Például nem lehet postafiókot létrehozni, pedig tegnap még lehetett, ráadásul a hibaüzenet is zavaros.
A hibaüzenet tényleg elég zavaros volt. Megnéztem az eventlogot, tele volt szórva AD hibával. Oké, akkor nem is az Exchange hülye, hanem az AD. Vizsgáljuk meg.
Alapvetően egyszerű felállásról volt szó, két DC, az FSMO szerepkörök szépen elosztva, mindkettő GC. Ezek melllett pöfögött egy Exchange szerver. Tényleg nem bonyolult.
Nézzük az AD-t. Teljesen meggárgyult. A címtárreplikáció szétesett, a DC1 gyakorlatilag eltűnt a rendszerből. DNS. AD integrált. Az SRV rekordok rendben. Akkor miért nem látják? Azért, mert az A rekordja tűnt el. Azaz az SRV rekordok alapján az Exchange is, meg minden más gép is kereste volna (RIDm/PDC/IM/GC is a szerencsétlen), de az A rekord híján nem érték el. Oké, ez egyszerű eset. Az egyik irányban működött a replikáció, így felvettem az A rekordot az egyik gépen, meghúztam a replikációt, átkerült a másik gépre is, pár perc és teljesen helyrejött az AD.
De miért tűnhetett el az A rekord? Két lehetőség van, dinamikus rekord volt, és a scavenge kinyírta, vagy valaki direktben törölte. Megnéztem a beállításokat, de semmi. Azaz nem volt beállítva takarítás, hiába járt le egy bejegyzés, attól az még bent maradt a zónában. Akkor maradt a manuális törlés. Lesz egy kínos beszélgetés a helyi rendszergazdával.
Na, mindegy, nézzük, mit lépett a rendrakásra az Exchange? Új postafiók… és ugyanaz a hiba. Ne te, már. Hát meggyógyítottam a címtárat! Itt van, ni: nslookup dc1… nincs ilyen rekord. Mi van? Visszatekertem a DC-re, megnéztem a zónát: tényleg eltűnt a bejegyzésem. Izé… lehet, hogy mégsem a helyi rendszergazda törölget? De akkor ki? A scavenge ki van kapcsolva mind a két DC-n, meg egyébként is, statikusnak vettem fel a rekordot. Vegyük fel újra. Hátha most nem tűnik el. (Ez a legnagyobb marhaság, reménykedni abban, hogy csak elégszer kell próbálni, aztán egyszer jó lesz. De legalább megy vele az idő, lehet gondolkodni.) Kábé 10 perc után a rekord megint törlődött, méghozzá a DC1 törölte. Egy botor próbálkozás: DC1 netlogon service újraindít, de semmi.
Azt hiszem, valami érdekeset fedeztem fel: fekete lyuk az informatikában.
Gondolkodjunk.
AD integrált DNS zónában egy rekord törlése az valójában meglehetősen bonyolult folyamat. Egyrészt van magának a dinamikus DNS-nek a törlési folyamata (lejárat, érzékenység, scavenge időzítés), másfelől pedig a rekord maga is egy AD objektum, azaz elosztott, multimaster replikált adatbázisban lakozik. Sírkő. (Ha esetleg valaki nem lenne tisztában vele: elosztott, multimaster adatbázisban nem egyszerűen törlünk, mert az nehezen replikálódna át. Ilyenkor az objektum kap egy sírkövet, miszerint már valójában halott, és ez a sírkő feltét replikálódik. A sírkövön szerepel az is, hogy meddig tartózkodik még az objektum az adatbázisban. Utána eltűnik, sírkövestől együtt.)
Jelen esetben a dögeltakarítás (scavenge) nem működött, tehát csak a sírkövezésre kellett koncentrálnom. Mivel AD objektumról van szó, értelemszerűen elő kellett kapni az Adsiedit-et. (Vigyázat, a DNS zónákat nem ajánlja fel helyből, nekünk kell tudnunk, hogy milyen szintű integrációt állítottunk be és annak megfelelően beírni vagy a DomainDNSZones vagy a ForestDNSZones partíciók DN értékét.)
És igen, szépen ott is volt a kinyírt rekord, a dNSTombstoned tulajdonsága pedig True. Tehát akármi is nyírta ki, az az AD szintjén történt. Visszabillentettem az értéket False-ra, és hátradőlve vártam, hogy megjelenjen a DNS konzolban is. (A netes forrásom szerint meg kellett volna jelennie.) Hát, nem. Ez a rekord szégyenlősebb volt annál. Akkor most mi van? Rosszabb már úgysem lehet a helyzet, kitöröltem Adsiedit-ből is, aztán a konzolból újra létrehoztam. Erre visszajött a rekord, a változója üresen állt, ellenben létrejött mellette egy tipikusan sírkövezéskor előforduló, név+guid nevű objektum is. Na, ebből mi lesz? Vártam tíz percet. Az lett, hogy az eredeti rekord eltűnt, a guidnevűből eltűnt a guid, maradt egy bejegyzés, de a tombstone már be volt kattintva. Azaz eltűnt a törölt, az új vette át a helyét, de az is egyből töröltre jelölt lett. A nénikéd.
Akkor workaround. Villámkezű Joe. Felvettem újra az A rekordot, meghúztam a replikációt, AD helyreállt, gyorsan átmozgattam az FSMO-kat a DC2-re, GC a DC1-en lekapcsol, újból meghúztam a replikációt, az Exchange szerveren a DNS kliens beállítást átírtam a DC2-re, magán az Exchange-n is mindenhol beállítottam, hogy a DC2-t használja. AD Topology (és vele még 7 egyéb) service újraindít, IISreset. Gyors ellenőrzés, még megvolt a DC1 rekordja. Oké, teszt. Új postafiók. Ugyanaza a hiba.
Vicces. Mindez péntek délután.
Ekkor vettem a fáradtságot, hogy értelmezzem az Exchange egyébként borzasztóan nem odaillő hibaüzenetét. Vazzeg. Azt írja, hogy az Address List service hülyült be. Az viszont valójában a System Attendant, mely kimaradt a nagy újraindítási hullámból. Restart. Postafiókteszt. Működött. Hurrá. DC1 bejegyzés? Már eltűnt. Most ez is hurrá, mert ez azt jelenti, hogy az Exchange már megy, a DC1-től függetlenül, azaz innentől ráérek az állandóan kinyírt A rekorddal foglalkozni.
A gond csak az, hogy semmi ötletem nem volt. Áttúrtam a netet, remek írásokat találtam arról, hogyan lehet auditálni a DNS-t, ahhoz, hogy elkapjuk a rekordtörlő rendszergazdákat. De itt magát a rendszert kellett volna elkapni, arra meg nem vonatkozik az audit. Végül úgy döntöttem, hogy marad az atombomba. Életre rángatom megint az AD-t, aztán DC1 demote (és bízom benne, hogy lemegy 10 perc alatt), az immár member szervert átnevezem, aztán DC3 promote.
Előtte feltettem a teavizet. Míg a konyhában kortyolgattam a teát, eszembe jutott, hogy adjunk egy esélyt a mágikus újraindításnak. Veszíteni nem veszítek vele semmit. A tea után meg is történt a restart – és csodák csodája, egyből létrejött a DC1 A rekordja! Igaz, dinamikus bejegyzés lett belőle, ezt gyorsan átírtam statikusra… és vártam. Elég sokat. 25 perc után kezdtem csak elhinni, hogy meggyógyult az AD, hiszen továbbra is élt az A rekord. Romeltakarítás.
Case solved. (Azt most ne firtassuk, hogy hétórányi szopást tudtam volna megúszni, ha egyből a restartot választom.)
Hogy mi volt az a rejtélyes krokodil, mely tíz percenként előbújt és leharapta az AD-ból a DC1 A rekordját, azt nem tudom és valószínűleg nem is fogom megtudni. Annyit sikerült kiderítenem, hogy két héttel ezelőtt volt egy áramszünet, mely levágta a Hyper-V hostgépet és nyilván mentek vele a virtuálisak is. (Pl. a DC1.) Utána minden visszaindult és látszólag rendben is volt. Látszólag. A mai napig.
ps.
Mondjuk, nekem még igen büdös volt az el-eltűnő A rekord objektum dSCorePropagationData tulajdonságának az értéke is. A DC2 esetében a tulajdonság értéke 0x0 volt, amikor a DC1 megjavult, akkor az övé is, de amíg rossz volt, addig az aznapi dátum volt benne. Sajnos nem találtam semmi infót, hogy konkrétan ennél az AD objektumnál ez a tulajdonság mire szolgál (úgy egyébként az öröklődés szabályozásához van köze, de ennyi a konkrétum: “This attribute is for internal use only”). Ráadásul még csak nem is módosítható.
Tipikus
Az a mém megvan, hogy ‘váratlanul megjavult magától’?
Trust kapcsolat egy multi két leányvállalata között. A végpontok különböző országokban, a központ meg valahol Európában. Egyszer csak ügyfél jelzi, hogy nem működik a trust. Megnézem, tényleg.
Network ellenőrzés, kiderül, hogy valahol blokkolják az udp389-et. Levél elmegy mindegyik országba, plusz a központba: – Uraim, nézzenek utána, mi van a tűzfalakon/routereken? Levelek vissza. Kivétel nélkül mindenhonnan azt írják, hogy leellenőrizték és a port mindenhol engedélyezve van.
Csak éppen onnantól megint működik a trust.
Ki mennyire autoritatív?
Érdekes jelenségbe futottam bele a napokban. Különböző tartományok felé DNS lekérdezéseket kellett volna futtatnom – és nem igazán értettem az eredményeket.
De ehhez egy kis ismétlés.
Anélkül, hogy túlzottan belemennék a DNS részleteibe: tudjuk, hogy vannap primary zónák, vannak AD integrált zónák… de ezek most hidegen hagynak minket.
A finomságok a secondary és a stub zónáknál kezdődnek, illetve bejönnek a képbe a zónadelegálások is.
Secondary zóna:
A primary (elsődleges) zónát tükrözi le egy másik DNS szerverre, gyakorlatilag teljes egészében.
Stub zóna:
Szintén tükröz, de nem az egész zónát, hanem csak az A, NS és SRV rekordokat szedi le.
Zónadelegálás:
Megadjuk, hogy egy hozzánk tartozó zóna alzónájának ki a DNS szervere. Ez tetszőleges külsős DNS szerver is lehet.
És akkor a konkrét jelenség. Nemzetközi környezet, tartomány tartomány hátán. Szeretném megtudni az egyes tartományok MX rekordjait. Aztán nem mindegyikét kapom meg. Viszonylag hamar kiderült, hogy ahol stub zóna van, ott megkapom, ahol meg zónadelegálás, ott nem.
Mondanom sem kell, a névfeloldás mindegyik esetben tökéletesen megy – de az MX rekord beszerzése nem egy egyszerű kérés.
nslookup
ls -t MX kerdeses.domain
Stub zóna esetén vagy megkapom a kérdéses MX rekordot, vagy jogosultsági hiányosságból kifolyólag elutasítanak. Delegált zóna esetén viszont azt kapom vissza, hogy a zóna ismeretlen. Pedig – mint írtam is – a névfeloldás remekül megy, azaz dehogyis ismeretlen a zóna.
Keresgélés a neten. Azt írja a DNS hibakereső doksi, hogy ha nem autoritatív DNS szervert kérdezek, akkor jöhet ilyen üzenet. Ellenteszt: delegált zónánál kiegészítettem a lekérdezést:
nslookup
server a.zona.eredeti.dns.szervere.ahova.a.delegacio.mutat
ls -t MX kerdeses.domain
Láss csodát, egyből működött.
Ezzel akár már elégedett is lehetnék, de nem hagyott nyugodni a kisördög. Most akkor mi van a stub zónával? Gyors teszt: a stub zóna is non-authoritative választ ad, tetszőleges lekérdezésre. Azaz olyan rekord esetén is, mely egyébként már letükröződött a helyi DNS szerverre. Akkor meg miért működik az MX lekérdezés? Ha mindkét módszernél egyformán nem-autoritatív a kérdezett helyi szerver, akkor miért működik az MX lekérés a stub zónánál és miért nem a delegálásnál?
Nyilván azért, mert a stub egy hajszállal autoritatívabb, mint a delegálás.
Rasszista TLD
Kutyafuttában, mert tényleg őrült nagy hajtás van.
Belecsöppentem egy újabb remek nemzetközi projektbe. A héten megy az adatgyűjtés, illetve a tesztlabor összerakása. Nem kicsi laborról van szó, rögtön indulásképpen 5 tartományból álló erdőt kell összekötözni két másik erdővel.
A külső erdőknél igyekeztem semleges nevet választani. Az első az lett, hogy akarmi.akarhol. Szépen le is mentek vele a kísérletek. Ekkor derült ki, hogy az egyik partner élesben már Windows 2008 erdőt használ, tehát azt is le kell tesztelnünk. Így jött be még egy erdő, ennek roppant frappánsan az akarmi.akarhol.2008 nevet adtam. Tartomány működik, kliensgépet be lehetett léptetni.
A DNS rendszereket összelőttem, nslookup oda-vissza feloldott minden címet, minden tartományban. Oké, a biztonság kedvéért jöjjön egy ping. Semmi. Nincs ilyen cím.
Aha. Biztosan elgépeltem. A felfelé nyíllal elővettem a korábbi sikeres nslookup sort, átírtam pingre – nincs ilyen cím.
Aztakurva. Ezt meg akkor hogyan? Az nslookup feloldja a címet, a ping meg nem? Dehát nem ugyanazt az algoritmust használják? Mi van itt?
Egy bájos, nem túl gyakran kommunikált bug. Pedig valamikor mintha olvastam volna róla, csak most későn jutott eszembe: a TLD nem lehet szám. Azaz a tartomány nevében bárhol használhatok számot, de a legutolsó elem nem lehet az.
Lebontottam az új tartományt, létrehoztam egy másikat akarmi.akarhol.longhorn néven – és azóta is tökéletesen megy minden.
Csak éppen kiesett egy fél nap. Azon meg már nem is morgok, hogy valami, akármelyik fázisban, igazán figyelmeztethetett volna, hogy ‘hé, te, ez a cím nem lesz frankó mindenhol’.
MI SE, még mindig
Tehát ott jártunk, hogy boldogan lejelentettük, miszerint itt van az összes cím, barátaim, feleim, levelezzetek.
Aztán jött az indignált újabb bejelentés. Oké, a cím ott van, de ha levelet küldenek neki, akkor másodpercen belül hibaüzenet jön vissza. A levelet nem lehet kiküldeni.
Nézzük, mi is van az NDR-ben? A következő felhasználó nem létezik: IMCEAEX_******@cegnev.hu.
Naná, hogy nem. Szépen is néznénk ki, ha létezne. Ja, hogy mi is ez az IMCEAEX***? Írtam már róla, olvasd el bátran. De ha nem akarod, rövid összefoglalás: ez egy kapszulázás. Ha valakinek nincsen SMTP címe, akkor az Exchange az egyéb címéből (x.400) szigorú szabályok alapján gyárt egy meglehetősen bonyolult smtp címet, majd ezzel küldi el a levelet. Aztán a válasznál meg – a szigorú szabályok ismeretében – kikapszulázza, azaz az IMCEAEX_****@cegnev.hu címből visszafejti az x.400 címet és oda küldi tovább a levelet.
Nos, ez mind szép, de hogyan kerül ez a sáros bakancs az asztalra? Itt a _címzett_ kapott IMCEAEX címet! Az Exchange 2007 ennyire optimista lenne? Azt mondja, nem lát a címzettnél SMTP címet, tehát abszolút vaktában hasra üt, legyárt egy IMCEAEX_****@cegnev.hu címet és bízik benne, hogy ha a túloldalon kikapszulázzák, akkor pont lesz olyan x.400-as cím? Bizony, így. Ne tudd meg, mennyi felháborodott levelet kaptam, hogy honnan meri az Exchange a @cegnev.hu tartományba küldeni a török, cseh, lengyel és még mittudoménmilyen leveleket? Hát ennyire hülyék vagyunk?
Ehe. Mosoly nyáladzó szájszéllel. Igen, reménytelenül debilek vagyunk.
Aztán elkezdtem kisérletezgetni… és a helyzet egyre durvább lett. Küldtem egy új levelet. Kiválasztottam a címzettet a Worldwide címlistából. Kiváncsiságból ránéztem a tualjdonságlapjára, gyönyörűen ott voltak a tulajdonságai, köztük a jó SMTP cím is. Oké. Elküldtem. Már jött is vissza az NDR, benne az IMCEAEX-es címmel.
Miaf?
Eljátszottam ugyanezt OWA-ból is. Tökéletes. A levél elment. Hát ezt meg hogyan? Elméletileg mindkét levél ugyanazt az útvonalat kell, hogy bejárja. Hát itt már semmi sem úgy működik, ahogyan működnie kellene?
Nézzük meg EMC-ből, látjuk-e az összes kontaktot. Feljött egy hibaüzenet. Lehet, hogy pont a mi emberünk sérült? A hibaüzenetre kattintva üres ablak jött elő. Hmm… lehet, hogy 40000 kontaktnál várni kell egy kicsit? Otthagytam éjszakára. Másnap reggel még mindig üres volt az ablak. Hmm. Ott van egy üzenet az alján, hogy a ‘ctrl+c’ kiteszi vágólapra a szöveget. Legyen. És tényleg, a notepad-ben már ott is volt a lista. Lehet, hogy valami idióta fehér betűkkel írta ki az ablakban fehér háttérre a listát? Már ezen sem lepődnék meg. Mindenesetre kellemetlen, a keresett cím nincs a hibások között. (Megjegyzem, itt is látok cuclizási lehetőséget: a hibás címek azért hibásak, mert space van a display név elején, illetve végén. Főbelőni. Mindet.)
Egy gyors, de bátortalan pillantás a GC adatbázisba. (Ugye tudod: ldp, a 3268-as porton.) Ott volt szépen a kontakt.
Eddig tartott a dal. Habár szívesen elmolyoltam volna még napokat a problémán, de mivel priority2-vel jelentették be, így ha nem akartam SLA-t sérteni, eszkalálnom kellett. PSS.
Hosszú beszélgetések. Lista, hogy miket küldjek el.
Aztán az ldp dump-ban a Sólyomszem Brigád kiszúrta, hogy a vizsgált kontaktnak üres a legacyExchangeDN értéke. (Konkrétan, nem szerepelt a dump-ban. Ugye tudjuk, hogy az ldp csak azokat a tulajdonságokat listázza, melyeknek van értéke.) Szinte hallani lehetett, ahogy a felfelé görgetett kőgolyó átbillent a csúcsponton.
– Ez baj – hívott vissza a mérnök.
Adtunk a kontaktnak. Mármint értéket.
Itt kellett megemelnem a kalapomat. Azt, hogy üres a legacyExchangeDN – különösen a korábban belinkelt cikk alapján – valószínűleg előbb-utóbb én is megtaláltam volna. De mit kellett volna beírnom? A kontaktnak volt vagy tíz x.500-as címe. Melyik legyen a legacyExchangeDN?
A mérnök segített: egyik sem. A legacyExchangeDN mindig a _helyi_ objektum helyzetére vonatkozik. Hiába tolják ki ugyanazt a kontaktot Amerikából Japánba, Grönlandra és Budapestre – a legacyExchangeDN értéke mindenhol más és más kell, hogy legyen. Míg az x.500 címe pedig annak a nyomát mutatja, hogy az objektum honnan hová lett migrálva.
Itt kezd a szituáció logikussá válni. Az elején, mondjuk, nem néztem volna ki belőle. Hogyan is működik a MIIS? Legyártja a távoli címtárban a kontakt objektumot. Ír neki legacyExchangeDN értéket? Hát, miért írna, amikor arra találták ki a helyi RUS-t? Majd amikor az végigmegy a recipienteken, akkor beírja a helyes értéket. (Hasonlóképpen békén hagyja a ShowInAddressBook értéket is. Ezt majd beállítják a helyiek.)
Ja, hogy az Exchange 2007-ben nincs RUS? Cucl.
Megoldási lehetőségek?
Elvégezni a RUS munkáját – azaz valamilyen jól definiált pontban mindenhová, ahol üres a legacyExchangeDN mező értéke, beírni a jó értéket. Yep. Mi lesz a jól definiált pont? Hát, nemrég derült ki, hogy az MIIS szinkronizáció után úgyis szkriptből kell frissítenünk a címlistákat. Akkor nincs is más hátra, mint ki kell bővíteni a szkriptünket.
Ja, a legszebbet meg nem is mondtam. Honnan tudod, hogy az adott környezetben mi lenne a kontakt helyes legacyExchangeDN értéke? Mindegy. Nem kell tudnod. Elég, ha felolvasod a kontakt objektum tulajdonságait, majd visszaírod. Ekkor a rendszer automatikusan beírja a legacyExchangeDN értéket.
Így: get-mailcontact “user-alias” | set-mailcontact.
Nyilván, tömeges módosításnál játszani kell a szkóppal (nem elég az alias), meg illenék rá is vizsgálni, hogy üres-e az érték vagy sem… dehát ez már mind iszonyúan részletkérdés.
MI IS helyett MI SE
Irkáltam már arról az ügyfelünkről, akik kinyitották a szelencét és rájukborult 40000 kontakt. (Egyik, másik, harmadik.) Köszönik szépen, élnek még… de ez a rengeteg cím, melyet csak a dolgozók kb 5%-a használ, továbbra is komoly problémát okoz nekik.
Különösen úgy, hogy a közelmúltban álltak át Exchange 2007-re.
A legszebb ugyanis az volt, hogy elméletileg semmi problémát sem lenne szabad okoznia ennek a tömérdek címnek… de valahogy éreztem, hogy nem lesz ez olyan sima menet.
Akik nem akarják elolvasni a kilométer hosszúságú előzményeket, azoknak összefoglalom:
- Trükkös módon a Global Address List mögött kicseréltem a keresőfeltételt, így csak a helyi címek kerültek bele. Ezt mindenki boldogan használta.
- Létrehoztam egy Worldwide nevű listát, mely mögé odatettem az eredeti GAL keresőfeltételét. Ha az az 5% külföldre akarat írni, akkor címlistát váltott.
Még egy technikai előzmény. Az egyes nemzeti leányvállalatok között a címlista szinkronizáció úgy zajlik, hogy a tengerentúlon egy MIIS szerver felolvassa a felhasználók smtp és egyéb címeit, beledolgozza egy adatbázisba, majd mindenkinek a címtárába visszatolja a címeket, mail kontakt objektum formájában. Ez az a bizonyos negyvenezer, ki dalolva ment.
Az átállás után kezdtek rendeződni a sorok, kezdtek beérkezni az első rejtélyes panaszok.
(Nem tudom, ki hogy van vele, nekem ez a legnehezebben elviselhető időszak. Én általában beleadok apait-anyait, heteken, hónapokon keresztül megfeszítetten dolgozok, hogy időre tökéletesen működjön az új rendszer. Ez általában össze is jön, maximum a haragosaim száma növekszik. És amikor hátradőlnék, arcomon az elégedett mosoly, miszerint ‘használjátok, népeim, nektek csináltam…’ majd várnám a dicséreteket… azok valahogy nem jönnek. Egy csepp sem. Ezzel szemben beindulnak a hőbörgések. Hogy micsoda szar ez. Nem tudja ezt, meg azt. Ja, meg minden máshol van. És rossz! Majd jön, hogy mindezért ki is a felelős? A megrendelő persze elkezdi védeni a seggét, hogy ők sem így akarták. Eh.
Nyilván oktatással mindezt ki lehetne védeni, de az ügyfél helyett nem tudom tanítani a felhasználóit, különösen, hogy ezt rendszeresen nem rendelik meg. Így pont akkor, amikor a legfáradtabb vagyok, pont akkor, amikor az asszertív szóról maximum annyi jut eszembe, hogy biztosan egy perzsa hadvezér lehetett, szóval pont ekkor kellene türelmesen elmagyaráznom az embereknek, hogy nem szar, csak más.
Nem szokott sikerülni.
És a legdurvább az, hogy az esetek 1-2%-ában a bejelentőnek tényleg igaza van. Csak ez nem derül ki elsőre. Ilyenkor még elnézést is kell kérnem a végén.)
Nos, ilyen elnézéskérős esetekről lesz most szó.
Az első bejelentés az volt, hogy néhányan hiányolták a Worldwide listákról a külföldi ismerőseiket. (Ja, mondanom sem kell, külföldre leginkább a VIP-ek leveleznek. Ezt, mint türelmetlenségi faktort tessék figyelembe venni.) Megnéztem… és tényleg. Először felrémlett bennem a GAL és annak cefettül bonyolult szerver- illetve kliensoldali függőségei… de aztán lehiggadtam. A Worldwide lista sima Address List, azaz egy szűrő a Global Catalog adatbázisra.
De akkor hogyan lehet, hogy nem kerül bele egy kontakt? Ugyanis a címtárban megnéztem, a kontakt objektumot a MIIS rendesen beletojta az OU-ba.
Aztán később eszembe jutott, hogy valahol olvastam már ilyesmiről. Aztán még később eszembe jutott, hogy nem is olvastam, hanem írtam. Ebben a könyvben. (Igen, öregszem. Igen, én is leszek szenilisek.) Konkrétan arról van szó, hogy az Exchange 2007-ből kiműtötték a RUS-t. Ez a szolgáltatás nem csak a recipient policy-k betartásáért felelt, hanem minden kötegelt, asszimetrikus műveletért. (Mi is az, hogy asszimetrikus? Bekattintok valamiket, aztán csak pár óra múlva fut le egy kötegelt folyamat, mely érvényesíti a hatásokat.)
Tipikusan ilyen folyamat volt a címlisták tagságának érvényesítése is: a RUS megvizsgálta az egyes címlisták szűrőfeltételeit, majd minden recipient objektumra bejegyezte annak a címlistának a nevét, amelyiket a szűrőfeltétel eltalált. (Nem, nem röptében történt a szűrőfeltétel érvényesítése. Ezt nem igazán bírták volna a GC-k.)
Az Exchange 2007-ben ez megváltozott. Amikor létrehoztunk egy recipient objektumot, akkor egyből rá is esett minden, aminek kellett. Ha bármit piszkáltunk rajta, akkor szintén. De kötegelt folyamatok már nincsenek.
Látjátok már a kiskaput? Amikor a MIIS tojja be a kontaktot, akkor megkerüli a folyamatot. Létrejön egy új kontakt, de nem jegyződik be rá, hogy ő mind az ‘All Contact’, mind a Worldwide címlistának a tagja lesz. Nem is lesz. Jogos az ügyfél reklamációja.
Szerencsére a megoldás nem túl bonyolult: mivel a kontaktok éjjel jönnek, reggelre be kell időzíteni két EMS parancsot:
update-addresslist -identity “All Contact\”
update-addresslist -identity Worldwide
Ahogy mondani szokás, az ördög a részletekben lakik. A mocsok.
Időzítettél már be EMS parancsot Windows 2008 szerveren? Ráadásul olyat, melyhez Exchange Organization Administrator (Atyauristen) jogosultság kell?
Egy élmény.
- Létrehozol egy kellő erősségű felhasználót, nem lejárós jelszóval.
- Létrehozol egy könyvtárat ‘d:\scripts’ néven, úgy, hogy csak az Atyauristen nevű felhasználónak legyen benne írási joga.
- Létrehozol egy frank-drebin.ps1 nevű fájlt, melybe beleírod a fenti két parancsot.
- Elindítod a Task Scheduler konzolt és ugyanazzal a mozdulattal beveszel egy marék Seduxent.
- Beidőzíted a taszkot, beállítod a felhasználót, tesztelsz. Természetesen nem fog történni semmi. Hogyan is gondoltad, hogy egy Exchange szerver fel fogja ismerni az Exchange Management Shell (ps1) parancsát?
- Indul a vajákolás. Először is szeretnéd látni, mit is ír ki futás helyett a szkript. Ehhez volt régebben a /i (interactive) kapcsoló. A grafikus felületen nyoma sincs. Parancssorban? A-ha. /IT lett belőle. De nem is ez a lényeg. Hanem az a megjegyzés, hogy ilyesmi csak akkor van, ha a felhasználó ténylegesen be is van jelentkezve. Eszedbe jut, hogy volt egy rádiógomb, miszerint
– Run only when user is logged on
– Run whether user is logged on or not
Nos, bármilyen furcsa is, az első jelenti az interaktív futást, a második a nem interaktívat. Tudnak fogalmazni a fiúk, szó se róla. - Most már látod, hogy egyszerűen az operációs rendszer nem tud mit kezdeni a .ps1 fájlokkal. Megkíméllek a rengeteg utánajárástól, a következőket kell beírnod:
– A program/script mezőbe: c:\windows\system32\windowspowershell\v1.0\powershell.exe
– Az add argument mezőbe: -psconsolefile “c:\exchsrvr\bin\exshell.psc1” -command “. ‘d:\script\frank-drebin.ps1′”
Feltéve, hogy az Exchange alkalmazást a C:\exchsrvr könyvtárba telepítetted. - Azt hiszed, mi, hogy működik? Hát nem. Megjelent az eddig még csak barlangjában szunyókáló UAC. Nem fog lefutni a szkripted, mert hiába vagy maga az Atyauristen, ha nem Atyauristen módban indítottad. Na jó, de hol lehet? A fene tudja. Nézzük meg a runas parancsot… semmi. Csak a jó öreg /savecred van, de az már kilenc évvel ezelőtt is maximum vicc volt. (Jelszót beleírni a parancsba… egy mindenható felhasználónál. Aha.) Na jó, nem csigázlak, ezt a csekkbokszot kell bebillentened: ‘Run with highest privileges’. Biztos ugyanaz a mókus fogalmazta, aki az előző objektumot. Még az is lehet, hogy ideológiát is gyártott hozzá: security through obscurity, azaz hülye ember ne tudja már beállítani. Mintha ez a fajta védekezés valaha is ért volna akár egy koszvadt hajítófát is.
És nagyjából ennyi. A szkriptünk minden reggel lefut, a nevek pedig megjelentek a Worldwide címlistában.
Csak éppen levelet nem lehet küldeni nekik.
De ez már majd a következő írás témája lesz.
Beszéljünk nyelveket
Velem mostanában nem történik semmi érdekes: tervezek ugyan egy többrészes ismeretterjesztő cikket, de ahogy mostanában a csillagok állnak, problémamegoldást, nyomozást ne nagyon várjatok tőlem.
Inkább leírom, hogyan járt egy kollégám a napokban.
Exchange 2007-et kellett telepítenie. Ez ma már szerencsére nem annyirra horror, mint eleinte. (No, nem azért, mintha egyszerűbb és hibátlanabb lenne: csak már annyian szívtak vele, hogy mindenre megvan a megoldás a neten.)
Neki is állt. Nyilván először végigolvasta a feltételeket. Ki is pipálta mindegyiket. Ugyan volt egy pont, ahol elgondolkodott egy kicsit, de végül csak rálegyintett. Arról volt szó konkrétan, hogy a telepítési doksik szerint minden érintett tartományban lennie kell legalább egy minimum Windows 2003 Server Sp1 DC-nek, plusz a Schema Master-nek is minimum ennek kell lennie. Ez bőven meg is volt, mindenhol SP2-es volt a környezet… csak éppen az összes DC magyar nyelvű volt. (Kéretik nem anyázni, mi azzal dolgozunk, ami az ügyfélnél van.)
Végül belevágott. Rögtön az első lépésben fejreállt a setup /preparelegacyexchangepermissions. Káromkodás, nyomozás. Nyilván először az ember a triviális problémaforrásokra koncentrál, no meg persze a hibaüzenet is eléggé félrevezető volt. Nem talált semmit. Többször is beszéltünk, de én se tudtam neki segíteni. Maximum annyit, hogy toljad haver a guglit ezerrel, mert ha ott sem lesz megoldás, akkor sehol sem. Tolta. Végül egy órával később jött a telefon, hogy oké, minden rendben.
Mi is történt?
Mielőtt elmélyednék a válaszban, egy gyors segédinformáció. Miért is kell annyira az Exchange 2007 szervernek minimum a Windows 2003 SP1? Azért, mert az SP1-ben jött be egy úgynevezett Service Notification funkció. Ez azt tudja, hogy bármi változás is történt a címtárban, akkor erről értesíti az érintett alkalmazásokat. Az Exchange 2007 erősen épít is rá.
Na most, ha te lennél egy Exchange setup folyamat programtervezője (és a végeredmény alapján simán lehetnél is, sőt , ahogy elnézem, akár az Újpest Központ metróállomás nyáladzó hajléktalanjai is lehettek volna), akkor hogyan ellenőriznéd, hogy a DC-k megfelelőek-e? Én – és a hajléktalanok – valószínűleg úgy, hogy rávizsgálnánk, működik-e ez a szolgáltatás. A fejlesztők nem ezt az utat választották: ránéztek egy registry értékre, hogy oda mi van beírva. Angolul. Tehát a Windows Server 2003 Service Pack 1 nyilván jó, ha a végén a szám nagyobb, mint egy, az még jobb… és ennyi. A Windows Server 2003 Szervízcsomag 1 például már nem volt jó.
Most gondolj bele, hogy már csak strukturálisan, logikusan nézve is, mekkora baromság ez? Ha egy funkcióra vagyok kíváncsi, akkor nem a funkció működését vizsgálom, hanem egy tőle független karakterlánc értékét. Miközben nem tudom, mit csinál a másik kéz… mely egész egyszerűen nem angolul írja be a karakterláncba az értéket.
Miután a kollégám rájött, át is írta adsiedittel a DC tulajdonságainál a megfelelő értéket. Egyből lefutott a jogosultsági rendszer preparációja. Kolléga boldogan felsóhajtott, kiment, ivott egy kávét, kifújta magát. Majd visszament és beírta a sorban következő parancsot: setup /prepareschema.
Zsíros hibaüzenet.
Tekintve, hogy kollégámnak ez volt az első találkozása az Exchange 2007 szerverrel, egész pontosan el tudom képzelni, mit gondolhatott ekkor. De nem fogom leírni. Habár ez nem egy prűd blog, de egyáltalán nem vagyok benne biztos, hogy a monitorod ilyen szinten is elviselné a túl erős kifejezéseket.
Gyors ellenőrzés a registry-ben… és igen: amíg ő kint kávézott, egy automatikus mechanizmus észrevette, hogy módosítva lett a szerver verziószáma. Természetesen gyorsan javította is. Melytől persze ismét fejreállt az Exchange telepító. Ha valaki hülye, akkor az legyen következetesen is hülye.
Innentől nyilván gyorsan ment a prepare folyamat: kolléga minden parancs kiadása előtt megnézte a registry-t és ha kellett, javított. Aztán most már csak reménykedünk, hogy a működés során ez az idióta hiba nem fog többször előjönni.
ps.
Kolléga végül átküldte a linket, ahol megtalálta a megoldást. Külön jól esett, hogy az eset a magyar Technet blogban fordult elő, és viszonylag kevés felesleges kör lefutása után Flowman kolléga be is írta a helyes megoldást.
Csak azt magyarázza el valaki, hogy ez miért a német nyelvű Technet blogon jelent meg?
Ez nem fair
De tényleg. Azt hittem, hogy ezen a szinten már nem érhet meglepetés. Ha az ember profin hajt egykerekű bringát, akkor nem lehet kihívás a tricikli.
Címtárpreparálás, Exchange 2007 bevezetés előtt. Erről már mindenki leírt mindent, amit csak lehetett. Kockázatos művelet, de ha az ember odafigyel, meg bebiztosítja magát, nem lehet belőle baj.
Ment is minden. Egy ideig. A ‘setup /preparelegacyexchangepermissions’ simán lefutott. A ‘setup /prepareschema’ is… pedig ennél rágtam a legtöbbet a körmöm. Jöhetett a ‘setup /preparead’. Ettől már nem tartottam, hiszen ez már nem szánt olyan mélyen a címtárban.
Aztán kaptam egy valag hibaüzenetet:
The name property contains leading or trailing whitespace, which must be removed.
Hmm… elméletileg egy szavam sem lehet. A Microsoft standard-hez képest kifejezetten korrekt hibaüzenetet kaptam. Pontosan megmondta, mi a hiba.
Csak azt nem, hogy hol.
Hány olyan objektum van, amelyiknek van ‘name’ tulajdonsága? Az összesnek. Cca pár millió lehet az ügyfél rendszerében. Hogyan látod meg, ha whitespace van a név végén? Sehogy.
Na, ez a kihívás, nem a tű a szénakazalban.
Kezdjük szokás szerint a guglinál. Három találat. Elég vérszegény. Az első egy fórum, ahová egy hapi bedobta ugyanezt a kérdést. Választ nem kapott. A második ennek a fórumnak letükrözése. A harmadik meg egy pdf doksi. Azt írja a fazon, hogy nála a Recipient Policy-k között volt egy ilyen név.
Sokat nem segített. Mivel akárhol is kezdhetem a keresést, elkezdtem én is a Recipient Policy-knél. Van vagy húsz. Jobb kattintás, rename, bemeszelés. És a tizenvalahanyadiknál rámmosolygott a szerencse, egy kövér szóvégi whitespace képében.
15-20 perc várakozás, újabb kisérlet: siker.
Egy láthatatlan karakter valahol… mekkora retkes hiba már…
A sóvárgó objektum
Lassan egy éve, hogy volt ez az üde, bájos eset. Nem, nem megünnepelni akarom az évfordulóját… egyszerűen csak szeretném lezárni.
Micsoda? Hogy mit kell még egy év után lezárni?
Nos, volt egy olyan hiba, mely akkor került bele a rendszerbe, de csak most lett kijavítva.
Szó se róla, hagytunk neki időt, hogy megoldódjon magától.
Január másodikán is hívott a helyi rendszergazda. Van egy felhasználója, akinek a nagy reszelésben elveszett az accountja. Ez nem is lenne gond, legfeljebb kap egy újabbat… de nem tudja kiosztani neki a régi emailcímét, mert azt mondja a rendszer, hogy ilyen cím már van. Pedig nem is.
Megnéztem. ADUC. Tényleg nem volt ilyen cím sehol… de kiadni mégsem lehetett. Miaf?
Gondolkodósarok.
Annyiszor elmondtam, leírtam… épp ideje volt, hogy magamtól is ráébredjek: az Exchange – szemben az ADUC-cal – nem az AD hagyományos ldap adatbázisát használja. Ekkor ugyanis az Exchange szerver nem látná a távoli tartományok domain partícióit – márpedig pont ott vannak a felhasználónevek és az emailcímek. Nem, ehelyett a globális katalógus ldap adatbázisát használja. Hogyan tudunk ebbe belenézni? Ldp, a portnál pedig a 3268-ast adjuk meg. Az ldp-nek van még egy nagy előnye az adsiedit-tel szemben: tud keresni. Rákerestem a felhasználó régi felhasználói nevére… és megtaláltam mind a két objektumot: az újat is, meg a beragadt régit is.
Ez bizony fogós probléma. Hogyan lehet a GC adatbázisból kitörölni egy bejegyzést, mely hivatalosan nincs is ott?
Mese nincs, google. Kiindulásnak pont jó volt, hogy a rossz felhasználó DN tulajdonságának értéke valami ilyesmi volt: “*CNF:GUID”. Meg is találtam, hogy ez egy vágyakozó objektum. Vágyik az elmúlásra.
Amikor kitörlünk egy objektumot, akkor az nem törlődik egyből. Ugye, nem kell magyaráznom, multimaster replikációs környezetben először a törlés tényének kell szétreplikálódnia, majd csak utána jöhet a tényleges megsemmisítés. Ez egész konkrétan úgy néz ki, hogy az ojjektum kap egy sírkövet, rajta a dátum, hogy mikor halálozott el. Innentől senki nem veszi komolyan… aztán pár hónap után (verziófüggő) eldől a sírkő is és az objektum ténylegesen is törlődik.
Igenám, de mi van a zombikkal? Képzeljük el, hogy lekapcsoltunk egy DC-t. A lekapcsolás pillanatában volt egy sírköves objektumunk. Telt-múlt az idő, az élő címtárból kitörlődött az objektum… aztán valaki visszakapcsolja a korábbi DC-t. Visszajön a sírköves objektum… de az AD nem tud mit kezdeni vele. Hiszen már rég a föld alatt kellene lennie. Törölni nem meri… de replikálni a biztonság kedvéért azért replikálja.
Ezek a vágyakozó objektumok. Angolul lingering objects. A CNF pedig annyit tesz, hogy conflict.
Hogyan került bele ez az objektum abba a bizonyos címtárba az ügyfélnél? Hát… ahogy a viccben is mondják, amit ott abban a másfél napban a kollégámmal csináltunk, örülj fiam, hogy nem nyerítesz.
De mindenesetre nyomon voltam. Megvolt a név, megvolt a jelenség. Már csak azt kellett megtalálnom, hogyan is lehetne eltávolítani az objektumot.
Ehhez sem kellett sokat keresgélnem: itt van a cikk. Javaslom, fusd át, mielőtt tovább olvasnál.
Durva.
Első olvasás után zsongott is rendesen a fejem: mikor, melyik GC-ről kell becélozni melyik GC-t? És mi ez a tömérdek GUID? Micsoda… mindegyik GC-t meg kell műteni? És mindezt egy nyomorult emailcímért?
Szóltunk az ügyfélnek, hogy ez egy kicsit durvább műtét, mint gondoltuk. Meg kellene várni egy csendesebb időszakot, amikor éppen nem heggesztjük ezerrel a címtárat. Rábólintottak.
Az más kérdés, hogy azóta folyamatosan rajta lógtunk a címtáron.
Végül eljött az az időszak, amikor már nem lehetett tovább várni. Hamarosan megszűnik az a bizonyos tartomány, márpedig a megszűnés után szinte reménytelen lenne eltávolítani a sóvárgó zombit.
Nekiugrottam a manuális eltávolításnak. Kövér error. Na jó, erre most nincs időm, ment a bejelentés a PSS-nek. A német sráccal lefutottuk a kötelező köröket, majd kipróbáltuk a meglehetősen beszédes nevű ‘repadmin /removelingeringobjects’ parancsot. Kiiírta, hogy minden fasza, eltávolította az összes lingeringet, nézzük meg az eventlogban, hogy mennyit. Egész konkrétan nullát.
– Ejha – füttyentett a mérnök. Ez mégsem lesz egy hétköznapi történet.
Nekiálltunk mi is a manuális eltávolításoknak. Kaptuk is az errorokat. De a hapi nem csüggedt.
Neki volt igaza… az egyik kombinációnál siker koronázta az erőfeszítésünket: az ldp kiírta, hogy eltávolította az objektumot.
– Oké – dőlt hátra székében a fazon – Megvan a módszer. Most már csak ezt kellene végigcsinálni mindegyik DC-nél.
A helyzet ugyanis az, hogy a zombi valamiért mégsem replikálódik szét mindegyik DC-re. Csak úgy, sztochasztikusan.
Javasolta, hogy próbálkozzak inkább a cikkben található szkripttel.
Nem mondtam neki, de eszem ágában sem volt. Ilyen kritikus műtétet rábízni egy ismeretlen szkriptre… egy ekkora címtárban… hiszen le se tudom menteni. Inkább kattogtatok.
Szóval azt mondja… az ldp-ből konnektálok egy DC-re. Aztán a command string megadásakor beírom egy másik GC GUID-ját, illetve a lingering objektum GUID-ját. Majd a commandnál végigmegyek az összes DC-n. Huszonegy DC, az annyi mint… 441 futtatás.
Izé… hol is van az a script?
Ez sem volt egy matyóhímzés. Egész konkrétan 5 darab fájlt kellett legyártani, GUID-hegyek torlaszoltak el másik GUID-hegyeket… de végül összeállt. Ráküldtem az éles címtárra, végiggondoltam, hogy hol is tárolom a munkakönyvemet, elolvastam egy gazdasági cikket… aztán egyszer csak lefutott a szkript. Dobáltam még egy kis dartsot, majd nagy levegő, teszt: felvettem a felhasználónál a korábban kiadott emailcímét.
És működött.
Nagy sóhaj.
Házirendetlenül
Mint GT is rámutatott, az, hogy én létrehozok a nem működő, megsemmisült, sóvel beszántott default gpo-k helyett egy-egy hasonló nevű csoportházirend objektumot, nos… az nem az igazi. A rendszer, pusztán csak név alapján nem fog ráismerni. Hogy egész konkrét legyek, a rendszer csak akkor ismerne rájuk, ha az egyiket 31B2F340-016D-11D2-945F-00C04FB984F9-nek, a másikat meg 6AC1786C-016F-11D2-945F-00C04FB984F9-nek nevezném el – de természetesen ezek a nevek már foglaltak voltak.
Szokásos vadászat a neten, majd viszonylag hamar meg is lett a dcgpofix.exe progi neve. Meg a leírás is, hogyan kell használni. Az én esetemben borzasztó egyszerűen: be kellett írnom a parancssorba, majd minden rémüldözésekor yes-t nyomni. (Mondjuk előtte aprólékosan lejegyzeteltem a GPO-k ACL értékeit. Az ördög nem alszik. ADUC/System/Policy/GUID.) Még hozzá kellett rendelni a GPO-kat a megfelelő objektumokhoz, kitörölni a kamu GPO-kat – és már ment is minden.
Végül még lokálisan is rendet kellett tennem. Ez annyiból állt, hogy most, miután már megvoltak a default GPO-k, ráfutattam mindkét DC-re a DC security sablont. Ez az a sablon, mely akkor jön létre – és húzódik rá a gépre – amikor előléptetjük tartományvezérlővé.
Most nagyjából rend van a Futrinka utcában.
Újabb Exchange esettanulmány
Ügyfél szeretné, ha meglévő Exchange 2003 Sp1 szervereire Sp2-t telepítenénk. Nem egy nagy dolog, mondhatnád. Csakhogy. A hálózatuk meglehetősen cifra, benne az Exchange organizáció szintúgy.
– Mekkora a valószínűsége, hogy félremegy a telepítés? – kérdezték.
– Minimális – válaszoltuk.
– És ha mégis félremegy, mekkora a kár?
– Nem vészes. Uninstall, oszt jól van.
– Akkor csináljátok.
Mindez volt tavaly ősszel. Ugyanis mielőtt nekiugrottunk volna, megnéztük, hogy tényleg van-e uninstall. Nem volt. Sőt. Azt mondta a silabusz, hogy ha egyszer felraktad, akkor az már odanőtt; nem szedheted le. Azaz ha félremegy a telepítés és azt hiszi az Exchange, hogy már fent van az Sp2, pedig igazából nem – nos, akkor elég hülyén járunk.
– Kedves Ügyfél, ezt benéztük. Nincs uninstall – kezdtük beadagolni a keserű pirulát.
– Akkor most mi lesz?
– Majd kitalálunk valamit.
– Az jó lesz, mert rollback elképzelés nélkül coki.
Azaz előállt a feladat: csináljuk meg azt, amit a Microsoft szerint nem lehet.
A legjobb módszer ilyenkor gondolkodni egy cseppet. Mit csinálhat egy service pack? Egész biztosan lecserél egy csomó binárist. Hol lehetnek ezek? A ‘program files/exchsrvr’ könyvtárban tuti, és tudjuk, hogy a mapi32.dll meg a system32-ben van, tehát ez a könyvtár is érintett. Mi lehet még? Hát, van még ugye a szerver konfiguráció – csakhogy ez nem az Exchange szerveren tárolódik, hanem a címtár konfigurációs névterében. Igen, abban amelyből egy darab van az egész erdőben. Séma? Nem, nem kell semmilyen séma preparáció, tehát ahhoz biztosan nem nyúl. Adatbázis? Nos, igen. Ez sarkalatos kérdés.
Azaz, ha vissza akarjuk állítani az esetlegesen félrement sp2 telepítés előtti állapotot, egész biztosan mentenünk kell a binárisokat és a konfigurációs névteret. A sémát biztosan nem kell, az adatbázisról – és hozzá kapcsolódóan a domain névtérről viszont nem tudunk semmit.
Teszt.
Virtuális tartományban virtuális Exchange szerver. Sp2 telepítés előtt összes Exchange szolgáltatás lestoppol, telepítés közben a másolandó fájlok útvonala meredten figyel. Az eredmény mindenképpen kellemes: a telepítőt nem zavarta, hogy nem éri el az adatbázisokat, ergo nem is bántja őket. A binárisoknál pedig csak a fenti két könyvtár érintett.
Körvonalazódik a megoldás. Hogy elkerüljük a felesleges replikációhullámokat, a félisten repadminnal leállítjuk az Exchange szerver logon szervereként szolgáló tartományvezérlőn a kifelé menő replikációt, csinálunk egy system state mentést a DC-n, csinálunk egy fájl szintű mentést az Exchange szerveren, majd jöhet a service pack. Hiba esetén visszatesszük a binárisokat, egy non-authoritative restore a lezárt DC-n – és kezdhetjük előlről.
Újabb teszt.
Ilyenkor jön jól a virtuális környezet, ugyanis az előző virtuális tartomány gépeit előrelátóan elmentettem, még a kísérlet előtt.
Replikáció leáll, sp2 felmegy. Nézzük, mit látunk? Nézni nézzük, de nem hisszük – telepítés után az ESM azt mondja, hogy továbbra is csak az SP1 van fent. ADSIEdit-tel megnéztem a tartományvezérlőket – és ledöbbentem. A telepítő nem a logon szerveren tárolt címtáradatbázis konfigurációs névterébe írt, hanem egy éppen arra járó kósza tartományvezérlő adatbázisába. Visszakeresni viszont a logon szerveren keresett. A replikáció meg ugye fejbe volt csapva.
Azannya. Akkor az izolációnak lőttek. Szerencsére létezik fa/objektum szintre korlátozható autoritatív visszaállítás is, amelynek tulajdonképpen mindegy, mit történt a többi tartományvezérlőn – csak éppen így majd lesz két erős replikációhullám az erdőben.
Végső teszt.
- Az összes Exchange szolgáltatás leállít.
- Az összes virnyákölő szolgáltatás leállít.
- Mentés az Exchange szerveren a fenti két könyvtárból.
- System state mentés egy közeli tartományvezérlőn
- Servicepack2 hopsza, felugrik.
- Megvárjuk, amíg a replikáció szétterjed.
- ADSIEdit-tel ellenőrzés az összes DC-n. (Exchange server objektum, version tulajdonság. Hogy melyik szám mit jelent, itt találod.)
- Jöhet a visszaállítás. Binárisok visszatöltése az Exchange szerveren. Fontos, hogy a szolgáltatások még mindig állnak, tehát az adatbázis könyvtár még érintetlen.
- Tartományvezérlő újraindít, Directory Service Restore üzemmódban.
- Ideges kapkodás, hogy hová is írtuk fel évekkel ezelőtt a DC lokáladmin jelszavát.
- System state mentés visszatöltése.
- A konfigurációs névtér autoritatívvá jelölése:
– ntdsutil elindít, megkapjuk a promptot,
– beírjuk, hogy ‘authoritative restore’,
– majd azt, hogy ‘restore subtree „CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=cegnev,DC=hu”‘
– felírjuk, hogy hová gyártott az ntdsutil az ldf segédfájlokat,
– quit.
Ide elkél némi magyarázat, legalábbis a segédfájlokkal kapcsolatban. Egyszer már írtam az ún. Linked Value tulajdonságtípusról – itt is erről van szó. Egész egyszerűen van néhány olyan tulajdonság(backlink) a konfigurációs névtérben, melyek értékei más – esetlegesen más névtérben lévő – objektumtulajdonságok értékeiből állnak össze. Ezeket az értékeket az ntdsutil roppant intelligensen kiteszi egy ldif fájlba. - Újraindítjuk a tartományvezérlőt, normál üzemmódban.
- Elindítunk egy replikációs hullámot: repadmin /syncall dc.cegnev.hu /e /d /A /P /q. (Ez ugyan lereplikál mindent, de csak a konfigurációs névtér lett autoritatív, a séma ugye intakt, a domain névtér meg normálisan replikálódik.)
- Végül visszatöltjük a backlink értékeket: ldifde -i -k -f fájlnév.ldf
- Szépen megvárjuk, amíg a replikáció elvégzi a dolgát. Leellenőrizzük mindegyik tartományvezérlőn, hogy a verziószám visszaállt Sp1-re.
- Biztonság kedvéért Exchange server újraindul, teszt levelezés, pihentetés.
- Végül Sp2 telepítés, megeszi-e. Megette.
Nos, ennyi. Ez már megnyugtatónak tűnt, nekikezdhettünk.
Természetesen végül nem volt semmilyen probléma.
ps: A fenti recept Windows Server 2003 Sp1 operációs rendszerű tartományvezérlők esetén működik! AD2000 esetén jócskán más a metódus.
Nem hivatalos rekordkísérlet
Ma olyan délutánom volt, hogy két gépen egyszerre 11 Terminál konzolból dolgoztam. Pörgött a kezem, füstölt a fejem… de sikerült minden.
- Az egyik cégnél beröffent az egy hete működésképtelen Exchange 2007 OWA proxy.
- A másik cégnél lecseréltem egy tűzfal mögötti tartomány összes tartományvezérlőjét Windows2003 szerverre, majd előléptettem a tartományt w2k3 módba.
Most egy hosszú szundikálás a metrón, majd jön az otthoni műszak.
[Update]
Azt hiszem, elkapkodtam ezt a délutáni bejegyzést. Mielőtt ugyanis előléptettem volna azt a tartományt, a biztonság kedvéért gyorsan leellenőriztem egy-két dolgot.
A hajam is égnek állt.
Először csak a replikáció nem ment.
Aztán a tartomány tokkal-vonóval leszakadt az erdőről.
Később már az Atyaúristens jogú felhasználómnak sem lett rá joga. Az erdő közölte, hogy olyan tartomány márpedig nincsen.
Na, ekkor füstölt csak igazán az agyam.
De végül meglett. Tudni kell, hogy ez ugyanaz a szutyok tartomány. Egész egyszerűen az történt, hogy a múltkori kavarás után a _pdc srv rekord értéke rossz helyre mutatott ugyan, de mivel az a gép még tagja volt a tartománynak, valahogy csak megtalálták a többiek az eldugott tartomány pdc emulátorát. Csakhogy most minden régi DC demotálva lett, az erdő pedig végképp elveszítette a fonalat. Természetesen az időszinkron is elment.
Most nagyzolhatnék, hogy mindezt brilliáns elmével következtettem ki, de nem lenne igaz. Bizony, ez egy kemény rakkolás volt, gyakorlatilag mind az öt – srv rekordokat tartalmazó – zónát egyenként csekkoltam át, hol találok valami rendelleneset. Szinte csak azt találtam. De végül összelegóztam mindent, kiszórtam a francba minden új link objektumot, hagytam, hogy a kcc elrendezze a dolgot, végül ki is segítettem néhány manuális konnektorral.
Juhé.
Innen már csak a GPO-kat kellett visszaállítanom, ugyanis az összes úgy elszállt, mint a győzelmi zászló. A teljes Sysvol – azaz Policy és Netlogon – csont üres lett. Bezzeg az eventlog…
Van erre egy jó módszer. Érdemes végigrágni, olyan területekre kaphatunk bepillantást, melyekről nekem eddig fogalmam sem volt, pedig elég régóta benne vagyok már az AD bizniszben. Csak a megértés volt egy félóra, a végigjátszás meg a duplája. És persze nem működött úgy, ahogy elképzeltem. (Én már annak is örültem volna, ha az egyik DC létrehoz egy szűz új struktúrát, a másik pedig átveszi. Csak működjön már végre a GPO szerkesztés.)
Végül a megoldás pofonegyszerű volt: habár a régi házirendekhez nem lehetett hozzányúlni, új objektumokat mégis engedett létrehozni. Utána már törölhettem a régi elárvult bejegyzéseket, az új házirendeket meg majd bekalapálja a helyi rendszergazda. Ha használta egyáltalán.
Tartományi konszolidáció
A helyi erők a migrációt már elvégezték. Amikor odakerültem, már minden kongott az ürességtől.
Az összeszorított fogak közül kiszüremlő kifejezések ennek ellenére már az első körülnézéskor előbukkantak. Ha azt mondom, hogy a megszűntetendő tartomány ebek harmincadján volt, akkor finom voltam. Tartományvezérlő, melyet egyszerűen csak kikapcsoltak és újratelepítettek máshol. Ugyanez Exchange szerverrel is. Az egyetlen fizikailag létező Exchange szerver külön Routing Groupban volt. Némileg cifrázta a helyzetet, hogy a Routing Group Connector-t viszont másfél éve lebontották. A postafiókokat pst-kkel lapátolták át. Kismillió public folder. Szükség van rájuk? Persze! – jött a válasz.
Visszaépítettük az RGC-t. Kismillió replikációs konfliktust jelző levél söpört végig napokon keresztül a levelező szervereken. (Ugye tudjuk, a public folderek a két replikáció közötti párhuzamos módosítások esetén nem az időbélyeg alapján döntik el, melyik módosítás a frissebb, hanem levelet küldenek mindkét módosítónak, hogy csókolom, tessék leharcolni egymás között, kié legyen az érvényes. És itt volt másfél év, replikáció nélkül.)
Végül mindegyik folderről született replika másik szerveren is, így levehettük a példányokat a megszűntetendő szerverről. Ez már csak napok kérdése volt. Az IT vezető itt kezdte el rágni a kefét, hiszen az egész tartománytörlésre egy nap volt ütemezve.
De végre eltűntek a public folderek, lehetett eltakarítani az Exchange szervereket. Rögtön az elsőnél földön koppant az állam: az Add/Remove panel szerint a Windows szerveren két példányban is futott az Exchange szerver. Ráadásul az egyiknek olyan verziószáma volt, mely a hivatalos táblázatok szerint nem is létezett. Fejvakarás. Megpróbáltam mindkettőt eltávolítani. Az egyiknél már a telepítő sem indult el. A másiknál elindult, de amikor azt mondtam neki, hogy mars ki, azt válaszolta, hogy “There is no such object on the server”. Azaz a kettőből elméletileg egy sem létezett. Ismerjük el, azért van abban némi kihívás, hogyan távolítsunk el egy gépről két darab nemlétező Exchange szervert. Feltettem a hegesztőszemüveget, előkészítettem a registry editort, az adsieditet és a szokásos mmc konzolomat. Csak nagy vonalakban:
- Exchange szolgáltatások leállít
- Exchange registry beállítások kigyomlál:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DAVEX
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EXIFS
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ExIPC
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EXOLEDB
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IMAP4Svc
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeActiveSynchNotify
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeADDXA
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeAL
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeDSAccess
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeES
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeFBPublish
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeMGMT
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeMTA
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeMU
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeOMA
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeSA
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeSRS
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeTransport
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWEB
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\POP3Svc
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RESvc - IIS eltávolít a gépről
- Másik gép Exchange System Manager programjából az Exchange szerver töröl
- AD-ból a gép kiléptet.
Egy szerverrel végeztünk. Jöhetett az utolsó Exchange szerver a Routing Groupban. Add/Remove, eltávolít… ugyanaz a hibaüzenet: “There is no such object on the server”. Eszelős guglizás. Ugyan eltávolíthatnám ugyanúgy, ahogy a másikat, de ez akkor is az utolsó szerver, legalább ezt tisztességesen kellene kirúgni. Aztán szerencsés találat, egy newsgroupban azt írják, hogy látszani ugyan nem látszik a postafiókok között, de minden szervernek van egy postmaster accountja is. A következő objektumon – CN=Configuration,DC=SUBDOMAIN,DC=DOMAIN,DC=COM\CN=Services\CN=Microsoft
Exchange\CN=EXCHANGE\CN=Global Settings\CN=Message Delivery – meg kell keresni az msExchAdminMailbox tulajdonságot. Ennek értéke mondja meg, melyik felhasználóhoz van hozzárendelve a postmaster mailbox. Ha ez megvan, akkor adsieditből megnyitjuk a felhasználó objektumát és meglessük a HomeMDB tulajdonságát. Ha ez a letörlendő szerverre mutat, akkor töröljük. Ha nincs már meg a felhasználó, akkor az msExchAdminMailbox tulajdonságnál adunk meg egy másik felhasználót.
És bejött. Egy már ezer éve nem létező service account userre mutatott az érték. Átírtam… és rögtön más hibaüzenettel állt le az eltávolítás. De ez már ismerős volt korábbról. Anélkül, hogy mélyebben belemennék, a HomeMDB értékekhez kapcsolódik egy backlink, a HomeMDBBL, abból lehet kimazsolázni a sunnyogó postafiókokat, lásd KB279202.
Most már semmi akadálya nincs az eltávolításnak. El is indult a folyamat… majd az Information Store leállítása befagyott. Hosszú várakozás után közölte, hogy oké… pedig ádehogy. Újabb fejvakarás. (Csodálod, hogy kopaszodok?) Átnéztem a szolgáltatásokat… hát ilyen nincs. El volt indítva a Site Replication Service. Natív Exchange 2000 organizációban. Az eszem megáll. Leállítottam előre minden szolgáltatást, beleértve az IIS és Winmgmt szolgáltatásokat is – és innentől már tényleg leesett a gépről az Exchange.
A többi már rutinmunka volt. Egy kicsit megpörgettem az ntdsutil-t (metadata cleanup), hogy eltávolítsam a szabálytalanul leállított DC-t, aztán dcpromo az utolsó DC-re végül egy óriási nagy takarítás az AD konzolokból, DNS-ből, WINS-ből, Exchange konzolokból.
Hajnali egy óra és már végeztünk is.
Második felvonásként rendezkedni kellett a gyökértartományban is. Az erdő szintű FSMO szerepeket birtokló tartományvezérlő… minden volt, csak nem acélos. Amennyit fagyott, attól akár Gorenje gyártmányú is lehetett volna. Olyan trükköt tudott, amilyet én még számítógéptől nem láttam: a szoftveres tükör mindkét lemeze külön-külön is látszott: az egyik C: néven, a másik meg talán V: néven. Nyilván ez így nem maradhatott. A FSMO szerepek szerencsére simán átmentek egy másik DC-re, jött volna a dcpromo. Jött is, aztán udvarias köhintéssel megkérdezte, hogy mit is csináljon a rajta lévő enterprise root CA szerverrel.
– Ez mi? – néztem meglepve a rendszergazdára.
– Nem tudom – vonta meg a vállát.
– CA szervernek tűnik – tippeltem.
– Lehet. Tudtam, hogy valahol van egy.
– Kik használják?
– ? – vonta meg a vállát.
Itt a magam részéről befejeztem a munkát. Mondtam, hogy amíg nem tudják, kik és mire használják ezt a CA szervert, addig én nem bolygatom meg. Meg utána sem szívesen, mert CA téren nem mozgok olyan biztos lábakkal. A takarításnak ezt a részét az insource vállalta be. Lementették a CA adatbázist, dcpromo le, operációs rendszer újratelepítése – a CA miatt szigorúan ugyanolyan néven – dcpromo fel, CA telepítés, adatbázis visszatöltés. Itt futottak bele egy pofonba, mert a régi CA hol a C: meghajtóra hivatkozott, hol a V: meghajtóra – amely ugyebár megszűnt. De a srác becsületére legyen mondva, ügyesen összekötözgette valahogy a szálakat. Végül visszamásztak a FSMO-k is.
Aztán jöttek a tartományvezérlő frissítések. Rendben meg is történtek. A rendszergazda éppen a drivereket telepítette fel a vacakabb, immár w2k3 tartományvezérlőre, amikor az úgy döntött, hogy elég volt neki ebből a világból. Olyan szinten szakadt össze, hogy esély sem volt feltámasztani. A fiúk vettek egy új vasat, és arra már közvetlenül w2k3 oprendszert telepítettek. És ekkor derült csak ki, hogy a CA adatbázis ugyan átkonvertálódott w2k3-ra, de az a géppel együtt elszállt. A mentésben lévő w2k formátumú CA adatbázistból meg nem lehet visszaállítani w2k3 CA alá semmit. Mivel közben a tartomány is natív lett, így elég bonyolult forgatókönyvek adódtak a visszaállításra. Olyannyira bonyolultak, hogy az IT vezető úgy döntött, inkább telepítsünk egy új CA szervert. Némileg kellemetlen, hogy még mindig nem lehet tudni, kik és mire használták a régit..
Na, mindegy, a tartomány legalább szépen működött.
Boldog új évet!
Valamelyik népművelő csatornán láttam régebben egy filmet a német tengerészet csúcs hadihajójáról – és arról, hogyan sikerült elsüllyeszteni. Ez jutott eszembe, ahogy a tegnapi éjszaka során folyamatosan süllyedtem én is a letargiába.
A hadihajó a világ egyik legerősebb hajója volt. Tulajdonképpen sebezhetetlennek készült, egy apró hibával. Ha megfelelő szögből belőttek az egyik tatbudi 10 centis ablakán, akkor eltalálhattak valami robbanásveszélyes berendezést, melytől levegőbe röpülhetett a tatfedélzet.
Az egészről film volt. Látszott a viszonylag kicsike angol hajó és a bazi nagy német hadihajó, ahogy szép kényelmesen fordul oldalra, hogy lesorozza a felszínről az angol jószágot. Aztán egyszercsak valamelyik angol belepukkantott egyet a nagyvilágba – és mit ád Isten, a lövedék pont bement a budiablakon, a hajó meg fordulás közben épp a kritikus szögben volt. A következő pillanatban felrobbant a német hajó segge és szép lassan befordult az egész a tengerbe.
Képzeld el, hogy van egy címtárad, meg egy Exchange szervered. Az ügyfelünknek is volt. Aztán január másodikán hajnali négykor a vacak, kifejezetten csak tartalékcélokra szolgáló PIII WS kategóriájú DC2 merevlemeze diszkrét pukkanással elhalt. Dugovics Tituszként magával rántott egy computer objektumot is a címtárból.
Ez még nem olyan nagy tragédia: a DC-t ki kell irtani, újat kell rakni helyette, a computer accountot meg resetelni kell. Mint ahogy Cary W. Shulz – Active Directory MVP – is írja:
There are user account objects just like there are computer account objects. The computer account objects have a secure channel with a Domain Controller. Over this secure channel the workstation and the Domain Controller communicate. In WIN2000 the computer account objects change their secret password every 30 days ( in WINNT 4.0 it was seven days ). Sometimes this secure channel gets flubbed up…for whatever reason. So, based on what I just wrote you can see how this can create a little bit of a problem. So, in order to resolve the problem of the flubbed up secure channel you Microsoft gives us the ability to reset that secure channel.
Illetve később Bizonyos Steve hozzáteszi:
In that scenario I would reset the Computer account first before trying the remove/add to domain. This works for me 99% of the time, the 1% usually require the remove/add method.
Csakhogy… gondolj bele, mi történik akkor, ha a flubbed account pont egy Exchange Server computer accountja – és bejön az 1%, azaz az account reset sem segít.
Hagyok időt végiggondolni.
A fent említett remove/add módszer értelemszerűen nem működik. Pontosabban meg lehet csinálni, de onnantól az Information Store az életben sem fog elindulni.
Az esetet a kollégám kapta tüdőre. Reggeltől estig a tartományt foltozgatta: vacak DC eltávolítása, tartományi replikáció beindítása, kismillió anomália megszűntetése, új DC üzembeállítása, makacs account resetelgetés… nem segített. Este héttől váltottunk, mint a pankrátorok: arénából ki, arénába be, high five.
Mit láttam?
- Az Exchange szerveren a szolgáltatások leállítva, mert minek fussanak.
- Az Exchange szerveren a tartományba belépni nem lehet: azt mondja, nincs olyan account.
- A netdom join azt mondja, hogy már van ilyen account.
- Amikor elrontom szándékosan a jelszavamat, akkor azt írja, hogy rossz a jelszó. Azaz a DC – és az AD – elérés tökéletes.
- Amikor kitiltom a computer accountot, akkor azt írja, hogy ki van tiltva. Az AD acélos.
- Próbaképp egy munkaállomás beléptetése: tökéletes.
- Az eventlog alapján az account “Access Denied”.
- Ha everyone full control-t állítok rajta, akkor is.
Brainstorming.
- Vegyük ki a tartományból majd tegyük vissza. Hevesen tiltakoztam. (Lásd korábban.)
- Promotáljuk DC-vé, majd az account reset után demotáljuk vissza sima szerverré. Újabb heves tiltakozás. (A dcpromo és az Exchange nem férnek meg egy csárdában. Ha ráküldjük egy Exchange szerverre, akkor tönkrevágja az IIS-t meg az asp.net-et, újra kell húzni mindkettőt. És utána belassul, meg össze-vissza működik. De a fekete leves a következő lépés: demotáláskor az IIS és az AD megszűnik egymással kommunikálni. Nem csak a kérdéses szerveren, hanem az egész organizációban. Nem kicsit durva.
- Gondolkozzunk. Mi mehetett tönkre? Az AD szépen működik. Az Exchange számítógéphez nem nyúlt senki, az adatbázisok tutira jók. A network, névfeloldások tökéletesek. Ha valami itt elromlott, az csak a computer objektum lehet.
Hmm… állítsuk vissza. Elméletileg létezik korlátozott hatósugarú autoritatív restore. - Megpróbálkozhatunk egy éles Exchange disaster recovery-vel is. Persze, tudjuk, hogy az Exchange tökéletes, de ha eljátszanánk, hogy ugyanazzal a névvel átraknánk az Exchange szervert egy másik gépre, talán ki tudnánk erőszakolni egy account reset-et.
- Persze nem kizárt, hogy az az elkefélt computer account ellenáll ennek az invitálásnak is. Akkor nincs más hátra, csinálunk egy új Exchange szervert más névvel, átmásoljuk rá az adatbázisokat, a felhasználóknál – szerencsére nincs sok – töröljük az Exchange tulajdonságokat, majd létrehozunk mindegyiknek egy új postafiókot, MAPI profilt, a régi Exchange szervert kiradírozzuk, végül egy offline adatbázismatyizóval kiszedjük pst-kbe a régi leveleket és visszalapátoljuk a felhasználók postafiókjába. Elég gusztustalan, de B tervnek megteszi.
Az utolsó három igéretesnek tűnik. Tudjuk, csak a kombinált bérlet a biztos. Ilyen sorrendben pont jó is lesz nekiindulni az éjszakának.
3. pont. Ahhoz bizony kell egy system state mentés is.
– Van? – kérdezem a helyi rendszergazdát.
– Persze – vágja rá.
Aztán nem sokkal később jön a helyesbítő telefon.
– Volt – közli – Azon a merevlemezen tartottuk, amelyik elpukkant.
Feltúrjuk a gépeket, az egyiken végül beleakadtunk egy két évvel ezelőtti systemdrive+systemstate mentésbe. Volt már akkor ez az Exchange szerver? Éppenhogy: 3 hónappal előtte lett telepítve. Nagyon necces. Nézzük csak, hogyan működik Windows 2000 szerveren az autoritatív restore? Aszongya, belépünk Directory Restore módban, visszatöltünk egy komplett systemdrive+systemstate mentést(!), majd ntdsutil-lal kijelöljük, melyik OU-t akarjuk megtartani, utána újraindítjuk a gépet, mely magára rántja az AD-t. Hát… ennek csak egy veszélye van, az, hogy működik. Gondoljunk bele, visszarántunk egy két évvel ezelőtti állapotot. Lehet, hogy akkor még nem is maguktól tekertek a bitek az alaplapon, hanem kis zöld emberkék hurcolászták őket. Aztán a systemstate… az nem csak az AD-t jelenti, hanem rengeteg operációs rendszer szintű adatbázist is. Azzal, hogy visszarántom az AD-t, az összes többi pókhálós cucc ottmarad. Esetleg azt tudom megcsinálni, hogy mielőtt belevágok, csinálok egy másik systemdrive+systemstate mentést, az első autoritatív restore után visszaröffentem a computer account-ot, ezzel megnövelem az UID-jét, majd csinálok egy non-autoritatív restore-t, melyet teljesen felül fog vágni a jó AD és visszakerülnek a rendszerkomponensek is a helyükre.
Ezzel csak két baj van.
- Egyfelől egyáltalán nem biztos, hogy a két évvel korábbi állapotú DC be fog tudni lépni a tartományba. Meg ugyan nem esküdnék rá, de úgy rémlik, van valami korlát, ameddig felhasználható a mentés.
- Elég rizikós egy pici tartomány hegesztésekor egy baromi nagy AD-t belengetni, felvállalni az inkonzisztencia kockázatát.
- Végül azt írja a manuál, hogy egy ilyen restore során egy csomó AD elem by design tönkremegy. Látható is a blue-frame jellegű elvből, hogy mindent visszarak, még akkor is, ha nem kellene, és abba vág majd egy maszkot. Azaz optimáis esetben visszaáll a computer account, de elszállnak a backlist értékek, az FRS replikáció, a RID pool… meg ilyenek.
Jé, ez három…
Ettől függetlenül ezt az utat túl kockázatosnak ítéltem. Ha a DC 2003-as lenne, a mentés pedig 30 napon belüli, akkor esetleg, de így… inkább nem.
Ennyit az egyenes útról. Nézzük a görbéket.
A korábbi disaster recovery cikk sem rossz, de az igazi recept Petrinél található. Mielőtt bármit is csináltunk volna, a helyi rendszergazda a régi Exchange szerver adatbázisait elmentette félre egy másik hardveren, felhúzott egy nagyjából ugyanolyan operációs rendszerű gépet (oprendszer, SP, patch, Windows komponensek – különösen az utóbbi a fontos). Ezután lehúzta a netről a régi szervert, az újnak átírta az IP címét, én a a nevét, közben reseteltem a computer accountot, majd beléptettem az új szervert a tartományba. Áttörtünk. (Mondjuk elsőre elhűlt bennem a vér, mert egy lépésen belül próbáltam átnevezni is meg beléptetni is a gépet, de az éber – akkor már durván 30 órája ébren lévő – helyi rendszergazda szerencsére figyelt… és a második kisérlet már sikerült.)
Innen már simán ment minden, úgy, ahogy Petri bácsi leírta. A végén extra bónuszként az is összejött, hogy egyszerűen visszamásoltam a korábbi adatfájlokat és az IS szó nélkül felmountolta.
Délután fél egy.
Nem sokkal szilveszter után. Mondanom sem kell, hogy a kollégám is, meg én is szabadságon vagyunk.
De így jár, aki az informatikusok bohó szakmáját választja.
ps.
Éppen befejeztem a jegyzőkönyvet – addig kell írni, amíg emlékszem, mi is történt pontosan – amikor csörgött a telefon. A Service Desk szólt, hogy jött egy bejelentés, miszerint megint nem megy a levelezés az ügyfélnél. Sóhaj, enyhe káromkodás, irány vissza. Átnézni a konnektorokat egytől-egyig, tesztlevelek innen-oda, meg vissza… minden működik. Még be sem fejeztem, amikor újból csörgött a telefon. A felhasználó pontosított, azt szerette volna mondani, hogy reggel nem ment a levelezés.
Délután fél öt van.
Köszönjük, az Ön hívása fontos nekünk.
Bevezetés
A novemberi Technet Magazinban jelent meg egy cikk arról, hogyan állt át egy cég Microsoft infrastruktúrára. Örült a lelkem, amikor olvastam, hiszen jó látni, hogy vannak helyek, ahol ez flottul megy. Nekem valahogy mindig a csatornákban mászkálás marad.
Gondolkodtam is, hogy megírjam-e az egészet ennyire részletesen, de aztán győzött a grafomániám. Nekem is jó, ha egyben látom, mi mindent csináltam/csináltunk rosszul, na meg másoknak is segíthet.
Ami még kérdéses volt, hogy hová írjam? Ide mély szakmai írásokat már nem szántam – de ebben a szakmai tartalom mellett lesz rendesen hőbörgés is, azt meg a katedráról talán mégsem kellene. Szóval maradt az egész a kocsma jellegű blogban.
A feladat látszólag egyszerű volt: rendbe kell tenni az ügyfél címtárát, Exchange organizációját, úgy, hogy menetközben upgradeljük a tartományt és a végén átállunk Exchange 2007-re. Gondolom, érezhető, hogy a ‘látszólag’ szó az iróniát hivatott képviselni az előző mondatban.
A helyzetet bonyolította, hogy az ügyfélnek vannak insource informatikusai is, azaz nemcsak mi, mint outsourcing cég kezelgetjük az IT rendszerüket. Hogy fokozzam a helyzetet, eddig alig fértünk hozzá a rendszerükhöz, a helyi rendszergazda sokáig elkövetett mindent, hogy ne kapjunk komolyabb jogosultságot. Embereink maximum egyszerűbb feladatokat láttak el, jórészt felhasználóadminisztrációt. A rendszerről meglehetősen homályos képünk volt. Meg is lepődtünk, hogy ezt a munkát végül mi nyertük el, nem az insource.
Maradjunk egy kicsit még a kiindulási feltételeknél. A meglévő rendszer a következőképpen nézett ki:
- Windows2000 erdő, natív windows2000 tartományok. Egy gyökértartomány, két gyerektartomány. A projekt része az egyik gyerektartomány megszűntetése, az erőforrások átmigrálása a gyökértartományba.
- Exchange 2000 szerverek, különösebb cifrázások – cluster, nlbs – nélkül. Minden tartomány mindegyik telephelyén van legalább egy szerver.
Tervezés… minimális. Az ügyfélnek nagyon sürgős. Az egész projektre tokkal-vonóval adott 3 hetet. Habár jeleztem, hogy igazából ez a rendszer megismerésére sem elég, de akkora nagy volt a különbség az ügyfél időbecslése és az enyém között, hogy nem is láttam értelmét a vitának. Csináljuk, aztán majd kialakul. Néha megpróbáltam tervezgetni, de annyira nem volt rá idő, hogy végül belementem egy kompromisszumos munkamódszerbe: a koncepció nálam megvan fejben, hetente összeülünk, én elmondom, mi várható a következő egy hetes etapban, felvázolom a döntési lehetőségeket, ha kell rajzolgatok is a táblára, aztán döntünk, ütemezünk. Végül a helyi IT vezető gyárt egy meeting minutes doksit, melyet egy hét múlva átnézünk, utána pedig megtervezzük a következő hetet.
Eddig sem hangzott túl jól, de aztán kiderült, hogy igazából a helyi rendszergazda sem ismeri részleteiben a saját rendszerét. Többször futottunk bele olyasmibe, hogy ‘ja, tényleg, emlékszem, mintha XY valamikor ezt meg azt telepített volna’ – mindez olyankor, amikor éppen valami nem várt falba ütköztünk. Dokumentáció nem volt semmiről sem. Életem első éles Exchange2007 bevezetése volt. Elég vadul hangzik. Ha tisztességesen akartam volna csinálni, akkor azt mondom, hogy egy-két hét rendszerfelmérés, két-három hét tesztlabor, lemodellezés, jegyzőkönyv, aztán az alapján egy hét tervezés. Ez durván a duplája volt az ügyfél által a _teljes_ projektre szánt időnek.
Nos, így. Ennyi volt a bevezetés. Legközelebb már szakmai dolgok jönnek.
Az igazán kemény legény
Vannak olyan dolgok, melyekhez az ember mindig félve nyúl hozzá. Ilyenek például az Exchange adatbázisok offline matyizásai a segédprogramokkal, és ilyen pl. az ntdsutil segédprogram is.
Ezek után egyetérthetünk, hogy az igazi extrém sport, az az Active Directory offline defregmentálása. Az ntdsutil programmal, directory restore módban.
Miért is lehet erre szükség? Hát, mert például a címtár ESE adatbázis alapú ldap szerver – ugyanolyan ESE adatbázismotor dübörög alatta, mint amilyen az Exchange alatt is. (Régóta mondogatom, a legtöbb izgalmas dolog az MS alapú szervertechnikában az Exchange-ből nőtt ki.) És ezeket a hasonló adatbázisokat hasonlóan is kell kezelni. Mindkettőben ugyanúgy keletkeznek whitespace-ek. Ráadásul a törlési mechanizmus az eleve pici objektumokra is elég rendes overhead-et rak rá, mire az törölhető állapotba kerül – és persze a végső törlés itt is csak az offline defrag lehet.
Mikor érjük el azt az állapotot, hogy most már aztán tényleg defregmentálnunk kell? Egyszerű, nézzük végig a tartományvezérlőinket, melyiken mekkora az ntds.dit fájl mérete. A rendszer logikájából következően az azonos tartományba tartozó DC-ken közel azonosnak kell lennie a fájl méreteknek is. Ha találunk olyat, mely drasztikusan kilóg a sorból, akkor arra már ráférhet az adjusztálás. (Csak a tisztánlátás kedvéért: habár címtár csak egy van, de az azt megvalósító ntds.dit fájlok minden további nélkül lehetnek eltérő méretűek: hiszen a szemét – mely nem vesz részt a folyamatokban – példányonként eltérő méretű lehet. Azaz megint nem bírtam ellenállni a bombasztikus cím kísértésének – de te már látod, hogy nem a teljes címtárat defregmentáljuk, hanem csak egy konkrét példányát, mely egy konkrét DC-n van.)
Segíthet a döntésben az is, ha úgy találjuk, hogy valamelyik DC gyanúsan lassú. Ha ekkor úgy látjuk, hogy az ntds.dit állománya is jóval nagyobb a többieknél, akár már hegyezhetjük is a karót.
És akkor nézzük végig az algoritmust:
- Újraindítjuk a tartományvezérlőt, az F8 gombbal belépünk a Directory Restore üzemmódba
- Parancssorból elindítjuk az ntdsutil programot
- files
- file maintenance: compact to: c:\munka
- Meredten bámuljuk a progress bar csíkját
- Ha végzett, akkor a c:\munka\ntds.dit állománnyal agyonvágjuk a %systemroot%\ntds\ntds.dit fájlt.
- Újraindítjuk a tartományvezérlőt.
Az külön megérne egy eszmefuttatást, hogy milyen esetleges balesetek ellen hogyan kellene védekeznünk. Nyilván óvnunk kell az FSMO szerepeket, az se mindegy, mi van még a tartományvezérlőre telepítve, nyilván egy systemstate mentés is jól jöhet a művelet megkezdése előtt… legyünk kreatívak.
– Oz Ozugurlu cikke alapján –
Mikor léptél be utoljára?
Aki már egy-két évnél régebben van az IT üzemeltetési szakmában, kilométerekről megérzi, mikor akarja a főnöke felvetni neki, hogy ‘Te, milyen jó lenne, ha egy szkriptben legyűjtenéd, kik azok a felhasználók, akik egy hónapja nem léptek be a rendszerbe.’. Ilyenkor kell pánikszerűen kivenni az éves garantált szabadságot és megvárni, amíg magától kihúny a láng a vezéri koponyában.
Miért is? Hiszen ez tulajdonképpen egy érték a felhasználó objektum egyik tulajdonságán. Ki kell olvasni oszt jól van.
Lelkes padavanok bele is szoktak ebbe a hibába esni. Legyűjtik, boldogan leadják a listát. Aztán jön a pofára esés: a listával szembesített felhasználók egy idő után karóval felfegyverkezve szándékoznak elbeszélgetni a lista készítőjével.
Mi történhetett? Hát, például az, hogy ezt a bizonyos értéket a tartományvezérlők khmm… közösülnek replikálni. Azaz ha pontos értéket szeretnénk tudni, akkor a korrekt módszer az lenne, hogy a lekérdezés során letámadjuk az összes tartományvezérlőt, majd kiválasztjuk a legközelebbi dátumot.
Nos, ezzel már készen is lennénk… de azért jogosan horgad fel a népharag: mi az már, hogy egy objektum tulajdonsága nem replikálódik? Azt mondja erre a Microsoft, hogy ha ezt a tömérdek adatot sűrűn replikálnák, akkor belehalna a hálózat. Lehet… végül is lehet. De akkor is bosszantó, hogy nem bízzák ránk a döntést, hanem azt mondják, így van, és kész.
Tulajdonképpen nem mondják. Nézzük csak meg az alábbi képet:
Van egy tulajdonság a tartomány objektumon. Úgy hívják, hogy msDS-LogonTimeSynchronization. Alapértelmezetten üres, ekkor 14 naponta replikálódik az az érték, hogy egyes felhasználók mikor léptek be utoljára. Ha ide beírjuk, hogy 1, akkor ez az érték lecsökken egy napra.
Nem mondom, hogy innentől naprakészek leszünk – de azért ekkor már sokkal jobban megközelítjük a valóságot.
Sokkal jobban, mint azok a szerencsétlenek, akik Windows2000 tartományban tengetik az életüket. Nézzük csak meg, nekik milyen lehetőségeik vannak:
Ennyi. Semmi msDS-LogonTimeSynchronization. Marad az összes DC nyaggatása adsi szkriptekkel.
Az ellopott tartományvezérlő esete
A szerverszobában, a szokásos hétfő reggeli névsorolvasáson azt vesszük észre, hogy eggyel kevesebb tartományvezérlő válaszolja azt, hogy ‘jelen’.
Mi ilyenkor a teendő?
Először természetesen a pánik. Egy-két perc dühödt headbanging a szerverrack-en határozottan ki tudja tisztítani az ember tudatát.
Amint elül a pánik, az ember kezdi végigondolni a lehetőségeit. Sajnos ekkor már késő. Ugyanis nagyon gyorsan kellene cselekednie, hogy csökkentse a hálózatát fenyegető veszélyt.
A legjobb, ha már azelőtt elgondolkodik a helyzetről, mielőtt elcsakliznák tőle a gépet.
Ezt tette Steve Riley a 2006 szeptemberi Technet Magazinban.
Miután végiggondolt mindent, részletesen kielemezte a lehetőségeket, ezenkívül számbavett minden rejtekutat – a következtetését egy mondatban foglalta össze: ember, építsd újra az egész AD erdőt.
Borzasztóan hangzik. (Eltekintve attól, ha a kedves olvasó nem pont AD telepítésekből él.) Ennél még a korábbi pánik is kellemesebb volt.
Ezt Riley is elismeri, ezért hívja fel a figyelmet arra, hogy tegyünk meg időben mindent a tartományvezérlőink védelmében.
Azaz:
- Láncoljuk le őket valami elvihetetlen tárgyhoz. Ha ugyanezt elektronikusan is meg tudjuk oldani az még jobb.
- A címtárat több erdőből építsük fel, majd vezessünk be szelektív autentikálást.
Azt hiszem, ez megér némi magyarázatot. Először is, ilyesmi csak Windows2003 címtárban létezik. Másodszor – és ez nekem is újdonság volt – a Microsoft szakított az eddigi ‘használj egy erdőt és egy tartományt’ modellel. Feltételezem, nem kis mértékben a szelektív autentikáció miatt.
Mi is ez pontosan? Addig gondolom oké, hogy ha egy cég egy címtárban több erdőt használ, akkor azokat egy forest root-on keresztül össze is kell trustolnia. Itt, a truston lehet beállítani az autentikáció típusát: ez lehet teljes vagy szelektív. A teljes azt jelenti, hogy az egyik erdőbeli felhasználó (Farkas), amikor megpróbálja elérni a másik erdőbeli erőforrást (Piroska), akkor megadja a felhasználói nevet és jelszót, majd az erőforrás jogosultsági listája alapján vagy eléri azt, vagy sem. Ezzel szemben a szelektív autentikációnál már az is egy jogosultság, hogy a Farkas egyáltalán autentikálhatja-e magát.
Ebben az esetben ha lenyúlják az egyik erdő tartományvezérlőjét, akkor csak az illető erdőt kell újrahúzni, illetve azokat az erőforrásokat megpiszkálni a többi erdőben, amelyek egyáltalán autentikálhatóak voltak a kompromittált erdő felől. - Telepíts read-only DC-t.
Ez – mondjuk úgy – jótanács a jövőre nézve. Read-only DC majd a Longhorn Server családban lesz, mint ahogy ezen a blogon tanult kollégám nagyon alaposan ki is vesézte a témát. - Végül Riley leírja, hogyan kell gyorsan, hatékonyan címtárat tervezni. Gondolom azért, hogy újratelepítéskor nem kelljen azon agyalnunk, milyen elvek mellett is építettük fel anno az egyes alrendszereket.
Nos, oké. Riley letette a voksát.
Ekkor lépett színre Joe. (Joe Richards az egyik személyes kedvencem. Mint írtam korábban, a fiú Directory MVP, néhány nagy sikerű segédprogram megalkotója és a maga kendőzetlen, nyers modorában egészen jó cikkek szerzője.)
Szóval Joe rögtön azzal kezdi, hogy ez egy nagyon jó a kérdés, de szerinte teljesen rossz a válasz. Nem is vacakol sokat, felsorolja a _rögtön_ lezongorázandó teendőket:
- Töröljük az ellopott tartományvezérlőt a címtárból. Azonnal. Gondolkodás nélkül. Erre teljesen jó az NTDSUTIL segédprogram. (Én fűzném hozzá, hogy ha volt a DC-n valamilyen FSMO, akkor azt természetesen el kell tőle rabolni.)
- Reseteljük mindenkinek az accountját, akinek lokális belépési lehetősége volt a tartományvezérlőkön. (Népszerűségi indexünk egész biztosan fel fog szökni – de erről majd később.)
- Reseteljük mindenkinek az accountját, akinek file/registry/services módosítási joga van az erdő tartományvezérlőin.
- Reseteljük mindenkinek az accountját, akinek jogosultsága volt bármilyen AD-hoz kapcsolódó alkalmazás (Exchange, SMS, MOM, stb…) menedzseléséhez.
- Ha a fenti adminok közül valamelyiknek van nem admin felhasználója, reseteljük azt is. Lehet, hogy az illető ugyanazokat a jelszavakat használta.
- Reseteljük az összes DC jelszavát. (Segítségképpen megadja, hogy a PSExex és a NetDom resetpwd lesz a mi barátunk.)
- Reseteljük a krbtgt tartományi felhasználó accountját. Méghozzá kétszer. Ekkor fognak elveszni a korábbi TGT-k. Szerencsére. (TGT: Ticket Granting Ticket; jegy, amellyel jegyet lehet igényelni a Kerberos szervertől.)
- Reseteljük mindenkinek az accountját, akinek joga volt a normális felhasználói aktivitáson túl belepiszkálni a címtárba.
És most el lehet kezdeni filozofálni. Joe véleménye szerint a fenti adminisztrátori teendőkhöz 2-5 adminisztrátor bőven elegendő. Határozottan kijelenti, hogy ennyi accounttal végigzongorázni a fenti listát, másodpercek kérdése. Ha több accountunk van, érdemes szkriptelni. Ha ez a gyorsaság nem megy kézségszinten, nos, akkor Joe szerint kutyaütők vagyunk, nem rendszergazdák. A címtár a hálózat legnagyobb értéke, akinek a dolga ezt védeni, annak nagyon ott kell lennie a szeren.
A másik filozófikus kérdés: egyeztessünk-e előtte? Joe szerint semmiképpen sem. Tegyük a dolgunkat. Itt másodpercek számítanak. És ha azok az opciók, hogy lesz néhány parázs veszekedésünk vagy egy korrupt címtárunk… akkor mindenképpen az elsőt kell választanunk. Sőt, Joe szerint már akkor elveszítettük a csatát, ha éles helyzetben egyáltalán azon filózunk, hogy értesítsük-e őket vagy sem.
A fentieken kívül két dolgot kell még megtennünk:
- Járassuk le a sárga földig az összes felhasználó jelszavát. Előtte azért szóljunk oda a helpdesknek…
- Figyelmeztessük az összes rendszer összes service account tulajdonosát, hogy egy órán belül változtassák meg az accountok jelszavát. Ha nem teszik meg, változtassuk meg mi. Jobb utólag röviden elnézést kérni, mint hetekig tartó türelmet később. Egy ideiglenesen leállt alkalmazás nem ugyanaz a nagyságrend, mint egy korrupttá vált címtár. (Nem tudom… azért a banki alkalmazásoknál nekem lennének kétségeim. Ezzel – Joe szerint – meg is buktam. Ő ugyanis a nem tervezett leállítás viszonylag rövid idejét veti össze a címtár – újrafelépítés okozta – hosszabb leállás idejével. Igenám, de az utóbbi tervezett. _Normális_ leállás után a cég addig kitalál valami metódust, mittudomén, papírnoteszt és postagalambot, meg egy adatfeldolgozási technikát, hogy hogyan lehet majd ezeket beledolgozni az újra felállt rendszerbe. Lehet, hogy ez kevesebb költséggel jár, mint egy inkonzisztens adatbázis.)
Végül természetesen a hapi szót kerít arra, hogy régen rossz, ha egy ilyen helyzetben improvizálnod kell. Hiszen rég a fiókban – és a megfelelő emberek fejében – kellene lennie a haváriatervnek.
Hogy miért is jó egy ilyen terv? Itt inkább idézem Joe-t:
A. Understand what your weaknesses are now so you can correct them.
B. Be able to block things others try to bring into your environment that will add more weaknesses later.
C. Have something you can follow when the fan and the excrement meet f2f.
Itt a vége felé térjünk vissza egy kicsit a realitás talajára. Azért ma már szinte mindenütt természetes, hogy van valamilyen szerverszoba – és ezek valamilyen formában zárhatók is. Ilyen helyekről szervert ellopni már nem olyan egyszerű.
Csakhogy… nem csak cégközpontok vannak a világon, hanem telephelyek is. Márpedig mifelénk még mindig elég drága a sávszélesség ahhoz, hogy érdemes legyen távoli helyekre is egy-egy lokális tartományvezérlőt lerakni. Általában az is igaz, hogy ezek a vidéki DC-k leginkább munkaállomás kategóriájú gépek, lelökve valamelyik sarokba – hiszen a plusz gép költségét is nehezen nézik el az informatikának, nemhogy még szerverszoba is legyen a telephelyen. Nos, ezeket már könnyű megcsapni – márpedig akármennyire vidéki is a DC, de ott van rajta a tartományi névtér írható változata, az egész erdő konfigurációs névterének írható változata és az egész erdő sémájának olvasható változata.
Ijesztő.
Erre lesz majd megoldás a Read-only DC – hiszen az azon végrehajtott Ad változtatások nem replikálódnak szét a címtárban, így hiába dugná vissza a gonosz tolvaj a preparált tartományvezérlőt, nem érne vele semmit. (Ettől függetlenül a tartomány felhasználóinak a jelszavát feltörheti, tehát a fentebb írt jelszó resetelések tartományi szinten továbbra is meg kell történjenek.)
Nos, ennyi. Elolvashattunk két véleményt. Nekem a magam részéről Joe elképzelése jobban tetszik – különösen azért, mert felhívja a figyelmet, hogy lennie kell egy alaposan kidolgozott tervnek erre az esetre is.
Tényleg, nálatok van?
Recent Comments