Category: 2007

Nem divat a frissítés

Elgondolkodtató…

…in late November there were 30,635 machines on the public web with an unsupported version of Microsoft Exchange:

  • 275 instances of Exchange Server 2007
  • 4,062 instances of Exchange Server 2010
  • 26,298 instances of Exchange Server 2013

 

Visszanyomás

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

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

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

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

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

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

Tanulság?

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

Exchange patch és egyebek

Nemrég megkérdezték tőlem, miért paráznak az Exchange adminok a hotfixek telepítésétől. Megemlítettem, hogy két olyan esetről is tudok, amikor egy-egy rollup pack hazavágta a rendszert, és a kardjukba dőlt adminokat nem igazán vigasztalta, hogy az MS később visszavonta a csomagokat.

Nos, itt egy újabb csapda. Azt írják az Exchange blogon, hogy habár a Windows Update / WSUS / SCCM mind lelkendezve ajánlja ki az opcionális frissítések között a Windows Management Framework 3.0-t – igen, benne a csábos Powershell 3.0-val – az Exchange 2007/2010-et futtató gépekre inkább ne telepítsük. Ha mégis feltennénk, számíthatunk arra, hogy a rollup packok nem települnek fel, illetve az EMS begolyózik. Szóval óvatosan.

targetAddress avagy spóroljunk a licenszeken

Most következik az az eset, amikor bebizonyítom, hogy nem értek az Exchange-hez.

Mit csinálunk olyankor, amikor van egy email címünk, amiért a saját Exchange szervezetünk a felelős, de az ide érkező leveleket tovább kell küldenünk egy külső címre, és saját rendszerünkön soha egy darab levelet sem kell tárolnunk, ami a megadott címre érkezik?

Én (és az a gyanúm, hogy ezzel nem vagyok egyedül) a következőt tettem a fenti esetben. Létrehoztam a saját címünkhöz egy postaládát, a külső címhez egy kontaktot és a postaládát ráirányítottam a kontaktra. Megbékéltem azzal, hogy ez ronda, sőt minden egyes ilyen akció visz magával egy nem is túl olcsó CAL-t.

Mostanában a több ügyfélnél az Exchange 2003 – Exchange 2010 Cross-Forest migrációval birkózom (ez egyszer még megér egy másik cikket). Ennek kapcsán meglepetten tapasztaltam, hogy a migráció végén a rendszer egy olyan Mail Enabled User-t (ez ugye Exchange szempontból egy kontakt, és mint ilyen nincs postaládája) hagy maga után. Ami viszont képes leveleket továbbítani pontosan úgy, ahogy a fenti kérdésben szerepel.

Némi nyomozás után kiderült, hogy a tettes a targetAddress nevű AD property. Tehát minden levél, ami a kontakt egyik proxyaddress-ére érkezik azt a rendszer tovább küldi a targetAddress property-ben szereplő címre. Ráadásul a rendszer azt a kedvességet is megteszi (mind Exchange 2003 mind 2010 esetén), hogy a targetAddress property-t eleve kitölti a kontakt email címére.

Ebből adódóan az eredeti kérdésre adott válasz így változik:

Felveszünk egy kontaktot a külső címmel, majd a kontakt proxyAddresses listájába felvesszük az átirányítani kívánt saját címet.

Kész vagyunk. Mínusz egy CAL.

AntiSpam Update

Van egy dolog, ami már jó ideje bosszant.

Az Exchange 2007/2010 lehetőséget biztosít arra, hogy a Hub Transport szerveren feltelepísük a Microsoft AntiSpam agent-jeit. Ezzel kapunk egy jól működő, nagy tudású spam szűrő infrastruktúrát.

Ez ugyan nem annyira hatékony, mint a ForeFront for Exchange, továbbá nincs benne vírusirtó, viszont ingyen van.

Amikor ez a lehetőség először megjelent az Exchange 2007-ben, akkor lehetőségünk volt arra, hogy a hozzá tartozó definíciós fájlokat automatikusan frissítsük (Ez a ForeFront nélkül 3 hetente történt). Ez a lehetőség egy adott ponton megszűnt. Pontosabban, ha nincs ForeFrontunk akkor az Exchange maga nem frissít, hanem ezt a Windows Update teszi meg helyette.

Ezzel viszont gond van. Én magam részéről szerveren sosem kapcsolom be a frissítések automatikus telepítését (csak az automatikus letöltést), mert a folyamatos üzem miatt az nem elfogadható, hogy a szerver újrainduljon, amikor az update-nek ehhez van kedve, ráadásul bizonyos környezetekben a biztonsági frissítések csak tesztelés után kerülhetnek az éles rendszerbe. Ebből adódóan nem csak a biztonsági frissítések, hanem az AntiSpam definició sem települ automatikusan, aminek pedig kellene.

A fenti állapotot kezelendő írtam egy kis javascriptet ami feltelepíti az AntiSpam definíciós fájlt. És csak azt. Ha ezt a kis scriptet (cscript.exe SpamUpdate.js) berakjuk a Task Scheduler-be akkor a fenti problémát megoldottuk.

A script innen tölthető le.

Export-mailbox, szomorodj meg

Hajnalban megállt az export. Azt mondta, hogy

Export-Mailbox : Error was found for XY (xy@cegnev.hu) because: Error occurred in the step: Approving object. An unknown error has occurred., error code: -2147221219 At line:1 char:2312
+ CategoryInfo: InvalidOperation: (179:Int32) [Export-Mailbox], RecipientTaskException
+ FullyQualifiedErrorId : 7D782610,Microsoft.Exchange.Management.RecipientTasks.ExportMailbox

Próbáltam utánajárni, mi is lehet ez. Volt a neten minden, zárjam be az Outlookot (ki sem volt nyitva), állítsak be valós default gateway-t (be volt), vagy futtassak le egy fixmapi nevű programot. Pusztán kíváncsiságból ráküldtem ismét, minden módosítás nélkül ugyanazt a parancsot, amelyen elhasalt. (Természetesen az exportálandó postafiókok közül kivettem a már készeket.) Simán vette az akadályt, most is az fut.

Megvan, mi lehetett a probléma: alvás közben nem imádkoztam elég intenzíven. Aztán eddig tartott a deikus töltet.

Ideges? Á, egyáltalán nem vagyok az. De reggel simán bevettem a savcsökkentő (kék) gyógyszerem helyett az éjszakai (fehér) koleszterincsökkentőt.

Halott ember visszalő

Ezt írtam korábban:

Itt már lejjebb adjuk az igényeket, eszébe se jusson windowsupdate-tel foglalkozni.

Naív dolog volt azt hinni, hogy a windowsupdate ennyiben fogja hagyni. A nagy kapkodásban a kolléga ugyanis automatikus beállításon hagyta, én meg elfelejtettem leellenőrizni – őszintén szólva, egyikünknek sem jutott eszébe, hogy egyáltalán létezik – az a dög pedig, mármint a windowsupdate, hajnalban restartolta a gépet, teljeskörűen ignorálva azt, hogy milyen fontos processz fut rajta.
Kora reggel, még félig kinyílt szemmel néztem rá a monitorra és elhűlve láttam, hogy nem látok semmit. Megszakadt a session. Meg a jókedvem. A kiadott utasítás ugyanis úgy nézett ki, hogy a get-mailbox parancs kimenetele volt belecsövezve az export-mailbox parancsba. Csakhogy a get-mailbox a jó ég tudja, milyen alapon rendezi sorrendbe a postafiókokat, de hogy nem ABC sorrendben, az biztos. Kénytelen voltam lehúzni egy listát, kimazsolázni, hogy kinek készült már el a pst-je, a többiek nevét pedig úgy összerakni egy szövegszerkesztőben, hogy be lehessen tolni az export-mailbox parancsba. Mindezt kora reggel, még kávé előtt.
Oké, elkészült, parancs átmásol a PSH ablakba, enter – váratlan PS hiba. Ó, hogy szomorodj meg! De most legalább már tudtam a megoldást. Szerver, kliens újraindít. (Közben gyors kávé.) Beléptem a kliensre, parancs átmásol a PSH ablakba, enter – és ismét váratlan PS hiba. De most tényleg váratlan, mert még én sem számítottam rá. Egyből le is konyult az orrom. Ez most már minőségileg más helyzet, innen hogyan tovább? Aztán eszembe jutott egy fontos momentum: újraindítás közben elfelejtettem imádkozni. Tehát újraindítottam a klienst és a szervert _még egyszer_, közben barbár imákat mormoltam és a biztonság kedvéért elővettem a legcsúnyább nézésemet is. És most már elindult a szkript. Hogy az informatika egzakt tudomány? Persze, királyfi.

