Month: January 2008

A betervezett döbbenet

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.

Outlook – look out!

Örültem az Outlook2007-nek, a grafikai újításai határozottan tetszenek. Azóta élvezettel használom újra a Calendar/Task részét, teljesen jól átlátható lett, tényleg segít a tervezésben. De két dolog megkeserítette az örömömet.

Az egyik a beépített kereső. Lassúúú. Nehézkes. Oké, bele lehet rakni a Desktop search-öt, de egyrészt nem örülök neki, hogy az mellesleg nekiáll a fájlrendszert is piszkálni, másrészt nem sokkal lesz gyorsabb tőle a keresés.
A másik szívfájdalmam a lassú indulás. Az Outlook 2003 elindult, fél percen belül lekapta az átlagosan napi 100 levelet – és szét is szórta a folderekbe. Ezzel ellentétben az Outlook 2007 – ugyanazokkal a szabályokkal – simán elszuttyog 4-5 percig is a levelekkel, úgy, hogy az utolsó egy percben már nincs is mit letöltenie, mégis, az utolsó néhány levél még nem jelenik meg. Valahol a semmi szélén lebeghetnek. Egyhetes nyaralásról hazatérve lazán összejön a 20 perces várakozás is. (Patch, Sp1 mind fent van.)
Eleinte azt gondoltam, lehet, hogy a desktop search kavar be, azért ilyen lassú. Bizonyos okokból többször is újra kellett telepítenem a gépemet, az utóbbi időkben már nem is raktam fel az asztali keresőt – de nem lett jelentősen gyorsabb. Inkább le is mondtam a keresgélésről – pontosabban, használtam a fejembe épített indexfájlt.

Egészen addig, amíg rá nem bukkantam, hogy Joel-t ugyanez a féreg rágja. Csakhogy ő a megoldást is megtalálta: lookout.
Ez egy népszerű, apró programocska volt, semmi másra nem lehetett használni, csak arra, hogy Outlook adatokat indexeljen és keressen bennük. Ezt viszont piszok jól tudta. Olyannyira jól, hogy a Microsoft fejlesztőstől együtt meg is vette a terméket. Hogy aztán itt mi történt, hogyan történt, arról túl sokat nem lehet tudni, de a fejlesztő hamarosan kilépett a cégtől, a program pedig a mai napig nem épült be az Outlookba. Maradt a Desktop Search. Ráadásul a helyzet annyival rosszabb is lett, hogy az Outlook 2007 alá már nem lehet feltelepíteni a programot, mert a levelező nemes egyszerűséggel nem indul el.

Aranyos. Szerencsére Joel nem hagyta annyiban, utánanézett és a fejlesztő blogjában talált is egy írást. Eszerint az illető megtalálta, miért nem indul az Outlook és le is írta, hogyan lehet körbedolgozni a problémát. Letöltöttem, körbedolgoztam, kipróbáltam – remekül működik. Piszok gyors és nem kér enni.

De az Outlook még mindig rohadt lassan indul.

További faragások

Tesztelgettek egy kis Calendar-t, OWÁ-t, Blackberry-t, végül a helyi rendszergazda úgy döntött, hogy átmigrálja az összes postafiókot az új Exchange szerverre. Távolról – egyenesen Barcelonából – szurkoltam neki.
Amikor visszajöttem, alapvetően elégedett embereket találtam. Még működött a rendszer. Az utóbbi időben kicsit visszavettek az igényeikből.

De persze kisebb-nagyobb problémáik voltak.

Az Insource panaszkodott, hogy nem látják senkinek sem a foglaltsági információját. Meg hiába foglalnak le tárgyalókat, nem jelenik meg a foglalásuk. Ellentesztek. Mindenkinek működik. Kérdeztem a rendszergazdát, mi különleges lehet az Insource gépeken. Hosszas fejvakarás. Végül kinyögi, hogy ők külön címtárban vannak, mely össze van trustolva a cég címtárával. B+. Egy preparálatlan címtár. Pár óra vakaródzás nálam is, aztán szép lassan megszületett a megoldás: abban a tartományban nincs SCP objektum a címtárban, így nem érik el az Autodiscovery szolgáltatást. Outlook teszt, kibogarásztam, milyen DNS néven keresi a kliens a szolgáltatást. Rövid nyomozás, milyen DNS szervert is használnak a fiúk, aliasként felvettem benne a CAS-ra az autodiscovery nevet, egyből megjavult minden.

