Month: January 2006

Címek az égből

Egyik ügyfelünket az a szerencse érte, hogy egyesítenie kellett saját internetes/belső levelezését anyacége belsős levelezésével. Beszélhetnék a két Exchange organizáció egyesítésének szépségeiről, de most elég lesz, ha csak a címekkel foglalkozom.
Nem kis méretekről van szó: az egyesítés révén több, mint harmincezer új cím fog megjelenni a címlistájukban a jelenlegi ezer mellett – miközben az új címeket csak a top50 felhasználó használja.
Megjósolható, hogy itt nagyokat kell majd varázsolni a címlistákkal.

    Kitérő:
    Ha valaki úgy képzeli el a címlistát, hogy van egy nagy lajstrom, benne a tagok neve – az hatalmasat téved. Szó sincs ilyesmiről. Az egész lista tulajdonképpen egy bazi nagy LDAP lekérdezés. (Érdemes megnézni az Exchange System Managerben a címlista tulajdonságlapján. Igen, arról a kínai szövegről van szó. Később részletezni is fogom.) Lehet ujjongani: mekkora ötlet, nincs lista, nincs egyenként postafiókba firkálgatás, egyszerűen van időnként egy gyors ldap query és ennek eredményét használják a kliensek. És az ldap query gyors – hiszen ez az értelme az egész adatbázis faszerkezetnek. (Már látom előre, hogy erre a szóra mennyire rá fognak harapni a keresőrobotok.:)
    Nos, ha kiujjongtuk magunkat, jöhet a keserves ébredés. Indítsunk el egy ldp-t (support tools) és vizsgáljuk meg egy felhasználó értékkel is bíró tulajdonságait. Fókuszáljunk rá a showInAddressBook tulajdonságra és lassan forduljunk le a székről. Igen. Minden exchange tulajdonságokkal rendelkező objektum tulajdonságai közé be van vésve, hogy mely címlistáknak a tagja.
    Láthatod, nem hazudtam. Nevekből álló lista nincs. Van lekérdezés és van objektumba bevésés. Mindezzel sikerült ötvözni a kényelmetlenséget a lassúsággal. Szerencsére a lassú folyamatok időzíthetők, így végülis nem vészes. (De erről megint később.)

No, nézzük a feladatot. A fentről jövő címeket egy OU szerkezetbe fogja beletojni a MIIS, kontaktok formájában. Természetesen a globális címlistában (Global Address List, GAL) meg fognak jelenni, hiszen azért globális a szerencsétlen.

Ötlet1.
Csináljunk egy alternatív globális címlistát. Na jó, értem én, nem kell kötekedni – igen, ez már nem globális. Csináljunk egy listát és valahogy szűrjük ki a beszülető címeket. Mivel az ügyfélnek is vannak kontaktjai, a legegyszerűbb szűrés – kihajítjuk a kontaktokat – kizárható. Vegyük elő megint az ldp-t, nézzük végig az egyes objektumok tulajdonságait, hátha találunk valami jó szűrőfeltételt. Nos, nem. Nincs. Ez nagyon rossz hír. Kénytelenek leszünk csinálni egyet. Erre valók az ún custom attribute tulajdonságok, van is belőlük tizenhat. Most még csak tesztelünk, tehát egy-egy kontakt, csoport illetve felhasználói postafiók második custom attribute tulajdonságába beírjuk, hogy Valami. Innentől már csak csinálni kell egy teszt címlistát, majd összekattogtatjuk a szűrést ezen tulajdonság értékére. Ja, igen, elfelejtettem mondani, az Address List tulajdonságlapján az egyik fül alatt egy kattogtatógép lapul, ezzel lehet összeállítani ldap query-ket. Legalábbis ez volt a szándék. Sajnos a megvalósítás ettől igen messzire került. Röviden fogalmazva botrányos: a fenti feltételt spec nem lehet összeállítani.
Erről van szó: gyűjts le mindenkit, akinél
vagy userpostafiok.customattribute2=’Valami’
vagy kontakt.customattribute2=’Valami’
vagy group.customattribute2=’Valami’.
Nem egy nagy ügy, így nézne ki:
(|
(&(objektum=user)(customattribute2=Valami))
(&(objektum=kontakt)(customattribute2=Valami))
(&(objektum=group)(customattribute2=Valami))
)
A fenti példán remekül el lehet magyarázni az ldap lekérdezés szintaktikáját. Kezdjük az ún. lengyel logikával. Nem azt mondják, hogy ‘3+3=’, hanem azt, hogy ‘+(3)(3)=’. Az & jelenti az ‘és’ műveletet, a | a ‘vagy’ műveletet és a ! a tagadást.
A valóság ennél jóvabb cifrább, nyilván meg kell vizsgálni, hogy egyáltalán léteznek-e a tulajdonságok és az objektum beazonosítása sem ilyen egyszerű.
Kezdjük a kattogtatást.
Első fül: Kellenek a kontaktok, a postafiókok és a csoportok.
Második fül: Kell az összes Exchange szerver.
Marha jól haladunk, már csak egy fül van hátra, ahol a customattribute2 értékét kellene megadnunk.
Harmadik fül: Izé. Csak úgy nem lehet megadni, előtte ki kell választani, hogy user vagy kontakt vagy group. Válasszuk először a felhasználót. Ekkor a tesztnél megjelenik a tesztkontakt és a tesztfelhasználó. A tesztcsoport nem. Oké, válasszuk a csoportot. Ekkor csak a tesztcsoport jelenik meg. Jó, akkor vegyünk fel két feltételt, legyen felhasználó is és csoport is. Ekkor nem jelenik meg semmi. Nyilván az idióta engine ‘és’ feltételt tett közéjük.
Khmm. Valami nem stimmel.
Jelöljük ki a harmadik fülnél csak a felhasználót és nézzük meg, milyen lekérdezést alkot a robot. Imhol.
(&
(&
(&
(&
(mailnickname=*)
(|(&(objectCategory=person)(objectClass=user)(|(homeMDB=*)(msExchHomeServerName=*)))
(&(objectCategory=person)(objectClass=contact))
(objectCategory=group)
)
)
)
(objectCategory=user)(extensionAttribute8=Valami*)
)
)
A valóságban nincs tördelve. Kell hozzá némi áttekintőképesség, szó se róla.
A ‘*’ az az aszteriszk, azaz jelentése: ‘bármi’. A ‘valami=*’ jelentése, hogy létezik-e egyáltalán a tulajdonság.
Tessék jobban átnézni. Where is the loony? A végén. Egyszerűen tök felesleges az (objectCategory=user) feltétel. Ez a hülye kattintógép viszont mindenképpen berakja, csak hol ‘user’, hol ‘group’ paraméterrel.
Ilyenkor vonja meg az ember a vállát. Hülyék vagytok. Majd beírom én a feltételt. Csakhogy a hülyeség ritkán áll meg félúton: a gyönyörű kattogtatógépben nincs custom fül; _nem lehet_ saját keresőfeltételt beadni. Ami már csak azért is meglepő, mert szószerint ugyanígy néz ki az AD custom query kattogtatógépe és ott meg van olyan: egyszerűen a legördülő menüben eggyel több a választható lehetőség és bejön egy üres szövegmező, ahová gépelhetsz.
Elég mélyre ástunk eddig is, itt az idő, hogy még mélyebbre hatoljunk. Nyilván ezek a lekérdezőfeltételek valahol le vannak tárolva az AD-ban is. Vegyük elő kedvenc AD matyizó svájcibicskánkat, az ADSIedit mmc snap-int. (Szintén support tools.) Nagyon remélem, hogy senkinek sem mondok azzal nagy újdonságot, hogy az Exchange organizáció összes konfigurációs beállítása az AD konfigurációs névterében van elrejtve, a Services/Exchange alatt. Nem kell sokáig túrni, hamar meglesznek a címlista objektumok is… és igen, az objektum ‘purportedsearch’ tulajdonsága rejti a keresőfeltételt. Hanyag eleganciával töröljük ki a felesleges kérdést, hajigáljunk pár percig dartsot, majd ha a replikáció megtette a dolgát, nézzük meg immár az ESM-ben a tesztcímlistát. Gyönyörű. Ott van a lekérdezésünk. Írjuk még be a description mezőbe, hogy aki a grafikus felületen módosítani meri a lekérdezést, annak letört kezét fogjuk a seggébe dugni.
Nyertünk.
Eltekintve attól az apróságtól, hogy a teszt címlista nem hajlandó megjelenni kliensoldalon. De ez apróság, összehasonlítva azzal a hátul motoszkáló rossz érzéssel, hogy ez nem frankó. Kurvára nem elegáns. Eleve fel kell tölteni az AD-t ezzel a Valami értékkel. Ha új felhasználót, kontaktot veszünk fel, tudni kell, hogy ezt az értéket is be kell írni, ha látni akarjuk a címlistában. Emberi munka. Hibalehetőség. Tré.