Egyébként tényleg hihetetlen ez az egész és nevezhetném groteszk balszerencse-sorozatnak is, de vegyük észre, hogy van azért mögötte nem átgondolt, kapkodós gányolás is. Ha még emlékszünk, az Exchange 2007 trágya, félkész állapotban jött ki a piacra, és a nagyon várt, de időhiány miatt kimaradt funkciókat utólag hegesztgették bele, service és rollup pack-ek segítségével. Ilyen utólag beleműtött dolog volt az export-mailbox kibővítése a pst fájlok kezelésével. Ezen különösen látszik az utólagos toldozgatás, hiszen egy alapvetően szerveroldalon optimális folyamatot raktak ki a kilens oldalra, azért, mert ott már volt pst-t kezelni tudó MAPI motor, az Outlook. Igaz, emiatt a teljes adatbázismennyiséget át kell tolni kétszer a hálózaton, a feldolgozást egy erőforrásait tekintve sokkal-sokkal gyengébb gépen kell futtatni (Exchange 2007 esetén 32 bites kliensen), és akkor még nem is beszéltünk a kliensgépek speciális nyűgeiről, mint például a tipikusan automatikusra állított windowsupdate szolgáltatás, vagy éppen a rafinált csoportházirendek.

Na, mindegy, újabb fél nap csúszás, azaz most már egy teljes nap.

Powerhell

Nevezhetjük szerencsének, de eddig még sikerült megúsznom a postafiókok nagy tömegben történő exportálását pst fájlokba. Eddig. Háát…

A környezet ránézésre nem túl veszélyes. 230 postafiók, 160 GB adatmennyiség. A szerver jól méretezett. A kliens, amelyikről a másolást végezni kell – a lehetőségekhez képest – szintén.
Ezen azért rugózzunk egy kicsit, mert később fontos lesz. Exchange 2007, az export-mailbox követelménye 32 bites(!) Outlook 2007, szigorúan 32 bites(!) Windows 7-en. Erre kell még egy 32 bites Exchange 2007 admin csomag.
Még a tesztfázisban összeraktam egy virtuális kliensgépet, hogy ismerkedjek a folyamat dinamikájával. Másra nem is volt jó, mert diszk, az nem volt mögötte, de sikerült bejátszani a parancsot, eljátszottam a nyelvi beállításokkal, szóval felkészültem.
A migrációra a helyi emberünkkel közösen összeraktunk egy kliensgépet. Az éles indulás előtt ezen is teszteltem egy kicsit, minden működött, mint egy svájci óra.
Eldördült a startpisztoly, levélforgalom leállít, a kliensen parancs kiad, elégedetten hátradől. Kábé 10 percig. Ekkor kezdett el sikítozni a Windows, hogy eldobta az agyát. Konkrétan elfogyott a memóriája. Ezzel párhuzamosan a másolás is beállt, mint a gerely. Kilőttem a taszkot. Fejvakarás. Nem túl sokáig, mert a helyzet hamarosan világossá vált. A Windows ugye 32 bites, ebben a maximum RAM 4 GB lehet. Volt még a pagefile, a kettő együtt 10 GB. Az export-mailbox egyszerre 4 szálat indít és balszerencsémre rögtön az első csoportban benne volt a titkárság postafiókja, nem is mondom, mekkora mérettel. Lúzer hiba volt. Felnyomtam a virtuális memóriát 40 GB-re, restart, aztán elkezdtem újra.
Nem indult el. A powershell fél perc szutykolódás után váratlan hibát dobott, a legsemmitmondóbb 1000-es hibaüzenettel. Újraindítás már volt, tehát ebben sem reménykedhettem. Mi romolhatott el? Persze, játszottam még a parancs maxthreads paraméterével, de el se jutott odáig a folyamat, a powershell sorra dobta a váratlan hibákat. Pedig addigra már megszokhatta volna.
A leginkább logikus gondolat az volt, hogy amikor erőszakosan kilőttem a powershell processzt, akkor megsérülhetett valami alkotóeleme és azóta a PS nem tér magához. Telepítsük újra! Ahogy azt Móricka elképzeli. Mivel Windows 7 esetében már beépítve jön a PS 2.0, így nem lehet külön letölteni. Feature-ként sem lehet eltávolítani, majd visszarakni. Ekkor szóltam a kollégának, hogy B terv, kezdjen el telepíteni egy másik munkaállomást. Itt már lejjebb adjuk az igényeket, eszébe se jusson windowsupdate-tel foglalkozni. Én pedig előre menekültem. Rakjunk fel WMF3 CTP2 csomagot, abban van Powershell 3. Aztán majd meglátjuk, mit csinál. Semmit. Fel sem települt. Azt mondta, hogy neki szigorúan angol nyelv kell, ez meg nem az. De meg lehet engesztelni egy angol language pack-kel. Töltsük le! Hát, nem. Nyelvi csomag eleve a Windows Update-ről szedhető le, ultimate és enterprise Windows 7 esetén. Csakhogy mi itt professional verzióval szopunk. Elvileg leszedhető az MSDN-ről a teljes csomag, de mire a 2 GB lejön, addigra a kolléga újrahúzza a gépet. És még ekkor sem garantálja senki, hogy nyelvet tudok váltani, hiszen a professional eleve nem lehet többnyelvű.
Csapásváltás. Menjünk vissza a legutóbbi rendszermentéshez, töltsük vissza, aztán telepítsünk mindent újra attól a ponttól. Röpke félóra alatt meg is csináltam, restart, újabb próba, újabb váratlan PS elszállás.
Hát, ezzel nem jutottam sokat előre.
Közben kolléga felhúzta az új gépet, gyorsan kipreparáltam, maxthreads a biztonság kedvéért kettőre állítva, aztán hajrá. Nem hiszed el: ezen is váratlan Powershell hiba történt. Meg lehetett volna mintázni rólam a bambaság szobrát.

Vicc.

– Doktor úr, nagy baj van!
– Mi a panasza?
– Ha megnyomom a lábam, fáj! Ha megnyomom a derekam, fáj! Ha megnyomom a tarkóm, fáj! Milyen betegség az ilyen?
– Valószínűleg eltörött az ujja.

Azaz ha több kliensen is ugyanazzal a hibával száll el egy folyamat, akkor lehet, hogy a szerver a hibás. Mágikus restart. A biztonság kedvéért a kliensen is. Másolás elindít, összes végtaggal imádkozik. És igen, ez volt a probléma, a Powershell váratlanul jól működik.

Vegyük észre az eset szépségét. A 32 bites kliensen elindított, 32 bites Exchange modullal feljavított Powershell (aka EMS) menetközben meghívogatja a 32 bites Outlook MAPI motorját, ezen keresztül próbálja meg leszívni a szerverről a levelezési tartalmakat és kirakni pst fájlokba. Aztán elfogy a RAM, ki kell lőni a taszkot, és mi hal meg tőle? A szerver. Finom.

Mindegy, elméletileg örülhetnénk is… csakhogy itt a háromnapos ünnepre terveztünk egy háromnapos átállást. Ebből elveszett a péntek délután, az export legjobb esetben is csak szombat délre fejeződik be és igencsak csipkedhetjük magunkat, hogy ezt a fél napot behozzuk valahogy.

Én mindenesetre halk sóhajjal betoltam az Alvin albumot az mp3 lejátszóba.

Ott szorít, ahol szűkebb

Egy nagyon jó nyomozás leírása Paul-tól. Érdemes végigolvasni, megnézni, hogyan gondolkodott, milyen eszközöket használt és hogyan göngyölítette fel az esetet. Majd hasonlítsuk össze, hogyan oldottam meg anno én egy ránézésre teljesen különböző, de valójában ugyanarra a konfigurációs hibára visszavezethető problémát, pusztán a józan eszem és a Salvador Dali-féle paranoiac-critical módszer segítségével.

Exchange javítások

Két új hotfix jelent meg.

Az egyik az Exchange 2010 SP1 soron következő immár 6-os rollupja. Letölthető innen, további infók róla itt.

A másik egy igen bosszantó, ugyanakkor nem életbevágóan fontos hibát hivatott orvosolni. Ha az Exchange Management Console-t futtató gépen fenn van az IE9 és a Mailbox szerepkör tualjdonságait piszkáljuk akkor nem lehet becsukni a konzolt. Ezt az üzenetet kapjuk és csak a Task Managerből lehet kilőni az MMC-t: “You must close all dialog boxes before you can close Exchange Manaagement Console.”

Bővebben itt.

Mondd meg a Ferinek, hogy szóljon a Janinak

