Category: szívás

DotNet

2009-02-11 / / 0 Comments

Egész biztosan vannak kellemetlenebbül hangzó szavak. De nem sokan.

Mit tudunk róla? Keretrendszer. Valami olyasmi, mint a Java. Megírnak egy programot valamilyen nyelven, a keretrendszer pedig képes értelmezni és az adott operációs rendszer keretein belül futtatni is azt. Mi itt a baj?
A fejlődés, barátom, a fejlövés fejlődés. Az első dotnet az 1.1 volt, aztán jött az sp1, majd jött a 2.0, persze az is kapott sp1-et, feltartóztathatatlanul jött a 3.0 az adekvát sp1-gyel, végül előmászott a 3.5, persze neki is van sp1 csomagja. Szerinted mire számíthat egy akármilyen program? Ezek közül vajh melyik lesz fent az operációs rendszeren? Ha azt mondod, mindegy, akkor látszik, nemrégóta vagy a szakmában. Ez az egész kóceráj visszafelé nem kompatibilis. Azt hiszed, ha van 2.0 verziód, akkor futni fognak az 1.1-hez írt programok? Erre csak annyit tudok mondani, hogy probatbicol pfdavadmin. Akkor esetleg elférnek egymás mellett ezek a keretrendszerek? Talán. De ha például az Exchange 2007 mellé (.Net 2.0) fel akarnád tenni a pfdavadmint és emiatt utólag a .Net 1.1-et… nem csak én nem tanácsolnám. (Mindemellett, ha a az 1.1 után teszed fel a 2.0-át, akkor simán elketyegnek egymás mellett.)

A röpke bemelegítés után térjünk a tárgyra. Hiszen projekt van.

Eddig nem beszéltem róla, de az ügyfél nem csak Exchange 2007 clustert akart, hanem profi levélarchiválási rendszert is. A választásuk a Symantec Enterprise Vault (a továbbiakban SEV) rendszerre esett. Az ajánlatot tevő cég a projekt során az alvállakozónk lett. Némi vérgőzös ütésváltás szakmai egyeztetés után abban maradtunk, hogy a SEV egy Windows 2003 clusterre kerül, ahol az ún. Storage Foundation (SF) lövi ki a klasszikus failover cluster spof-ját. (Nem baj, ha nem érted elsőre, annyira nem lényeges.)
Bele is vágtunk. Feltelepítettük az operációs rendszereket. A kolléga kérdezte, hogy tegyen-e rá valamilyen dotnet-et. Elgondolkodtam. Ha már fent lesz a cluster meg az SF, utólag sokkal bonyolultabb lesz biztosítani a megfelelő dotnet keretrendszert. Végül azt mondtam, tegye fel a .Net 3.5-öt, az olyan ultimate dolog, az felrakja az összes olyan keretrendszert, mely még nem volt fent. Aztán ha minden fent van, akkor a SEV is ki fogja majd tudni választani, melyik kell neki.
Utána jött a cluster, jött az SF, szépen haladtunk. Jött a SEV telepítő ember is. Elkezdtük silabizálni a prerekviziteket. És amikor odaértünk, hogy a számíítógépen _nem lehet_ dotnet kettőnél _magasabb_ verziójú keretrendszer, akkor azért kezdtem hülyén érezni magam. Miért? Erre nem tért ki a doksi. De tudjuk, milyen ravasz dolog a felelősség – ha telepítési előírás, akkor be kell tartani, még akkor is, ha azt írja, hogy a telepítő mérnöknek aranyszínű tangabugyiban kell felszaladnia virradatkor a Gellérthegyre, fényáldozatra bemutatva telepítő cédét.

Jó, távolítsuk el. Itt másztunk bele a mocsárba. Hivatalosan ugyanis el lehet. De. Az internet tele van rémtörténetekkel, mi is történt azokkal, akik naív módon nekiálltak uninstallálni a keretrendszert. Eleve a 3.5 csomagot csak úgy tudod kilőni, ha minden csomagot leszedsz, melyet az rakott fel. De le tudod szedni? A történet ott kezdett tragikomédiába fordulni, amikor rátaláltam Aaron Stebner – MS alkalmazott srác – blogjára, ahol megemlíti, hogy szabadidejében írt egy progit – As Is – mely le tudja szedni akkor is a dotnetrusnyákat, ha azok nem akarnak eltávozni. (Legfrissebb változat.) Ekkor mondtam azt, hogy kösz, de nem. Legalább induláskor legyek biztos abban, hogy a rendszer flottul működik, nincs belekódolva semmiféle döglött(?) akna.

Formatcé.

Szépen összeraktuk újra az egészet, csak most már kihagytuk a dotnet kettő feletti csomagokat. Mindenki megnyugodott, csak bennem maradt némi tüske a dotnetekkel kapcsolatban.

Aztán itt volt a mai nap.

A héten keresett egy kolléga, hogy az ügyfél rendszerében, ha Outlook 2007-ből akarnak megbeszélést szervezni, nem látják a foglaltsági információkat.
Sóhaj.
Apa, kezdődik.

Egy nagyméretű rendszerben, ahol egyszerre vannak jelen Exchange 2003 és 2007 szerverek, ahol egyszerre van jelen az összes MAPI kliens, melyet a Microsoft az utóbbi tíz évben gyártott, beleértve az összes service pack kombinációt is – nagyjából huszonötmillió oka lehet, hogy egy konkrét kliensen miért nem megy a Free/Busy.
– Látja a CAS szervert? Internet Explorer beállításainál benne van a CAS a proxy kivételek között? – kérdeztem rá.
– Hoppá – jött a válasz.
Nem volt benne.
– Megjavult?
– Nem mondhatnám. Mostantól Váratlan Hibával elszáll az Outlook.
– Hah. Kliens oldali hiba. Apage Satanas.
– Mi legyen?
– Pecseljétek halálra. Aztán majd meglátjuk.
Felraktak rá minden létező szervízcsomagot, javítófoltot.
– Na? – kérdeztem rá.
– Ugyanaz. Sőt, az Out of Office be sem jön.
– Miaf? Állítsátok be légyszi, hogy elérjek egy tesztgépet.

És tényleg. Pedig az Autoconfiguration teszt szépen megmutatta, hogy az Autodiscovery a pontos OOF webservice útvonalat adta vissza. (Azaz az EWS útvonalát.) Ha ezt az útvonalat bemásoltam az IE-be, meg is kaptam a korrekt xml-t. Jogosultság az EWS-en? Tökéletes.
Az mindenesetre ekkor már látszott, hogy nem kliens oldali hibáról van szó. Mind az OOF, mind az Availabilty service (Free/Busy) az EWS-t használja, tehát ott lesz valami gubanc. De mi?

Nézzük, itt van a test-outlookservices parancs. Mit mond, ha megkérdezzük?
Ekkor koppant az állam a padlón: a harmadik lépésben error-ral elszállt. Na de kérem…? Egy default telepítésű CAS+HTS szervernél nem működik az EMS? Szar a powershell?

Vad guglizás következett.

Nem akarom a végtelenségig fokozni a feszültséget, az első értelmes nyom ez a thread volt egy fórumon. A jelenség pont ugyanaz, gyönyörűen látni, hogyan gyűlnek a károsultak, hogyan válik belőlük izgatott tömeg, hogyan saccolnak először a .Net 3.5 sp1-re, hogyan lesz egyre élesebb a gyanú, végül hogyan válik bizonyossággá: az egyik bátor jelentkező leszedte a 3.5 sp1-et (Hogyan?? – hördült fel a közönség.) és egyből megjavult nála a helyzet. Végül kialakult az a konklúzió, miszerint a tuti módszer az sp1 leszedése, bár valaki megjegyezte, hogy a Microsoftnak mintha lenne egy nem publikus javítófoltja is.

Ehhez képest volt felüdülés a következő találat, ahol az a bizonyos javítófolt nevesítve is lett. Innen lehet letölteni a csomagot. (Igen, csomagot. Nem csak a 3.5-höz kell patch, hanem az egész bagázshoz. Vigyázat, a sorrend is számít.)

Most már jó. Legalábbis, majdnem. A kliensek már nem panaszkodnak, megy rendesen minden, ami EWS-re épül. Egyedül a test-outlookservices nem fut még le rendesen, telesírja a képernyőt sémahibákra panaszkodva. Azaz lesz még itt néhány tiszteletkör.

Belehalni egy sajtóhibába

2009-01-22 / / 0 Comments

A projekt, mint egy elszabadult úthenger, száguldott tovább. Tegnap jutottunk el addig a lépésig, hogy növeljük a levéltovábbítás rendelkezésreállását, meg elosszuk a terhelést. Azaz berakjunk egy második HUB Transport szervert a meglévő mellé.
Hogy érthetőbb legyen az írás, összedobtam egy skiccet.

Nagyítás

Azaz van jobb oldalon egy CCR MBX szerver, előtte a HTS szerverek. A piros vastag vonal jelöli az Exchange 2007 – Exchange 2003 közötti routing group konnektort. Baloldalt pedig egy smarhost tartja a kapcsolatot a nettel. (A levegőben lógó vonalak egyéb, belső levelezési irányok.)
Kékkel jelöltem az újonnan berakott HTS szervert. HTS1 és HTS2 teljesen megegyező virtuális gépek.

Hogyan lesz ebből érdekes cikk? Hiszen a felállás egyszerű, mint a faék. Működnie kell, oszt jól van.

Csakhogy nem működött.

Abban a pillanatban, ahogy beraktam HTS2-t, bedőlt a kifelé menő levelezés – legalábbis a levelek jó része nem ment ki. A HTS2-n lévő várakozási sorokban pedig elkezdtek gyűlni a levelek. Egész pontosan így hívták az érintett queue-kat:

  • HTS1-xch2003
  • HTS1

A queue viewer azt mondta, hogy a legutolsó hibaüzenet ez volt:

451 4.4.0 Primary Target IP Address responded with :” 451 5.7.3 Cannot achieve exchange server authentication.” Attempted failover to alternate host but that did not succeed.Either there are no alternate hosts or delivery failed to all alternate hosts.”

Target IP. Valószínűleg a fejlesztőknek leesett volna a karikagyűrű az ujjukról, ha ki is írták volna, hogy jelen esetben ki is volt az a target, aki visszaröffent? HTS1? Xch2003? A smarthost?
Na, mindegy. Kezdjük el összerakni a kirakós játékot. A Google szerint ilyen probléma akkor van, ha Exchange 2007 szervert kötünk össze Exchange 2003 szerverrel (eddig jó) és a 2003-ason nincs engedélyezve az integrated autentikáció. Megnéztem, engedélyezve volt. Innentől a Google felejtős, más találat nem volt. Kénytelen voltam az eszemet használni.
A queue-k csak a HTS2-n látszottak. Viszont az első queue neve gyanúsan ugyanaz volt, mint az RGC-é. Lehetséges, hogy nem is az xch2003-2007 határon van a probléma? Mit is tanultunk az Exchange 2007 routolásról? Például azt, hogy queue at point of failure – azaz szállítási hiba esetén a levelek azon a szerveren várakoznak, amelyik legközelebb van a szakadáshoz.
Azaz nem az xch2003 és a HTS1 között van a hiba, hanem már a HTS1 előtt.

Nadehát… mi lehet itt? A közvetlenül egymás mellé bedugott két Exchange 2007 HTS szerver nem tud kommunikálni egymással?

Mindenesetre gyorsan lekötöztem az RSG lábát a HTS2-höz is (ez már nincs a rajzon), így a levelek nagy része huss, kirepült. De ettől a probléma nem oldódott meg. Hiszen még élt a HTS1 queue, és álltak ebben is levelek.

Jogos a kérdés, hogy ezek vajon milyen levelek lehettek? Milyen levelek azok, melyek a fenti rendszerben a CCR-en keletkeztek, a HTS2 átvette továbbításra, majd továbbküldte a HTS1-nek… hogy az továbbítsa vissza cuccot a CCR-nek. Elég bizarr kör, nemde?
Mit tanultunk még az Exchange 2007 routolásáról? Delayed fan out – azaz ha egy levélnek több címzettje van, akkor addig a pontig, amíg a levelek együtt mennek, lejátszódik egy direct relay, majd onnan megy minden csomag a maga útjára, további direct relay-vel. Azaz a vizsgált várakozási sorban azok a levelek álltak, melyeket olyan levelezési csoportoknak küldtek, amelyiknek volt tagja a CCR-en, de volt tagja vagy a külvilágban, vagy az xch2003 rendszerben… vagy bármelyik más célpontban. Ekkor lett volna egy direct relay a HTS1-re, majd onnan a CCR-en lévő postafiókoknak ment volna vissza is a levél.

De nem ment. Illetve…
Nyilván, telnet. Nyilván ‘ismeretlen parancs’ választ kaptam. Hogy mekkora biztonsági fenyegetést jelent Windows 2008 szerveren a default telepített telnet kliens… nem tudom. De én már sokadszor futok bele abba, hogy nincs… és már majdnem annyira frusztrál, mint az UAC.
Na, mindegy. Telepítve. Aztán boldogan telnetelgettem. És sikeresen. HTS2-n belépve, HTS1-re telnetelve, minden irányban elmentek a levelek. Csak a queue-ból nem ürültek.
Itt már kezdtem ingerült lenni.

Nézzünk már egy smtp logot. Hol is van? Az Exchange könyvtárban lévő smtpout könyvtár üres. Jó, akkor kapcsoljuk be az smtp logolást. Hol is kell?
Azt írják, hogy a logolást a send konnektoron kell beállítani.

