MonthMarch 2008

Mennyi? Harminc!

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íz körömmel kapaszkodva

Beindítottuk ezerrel a mozgatásokat. Elindultak a Public Folderek és elindultak a felhasználói postafiókok is; a cél az volt, hogy a régi szerverek adatbázisai teljesen üresek legyenek. (Eltekintve egy darab régi szervertől, mert onnan tudtuk elérni a PF adatbázist. Az Exchange 2007 SP1-gyel egyelőre még nem akartuk bonyolítani a rendszert.)

Nem is lett volna ezzel semmi baj… csakhogy az előállt káosz nem működött. Hiába lett alaposan végiggondolva, hiába sikerültek a műveletek előtti tesztek, a valóságban teljesen érthetetlenül alakultak a dolgok. Bizonyos elérések működtek, bizonyos elérések nem. Ha teszteltünk egy elérést, működött, ha használni akartuk a postafiókot, akkor nem. A free-busy mátrixon annyi lyuk volt, mintha sörétespuskával durrantottak volna bele – ráadásul a minta is illogikus volt.
Más lehetőségünk nem lévén, előre menekültünk. Közöltük mindenkivel, hogy _nem_ fogunk hibákat javítani és nem fogunk a rendszer stabilizálásával foglalkozni – ehelyett amilyen gyorsan csak lehet, lepörgetjük a mozgatásokat és kihajítjuk a régi Exchange 2000-es szervereket. (Amilyen gyorsan csak lehet… persze a Public Folderek nem arról híresek, hogy túlzottan kapkodnák a seggüket – és akkor még nem is beszéltem a postafiókmozgatások egyeztetéséről.)

De végül csak elértünk odáig, hogy üres lett a vidéki Exchange 2000 szerver. (Mondjuk, az üres enyhe túlzás: a PF instance-ok között még ott volt egy OAB folder; egy olyan, melyen már nem volt beállítva a kérdéses szerver, mint tulajdonos.) De ettől még nekimentem. Control Panel, Add/remove programs, Exchange 2000, remove. Végigmentünk a varázslón, szervízek leálltak… majd kiírta a következő borzasztóan szellemes üzenetet, minden eltávolítandó szolgáltatásra külön-külön.

Setup failed while (error 0×8000FFFF: An unexpected error occurred.)

Additional information:
An unexpected error occurred.

Ízlelgessük. Garantáltan nem fake, tényleg képes volt az alkalmazás egy ilyen hibaüzenetet a képembe tolni.
Ekkor még nem voltam igazán ideges. Amit az utóbbi években nem tanultam meg Exchange szerver likvidálásból, azt már nem is érdemes tudni. Őszintén szólva, nem is számítottam gyors sikerre.

Elkezdtem a skálázást.

1. Idézet magamtól:

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.

Megkerestem. Teljesen szabályos felhasználót találtam, másik Exchange szerveren lévő postafiókkal.

2. KB279202. Itt találunk különböző módszereket arra nézve, hogyan állapíthatjuk meg, mely felhasználók ragadtak be láthatatlanul egy postafiókba. Végigzongoráztam mindegyik módszert, de nem találtam semmit.

3. Teljes gőzzel beindítottam a guglizást. Rengeteg hivatkozást találtam ugyan rá, de… ezek nagy része más – de azonos kódú – váratlan hibára utalt, a maradékban pedig valami kérdező feldobta egy listára a hibát… aztán néma csend. Senki sem tudott értelmesen válaszolni.

4. Abbahagytam az internet faggatását és használtam egy kicsit a józan eszemet. Mint az közismert (hogy mondta, Safranek?), minden adatbázisnak van egy homemdbbl tulajdonsága, mely tulajdonképpen egy backlist. Egy tömb, mely azon felhasználók DN értékeit tartalmazza, akiknek a homemdb tulajdonságának az értéke az illető adatbázisra mutat. (Azért backlist, mert a visszanyalás automatikus.) Ebből halálpontosan lehet tudni, ténylegesen kik tartoznak még az adatbázishoz. De akárhogy is néztem, mindenhol csak a system felhasználókat találtam, azokat viszont, ahogy Evan is írta, nem érdemes törölni. Nem akadályozzák meg az uninstallt.