Ügyfél haladt a korral. A saját alkalmazásai korábban MAPI-n keresztül érték el az alkalmazásokhoz tartozó Exchange postafiókokat. A felhasználók autentikálták magukat az alkalmazások indulása után, aztán vagy volt joguk az egyes funkciók postafiókjaihoz, vagy sem – attól függően, milyen jogosultságok voltak beállítva közvetlenül a postafiókon.

Mint írtam, haladtak a korral. Az alkalmazások új verziójában úgy döntöttek, hogy szakítanak a MAPI-val, helyette inkább webes protokollokon keresztül érik el a postafiókokat.
Első ránézésre nincs is nagy gond, megkapták a mailbox szerver helyett a CAS szerver nevét, aztán hajrá.
Nem sikerült. Még az atyaúristen jogosultsággal bíró fejlesztők sem tudtak kapcsolódni egy postafiókhoz sem. Azt a választ kapták, hogy nincsenek megszemélyesítve.

Hmm? Ez meg mi?

A CAS szerver önérzete. Ugyanis most nem közvetlenül fordulunk a mailbox szerverhez, hanem egy CAS (azaz web) szerveren futó webes szolgáltatáson (EWS) keresztül. Márpedig ahhoz, hogy ez az egész működjön, az kell, hogy a webes szolgáltatás megszemélyesítse a hozzáforduló személyt a mailbox szerveren. (Megjegyzem, a Free/Busy információk webes lekérdezése is hasonlóképpen működik.)

A megszemélyesítésben két jogosultság is keresztbetehet:

  • ms-Exch-EPI-Impersonation: Ez egy, a CAS szerverekre vonatkozó jogosultság. Azt lehet vele szabályozni, hogy a kérelmező egyáltalán bekerülhessen a megszemélyesítés bizniszbe. Ha ez a jogosultság tiltott, akkor az illetőt már a CAS szerver elhajtja.
  • ms-Exch-EPI-May-Impersonate: Ez a jogosultság a mailbox szerveren értelmezendő. Szintjei nincsenek (azt továbbra is a postafiókon szabályozzuk), itt csak az dől el, hogy a kérelmezőt megszemélyesítő webes szolgáltatás hozzáfér-e valaki nevében a postafiókhoz, vagy sem.

Mondanom sem kell, ebből az egészből semmi nem volt beállítva. Nyilván el lettek hajtva az alkalmazásokon keresztül érkezők.

Szerencsére a megoldás technikailag nem volt túl bonyolult. Kérni kellett egy listát arról, hogy milyen postafiókokhoz milyen felhasználóknak kell hozzáférniük. Mindegyik postafiókhoz készült egy biztonsági csoport, benne a megadott felhasználókkal, illetve az összes biztonsági csoportot betettem egy CAS-Impersonate biztonsági csoportba.

Első lépésben a CAS-Impersonate csoportnak megadtam a CAS szerveren a megszemélyesítési jogot.

Add-ADPermission -Identity <CAS_server_name> -User <CAS-Impersonate> -extendedRight ms-Exch-EPI-Impersonation

A következő lépésben postafiókonként (PFname) lefutattam a következő parancsot:

Add-ADPermission -Identity <PFname> -User <PfGroup> -extendedRight ms-Exch-EPI-May-Impersonate

Ugye, milyen egyszerű?

Hát, nem.

Az ördög megint a részletekben vigyorog. Az Add-ADPermission ugyanis roppant kényes ízlésű jószág, semmilyen más azonosító paramétert nem fogad el, csak az objektum distinguished name értékét. Mindenhol. Az első parancs sikeres végrehajtásához le kell vadásznod (adsiedit) mind a CAS szerver dn értékét, mind a CAS-Impersonate csoport dn értékét. A második parancs még durvább. Így, ahogy fentebb látod, nem is működik.

Add-ADPermission -Identity <Username> -User <PfGroup> -extendedRight ms-Exch-EPI-May-Impersonate

Ahol az <Username> egy konkrét felhasználói objektum dn értéke, a <PfGroup> pedig az általam a postafiókhoz kreált csoport dn értéke. Ebben az esetben a csoport pontosan azt a szintű jogosultságot kapja meg a postafiókra a megszemélyesítésen keresztül, mely az <Username> felhasználónak is van.

Az eljárásról van cikk, itt találod.

Apu, hod med be

Jó téma, napokig lehetne cikkezni róla. Konkrétan arról van szó, hogyan nyúl bele a tűzfal a legegyszerűbb adatáramlásokba is. Melyekről persze kiderül, hogy nem is olyan egyszerűek.

Az első sztorink egy világméretű hálózaton történt. Két Exchange organizáció között kellett Free/Busy szinkront összelőni. A túloldal Amerikában volt, jó nagy időeltolódással. A kommunikáció enélkül is igen nehézkesen ment, ilyen környezetben nem egyszerű összehozni egy élő kapcsolatot, hogy mind a két oldalon ott üljön a megfelelő mérnök és szinkronban taperolják a billentyűzetet.

Előtte határozottan felhívtam a tűzfalas kollégák figyelmét, hogy a két host között any-any kapcsolatot kérek az oldalunkon. Belső hálózatról van szó, épp elég lesz az F/B szinkronnal játszanunk, első körben nem szeretnénk, ha a tűzfal bekavarna. (Utána lehet majd szigorítani.) Megigérték, beállították.

Eljött az idő. Próbálkoztunk. Nem működött. Kiderült, hogy a túloldali tűzfalon mindösszesen néhány portot engedélyeztek, csak éppen ezt a portlistát elfelejtették közölni. Mi viszont az Exchange megfelelő szolgáltatását nem korlátoztuk konkrét portokra. Némi gondot jelentett, hogy az általuk engedélyezett portokat nálunk már más Exchange szolgáltatások használták. Hasraütve kiválasztottunk néhányat a környékről (6xxx), a túloldalon engedélyezték a tűzfalon, nálunk ugye nem kellett.
Továbbra sem működött a szinkronizáció. Izzadtunk még egy sort, majd kölcsönös és sűrű sorry-k mellett befejeztük a közös munkát. Majd legközelebb.

Másnap a biztonság kedvéért rákérdeztem a helyi biztonsági erőknél, hogy tényleg any-any lett-e beállítva? Mellékeltem a konkrét portszámot is. Erre kaptam egy olyan választ, hogy jojózott a szemem. Ugyanis a véletlenszerű porttal pont beletaláltam egy általam még csak soha nem is hallott protokoll tartományába, melyet a konkrét tűzfalon nem engednek át direktben, hanem proxyznak. Innentől jókedvű anyázásba fordult a levelezés, én próbáltam elmagyarázni, hogy az any-any azt jelenti, hogy a két host között minden kommunikáció transzparens, ők viszont ragaszkodtak ahhoz, hogy az any-any az egy beállítás a szabályon, de nem érinti a különböző protokollproxykat.

A vége az lett, hogy kerestünk egy olyan portot, amelyiken biztosan nincs semmi trükközés, a következő partira az amik módosították a náluk lévő tűzfal szabályát, be is indult a kommunikáció.

A második sztori nem sokkal ezután esett meg egy kollégámmal és kisértetiesen hasonlított az előzőre.

Ügyfélnél két telephely, két AD site. Mindkettőn vannak Exchange Hub Transport szerverek. A jelenség: nem mennek át a levelek. Ott állnak a várakozási sorban, és azt mondják, hogy a túloldali szerver nem képes az Exchange szerver autentikációra. (Lásd a korábbi cikk.) A tűzfalas kolléga szerint a hostok között a kért portok engedélyezve vannak.
Ami alapvetően igaz is volt, de amikor megpróbáltak telnetelni, elég érdekes válaszokat kaptak. Lényeg a lényeg, a tűzfalas úriember csak azt felejtette el közölni, hogy a készüléken be van kapcsolva a MailGuard, amelyik meglehetősen szigorú ellenőrzést gyakorol az smtp forgalom felett: egyedül a HELO, MAIL, RCPT, DATA, RSET, NOOP és QUIT parancsokat támogatja, minden más tiltott. Igen, már az ESMTP és az AUTH is.
Nyilván a kikapcsolás után beindult minden.

Welcome

Az ember azt gondolná, hogy ezek a receive konnektorok olyan kicsi, ártalmatlan lények. Aztán ádehogy. (Nem véletlenül szoktam mondani, hogy a konnektorok közül ők a nőneműek. Elvégre az ő dolguk a behatolási engedélyek kiosztása.)