Kérdés: hol van itt send konnektor? Egyáltalán, ki csinált itt send konnectort? Mert én biztosan nem.
Nem is kellett. Ugyanis amikor beteszünk egy AD site-ra egy második HTS szervert, automatikusan létrejön egy send konnektor a kettő között.
Megint tanulunk. Milyen send konnektorok is léteznek?

  • Explicit: Határozott ráutaló magatartással mi gyártjuk le, vagy a konzolból, vagy a shellből a new-sendconnector paranccsal. Jellegzetessége, hogy látszik: azaz mindkét menedzsment felületről nézegethetjük, konfigurálhatjuk.
  • Semi-explicit: Ugyan automatikusan keletkeznek, de a konnektorok látszódnak, konfigurálhatók. Tipikusan ilyenek az Edge szerver beállításakor az Edge-HTS send konnektorok.
  • Implicit: Automatikusan keletkeznek, nem látszanak, nem hozzáférhetők. Ha nem olvasgatnánk minden szabad percünkben Exchange szakkönyveket, nem is tudnánk róla, hogy léteznek.

Nyilván itt a legutolsóról van szó. Érezzük a bukfencet? Hogyan állítsunk be logolást egy olyan konnektorra, amelyhez semmi hozzáférésünk sincs? Marha egyszerű. Mint a viccben: rostáljuk át a sivatagot és ami fentmarad a rácson, az az oroszlán. Az alábbi írás szerint a következő parancsot kell kiadnunk, ha intra-organization send konnektort akarunk logoltatni:

Set-TransportServer “HTS2” -IntraOrgProtocolLoggingLevel Verbose

Ha kiadjuk… ugyanazt a kövér syntax errort kapjuk, mint amilyent én kaptam. A KB cikk ugyanis hibás. Kérjük le a get-help set-transportserver -full paranccsal a paraméterek listáját – és láthatjuk, hogy a helyes paraméter az -IntraOrgConnectorProtocolLoggingLevel. Ja, és ne lepődjünk meg, ha kigördül a képernyőről a szöveg. Nálam az EMS puffere 999 sor (több nem lehet), ebbe a paraméterlistának kábé a fele fért bele.

Viszont azt gondolom nem kell magyarázni, mi is történik. Azt mondtuk, hogy te, kedves HUB Transport szerver, logoljad lécci az összes send konnektorodat. És az összesben már benne van a szupertitkos is.
Transport szerver újraindít, ekkor ugye kénytelen megabajgatni a beragadt várakozási sort. Végre van log is. De milyen furcsa! HTS2 beehlózik HTS1-hez. HTS1 elsorolja, milyen kunsztokat tud. Majd páros lábbal kirúgja HTS2-t.

?

Gondolom, már hiányérzeted van. Miért nem ír ez a fazon a receive konnektorokról? Ordít, hogy ott lesz a hiba.
Először én is így gondoltam. Átnéztem többször is, az összeset.
– Milyen összeset? – kérdezhetnéd.
– Hát, a gyárit, meg a barkácsoltat – válaszolnám.

Miért is kell barkácsolni? Close Relay. Az ember a default (server) receive konnektoron állítja be, hogy a szóbajöhető IP tartományból mindenki bejöhessen, mindenféle autentikációt használhasson – eltekintve az anonymous hozzáféréstől. Emellett célszerű gyártani egy relay receive konnektort is, melyet úgy állítunk be, hogy ne kérjen autentikációt és engedélyezze az anonymous hozzáférést. De itt, a network fülön csak – és szigorúan csak – azokat a hostokat engedjük, melyek számára engedélyezzük a relay-t… és amelyek annyira rendszeridegenek, hogy kizárt velük minden együttműködés. (Tudom, ne mondjuk soha azt, hogy kizárt… mondjuk helyette azt, hogy egyik oldal sem akar annyi energiát beleölni a mutatványba, hogy összehozzunk egy tisztességes autentikációt. Inkább megbízunk egymásban.)

Nos, receive konnektorok többször is átnézve, ránézésre minden rendben. Pedig az eddigi nyomozásból 110 százalékra tudjuk, hogy kizárólag csak itt lehet a hiba.
Kiváncsiságból kikapcsoltam a relay konnektort. Abban a pillanatban kirepült az összes levél a queue-ból.

Oké. Akkor eddig megvolnánk. Idő? Még ma van. Igaz, éppenhogy csak. Mindenesetre a szemem már annyira kifolyt a helyéről, hogy amikor telefonálgatnom kellett, folyamatosan zárva tartottam. Addig is pihent.

Gyors mérleg: queue üres. Megvan a bűnös. Én viszont már használhatatlan vagyok. HTS2 lekapcsol, relay receive konnektor visszakapcsol. Ezzel el tud zakatolni az ügyfél… aztán holnap is nap lesz.
Hátha megálmodom, mi lehet a baj.

Nem hiszed el, megálmodtam.

Reggel felkeltem… és fogmosás közben lepörögtek előttem a konnektorokban lévő network listák. Bakker, a HTS2 mindkét receive konnektor szkópjában szerepel! Márpedig a relay konnektor a szigorúbb, tehát az lesz rá érvényes… ekkor viszont nem lesz engedélyezve számára az Exchange autentikáció!

Napközben volt éppen elég más dolgom is, az összeszedettség szobrát sem rólam mintázták volna, de délutánra összevakartam magam. (Két redbull, meg egy vizespohár kávé.) Háromkor bejelentettem, hogy éles teszt. A kollégáimnak elszürkült az arcuk. Szerettek volna otthon éjszakázni.
Lecsökkentettem azt az IP tartományt a relay receive konnektoron, mely magába foglalta a HTS2-t is. Majd bekapcsoltuk a HTS2-t. Queue viewer… és gyönyörűen üres.
– Na látjátok, nem kell beszarni – nyugtatgattam a többieket – megy ez.
Már majdnem pezsgőt bontottunk, amikor megjelent az első kézbesítetlen levél a HTS1 queue-ban.
– Miaf? – néztem bambán. Hiszen annyira biztos voltam az elméletemben.
– Figyelj, még egy olyan délutánt nem engedhetünk meg magunknak, mint tegnap – figyelmeztettek.
– Oké, tíz levélig elmegyünk. Ha addig nem tudom megoldani, akkor letiltjuk a relay konnektort és leállítjuk a HTS2-t.

Körülbelül hat levélnél jártunk, amikorra kiszúrtam, hogy a relay receive konnektor network listájában direktben is fel volt véve a HTS2 IP címe. Nyilván a tegnap esti eszetlen rodeó egyik fázisában tehettem egy bátortalan kisérletet. Gyorsan töröltem, pár perc várakozás – és a queue kiürült.
Győzelem. Ugyan vártunk még egy félórát, mielőtt megfújtuk volna a harsonákat – de én már rögtön biztos voltam a győzelemben: hiszen kiürült a feltorlódott queue. Ez már nem fog még egyszer feltorlódni.

Hátravolt még a nyomozás: hogyan történhetett meg egy ilyen félrekonfigurálás?

Ezt is megtaláltam. Nem voltam boldog. Én gépeltem el… méghozzá az implementációs tervben. Egy A4-es oldal méretű táblázatban voltak felsorolva azok az IP címek, akiknek engedélyezve volt a relay. (Az értékeket az Exchange 2003 rendszerből kellett átvinni a 2007-be.)
A táblázat valahogy így nézett ki (az értékek nem valósak):

  1. 192.168.100.0/24
  2. 192.168.101.0/24
  3. 192.168.102.0/24
  4. Meg vagy hatvan szóló IP cím

A harmadik helyen a jó érték az lett volna, hogy 192.168.102.0/25… azaz csak a tartomány alsó felének volt engedélyezve a relay. A HTS2 pedig ugyanezen tartomány felső felében volt.
És amennyire precíz vagyok, az implementáció során pontosan ezt a táblázatot pötyögtem be – így került bele mindkét konnektor szkópjába a HTS2.

Shame on me.

Tudom, a következőket fel lehet fogni egyfajta racionalizálásnak is… de ez nem fog visszatartani attól, hogy elmélkedjek egy kicsit az eseten.

Jó-e egy ilyen hiba a projektben? Dühöngjünk-e miatta? Vagy – és most nagyon meredeket mondok – örüljünk-e egy ilyen hibának?

Én az utóbbira szavazok. És nem csak azért, mert pontosan ezt állítja a talán legkedvesebb könyvemben – A zen és a motorkerékpár ápolásának művészete – Robert Pirsig is… hanem azért, mert én magam is ebben hiszek. Ha belefutsz egy hibába, és ellövöd rá az összes töltényedet, de a hiba makacsul megmarad… akkor ujjonganod kell. Mert a hiba rá fog kényszeríteni arra, hogy átlépd a határaidat… hogy olyan fegyvereket, olyan harcmodort találj ki, melyeket korábban nem ismertél. Az ilyen hiba tágítja a gondolkodásod horizontját.
Most például a valóságban is találkoztunk olyan – korábban csak elméletből ismert – jelenségekkel, mint a ‘queue at point of failure’ vagy a ‘delayed fan out’… megtanultuk, hogyan lehet send és receive konnektorokat logolni… és egyáltalán, elmélyedtünk a levéltovábbítás módjában, beleégettük a gondolkodásunkba a folyamat felépítését.
Innentől jobban fogjuk érteni, mi is történik a mélyben.

Adatbázis rodeó

2009-01-13 / / 11 Comments

Ez egy érdekes alkalom. Tulajdonképpen le kellene írnom egy esetet… de a jelenséget Zoli már leírta, a megoldási lehetőségeket pedig bőségesen kitárgyaltuk a kommentek között.

Akkor mit akarok én itt?

Hát, például összefoglalni. Meg fut éppen egy projektem – és ez a szívás is része volt. Szóval, hajrá.

Karácsony előtt járunk. Az erdő szélén farkasok üvöltenek, a plázákban meg a tolakodó emberek – azaz igazi karácsonyi hangulat van. December 19-én, pénteken az utolsó címlistát is benyeleztem, elégedetten toltam hátra billentyűzetet. Idén is megtettünk mindent, amit ember tehetett. Meg egy kicsivel többet is. Hazamentem. Pihenni. (Mwhaha.)

December 20. Aranyvasárnap szombatja. Az ajándékozási ösztön már a levegőt is kiszorította a plázákból. Mivel mi idén nem vettünk senkinek semmit, angyali békességben készültünk a karácsonyra. Főzőcskéztünk, tettünk-vettünk.

Aztán csörgött a telefon. Kollégám keresett. Hogy mozgatná a postafiókokat, de kardjába dőlt a szerver. Betelt a logpartíció.
– Te, be kellett volna kapcsolni a circular loggingot – korholtam meg enyhén – hiszen mondtam is.
– Bekapcsoltam.
– Igen? Hm… Most is be van kapcsolva?
– Persze.
– És a logok ennek ellenére is kidagadtak a fazékból?
– Ki bizony.
– Hm… ez érdekes. Miaf?
– Ja.
– Oké, elöször rakjunk rendet, nyomozni ráérünk utána is. Csapjatok pár gigát a partícióhoz, mountoljátok fel az adatbázist, kapcsoljátok ki-be a cirkuláris logolást. Ennek meg kell ennie a logokat.

Így is történt.

Kolléga hívott kicsit később.

– Rendben, működik.
– Örülök. Találtál valami nyomot?
– Igen. Az ügyfélnél tesztelnek egy webes ügyfélszolgálati programot. Beismerték, hogy véletlenül ráküldtek 180000 levelet a rendszerre.
– Hogy az a @&xß$…! Hát ezek teljesen meghülyültek? Migráció közben? Úgy, hogy nem is szóltak?
– Azt mondták, véletlen volt.
– Ennél még a fiam is fantáziadúsabb kifogásokat tud! Na, mindegy. A lényeg, hogy túléltük. Akkor most minden oké?
– Ja.
– Akkor hajrá. Migráljatok tovább.

Vissza a karácsonyi hangulatba. Finom ebéd, Nej remekelt. Szieszta.

A telefon csörgése ébresztett.

– Te, megint betelt a log partíció.
– Mfmvmf?
– Megállt az Exchange cluster. Betelt az egyik log partíció.
– Asztakurva.
– Mit csináljunk?
– Amit délelőtt is. Meg hívd fel a tesztelőket és helyezz kilátásba egy élvekibelezést, ha nem mennek legalább két méter távolságba a billentyűzettől. Mondjuk, egy évig.
– Oké.

Innentől nem is volt baj, egészen január 5-ig. Az új év első munkahelyi hívása útközben ért. (De még mindig jobb volt, mint tavaly.)

– Megint betelt a log partíció.
– Micsoda? Mi az, hogy log? Meg partíció?
– Exchange szerver. Tranzakciós log. Kaput. Finito. Konyec.
– Ja, már rémlik. Tudjátok, mit kell csinálni. Hamarosan bent leszek. Ja, és le kell ordítani a hajat a tesztelőkről. Egyáltalán, tesztelnek most?
– A service fut.
– Leállítani!
– Oké.

Cifrázta a helyzetet, hogy mind december 20-án, mind január 5-én mentés teszt is volt. Nem is akármilyen téttel. Nem is akármilyen mentésé.
CCR rendszerről van szó és én VSS alapú mentést álmodtam a passzív node-ra. Mert így egyfelől meg lehet növelni az adatbázisméretet (el se hiszed, milyen kevés betű van az angol ABC-ben), másfelől így az a rövid éjszaka is elég lesz mindenre. Egy valamivel nem számoltam: ez a mentési mód teljesen új volt az ügyfél rendszerében, hiányoztak a tapasztalatok, hiányoztak a kliens szoftverek. Rengeteget kellett volna tesztelnünk. Csakhogy akárhányszor elindítottunk egy mentést, annyiszor vadult be a legelső adatbázis. És ekkor már két hete ment a rendszer, kezdtek üzemszerűen is feltelni a log partíciók.
Csak nem a mentés lenne az, ami behülyíti a rendszert?

Ebben az állapotban olvastam újra Zoli írását. Nem-e lehet-e? Tudom, ezzel már hárman ülnek a gyanúsítottak padján… de mind a három eléggé esélyes.