A gyerektartományba nemrég felvett úriember neve viszont nem jelenik meg a globális címlistában. Az istennek sem. Várunk vele, rugdosok mindent, nem és nem. Hazafelé már a fákat és a köveket is rugdosom, hátha az segít. (A mélypont és a lenyugvás.)
Elsőre persze a GAL-ra gyanakodtam. Végigböngésztem, mit is csinál és úgy véltem, túl bonyolult a szűrőfeltétel. Ki kellene cserélni. Szűrőcsere… mint a gépkocsikban. Végülis… elég lenne annyi kritérium, hogy legyen alias értéke az objektumnak. Nosza. Nem lehet. Ha már egyszer sikeresen módosítottad a GAL-t, akkor azt többször nem lehet. Miaf? Ez mekkora kreténség már…?
Beleástam magam a szakirodalomba. Utólag már azt mondom, megérte az a másfél nap kinlódás. Most már sokkal jobban átlátom, mi is zajlik a mélyben. (Olyannyira, hogy lett is belőle egy Technet cikk.) Végigmentem egyenként a láncon, begyorsítottam mindent, amit csak lehetett, végül megtaláltam azt is, hogy a leánytartományi RUS egy olyan GC-hez volt rendelve, melyet menetközben a rendszergazda – velem egyeztetve – megszűntetett, emiatt állt le az aszinkron frissítgetés. Ez is ki lett pipálva.

Aztán belefutottunk egy olyan szopásba, hogy van egy SQL rendszer, mely ékezetes karaktereket tartalmazó ASCII kódolású leveleket küld a leánytartomány Exchange2000 szerverére. Ott még ékezethelyesek a levelek. Aztán amint átjutnak az Exchange 2007 Mailbox szerverre, akkor teljes katyvasz lesz a levelekből. Az első gyanú a locale beállítás. Az Exchange2000 szervereken magyar és angol. Az Exchange2007-ben… default. A get-mailboxserver szerint ugyanis üres az érték. És nem is lehet módosítani, hiába próbáltam akár szöveges formában, akár decimális, akár hexadecimális formátumban beadni a magyar locale-t.
Tudomány elfogy. Bejelentettük az esetet a PSS-nek. Még mindig náluk van… de egyre inkább úgy tűnik, azt fogják mondani, hogy ez by default és RFC kompatibilis és alakítsam át úgy az SQL rendszert, hogy más karakterkészlettel menjen a levél. Az ügyfél baromira fog neki örülni. Eddig egyedül az Exchange2007 OWA jött be nekik, minden másra azt mondta, hogy sok kényelmetlenség semmiért.

Aztán egyszer csak váratlanul vége szakadt az őrületnek.
Menetközben beindult a többtelephelyes gyerektartomány tartományi migrációja, gyakorlatilag nélkülem. Ekkor már amit lehetett, azt helyi emberrel csináltatták meg – a rendszergazda meg már végigcsinált egy tartományi migrációt, látta, hogyan megy. Egyedül a DHCP okozhatott problémákat, erre megigértem, hogy majd utánanézek. Ehhez képest azért meglepődtem, hogy anélkül demotáltak egy DC-t, hogy nem szóltak, azt sem várták meg, utánanéztem-e a DHCP-nek. Aztán az üzemeltetési szempontból kritikus telephelyen egyszer csak megállt a DHCP szolgáltatás. Rövid időn belül mindenki szaladgált össze-vissza, mint pók a falon. Routermágusok vetették be magukat, eredmény nélkül. Már olyan embereket is felhívtak, akik anno a rendszert építették, csak azóta máshová mentek dolgozni. Gondoltam, én is megnézem, mit tehetnék. Rövid keresgélés után belebotlottam, hogy a telephelyi DC-re DHCP Relay lett telepítve, mely a demotált DC-re mutatott. Átállítottam az újra, beindult minden. Aztán kiderült, hogy a DNS áthelyezése sem igazán sikerült – és ekkor még igen finom voltam. Azt is rendbetettem. De már késő volt, ezt a bakit a cég már nem nyelte le. Csúnya veszekedések jöttek, indulatos ordibálások. Aztán az IT vezető írt egy körlevelet, miszerint az egész projekt műszaki tartalmáért én egyszemélyben vagyok a felelős, tehát tessék engem anyázni. Erre bepöccentem, én is írtam egy levelet, hogy a projektnek ebben a formában vége. Le fogok ülni, összeszedem, hogyan állunk, és aprólékosan meg fogom tervezni, hogyan lehet a rendszert egyenesbe tenni. Csak ez a tervezés tartott 3 hétig. Érdekes módon most már nem volt tiltakozás – pedig ekkor már negyedik hónapja(!) ment ez a projekt ilyen eszetlen tempóban.