És ha olyan egyszerű lenne behangolni őket! De nem. Hiába tudod, mit szeretnél, ha egyáltalán nem olyan egyértelmű azt összekattogtatni. Az első két fül (general, network) még hagyján, itt minden érthető. De hogyan is kell értelmezni az authentication, illetve permission group fogalmakat? Hiszen mind a kettő ugyanazt jelenti, nem? Nem. Az autentikáció azt mondja meg, hogy a konnektor milyen autentikációs módszereket, milyen technikákat fogadjon. A permission group pedig azt, hogy – az autentikációs technológia alkalmazása után – kik, milyen csoportok férhessenek hozzá a konnektorhoz.
Hogy egy hasonlattal éljek. Odamész egy bankautomatához. Rá van írva, milyen kártyákat ismer. Pl. Visa és ECMC. Ha csak American Express kártyád van, akkor ez nem a te automatád, biztosan nem vehetsz ki pénzt belőle. Ha van ECMC kártyád, akkor bedugod, az automata felismeri, mehetsz tovább. (Ami persze nem jelent automatikusan pénzt, kell a pinkód, kell, hogy legyen zsé a kártyádon, kell, hogy legyen zsé az automatában, stb.)

From Segédlet
From Segédlet

Játszunk el egy kicsit a beállításokkal.

1. kísérlet

Authentication: Externally secured
Permission Groups: anonymous, exchange servers

Ez egy kikényszerített beállítás. Igazából azt szerettem volna elérni, hogy a konnektor teljesen nyitott legyen (ribanc), azaz mindenhonnan mindenkitől befogadjon minden levelet, függetlenül attól, hogy azok neki szóltak, vagy más, akár külső címzettnek. Ezt nevezik egyébként open relay-nek. Ehhez csak az anonymous-t akartam megadni, de a varázsló ragaszkodott hozzá, hogy be legyen kattintva az exchange servers jogosultsági csoport is. Őszintén szólva, fogalmam sincs miért. Hiszen az autentikációs módszernél azt mondtuk, hogy nem foglakozunk az autentikációval, eleve megbízunk a feladóban.

Eredmények:
Levélküldés bentről kintre: sikerült
Levélküldés kintről bentre: sikerült.
Levélküldés kintről kintre: sikerült.

(A tesztről pár szót. Telnet-tel kapcsolódtam a szerverre, a bent és a kint az gyakorlatilag belső, illetve külső feladót jelent. A siker pedig azt, hogy a szerver befogadta a levelet az smtp queue-ba. A továbbküldés – mely már a send konnektor dolga – most nem érdekelt.)

2. kísérlet

Authentication: semmi
Permission Groups: anonymous

Eredmények:
Kintről bentre: sikerült.
Bentről kintre: unable to relay
Kintről kintre: unable to relay.

Fura, nem? Az ember azt gondolná, hogy ez aztán az igazi open relay, nem autentikálunk és csak anonymous hozzáférést engedélyezünk. Ehhez képest igen durva az eredmény, a szerver csak befelé jövő levelet fogad. Már kifelé sem tudunk küldeni, még létező belső felhasználóval sem.

3. kísérlet

Elegem lett a kotyvasztásokból, gondoltam, megnézem, milyen lehetőségeket adnak a beépített tipusok. (Amikor létrehozunk egy receive konnektort, akkor sablonokból választhatunk. Az előző kettő custom sablon volt.)

From Segédlet

Authentication: TLS
Permission Groups: anonymous

Ez az internet sablon volt.

Eredmények:
Kintről bentre: sikerült.
Bentről kintre: unable to relay
Kintről kintre: unable to relay.

Gyakorlatilag ugyanaz történt, mint az előbbi esetben. Ami nem baj, hiszen pont ezt is akartuk: a receive konnektor mindenkitől elfogad levelet, feltéve, hogy a címzett belső ember.

4. kísérlet

Authentication: TLS, exchange server authentication
Permission Groups: exchange servers

A fenti kombináció az internal sablon.

Eredmények:
Hát, az most nincs. Rögtön az első próbálkozásnál, már a ‘mail from’ paraméternél ezt kaptam vissza: client was not autenticated. Ami teljesen rendben is van, hiszen nem vagyunk Exchange szerverek.
Mindenesetre éles rendszerben használva a konnektor remekül működik, a szerver elfogadja a kifelé menő leveleket.

Oké, játszottunk. Most viszont, a kísérletek fényében, rakjunk össze működő receive konnektorokat, különböző esetekre.

Edge Transport szerver

Én a magam részéről törölni szoktam az automatikusan létrejövőket, mert gyakorlatilag nem működnek. Ehelyett a következőket használom:

from corenet
Azok a levelek, melyeknek a címzettje kint van a nagyvilágban. A sablon, amelyikből a konnektor készül, az az internal(!), a network fülön csak a belső Exchange szervereket adom meg.

from internet
Azok a levelek, melyek kintről jönnek és a címzettjük a cégen belül van. A sablon, amelyikből készül, az internet, a network fülön a teljes IP tartományt (0.0.0.0 – 255.255.255.255) kell megadni.

relay
Mindenki, aki a DMZ-ből az Exchange SMTP szerverét használva próbál levelet küldeni. A sablon a custom, a beállítások az 1. kísérletben leírtak. A network fülön csak azokat az IP címeket adjuk meg, amelyek küldhetnek. (Ezzel azért bánjunk óvatosan, hisz ezekre az IP címekre nézve az Exchange szerver open relay lesz.)

Hub Transport szerver

A különbség az, hogy ez a szerver már bent van a belső hálózatban.

client
Gyári konnektor. Ha megnézed, egész érdekes portot használ (587). Ez az SMTP Submission protokoll portja. A történet arról szól, hogy ha van olyan felhasználónk, akinek van belső postafiókja (exchange users permission group), de nem Outlookból levelez, hanem bármilyen más levelezőklienssel (Thunderbird, Eudora, Pine, Pegasus és egyebek), akkor nem RPC-n adja fel a levelét, hanem azon a bizonyos SMTP Submission protokollon. Ha nincs ilyenünk, akkor nyugodtan tiltsuk le a konnektort, ha van, akkor pedig értelemszerűen állítsuk be az IP címeket a network fülön.

default
Ez a – szintén gyári – konnektor leginkább az internal sablonra hasonlít. Ezen annyit szoktam változtatni, hogy nem engedem a teljes IP tartományt, hanem csak a létező Exchange HTS/ETS szerverek IP címeit engedélyezem.

relay
Nagyjából megegyezik az Edge szervernél írtakkal. Annyi az összes különbség, hogy itt már a belső hálón vagyunk, ergo itt azon belső, de nem Exchange szerverek IP címeit adjuk meg, amelyeknek levelezési kényszerük van.

Katasztrófa

Milyen már, amikor a katasztrófa-visszaállítási teszt során következik be a katasztrófa?

Elmesélem a sztorit. Tanulságos. Először ugyanis elböktük, aztán viszont kimásztunk belőle.

Mivel egy komplett datacentert kellett visszaállítanunk, mondanom sem kell, egy csomó ember nyüzsgött a munkán. Az én feladatom meglehetősen korlátozott volt, a levelezésnek kellett mennie a visszaállítás után, oszt jónapot.
Egy teljesen klasszikus CCR/SCR rendszerről van szó, többször is végigjátszottam már ilyen teszteket, bent volt egy dossziéban a szükséges egységcsomag. Nem mondhatnám, hogy túlzottan ideges voltam. A CCR/SCR replikációra ránéztem még a teszt előtt, normálisan ment.

Aztán egyik délután kilőtték a jelzőrakétát, elvágták a vezetéket a két telephely között. Másnap reggel megkérdeztem a PM-et, hogy tényleg elvágták-e a kábelt. Ja.
Oké, a disable-storagegroupcopy paranccsal kiirtottam az irmagját is a standby node-nak az éles rendszerből, majd vártam, mikor szólnak, hogy mehetek a DR telephelyre, stoppolni. (A kiirtás nagyon fontos: mint nemrég is írtam, ha fizikailag elérhetetlenné válik az SCR, akkor a backup nem törli a logokat, így viszont hamar feltelnek a logpartíciók.)

Eltelt pár nap, szóltak.

Kezdtem az első lépéssel, az adatbázisok macerálásával.

Itt most egy kis kitérő jön. Legyen már szakmai anyag is az írásban, ne csak egy szívás története.
Az SCR node az egy furcsa lény. Felkerülnek rá az Exchange dll-ek, lesz rajta konzol és shell… de Exchange szerver, az nem. Nem fogod látni sehol sem a konzolban. De még a shellben sem. A jelenlétéről is csak akkor fogsz tudni, ha néhány parancsnál használod a -standbymachine kapcsolót.
Ennek ellenére vannak rajta adatbázisok. (Még szép, hiszen ez az egész elv lényege.) Information Store, az nincs. Viszont van Microsoft Exchange Replication szolgáltatás.