Az első kettővel túl sokat nem tudtam kezdeni. Maradt a harmadik.

Eleve itt van a Snefi által linkelt KB cikk. Elolvastam. Hajjaj, de hányszor olvastam el. És folyamatosan úgy éreztem, ez a recept arra, hogyan lehet birkavesével földrengést előídézni. Mi köze lehet egy operációs rendszer hibájának ahhoz, hogy bizonyos nyelvi beállítások esetén elhasal rajta az Exchange 2007 adatbázis-motorja?
És mi az a másik, rejtélyes patch, melyet Snefi említett?
Oké, hívjuk a PSS-t.

Rövid idő alatt ki lettem kupálva. (Bigup for Madaras Gábor.) Tehát tényleg van egy operációs rendszer szintjén előbukkanó hiba. Ez egy olyan hiba, mely – bizonyos nyelvi beállításoknál – az Exchange ESE motorját végtelen ciklusba zavarja. Meg lehet figyelni, amikor bevadul a log, igazából nincs is levelezési tevékenység. (Check the Message Tracking Log.) A patch javítja a hibát… de nem javítja az adatbázist. Ez ugyanis olyan, mint egy vírus: ha egy adatbázis bekapja, akkor vége. Hiába gyógyul meg a szerver, az adatbázis élete végéig köhögni fog.
Két megoldás létezik rá:

  • Gyógyszert adunk az adatbázisnak.
  • Megöljük az adatbázist.

Én, személy szerint, az utóbbi megoldást favorizálom. Valahogy… olyan véglegesebb.

De nézzük először az első megoldást. A gyógyszert úgy hívják, hogy interim fix. Azért interim, mert menetközben lett rajtakapva. Tudni kell, hogy a csomag, amelyből majd a rollup pack lesz, az idők során folyamatosan gyűlik. Amíg nem lesz belőle végleges Rollup Pack, addig interimnek hívják.
Azaz az a javítás, mely kikúrálná az adatbázisunkat, jelenleg még csak interim formában létezik. Ráadásul RU7 formában, azaz saccra csak nagyon sok hónap múlva lesz véglegessé. Miközben az interim patch nem egy barátságos jószág, de nem ám. Például nem lehet Rollup Pack-ot telepíteni rá. Ha feltennéd, akkor – mivel ez egy RU7 interim, eleve le is mondhatsz a RU6-ról. Hadd ne részletezzem, mennyi balhé lehet ebből, akár csak a legegyszerűbb PSS eszkaláció esetén is.

Szóval inkább akasszuk fel.

Ehhez bizony neki kell gyürkőzni. A felakasztás ugyanis egész konkrétan offline defregmentálást jelent. Miért is? Mitől gyógyíthat egy tömörítés? Attól, ahogyan tömörít. Az offline defrag ugyanis nyit egy új, temporary adatbázist, ebbe elkezdi átmásolni a még értelmezhető leveleket. Amelyeket nem tud értelmezni, azokat kihagyja. Kihagyásra kerül minden szemét, minden sérült ezmegaz. Csak azok az itemek kerülnek át, amelyek teljesen jók. (Ez a folyamat időnként meglepően pici új adatbázist eredményez. Ezért kell feltétlenül menteni is előtte.) A legvégén pedig törli az adatbázist, a temporary-t pedig átnevezi. Ezzel a módszerrel a fertőzés tuti kiesik, hiszen azt a másoló folyamat sem képes átvinni.
Miért nem vadul be offline defrag közben az adatbázis? Azért, mert ekkor az adatbázsi le van mountolva. Az Information Store service nyüsszögve kussol a sarokban.

Frissítsük csak fel, hogyan is van ez?

Az Exchange adatbázis-kezelésének legmélyén van egy ESE motor. Ez egy nagyon primitív motor, kifejezetten egyszerű utasításokat képes megérteni. Ez fölött van egy database layer – tulajdonképpen címfordítási céllal – majd jön a DSA, mely képes minden hozzáfordulóval megtalálni a közös hangot… és képes a kéréseket lefordítani az ESE hótprimitív nyelvére.

Nagyítás

Tudom, ez nem Exchange. Ez Active Directory. De ne felejtsd el, hogy az utóbbi az előbbiből nőtt ki.

Tehát, a lényeg az, hogy az ESE szempontjából az Information Store is csak egy ügyfél a sok közül. És amikor lemountolod az adatbázist, akkor az IS elveszíti fölötte a hatalmát.
Jöhetnek a többiek, az offline adatbázis-matyizók. Mint például az eseutl. Ez ugyanúgy a DSA-t keresi meg, konkrét kérdésekkel, mint az IS. De mégsem IS.

Tehát ha offline tömörítesz, akkor menetközben védve leszel ettől a misztikus hibától. Ráadásul a végső adatbázis is tiszta lesz. Nem kell vacakolnod az interim fix okozta megkötésekkel.

Ql.

Akkor mi a probléma?

Az idő. Az ügyfelünk magyar viszonylatban a felső-közép kategóriába tartozik, összességében 500 GB adatbázissal. A Microsoft szerint az offline defrag 5-10 GB/óra sebességgel tép. Ez testvérek között is 50-100 óra leállást jelent az ügyfélnél. Ha esetleg nem lennél jó fejszámolásban, akkor ez 2-4 nap. Levelezés nélkül.

El tudod képzelni?

Muszáj lesz. Ez az egyedüli értelmes kiút. Telepíteni kell a patch-et, majd offline defrag-gal gyógyítani az összes adatbázist. Az interim fix… több megkötést hoz, mint amennyi előnyt a leállás nélküli javítás jelentene.

Tesztelve.

Minden jó, hajó a vége

2008-12-04 / / 1 Comment

Valamikor írtam róla, hogyan járt szerencsétlen ügyfelünk: az anyacége dömperrel beborított vagy 30000 kontaktot a címtárába. Szaladgáltak is szegények, mi lesz most a címlistákkal: végül egy illegalitásba hajló lépéssel megpatkoltuk a rendszert.

Aki nem olvasta át a két linket, röviden összefoglalom: szerencsére kiderült, hogy a távoli tartományban született kontaktok msexchoriginatingforest tulajdonsága megőrzi az eredeti forest értékét. A helyben született objektumoknál viszont ez üres. Azaz a GAL mögötti ldap filterbe ‘és’ kapcsolattal becsatoltunk egy !(msexchoriginatingforest=*) feltételt – így csak azok jelentek meg a globális címlistában, akiknek üres volt ez a tulajdonsága. Természetesen az eredeti GAL filtert kimentettük egy custom címlistába, hogy akik abban akarnak keresni, azért tudjanak.

Mindenki boldog volt.

Egészen az Exchange 2007 migrációig.

Igazából nem az a legnagyobb baj, hogy ebben a termékben kinyírták az ldap alapú szűrést. Hiszen bejött helyette az OPATH – és ha megszokod, rájössz, hogy ez tényleg jobb. Még csak nem is az a katasztrófa, hogy beszuszakoltak egy plusz réteget a filter és a címtár közé. Igaz, hogy mostantól a feltételekben nem direktben hivatkozol az objektumok tulajdonságainak értékére, hanem helyette ujjból szopott nevű változókat kell használnod… de ez maximum kényelmetlenség. A tragédia az, hogy nem definiáltak minden tulajdonsághoz változót. Költői kérdés: találd ki, használhatjuk-e OPATH filterben az msexchoriginatingforest tulajdonságra definiált változót? Nem… mert nincs. Nyugodtan böngészd át a választékot.

Mondtam, ugye, hogy a legnagyobb szopás az ldap filter az egész upgrade-ben?

Akkor mi legyen? Adódik, hogy szűrjünk rá a szerver nevére. Az ügyfélnél egy darab nagy teljesítményű központi szerver lesz, tehát még a szűrőfeltétel sem lesz túl bonyolult. Alapvetően működhetne is… csak éppen nem elegáns. Mi van, ha valamikor üzembeállítanak majd egy másik MBX szervert is? Mi van, ha egyszer átmigrálják a postafiókokat egy másik szerverre? Ki fog emlékezni rá, hogyan lett megbuherálva a GAL? Ráadásul…ugye az átállás ideje alatt még két szerver van, tehát mindkettőnek a nevét be kellene írni a feltételbe. Pedig a régi csak pár hétig fog még élni. Jó, majd utólag módosítjuk.
Meséltem már erről? Lehet. De ismétlés a tudás k. anyja.
Szóval, a GAL-t a set-globaladdresslist paranccsal tudjuk upgradelni. Exchange 2007 alatt ugyanis minden szűrős objektumnak két szűrője is van. (Logikus, hiszen illeszkednie kell mind a régi, mind az új rendszerhez.) A címtár preparálásakor meg is jelenik az új tulajdonság, de sehol, hangsúlyozom, sehol sem történik automatikus filter konverzió, amikor betoljuk az első MBX szervert az organizációba.
Magad uram, ha szolgád nincsen.
Címlistáknál, email address policy-knél nem is gond. De a GAL-nál igen. A set-globaladdresslist parancs ugyanis egylövetű. Egyszer beírhatod az OPATH szűrőt. A következő futtatáskor már azt kapod, hogy ‘Hohó, valaki nem bír magával!’. Nyilván adsiedit és purportedsearch… de nem lehetsz benne biztos, nem csináltál-e valami visszafordíthatatlant. Lehet, hogy valahol a mélyben elpattant egy fogaskerék, a szerver teliholdkor életre kel és szakrálisan feláldozza az éjszakai recepcióst. Vagy bármi. De hogy nem lesz supportált, az tuti biztos.
Márpedig, ha a szervernevekkel játszol, akkor kétszer is módosítanod kell a GAL-t.

De azért megpróbáltam körbejárni. Leginkább azért, hogy közben időt hagyjak ott hátul a megoldáskeresésnek.
Összedobtam az Exchange 2003-ban egy teszt címlistát. Varázslóval. Középső fül, szervernév megad. Nézzük az eredményt… hoppá. Brian… leestem a székről. Ott voltak benne a külföldi címek. Most én vagyok a hülye… vagy a varázsló? Szerintem az utóbbi. Nézzük csak a konkrét feltételt… jézusmária. Sőt, ez már inkább duplajézusmária erősségű volt. Ez az idióta kuruzsló ‘vagy’ kapcsolatba tette a szervernévre vonatkozó feltételt az első panelen bepipált ‘contact’ feltétellel. Így mindenki beleesett. Döbbenet.

Kitérő:

Ha csak lehet, ne használj varázslót.
Ha ez eddig nem lenne egyértelmű, elmagyarázom, miért.
Nézzük az előbbi példát, kattogtassunk össze egy címlistát, amelyikben az Exchange postafiókkal bíró felhasználók címei vannak. Első fül, ‘Users with Exchange mailbox’ checkbox. Ez lesz a szűrőfeltétel:

(&(&(& (mailnickname=*) (| (&(objectCategory=person)(objectClass=user)(|(homeMDB=*)(msExchHomeServerName=*))) ))))

Azaz mindenki, akinek nem üres a homemdb (melyik adatbázisban van) és az msexchhomeservername (melyik exchange szerveren van) tulajdonságának az értéke.

Jelöljük be mellé a külső emailcímmel bíró felhasználókat is. Ez ugyanazon a panelen a következő két checkboxot jelenti: ‘Users with Exchange mailbox’ és ‘Users with external mail addresses’. A szűrőfeltétel:

(&(&(& (mailnickname=*) (| (&(objectCategory=person)(objectClass=user)(!(homeMDB=*))(!(msExchHomeServerName=*)))(&(objectCategory=person)(objectClass=user)(|(homeMDB=*)(msExchHomeServerName=*))) ))))

Azaz mindenki, akinek nem üres a homemdb (melyik adatbázisban van) és az msexchhomeservername (melyik exchange szerveren van) tulajdonságának az értéke – illetve mindenki, akinek meg üres. Jópofa, mi? Ha belegondolsz, hogy beviszünk egy feltételt, majd ‘vagy’ kapcsolattal annak az ellenkezőjét is, akkor tkp megkapjuk az univerzumot. Ami nem baj, mert ugye pont azt kértük… csak éppen megkaphatjuk egyszerűbben is, sokkal kevesebb munkával.
A helyes, varázslótlanitott szűrő:

(&(mailnickname=*)(objectCategory=person)(objectClass=user))

Ha belegondolsz, hogy ez a szűrőfeltétel minden RUS futáskor végigmegy a címtáradon… ugye nem mindegy, mennyit kell tökölnie a feltétel kiértékelésén.

Kitérő vége.

Szóval nem tetszett a szerverneves vizsgálódás. Ldp-ből kinyomtattam mindenfajta objektumból egy-egy teljes tulajdonságlistát, majd egy kihúzófilc társaságában félrevonultam. Kerestem, hol lehet ezt az egészet megfogni.
Hamar kiderült, hogy a szervernévvel egész konkrétan nem. Az ugyanis a magyar kontaktoknál is üres, nemcsak a kintről betoltaknál.
Gyakorlatilag nem találtam semmit. Illetve találtam, de. Nekem, emberi aggyal egyből látszott…de látszik-e ez a programnak is? Ugye ott van a distinguishedname, mint paraméter. Ebben szépen benne van az objektum elérési útvonala is. Márpedig a letolt címek, mégha egy nagyon bonyolult OU struktúrában is, de egy OU-n belül vannak. Azaz a distinguishedname valahogy így néz ki: cn=blabla,,,ou=PamPam,ou=blabla,dc=blabla. A vastaggal jelölt rész mindegyik idegen címben megegyezik, és csak azokra jellemző. Nosza, nézzük csak meg azt az OPATH szintakszist. Jé, ez a nolike egész szimpatikus. Tud ez wildcardot? Tud. A distinguishedname tulajdonságra létezik változó? Létezik, méghozzá ugyanazzal a névvel. Mire várunk?

