MonthFebruary 2013

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…

Visszanyomás

Habár szerintem már nincs olyan Exchange-közeli ember, aki ne hallott volna az elbökött bevezetése miatt felettébb rossz hírnévre szert tett back-pressure folyamatról, de még mindig van hús a csonton, melyet le lehet rágni.

Ügyfél. Exchange 2007, délután fejreáll. Szaki elkezd nyomozni, megállapítja, hogy elfogyott a C:-n a hely (hiába, hol legyen az smtp queue), elkezdi átrakni a D:-re, de aztán gyorsan el kell mennie máshová, telefon nekem, hogy fejezzem be. Az ilyen hívásokban benne van minden, amiért öröm élni: ideges ügyfél, fejreállt levelezés és egy más ember által elkezdett, de aztán félbehagyott megoldási folyamat.
Szerencsére a probléma tényleg egyértelmű volt: világosan ott figyelt a logban, hogy a queue log-ra kalkulált hely elfogyott, azaz a pánikindikátor 97%-on állt, és ekkor az Exchange már lelövi a levelezést.

Emlékszem, anno mennyit anyáztuk ezért az Exchange fejlesztőket, pedig alapvetően igazuk van. Úgy döntöttek, hogy az adatbázisok – és a 2007-estől már a queue is adatbázis – konzisztens állapota fontosabb, mint a szolgáltatás megléte, azaz ha már borzasztóan kevés a hely, akkor elindítanak egy clean shutdown-t, még mielőtt az elfogyott hely miatt dirty shutdown következne be. Viszont az anyázás is jogos volt, ugyanis az első verzióban a kevés hely az 5GB-re volt belőve. Persze, hogy nem értette az egyszeri admin, hogy most mi a fasz baj van, amikor a 10 GB-s diszk fele még szabad? Cifrázta a helyzetet, hogy nem esett le, sőt, a tapasztalataim szerint még ma sem esett le sokaknak, hogy a queue is adatbázis, tehát bőven hagyni kell neki helyet. És legfőképpen nem a meglehetősen elhanyagolt C: partíción tárolni.

No, mindegy, a kollégától megtudtam, hogy elindított egy szkriptet, mely átmozgatja a queue-t a D: meghajtóra, a folyamat le is ment, de valami még nem kerek, mert továbbra sem indul a el Transport service. Ekkor tovább szürkült a tekintetem. Valahogy nem szeretem, ha az ilyen kényes lépéseket szkriptből futtatjuk, különösen akkor nem, ha maga a mozgatás nem bonyolult és ráadásul jól dokumentált is. Így kezdhettem azzal, hogy leellenőriztem a szkriptet.
Ránézésre minden rendben. Jogosultságok beállítva, ahogy kell, az edgetransport.exe.config fájlban is korrektek a queue bejegyzései. A Transport service pedig elindult, majd pár másodperc múlva megállt.
Hmm.
Eventlog. Azt írja, hogy valami process fogja a queue adatbázist, az Exchange nem fér hozzá.
Vírusirtó. Tuti. A rohadt anyját. Megnéztem és így legyen lottó ötösöm. Valós idejű fájlvédelem bekapcsolva, a kivételek között nem szerepelt az új queue könyvtára. Felvettem. Erre az antivírus program közölte, hogy ehhez újra kellene indítani a gépet.
Hívtam a helyi embert.
– Te, újra kellene indítani az Exchange szervert. Gondolom, nem probléma, mert úgysem megy a levelezés.
– Ööö, ez nem Exchange szerver, hanem SBS. Ezen megy a cég mindene.
– Oké, értem. Újraindítható?
– Nem igazán.
– Tőlem. De addig nem lesz levelezés.
– Khm. Megkérdezem az ügyfelet.

Hamarosan jött a telefon.
– Újraindítható. Akár többször is.