Na most, mire is lehet használni egy ilyen szervert?

  • Database portability
    Valamilyen oknál fogva egy adatbázisodat egy másik szerveren szeretnéd felcsatolni. Lehet, hogy kidőlt az SCR forrásod alól a diszk alegység, lehet, hogy kidőlt a CCR-ed alól az az egy SAN, amelyiken mindkét adatbázispéldányok laktak (ugye-ugye), lehet, hogy át akarsz vinni egy adatbázist egy tesztkörnyezetbe. Nos, erre az SCR adatbázisok tökéletesek.
  • Site Resilience
    Az SCR forrásod elpárolgott. Semmivé lett. Te pedig szeretnél máshol, más telephelyen, az előzővel egyező néven létrehozni egy új szervert, majd ez alá felcsatolni az SCR adatbázisokat.

Akármelyik esetről is legyen szó – jelenleg ugye a második játszik – az első lépés az adatbázisok preparációja. Rájuk kell játszatni a logokat – és egyáltalán, olyan állapotba kell hozni, hogy az adatbázis felcsatolható legyen.
Erre szolgál a recover-storagegroupcopy parancs, méghozzá a következő szintaktikával:

recover-storagegroupcopy -identity server\sg -standbymachine scrname -force

Térjünk vissza a konkrét történethez. Kiadtam a fenti parancsot – és azt mondta az a gonosz EMS, hogy nincs ilyen nevű SCR szerverem. Nyilván begépeltem még néhányszor, hátha elütöttem egy karaktert, beírtam a teljes DNS nevével, adtam meg -domaincontroller értéket… hiába. Próbálkoztam a guglival is, de csak annyi választ kaptam, hogy ha ezt írja ki, akkor tényleg nincs a rendszerben ilyen nevű SCR.
Hát ez meg hogyan lehet?

Úgy, hogy – most nem részletezendő okok miatt – még rögtön a teszt elején pár percre összenyitották a két telephelyet. Mi történt? A címtár konfigurációs névtere egyből lereplikálódott a DR telephelyre. Benne az az információ, hogy én akkor már lebontottam az SCR kapcsolatot – azaz nincs SCR a rendszerben. Szépen vagyunk. A DR telephelyen nincs más, amiből építkezhetnénk, csak az SCR node. Ami jelenleg nincs.

Vegyük sorra a lehetőségeket.

  • Húzzunk fel egy kamu clustert az élessel megegyező névvel a DR telephelyen, majd építsünk ki egy SCR kapcsolatot? Az égegyadta világon semmi értelme sincs.
  • Tegyük vissza az SCR szervert az éles környezetbe és építsük ki újra az SCR replikációt? Ez megoldás lenne, de DR teszt során még csak gondolni sem szabad ilyesmire. Nincs éles környezet.
  • Egy korábbi system state mentésből töltsük vissza a konfigurációs névteret – azon belül is az Exchange ágat – autoritatív módon a DR telephelyen? Ez akár még működhetne is, csak éppen ekkor már az összes felesleges DC ki volt irtva a DR címtárból, a meglévők meg már annyira el voltak állítva, hogy esélytelen volt a visszatöltés.
  • Próbáljuk meg Eseutil-lal feljátszatni a logokat? Biztos, hogy a restore-storagegroupcopy csak ennyit csinál? Itt ugyanis az a gond, hogy ha mégsem, akkor nagyot bukunk, mivel a különbség nem itt derül ki, hanem egy későbbi lépésben. Ahonnan már nincs visszaút. És akkor már nincsenek adatbázisok sem, ergo bedőlt a DR teszt levelezési része, az meg azért túl nagy blamázs lenne.

Maradt a jó öreg magyaros megoldás, a buhera. Amit biztosan tudtam, az az, hogy az SCR beállításai a címtár konfigurációs névterében laknak, méghozzá az Exchange Services ág alatt. Mi lenne, ha megkeresném ezeket és úgy csinálnék, mintha lenne még SCR node a rendszerben?
Az első probléma ott volt, hogy honnan találom ki, hol vannak ezek az értékek? A DR telephelyen már nem volt SCR, de az élesen sem. Szerencsére volt hozzáférésem más, hasonló rendszerhez, beléptem, turkáltam. Hadd ne mondjam végig a folyamatot… itt van az eredmény. A beállítások a Storage Group objektumokon vannak (mindegyiken egyenként), méghozzá az MsExchangeStandByCopyMachine nevű változóban, a következő kódolással:

scrname.domain.name;1;xx:xx:xx;yy:yy:yy

Ahol az xx:xx:xx a replaylagtime, az yy:yy:yy pedig a truncationlagtime. Az 1-es értékét nem tudom – de őszintén szólva, nem is érdekel. Nem szándékoztam működő SCR-t létrehozni, csak behazudni a címtárnak, hogy az scrname nevű gépem valóban SCR target volt.

Óvnék mindenkit, hogy éles rendszerben ezeket az értékeket módosítsa. A Microsoft hivatalos álláspontja szerint az SCR replikáció paramétereit csak úgy lehet megváltoztatni, ha lebontjuk a replikációt, majd az új paraméterekkel újra létrehozzuk. Nyilván okuk van rá.

Hozzáteszem, a kockázat most is megvolt. De csökkent! Ha Eseutil-lal esek neki, akkor esély sincs rá, hogy a restore-storagegroupcopy esetleges plusz műveletei lemenjenek. Ha viszont behazudok egy SCR-t, akkor lehet, lefut a restore-storagegroupcopy, a továbbiakban meg már kell a fenének az SCR.

Kiválasztottam egy adatbázist, preparáltam, majd lefuttattam rá a restore-storagegroupcopy parancsot. Molyolt, molyolt… majd a várt 1 warning helyett kettő dobott. Ennek azért nem örültem olyan nagyon, tekintve, hogy a plusz figyelmeztetést olyan szinten voltam képtelen értelmezni, hogy még az se derült ki belőle, hogy lefutott-e a parancs? Vadul nekiálltam túrni a netet, de nem találtam megnyugtató választ. Lefuttattam még egyszer a parancsot… erre megint azt mondta, hogy nincs SCR. Háteztmeghogyan? Hiszen éppen az előbb hazudtam be, hogy van?
Vissza az adsieditbe… és tényleg nem volt ott a beírás. Valaki törölte. Tehát van egy érthetetlen warning-om és belefutottam egy önvédelmi mechanizmusba. Nem túl biztató.

Elvonultam gondolkozni.

A kulcs az, hogy a warning ellenére tényleg megcsinálta-e mindazt, amit tennie kellett? És csak utána törölte-e ki az általam beírt adatokat a védelme?
A törlés biztosan utólag történt, mert hibaüzenetet csak az újabb futtatáskor kaptam. De az a warning… Ráküldtem a parancsot a -verbose paraméterrel. Nem lettem okosabb. Végül úgy döntöttem, hogy ha tényleg képtelen lett volna elvégezni a dolgát – akár egy kezdeti ellenőrzés után is – akkor itt hibaüzenet lett volna, nem figyelmeztetés. Meg egyébként sincs más esélyem, csak ez.
Behazudtam a fenti string-et az összes storage group-nál, beírtam az alábbi parancsot, és malmoztam.

get-storagegroup | restore-storagegroupcopy -standbymachine scrname -force

Jó jel volt, hogy nagyon sokáig dolgozott.

Aztán nagy levegő, gyerünk tovább. DNS preparáció, AD jogosultságok állítása, majd jöhet a vízpróba. Cluster telepítése, a recovercms kapcsolóval. Prerequisit-ek ellenőrzése. 10 perc. Az életemből a tízszeresét vette el. Végül átszaladt rajta. Most jött a döntő pillanat: az első adatbázis felcsatolása.
Sikerült. Aztán szépen egyenként az összes.

Innentől meg már a jól ismert ösvényen mentünk tovább.

Trükkös telepítés

Ide a bökőt, hogy kevesen tudnak róla. Én is véletlenül botlottam bele. Hallottál már az “Exchange Server 2007 Password Reset Tool”-ról? Ugye, nem? Pedig izgalmas dolog.
Arról szól, hogy ha feltelepíted a CAS szerveredre, akkor OWA2007 alól is képesek lesznek a felhasználóid megváltoztatni a jelszavaikat, még akkor is, ha éppen nem ISA/TMG szerveren keresztül publikáltad ki az OWA-t. (Ha igen, akkor ez a leírás a barátod.)
Némi kellemetlenség, hogy a fenti tool nem minden rendszerre telepíthető.