Hölgyeim és Uraim! Imhol az új GAL:

alias -ne $null -and distinguishedname -nolike ‘*ou=PamPam*’

Már csak be kell gépelni. Jelzem, elsőre úgysem fog sikerülni. A filterek beadása rendszeresen kész katasztrófa. Elsőre úgyis csak címlistákon gyakorlunk, tehát dobjuk be ezt a keresést egy már létező ‘teszt’ nevűbe:

set-addresslist -identity teszt domaincontroller dc.domain.hu -recipientfilter {alias -ne $null -and distinguishedname -nolike ‘*ou=PamPam*’} -whatif

A -whatif azért van a végén, hogy ne csinálja meg, csak írja ki, mi lett volna.
Nos?
Ha jól csináltuk, akkor egy kövér errort kaptunk. Azt mondja, ennél a tulajdonságnál nem használhatunk wildcard-ot.
Ez már maga a Turáni Átok. Miért, ó miért? Bakker, hiszen ezen tudtuk (volna) egyedül megfogni a külsős címeket.
Gugli. Ezen a fórumon valaki hasonlóba futott bele, választ persze nem kapott. Viszont a Szkriptelő Fiúk egy helyen elkottyantották magukat:

Alas, this won’t work, either. As it turns out, the DN is a “constructed” attribute. The DN isn’t actually stored in Active Directory, it’s constructed on-the-fly any time you request it. Thus you can’t do a wildcard search on the distinguishedName attribute. And don’t bother asking about the ADsPath attribute, which also contains the OU name; you can’t do a wildcard search on the ADsPath, either.

Nem örülök… de beletörődtem.

Viszont az agyam, az kiürült. Szórakozottan nézegettem a papírjaimat, meg a változókat. Aztán az agyam kezdett magára találni, szép lassan összerakta az újabb variációt. Nézzük csak, proxyaddress tulajdonság, melyet itt emailaddresses-nek hívnak. Határozottan jelzi a táblázat, hogy nyomjuk csak bátran neki a wildcardot, bírja. Csakhogy ez egy tömb. Hogyan szűrjünk rá? Ezt is megmondja: a tömb elemei vesszővel vannak elválasztva és az egész egy szép nagy sztring. Nocsak. Persze az SMTP cím nem megoldás, rengeteg fajta van a cégen belül, aztán meg ott vannak a külsős kontaktok is. Na de… itt van ez az őskövület. Az X400-as cím. Mely már az égegyadta világon semmire sem jó. Csakhogy ennek a ‘P’ paramétere (Private Management Domain Name) pont az organizáció neve. És X400-as címe mindenkinek van – hiszen ez csak az email address policy-n múlik.

Azaz a következő kisérlet:

alias -ne $null -and emailaddresses -like ‘*p=orgname*’

Na, ez már jó. Mennyire? Túl.
Ez ugyanis beleveszi az összes emailcímmel bíró public foldert is, azt meg mi nem igazán szeretnénk. De innentől már rutinmunka. Úgy csinálunk, mintha gyártanánk egy új címlistát, bejelölünk mindenkit az első panelen (vegyük észre, hogy a public folderek fel sincsennek sorolva, azokat csak EMS-ből lehet felvenni), majd az utolsó panelről ctrl+v-vel lekapjuk a recipientfilter paraméter értékét, beleírjuk az emailaddresses figyelést… és készen is vagyunk. Imhol.

set-addresslist -identity teszt -domaincontroller dc.domain.hu -recipientfilter {emailaddresses -like ‘*p=orgname*’ -and (RecipientType -eq ‘UserMailbox’ -or RecipientType -eq ‘MailContact’ -or RecipientType -eq ‘MailUser’ -or (RecipientType -eq ‘MailUniversalDistributionGroup’ -or RecipientType -eq ‘MailUniversalSecurityGroup’ -or RecipientType -eq ‘MailNonUniversalGroup’ -or RecipientType -eq ‘DynamicDistributionGroup’) -or (RecipientType -eq ‘UserMailbox’ -and ResourceMetaData -like ‘ResourceType:*’ -and ResourceSearchProperties -ne $null))}

Habár már éppen eleget dolgoztunk ma, de azért ellenőrizzünk. Számoljuk össze, hány emberből áll az egyik lista és hányból a másik. Apró baki, hogy Exchange 2007-ben már csak preview van az Address List tulajdonságlapján, számláló nincs. Na de ott van még a régi szerver! Meg tudja számolni a 2003-as Exchange System Manager a 2007-es címlista elemeit? Meg hát. Igaz, eleinte hőbörög, de aztán beletörődik és számol.
A jó hír az, hogy kicsi az eltérés. A rossz hír az, hogy van. Nyilván annak a húsz embernek nem vigasz, hogy csak huszan nem látszanak a listában. És persze az egyik biztosan a vezérigazgató.
Akkor mégsem végeztünk. Nyilván az történt, hogy a több ezer emberből húsznál ki van kapcsolva a recipient policy, manuálisan meg nem kaptak X.400 címet. Semmi gond, megkeressük, levadásszuk.
Nyilván szkripttel.
Egy általános keresőszkript mindig itt figyel a gépemen, pusztán csak a kilistázott adatokat kell konkretizálnom. X400-as cím… az ugye a proxyaddresses tömb része. Nem tudom, ki szeret tömböt boncolni, én nem igazán. Kerülő út? Persze, hogy van. Tudni kell, hogy létezik olyan, hogy textEncodedORAddress változó, ebben a felhasználó elsődleges X400-as címe figyel. Pusztán csak ezeket kell lekérni egy Excel táblába, majd vizuálisan kiszúrni, kinél nincs adat.

Innentől már tényleg csak a piszkos munka van hátra.

Vazze

2008-11-30 / / 0 Comments

Tudod, én igazán szeretem az Exchange szervert, mint terméket. De időnként komolyan fel tud bosszantani.

Nem, ezek nem az én szavaim. Nekem sokkal durvábbak csúsztak ki a számon, amikor hasonló problémába futottam bele, mint Jim McBee.

Már a W2k8 NFSM cluster is megdolgoztatott, mire minden stimmelt. Hol ez nem volt, hol az viselkedett teljesen máshogy… és persze örök kedvencem, az a nyomorult Internet Explorer a nyomorult fokozott biztonságával. De végül összeállt minden, jöhetett az Exchange cluster. CAS és HTS szerver már duruzsolt a hálózatban, tehát megágyazva már meg volt rendesen. Kell is, mert a legtöbb baj mindig a Mailbox szerverrel van – érdemes előtte az összes egyéb szerepkört pöpecül belőni.

Kíváncsi vagyok, ha feltenném a kérdést, vajon szerintetek egy Exchange 2003 – Exchange 2007 átállásnak mi a legkritikusabb része, mit válaszolnátok? Én már a másodikat csinálom élesben, nagy ügyfélnél – és van egy pont, ahol mindig elhasalunk, ahol garantáltan behal a telepítés és mely után lehet a félbehagyott telepítés szutykait kivakarni és reménykedni, hogy a következő telepítést nem fogják a romok bezavarni. A címtárról nem is beszélve.

Mik ezek a félelmetes, bonyolult dolgok? A címlisták és a recipient policy-k. Nem gondoltad volna, mi? Hiszen nem is néznek ki olyan veszélyesen. De annak az embernek a kezét, aki ezt a setup darabot leprogramozta, beledugnám könyékig annak a seggébe, aki ezt a folyamatot megtervezte, és vica-versa – majd kiakasztanám őket a Nagykörútra karácsonyi dísznek, egy szál mikulássapkában.

Ugye, leírtam, hogy a múltkor hogyan jártunk. (Egyik, másik.) Tanultam belőle, most időben átvizsgáltam az összes címlistát, recpolt. Nem volt bennük névbe ágyazott zárójel, nem volt bennük felesleges ‘&’. Meg hát azért ez már SP1, az meg csak RTM volt.
A magam részéről mondjuk nem bántam volna, ha van előzetes validálási lehetőség, de hát ugye… Külön nehezítés, hogy itt az első MBX szerver rögtön egy CCR cluster aktív lába lesz…. ezt nem kellene elrontani, mert utána kivakarni a koszt… brrrr… nem kellemes.

No mindegy, még egyszer átfutottam az ldap lekérdezéseket… jóknak tűntek.
Hajrá.

Húzza a csíkot… húzza a csíkot… majd megáll. Hogy van egy policy, amelyikben szerinte nem stimmelnek a zárójelek. Szerencsére még nem történt semmi visszavonhatatlan, aktív a retry gomb a varázslóban, ráadásul megadja a policy nevét is. Megvizsgálom, ránézésre teljesen jó. De ami még durvább, az az, hogy ez az ldap feltétel nem valami egyedi dolog, hanem varázslóval lett összekattogtatva. Mi az, hogy az egyik varázsló nem eszi meg azt, amit a másik állított össze?
Néztem pár percig, végül felhívtam a rendszergazdát, mi is ez a recpol? Nem fontos, törölheted – jött a megnyugtató válasz. Huss.
Ez az egy policy akadt csak meg a torkán, nyugodtan nyomtam rá a retry gombra pár perc várakozás után. Be is fejezte a Mailbox szerepkör telepítését, belevágott az utolsó fordulóba, az MBX clusterezésbe.
És belehalt. Közölte, hogy

Summary: 4 item(s). 3 succeeded, 1 failed.
Elapsed time: 00:08:56

Copy Exchange Files
Completed
Elapsed Time: 00:01:13

Management Tools
Completed
Elapsed Time: 00:00:07

Mailbox Role
Completed
Elapsed Time: 00:06:34

Clustered Mailbox Server
Failed
Error:
The Exchange server address list service failed to respond. This could be because of an address list or email address policy configuration error.
Elapsed Time: 00:01:01

Érted??? Ennyit mondott csak, és itt már nem volt retry. Meghalt a telepítés. Kaptam egy nem clusterezett MBX szerepkört egy clusteren. Sokáig nem is tértem magamhoz. Úristen, hogyan fogom én ezt úgy egyenesbe tenni, hogy később ugyanezen a néven és ugyanezen az IP-n működő CCR szervereim legyenek?
És mi a büdös istenharagja nem tetszett már megint neki a listákon vagy recpolokon? És egyáltalán, melyiken? Hiszen az ügyfélnél volt belőlük épp elég.

A hangulatom…. képzelheted. Dühöngtem. Hogy nem igaz, hogy ezekkel a szar ldap konvertálásokkal ekkorát kell szopni. Hogy nem lehet előre lefuttatni egy próbát, megvizsgálni, hogy végigmenne-e a telepítés. Vagy belerakni a telepítésbe, hogy ha ilyet talál, írja ki egy logba, hagyja ki… és _fejezze be rendesen a telepítést_. Nem hiszem, hogy egy filter ekkor stopper kell legyen a telepítésben. Illetve ha az, akkor meg ne lehessen addig telepíteni, amíg nincsenek rendberakva.
És akkor ott van még, hogy csesznek megmondani, konkrétan melyik filter volt és mi is volt a baj vele. Ha szándékosan akarták volna szívatni a jónépet, akkor sem csinálhatták volna meg ennél aljasabbul.

Tea. Utána nekiálltam feltúrni az eventlogot. És hoppá, ott egy hibaüzenet, benne a bűnös policy neve: Akármi Teszt. Micsoda? Egy teszt policy? Huss. (Későbbi elemzésre persze elmentettem az ldap filtert.)

Most már csak a takarítás volt hátra. Először halványan reménykedtem, hogy talán végigment a telepítés, csak a szervíz nem indult el, de a törlés után majd el fog indulni… és már készen is vagyunk. De megnéztem jobban, ez nem telepített public folder adatbázist… márpedig akkor ez más gazságra is képes lehetett. Radír. (Csak az érdekesség kedvéért jegyzem meg, hogy ez a befejezetlen torzó, ez a nem clusterezett MBX szerepkörű virtuális szerver olyan szépen failoverezett, hogy öröm volt nézni.)
Nem részletezem. Levakartam. Újra telepítettem. Gyönyörűen működött.
Egészen a Rollup Pack 5 telepítéséig. A csomag ugyan nem kért újraindítást… csak éppen mindkét gépen kinyírta a clustert. Egész konkrétan a cluster szolgáltatást. Baromi rondán nézett ki az MMC konzol, tök üresen. De egy bűvös újraindítás megoldotta ezt a problémát is.

Maradt az ldap filter megvizsgálása. Elhiheted, láttam már néhányat… de ebben tényleg voltak meglepő dolgok. Már az is érdekes volt, hogy SID-re szűrt. De a végén volt egy olyan feltétel, hogy (anr=nev*). Ez meg mi a fene lehet? ‘Anr’ nevű tulajdonság nincsen. Gugli.

Hát… itt van a megoldás. Érteni most már értettem… de ki ír ilyen szűrőket egy éles rendszerben? Még akkor is, ha teszt? Ebbe a rendszerbe ilyen szinten csak én szoktam belenyúlkálni, én meg nem emlékszem erre a szürőre. A varázsló…?
Most sajnáltam, hogy egyből kitöröltem. Soha nem fogjuk megtudni.

Ez nem fair

2008-11-25 / / 1 Comment

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…

Tétova cluster

2008-11-23 / / 2 Comments

Exchange 2007 CCR cluster Windows 2008 NFSM cluster alapokon… izgalmas dolgok ezek. Nyilván össze is dobtam egy tesztrendszert, hogy nézegessem, simogassam, babusgassam. Na meg időnként agyon is vágjam.
A cluster, mint egy hiperaktív kisbaba, szépen felállt minden fejberúgás után, működött rendesen. Ide-oda terelgettem az aktív node-ot, tette a dolgát. (Már ahogy.)

Aztán eltelt egy hét, úgy, hogy nem nyúltam hozzá. Volt dolgom épp elég, máshol.