Gondolom, mindenkit hazazavartak, hogy mára vége a munkaidőnek. Szeretem az ilyen rugalmasságot.
Restart. Transport service? Megint áll. Nofene, nofene. Eventlog. Ugyanaz. Valami fogja az adatbázist.
Itt hirtelen elfogytak az ötleteim. Oké, ismerem a Process Explorert, de általában csak a legvégső esetben használom. Kell itt még lennie kézzelfogható magyarázatnak.
Böngésztem tovább az eventlogot és hoppá! Nem csak egy hibaszál van, hanem kettő. Az egyik ez a ‘valami fogja a queue-t’, de van egy másik is, mely nem a szolgáltatás indításakor keletkezik, hanem rendszeres időközönként. Hogy mit mond? Hát, ez elég fura. Az a baja, hogy nem tudja meghatározni a D: meghajtóra jellemző minimális allokációs egység értékét. (Vagy valami hasonló. Nem írtam fel, meg egyébként is, magyar nyelvű szerver.)
Még csak nem is hallottam hasonlóról, de elméletileg okozhatja ez is a bajt. Gugli. Nem mondanám, hogy túl sok találatot kaptam, de ugye az ideális keresés az, amikor csak egy találat van, de az pont az, ami kell. És volt is egy elgondolkodtató cikk: azt írta a hapi, hogy ahhoz, hogy az Exchange 2007 adatbázist tudjon üzemeltetni egy meghajtón, a Network Service számára FC jogot kell adni a gyökérkönyvtáron. Csak. Megnéztem. Nem volt. Hjaj. Megadtam.
Persze, hogy elböktem. Nem mentem be az Advanced gomb mögé, hanem csak nyomtam egy OK-t. Erre elkezdte hozzáadni a Network Service-t a D: meghajtó összes objektumához. Vártam 5 percet. Aztán kimentem konyhába, megvacsoráztam. Fél óra. Visszajöttem. Még nem fejezte be. Na, ja: SBS, azaz fájlszerver is. Aztán lelőttem: mivel ez addicionális jogadás, így nem lesz belőle senkinek sem baja, ha a fájlok felénél nem lesz benne a Network Service a listában. Különben is, ha elindul az Exchange, akkor rendezem a jogosultságokat.
A lényeg: a gyökér most már jó. Transport Service restart… aztán pár másodperc múlva megállt.
Ilyen nincs.
Aki rendszeresen hárít el incidenseket, tudja, milyen érzés ez. Amikor sokadjára állítasz fel valamilyen hipotézist – egyik zseniálisabb, mint a másik – aztán feltúrod az internetet, hogyan lehet a feltételezett akadályt eltakarítani, majd valahogy el is takarítod, aztán hátradőlsz… és nem, az incidens nem szűnik meg.
A végén tényleg használnom kell a Process Explorer-t.
Aztán eszembe jutott még valami. Az a nyűves antivírus szoftver. Nem lehet, hogy az nem engedi elérni a D: gyökeret? Most már nem finomkodtam, kikapcsoltam a realtime fájlvédelmet. Service restart… és… és még megy… még mindig megy… nocsak, még mindig… eventlog… semmi. Ez megjavult.
Hátradőlés. Huh.
Aztán a következő kérdés: hogyan tovább? Mondjam azt az ügyfélnek, hogy ne használjon fájlszintű vírusvédelmet? Egy fájlszerveren? Háát, izé. Akkor inkább próbáljuk meg a két rendszert összenutolni, hátha elketyegnek egymás mellett. Drasztikus kísérlet #1: visszaindítottam a realtime védelmet. A Transport service meg se rezdült. Jó jel. Drasztikus kisérlet #2: bekapcsolt realtime védelem mellett újraindítottam a Transport szolgáltatást. Elindult. Sőt. nem is állt le. Még jobb jel. Tehát elég volt meghatároznia azt az allokációs egységet egyszer, utána már nem piszkálja a gyökeret. Drasztikus kisérlet #3: szerver újraindít. Transport service ugyanúgy megy. Tehát a meghatározott értéket nem a memóriában tárolta, hanem ki is írta valahová.
Oké. Case solved.

Tanulság?

Van az Exchange adminok egyes számú posztulátuma:
“Mindig a víruskereső a hibás.”
Nos, ezt meg kell változtatni a következő formulára:
“Mindig a víruskereső a hibás, még akkor is, ha látszólag ártatlan.”

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ó.

Hyper-V 2012 + Storage Sapces 2.

Elkezdtem az első 2012-es vizsgámra tanulni. Eközben bele-bele nézegetek a jelenlegi infrastruktúrám beállításaiba.

Pár napja eszrevettem, hogy a feltelepített Storage Spaces köteteimen nincs bekapcsolva a Deduplication. Akkor úgy voltam vele, hogy majd utánanézek később, mert most még nem sürgős.

Ma a nézelődés kapcsán képenvágott a szomorú valóság:

Miután a Host (ami az ingyenes Hyper-V Server 2012) elkobozta a Storage Poolt a guest-től (ami egy Windows Server 2012 Standard), nem is lesz dedupom (legalábbis nem mindenütt). Miért? Mert a Hyper-V Serverből hiányzik ez a Role Service.

Exchange 2010 SP3 – Végre

Tegnapi napon megjelent az Exchange 2010 SP3. !!!VÉGRE!!!

Ez talán a leginkább várt frissítése az Exchange-nek. A legfontosabb dologok amket tartalmaz:

– Az első Exchange 2010 kiadás ami telepíthető Windows 2012-re

– A minimális SP szint az Exchnage 2013 együttéléshez (ez sajnos még nem az igazi, mert Exchange 2013 oldalon kell hozzá egy CU1 jelű frissítés ami még nincs kész)

– Internet Explorer 10 támogatás

Forrás: http://blogs.technet.com/b/exchange/archive/2013/02/12/released-exchange-server-2010-sp3.aspx