Két szigorú kritériuma van:

  • A CAS szervernek Exchange 2007 SP3-nak kell lennie.
  • IIS7 kell hozzá. (Azaz a CAS szerver alatt Windows 2008 kell dübörögjön.)

Oké, lássuk, honnan lehet letölteni, hogyan kell telepíteni.

Trükkösen.

Fogsz egy regeditet, és a HKEY_LOCAL_Machine\System\CurrentControlSet\Services\MSExchange OWA objektumban létrehozol egy új DWORD (32 bit) tipusú változót ChangeExpiredPasswordEnabled néven, majd az értékére beírsz egy 1-est.

Ennyi. Meg egy iisreset -noforce.

Megyen a log vándorútra

Nagyjából éppen a bokáig érő lószarban sárban cuppogtam Moritzburg környékén, amikor egyik ügyfelünk nem kicsit bonyolult Exchange mailbox szervere úgy döntött, hogy torkonszúrja magát. No nem nagyon, de két mailbox adatbázis és a public folder adatbázis leállt. Kolléga rávetődött az incidensre. Hamar rájött, hogy a leállást az okozta, hogy betelt egy log partíció. Egy olyan partíció, ahová ez a 3 adatbázis dolgozott.

Kitérő:

Igen, ilyet teljesítményproblémák miatt nem szoktak csinálni. Csakhogy egész egyszerűen az ügyfélnél annyi adatbázis van, hogy nincs annyi betű az angol ABC-ben, hogy minden log könyvtárhoz külön partíciót rendeljünk. Így a 3 legritkábban használt, legkisebb adatbázis log fájljait egy partícióra tettük.

Nos, a két pici mailbox adatbázisból az egyik bevadult. Nem, nem a korábbi bevadulás, ennek üzleti okai voltak. A vadulás miatt elszabadultak a logfájlok, betelt a partíció, méghozzá olyan gyorsan, hogy a riasztás után már cselekedni sem maradt időnk – aztán leállt mindhárom adatbázis.

Kitérő:

Maga az Exchange mailbox rendszer a következőképpen nézett ki: CCR rendszer egy aktív és egy passzív node-dal, melyhez kapcsolódott egy SCR rendszer egy passzív node-dal.

Tehát ez volt a játszótér és adott volt a feladat. Az ügyfél nyilván ki volt kattanva, hiszen mi az, hogy egy ilyen bonyolult cluster elérhetetlenné válik – és természetesen azt várta el, hogy minél hamarabb megint elérhetőek legyenek az adatbázisok. Kolléga fogta, és a CCR mindkét node-ján elmásolta ugyanazt a nagy kupac régi – ergo már biztosan rájátszott – logot mind a public folder, mind a bevadult adatbázis logkönyvtárából, felmountolta az adatbázisokat és minden be is indult szépen. Az adatbázisok működtek, sőt, a konzol alapján a log replikáció is egészséges volt. Problem solved.

Egészen addig mindenki nyugodt volt, amíg el nem érkezett a mentés ideje. De elérkezett. Le is ment – majdnem minden adatbázisra. Egy, csak egy szaladt hibára, az a bizonyos vad adatbázis. Mely ugye nem véletlenül vadult be, a hirtelen megnövekedett üzleti igények okozták a hízást – azaz meglehetősen fontos adatok kerültek az adatbázisba.

Kolléga még megnézte az eseutil /mh paranccsal, hogy konkrétan milyen log fájlok hiányoznak a passzív node-on – de a válasz az volt, hogy semmi. Rá lett küldve egy reseed (update-storagegroupcopy), de csak annyit csinált, hogy a passzív node-on kiürült a logkönyvtár.

Ekkor érkeztem vissza szabadságról és rögtön meg is kaptam a feladatot.

Helyzetfelmérés:

  • Az adatbázis megy, ránézésre a log replikáció egészséges, az ügyfél nyugodt.
  • Ezzel szemben az aktív node-on rengeteg log van, a passzív node-on egy sem. Az adatbázisok azonos méretűek, azaz a reseeding sikerült.
  • Az SCR node-on az a bizonyos partíció fullon volt, a replikáció az említett adatbázisokon állt. Szemmel láthatóan az SCR-rel senki sem foglalkozott.
  • Viszont mivel nem sikerült a mentés, az aktív node-on pár óra múlva megint elfogy a hely, szóval nagyon gyorsan ki kell találni valamit.

Ergo egyfelől meg kellett akadályoznom az újabb leállást, másfelől össze kellett kötözgetnem a szálakat, mert itt valami nagyon félrement.

A feladat első része volt az egyszerűbb. Kerestem egy üres partíciót (későbbi fejlesztésekre volt is félrerakva egy, de a későbbi szó pont azt jelenti ugye, hogy nem mostani), majd átirányítottam ide a logolást.
Ránézésre olyan egyszerűnek és logikusnak tűnik – de nem az. Nem véletlen, hogy a kollégám sem így próbálkozott. Neki ugyanis sietnie kellett.
Első lépésben ugyanis suspendbe kell rakni a log replikációt. Ez még nem is fáj.
Második lépésben dismountolni kell az adatbázist, ráadásul bizonytalan ideig. Ez már fájt az ügyfélnek, nem is mentek bele szó nélkül. Amikor közöltem velük, hogy ez van, törődjenek bele, nincs más lehetőség, rögtön jöttek, hogy bezzeg a kollégám meg tudta oldani máshogyan. Na, ez a szakma kellemetlen része. Elmagyarázni az ügyfélnek a szakmai finomságokat, úgy, hogy közben a mundér becsületét is megvédjük. Végül azért sikerült tisztáznom, hogy a múltkori az egy gyors, ideiglenes megoldás volt, én viszont már a végleges megoldáson dolgozom.
Ha ezzel megvagyunk, akkor jön a move-storagegrouppath parancs, valahogy így:

move-StorageGroupPath -Identity ‘adatbázis‘ -LogFolderPath ‘ujlogkonyvtar‘ -SystemFolderPath ‘ujsystemkonyvtar‘ -configurationonly

Vagy hogy érthetőbb legyen, konkrét példával:

move-StorageGroupPath -Identity ‘server\vad-adatbazis’ -LogFolderPath ‘Z:\exchsrvr\log’ -SystemFolderPath ‘Z:\exchsrvr\log’ -configurationonly

Határozottan felhívom a figyelmet a configurationonly paraméterre! CCR környezetben a logkönyvtárt ugyanis nem lehet csak úgy átrakni. A parancs hatására a következők történnek:

  • Az AD konfigurációs névterében az érintett storage group tulajdonságainál átíródnak a log, illetve system könyvtárak útvonalai.
  • Emellett az új könyvtár (z:\exchsrvr\log) meg lesz osztva, méghozzá egy GUID névvel. Ha visszanézzük, akkor ez a GUID a storage group azonosítója. A megfelelő jogosultságokat szintén beállítja a parancs.

Végül ha ezen túlvagyunk, akkor manuálisan átmásoljuk a lecsatolt adatbázis log és system fájljait a régi helyről az újra, majd felmountoljuk az adatbázist. Ha nem rontottunk semmit el, akkor el is indul.
Látjuk, az időbeli bizonytalanságot a logfájlok másolása jelenti. Viszont amíg a másolás folyik, addig szét is tud replikálódni a címtárban a változás.

Ezzel a sürgős résszel meg is volnánk, jöhet a kötözgetés.

A biztonság kedvéért ráküldtem én is egy reseedet. Hátha apucitól jobban elfogadja. De semmi. Vágjunk mélyebbre. Újraindítottam a passzív node-on a replikációs szolgáltatást.
És végre történt valami. A replikáció státusza elmozdult az egészséges állapotból. Initializing. A végtelenségig. Vártam rá egy kicsit, aztán eluntam. Ennél még a kamu egészséges visszajelzés is jobb volt. Újabb reseed.

Jobb híján nézelődtem, gondolkodtam. A log könyvtár átmozgatása rendberakta az SCR-t, tökéletesen működik. Azért ez is valami: van egy aktív CCR node-om és egy passzív SCR node-om.
Aztán egy kellemetlen gondolat. Eddig azt mondtam, hogy a logfájlok másolása sértett meg valami ismeretlen dolgot az Exchange rejtett mélységeinek szövetében. De akkor a public folder adatbázisok logshipping folyamatának sem kellene működnie. Aztán mégis működik.
Hjaj. De bonyolult az élet.