A hosszú álldogálás után újra beléptem, barátságosan hátbaszúrtam az aktív node-ot, figyeltem a failovert… mely nem következett be. Közölte, hogy az egyik Storage Group nem állt vissza online-ba, tehát a virtuális szervernek is Sándor. Néztem, mint Rozi a moziban. Oké, failback. Az működött.
Eljátszottam néhányszor ezt a failover/failback testcselt, de az eredmény mindig ugyanaz volt. Remek. Még jó, hogy a tesztrendszeren jött elő. Meg hát az amerikaiak úgyis azon aggódtak, hogy nem fogunk érteni a clusterhez…. nos, akkor itt a lehetőség, hogy kipróbáljam magam: rendbe tudom-e rakni ezt a rakoncátlankodó clustert. Mondjuk elsőre séróból, google nélkül.

Event viewer. Semmi. Annyit mond csak, hogy nem működött a failover – de ezt nélküle is tudtuk. Cluster.log… nos, az már nincs. (Illetve van, de egyelőre ugye google nélkül nyomjuk.) Nézzük, mi a helyzet az EMC-ből. Azt mondja, hogy a storage group adatbázisa (ugye, csak egy lehet) mountolva van, viszont a replikáció státusza: suspended. Hoppá… ez ledőlt pihenni. De miért? Resume, az anyád mindenit. És egyből healthy is lett. Kábé 10 másodpercig, mert utána megint elfáradt.
Nézzük a node-okat: látszólag minden rendben. Megvannak a könyvtárak, hely van bőven a vinyón… akkor mi a francért nem éled fel a passzív node adatbázisa?

Ismételjük át a tananyagot. Hogyan lehet életre lehelni egy hibás adatbázist CCR clusteren?

  • Ha az aktív node-on sérült az adatbázis, akkor eleve nem lehet felmountolni. Ilyenkor a ‘Recover database’ segít, az aktív node-on kiadva: ekkor a passzív node-ról történik egy visszamásolás. Jelen esetben ugye nem ez a helyzet, a Recover menüpontot választva az Exchange csak visszamorog, hogy ‘hülye vagy Ödön’.
  • Amennyiben a passzív node-on lévő példány sérül meg, akkor jön az ‘Update database’, de a passzív node-on kiadva. (Egyébként el sem ronthatjuk, az aktív node grafikus felületén nincs update opció és vica-versa.) De ha már durvulunk, legyünk extra durvák: jelöjük be, hogy mindent töröljön, ami az adatbázishoz tartozik. Ez a tuti. Ilyenkor a passzív node-ról törli a hibás adatbázist, törli a hozzátartozó checkfile-t és a logokat, majd újraseed-eli az adatbázist.

Naná, hogy az utóbbi segített.

Ami a jó hír a történetben, hogy el tudtam bánni a hibával, szolgáltatás nem esett ki. A rossz hír, hogy nem tudom, mi történt. Egy hétig hozzá sem nyúltam a rendszerhez, ment minden… és csak az EMC konzolban lehetett volna észrevenni – ha valaki rendszeresen rá-ránézett volna – hogy az egyik adatbázisra nem megy a háttérben a replikáció. Természetesen ez egész addig nem tűnik fel senkinek, amíg nem történik valami, mely failovert indikálna. Mely ugye ebben az esetben előre nem látott körülmény miatt elmarad. És ekkor már a reseed sem segít, hiszen pont az aktív node dőlt le.

Erre bizony hamarosan megoldást kell találnunk.

A sóvárgó objektum

2008-11-21 / / 1 Comment

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.

Névtelen nulla

2008-07-29 / / 0 Comments

Habár a címkonvencióból annyira már nem látszik, de ez az írás az ún. ‘félresiklott projekt’ sorozat része. Akit érdekel a történet többi része is, itt, alul, a ‘félresiklott’ tag-re kattintva tudja elérni azokat.

Akkor csapjunk bele.

A világ legfeleslegesebb nyomógombjai – azaz az UI designer csapat újra száguld.

Leszedném a következő Exchange 2000 szervert. El is indult a telepítő, állítgatja le a szolgáltatásokat. Ekkor jutott eszembe, hogy sokkal biztosabb lenne a művelet, ha előtte én állítgatnám le kézzel a szervízeket, manuálba tenném mindet, újraindítanám a gépet – és utána esnék csak neki a leszedésnek. Gond egy szál se, aktív az ablakon a Cancel gomb, lényegi művelet meg még nem történt. Rákattintottam. Erre feljött egy ablak, hogy “Mit képzelsz? Csak úgy össze-vissza kattintgatsz? Itt fontos dolgok történnek, _nem lehet_ leállítani!”
Alatta két nyomógomb: Igen, Nem. Mindkettőre továbbmegy a remove. (Direkt kipróbáltam később, egy másik szervernél.)

Az anonymous, mint korlátozó lehetőség

Minden rendben. Pontosabban majdnem minden rendben.
A központi site-ról ugyanis nem látszódnak a vidéki telephelyen lévők free/busy információi, amennyiben Outlook 2007-et használunk – azaz nem lehet velük megbeszélést szervezni az egyre terjedő új céges sztenderd munkaállomásokól. Korábbi kliensekről megy, de hát tudjuk, az Public Folder alapú. A 2007-es viszont webes szolgáltatásokon keresztül működik: először SCP, aztán Autodiscovery, aztán Availability szolgáltatások. (Lsd. részletesen ezt a cikket .)
Nem túlzok, hetekig gyököltem rajta. No persze, nem 100%-ban ezen, de ha volt egy kis időm, törtem a fejem. Nézegettem a pfdavadminnal, mi is a helyzet. Ez első ránézésre hülyeség, hiszen ez a rész működik… de kíváncsi voltam, hogy rendben van-e a MAPI hozzáférés a központi site CAS szervere és a vidéki site CAS/MBX/HTR szervere között. (Az Availability szolgáltatás mögött megbújó EWS ugyanúgy MAPI-val dolgozik, mint a pfdavadmin.) És hopp! Rögtön egy hiba:

Could not expand https://utvonal/public%20folders/ : name cannot begin with the ‘0′ character, hexadecimal value 0×30. Line 1, position 416′

Hah! Rávetődtem.
Azt írták, hogy akkor van ilyen, ha nincs feltelepítve a .Net 1.1. Dehát, nem is mondta senki, hogy kell. .Net 2.0, az igen, azt tudom. Már majdnem fel is raktam, amikor elolvastam Jim McBee írását a témáról.

If you get this message, do NOT install the v1.1 Framework on an existing Exchange 2007 server. You run the risk of resetting some of the v2.0 Framework settings and, thus, breaking Exchange Server 2007! If you want to run PFDAVADMIN from the console of an Exchange 2007 server, you need to install the v1.1 .NET Framework prior to building Exchange.

Kár érte. De most már legalább tudjuk, hogy a pfdavadmint _nem_ futtatjuk szerverről, csak munkaállomásról. Mert nem lehet.

Mihez nyúljak? Mármint magamon kívül. Nézzük meg azt a test-outlookwebservices parancsot!
Döbbenet.
A kimenetben az volt, hogy a távoli site CAS Exchange szerverén az EWS szolgáltatás 403-as hibával dob el. Ez ugye az Ekszessz Dániel. Viszont emellett _ugyanez_ a szolgáltatás tökéletesen működik _ugyanarra_ a felhasználóra az OAB tesztben.
Meg kell bolondulni. Ilyen nincs. Ha access denied egy webes szolgáltatás – egész konkrétan ugyanaz az Exchange.asmx progi, akkor igenis legyen következetes. Milyen már, hogy egyszer engedi, egyszer meg nem?

További guglizás. Hoppá .
A figurának pont ugyanaz a betegsége, mint nekem. A megoldás?

it was as simple as change to reject client certificates in IIS Directory security, edit, configuration.

A jó szószátyár nénikédet. Természetesen az IIS adminban _nincs_ ilyen ‘reject client certificates’ menü vagy nyomógomb. De hogyan lehetne másképpen? Metabase turka .
Hú, de ronda. Meg a többiek is: egy , kettő , három , négy .
Nem tetszik. Egyelőre mennek talonba.

Kulimunka következett. Hihetetlen mennyiségű jogosultságot néztem át. (Mert szimatra azért éreztem, hogy itt valami jogosultsági balhé van. Hiszen a 403, az azért elég konkrét utalás.) Felhasználókon, adatbázisokon, mi öröklődik, hol vannak esetleg elvágások, mi van a gyári csoportokkal, /domainprep újra, ki melyik csoportban mit is kap végül, mi van beállítgatva kliens oldalról… jojózott a szemem.
Innen külön üdvözlöm azt a GUI tervező zsenit, aki a jogosultságokat részletező ablakot _nem méretezhetőnek_ álmodta meg, még valamikor 1995 táján, az NT3.51-ben. Amikor szerveren a 640*480 felbontás már vad ollézást váltott ki az adminokból. Aztán külön csókoltatom azt a másik barmot, aki képes volt ezt az idiotizmust változtatás nélkül továbbvinni az újabb meg újabb termékekben.
Itt vagyok, 1600*1200-as monitorom van – és nézegethetek egy bélyeg méretű ablakot, ronggyá szkrollozva a csuklómat.
De itt sem találtam semmi használható nyomot.

Aztán kész. Eddig tartott a hajat vadul lobogtató vágta. Bár még agyalhattam volna a problémán, de vannak más ügyfeleink, vannak más munkáink, várnak az új szopások. Erre már nincs idő.
Eszkaláltunk a Microsoft felé.
Összeállítottam egy derék esetleírást (úgyis kellett dokumentálnom is). A támogató mérnök rögtön kért is pár napot, hogy átolvasgathassa.

Aztán közölte, hogy a test-outlookservices nem mérvadó, felejtsük el. Ez ugyanis szeret localhoston próbálkozni, de ott meg pofán vágják. (DisableLoopbackCheck: itt megtalálod a részleteket.) De jelen esetben ez irreveláns volt, mi 403-as errort kaptunk, nem 401-est.

Nyomoztunk tovább, a szokásos módon: a support irányított, én meg toltam az egeret. Aztán a srác egy helyen felsikított. (Na, jó, többször is, de ez hozta meg a megoldást.)
– Miért van engedélyezve az EWS webszolgáltatáson az anonymous access?
– Hát, izé. A fene tudja. Azt se tudom, mi volt a default. Még az is lehet, hogy fentről örökölte, hiszen egyszer már volt egy jogosultság reset. Lehet, hogy a sokadik kisérletezésnél vagy én vagy a helyi admin kattintottuk be, hátha ettől megjavul a Free/Busy terjesztés.
– Vegyük ki.
– Örömmel… de nem az a bajunk most, hogy túl szigorú az autentikáció? Ha elveszem az anonymoust, akkor csak tovább szigorítok.
– Nem. Ha az van beállítva, hogy anonymous, akkor _nem kér autentikációt_. Viszont később, amikor az EWS a kérelmező nevében fordul a Mailbox szerveren megcélzott postafiókhoz, pofára fog esni, mert mivel nem autentikálta a kérelmezőt, így a nagy büdös semmi nevében szeretne hozzáférni a mailboxhoz. Persze, hogy elhajtják.
– Azannya.

Tehát, értelmezzük. Ha megadom, hogy anonymous, azaz bárki jöhet, akkor azzal tulajdonképpen lehetetlen feladat elé állítottam az EWS-t… hiszen hiába van mellette az is bepippantva, hogy ‘integrated’, az anonymous miatt nem fog autentikációt kérni. És ebben a pillanatben az EWS még nem tudja, hogy én most az OAB-ot kértem el (amelyhez nem kell spéci jogosultság, tehát az anonymous is elviheti), vagy valaki Free/busy információja kell, melyhez viszont kellene jogosultság, pontosabban credential… de az anonymous miatt nem lett credential bekérve. Tehát azzal, hogy kiszélesítettem a kört az anonymous hozzáférésre, tulajdonképpen hazavágtam azokat, akik nagyon szívesen megadnék a nevüket, jelszavukat. Csak nem fogja megkérdezni senki.

De tényleg ez volt a megoldás. Mindenhonnan kivettük az anonymous hozzáférést – és beindult a Free/Busy információk terjesztése.
Ez egy hihetetlen levelezőrendszer.

Mennyi? Harminc!

2008-03-31 / / 0 Comments

Közben persze neki kellett ugrani a PKI rendszer feltámasztásának is. (Mely ugye rögtön az elején sikeresen összedőlt.) Tiszta lappal kezdtünk, méghozzá ‘ha már csináljuk, legyen jó’ felkiáltással: azaz legyen egy offline root CA meg egy online subordinate issuing CA.

A történetet majd megírom egyszer, nem volt kispálya.

Most csak egy apró frusztráció.

Elkészült, átadtam. Egy hét múlva jött az üzenet, hogy nem megy a CA szolgáltatás. Ránéztem, tényleg.
Eventlog megnéz, azt mondja a CA szolgáltatás nem tudja leellenőrizni, hogy nem vonták-e vissza véletlenül a tanúsítványát, ezért nem indul el. Azannya. Azaz nem tudja elérni az offline CA-t… mivel az offline. Gugli, turkálás. Azt írták, hogy állítsuk be a registryben a CRLFLAGS értékét 2-re. Beállítottam, service vidáman elindult. Én is, boldogan, haza.
Pár napra rá megbeszélés az IT vezetőnél, teszteljük le élesben a CA szervert. Teszteljük. Megigényelték a tanúsítványt, szépen végigmentünk a varázslóval, aztán a végén kövér error. Ajjaj.

Habár vannak események a naplóban, de az eventid.net nem tud mondani semmit. A konzolból azt látom, hogy egy ideig ment a tanúsítványkiadás, aztán egy időtől meg már nem. Miaf?
Bősz guglizás. Végül találok egy parancsot:
certutil –setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE.
Ez ugye ugyanazt a registry értéket piszkálja, melyet korábban manuálisan állítottam be, csak éppen nem számot ír be, hanem egy ködös változót. Próbáljuk ki, milyen számot fog használni?
Nos, egész pontosan azt mondta:

New Value:
CRLFlags REG_DWORD = a (10)
CRLF_DELETE_EXPIRED_CRLS — 2
CRLF_REVCHECK_IGNORE_OFFLINE — 8
CertUtil: -setreg command completed successfully.
The CertSvc service may need to be restarted for changes to take effect.

Érted, ugye? Tehát a flag-be be kell rakni egy kettest – ezt tettem én is meg korábban – azért, hogy a szolgáltatás offline root CA esetén elinduljon és egy nyolcast, hogy rendesen is működjön. A végeredmény tehát 10, azaz a beírandó érték 0a. Be is írta, működik.
Én pedig vegetative néztem az asztalt, azon meditálva, mennyire jó nekem, hogy ilyesmikkel foglalkozom.

De most komolyan:
Ez a nyomorult PKI egyébként sem egyszerű dolog, se a megértése, se az implementálása nem könnyű – és akkor telerakjuk ilyen csapdákkal. Feltúrni az internetet egy rohadt registry heckért, aztán kiderül, hogy több is van belőle… ahelyett, hogy lenne egy szájbanyomott checkbox valahol a subordinate CA tulajdonságlapján, hogy a root CA az offline.
De biztos én vagyok a hülye.

Tüskék a köröm alá

2008-03-10 / / 0 Comments

Nem is tudom, mikor lesz ennek vége. Az ember azt gondolná, most már minden menni fog a maga útján, semmi extra, semmi meglepetés.

Ja.

1. tüske:

Tesztuser hív estefelé. Nem megy az OWA hozzáférése. Belépek, ránézek a szerverre: Ó Irgalom Atyja, ne hagyj el. Az Exchange szolgáltatások több, mint a fele nem megy. Csoda, hogy napközben használni tudtuk. Aztán eszembe jut, hogy nem is. Például az otthoni postafiókomba küldött tesztlevél sem érkezett meg. Nézzük csak, mi van a queue-ban? Azt mondja, balhé – mert hogy nem tudja megnyitni. Miért? Mert állnak a szervizek.
Ezt jól körbejártuk.
Újraindítás.
Service szeretkezik újraindulni.
Azt mondja, kevés neki az idő. Pedig tőlem még próbálkozhatna…
Gugli.
Ha annyiszor lenne egymillióm, ahányszor leírtam ebben a sorozatban a nevét, már az enyém lenne a cég.

És igen… meg is lett. (Néha tényleg úgy érzem, a szakmámban a legfontosabb képesség a keresnitudás a neten.)

Cikk elolvas, székről leborul. Hát, azért már… mégis. Fiúk, ez nagyon durva volt.

Azt mondja, hogy a .Net2.0 programok már digitálisan alá vannak írva. Derék. Csakhogy a tanúsítvány része a CRL (Certficate Revocation List) elérhetősége is. Márpedig a .Net2.0 program minden induláskor leellenőrzi, nem vonták-e időközben vissza azt a tanúsítványt, amellyel őt aláírták.
Pontosabban… ellenőrizné, ha tudná. Ha volna a gépnek internet elérhetősége.
Gyors ellenőrzés… nahát, ennek a szervernek éppen volt. Akkor mi lehet a baj?

Hát az az átok WinHTTP.

Már egyszer keresztbeakadt a torkomon egy windowsupdate mókánál, most megint belémkötött. Az ugyanis egy dolog, hogy te a böngésződből tudsz böngészni, ha beállítottad a proxy beállításokat – de ugyanezt WinHTTP rutint használó szolgáltatások (BITS, .Net2.0 programok) alapból nem látják. Neked kell a proxycfg programmal beállítanod, vagy egyszerűen csak a ‘proxycfg -u’ parancs segítségével az Internet Explorerből átmásoltatnod.

Átmásoltattam, a szervizek be is indultak, mint a kisangyal.

2. tüske:

Már úgy nagyjából muzsikál minden, de a vidéki telephelyen nem működik az OWA. Az ügyfél csak egy internetkijáratot szeretne, a cég központjában. Minden tartományban, minden telephelyen van legalább egy CAS szerver, tehát az OWA proxy-nak kutyakötelessége lenne működnie. Egyik tartományból a másikba megy is, de egyik telephelyről a másikra az istennek sem. Ezt írja:

Outlook Web Access is not available. If the problem continues, contact technical support for your organization and tell them the following: There is no Microsoft Exchange Client Access server that has the necessary configuration in the Active Directory site where the mailbox is stored.

Most az egyszer a guglipower sem működött, mindenféle hülyeségek jönnek fel. Töröljem le a CAS szerepkört, töröljem le az IIS-t, telepítsem újra az IIS-t, telepítsem újra a CAS-t, persze közben áldozzak kecskét is keresztútnál. Valahogy nem volt kedvem ennyire vajákolni.
Még szerencse, hogy emlékeztem rá, az Exchange blogon boncolgatták rendesen ezt az OWA proxy témát. És igen, az egyik cikkben ott is van konkrétan az én hibaüzenetem. A megoldás sem bonyolult: engedélyezni kell a becélzott CAS szerver OWA virtuális könyvtárán az Integrated autentikációt. Megnéztem az IIS menedzserben, tényleg nem volt bekattintva. Ihaj. Bekattintottam, persze le is csorgott az alatta lévő könyvtárakra. Vártam egy kicsit, újabb próba.
Innentől kezdve belülről sem működött az OWA, átirányítás nélkül. Miaf. Azt mondta, hogy 440 Login Timeout.
Visszaállítottam az eredeti állapotot – az alkönyvtárakon is – de nem javult meg a helyzet. Ebből emberhalál lesz.
Gugli. Megint.
A találat kissé vajákolás szagú, de talán jó lesz. OWA virtuális könyvtár letöröl, pihen, újra létrehoz. És igen, ismét nem működik az OWA proxy, de legalább már eltűnt a hibaüzenet.

Akkor kezdjük előlről. Mi lehetett a probléma? Hát persze, kellett nekem az IIS adminból állítgatni, amikor van beállítási lehetőség az Exchange Management konzolból is! Gyors teszt: átírtam az autentikációt az IIS adminból – nyilván nem jelent meg az átállítás a címtárban. Ahhoz a konzol kell. Jaj. A lustaság. Vegyük észre: hiába van a jó jogosultság beállítva a virtuális könyvtáron, ha az nincs lekönyvelve az AD-ben, akkor nem működik. A fogadó CAS nem veszi a fáradtságot, hogy kontaktáljon a távoli CAS-sal, megnézi a címtárat és elhiszi azt, amit ott talál.

Gyors nagytakarítás, OWA újból le, majd fel, az InternalURL paraméter újra bevésése – a new-owavirtualdirectory parancs alapértelmezésben kihagyja – majd egy óra várakozás. Zöld tea, darts. Élni tudni kell.

És működik. Én már ideges sem vagyok.

Konnektória

2008-02-27 / / 0 Comments

Ez az írás már hetek óta itt aszalódik a piszkozatok között, de valahogy úgy éreztem, hogy ábra nélkül nem igazán lenne élvezhető. (Nem mintha azzal valami nagy mámor lenne.)
Mostanra készült el.

Nagyítás

Értő szemű olvasók gondolom kapásból kiszúrják a hibát: igen, egy budapesti Exchange2000 szerver és egy vidéki Exchange 2000 szerver ugyanabban a routing groupban van, dacára annak, hogy egy igen vékonyka WAN vonal feszül a két telephely között.
Hát, igen. Exchange 2000 alatt még lehetett ilyesmit csinálni. Az Exchange 2007 alatt már nem annyira, az ugyanis routing group-ok helyett az AD telephelyeket használja.
Ezzel el is érkeztünk a rajzon található kaotikus állapothoz.

Igen, kénytelen voltam extra konnektorokat beledöfni az organizációba – ha el akartam kerülni azt, hogy vidék a vidékkel Budapesten keresztül levelezzen. A postafiók migrációról már nem is beszélve.

Össze is raktam. Át is migráltam 3 szerencsétlent a BP2-XCH2000 szerverről a BP2-XCH2007 szerverre. Meg is halt a levelezésük, legalábbis bizonyos irányokba.

Mi történhetett?
A Winroute látott valami konnektorszerűséget, méghozzá működőnek látta. Csak éppen unknown objektumként. De azért arra küldte a leveleket – csakhogy azok nem jutottak el odáig. (Megragadom az alkalmat, hogy itt is rúgjak egyet a Message Tracking Centerbe. Sokkal rosszabb lett, mint az Exchange 2003-ban volt.)
A levelek ott álltak a queue-ban. Dühömben levertem minden extra konnektort – a levelezés hamarosan be is indult, igaz bejárta a fél világot a levél, mire kitalált.
Menetközben jött az újabb sokk: a tesztuserek emailcíme evolválódott. kovacs.bela@leany.hu -> bela@leany.hu

Slatty. Ez az a hang volt, amikor a fejemre csaptam. Hát, persze. Email address policy – mint korábban is írtam, adatbázis szintre. Csakhogy a userek átkerültek másik szerverre, másik adatbázisba, mely még nem szerepelt a házirendben. A default policy meg – most nem részletezendő okból – ilyen idétlenke.
Kivettem, hogy ne essen a userekre a policy, emailcím visszaír, eredmény vár.
Semmi.
Szokásos körök: RUS (bár itt már nem kellene), OAB generálás, OAB lekérés gyakorisága 1 perc, SCP? Mindegyik CAS-ra leellenőriztem. Jöhetett a szokásos keresztúton kecskeáldozás, közben állandóan nyomkodva az outlookban a download OAB gombot. Semmi.
Adsiedit, összes DC-ről megnézve a proxyaddress tulajdonságot. mindenhol jó. Ldp-vel belekukkoltam a GC adatbázisába, jó.
Hol a francba ragadt be az a hülye emailcím?
Aztán egyszer csak eltűnt a 3 tesztuser a GAL-ból. Újabb rángatózások, majd leesett, hogy most ért körbe a lebontott konnektor hatása. (Ekkor indult be a levelezés is.)
Új konnektorokat álmodtam magamnak. (Más színes tintákkal szokott.)
Semmi javulás.
Küldtem néhány tesztlevelet. Megkapta. A benne lévő cím jó. Reply. Elment. Majd visszajött, hogy nincs olyan címzett, hogy bela@. Miért??
Aztán valahonnan beugrott, hogy minden felhasználónak, még a postafiókkal nem rendelkezőknek is van olyan tulajdonságuk, hogy ‘mail’. Eddig úgy tudtam, hogy csak megjelenítésre szolgál. Azért ránéztem. Bakker, ott volt. Létezik ugyanis egy automatizmus, mely amikor policy változtatja meg a default emailcímet, akkor átírja ezt a tulajdonságot is. Ha én, manuálisan változtatom meg, akkor nem. És úgy látszik, mégis van szerepe.
Átírtam, megrángattam a szálakat, hamarosan meg is jelentek a jó címek a GAL-ban. Méghogy öreg kutya nem tanul új trükköket….
De az OAB letöltés továbbra sem ment. Google. Néhány óra szenvedés. Aztán összedobtam egy új profilt (az egyik tesztalanynak) a gépemen. Működött. Tehát az outlook profilban romlott el valami. Remek. Új profil, kismillió új beállítások, új ost. Mondjuk, ki nem szarja le. Működik.

Csak a nyolc terminálablak bezárása eltartott egy negyedóráig.
Hajnali fél kettő. Mehettem haza.

Mondjuk nem aludtam jól. Valami zavart. De még reggel is. Éreztem, hogy nem kerek a történet.

Másnap reggel folytattam a levélküldési teszteket. Volna. De nem működött sem a Free/Busy, sem az OAB elérésem. (Ja, nem mondtam: az egyik teszt postafiók az én tesztfelhasználóm volt.) Agyalások, gyötrések. Valamiért nem fordul a dög a CAS-hoz – legalábbis nem jön fel a selfsigned certre figyelmeztető ablak. Próbaprofil másik – tegnap szintén elkutyult – felhasználóval. Működik. Azaz az én mapi profilomba ragadt be valami szemét. Csináltam magamnak egy újabbat. Aztán a sokadik OAB letöltési kisérletnél egyszer csak megjelent a CERT ablak. Onnantól már a régi profilomból is ment. Idióta.

Most már tényleg levelezési tesztek. Gáz: nem tudtam vidékre levelet küldeni. Visszafelé ment. Nyomozás. Winroute: A konnektor megint ledőlt. Letöröltem a francba. Nem változott semmi. Ilyen nincs. Most már csak az IP site link ívelt át a telephelyre, a címtár replikáció működött, de az Exchange routolás nem. Set-adsitelink, költségek különválasztása, akkor sem.

Ekkor tettem meg azt, amit jóval korábban kellett volna: oda-vissza telnet 25. Lefelé nem ment, lent viszont egyik szerverről a másikra igen. Tűzfal!! – ordítottam fel. Jött is egy tűzfalas ember. Elkezdtem demonstrálni neki:
– Látod, nem megy a 25 port. De ha teszem azt, a 135-öst adom meg, akkor sem… – mondtam, miközben pörgött a kezem… és a 135-ös port átment.
– Igen? – nézett rám kérdőn az ember.
– Any/any van? – hebegtem.
– Persze – bólintott.
– Bocs.

Mi a retek lehet? Transport szolgáltatások futnak. – Receive connector! – csaptam a fejemre. Autentikációk rendben. Network… és akkorát csaptam a fejemre, hogy lefordultam a székről. Egy, azaz egy szám el volt írva a három IP range közül az egyikben a Default smtp receive konnektornál. Így onnan nem fogadott el kapcsolatot. Ez a range pont az egyik pesti LAN volt, két Exchange szerverrel. Ráadásul következetes voltam: a tervben – a jól kidolgozott tervben! – gépeltem el a számot, és utána már mindkét helyen ész nélkül írtam be a rossz értékeket az implementáció során.

