Tag: ccr

Katasztrófa

2010-11-20 / / 0 Comments

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.

Vazze

2008-11-30 / / 0 Comments

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

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

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

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

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

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

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

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

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

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

Management Tools
Completed
Elapsed Time: 00:00:07

Mailbox Role
Completed
Elapsed Time: 00:06:34

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

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

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

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

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

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

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

Tétova cluster

2008-11-23 / / 2 Comments

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

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

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

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

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

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

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

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

Erre bizony hamarosan megoldást kell találnunk.

Halálra replikálva

2008-11-19 / / 0 Comments

Furcsa ez a szakmai blogolás. Van, amikor hónapokig nem történik semmi érdekes, nincs miről írni. Aztán van, amikor teljesen bevadul az élet, hirtelen rengeteg minden történik – de ekkor meg idő nincs megírni.

Ez utóbbi van most.

Így mindenféle körítés, mindenféle hangulatkeltés, mindenféle érzelemfelcsigázás és feloldás, azaz katarzis nélkül most egyszerűen csak leírom, mibe futottam bele a napokban.

Egy ügyfelünknél Windows Server 2008 alapon rakunk össze egy Node and File Share Majority clustert, melyre majd egy Exchange 2007 CCR cluster kerül. (És ez csak apró része a projektnek… nem mondhatnám, hogy mostanában szénné unatkozom magam.)

Nos, tesztrendszer. Minden frankó, rángatom a clustert, mint Floki a lábtörlőt, failover, failback az MMC konzolból … minden működik. Kisördög belémbúj: mit csinál igazi lehalás esetén? Fogtam, lekapcsoltam az aktív node-ot. Erőforrásék szépen el is haltak, majd elindultak vissza online-ba… kivéve a public folder adatbázist. Az nem. Ugocsa non coronat. Persze emiatt a virtuális szerver sem állt fel. Ráböktem a public folderre: bring online. És visszajött. Szép kis cluster: működik a failover, de csak egy kattintás után. Mint a viccben a Microsoft légzsák. Mi lehet ez: tesztelésnél minden remek, éles hibánál meg halál?
Az eventlogban nyilván nem volt semmi.

RTFM.

De tényleg. Elő kellett túrni a Technet Library-ból azt a cikket, hogyan tervezzünk CCR clustert – és ott szépen le is volt írva. Ez kérem, by design.
Mit is takar az a név, hogy CCR? Cluster Continuous Replication. És hogyan is néznek ki a public folderek? Van egy organizáció szintű hierarchia, melynek tartalma több Exchange szerver adatbázisaiból áll össze. Hogyan disztributálódik a public folderek tartalma? Replikációval. Replikáció itt, replikáció ott. Márpedig két dudás nem fér meg egy csárdában.
Azaz a következő választási lehetőségeink vannak:

  1. Ha CCR clusteren akarjuk tárolni a public foldereinket, akkor azok más szervereken nem lehetnek. Ez működhet centralizált felállás esetén.
  2. Ha intenzíven használjuk a public foldereinket és több telephelyen is el szeretnénk érni azokat, akkor nincs CCR. Pontosabban van, de akkor nem lehet public folder replika a clusteren.
  3. Tojunk az alkotmányra. Ekkor kapjuk a fenti viselkedést: a clusterünk valódi hiba esetén nem fog automatikusan átvándorolni a másik node-ra.

Nos… ez van. Mondhatni, ez egy szimpla tervezési probléma.

Hát… nem egészen. Gondoljuk csak el: egyszerűen nem létezik olyan szituáció, hogy valamilyen/akármilyen rendszer upgrade-jével állítjuk elő a CCR clustert. Az bizony ott helyben születik. tehát a public folder adatbázist is rá kell varázsolni valahogyan. Erre pedig jelenleg csak egyetlen szóbajöhető módszer létezik: replikációval. Azaz teljesen szabályosan járunk el, mégis beleütközünk a 3-as megoldásba. Oké, nyilván nem egy világrengető tragédia… de jobb ha felkészülünk rá, hogy arra a pár napra (ritka lusta jószág ám ez a public folder), amíg a teljes public folder tartalom fel nem másolódik a CCR-re, addig a cluster megszűnik cluster lenni.

[Update]
Asztakurva. Most olvasom egy teljesen harmatos blogbejegyzésben a hamarosan kijövő SP1 Rollup5-ről:

While we will have a full list of issues fixed when the Rollup releases, some of major issues are:
…
Exchange 2007 CAS cannot copy the OAB from the OAB share on Windows Server 2008-based Exchange 2007 CCR clusters

Tehát, ha teljesen logikusan, az egyébként szintén teljesen logikus Windows 2008 alapú CCR clusteren futtatjuk az OABGEN processzt, akkor a – megint teljesen logikusan – cached módba kapcsolt Outlook 2007 userek nem kapnak címlistát. Se rosszat, se jót.
Téphettem volna megint a hajam. Mintha olyan sok lenne.