Get-storagegroupcopystatus. Mindenki healthy. Egészségükre. Aztán hoppá. A CopyQueueLength értéke a vad adatbázisnál 14234. Mit ír erről a manuál? Azt, hogy ha az értéke nagyobb 3-nál, akkor baj van. Hmm. Ide azért most nem kell fejszámolóművész, itt baj van.

Test-replicationhealth. Minden passed – kivéve a vad adatbázis copy queue értéke. Az viszont nagyon nem.

További nézegetés. Hoppá. Nincs a passzív node-on edb.chk. Ezt azért volt nehéz észrevenni, mert abszolút nincs semmi más sem a könyvtárban. Ez azért magyarázza, miért nem ment le a mentés. (Akinek újdonság lenne: az Exchange az edb.chk fájlba írja, melyik lognál indult a mentés, azaz a mentés után meddig kell törölni a logokat.) Lehetséges, hogy nem csak a backup használja ezt, hanem a log replikáció is? Nagyon lehet, hiszen egy normális reseed úgy indul, hogy törli az edb.chk-t és az adatbázist.
Akkor lehet, hogy nem is jó a látszólag jó reseed?

Mint az ínyenc, aki a legfinomabb falatokat a végére hagyja, én is elővettem végül az event logot. Volt is benne érdekesség.

Nagyítás

Ez legalább világos beszéd, végre. Habár az eseutil /mh szerint nem hiányzik neki logfájl, de az eventlog szerint mégis hiányzik a 84679-es számú. (Azért ezen ne lepődjünk meg. Az eseutil csak az adatbázis épségével foglalkozik – és az adatbázisok tökéletesen jók. Itt a logshipping szakadt össze, de ahhoz az eseutil meg nem ért.) Természetesen ilyen nevű logfájl nincsen. De ennyi szívás után az ember már csak legyint és átszámol hexába: 14AC7. Ilyen nevű log már lehet. De hol? Hát például a kolléga által félrementett logok között, melyeket szerencsére nem töröltünk.
Mi lenne, ha bemásolnám az aktív node logkönyvtárába?
Bemásoltam. Egy perc focilabda rugdosás (az új irodámban nincs darts tábla) – és ott van a log a passzív node-on is. Vérszem. Az az, amit kaptam. Bemásoltam a sorban következő 10 logot az aktív node-ra. Egy percen belül megjelentek a passzív node-on is. Ujjé. Elkezdtem név alapján bogarászni az éles log könyvtárat és a mentett logok könyvtárát. Úgy tűnik, hogy az egyik a zsák, a másik meg a foltja. Ha a félremásolt logokat átmásolnám az éles logkönyvtárba, akkor zárt lenne a sor.

Persze ehhez több hely kell.

Újabb telefon az ügyfélnek. Leállnánk pár percre, ugye nem baj? Ügyfél füle egy kicsit rángatózik.

Átmásoltam a logokat egy nagyobb partícióra. (Igen, ez már adatbázispartíció volt. De csak a mentésig lesznek itt a logok, addig meg kibírják.)

Utána pedig megtörtént a nagy családegyesítés. Elvonultam gyakorolni a külső csavarást a nyomtató asztalának lábai közé. 20 perc műlva néztem vissza – és a logok szorgalmasan másolódtak át a passzív node-ra. Remek.

Legyen teljes a győzelem: újabb get-storagegroupcopystatus. A CopyQueueLength értéke szépen le is csökkent… de miaf… elkezdett növekedni a ReplayQueueLength értéke. Ugyan – hessegettem el a kellemetlen gondolatot – ez most kapott hirtelen 14000 logot, persze, hogy nem tudja ilyen tempóban rájátszani. Hagyjuk békén, holnap reggel majd meglátjuk, mi lesz a vége.

Eljött a holnap reggel. A győzelem érzésével gépeltem be a jó öreg get-storagegroupcopystaus parancsot – és a ReplayQueueLength értéke 500 körül volt. Az első gondolatom rögtön az volt: miért? A nullát el tudtam volna fogadni. A 14000 körüli értéket szintén. De miért pont 500?
A magyarázat gyorsan jött. Konzol, gyors vizuális pásztázás: a vad adatbázisnál a logshipping státusza failed. Aha. 500-nál besokkalt, aztán azóta coki.

Hát. Tulajdonképpen előrébb vagyunk. De a beteg még mindig kómában fekszik.

Most már nem álltam neki ködöt rágni, mentem egyből az eventlogba.

Nagyítás

Nagyítás

Keressünk rá a hibakódra. Azt írja, hogy a 1216 azt jelenti, hiányzik néhány tranzakciós log. Kérdezzem le az eseutil /mh paranccsal, mely logok hiányoznak. Lekérdeztem. Semmilyen log sem hiányzik.

Bakker. Mégis köd. Azért ez már kezd bizarrá válni: egyfelől azt mondja, hiányzik neki x darab log, ahhoz, hogy rájátssza végre az összes logot arra az adatbázisra, amelyikre már jó egy hete rá van játszva az összes log – másfelől pedig konkrét kérdésre azt mondja, hogy nem is hiányzik neki egy log sem.
Csak éppen nem indul el a rájátszás.

Ekkor már teli csőrrel gyakoroltam a védhetetlen bombákat a szerverszoba ajtajára.

Végül visszadaráltam az elejére. Emberek, végülis… már van edb.chk fájlunk a passzív node-on. Ez jó hír.
Töröljük gyorsan le. Azaz küldjünk rá egy reseed-et. Mert mi van, ha az a baj, hogy az adatbázis – amelyikre már rá van játszva minden log – nincs szinkronban a logkönyvtárban lévő edb.chk-val, mely még csak nemrég jött létre, a replikáció befejeztével. A reseed ugyanis törli mindkettőt, majd újra létrehozza, immár szinkronban.

És tényleg.

A ReplayQueueLength értéke egyből lenullázódott, a logshipping meggyógyult. A pezsgőbontással vártam még tíz percet, mert ez a nyomorult replikáció képes megint elromlani – de nem.

Tanulság:

  • Amíg elő nem varázsolom valahonnan a hiányzó logokat, addig felesleges a reseed. Nincs értelme. Nincs edb.chk.
  • Ha megvannak a logfájlok, akkor vissza kell másolni az aktívra, a logshipping beindul, legyártódik az edb.chk. Ekkor viszont kötelező a reseed, mert ez hozza összhangba a két node-ot.

Végül egy kényelmetlen gondolat:

És akkor mi van, ha közben töröltem a logokat?
Nos, végső esetben az SCR-en ott kellett lenniük.
De mi van, ha onnan is töröltük? Gáz.
Szóval óvatosan azzal a közvetlen logpiszkálással.

ps.
Elkiabáltam. Utólag derült ki, hogy az SCR node-on sem megy a rájátszás, ott is újra kellett seedelni az adatbázist és a logokat.

Vicc

Van egy meglehetősen rejtélyes hibánk. Időnként az Address List szolgáltatás megáll a CCR clusteren és ilyenkor nem tudunk új postafiókokat létrehozni. A workaround az, hogy ráküldünk egy failover/failback párost, azaz gyakorlatilag újraindítjuk az AL szolgáltatást is magába foglaló System Attendant szolgáltatást.
Nyilván ez így még nem igazán kielégítő, emiatt turkáltam egy kicsit a neten. Így találtam meg a KB viccrovatát. Kicsit régi a történet, ma már nem is aktuális… de jó.

You cannot create a new mailbox or enable a mailbox in an Exchange Server 2007 environment on February 29, 2008

Sorvezető

Ha ISA 2006 szerveren keresztül szeretnénk Exchange 2007 webszolgáltatásokat kipublikálni, ahhoz ma már nem kell remegő kézzel nekifogni. Az internet tele van cikkekkel, írásokkal, tényleg minden információ begyűjthető. Konkrétan itt van egy MS cikk, ez alapján nem lehet semmi gond.

Vagy mégis?

Nos, amennyiben az Exchange szervered alatt Windows Server 2008 fut, akkor azért fognak érni meglepetések.

Nem akarom végig leírni a folyamatot, az említett cikk tényleg nagyon jó. Itt inkább csak a buktatókat gyűjteném össze.

Először is, a Windows 2003-as CA szerver nem fog tudni neked SAN tanúsítványt gyártani. A következő paranccsal lehet erre rábeszélni:
certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
Majd újra kell indítani a Certification szolgáltatást.

