A patkó miatt a ló elveszett,
A ló miatt a lovas elveszett,
A lovas miatt a csata elveszett,
A csata miatt az ország elveszett,
B+ nézd már meg jobban azt a patkószeget.
Bevezetés:
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.)
Cselekmény:
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.
- Kitérő:ezzel azért óvatosan kell bánni. A Message Tracking azt a címet mutatja, amelyik a borítékon belül(!), azaz a levél data mezőjén belül van. Csakhogy a levelezés az alapján a cím alapján történik, amelyik a borítékra van írva – és ez a tracking logban nem látszik. Jártam már úgy – pont ennél a cégnél -, hogy installálás után az IS nem kapott email címet, emiatt nem ment a PF replikáció. A tracking log azt mutatta, hogy a levél jó címre ment ki: a data mezőben ott is volt a jó cím; csakhogy a nem látható ‘rcpt to’ üres volt. Az event log és az Archive Sink mondta meg végül az igazat és az AdsiEdit-tel írtam be a jó emailcímet az IS adatai közé.
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