Innentől már csak a törmelékeltakarítás volt hátra. Mindent visszaállítani az eredeti elképzelés szerintire. Az összes CAS disztributálja az OAB-ot. Ekkor viszont nem megy az, hogy cegnev user belép a leánynál és letölti az OAB-ot. Szomorú lettem. Végül az lett, hogy anonymous autentikáció az autodiscovery, ews (availability) és oab website-okon. Igen, hőbörgött… de legalább működött.

Persze az OWA továbbra sem ment a vidéki telephelyen – de minden más, mint a svájci óra.

Házirendetlenül

2008-02-18 / / 0 Comments

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.

Nem hivatalos rekordkísérlet

2008-02-16 / / 0 Comments

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.

A betervezett döbbenet

2008-01-31 / / 0 Comments

E-he. Azt hittem, már nem lesz miről írnom. Tévedtem. Van. Csak már nem olyan sok.

Az egyik az a bizonyos ékezetes probléma. Hát, az bizony nem oldódott meg, pontosabban nem úgy, ahogy szerettük volna. A német mérnök ugyanis, miután kijelentette, hogy az Exchange 2007 eltérő viselkedése by design és az ügyfélnek kell újrafordítania a programját, keresztbe tette a karját és várt. Én ugyan célozgattam rá, hogy foglalkozhatna azzal is, hogy miért nem lehet állítani a locale paramétert a Mailbox szerveren, de a füle botját sem mozgatta. Aztán az ügyfél megmozgatott minden követ, felvette a kapcsolatot azzal a külső fejlesztő céggel, aki anno a programot készítette, megolajozta a folyamatot egy kis zsével, újrafordították a programot – és most már jó. Eset lezárva – még csak bug report sem lett belőle. Aztán nem győzött csodálkozni a customer survey hapi, hogy csak úgy röpködtek részemről a hármasok.

A másik… hát, az jó nagy égés volt. Az előző írást ott fejeztem be, hogy leállítottunk minden észnélküli kapkodást, szépen felmértük a terepet, megterveztem mind a rendrakást, mind a további lépéseket. A rendrakás egyik lépése az volt, hogy az AD integrált DNS zónákat átpakoljuk a domain partícióból az applikációs partícióba. Ez egy logikus lépés, így ugyanis a DNS rekordok nem terhelik a GC replikációt.
Megcsináltam. Természetesen bejelentések folyamatosan jöttek az ügyféltől, mint mindig. A gyerektartományban nem működött az OWA – de az mindig is trágya volt. Időnként belassult az ügyfél befelé jövő levelezése. Felhívtak. Visszakérdeztem: hol lassú? – Hát, a unixos smarthost és a nem általunk támogatott brightmail között. Akkor? – kérdeztem vissza, talán túl ingerülten is. Jó, jó – mondták, csak úgy érdeklődtünk.
Ment tovább az élet. Aztán jött egy újabb telefon a helyi rendszergazdától. Hogy mi a jó francot csináltam a DNS zónájukkal? Mondtam, hogy terv szerint átraktam az applikációs partícióba. Miért? Mert megtalálták a hiba okát – közölte – A külső rendszerek számára ugyanis megszűnt mind a cegnev.hu, mind a leany.cegnev.hu zóna. Azt is megtalálták, hogy azért, mert az összes zónáról törölve lett az a pipa, mely engedélyezi a zónatranszfert. Bang. A pofám fémes reccsenéssel szakadt le. Ennyit az alapos tervezésről. A fene sem gondolta volna, hogy azzal, hogy áthelyezem máshová a zónát, valami ellenállhatatlan kényszertől vezérelve a zóna beállításait is megváltoztatja valami idióta mechanizmus. Rémálom… de le kellett nyelnem a békát. Végül is… én nem gondoltam rá a tervezéskor. Persze ennyi erővel arra is gondolhattam volna, hogy a gombra kattintáskor zöld koboldok törnek ki a My Computer ikonból és magukkal ragadják az egérkurzoromat, majd perverz leveleket küldözgetnek a nevemben a nőnemű munkatársaknak.
Hogy még nagyobb legyen az égés, tudni kell, hogy az ügyfél hatalmas erőket ölt bele a probléma megoldásába. Network-ös szakemberei hihetetlen méretű logokat túrtak át. A tűzfalas ember napokon keresztül bogarászta a szabálylistákat. A unixos emberük órákon keresztül reszelgette a smarthostot. Az ügyfél összes informatikusa a problémán pörgött, durván két napon keresztül.
Így amikor kiderült a jelenség oka, biztos lehettem benne, hogy az ügyfél összes informatikusa egyszerre csapott a fejére: már megint az a szerencsétlen nem tudja, mit csinál.

Jó szakma.

Faragások

2008-01-14 / / 0 Comments

A szerverek telepítése pénteken volt. Szombat délelőtt már csörgött is a telefon: nem megy az OWA. Érezhető volt a gyanú, hogy mivel tegnap mi piszkáltuk az Exchange szervereket, biztosan mi keffentettünk el valamit. Nekem meg egyértelmű volt, hogy az organizáció upgrade nem volt szabad, hogy beleszóljon a webes elérésbe… de azért az ördög nem alszik. Megkértem a rendszergazdát, telnetelgessen már be az smtp porton az OWA szerverről a backend Exchange szerverre. Semmi. Akkor esetleg beszélgessen el a tűzfalas emberrel – tettem le a telefont. Mint később kiderült, a tűzfalas kolléga, anélkül, hogy bárkinek is szólt volna, ugyanazon a pénteken cserélt tűzfalat – és a szabályok visszatöltésébe valami hiba csúszott, emiatt az OWA szerver leszakadt. Teljeskörű tűzfal teszt az átállás után… az nem volt. Gondolták, ha valakinek valami baja van, majd szól.
Néhány újabb felesleges ősz hajszál a bozontomban.

Hétfő reggel a helyi rendszergazda kétségbeesett telefonja fogadott: az új konzolból nem érhetők el a gyerektartomány postafiókjai. A fene. Nézzük azokat a Routing konnektorokat… jók. Mi lehet? Nézzük csak az admin konzolját… hát persze, a View beállítás alaphelyzetben csak a root tartomány felhasználóit mutatja. Üde reggel.

Aztán még aznap a Nagyvezér behívatta az IT vezetőt. Hogy sem ő, sem a kulcsemberei nem tudtak a hétvégén OWÁzni. Egy ilyen kritikus időpontban. Úgy lebaszták a hapit, mint a pengős malacot. Közölték vele, hogy az Exchange projektben több hiba nem fordulhat elő. Nyilván az IT vezető is közölte velem, hogy ugye megértettem: több hiba nem lehet. Ja.

Akkor jöhetett a filter konverzió. Az ldap filterek megvoltak, a feltételeket átalakítottam, bemásolnám az OPATH filtert – kövér syntax error. Fejvakarás. A francba… az OPATH nem ismeri az AD objektumokat. De akkor mit ismer? Hát, AD objektumokat. Legalábbis néhányat – de nem mindet. A homeMDB értéket például nem. Hosszú napnak nézünk elébe. Blogböngészés. Evan azt írja, hogy nincs leprogramozható út a két filtertípus közötti konverzióra, ezért nem rakták bele a telepítőbe az automatikus konverziót. Mondjuk, ettől azért zabos vagyok egy kicsit, hiszen emiatt még nem kellett volna megölni a telepítést: például az Address List-ek ldap filterei sem konvertálódtak át, mégis tovább tudott menni a folyamat. Miért kellett a Recipient policy-knél leblokkolni?
Aztán ahogy továbbolvastam ugyanazt a blogot, még zabosabb lettem. Bill Long visual basic-ben ugyanis megírta azt a segédprogramot, melyet kollégája szerint nem lehetett megírni. Letöltöttem. Kipróbáltam. Működött. Néha. Volt olyan feltétel, amelyre működött, volt olyan, amelyikre nem. (Érdekességképpen megjegyzem, hogy a homeMDB érték neve Database lett. Mindjárt más, ugyebár.) Aztán azt is észrevettem, hogy ott nem működött, ahol szerepelt egy olyan feltétel, hogy ‘ne $null’, azaz ‘a tulajdonságnak van-e értéke’ vizsgálatnál. Akárhogy tekergettem, nem fogadta el vele a -recipientfilter paramétert a cmdlet – miközben a net tele volt ilyen példákkal és sehol sem említették, hogy trükközni kellene. A ‘ne $null’ nélkül viszont ment minden. Őszültem megint egy kicsit. Végül kínomban zárójel helyett kapcsos zárójelbe tettem az egész feltételt – és akkor már elfogadta. Az élet apró szépségei.
El se hittem, de délutánra átkonvertáltam az összes Recipient Policyt, tesztek, mindegyik működött. Be lehetett újra röffenteni a RUS-t.

Második forduló: címlisták. Emlékszünk, mind a GAL, mind az Address List-ek ugyanúgy ldap lekérdezések. Itt már nem vacakoltam, Bill Long kis programjával sorra konvertáltam át a filtereket, majd nyomtam be a cmdletből.
Szégyen… annyiszor szoktam mondogatni, hogy ‘ember, gondolkozz’… aztán én magam sem mindig teszem. Miután átkonvertáltam a filtereket, utána kezdtem csak végiggondolni, mit is tesznek ezek egyáltalán? És látszott, hogy a bonyolult átkonvertált cuccok helyett van sokkal egyszerűbb út is az OPATH-on belül, sőt, ezekhez varázsló is van. Na, nem mindhez, de a legtöbbhöz. Itt egy példa:

Ez az az OPATH filter, mely az eredeti Exchange2000 ‘All Users’ ldap filter transzformációjából keletkezett:
(& (mailnickname=*)
(| (&(objectCategory=person)(objectClass=user)(!(homeMDB=*))(!(msExchHomeServerName=*)))(&(objectCategory=person)(objectClass=user)(|(homeMDB=*)(msExchHomeServerName=*))) ))
( ( Alias -ne $null ) -and ( ( ( ObjectCategory -like ‘person’ ) -and ( ObjectClass -eq ‘user’ ) -and -not ( Database -ne $null ) -and -not ( ServerLegacyDN -ne $null ) ) -or ( ( ObjectCategory -like ‘person’ ) -and ( ObjectClass -eq ‘user’ ) -and ( recipientType -eq ‘UserMailbox’ ) ) ) )

Tulajdonképpen bele lehet erőszakolni egy Address List-be. Működni is fog. De ha végiggondoljuk, mit is csinál a szűrő, akkor rájövünk, hogy ugyanezt varázslóval is be tudjuk nyomni.

A varázslónak megfelelő Powershell cmdlet egyébként így néz ki:
Set-AddressList “All Users” –IncludedRecipients MailboxUsers

Nyilván ezekre a szűrőkre is igaz, hogy az egyszerű a szép. És a gyors is.

Már csak a globális címlistával kellett valamit kezdeni – a GAL-hoz ugyanis nincs varázsló. Semmilyen. Elfogyott. Egy logikus kísérlet: get-globaladdresslist. És igen. Innen nyílván működött a set-globaladdresslist is, na meg Bill Long progija. Szuper.
Teszt: új postafiók, mennyi idő után jelenik meg a GAL-ban. Soha. Tudom, nem szabad rohanni, az Exchange a nyugodt emberek platformja, de ennyi zen azért még nekem is sok volt. Jé, van olyan parancs is, hogy refreshGAL. Aztán semmi. Úgy hagytam, mint a vasalt ruhát. És lám, másnap már meg is jelent az új postafiók. A helyi rendszergazda morgott ugyan valamit, de a probléma megoldását elhalasztottuk. Majd, ha sok időnk lesz.

Érdekesség még az ütemezési lehetőség az email address policy/address list kreálásánál. Az ember elsőre azt hinné, ez valami olyasmi, hogy megadott időnként lefut és érvényesíti a házirendet. De persze ennél műveltebbek vagyunk, tudjuk, hogy RUS jellegű tevékenység ebben a verzióban már nincs. Kiváncsian bekapcsoltam, egy héttel későbbre véve az aktualizálást. Nos, azt csinálta, hogy amikor leokéztam a varázslót, megjelent egy számlálóablak. Amelyikben elkezdett visszafelé számolni. Másodpercenként. Egy hetet. Addig persze a konzolt nem lőhetem ki, mert menne vele a számlálós ablak is. MegaLOL. Cancel.

Szünet. Egy hét idegnyugtatás az őszi erdőben. Hegynek föl, völgynek le.
Ügyfél ezalatt hozzá se nyúlt a rendszerhez.
Visszajöttem. Az első barátságos pillantások hamar elsötétedtek: a System Attendant nem megy. Az Information Store megy ugyan, de újraindításkor bevés valami hülye hibát az eseménynaplóba. Az SA meg elindul ugyan, ezt be is írja, de utána egyből leáll. Hibaüzenet utáni turkászás, sehol semmi. EventID hallgat, Google szintúgy. Addig jutok, hogy jó eséllyel valami ldap cucli lesz. Beugrik, hogy valahol be lehet állítani, melyik GC-t részesítse előnyben a szerver. Lehet, hogy az a baj, hogy van a címtárban néhány nem w2k3 DC/GC? Állítsuk be mind organizáció, mind szerver szinten, melyik DC-t használja. Semmi javulás. Kínomban újraindítottam a gépet – és innentől tökéletesen megy.
Nem jósolok hosszú karriert a gyerektartomány W2k tartományvezérlőinek.

