A Blackberry szerver telepítő kézikönyvéből való a részlet:
1. On the installation CD open the …. file.
2. In the config section add the folloving lines:
…
…
3. Save and close the file.
Aha. Akárhogy is néztem a csomagot, vésőt nem adtak mellé.
Exchange, Active Directory, Windows server... és ami még belefér
Lehet, hogy találkoztál már olyannal, hogy belefutsz egy problémába, hosszas nyomozás után kideríted, hogy emögött az áll, hogy néhány erős felhasználónál elvesztek bizonyos jogosultságok. Beállítod, probléma eltűnik, hátradőlsz, ajnározod magad. Egészen 61,5 percig, amikor a probléma újból előjön.
Tavaly tavasszal találkoztam ezzel először Exchange telepítés közben. Forestprep, domainprep megvolt valamikor, de az install ellszállt. A domainprep újbóli lefuttatása után végigment a telepítés, de amikor később újra elindítottam, hogy megnézzek valamit, megint kardjába dőlt.
A bűnös az AdminSDHolder. Ennek az agyába be van égetve néhány kulcsszereplő jogosultsága és rendszeresen csekkolja az Active Directoryt. Ha a neki megadottól eltérő jogosultságokat talál, akkor felsikít, előrántja a baltát és visszafaragja az eredeti jogosultságokat.
Hogyan lehet ezt a mániákus parkőrt meggyőzni?
Úgy van, az nyert, aki arra tippelt, hogy registry buherával.
Indulásnak itt egy másik KB cikk, a többi nyomozást rátok bízom.
Egy nyers szervert kellett átadnunk péntek reggelre. Kollégák felhúzták, de csütörtökön jelezték, hogy nem megy a windows update. Elindítás után feljött egy nyomógombos oldal és bármelyik gombra nyomtak, a 0×80244021 kódú hibát kapták. Böngészés, knowledge base, a KB842773 cikk pont erről szól. Oké, ISA2004 szerveren beállítottam, hogy a konkrét gép IP alapján is kimehessen. De a windowsupdate megint elszállt hibaüzenettel. Nekiálltam kuruzsolni (IE6 Sp1 telepítés, ActiveX engedélyezések, trusted site-ok feltöltése, automatic update beállítása, szervízek automatára állítása, egy csomó újraindítás, stb…) – és egyszer csak észrevettem, hogy megváltozott a hibakód: 0×8024402F. (Ha agyonüttök sem tudom, melyik lépés után változott meg.)
Újabb guglizás, de semmi értelmeset nem találtam. Aztán valahonnan a régmúltból előjött, hogy egyszer már szívtam ilyennel és akkor a BITS2.0 telepítése oldotta meg a problémát. Nosza, töltsük le: KB842773. (Genuine check, offkórsz.) Ez egyben letölti a Winhttp5.1-et is, így egyet kér, kettőt kap a tisztelt admin. Természetesen telepítés után újraindítás – és a gép elment kávézni. Pingre válaszolt, de máshogy nem lehetett elérni. Jó egy órába került, mire találtunk embert a Dataplex környékén, aki távvezérléssel (telefon) belerúgott a gépbe.
Akkor windowsupdate megint. Azt mondta, most még telepíteni szeretné a legújabb windows installert is. Oké, tedd azt. De nem tette, hibaüzenettel elszállt. Hát vécére is én vigyelek ki? – morogtam, és letöltöttem a windows installert is. (KB893803; genuine, naná.) És már el is jutottam odáig, hogy válogathatok a foltok közül. Király.
Csak éppen nem jött le semmi, az összes letöltés failed-re futott. (Hibakód:0×8024401B.) Elmegy ez egyáltalán a proxy felé? Az ősködből előjött egy proxycfg.exe segédprogram emléke. A Winhttp ugyanis egy karakán egyéniség, szarik az IE beállításaira – neki külön beállítások kellenek; a BITS pedig ezekből dolgozik. Command prompt, proxycfg, ismeretlen parancs. Mi is az oprencer? Windows 2000 szerver sp4. Hát… Na, mindegy, töltsük le. Nem lehet; kérheted és majd odaadják. De már fél nyolc van és nekem holnap reggelre át kell adnom ezt a cuccot. Végülis… ez egy registry érték, be lehet ezt gépelni direktben is. HKLM / Software / Microsoft / Windows / Currentversion /Internet Settings / Connections, itt van egy kulcs: Winhttpsettings. Sajnos bináris típusú, a fene tudja, mi a jó értéke.
Utánaolvastam, egy helyen azt írták, hogy a Winhttp5.1-hez másik proxycfg.exe kell, az amelyik az XP Sp2-ben jelent meg. Nosza, kerestem egy sp2-es XP-t majd felmásoltam a szerverre a segédprogramot. És működött. Proxycfg -u; ezzel lehet elérni azt, hogy Winhttp uraság ugyanazokat a proxybeállításokat használja, mint az IE. Csakhogy így sem működött az update. Proxycfg -d; visszaállás.
Legyünk tudományosak, vegyük elő a netmont. Röpke kukucska – és továbbra is sűrű sötét a homály. A windowsupdate teljesen jó irányba forgalmazott teljesen jónak tűnő http forgalmat. Nézzük az ISA szervert, az mit rögzített. Hoppá, itt van egy HEAD http kérés, mely deny-re futott. Lehet, hogy nincs engedélyezve a metódus a HTTP proxyban? Engedélyezzük. De… nincs filter menüpont a jobbklattyban és szürke a gomb a panelen… miafene…?! Oké, tudom, hogy az add-in-ok között van egy http filter ki/bekapcsolási lehetőség; és ha kikapcsolom, akkor ezt a jelenséget kapom. Csakhogy most nincs kikapcsolva. A legtudományosabb windows módszert választottam, néhányszor ki/bekapcsoltam a filtert, majd újraindítottam a tűzfalat. Semmi hatás. (Mental note: ezzel az ISÁval még foglalkozni kell a közeljövőben.)
Nos, ez az ügy egyre cifrább. Elmormogtam néhány ősmagyar siralmat a fogaim között és engedélyeztem minden protokollt az IP-s szabályban. Újabb windowsupdate kísérlet, megint ugyanaz a hiba. Viszont az ISA logban látszott, hogy minden forgalom átment, semmi deny. Csak hogy csináljak valamit, felraktam egy firewall klienst is, de azzal sem működött.
Itt rúgtam bele az asztalba és mentem haza.
Aztán új nap, új remények. Először is szóltam egy kollégának, hogy indítsa el a windowsupdate-t a gépen, írja fel egy cetlire a patch azonosítókat és kezdje el egyenként letölteni, fellapátolni. Eközben összedobtunk egy tiszta szervert, hogy azzal kísérletezzek. Elindítottam a windowsupdate-et, mely első lépésben nekiállt letölteni(!) a Bits2.0-át és a Winhttp5.1-et. Anyád. Az a hernyótalpas. Ezt tegnap este miért nem tudtad megcsinálni?? Restart,az újbóli próbálkozásra leszedte az új windows installt. Itt már csak csóváltam a fejem. A következő lépésben a tesztgép úgy lekapta mind a 27 foltot, mint a huzat.
Nézzük az éles rendszert. Szerencsére a kolléga még csak töltögetett (21 a 27-ből), nem installált. Próbaképp ráböktem egy kicsi patch-re – és lejött. Egyből vérszemet kaptam és ráindítottam mind a maradék 26-ot. Mind lejött. Meg a csempe is a falról.
Mivel racionális ember vagyok, számbavettem, mi történhetett valójában:
Mindhárom nagyjából azonos esélyű. Rátok bízom a választást.
Megjegyzés:
TankoP írkál itt valami apt-get-ről. Szerintem csak azért, hogy bosszantson.
Ha ezt tudom, elvihettem volna Nejt is. Eredetileg úgy terveztük, hogy péntekre szabadságot veszünk ki, délelőtt összepakolunk és ha hazajöttek a kölykök isiből, indulunk is a Bükkbe. Ebbe kavart be aTechnet szeminárium, ahol az első két előadásra éreztem úgy, hogy érdemes lesz elmennem.
Nos, az első előadáson Chris Capossela vizionált a szép új világról – a kiírás szerint. Ehelyett kaptunk egy Office12 ismertetőt. Nejt biztos érdekelte volna, különösen az a négy és fél kattintás, melyekkel a powerpointot mutatta be.
Chris ábrái barokkosan ki voltak dolgozva. Lelki szemeim előtt megjelent a 10 fős szerzetesi team, ahogy másolták a kódexeket gyártották a diákat, amíg olyan gyönyörűek lettek, hogy ész nélkül nedvesedtek tőlük a CEO-k. Kicsit zavaró volt, hogy a kulcsfogalmakon kívül a diák tele voltak boldog és sikeresnek látszó modellek fényképeivel, akik szemmel láthatóan a világ legdögösebb tevékenységének tartották, hogy hivatali környezetben a billentyűzetet meg mentálisan egymást bökdössék. A boldog értekezletszervező és az átszellemült meghívottak… aha.
Az előadó természetesen friss volt, üde és dinamikus – ahogy egy infomunkás aligazgatóhoz illik. Eljátszottam a gondolattal, vajon mi történne, ha az értékelőlapon a ‘van még hová fejlődnie’ rubrikát csekkolnám be? Megtépné a zakóját?
Mindegy, nem kellene ennyit morognom, egyszerűen csak az történt, hogy a marketingdetektorom kiverte a biztosítékot. Másfelől viszont egy új terméket mutattak be, ahol tkp. van létjogosultsága valamennyi marketingnek. (Csakhogy nem ennyinek – ez azért egy Technet szeminárium lenne, csupa kockafejűnek.)
Meglepő módon voltak kérdések. Jót vigyorogtam, hogy mindegyiknél akkorra értek oda a mikrofonnal, mire a kérdezőnek már sikerült megértetnie a kérdést. Tetszett a lelkesedés – a lány helyében én biztos feladtam volna az első sikertelen kísérlet után.
Chris végül eltolta kis piros kocsiját, jött Mick, aki meglehetősen perverz módon kilógatta az Exchange szervere összes fontos szervét az ablakon kívülre. Itt volt egy mondat, melyért megérte végigülni a délelőttöt – helyrerakott bennem néhány új fogalmat.
Van egy diszkrét bája ezeknek az előadássorozatoknak: érdemes végigkísérni, hogyan evolválódik a Technet harci asztal. Volt először egy sima szürke asztal, aztán elkezdtek rajta burjánzani a rácsok, egyre vadabb formákat öltve, míg végül eljutottunk a mostani betontömb imitációig. Kíváncsian várom, mi lesz a következő formaötlet.:)
A másik finom részlet a zeneválasztás. Nem tudom, kiknek tűnt fel, de Chris előadása előtt elhangzott a ‘Hé te, takarodj a felhőmről’ című Stones nóta, az átszerelés közben meg a ‘Nem kaphatod meg mindig azt, amit akarsz’ című. Irónia?
Sajnos Bátorfi Zsolt előadásáról nem tudok beszámolni – rohantam, várt a kies Jávorkút. De ez már egy másik történet.
Tavasszal már voltam hasonló rendezvényen, akkor a még béta fázisban lévő ISA2004 enterspájz verziót kattogtattuk lelkesen. Most is ugyanaz a hölgy volt itt és valamivel összeszedettebb előadást nyomott le – bár nem nagyon merültünk le most sem keszonveszélyes mélységekbe. (Egy kicsit furcsállottam: tudtommal a napokban van a nagy MVP röfögés Redmondban – a hölgy akkor most vagy nem MVP vagy lelépett, hogy a Minor kies oktatótermében előadhasson durván negyven embernek?)
Délelőtt általános ismerkedés volt az ISA2004 enterspájzzal, ez nekem már nem sok újdonságot hozott. Inkább csak kötekedések jutottak eszembe, pl. amikor Beth lelkendezett, hogy milyen remek dolog is az online logolás lehetősége. Az igen… de az idő szerinti kereséseknél azért lehetett volna finomítani az időréseken. Jelenleg ugyanis menüből választhatók ki az értékek és az 1 óra után következő lépcső a 7 nap. Ha nekem neadjisten másfél órával korábbi esemény kellene – hát, ne kelljen. Vagy keressek másképp.
Amit egészen biztosan mondott korábban is, de igazából csak most értettem meg (thx Technet Magazin): a CSS – azaz Configuration Storage Server – tulajdonképpen egy ADAM. (Active Directory Application Mode.) Itt tényleg van értelme, de az előadott magyarázat azért kicsit sántít: Beth szerint azért van, hogy olyan helyeken is használhassanak ISÁ-t, ahol nincs AD. Most nézzünk mélyen magunkba és saccoljuk be, mennyi lehet ennek az esélye?
A laborgyakorlat megint nem hozott túlzottan lázba, ehelyett nekiálltam CSS-t hekkelni. Ha ez is egyfajta AD, akkor tuti neki lehet esni a hagyományos AD faragó eszközökkel is. Próbáltam Adsiedit-et, Ldp-t de valahogy nem jött össze. Először a tűzfalra gyanakodtam és elkezdtem finom kis lyukakat fúrni rá. Végül már bazookával durrantottam bele, de akkor sem értem el a localhostot a 389-en. Ekkor kezdtem el gondolkodni. Lehet, hogy a CSS nem a 389-en adja a műsort? Megpróbáltam ráguglizni, de a css szó enyhén szólva is meglehetősen elterjedt kifejezés.
Mivel Beth azért ült ott, hogy kérdezgessünk tőle, letámadtam.
– Hogyan tudom elérni ADAM Adsiedit-tel a CSS-t?
– Oh, a CSS felülete teljesen megegyezik az ISA konzolban látottal. Nincs szükség ADAM utilityre.
– De én szeretném látni pucéran a CSS-t.
– Ugyan, ne akarjam már pucéran látni a CSS-t.
És ennyiben maradtunk.
Ebéd után jött a Sybari Antigen bemutatása. Erre marhára kíváncsi voltam, hogyan integrálták be az MS-be, de semmi különöset nem hallottam. Gyk. megvették és egyelőre ennyi. Ugyanúgy kell használni, mint korábban.
Hallottunk egy elég sekély előadást a termékről, a szokásos ‘balra ütök, jobbra ütök, középen lecsapom a labdát’ stílusban: hűdebaromirakurvasok a vírus, egy gyártóra támaszkodni SPOF -> ta-damm, itt a megoldás.
Beth védelmében azért meg kell említenem, hogy ez egy négy napos kurzus anyaga volt, amit neki kétszer másfél órába kellett összesűrítenie. Ergo jórészt otthon kell majd átnyálaznunk a két könyvet, felszórnunk a virtuális gépeket és végigjátszanunk a laborgyakorlatokat. Mondtam a múltkor is, most is megemlítem: határozottan szimpatikus, hogy megkaptunk mindent: mind a könyveket, mind a tesztkörnyezetet. A korábbi tapasztalatok alapján azért hozzáteszem, hogy 1 GB memória alatt ne is próbáljuk meg feltenni. És csak hat hónapig használható.
Mindenesetre az Antigen labort ún. mentális kattogtatással csináltam végig. Egy korábbi cégnél már üzemeltettem Antigen for Exchange programot, örömmel láttam, hogy a kezelői felületen nincsenek nagy változások. (Mondjuk azt nem igazán fogtam, hogy mintha a spamszűrő nem lett volna az alapcsomag része; enélkül meg csak a meglehetősen bugyuta ‘beírjuk kézzel a szöveget’ subject filter opció lenne benne?)
Aztán a végén találkoztam a megnövelt felhasználói élménnyel is. Elmenetel előtt még betértem a klotyiba és nem lehetett nem észrevenni, hogy a piszoár feletti csempelap méretű infravörös érzékelő olyan fényes volt, hogy az aktus során végig láttam benne a farkamat. Great.
Nagy ügyfélnek van egy nagy Exchange organizációja. Van neki két kisebb, többé-kevésbé független leányvállalata. Ezek szintén benne vannak az organizációban, saját Exchange/DC szerverekkel. Az egyik leánnyal nincs is gond, az ő szervereiket mi üzemeltetjük. A másik viszont zűrösebb, elméletileg semmi közünk sincs a gépeikhez – gyakorlatilag muszáj bele-belenyúlkálnunk. Persze a saját adminjaik is bele-belenyúlkálnak.
A nagy ügyfélnek van saját levelezési internet kijárata.
A leányvállalatnak önálló routing groupja van, de az Exchange-t csak belső levelezésre használták. Kifelé saját linuxos levelezési rendszert építettek ki. A kettő között nem volt átjárás.
Megkérték, hagy használhassák külső levelezésre is az Exchange-t. Beállítottam az organizációban, hogy a továbbiakban érezzen felelősséget az új emailtartományért (kaptak egy email policyt), szóltam nekik, hogy írassák át az MX rekordjukat és elmentem nyaralni külföldre.
Csakhogy ők kreatívan értelmezték a lehetőségeiket, ugyanis felraktak egy új smtp konnektort a saját tűzfaluk és Exchange szerverük közé majd erre iratták át az MX rekordot. A konnektoron 1-es súlyt állítottak be (naná!), ezzel sikeresen magukra rántották a nagy testvér teljes kifelé menő levelezését. Ez még nem is lett volna olyan nagy gond – de nem sokkal később lekorlátozták, hogy csak ők használhassák a konnektort. Ekkor állt le a nagy cég levelezése és tört ki a botrány. Kollégáim hosszas munkával kinyomozták, mi történt, felemelték a kalózkonnektor súlyát, a levelezés megjavult. Persze felelőst kellett találni. A leányvállalat elegánsan mindent rám fogott, mondván, hogy én csináltam a konnektort. Sőt, már a nyomozás kezdeti fázisában is mosták kezeiket, mind a nagy cégnek, mind a kollégáimnak azt állítva, hogy én csináltam mindent. Emiatt sokáig mindenki azt hitte, hogy ez a konnektor teljesen legális és jól van konfigurálva.
Amikor visszajöttem a nyaralásból, találtam néhány ejnye-bejnye levelet a postafiókomban. Marhára nem értettem a dolgot. Tiszta szerencse volt, hogy éppen nem akadt túl sok munkám, így megpróbáltam utánajárni a leveleknek. Lefényképeztem néhány képernyőt, megmutattam mind a főnökeimnek, mind a nagy ügyfélnek, hogy itt akkor történt a disznóság, amikor külföldön voltam. Ezzel rendeződött is a helyzet. (Mindenesetre akár örülhetnék is, hogy annyira jól fekszem mind az ügyfélnél, mind a saját cégemnél, hogy egy ekkora – nekem tulajdonított – malőrt tkp egy ejnye-bejnyével úsztam volna meg.)
Jött egy bejelentés, hogy a leányvállalat és a nagy cég között megszűnt a public folder replikáció. Tudjuk, hogy a replikáció levelek útján történik – tehát első dolgunk benézni a Message Trackingbe, hogy mi a helyzet. A PF replikáció az Exchange szerverek Information Store (IS) szolgáltatásai között zajlik, ők leveleznek egymással. Az IS-ek email címei így képződnek: Servername-IS@domain.root. Erre kell rákeresni a logban.
Visszatérve a mostani szituációhoz. Szépen látszott, hogy a nagy cég szervere elküldi a replikációt indító levelet a leányvállalatnak és nem kap választ. Nocsak. Korábban már írtam, hogy kényszeres telnetelésben szenvedek. Beléptem a leányvállalat szerverére, telnettel küldtem egy levelet a nagy cégnél lévő postafiókomba és megnéztem a levél tulajdonságlapján, milyen úton jött meg. Jól sejtettem, körbement: nem a két routing group közötti konnektort (RGC) használta, hanem kiment az internetre a leány kapuján és bejött a nagy cég internet kapuján. (Ídes babám, engedj ki, hagy jöjjek be!)
Nézzünk be a System Managerbe. Azt mondja, nincs hozzá jogom. Nekem?! Az Exchange Atyaúristen nevében voltam belépve: enterprise admin, domain admin, localadmin, schema admin. és ennek nevében történt az organizáció létrehozása is. Szóvá is tettem a legközelebbi összeröffenésen a leánycég vezetőinek, hogy ugyan miért rúgtak ki a szerverükről? Harsány tiltakozás, persze – dehát nekik ekkoriban volt némi szavahihetőségi deficitjük.
Mindenesetre az adminjukkal nekiugrottunk a rendszernek és tényleg nem volt egyszerű a helyzet. A DC-n belépve tudtam menedzselni a felhasználóikat. Ő az Exchange szerverre belépve el tudta indítani a System Managert és látszott, hogy a routing group-on megvan a full admin jogom. Meg lefelé is mindenhol. Ha én léptem be, még az ADUC-ot sem tudtam elérni.
Hmm… elvonultam gondolkodni.
Engem igazából a Winroute érdekelt volna, megnéztem: azt mondta, ismeretlen organizáció és egyáltalán, minden ismeretlen. Nocsak, nyomon vagyok? Nézzük, mi van az AdsiEdittel – itt sem értem el a tartományt. Ldp? És igen – az ldp-vel sikerült végre kapcsolódnom a tartományhoz. Tesztként átírtam egy felhasználó emailcímét, működött. Mit tudhat az ldp, amit az MMC illetve az AdsiEdit sem tud? Fogalmam sincs. Nézzük meg Netmonnal. (Pontosabban elsőre Ethereal-lel ugrottam neki, de az nem tudta értelmezni az LDAP forgalmat. (??))
Először az RST-kre figyeltem fel és csak később esett le, hogy némá, az Exchange szerver a forest root DC-vel akar ldapozni. Vajon minek? Mindkét tartományi DC GC is egyben – elméletileg le kellene tudniuk kezelni azt a helyzetet, hogy a felhasználó a forest rootban lett létrehozva. Bár a szituáción lehetett volna egy csomót agyalni, de az egyszerűbb utat választottam, írtam egy levelet a tűzfalasunknak, hogy léccilécci engedd már át az ldap-ot e két gép között. És innentől működött minden adminisztrációs eszköz. (Mondjuk továbbra is érdekelne, miért volt ravaszabb az ldp, mint a többi.)
Persze a PF replikáció az nem javult meg.
Átnéztem jól az organizáció routolását, hangolgattam is, végül ez lett:
InternetN(SMTP)(2) – (2)(SMTP)Nagycég(RGC)(1) – (1)(RGC)Leány(SMTP)(2) – (2)(SMTP)InternetL
Ennek működnie kellett volna, különösen, hogy az RGC-nek kutya kötelessége lett volna a belső leveleket szállítania, függetlenül az SMTP konnektoron lévő súlytól. Kínomban írtam az MS TAM-unknak, ugyan szerezzen már valami anyagot arról, hogy hogyan működnek testközelből ezek a konnektorok, különös tekintettel arra az esetre, amikor egyszerre van RGC és SMTPC – ugyanis ilyen szituációról a Resource Kit sem tett említést. Visszaírt, hogy ennek így tökéletesen kellene működnie, itt más lesz a gáz. Beszélt Mészáros Kornéllal és küldtek egy checklistát, mit nézzek át. És igen, itt lett nyakoncsípve az aljas: a virtuális SMTP szerveren is be volt állítva egy smarthost – a leánycég internetkijárata előtti spamszűrőre célozva. Amikor csinálták az illegális konnektort, nem bízták a véletlenre, beállították itt is – ezáltal nemcsak azok a levelek mentek az SMTP konnektor felé, melyeknek arra kellett volna menniük, hanem mindegyik. Ugye milyen egyszerű, mi? Csak meg kellett volna nézni azt a nyomorult patkószeget.
A fiúk persze elfelejtették a beállítást és hagyták, hagy szívjak vele pár napot.
Persze, ha nem így tesznek, szegényebbek maradtunk volna ezzel a cikkel.
Recent Comments