Ötlet2
Ha nemcsak ldp-ből nézzük meg az objektumot, hanem ADSIedit-ből is, egyszercsak szemünkbe tűnik egy canonicalName nevű tulajdonság. Hö. Mifene. Ebben pont az az útvonal van, hogy hol található az objektum. Háde a címek egy meghatározott OU-ba fognak pottyanni – tehát elegendő lenne egy ‘!canonicalName=Domain/OU/*’ feltétellel kiegészíteni a jelenlegi globális címlista lekérdezési feltételét és máris Bob lenne a bácsikánk. Nosza kimásoltam a globális címlista feltételét (még szerencse, hogy engedik használni a ctrl+C-t…), egy editorban hozzáfűztem a fenti feltételt és az egészet bevágtam ADSIedittel a tesztcímlista megfelelő tulajdonságába. Darts, teszt – és üres halmazt kaptam. Habár szeretek dartsozni, de szorított a határidő, így gyorsítottam a tesztelésen. Nem a címlistáknál vacakoltam, hanem a már korábban emlegetett AD custom search ablakban teszteltem a lekérdezést – itt egyből látom az eredményt és van beíróablak. A tesztcímlista lekérdezésével egyből hibaüzenetet dobott. Jó, hagyjuk a GAL-t. Összekattogtattam egy jó általános lekérdezést, az eredményt kimásoltam, editorban hozzátettem a szükséges feltételt és visszamásoltam a custom search mezőbe, és… nem fogadta el! Szószerint ez történt: kurzor be az ablakba, ctrl+v, egy villanás – és nem történt semmi. Nem került be a szöveg. Azannya. Biztos elrontottam valamit az editorban. Fogtam a kattogtatás adta eredményt és egyből visszamásoltam a szövegablakba. Villanás, üres ablak. Mifasz? Adjuk be cseppenként. Editorból kezdtem feltételenként visszamásolni és most már megjelentek a sorok. Szépen haladtam is, de az utolsó feltétel bemásolásakor újból jött a villanás. Bazdmeg. És akkor még messze nem adtam vissza az akkori hangulatomat. Az idióták lekorlátozták a szövegablakban a bevihető karakterek számát. Olyannyira, hogy begépeléssel nem tudom összerakni azt a lekérdezést, melyet kattogtatással igen.
Habár szó sem volt replikációról, de megint sürgős dartsozhatnékom támadt.
Jó, menjünk vissza az elejére. Tesztként beírtam a ‘!canonicalName=Domain/OU/*’ lekérdezést – és erre is hibaüzenet jött. Így már sokkal tisztább a helyzet. Valamiért ez a feltétel nem jó. Miután tíz percig vizsla szemekkel ellenőriztem betűről betűre, hogy nem gépeltem-e el valamit, elkezdtem végre gondolkodni. Hogyan is működik egy AD query? Hol keres?
Hoppá. Ez bizony nem az egész AD-t túrja át, helyette csak az index adatbázist piszkálja – azt az adatbázist, melyet a globális katalógusok kezelnek. Benne van ebben az adatbázisban a canonicalName tulajdonság?
Nézzük meg. Schema management, canonicalName – bizony, üres az összes checkbox. Hát ezért halt meg futás közben az összes lekérdezés.
Itt volt az idő konzultálni az ügyféllel. Előtte azért megkérdeztem a Microsoftot, hogy mekkora plusz terhelést fog okozni az AD-nak egy új tulajdonság felvétele a GC adatbázisba. Ugyanazt a választ kaptam, mint Arthur Dent a bulldózer előtt: “semekkorát”. Ügyfélnek elmagyaráztam a helyzetet, azt mondták, hajrá, felvehetem a tulajdonságot.
Megvártam a péntek délutánt, nekifeszültem a sémának, bekattintottam a ‘vedd fel az index adatbázisba’ checkbox-ot és a ‘replikáld a GC-k között’ checkbox-ot… majd elgyönyörködtem két hibaüzenetben, miszerint ez a tulajdonság a System Class-ba tartozik, tehát se nem indexeltethető se nem replikáltatható.
Csak.

Ötlet3
Más választási lehetőség híján maradtunk az első módszernél. Közben eszembejutott egy újabb komplikáció: kliensoldalon mindenki a globális címlistát használja; ha bevezetek egy új címlistát, akkor mindenkinél át kell állítgatni. Az ügyfél viszont határozottan irtózik a kliensoldali beavatkozásoktól.
Kellene egy újabb ötlet.
Nos, eddig is bátrak voltunk. Miért ne lehetnénk még bátrabbak? Módosítsuk a globális címlistát. A neve marad globális, de kibelezzük és az álca alatt egy nem globális címlista lenne, mely megegyezne azzal a címlistával, melyet most használnak. A tesztlistát meg átberhelnénk és az lenne a tulajdonképpeni globális címlista.
Az ötlet jó. Némi fennakadást okoz, hogy a globális címlista (GAL) nem módosítható. A grafikus felületről. De itt van a jó öreg ADSIedit, és természetesen a GAL-nak is megvan a ‘purportedsearch’ tulajdonsága. A lekérdezés kimásolása a GAL-ból, átmásolása a tesztcímlistába, kibővítése a plusz feltétellel és visszamásolása a GAL-ba alig volt öt perc.
Csak hogy töltsem a helyet, idemásolom:
(& (extensionattribute2=Valami)(mailnickname=*)
(| (&(objectCategory=person)(objectClass=user)(!(homeMDB=*))(!(msExchHomeServerName=*)))
(&(objectCategory=person)(objectClass=user)(|(homeMDB=*)(msExchHomeServerName=*)))
(&(objectCategory=person)(objectClass=contact))
(objectCategory=group)(objectCategory=publicFolder)(objectCategory=msExchDynamicDistributionList)
))
Enyhe szépséghiba, hogy mindez kliens oldalon egyelőre nem látszik.
De ráérünk, mert még fel kell tölteni az AD-t szkriptből és ez sem apró feladat. Először is figyelni kell arra, hogy a nemlétező tulajdonság és az üres tulajdonság nem ugyanaz, dacára, hogy lekérdezéskor ugyanazt a választ kapjuk az Isempty() függvénnyel. Habár van valami módszer – lekérdezve az Err értékét -, de nekem ez sohasem működött. Viszont jelen esetben igen fontos rögtön az elején különbséget tenni a két lehetőség között, ha ugyanis egy olyan objektum Exchange tulajdonságának adunk értéket, mely se nem mail-, se nem mailbox-enabled, akkor egy olyan szürke zónába léptünk, melytől minden tisztességes adminisztrátor irtózik. Meg a tisztességtelenek is. A zóna kizárólag a hülyéknek van fenntartva.
Szerencsére van egy másik tulajdonság, melynek mindig van értéke, ha az objektum mail/mailbox-enabled: ez a proxyaddresses tulajdonság. Ez gyakorlatilag egy tömb, amelyben az objektum összes e-mailcíme van felsorolva – márpedig egy darab mindenképpen van neki.
A többi már nem nagy ügy. Még arra kell figyelni, hogy a romantikus nevű MsExchHideFromAddressLists változó értéke hamis legyen – azaz az objektum ne legyen kirejtve a címlistákból.
Mehet is. De még mennyire. És de még hányszor. Eszméletlen eldugott sarkai lehetnek egy 3 fás 6 tartományos erdőnek, zegzugos OU-kal, konténerekkel – márpedig addig kell erőszakolni a szkriptet, amíg a globális címlistával megegyező számú objektumot kapunk vissza. (Igen, megírhattam volna rekurzívnak is. Későn jutott eszembe.)

De végül ez is rendbe jött. Ennek ellenére kliensoldalon semmi változás. A tesztgépen továbbra is a régi címlisták látszanak.
Itt van egy láb, kibe rúgjak? Ki mögött rejtőzködik az MSExchangeAL? A legvégén biztos a System Attendant lesz, de azért durva lenne az egész szervert restartolni egy frissítés miatt.
Miről is írtam az elején? Hogy a listatagság beleíródik az objektumba. Ez egy bulk jellegű írási művelet. Melyik komponens lát el hasonló funkciót? Igen, a Recipient Update Service, a jó öreg RUS. Haza is érkeztünk. Ugyanazt kell csinálnunk, mint amit egy új recipient policy bevezetésekor: minden tartományi RUS-ba bele kell rúgni egy jó nagyot. Figyelem: nagyot. Én úgy tapasztaltam, hogy a hivatalos véleménnyel szemben kicsi rúgásra a füle botját sem mozgatja. (Segítség. Kis rúgás: update. Nagy rúgás: rebuild.)
Egy-két óra várakozás következett, közben volt egy röpke őszülés is: ugyanis befigyelt egy jó hosszú periódus, amikor üres volt a teljes globális címlista. Roppant lehangoló látvány. Szerencsére nem sokan látták, ez ugyanis már péntek éjfél körül volt. Hogy a modemesek mennyit fognak átkozódni, amíg az új offline Address Book-ok leérnek hozzájuk, azt nem tudom. Remélem, nem találnak meg.

Tulajdonképpen most már készen is vagyunk, boríthatják a címeket.
És ha már itt lesznek, át kell túrnom alaposan a tulajdonságaikat, hátha találok valami különbséget, ami alapján automatizálható lehet a listázás.

Mentális erő

A napokban kihelyezett okítás van nálunk, cluster témakörben. Nyilván az egészet nem fogom beírni, de a tegnapi napból egy levezetés megragadta a fantáziámat.
Előre jelzem, hogy erősen egyszerűsíteni fogok. Most egy konkrét erőforrásról lesz szó. Feltételezem, hogy ez egy fontos erőforrás, melynek ledőlése átmozgatja az erőforrás csoportot a másik node-ra – azaz failover következik be. Az erőforrás tulajdonságlapjának Advanced fülén lehet beállítani az advanced paramétereket. Ilyeneket:

  • Threshold / Period [sec]: a period időtartam alatt az erőforrás hányszor halhat meg, ahhoz, hogy kikényszerítsen egy node váltást.
  • Pending time out [sec]: mennyi ideig várjunk az erőforrásra ahhoz, hogy döglöttnek nyilvánítsuk.

Ránézésre semmi különös. De ha jobban belegondolunk, mégis van itt egy kis rafinéria.
Mondjuk legyen az erőforrás egy service. A küszöbérték legyen 3, a period 900 sec, a timeout 180 sec. (Ezek a default értékek.) A szerencsétlen szolgáltatás beragad – azaz az ‘Is alive’ hibásnak jelzi. Kivárják a 180 másodpercet, küszöbérték számláló 1-re áll. Megpróbálják újraindítani a szolgáltatást, de az ostoba vigyorral a képén továbbra is csak áll, újabb 180 sec múlva lép a küszöbérték kettőre és még 3 perc kell ahhoz, hogy az erőforráscsoport áttegye a seggét a másik node-ra. Átteszi? Igen, mert összesen 3*180 sec telt el, azaz benne vagyunk a 900 sec perióduson belül.
Igenám, de mi van akkor, ha az adminisztrátor azt mondja, hogy ez egy Exchange szolgáltatás, itt a timeout érték igen magas: vegyük fel 350 másodpercre. Tessék végiggondolni.
Pusztán szellemi erővel sikerült hazavágnunk a clustert, legalábbis a szolgáltatásra nézve. A hiba biztos megállapítása 1050 sec lesz, miközben az erőforráscsoport csak akkor fog vándorolni, ha a hibára jellemző mintázat 900 másodpercen belül történik meg. Ez a cluster a büdös életben nem fog clusztogni. (Mellékes folyomány, hogy emiatt nem lehet Exchange szerveren kiemelkedően magas rendelkezésre állást bevállalni – hiszen egy beragadt IS service biztos detektálása 15-20 percet is igénybe vehet.)
És a minta nem egyedi. Van egy másik beállító panel. Ez arra vonatkozik, hogy ha egy bizonyos intervallumon belül (period) volt x darab failover, akkor hagyja abba, mert ez az erőforráscsoport már a boldog vadászmezőkön nyargal és nem illik rugdosni a döglött oroszlánt. Namost, minden failovernek van egy jellemző ideje: ki kell nyírni a döglött erőforrásokat (szolgáltatás, egyebek) és el kell indítani a másik node-on. Exchange esetén ez megint nem kis idő. Ugyanaz a hibalehetőség: ha az x, megszorozva a failover idejével, több, mint a period érték, akkor ez a cluster még a harmadik világháború után is failoverezni fog az embernélküli sártekén.
Szép, mi? Ismerek egy csomó Microsoft terméket, de egyiknél sem emlékszem olyan GUI beállítási lehetőségre, amelyikkel ki lehet nyírni magát a terméket. (Uninstall nem játszik.)
Megint valami, amihez kevés a next-next-finish admin hozzáállás.

Link state – hova dugjam?

Life long learning. Ez már csak egy ilyen szakma. Szerencsére.
Jó egy hónapja álltam rá arra, hogy rendszeresen tanulok. A hangsúly a rendszerességen van – tanulni eddig is kellett.
A stratégia a következő: reggel tea felrak, elkortyol, internet átfut (email/feed/link). Utána, amennyiben nyugis nap van, ebédig tanulok. Ha zűrös, akkor csak egy órát. Outlookba jegyzetelek, a végén a levelet hazaküldöm.
Napközben az anyag ülepedik… a vérnyomás meg emelkedik… de ez a természetes.
Este rászánok egy órát és a délelőtt átvett anyagból csinálok egy írott jegyzetet. (Nekem ez jön be – leírni kézzel a vázlatot. Egyetemi vizsgára készüléskor a konyhaasztalunkra készítettem apró betűkkel jegyzeteket. A vizsga előtti napon már úgy nézett ki az asztal, mint egy burda szabásminta: vázlatpontok, nyúlfülek, nyilak. A szép nagy asztalon át lehetett tekinteni az egész tantárgy kapcsolatrendszerét – feltéve, ha a takarítónő nem törölte le közben. De ez igen erősen meg lett neki tiltva.)
Honnan jön a témaválasztás? Több méter könyv gyűlt fel a szekrényemben, ezekkel szép módszeresen haladok. De magunk között szólva, jobban szeretek csapongani – ha a reggeli feed olvasás során találok valamit, szívesen indulok el inkább azon a nyomon.
A napokban futottam rá egy témára és a linkek olyan oldalhoz vezettek, melyet véleményem szerint nem jegyzetelni érdemes, hanem értelmezni, összekapni – lefordítani. És persze elkalandozni. De ha ilyet csinálok, miért ne tegyem a blogban?
Ez merőben újdonság lesz, eddig ugyanis IT témakörben csak szívásokról irkáltam. Dehát mindig azt sulykolják, legyünk proaktívak… nosza.

A téma: routolás Exchange organizációban, azon belül is a link state table környéki problémák kezelése.

Kályha… ahonnan elindulunk: routing group (RG).
Azt gondolom mindenki tudja, hogy az Active Directory leánykori neve Exchange 5.x volt. Itt kisérletezték ki a fiúk a később nagyobb léptékben alkalmazott módszereket. Az összefonódás később is jól látható, az Exchange 200x úgy tapad rá az AD-re mint a kígyók Laookon családjára az ismert szoborcsoporton. Rengeteg átfedés van közöttük és akad analógia is szépen. Egyik ilyen a routing group – site analógia. Nagyjából ugyanaz létezésük oka: információs folyam terelgetése. Site esetén ez a replikáció, routing group esetén pedig a levéltovábbítás. Mindkettőre igaz, hogy egy egységen belül nagysebességű kapcsolattal rendelkező gépeknek illik lenniük – póriasan szólva, az a jó, ha egymásba ér a farkuk.

Kitérő: Azért nem csak a kapcsolat sebessége szabja meg a csoportosítást. Ha mixed módú organizációnk van, és szeretnénk több administrative group-ot is bevezetni, szomorúan fogjuk látni, hogy mindegyiknek külön RG kell.

A routing group létezésének értelme: csoporton belül a szerverek orrba-szájba kommunikálnak egymással (ugye, a nagy sávszélesség) – csoporton kívül viszont adminisztrátor által szabályozott módon, konnektorok segítségével. (Imádom ezt a szót: konnektor… konnektor. Azannya. Plasztikus. Fogom az egyik végét és feldugom az Exchange szerverbe. A másik végét meglengetem a fejem fölött és beleállítom valamibe, legyen az bármilyen alkalmazás. És ezt tessék szószerint érteni: az Exchange mind a külvilággal, mind saját magával legnagyobbrészt különböző konnektorokon keresztül kommunikál.)

No, tehát vannak routing groupok, melyeket konnektorok kötnek össze. Nincs megkötve, mennyi; nincs megkötve, hány bridgehead szerver lehet. Szabad a pálya. Ellenben minden routing groupban lennie kell egy routing group masternek. Ő az óvónéni. Ő tud mindenkiről mindent; ő terelgeti a leveleket konnektorról konnektorra (egy kis dombra lecsücsülünk, csüccs); ő rak rendet, ha kitör a balhé. Nem fontos, hogy ő legyen a bridgehead – de fontos, hogy tudjon mindenről.
Mi is ez a minden? Nos, a konnektoroknak állapotaik vannak: ezeket hívjuk link state-nek. És van egy táblázat, amelyikben a routing groupok összes link state információja megtalálható: ez a link state table.

Hosszú, de legalább körülményes bevezetőm végén eljutottam végre ahhoz a vadhoz, melynek természete képezi leginkább ezen cikk mondanivalóját. Huh.

Tudjuk, hogy az optimális route útvonalhoz az RG master a következő információkat használja fel: a konnektor költsége, az üzenet típusa, a különböző tiltások. Logikus, hogy ezeknek szintén bent kell lennie a link state táblában – amellett, hogy a konnektor éppen Up vagy Down.
Ha valaki el akar gyönyörködni egy ilyen táblázatban, javaslom, próbálja ki a winroute programot. Aki nem akar elgyönyörködni benne, az ráfaragott, mert a leírt módszerek közül elég sokban kell használni a programot – és higyjétek el, jobb gyönyörködve, jó hangulatban bogarászni, mint fásultan.

Felmerülhet a kérdés, hogy honnan fog tudni mindenről az RG master? Természetesen a member szerverek folyamatosan tömik feljelentésekkel.

  • A member szerveren lévő levélkezelő mechanizmus, az ún Advanced Queue (önállóan megérne egy cikket) rányalja a kimenő levélre a legközelebbi hop címét. Az infót a lokális link state táblából veszi.
  • A levél visszapattan.
  • A member szerver vár max. 10 percet majd feljelenti a konnektort. Jól.
  • Az RG master down-ba teszi a konnektort a központi link state táblában majd szétküldi azt a member szervereknek.
  • De a member szerverek nem nyugszanak. Sutyiban folyamatosan pingetik a ledőlt konnektort.
  • Tegyük fel, hogy a konnektor visszatér a harcmezőre. A member szerverek, mivel pingetik, észreveszik, boldogan üdvözlik és közlik az örömhírt az RG masterrel.
  • Az RG master blazírtan újra módosítja a link state táblát és ismét szétküldi.

Az egész kommunikáció a 691-es TCP porton történik. Emellett játszik még a 25-ös is – de ez az Exchange-ben mindenhol játszik, lévén ez az SMTP portja. A routing információk küldözgetéséért a Routing Engine Service, röviden RESrvc felel. (Gyakorlati jótanács: ha újra kell indítani, akkor praktikusabb az IISadmin szervízt piszkálni – ez ugyanis újraindítja az SMTP szolgáltatást is, praktikus sorrendben.)

Mi van akkor, ha pont az RG master dől ki a sorból? Értelemszerűen minden member szerver a lokális link state táblát használja, függetlenül attól, milyen változások történnek a nagyvilágban. Aztán egyszer csak visszajön az RG master – akár megjavítják, akár újat húznak fel, akár kinevezik valamelyiket. (System manager, RG, Members, Server, Set as master) Az új főnök körbenéz a nagyvilágban, gyorsan begyűjti a lokális link state táblákat, lekezeli a feljelentéseket, szétküldi a jó táblákat… röviden szólva asztalra csap és gatyába rázza a macska nélkül cincogó egereket. (Gyönyörű.)

Láthatjuk tehát, hogyan működik egy egészséges rendszer. (Ez olyan, mint az ideális – nem létezik. De állandó cél.) A működés ismerete pedig már fél siker a hibajavításhoz.
Milyen eszközöket fogunk használni:

  • Winroute segédprogram. (Igen, mondtam, hogy meg kell szeretni.)
  • Felemelt logolás.
  • Józan ész. (Valahonnan időben szerezzük be.)

A logolást az Exchange System Managerben lehet állítani, a megfelelő objektumokon. Legalábbis a tankönyvek szerint. Érdekes módon, amikor nagy szar van, mindig bele kell turkálni a registrybe és még feljebb csavarni a logolást. (Az ESM csak 5-ös szintig engedi állítani – pedig a legerősebb a 7-es szint.)
A felcsavarás a következőképpen történik: a registry HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services ágában megkeressük a minket érintő szolgáltatást, azon belül leásunk a Diagnostic menübe, megkeressük a minket érintő eseménycsoportot és 7-re állítjuk az értékét.
Arra azért készüljünk fel, hogy ilyenkor olyan 70 szerzetesnyi sebességel íródik a kódex log.

Nem beszéltem még egy érdekességről. Ha elindítjuk a Winroute programot, láthatjuk, hogy minden routing groupnak verziószáma van, [major.minor.user] formátumban.
Meglehetősen magáért beszélők a nevek, de érdemes egy-két apróságot megemlíteni róluk.
Átfogóan nagy – major – változás viszonylag ritkán történik. Ez alatt leginkább olyan változásokat kell érteni, amikor az AD nyúlkál bele az Exchange lelkivilágába. (Megjegyzés: ha a major index 0, az azt jelenti, hogy nincs link state táblás ökörködés -> azaz vagy csak egy routing group van az organizációban, vagy az illető routing group Exchange5.5 alapú – a jó öreg GWART.)
Közepes – minor – változás általában a konnektorokhoz kötődő változást jelent.
A legutolsó szám – user – változását mindenféle szutyok apróságok okozhatják: WMI piszkálta meg az RG mastert, megváltozott a routing group tagsága, át lett nevezve a routing group, elköhögte magát a szerverszoba egere, stb.

És most akkor lássunk konkrét hibajelenségeket és azok lekezeléseit:

1. A member szerver nem látja mesterét

Bizony, ez baj. A fentiek alapján sejthetjük, hogy ilyenkor a lokális link state tábla dolgozik, valamilyen őskori adatokkal.
A jelenséget könnyen felismerhetjük, elég a Winroute-ban a piros X-ekre koncentrálnunk. Ott találjuk, közvetlenül a szerver(ek) neve(i) mellett.
Mik okozhatják? Csupa triviális dolgok:

  • A Routing Engine Service nem fut valamelyik érintett gépen. Vagy fut, csak nem jól.
  • Egy gonosz firewall blokkolja a 691-es portot. Ezt telnettel tudjuk ellenőrizni.
    Emellett konkrétan azt is meg tudjuk nézni, hogy mi a helyzet a 691-es porttal a szervereken. A ‘netstat -a -n’ parancs megmutatja, mely portjaink nyitottak és merrefelé. Member szerver esetén látnunk kell egy kapcsolatot az RG master felé – RG master esetén látnunk kell egy-egy kapcsolatot minden member szerver felé. (Pontosabban, nem csak egyet, két szerver több szálon is kapcsolódhat.)
  • Okozhat problémát a computer felhasználó hibás autentikációja is. (Logikus – ilyenkor a számítógép kiesik a haveri körből.) Érdemes átnézni az eventlogot. Ugyanitt fogjuk megtalálni a transzport hibára utaló jeleket is. (Event kód: 961/962)
  • Elveszhet a bűnös szerver ‘Send as’ jogosultsága. (Elég cifra jogosultsági rendszerben vannak a szerverek; a domainprep létrehoz nekik néhány csoportot és ezekre beállít egy default jogosultságot. Elég könnyű ezt a rendszert felrúgni – bőven elég, ha átrakjuk a csoportokat egy másik OU-ba. Tesztelve.)
    A nyomozáshoz a Microsoft a Regtrace programot ajánlja. Én is ezt tenném a helyükben, tekintve, hogy ez egy nagyon praktikus program – nekik. Mezei halandó sajnos nem tud vele mit kezdeni. (Szépen le van írva, hogyan kell elindítani, hogyan kell paraméterezni, egyáltalán hogyan monitorozza a program a történéseket, miközben reprodukáljuk a hibát, szépen le van az is írva, hol találjuk az eredményként kapott bináris fájlt és hogyan kell azt elküldeni a PSS-nek visszafejtés céljából.)
  • Lehet, hogy a szerver rossz nevet használ a bemutatkozáskor. Elismerem, ez annyira azért nem triviális ok. A szerverek az ún. ServerPrincipalName (SPN) értékkel azonosítják magukat a routing groupban. Ez az érték a szerver Network Adress attribútumának ncacn_ip_tcp változójában tárolódik, megtekinteni illetve módosítani ADSIEdit-tel vagy LDP-vel lehet. Kicsit háklis banda ez a routing group, csak akkor fogadják el a bemutatkozást, ha FQDN formájú a név. Netbios név, IP cím nem megfelelő. Olyan ez, mint a nyakkendő az elit mulatókba.
  • Az, hogy a többiek nem ismerik fel a bűnös szervert, sokféle okból következhet. Lehet jogosultsági hiba, lehet bemutatkozási hiba – és lehet Kerberos autentikációs hiba, mondjuk egy lejárt computer jelszó miatt. Ekkor célszerű az NLTEST segédprogit használni. (Ez igaz általánosan is, minden olyan esetben, amikor netlogon hibára gyanakszunk.) A program használatáról van egy jó leírás. Röviden annyi, hogy el kell indítani a megfelelő paraméterrel – mely paraméterek egy szép nagy táblázatban találhatók és arra vonatkoznak, hogy mire vagyunk kíváncsiak – majd újraindítjuk a Netlogon szolgáltatást és megnézzük, mi került a %windir%\debug\netlogon.log fájlba.
  • Természetesen DNS. Ezt talán mondanom sem kellett volna. Ha a szerverek eltérő tartományokban vannak, meg kell nézni, rendesen megy-e a névfeloldás. A magam részéről megnézném akkor is, ha azonos tartományban vannak. Fontos, hogy a virtuális SMTP szerveren található FQDN megegyezzen a DNS-beli FQDN-nel.
  • Legvégül érdemes elgondolkodni, nem vezettünk-e be mostanában valami elkefélt GPO-t, mely esetleg belepiszkálhatott a korábban részletezett folyamatba.

2. RG mesterek háborúja

Megjelenik a sötét oldal.
Egy routing groupban az az RG master, akiről a szerverek fele+1 szerver azt állítja. Ezt a member szerverek ún. link state attach információk küldözgetésével beszélik meg. Értelemszerűen egy szervernél ő maga lesz a főnök – azaz alaphelyzetben mindig az elsőnek telepített szerver az RG master. Az is marad, amíg az adminisztrátor másképp nem rendelkezik.
Mikor tör ki a háború?

  • Például akkor, ha az adminisztrátor úgy léptet elő RG mesterré egy gépet, hogy az öreg mestert nem lépteti vissza.
  • Az egyik member szerver megőrül és hamis információkat kezd terjeszteni.
  • Hálózati hibák következtében nem érnek célba a link state attach információk, miközben főnökváltás történt.

Mi lehet a teendő? Először is megvizsgáljuk a hálózatot, mennyire atombiztos. Elérhetők-e azok a bizonyos 691/25 portok? Megy-e az AD replikáció? Nem rágta-e el a patkány a vezetéket?
Másrészt magunkba szállunk és végiggondoljuk, nem töröltük-e pusztán szórakozottságból azt az Exchange szervert, amelyik eddig az RG master volt? Esetleg nem léptettünk-e elő egyet úgy, hogy még a régi is megvan?
Ha ez utóbbi esetek egyike történt, akkor az ADSIEdit vagy LDP programokkal gyorsan korrigálhatunk, az üzemzavart meg ráfoghatjuk a napfolt tevékenységre. (Itt található egy írás, hogyan állítható vissza egy véletlenül kigyapált routing group. Azért ne próbáljátok ki éles rendszeren.)

3. Van olyan routing group, amelyik nincs

Felmerülhet a kérdés, hogy ha nincs, akkor hogyan látjuk. Nos, például a Winroute segédprogramból. Mutatja, hogy itt kérem van egy routing group, de a fene se tudja, hogyan hívják és mi ez.
Mondhatnánk, hogy a francot sem érdekli, nem kér enni. Csakhogy ott van. Érvényes routing információkkal. Hogy neki vannak konnektorai. Balszerencsés esetben egészen olcsók – és ilyenkor ebbe az irányba próbálnak menni a levelek. Mely irány nem létezik.
Nyilván törölni kell… de hogyan? Hiszen nem létezik!
Farkába harapott a kígyó.
Ravasz trükkök vannak a rendrakásra.

  • A legelső, hogy megnézzük, olyan felhasználóval vagyunk-e belépve, akinek legalább olvasási jogai vannak az AD konfigurációs névterében? Ha olyan a felhasználó, be tudott-e rendesen lépni? Ha belépett, eléri-e a konfigurációs névteret? Tudom, triviális… de egy autentikációs hiba miatt egyszer kis híján megőrültem egy hasonló szituációban.
    Általában is az egyik legfontosabb hibafelderítési lépés meggyőzödni, hogy egyáltalán fennáll-e a hiba… nem az észleléssel van-e inkább gond?
  • Nos, benne vagyunk az Atyauristens csoportban, közvetlenül az RG master gépen futtatjuk a Winroute-ot, mégis látszik, aminek nem lenne szabad látszódnia. Erre mondják azt városiasan, hogy kaki van a ventillátorban. (A póriast most inkább hagyjuk.)
    A helyzet az, hogy valószínűleg egy törölt routing group-ra vonatkozó bejegyzés beragadt a link state táblába – és a RESvc képtelen kitörölni. Az egyetlen megoldás a tabula rasa – kezdjünk mindent előlröl. Választhatjuk azt is, hogy újratelepítjük az összes Exchange szervert (nemröhög – a Microsoft eszköztárában szerepel ez a lehetőség is), de szerencsére van egy egyszerűbb megoldás is: a bűvös újraindítás. Némi kényelmetlenséget okoz, hogy az organizáció összes szerverét kell egyszerre újraindítani, úgy, hogy először mindenhol az RG master gépek álljanak fel. Kényelmetlen, de ha worldwide organizációnk van, akkor itt a lehetőség néhány potya repülőjegyre.
  • Az előbb hazudtam, de csak a drámai hatás kedvéért. Van egy másik lehetőség is: felhergelhetjük a REMonitor segédprogramot, hogy injection módban működjön. Erről igen jó cikket írt az Exchange gárda, én itt csak összefoglalom.
    Először a rossz hír: a program nem tölthető le szabadon, a Support-tól kell igényelni. Ha megvan, akkor első lépésben be kell állítani a futtatásához szükséges jogosultságot. A fiúk elég sokat vacakolnak ezzel, végül arra jutnak, hogy a legegyszerűbb, ha trükkös módon a local system account nevében futtatjuk. Ez – gondolom – ismerős. Beidőzítünk egy command prompt-ot és az a local system account nevében fog elindulni. Nos, itt csak annyi a probléma, hogy távolról ütemezve a taszkot, az a konzolon fog promptot adni. (Windows2003 esetén no problemo, az ‘mstsc /console’ kihúz a bajból.) Azért nálunk valamivel mások a viszonyok… feltételezem, minden Exchange adminisztrátor azzal kezdte a tevékenységét, hogy az Atyauristen felhasználónak visszaadta a “Send as”/”Receive as” jogokat – ez meg éppen elég a program futtatásához. (Jaj, ne üssenek… nem mondtam semmit…micsoda?… három év vasban?…)
    Ha rendeztük a jogosultsági matyit, akkor végre elkezdhetünk dolgozni. Bemásoljuk a progit a bin könyvtárba, elindítjuk. Kedvesen közli, hogy mely fázisnál jár, mit talált… majd vége.
    Mit is csinált?

    • Ha talált beazonosíthatatlan routing group-ot, törölte belőle a szerverek és konnektorok bejegyzéseit.
    • A routing group-hoz tartozó névterek címeibe belebiggyesztette a ‘deleted’ kifejezést.
    • A major indexet megnövelte eggyel.

    Ezzel sikeresen elérte, hogy egyrészt efelé a routing group felé soha a büdös életben nem fog levél kóvályogni, másrészt a link state table is lecsökkent valamelyest – ami nem hátrány nagyméretű organizációk esetében.
    Amit viszont nem ért el, az az, hogy nem tűnik el a rosszindulatú routing group bejegyzés a táblából. Sajnálatosan ezt csak az újraindításos módszer biztosítja.

4. Egy ledőlt konnektor üdének, frissnek látszik

Ilyesmi is előfordulhat. Mondanom sem kell, elég ciki, amikor szembesülünk a ténnyel, megtekintve a Winroute listáját.
Pedig simán előfordulhat.

  • Olyan konnektorunk van, amelyiknél bizonytalan a hídfőállás létezése. Akkor fordulhat ilyesmi elő, ha a konnektorunk pl. DNS-t használ ahhoz, hogy a következő hop-ot meghatározza. Tipikus példa erre egy SMTP konnektor, amelyik nem smarthost-hoz kapcsolódik.

    Megjegyzés: Amikor azt írom, hogy SMTP konnektor, mindig kicsit zavarban vagyok – mert eszembe jut, mennyit agyaltam anno, hogy mi is az a virtuális SMTP szerver és mi is az az SMTP konnektor és tulajdonképpen milyen viszonyban is vannak ezek? Fóti Marci gondolatát beépítve imhol egy plasztikus kép: van az SMTP szolgáltatás, mely tetszőleges számú virtuális SMTP szervert képes üzemeltetni. Az SMTP konnektor pedig tulajdonképpen a virtuális szerverekre vonatkozó SMTP policy.

    De akkor is előfordulhat ez a jelenség, ha az ún Routing Group konnektornál (RGC) a forrás bridgehead rovatba az <any> opciót hagyjuk bent. (Nem akarok most kitérni az egyes konnektor típusokra, mert a cikk lassan kezd fárasztó lenni. Nekem legalábbis meglehetősen.)

  • Smart host esetén sem vagyunk teljesen biztonságban, ha nemrég állítottuk át a távoli bridgehead szerver paramétert.
  • A konnektorunk Exchange5.5 verziójú konnektor vagy a konnektor egyik hídfőállása 5.5-ös szerver. Már tudjuk, ekkor nem játszik a link state table.

5. A konnektor bungee-jumping-ot játszik

Azaz meglehetősen nagy frekvenciával hol ledől (down), hol feláll (up). Lehet, hogy ez egy kellemes szórakozás a konnektor számára, de elég sokba kerül az Exchange rendszernek. Ugyanis a konnektor minden egyes állapotváltása bősz kommunikációt indít el a member szerverek és az RG master között, mire berendezik a megváltozott állapotnak megfelelő link state táblát. Aztán mire befejezik, az a hülye konnektor megint ugrik egyet.
A szóbajöhető okok:

  • Zavar az erőben, a network hülyéskedik. Netmon, vagy Ethereal… izé Packetyzer. Kinek melyik a szimpatikusabb.
  • A konnektorok alatt dübörgő protokoll bolondul meg. Összeakadnak az X.400 protokoll rétegei. Egymásba gubancolódnak az SMTP protokoll alsóbb rétegeiben lévő lábai. A Microsoft szerint ez leginkább a külső fejlesztésű implementációknál fordul elő. Naná.
    A megoldás ebben az esetben is Netmon és barátai.

Illetve létezik egy átmeneti megoldás, úgynevezett körbedolgozás. Van egy patch… mely valamit csinál. Sajnos, hogy mit, az nem derül ki. Csak az, hogy ilyen esetekben tegyük fel.
Pontosabban, eredetileg arra találták ki, hogy amikor Exchange5.5-ről frissítettünk Exchange2000-re és a nagyméretű rendszerinformációs forgalom (ORG_INFO) megakadályozza a levélküldést a lassú vonalon, akkor toljuk a képébe a foltot. Feltételezem, valahogy cseppekben adagolja a változásokat.
Élesebb szemű olvasók valószínűleg észrevehették, hogy itt nem ez a szituáció forog fenn. De ez egy remek folt, most is használhatjuk, csak bele kell túrni egy kicsit a registry-be. (Már vártam.) A HKLM\SYSTEM\CurrentControlSet\Services\RESvc\Parameters alatt kell létrehozni egy AttachedTimeout nevű dword kulcsot, majd értékének beírni egy szimpatikus számot 1 és 604800 között. Nem mondhatjuk, hogy nem kaptunk elég teret fantáziánk kibontakoztatásához.

Nos, a végére értem.
Akit ennél is mélyebben érdekelnek a routolási furfangok, itt talál egy remek letölthető könyvet a témáról.

REMonitor

Egy újabb rémálommal kevesebb.
Emlékszem, amikor először találkoztam ilyesmivel, nem hittem a fülemnek.
Egy nagyobb migráció után Exchange routing group-okkal zsonglőrködtem egy meglehetősen nagy organizációban. A végén minden beállt abba az állapotba, amilyenben lennie kellett. Szerintem.
Csak éppen nem tűnt el egy kitörölt routing group – emiatt a levelek véletlenszerűen félrementek. Jó lett volna ténylegesen is megszabadulni a rossz routing group-tól… de még flex-szel sem tudtam eltávolítani. Egy idő után feladtam, call PSS. Azt mondták, igen, elő szokott ilyesmi fordulni, a routing információk cache-ben vannak és néha beragad valami szemét. Ki kell üríteni a cache-t.
– Oké – mondtam – csapjunk bele… hogyan kell?
– Nagyon egyszerű – mondták – az összes szervert le kell állítani egy időben.
– A routing groupban?
– Nem. Az egész organizációban.
Ekkor ültem seggre. Nem kis munka volt megszervezni, hogy minden helyszínen legyen egy ember, aki adott jelre (mobiltelefon) lekapcsolja a szervereket majd adott másik jelre visszakapcsolja. Távoli újraindításról szó sem lehetett, mert addig mindegyik gépnek kikapcsolva kellett lennie, amíg a routing master Exchange szerver fel nem állt.
Viszont ettől tényleg megjavult a levelezés.
Azért úgy belegondoltam, hogy mondjuk egy multicégnél, ahol garmadával vannak szerverek különböző kontinenseken, mekkora meló lehet egy ilyen akciót megszervezni.
Valószínűleg belegondolt a Microsoft is, mert kihoztak végre egy eszközt, mely kezeli ezt a problémát. Az a neve, hogy Routing Engine Monitor (REMonitor) és az Exchange Team szépen le is írja, hogyan kell kezelni. A logika azt mondatja velem, hogy nagyon jó eszköznek kell lennie, ha ennyi időbe tellett a kifejlesztése.

A GC sem mindenható?

Őszintén szólva, még mindig tátva van a szám. Ettől a cikktől maradt úgy… pontosabban egy új, a GC-kre vonatkozó információtól.
A cikk egyébként több okból is nagyon jó. Meg lehet pl. tanulni belőle, hogyan tudom gyorsan megállapítani, mely GC-ket lát az Exchange szerver. (Pontosabban a DSACCESS szolgáltatása, mely a GC-XCH kapcsolatért felel.) Élvezetes a gondolatmenet, ahogy Jasper felgöngyölte a problémát. És megtudhatjuk, hogy megint a Public Folderek a bűnösek. És hogy a GC-k sem tudnak mindent.
Számomra ez utóbbi volt az igazán megdöbbentő:

It turns out that Exchange does not always use the local GCs. For certain specific security related user attributes like tokenGroups and tokengroupsGlobalandUniversal (used to determine what security groups a user is a member of and therefore what permissions s/he has to secure resources such as public folders). Exchange MUST query a DC that is authoritative for the user’s home domain, which will likely be an out-of-site DC—in this case it happened to be a DC in Australia. This behavior was introduced around the Exchange 2000 SP2 time frame to address an issue where users from remote domains (sibling or parent) were denied access to public folders even when the security groups they were in should have allowed them access. Pre-SP2 we had made the false assumption (in the product) that a local GC can service ALL queries that Exchange issues. A local GC can (and should) service MOST queries in a well designed multi-site AD environment.

Eltekintve attól, hogy erősen hiányzik egy ige a második mondatból, kihámozható, hogy Jasper szerint a GC adatbázisok nem tartalmazzák azokat az információkat, hogy a felhasználók mely biztonsági csoportoknak a tagjai. Ez alapjaiban rendítette meg az elképzelésemet a GC-k működéséről. De tényleg. Hiszen pont azért találták ki, hogy gyorsan, mindenféle DC abuzálás nélkül el lehessen dönteni, hogy Géza hozzáfér-e egy erőforráshoz, vagy sem?
A többi már csak hab a tortán; hogy Exchange SP2 előtt ilyenkor meghalt a PF elérés, SP2 után viszont megpróbálja a világ másik végén lévő helyi GC-t használni. Aztán van amikor ezzel több kárt okoz, mint hasznot.