5. Maradt volna a durva kiherélés, amelyről itt már írtam. Nem tudom, ki hogy van vele, de én irtózom az ilyesmi brutális módszerektől. Nyilván végső menedékként jó, ha vannak ilyen eljárások is… de kérdés ugye, hogy mennyire lesz megbízható a későbbiekben egy ilyen szétkurkászott szerver. És ezen még fájlszerver volt, mentőrendszer volt… meg mittudomén. Mint ahogy egy erőforráshiányos vidéki telephelyen illik.

6. Nézegettem, nézegettem azt a hibaüzenetet… aztán egyszer csak megtaláltam a gördítősávot – és előjött a hibaüzenet folytatása. Ránézésre valami debug jellegű dolognak tűnt – de nézzük már meg alaposan azt a folyamatot, ahol elhasaltunk.

Function:
CComExchSetupComponent::HrPromptForCDIfNecessary
CComExchSetupComponent::Install

HrPromptForCDIfNecessary – mintha azt mondaná, hogy cédét kér. És mivel nem kap, ezt unexpected (váratlan) hibának tartja. Nézzük csak meg, mi lenne, ha nem a Control Panelből indítanám az eltávolítást, hanem telepítőcédéről? Mi kell ehhez? Telepítő média. Exchange 2000. Péntek délután. Az ügyfélnél. Helyi rendszergazda roppant lelkes, előtúr valahonnan egyet. Igenám, de ez egy vidéki szerver, márpedig a sávszélesség finoman szólva sem acélos. Telefon a vidéki embernek. Ő is talál egy Exchange 2000 telepítőcédét valahol. Amikor elhűltem ekkora mázli láttán, blazírtan megjegyezte, hogy a cédé ott volt közvetlenül a Windows 3.11 telepítő floppyk mellett. Atyám.
A puding próbája az evés. Cédé bele a meghajtóba, telepítő elindít – hibátlanul végigmegy. A szerver megszűnt a továbbiakban Exchange szerverként létezni.

Gondoljuk végig még egyszer, mi történt? Egy program elindult, elkezdett leszedni egy alkalmazást, majd kellett volna neki néhány fájl egy cédéről. Mit csinált? Nem, nem mondta azt, hogy “b+ haver, told már be azt a cédét”, hanem ehelyett beleordította a nagyvilágba, hogy “unexpected error”, majd elszállt. Csak gratulálni tudok mindenkinek, aki részt vett eme csodálatos kód megírásában.

Azt hittem, ebben a projektben többször már nem harapok bele az asztallapba.
Tévedtem.

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

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.

Kilőtték

Mármint a Windows Server 2008-at, az SQL 2008-at meg a Visual Studio 2008-at. Jó magasra.

Lurdy-ház, megint. Nagyon sok az ember. 9.20-as érkezéssel már csak a B terem maradt. De a kollégáimnak itt is csak a lépcsőn jutott hely. És még rengeteg badge hever a recepción átvetetlenül.
Hát, ez a terem már nem olyan személyes… különösen akkor, amikor a kép is elmegy. Viszont szabadon lehet zajongani, nem zavarja az előadókat.

Előadások. Eleinte nincsenek. Az első blokk keynote – annak viszont nagyon jó. Senki nem csúszik, minden feszes, jól ment. Áttekintésnek pont megfelelő. Egyedül a gps-es hapi verte ki nálam a biztosítékot, különösen a megrendezett bekiabálásnál. De mindegy, valahol bóbiskolni is kellett.

Szünet. Reflexek. Mindenki az étterembe. Marci őrzi a labort, meg azt a két bátor kísérletezőt.
GT előadása: server core reloaded. Régen is jó volt, most se rossz. Mint amikor az ember másodjára is megnézi a Csillagok Háborúját.

Ebéd… az speciel nem jött össze. Keringtünk néhányan az asztalok körül, de még csak megpillantani sem sikerült a kaját -> Meki.

Ebéd után folytatódott a keynote stílus: 45 perc, 3 ember. Dacára a hálátlan időpontnak, ezek az előadások is lendületesek voltak. Az pedig mindig jó ötlet, ha Soci zárja az előadásokat. egyrészt sokan maradnak, másrészt kevesen alszanak el.

Majd jött az afterparty, de ezen már nem maradhattam, mert munka mint tenger.

Egyébként jó volt. Nem szántottak túl mélyen a fiúk, inkább csak asztalra lett téve a termék: emberek, most jó ideig ezzel fogunk foglalkozni.