Tanulság? Már itt is látszik. Az olcsójános technika megbosszulja magát. A durrbele-észnélkül-ügyesekvagytokfiúk_megtudjátokcsinálni mentalitás ekkora átalakításoknál nem működik. Ami több hónapos projekt, azt nem lehet hetekbe sűríteni, különösen úgy nem, hogy a tervezést hagyjuk el belőle. Ráadásul szakmailag ismeretlen terepen… Itt is látszott, még akkor is belefutottunk volna egy-egy nagyobb szopásba, ha mindent alaposan megtervezünk a rendelkezésre álló szakirodalom alapján. Ezért kell ismeretlen terepen külön időt hagyni laborkisérletre is – és az alapján kell írni a tervet. Persze nehéz akkor, ha stratégiai okból a munkát el kell vállalni, az ügyfél IT vezetője viszont nem érzékeli a munka nagyságát, nem tartja fontosnak a tervezést – aztán a végén persze mindent a külső cég nyakába varr. (Amiben persze meglehetősen groteszk módon _formálisan_ igaza van: a helyi rendszergazda és a tűzfalas ember valamikor az Ügyfél alkalmazásában álltak, aztán átkerültek hozzánk, a projekt idején teljes mellszélességgel éppen hozzánk tartoztak, de most, amikor ezt írom, már megint az Ügyfél alkalmazottai.)
Még valami. Nem tudom, ki mennyire figyelmesen olvasta el az írásokat… de talán akad egy-két ember, akiben felhorgadt valamiféle hiányérzet. Igen, sehol sem említettem meg egy nevet: azt, hogy projektmanager. Nem volt. Elfogyott. Gyakorlatilag mindkét cég úgy állt hozzá, hogy ez egy hipp-hopp upgrade, lekeverjük hamar. Én hiába küldözgettem mindkét irányba a jeleket, hogy ez így nem fasza, csak mosolygásokat kaptam: ügyes gyerek vagy, majd megoldod. Hát, nem. Kockafejűként nehéz ilyet beismernem, de egy bizonyos bonyolultság felett már szükség van dedikált PM-re. Ne a technikai embernek kelljen már a (fejben)tervezéssel meg az implemetálással küszködve még az Ügyféllel is harcolni.

Tulajdonképpen a történetnek itt vége is van. A projekt még megy, egész biztosan lesznek még benne izgalmas dolgok, de innentől már sínen vagyunk. Tervezés, döntés, implementálás – és ugyanez annyiszor, míg az átalakítás végére nem érünk. Ebből nem fogok engedni.
Ha már én lettem az egyszemélyi felelős.

Faragások

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

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

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ó

A helyi erők a migrációt már elvégezték. Amikor odakerültem, már minden kongott az ürességtől.
Az összeszorított fogak közül kiszüremlő kifejezések ennek ellenére már az első körülnézéskor előbukkantak. Ha azt mondom, hogy a megszűntetendő tartomány ebek harmincadján volt, akkor finom voltam. Tartományvezérlő, melyet egyszerűen csak kikapcsoltak és újratelepítettek máshol. Ugyanez Exchange szerverrel is. Az egyetlen fizikailag létező Exchange szerver külön Routing Groupban volt. Némileg cifrázta a helyzetet, hogy a Routing Group Connector-t viszont másfél éve lebontották. A postafiókokat pst-kkel lapátolták át. Kismillió public folder. Szükség van rájuk? Persze! – jött a válasz.

Visszaépítettük az RGC-t. Kismillió replikációs konfliktust jelző levél söpört végig napokon keresztül a levelező szervereken. (Ugye tudjuk, a public folderek a két replikáció közötti párhuzamos módosítások esetén nem az időbélyeg alapján döntik el, melyik módosítás a frissebb, hanem levelet küldenek mindkét módosítónak, hogy csókolom, tessék leharcolni egymás között, kié legyen az érvényes. És itt volt másfél év, replikáció nélkül.)