Oké. Fogod, elindítod a böngészőt az Exchange szerveren, rácsatlakozol a http://ca-server.cegnev.hu/certsrv/ weblapra – és már nem emlékszem pontosan, mit kapsz válaszul, de nem a megszokott nyitólapot. Valami olyasmit mond, hogy ez a tartalom a számodra nem érhető el.
Kedves.
A magyarázat itt található: http://support.microsoft.com/kb/922706.
A Windows Server 2003 alatti tanúsítványosztogató weblap olyan activex kontrollt használ, melyet a Windows Server 2008 / Vista undorral lök el magától. A megoldás: fel kell telepíteni egy patch-et a CA szerverre, hogy úgy is tudjon tanúsítványt osztogatni, ahogy az újabb fiúk kérik.

Akkor most már mehetünk is vissza a weblapra. De mégsem. Azt mondja, immár a helyi böngésző, hogy a CA weblapjának https-en keresztül kellene jönnie. Addig ő nem fogja megmutatni a tartalmat.

Kitérő: Szeneslapáttal igazítanám meg a frizuráját annak, aki ezt az egész nevetségesen idióta ‘Enhanced Security’ módú Internet Explorert kitalálta. Tipikusan az, amikor átesünk a ló túloldalára: használhatatlanná tesszük a terméket és a végtelenségig elbonyolítjuk az egyébként is meglehetősen érthetetlen konfigurálást. Ráadásul úgy tudom, W2k8 szerver alatt kikapcsolhatatlan – miközben ott már épp elég védelmet jelentene az UAC is. Amióta ez van, azóta az az első, hogy telepítem a Firefox-ot a szerverekre is. Szerveren úgyse nézeget az ember pornó oldalakat.

Fogcsikorgatás. Nyilván valahol át kell kattintani valamit, melynek a neve még csak nem is utal arra, hogy mit befolyásol. Szerencsére itt van a net, ahol egy sorstárs már megtalálta rá a workaround-ot.
Hurrá. Elérhető lett a CA weblapja.

Lehetne igényelni az Exchange tanúsítványát… de ez mégsem ennyire egyszerű. Amennyiben az Exchange szerverünk Windows Server 2003 alatt fut, akkor – ahogy a cikk is írja – powershell-ből tudunk tanúsítványt generálni. Csakhogy jelen esetben már W2k8 az alap, ezen már van grafikus felület is. Összedobunk egy custom MMC konzolt, felvesszük bele a Certificates (local machine) snapin-t. A Personal folderen jobbkattintunk, majd a lenti képen elmegyünk a ‘Create Custom Request’ menüponthoz.

Nagyítás

Tulajdonképpen mehetnénk a ‘Request New Certificate’ menüpontba is, hiszen itt van, LAN-on belül a CA szerver, mindenki domaintag, ne kelljen már bináris fájl tartalmát kopipasztázgatni. Mehetnénk… de nem működik. A varázsló második ablakán minden szürke – és közli, hogy nekem bizony nincs lehetőségem webserver tanúsítványt igényelnem. Márpedig hidd el nekem, hogy ha nekem nincs meg ez a jogom, akkor senki másnak sem.
Marad a custom request.

Maga az igény összerakása nem túl bonyolult, egy kicsit szokni kell az újfajta grafikus elemeket, de nem vész. Rá kell kattintani minden izére, meg bigyóra, megnézni, mi is van mögöttük. (Shinder bácsi írása elég jól képbe rakhat bárkit.)
Az alábbi ábrán azt a részt emelném ki, amitől SAN lesz a tanúsítvány.

Nagyítás

Igen, az alternatív nevek. Ahogy az előző linken is van – meg máshol is – beírtam a Subject mezőbe CN-ként a külső nevet, az Alternative Name alá meg az összes szóbajöhető lehetőséget, beleértve azt is, hogy bentről esetleg rövid névvel nyomul valaki. Amit a Subject mezőbe írtam, azt nyilván már nem írtam be az Alternative Name alá is. Aztán végigmentem a láncon, igényeltem, kiadtam, importáltam, majd exportáltam végül megint importáltam… szóval ahogy az első linken szépen le van írva – végül jött kintről az OWA teszt.

Nem sikerült. Azt írta ki, hogy a tanúsítvány nem erre a weblapra szól. A Firefox ennél imformatívabb volt, kiírta azt is, hogy mely weblapokra lenne jó ez a tanúsítvány: csak azokra, amelyek az Alternative Name mezőben szerepeltek. A Subject, az nem jött szóba.

Hozzáteszem, nem vagyok tanúsítvány guru. Fogalmam sincs, mennyire kötelező a Subject alatt CN tipusúnak megadni a nevet, nem tudom, lehet-e ott is DNS formátumot használni. Mindenesetre az egyszerűbb utat választottam, az Alternative Name alá is bedobtam a külső nevet – ahogy az ábrán is láthatod. Működött.

Odahaza ne próbáljátok ki

Kollégám futott bele az esetbe. Látszólag ez is X aktaként indult.

Nagy cég, kétszintű domainszerkezet. A felhasználók is és az Exchange 2003 szerverek is a child domainban vannak. Alapvetően minden szépen működik.

A feladat: az Exchange 2007 óvatos beterelgetése.

A címtár preparálása rendben megtörtént, legalábbis a cég alkalmazottja szerint. (A francokat.) Kolléga kiment, szétnézett, látszólag tényleg rendben volt minden.: a csoportok létrejöttek, a séma módosult, az ég kék volt és a madarak csicseregtek.

CAS szerver, HTS szerver rendben be is épült. Jött volna a Mailbox szerver, de a telepítő feldobott egy figyelmeztetést:

Nem tűnik annyira veszélyesnek, nem villog, nem piros… de akkor is, mi lehet ez? Azt mondja, a forest root tartományban nincsen RUS. De hiszen van! Konzolból látszik, adsiedit-ből látszik, a tartományi replikáció nem jelez hibát. Akkor ott RUS-nak kell lennie.

Agyalás. Internet. Kérdések az üzemeltetőkhöz: a setup /preparelegacyexchangepermissions lement minden tartományban?
Persze, hiszen ha paraméter nélkül adják ki, akkor az mindenhol megtörténik.
A setup /preparedomain is lement mindenhol?
Igen.

Ötlet semmi.

Egyáltalán, fontos-e ez egyáltalán? Fórumon valaki felvetette ugyanezt, egy MVP kolléga leoltotta, hogy szarni bele, nem fontos.
Annyiból igaza van, hogy ha a forest root tartományban nincs felhasználó, nincs Exchange szerver, az Exchange 2007 meg úgyis feleslegessé teszi a RUS-t, akkor ki a fenét érdekel, hogy most létezik-e belőle példány a forest root-ban vagy sem?
Annyiból viszont nincs igaza, hogy az AD egy bonyolult, nehezen átlátható rendszer. Ezt tovább bonyolítani csak úgy lehet, ha az adott szinten biztosak vagyunk benne, hogy minden jól működik. Ha nem teljesen százas az AD és ráteszek egy Exchange 2007 szervert, ki garantálja, hogy nem buknak ki váratlan és rejtélyes hibák?

Aludtunk rá egyet.

Másnap leültünk beszélgetni, hátha a közös gondolkodás előrébb visz. És tényleg.

Kitaláltunk egy hipotézist. Mi van, ha – még évekkel ezelőtt – nem történt meg az Exchange 2003 szintű domainprep a forest root tartományban? Most meg a fiúk rányomtak egy setup /preparelegacyexchangepermissions-t, mely kiírta, hogy nincs RUS – aztán ettől megijedve csináltak egyet? Ekkor egy látszólag jó rendszert kapunk – de a domainprep elmaradása miatt az Exchange 2007 nem érzékeli a forest root RUS-t.

Kolléga nekiugrott, tesztrendszeren lemodellezte. Bingo. 2003-as domainprep nélkül pont ehhez a szituációhoz jutottunk. Tulajdonképpen meg is kaptuk a választ: tudjuk, mi okozta a jelenséget, tudjuk, hogy nem fogja zavarni a 2007-es Exchange-t – mi kell még?

Például az, hogy lehet-e javítani? Hiszen van tesztrendszerünk, miért ne néznénk meg?

Kolléga ráküldte – a már 2007-esre preparált tartományra – a 2003-as domainprep-et. Na, ott volt ám csikorgás, meg füstölés. Fogaskerekek sikítottak, recsegett a fém. Végül lement a domainprep – de egy bizarr rendszert kaptunk. Az adminisztrátorok például kapásból le lettek tiltva (deny) egy csomó Exchange objektumról. Ijesztő volt.
Ekkor jött a kisérlet második fele. Kolléga megküldte a tartományra újból a 2007-es preparációkat – és gyönyörűen kiegyenesedett minden.

De az éles rendszeren valószínűleg nem próbáljuk ki.