ps.
Nem sokat dobott a jókedvemen, hogy az egész cirkusz után jelent meg Bill Long írása erről az egészről. Ebből az derült ki, hogy a telepítő csak a _felesleges_ zárójelektől és & jelektől akad ki – ergo maradhatott volna az ldap filter, csak adsiedit-tel ki kellett volna műteni a többletet. Köszönöm, fiúk. Azért a KB cikkbe is beleírhattátok volna.

Cause 3
There is a parenthesis or an ampersand in a recipient filter. Additionally, Exchange 2007 uses OPATH filters instead of LDAP filters.

Itt ugye egy szó sincs arról, hogy _felesleges_.

De azért ne hagyjuk ezt annyiban, nézzük csak meg pontosabban, mit is mond Bill?

Although Active Directory itself has no problem ignoring the unnecessary ‘&’, Exchange 2007 setup doesn’t like this at all.

The parentheses surrounding the server name in the value confuse setup, causing the same behavior.

Érted? Tehát azok az emberek, akik az Active Directory-t fejlesztették, le tudták kezelni azokat az eseteket, amikor egy név az ldap filterben zárójelet tartalmazott, vagy bekerült egy felesleges műveleti jel (&). Ellenben azok a kutyaütők, akik az Exchange setupot írták, sajnos már nem. Ezért hal be a setup.
Valamikor mindenesként dolgoztam, ami azt jelentette, hogy kódoltam is, mint állat. Volt egy beosztottam is, egy gépésztechnikus srác, akit én tanítottam meg programozni. Azt hiszem, zokogva szúrtam volna tökön magam, ha a srác képtelen lett volna egy ilyen beviteli stringet parszolni. Pedig mi tényleg kutyaütők voltunk.

Az Exchange organizáció átállítása

2008-01-09 / / 0 Comments

Nekiállhattunk becsempészni az első Exchange2007 szervert.
A szakirodalom ajánlása szerint – ha azt akarjuk, hogy az OWA proxyzások jól működjenek – a CAS szerepkört érdemes külön gépre tenni, tehát mi is két szervert terveztünk. Szintén ajánlás, hogy először a CAS szervert állítsuk üzembe, de mivel mi egyelőre egyik 2007-es szervert sem terveztük élesben használni – tényleg csak becsempészni szándékoztuk – ezért nekünk jó a régi OWA is.

Mielőtt bármibe is belekezdtünk volna, lefuttattam a telepítő cédéről az MBSA-t. Volt is nagy csodálkozás. Egy csomó piros jelecske mutatta, hogy ez a telepítés bizony nagyon hamar lyukra futott volna. Ilyenek voltak benne pl, hogy az egyik Exchange2000 szerverre még kell az SP3. Kérdőn néztem a helyi rendszergazdára. Oké, oké, mindjárt fent lesz – szaladt el. Valamelyik szerverre már le volt töltve, gyorsan felszórta. Abban a pillanatban megfeküdt az éles szerver, nem indult el az Information Store. Hurrá. Bogarászás, kurkászás, majd kiderült, hogy az Exchange 2000 SP3 szerver verziószáma nem egyezik a hivatalos verziószámmal. Rákeresve a neten az is kiderült, hogy a korábban általuk letöltött cucc egy béta SP3 volt, melyről rémtörténetek keringtek a neten. Szerencsére le lehetett vakarni, letöltöttük a jó szervízcsomagot, felraktuk, minden rendbe jött.

Telepítés elindult, bekattogtattam, hogy akkor egy Mailbox és Hub Transport szerver rendel. Csíkhúzás, hibaüzenet. Az elsőnek telepíteni szándékozott HTR szerepkör nem megy fel, az üzenet szerint hiányzik egy /64 könyvtár a telepítő cédé egyik bugyrából. Mivan? Megnéztem, tényleg nem volt ott. Milyen telepítőmédiát adtál már megint? – néztem kérdőn a helyi rendszergazdára. Szegény, nem győzött szabadkozni, hogy ez aztán tényleg az és tényleg originál. Irány az MSDN, az a biztos, amit saját egérrel kattogtatok össze. 5,5 GB. Amíg vánszorgott lefelé, nekiálltam kószálni a neten. Mint kiderült, a hiba ismert. A Microsoft szerint rossz a telepítő média. Ja, persze. Szerencsére máshol is megtaláltam a hibát és itt már többen is jelezték, hogy ádehogy, ez egy bug. Újra neki kell szaladni a telepítésnek, akkor már átdöccen ezen az akadályon.
Hát, jó. Megpróbáltuk, bevette. Most a Mailbox szerver komponensnél szállt el. Azt mondta, hogy “The Exchange server address list service failed to respond”. Jó, irány újra a net. Meg is van hozzá az írás, KB935636. Hamar kiderült, hogy az első két eset irreveláns volt, maradt a harmadik. Ezt elég nehezen értettem meg, elsőre csak annyi jött le, hogy illegális karakterek vannak a recipient policy beállításokban. Megnéztem, tényleg. Ugyanis Exchange2000-ben ha automatikus emailcímgenerálást választottunk, akkor az ‘ö’ helyett ‘oe’-t, az ‘ü’ helyett ‘ue’-t generált a szoftver. Ennek kivédésére a rendszergazda lecserélte a karaktereket, még mielőtt a generálás megtörtént volna. (%röo %rüu %rÖO %rÜU.) Tuti ez a baj. Kitöröltük az összes cserét. A telepítés ugyanúgy zátonyra futott. Elolvastam figyelmesebben a KB cikket. Aztán elkezdtem hisztérikusan kacagni. Azt mondja, az a problémája, hogy az ldap filterben ‘(’ és ‘&’ karakterek vannak. Persze, hogy vannak! Ezek kábé annyira lényegi részei egy ldap filternek, mint szélsőjobbos nénike sétafelszerelésének a tojás és a kereplő. Enélkül nem az, aki.

Dehát… más megoldás nem volt. Kiszórtuk mind a 8 recipient policy-t. Innentől az organizáció nem fogadott levelet sehonnan. Szerencsére hülye címeket sem osztogatott, mert leállítottuk a RUS-t.

És igen, most már lefutott a telepítő. Gyorsan lecsekkoltuk az accepted domain értékeket, hogy legalább leveleket kapjunk. Utána megnéztük, mit tudnánk kezdeni az email address policy beállításokkal. A helyi rendszergazda majdnem elsírta magát, amikor meglátta mennyi lehetőséget nyújt a varázsló. Nagyon ragaszkodott szegény az adatbázisonkénti külön emalcím megadásához. Szerencsére beugrott, hogy olvastam én valahol az OPATH filterekről. Ezek fogják leváltani az ldap filtereket. És tényleg. Megtaláltuk az írást, megtaláltuk, melyik cmdlet melyik paraméterével lehet beemelni a filtert – aztán gyorsan félreraktuk a problémát. Van sürgősebb. A RUS áll, policy nincs – reméljük, ebben az átmeneti időszakban címváltozás sem lesz.

Nézzük a routingot. Katasztrófa. Az új Routing Group létrejött ugyan, de konnektor nincs. Az ExchangeLegacyInterop csoport is üres. Bakkerbakkerbakker… haza akarok menni. Gyümölcsfát akarok ültetni. Bármit, csak ezt nem. Szerencsére a korábbi fórumos linken Nick megírta a frankót: egyenként le kell szedni a szerepköröket, amíg el nem tűnik a szerver. Aztán újrakezdeni a telepítést, de immár parancssorból – és egyenként felrakva a szerepköröket.
Egész konkrétan:

  • Hub Transport szerver telepítése:
    setup.com /mode:install /roles:hubtransport /targetdir:d:/exchsrvr /domaincontroller:dc2003sp1gc.cegnev.hu /legacyroutingserver: exchange2000.cegnev.hu
    Értelemszerűen az utolsó paraméterként azt az Exchange szervert kell megadni, amelyikhez szeretnénk kötni az Exchange2007 routing groupot.
  • Mailbox szerver telepítése:
    setup.com /mode:install /roles:mailbox /targetdir:d:/exchsrvr /domaincontroller:dc2003sp1gc.cegnev.hu /enablelegacyoutlook
    Nem győzöm az utolsó paraméter fontosságát hangsúlyozni. Részletesebben lásd itt.

Mondjuk a Mailbox szerepkör megint lehalt: már van fent adatbázis. Nem sokáig. Gyors ellenőrzés: minden oké. Végre. Igaz a policy nem működik, a címlisták nem működnek, a jogosultsági rendszerre visszamásztak a deny-k… de már nagyjából Exchange formája van.
Jöhetett külön vasra a CAS telepítés, most már dafke parancssorból. Menetközben kékhalál. Fel sem vettük, újraindítottuk a masinát, a telepítés simán továbbment.

Mára vége. Már megint holnap lett.

A diszpécser a taxiközpontban hangról beazonosított. Éjfél után úgy látszik nincs nagy mozgás errefelé.

Bénázás a parancssorban

2008-01-07 / / 0 Comments

Tiszta volt a terep, mint a téli ünnepek között a legtöbb iroda.
Kezdhettük preparálni a címtárat.

Első lépésben nem akartuk az összes Exchange szervert átállítani, csak a forest root tartomány szervereit céloztuk be. Ebből kifolyólag a gyerektartományt nem is frissítettük, meghagytuk Windows2000 natív módban. Az itiner is azt mondta, hogy

“In each Active Directory site where you plan to install Exchange 2007, you must have at least one domain controller that is also a global catalog server and is running Windows Server 2003 SP1 or a later version.”

Azaz csak azon a telephelyen kell lennie W2k3Sp1 GC-nek, ahová Exchange2007 szervert akarunk tenni. Márpedig egyedül a gyerektartománynak van külön telephelye, a többiek egy kupacban vannak.
Ügyfél egy kicsit megnyugodott, idén csak ennyi pénze volt, a teljes átállás második felére akkor ráér jövőre erőforrást ütemezni.

Ennek jegyében a gyökértartományt w2k3 szintre frissítettük. Bedugtam az Exchange telepítő cédét a friss, harmatos gépbe, aztán
setup.com /PrepareLegacyExchangePermission.
Azt mondta, hogy nincs ilyen paraméter, próbáljam meg a setup /? figurát. Megpróbáltam. Tényleg nem volt. Egy világ dőlt össze bennem. Írtam cikket erről a parancsról. Vizsgán egy csomószor adtam meg helyes válaszként. Akkor most mi van?!
Utánaolvastam. Az van, hogy a parancs sok jogosultságot módosít. Tehát permissions.

Boldogan elindít, parancs dolgozik, majd kikattan, mint órarugó. Azt mondja, hogy a gyerektartományban nincs w2k3sp1 GC. Persze, hogy nincs. Direkt nincs. Úgy terveztük. Mit akadékoskodik a köcsög? Itt van, pár sorral feljebb, hogy csak akkor kell, ha e2k7 megy oda.
Most akkor kinek van igaza?

A parancs helpje továbbra is hülye, marad a gugli. Ott van, hogy létezik egy /domaincontroller:<dc_fqdn> paraméter. Remek, adjuk meg az egyik root dc-t. Ugyanaz. Kikattan.
Én is. Ezután tuti, hogy elevenen nyársalnak fel. Az egész projekt azon alapult, hogy a gyerektartományt békén kell hagyni, a gyökértartományt meg át kell csúsztatni. Én meg bátran alapoztam arra a bizonyos mondatra az MS dokumentációban – mely szemmel láthatóan nem igaz.

Eszeveszett további keresések. Az eventid.net akkora baromságot mond a hibára, hogy én szégyellem magam. Aztán jön egy szerencsés találat: kiderül, hogy a parancsnak van egy speciális változata:
setup.com /PrepareLegacyExchangePermissions:<domain-fqdn>
Ekkor csak azt a tartományt frissíti, melyet megadtunk, a többit nem nézi.

Mehetünk tovább. Replikáció letilt, prepareschema. Megint ugyanaz. Kell neki a w2k3 GC. Megadóan keresem a /domain kapcsolót… de itt már nincs. Bakker…. a projektünk csak bedőlt az árokba. Kétségbeesett keresés. Első találat: egy MVP kolléga, ki van kattanva, de rendesen. Hogy szar a doksi, más a valóság. Én legalább ennyire ki vagyok kattanva: frissíttessem a gyerektartományt az ügyféllel, plusz szerverek, plusz pénzek, egy-két hét csúszás? A következő találat se nagyon dobott fel: az Exchange blogon írják, hogy hát, igen, elkúrtuk. De majd a sohakinemjövő sp1-ben javítjuk. Addig vagy ne telepítsél Exchange-t, vagy pakold tele – feleslegesen – a tartományaidat új vasakkal. Végül az ügyfél úgy dönt, hogy inkább leperkál 800k-t és belevágunk most a gyerektartományba is. Nekem ég a pofám… és az ügyfél szerint jogosan, mert én vagyok a szakértő. Az nem nagyon vígasztalja, hogy a hivatalos doksiban annak ellenére van valótlan követelmény, hogy a fejlesztők a nyilvánosság előtt ismerték be, hogy nem úgy van. Ahelyett, hogy a specifikációt frissítették volna a dokumentumtárban…

Preparáció elhalasztva.

Később kiderült, nem eszik annyira forrón a kását, elég betenni egy Windows2003 Sp1 DC/GC szervert a meglévő Windows2000 DC mellé, akkor már jók vagyunk, a tartományi upgrade ráér. Nagy sóhaj, csináljuk. Rossz sejtéseim vannak. (Azóta kijött az SP1, elméletileg már nincs ez a hiba, van helyette másik, lásd itt. Aranyos. 2007.12.30)
Mindenesetre a preparáció végül szépen lement. Apró finomság, hogy a setup /preparedomain parancs kiadásához nem volt jogom a gyerektartományban – nem voltam domain admin – de a gyökértartományban kiadott setup /preparealldomains már végigsöpört az összes tartományon – ugyanis ahhoz az enterprise admin jog kell, az meg megvolt.

Tartományi konszolidáció

2008-01-03 / / 0 Comments

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.