Végül mindegyik folderről született replika másik szerveren is, így levehettük a példányokat a megszűntetendő szerverről. Ez már csak napok kérdése volt. Az IT vezető itt kezdte el rágni a kefét, hiszen az egész tartománytörlésre egy nap volt ütemezve.
De végre eltűntek a public folderek, lehetett eltakarítani az Exchange szervereket. Rögtön az elsőnél földön koppant az állam: az Add/Remove panel szerint a Windows szerveren két példányban is futott az Exchange szerver. Ráadásul az egyiknek olyan verziószáma volt, mely a hivatalos táblázatok szerint nem is létezett. Fejvakarás. Megpróbáltam mindkettőt eltávolítani. Az egyiknél már a telepítő sem indult el. A másiknál elindult, de amikor azt mondtam neki, hogy mars ki, azt válaszolta, hogy “There is no such object on the server”. Azaz a kettőből elméletileg egy sem létezett. Ismerjük el, azért van abban némi kihívás, hogyan távolítsunk el egy gépről két darab nemlétező Exchange szervert. Feltettem a hegesztőszemüveget, előkészítettem a registry editort, az adsieditet és a szokásos mmc konzolomat. Csak nagy vonalakban:

  • Exchange szolgáltatások leállít
  • Exchange registry beállítások kigyomlál:
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DAVEX
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EXIFS
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ExIPC
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EXOLEDB
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IMAP4Svc
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeActiveSynchNotify
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeADDXA
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeAL
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeDSAccess
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeES
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeFBPublish
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeMGMT
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeMTA
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeMU
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeOMA
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeSA
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeSRS
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeTransport
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWEB
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\POP3Svc
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RESvc
  • IIS eltávolít a gépről
  • Másik gép Exchange System Manager programjából az Exchange szerver töröl
  • AD-ból a gép kiléptet.

Egy szerverrel végeztünk. Jöhetett az utolsó Exchange szerver a Routing Groupban. Add/Remove, eltávolít… ugyanaz a hibaüzenet: “There is no such object on the server”. Eszelős guglizás. Ugyan eltávolíthatnám ugyanúgy, ahogy a másikat, de ez akkor is az utolsó szerver, legalább ezt tisztességesen kellene kirúgni. Aztán szerencsés találat, egy newsgroupban azt írják, hogy látszani ugyan nem látszik a postafiókok között, de minden szervernek van egy postmaster accountja is. A következő objektumon – CN=Configuration,DC=SUBDOMAIN,DC=DOMAIN,DC=COM\CN=Services\CN=Microsoft
Exchange\CN=EXCHANGE\CN=Global Settings\CN=Message Delivery – meg kell keresni az msExchAdminMailbox tulajdonságot. Ennek értéke mondja meg, melyik felhasználóhoz van hozzárendelve a postmaster mailbox. Ha ez megvan, akkor adsieditből megnyitjuk a felhasználó objektumát és meglessük a HomeMDB tulajdonságát. Ha ez a letörlendő szerverre mutat, akkor töröljük. Ha nincs már meg a felhasználó, akkor az msExchAdminMailbox tulajdonságnál adunk meg egy másik felhasználót.
És bejött. Egy már ezer éve nem létező service account userre mutatott az érték. Átírtam… és rögtön más hibaüzenettel állt le az eltávolítás. De ez már ismerős volt korábbról. Anélkül, hogy mélyebben belemennék, a HomeMDB értékekhez kapcsolódik egy backlink, a HomeMDBBL, abból lehet kimazsolázni a sunnyogó postafiókokat, lásd KB279202.
Most már semmi akadálya nincs az eltávolításnak. El is indult a folyamat… majd az Information Store leállítása befagyott. Hosszú várakozás után közölte, hogy oké… pedig ádehogy. Újabb fejvakarás. (Csodálod, hogy kopaszodok?) Átnéztem a szolgáltatásokat… hát ilyen nincs. El volt indítva a Site Replication Service. Natív Exchange 2000 organizációban. Az eszem megáll. Leállítottam előre minden szolgáltatást, beleértve az IIS és Winmgmt szolgáltatásokat is – és innentől már tényleg leesett a gépről az Exchange.

A többi már rutinmunka volt. Egy kicsit megpörgettem az ntdsutil-t (metadata cleanup), hogy eltávolítsam a szabálytalanul leállított DC-t, aztán dcpromo az utolsó DC-re végül egy óriási nagy takarítás az AD konzolokból, DNS-ből, WINS-ből, Exchange konzolokból.
Hajnali egy óra és már végeztünk is.

Második felvonásként rendezkedni kellett a gyökértartományban is. Az erdő szintű FSMO szerepeket birtokló tartományvezérlő… minden volt, csak nem acélos. Amennyit fagyott, attól akár Gorenje gyártmányú is lehetett volna. Olyan trükköt tudott, amilyet én még számítógéptől nem láttam: a szoftveres tükör mindkét lemeze külön-külön is látszott: az egyik C: néven, a másik meg talán V: néven. Nyilván ez így nem maradhatott. A FSMO szerepek szerencsére simán átmentek egy másik DC-re, jött volna a dcpromo. Jött is, aztán udvarias köhintéssel megkérdezte, hogy mit is csináljon a rajta lévő enterprise root CA szerverrel.
– Ez mi? – néztem meglepve a rendszergazdára.
– Nem tudom – vonta meg a vállát.
– CA szervernek tűnik – tippeltem.
– Lehet. Tudtam, hogy valahol van egy.
– Kik használják?
– ? – vonta meg a vállát.
Itt a magam részéről befejeztem a munkát. Mondtam, hogy amíg nem tudják, kik és mire használják ezt a CA szervert, addig én nem bolygatom meg. Meg utána sem szívesen, mert CA téren nem mozgok olyan biztos lábakkal. A takarításnak ezt a részét az insource vállalta be. Lementették a CA adatbázist, dcpromo le, operációs rendszer újratelepítése – a CA miatt szigorúan ugyanolyan néven – dcpromo fel, CA telepítés, adatbázis visszatöltés. Itt futottak bele egy pofonba, mert a régi CA hol a C: meghajtóra hivatkozott, hol a V: meghajtóra – amely ugyebár megszűnt. De a srác becsületére legyen mondva, ügyesen összekötözgette valahogy a szálakat. Végül visszamásztak a FSMO-k is.

Aztán jöttek a tartományvezérlő frissítések. Rendben meg is történtek. A rendszergazda éppen a drivereket telepítette fel a vacakabb, immár w2k3 tartományvezérlőre, amikor az úgy döntött, hogy elég volt neki ebből a világból. Olyan szinten szakadt össze, hogy esély sem volt feltámasztani. A fiúk vettek egy új vasat, és arra már közvetlenül w2k3 oprendszert telepítettek. És ekkor derült csak ki, hogy a CA adatbázis ugyan átkonvertálódott w2k3-ra, de az a géppel együtt elszállt. A mentésben lévő w2k formátumú CA adatbázistból meg nem lehet visszaállítani w2k3 CA alá semmit. Mivel közben a tartomány is natív lett, így elég bonyolult forgatókönyvek adódtak a visszaállításra. Olyannyira bonyolultak, hogy az IT vezető úgy döntött, inkább telepítsünk egy új CA szervert. Némileg kellemetlen, hogy még mindig nem lehet tudni, kik és mire használták a régit..
Na, mindegy, a tartomány legalább szépen működött.

Boldog új évet!

Valamelyik népművelő csatornán láttam régebben egy filmet a német tengerészet csúcs hadihajójáról – és arról, hogyan sikerült elsüllyeszteni. Ez jutott eszembe, ahogy a tegnapi éjszaka során folyamatosan süllyedtem én is a letargiába.
A hadihajó a világ egyik legerősebb hajója volt. Tulajdonképpen sebezhetetlennek készült, egy apró hibával. Ha megfelelő szögből belőttek az egyik tatbudi 10 centis ablakán, akkor eltalálhattak valami robbanásveszélyes berendezést, melytől levegőbe röpülhetett a tatfedélzet.
Az egészről film volt. Látszott a viszonylag kicsike angol hajó és a bazi nagy német hadihajó, ahogy szép kényelmesen fordul oldalra, hogy lesorozza a felszínről az angol jószágot. Aztán egyszercsak valamelyik angol belepukkantott egyet a nagyvilágba – és mit ád Isten, a lövedék pont bement a budiablakon, a hajó meg fordulás közben épp a kritikus szögben volt. A következő pillanatban felrobbant a német hajó segge és szép lassan befordult az egész a tengerbe.

Képzeld el, hogy van egy címtárad, meg egy Exchange szervered. Az ügyfelünknek is volt. Aztán január másodikán hajnali négykor a vacak, kifejezetten csak tartalékcélokra szolgáló PIII WS kategóriájú DC2 merevlemeze diszkrét pukkanással elhalt. Dugovics Tituszként magával rántott egy computer objektumot is a címtárból.
Ez még nem olyan nagy tragédia: a DC-t ki kell irtani, újat kell rakni helyette, a computer accountot meg resetelni kell. Mint ahogy Cary W. Shulz – Active Directory MVP – is írja:

There are user account objects just like there are computer account objects. The computer account objects have a secure channel with a Domain Controller. Over this secure channel the workstation and the Domain Controller communicate. In WIN2000 the computer account objects change their secret password every 30 days ( in WINNT 4.0 it was seven days ). Sometimes this secure channel gets flubbed up…for whatever reason. So, based on what I just wrote you can see how this can create a little bit of a problem. So, in order to resolve the problem of the flubbed up secure channel you Microsoft gives us the ability to reset that secure channel.

Illetve később Bizonyos Steve hozzáteszi:

In that scenario I would reset the Computer account first before trying the remove/add to domain. This works for me 99% of the time, the 1% usually require the remove/add method.

Csakhogy… gondolj bele, mi történik akkor, ha a flubbed account pont egy Exchange Server computer accountja – és bejön az 1%, azaz az account reset sem segít.

Hagyok időt végiggondolni.

A fent említett remove/add módszer értelemszerűen nem működik. Pontosabban meg lehet csinálni, de onnantól az Information Store az életben sem fog elindulni.

Az esetet a kollégám kapta tüdőre. Reggeltől estig a tartományt foltozgatta: vacak DC eltávolítása, tartományi replikáció beindítása, kismillió anomália megszűntetése, új DC üzembeállítása, makacs account resetelgetés… nem segített. Este héttől váltottunk, mint a pankrátorok: arénából ki, arénába be, high five.
Mit láttam?

  • Az Exchange szerveren a szolgáltatások leállítva, mert minek fussanak.
  • Az Exchange szerveren a tartományba belépni nem lehet: azt mondja, nincs olyan account.
  • A netdom join azt mondja, hogy már van ilyen account.
  • Amikor elrontom szándékosan a jelszavamat, akkor azt írja, hogy rossz a jelszó. Azaz a DC – és az AD – elérés tökéletes.
  • Amikor kitiltom a computer accountot, akkor azt írja, hogy ki van tiltva. Az AD acélos.
  • Próbaképp egy munkaállomás beléptetése: tökéletes.
  • Az eventlog alapján az account “Access Denied”.
  • Ha everyone full control-t állítok rajta, akkor is.

Brainstorming.

  1. Vegyük ki a tartományból majd tegyük vissza. Hevesen tiltakoztam. (Lásd korábban.)
  2. Promotáljuk DC-vé, majd az account reset után demotáljuk vissza sima szerverré. Újabb heves tiltakozás. (A dcpromo és az Exchange nem férnek meg egy csárdában. Ha ráküldjük egy Exchange szerverre, akkor tönkrevágja az IIS-t meg az asp.net-et, újra kell húzni mindkettőt. És utána belassul, meg össze-vissza működik. De a fekete leves a következő lépés: demotáláskor az IIS és az AD megszűnik egymással kommunikálni. Nem csak a kérdéses szerveren, hanem az egész organizációban. Nem kicsit durva.
  3. Gondolkozzunk. Mi mehetett tönkre? Az AD szépen működik. Az Exchange számítógéphez nem nyúlt senki, az adatbázisok tutira jók. A network, névfeloldások tökéletesek. Ha valami itt elromlott, az csak a computer objektum lehet.
    Hmm… állítsuk vissza. Elméletileg létezik korlátozott hatósugarú autoritatív restore.
  4. Megpróbálkozhatunk egy éles Exchange disaster recovery-vel is. Persze, tudjuk, hogy az Exchange tökéletes, de ha eljátszanánk, hogy ugyanazzal a névvel átraknánk az Exchange szervert egy másik gépre, talán ki tudnánk erőszakolni egy account reset-et.
  5. Persze nem kizárt, hogy az az elkefélt computer account ellenáll ennek az invitálásnak is. Akkor nincs más hátra, csinálunk egy új Exchange szervert más névvel, átmásoljuk rá az adatbázisokat, a felhasználóknál – szerencsére nincs sok – töröljük az Exchange tulajdonságokat, majd létrehozunk mindegyiknek egy új postafiókot, MAPI profilt, a régi Exchange szervert kiradírozzuk, végül egy offline adatbázismatyizóval kiszedjük pst-kbe a régi leveleket és visszalapátoljuk a felhasználók postafiókjába. Elég gusztustalan, de B tervnek megteszi.

Az utolsó három igéretesnek tűnik. Tudjuk, csak a kombinált bérlet a biztos. Ilyen sorrendben pont jó is lesz nekiindulni az éjszakának.
3. pont. Ahhoz bizony kell egy system state mentés is.
– Van? – kérdezem a helyi rendszergazdát.
– Persze – vágja rá.
Aztán nem sokkal később jön a helyesbítő telefon.
– Volt – közli – Azon a merevlemezen tartottuk, amelyik elpukkant.
Feltúrjuk a gépeket, az egyiken végül beleakadtunk egy két évvel ezelőtti systemdrive+systemstate mentésbe. Volt már akkor ez az Exchange szerver? Éppenhogy: 3 hónappal előtte lett telepítve. Nagyon necces. Nézzük csak, hogyan működik Windows 2000 szerveren az autoritatív restore? Aszongya, belépünk Directory Restore módban, visszatöltünk egy komplett systemdrive+systemstate mentést(!), majd ntdsutil-lal kijelöljük, melyik OU-t akarjuk megtartani, utána újraindítjuk a gépet, mely magára rántja az AD-t. Hát… ennek csak egy veszélye van, az, hogy működik. Gondoljunk bele, visszarántunk egy két évvel ezelőtti állapotot. Lehet, hogy akkor még nem is maguktól tekertek a bitek az alaplapon, hanem kis zöld emberkék hurcolászták őket. Aztán a systemstate… az nem csak az AD-t jelenti, hanem rengeteg operációs rendszer szintű adatbázist is. Azzal, hogy visszarántom az AD-t, az összes többi pókhálós cucc ottmarad. Esetleg azt tudom megcsinálni, hogy mielőtt belevágok, csinálok egy másik systemdrive+systemstate mentést, az első autoritatív restore után visszaröffentem a computer account-ot, ezzel megnövelem az UID-jét, majd csinálok egy non-autoritatív restore-t, melyet teljesen felül fog vágni a jó AD és visszakerülnek a rendszerkomponensek is a helyükre.
Ezzel csak két baj van.

  • Egyfelől egyáltalán nem biztos, hogy a két évvel korábbi állapotú DC be fog tudni lépni a tartományba. Meg ugyan nem esküdnék rá, de úgy rémlik, van valami korlát, ameddig felhasználható a mentés.
  • Elég rizikós egy pici tartomány hegesztésekor egy baromi nagy AD-t belengetni, felvállalni az inkonzisztencia kockázatát.
  • Végül azt írja a manuál, hogy egy ilyen restore során egy csomó AD elem by design tönkremegy. Látható is a blue-frame jellegű elvből, hogy mindent visszarak, még akkor is, ha nem kellene, és abba vág majd egy maszkot. Azaz optimáis esetben visszaáll a computer account, de elszállnak a backlist értékek, az FRS replikáció, a RID pool… meg ilyenek.

Jé, ez három…
Ettől függetlenül ezt az utat túl kockázatosnak ítéltem. Ha a DC 2003-as lenne, a mentés pedig 30 napon belüli, akkor esetleg, de így… inkább nem.

Ennyit az egyenes útról. Nézzük a görbéket.

A korábbi disaster recovery cikk sem rossz, de az igazi recept Petrinél található. Mielőtt bármit is csináltunk volna, a helyi rendszergazda a régi Exchange szerver adatbázisait elmentette félre egy másik hardveren, felhúzott egy nagyjából ugyanolyan operációs rendszerű gépet (oprendszer, SP, patch, Windows komponensek – különösen az utóbbi a fontos). Ezután lehúzta a netről a régi szervert, az újnak átírta az IP címét, én a a nevét, közben reseteltem a computer accountot, majd beléptettem az új szervert a tartományba. Áttörtünk. (Mondjuk elsőre elhűlt bennem a vér, mert egy lépésen belül próbáltam átnevezni is meg beléptetni is a gépet, de az éber – akkor már durván 30 órája ébren lévő – helyi rendszergazda szerencsére figyelt… és a második kisérlet már sikerült.)
Innen már simán ment minden, úgy, ahogy Petri bácsi leírta. A végén extra bónuszként az is összejött, hogy egyszerűen visszamásoltam a korábbi adatfájlokat és az IS szó nélkül felmountolta.

Délután fél egy.
Nem sokkal szilveszter után. Mondanom sem kell, hogy a kollégám is, meg én is szabadságon vagyunk.

De így jár, aki az informatikusok bohó szakmáját választja.

ps.
Éppen befejeztem a jegyzőkönyvet – addig kell írni, amíg emlékszem, mi is történt pontosan – amikor csörgött a telefon. A Service Desk szólt, hogy jött egy bejelentés, miszerint megint nem megy a levelezés az ügyfélnél. Sóhaj, enyhe káromkodás, irány vissza. Átnézni a konnektorokat egytől-egyig, tesztlevelek innen-oda, meg vissza… minden működik. Még be sem fejeztem, amikor újból csörgött a telefon. A felhasználó pontosított, azt szerette volna mondani, hogy reggel nem ment a levelezés.
Délután fél öt van.
Köszönjük, az Ön hívása fontos nekünk.

Bevezetés

A novemberi Technet Magazinban jelent meg egy cikk arról, hogyan állt át egy cég Microsoft infrastruktúrára. Örült a lelkem, amikor olvastam, hiszen jó látni, hogy vannak helyek, ahol ez flottul megy. Nekem valahogy mindig a csatornákban mászkálás marad.
Gondolkodtam is, hogy megírjam-e az egészet ennyire részletesen, de aztán győzött a grafomániám. Nekem is jó, ha egyben látom, mi mindent csináltam/csináltunk rosszul, na meg másoknak is segíthet.
Ami még kérdéses volt, hogy hová írjam? Ide mély szakmai írásokat már nem szántam – de ebben a szakmai tartalom mellett lesz rendesen hőbörgés is, azt meg a katedráról talán mégsem kellene. Szóval maradt az egész a kocsma jellegű blogban.

A feladat látszólag egyszerű volt: rendbe kell tenni az ügyfél címtárát, Exchange organizációját, úgy, hogy menetközben upgradeljük a tartományt és a végén átállunk Exchange 2007-re. Gondolom, érezhető, hogy a ‘látszólag’ szó az iróniát hivatott képviselni az előző mondatban.
A helyzetet bonyolította, hogy az ügyfélnek vannak insource informatikusai is, azaz nemcsak mi, mint outsourcing cég kezelgetjük az IT rendszerüket. Hogy fokozzam a helyzetet, eddig alig fértünk hozzá a rendszerükhöz, a helyi rendszergazda sokáig elkövetett mindent, hogy ne kapjunk komolyabb jogosultságot. Embereink maximum egyszerűbb feladatokat láttak el, jórészt felhasználóadminisztrációt. A rendszerről meglehetősen homályos képünk volt. Meg is lepődtünk, hogy ezt a munkát végül mi nyertük el, nem az insource.
Maradjunk egy kicsit még a kiindulási feltételeknél. A meglévő rendszer a következőképpen nézett ki:

  • Windows2000 erdő, natív windows2000 tartományok. Egy gyökértartomány, két gyerektartomány. A projekt része az egyik gyerektartomány megszűntetése, az erőforrások átmigrálása a gyökértartományba.
  • Exchange 2000 szerverek, különösebb cifrázások – cluster, nlbs – nélkül. Minden tartomány mindegyik telephelyén van legalább egy szerver.

Tervezés… minimális. Az ügyfélnek nagyon sürgős. Az egész projektre tokkal-vonóval adott 3 hetet. Habár jeleztem, hogy igazából ez a rendszer megismerésére sem elég, de akkora nagy volt a különbség az ügyfél időbecslése és az enyém között, hogy nem is láttam értelmét a vitának. Csináljuk, aztán majd kialakul. Néha megpróbáltam tervezgetni, de annyira nem volt rá idő, hogy végül belementem egy kompromisszumos munkamódszerbe: a koncepció nálam megvan fejben, hetente összeülünk, én elmondom, mi várható a következő egy hetes etapban, felvázolom a döntési lehetőségeket, ha kell rajzolgatok is a táblára, aztán döntünk, ütemezünk. Végül a helyi IT vezető gyárt egy meeting minutes doksit, melyet egy hét múlva átnézünk, utána pedig megtervezzük a következő hetet.
Eddig sem hangzott túl jól, de aztán kiderült, hogy igazából a helyi rendszergazda sem ismeri részleteiben a saját rendszerét. Többször futottunk bele olyasmibe, hogy ‘ja, tényleg, emlékszem, mintha XY valamikor ezt meg azt telepített volna’ – mindez olyankor, amikor éppen valami nem várt falba ütköztünk. Dokumentáció nem volt semmiről sem. Életem első éles Exchange2007 bevezetése volt. Elég vadul hangzik. Ha tisztességesen akartam volna csinálni, akkor azt mondom, hogy egy-két hét rendszerfelmérés, két-három hét tesztlabor, lemodellezés, jegyzőkönyv, aztán az alapján egy hét tervezés. Ez durván a duplája volt az ügyfél által a _teljes_ projektre szánt időnek.

Nos, így. Ennyi volt a bevezetés. Legközelebb már szakmai dolgok jönnek.