MonthDecember 2008

Exchange 2007 – első adatbázis törlése

Két hete volt egy rendszerátállásunk. Mintegy háromszáz felhasználó költözött egy hétvégén Windows Server 2003/Exchange 2003-ról Windows Server 2008/Exchange 2007-re.

A költözés mondhatni sikeresen, láthatóan buktatók nélkül zajlott le. Két nappal az átállás után a helyi informatikus hívott, hogy valami (azóta is relytéjes) okból elkezdett nőni az Exchange adatbázis mérete 100% processzor terhelés mellett úgy, hogy közben senki sem dolgozott. Sikerült óránként kb. 10GB-ot hozzátenni az adatbázishoz.

Az Event Log-tól nem lettem okosabb és miután még igazán fontos adatok nem kerültek az adatbázisba megkockáztattam a gép teljesen szabályos újraindítását.

Elindult, a store is. Nem nőtt tovább a mérete (ekkor potom 42GB volt). Miután ez egy esti időpillanat volt, arra gondoltam, hogy majd másnap foglalkozom vele.

Ezt a számításomat keresztül húzta a következő telefon. Elkezdtek store hibaüzenetek keletkezni az Event Logba.

Na ez két lehetőséget adott:

1. A mindig fennálló gyűlölt csoda: eseutil

2. Miután a store még valamilyen szinten élt, átköltöztetni az összes fiókot egy új adatbázisba.

Ez utóbbit választottam. Létrehoztam egy új storage group-ot, benne egy új store-t és hiba nélkül átpakoltam mindenkit.

Ez rendben is van. Kaptam egy 2GB-os adatbázist, örülök. De mi legyen a régivel. Régi Exchange ismereteim arra figyelmeztetnek, hogy az infrastruktúra első adatbázisa, első szervere, első anyámtyúkja mindig tartalmaz valami olyan információt, amit meg kell őrizni.

Végigtúrtam a netet és azt találtam, hogy az egyetlen dolog, ami az első adatbázisban van és a mozgatás során nem költözik el az a System Attendant mailbox. Ennek a költözésével pedig nem kell foglalkozni, mert amikor megszüntetjük azt az adatbázist, amelyikben volt, akkor automatikusan újragenerálódik egy másik adatbázisban (az eredeti cikk linkjét idetenném, ha nem dobálna 500-as hibákat a Microsoft fóruma).

Kipróbáltam. Működik. Probléma megoldva. Az eredeti hiba azóta nem fordult elő.

ClamAgent, ClamSink

Már korábban írtam róla, hogy elkövettem egy ingyenes vírusirtót az Exchange 2007-hez. Most elkészült ennek az Exchange 2003-al vagy IIS SMTP szerverrel használható változata. Mind a kettő megtalálható a http://www.clamagent.org -on.

Feljegyzés magamnak

Még az ősszel kaptam egy megbízást. Mondanom sem kell, eddig esélyem sem volt foglalkozni vele… és most is éppen csak beleharaptam a témába, éppen csak elkezdtem anyagot gyűjteni.

De azért lepődtem már meg.

Nézzük például az EAP autentikációt. Azt ugye tudjuk, hogy az EAP alapvetően nem egy önálló autentikáció, sokkal inkább egy keretrendszer. Mint az MMC: beletűzdeljük a snap-in-eket és így lesz egy jól használható valami belőle. Az EAP-ba ilyesmiket szoktak beledöfni, hogy TLS (melyről tudjuk, hogy az SSL leszármazottja), illetve MS-CHAPv2. (Bónusz kérdés: mi a különbség az MS-CHAPv2 és NTLMv2 között? Bónusz válasz: a módszer ugyanaz. Csak máshol használjuk.)
No, most jön a meglepődés. Vajon MS rendszerekben wifi autentikációhoz melyik EAP sündísznót használjuk? Az EAP-TLS-t? Ahol tudjuk, hogy a TLS elődje az tkp. Netscape kreálmány? Vagy inkább az MS saját édes gyermekét?
Persze, hogy az EAP-TLS-t. Az MS édes gyermeke… most nem kapott lapot.

De mielőtt szottyosra zokognánk a kispárnánkat, olvassunk tovább.

Nemcsak EAP van a világon… létezik PEAP is. Mi a különbség? Úgy van, nagyon jól éreztél rá: a ‘P’ betű. ‘P’, mint Protected. Anélkül, hogy túlzottan belemennék a részletekbe, a különbség lényege az, hogy az EAP esetén a felek kölcsönös becsületsértegetése nyilvános, míg a PEAP esetén már ez is titkosított. És igen, a PEAP-nál már egyenrangú a PEAP-TLS és a PEAP-MSCHAPv2.

Adide, nemadom

Na, kérem, itt van a magyarázat ahhoz, ami miatt pár nappal ezelőtt csak kapkodtam a levegőt.

Nemrégiben jött ki az Exchange 2007 SP1 termékhez a Rollup Pack 5. (Csak gondoljunk bele… az SP1 előtt volt megint 5 Rollup Pack… és mindegyik megváltoztatta a termék viselkedését… nem könnyű ám Exchange adminnak lenni.)

Nos, az egyik hiba, melyet a csomag javított, így szólt: CCR vagy SCC clusterben megvalósított Mailbox szerveren nem működött a GAL disztribúció, amennyiben Outlook 2007 kliensről próbálkoztunk.
Ránézésre nem olyan vészes, pedig de. Összeraksz kemény munkával egy clustert, jön egy felhasználó Outlook 2007-tel – annyira azért már nem ritka jószág – és nem lát címlistát.

Eddig nem lehetett sokat tudni arról, mi is okozta a hibát – de Dave Goldmann nemrég írt egy cikket. Most már tudjuk. Most már verjük a fejünket a falba. Velük együtt. Annyira idióta hibáról van szó, hogy tényleg nem értem, hogyan kerülhetett bele a rendszerbe.

Nem húzom tovább az időt, itt a magyarázat: az OABGen process a \\gepnev\ExchangeOAB könyvtárba tette le a legenerált xml fájlt, mint ahogy mindig is szokta. A CAS szerver viszont nem ott kereste, mert ő hogyan is látja a clustert? A virtuális Exchange szerver nevén keresztül. Azaz a CAS a \\CMS\ExchangeOAB megosztást kereste, nem találta, tehát az OAB weblapon nem is tudott publikálni semmit.

Függöny.

Sírok

Most kivételesen nagyon negatív leszek. Úgy értem, negatív negatív. Általában ugyanis pozitív negatív szoktam lenni: ha szidok is valamit, azt javító szándékkal teszem – hiszen alapvetően azért kedvelem azt az izét.

Blackberry. És Onebridge.

A projektünk az ügyfélnél szépen haladt, elérkeztünk odáig, hogy foglalkozzunk az Exchange szerverekhez kapcsolódó külső szerverekkel. Igen, a fenti szerverekről van szó.

Na most, én már akkor kis híján lepetéztem, amikor a múltkor kiderült, hogy – dacára mindenféle natolásnak – a BB szervert a belső IP címével regisztrálják be odakint. Azaz ha egyszer feltelepítetted, akkor azt már át nem rakod máshová. De ami most jött, az felért egy tökönrúgással.
Közölték, hogy a fenti két szerver közül egyik sem bírja lekezelni azt a roppant bonyolult szituációt, hogy egy Active Directory több tartományból áll. Négylábas megadás. Érted, Windows környezetbe tervezek egy alkalmazás szervert, de az sajnos nem tud lekezelni olyan szituációkat, melyeket az alatta lévő Windows egyébként messzemenően támogat. De továbbmegyek: mindkét alkalmazás olyan rendszerhez – Exchange – kötődik szorosan, mely deklaráltan címtár szintű… azaz tartományok feletti. Az Exchange mindig a teljes címtárban gondolkodik, nem érdekli, hogy ki melyik tartományban van.
És akkor közlik, hogy telepítsük újra a régi BB/OB szervereket, mert az új Exchange másik tartományba került. Agybaj.

Kezdtük egy Onebridge teszttel. Kijött a nagynagy internetszolgáltató szakembere, mi is delegáltunk egy helyi rendszergazdát. Belevágtak. Aztán délután 5-kor jött a levél: help.
Napközben annyi történt, hogy a szakértő hozott egy telepítési leírást, meg néhány OB knowledge base cikket, hogyan kell felkészíteni az Exchange-t az együttműködésre. Ezeken becsülettel végig is mentek, majd jött a kapcsolódás… meg az error. Kipróbáltak mindent, de nem lett jobb a helyzet.
Ekkor kapaszkodott bele a szakértő és az ügyfél delegált embere abba a kitételbe, hogy az OB KB a preparációknál megemlítette azt, miszerint győződjenek meg róla, hogy az Exchange szerveren nincs-e letiltva a MAPI. Tény, le lehet. De nem egyszerűen. Ha a telepítésnél nem figyelünk, ész nélküll nyomjuk az OK-t, akkor belefuthatunk ilyen szituációba. (Írtam is erről anno.) De ha rendesen telepítünk, akkor már nincs ilyen veszély. Igaz, le lehet tiltani utólag is registrybuherával… de azért csak emlékeznék rá.
Így ment is vissza a levél a fiúknak, hogy nem, nincs letiltva a MAPI. De ezt egyből láthatják is, hiszen tudnak kapcsolódni régebbi Outlookkal, ráadásul láthatják, van Public Folder is. Erre jött az a válasz, hogy ez nem bizonyíték, tekintve, hogy mindenki tudja, miszerint az MS más MAPI-t használ, mint amit a külső cégeknek biztosít.
Itt szökött fel plafonig a szemöldököm. Ekkor lett nyilvánvaló, hogy a nagynagy internetszolgáltató szakértőjének halvány fogalma sincs arról az architektúráról, amelynek egyébként a szakértője lenne. Addig ugyanis oké, hogy más mapixx.dll települ fel mondjuk az Outlookkal, mint amit a külső cégeknek ajánlanak… de ettől a MAPI, mint távoli eljáráshívásokon alapuló függvénygyüjtemény köteles ugyanolyannak lenni ugyanazon szerver esetében, hiszen a túloldalon a szerver csak az eljáráshívásokra reagál, nem kér előtte személyi igazolványt.
A helyi mérnökünk mindenesetre rámutatott, hogy először talán azzal a tömérdek MAPI errrorral kellene foglalkozni az OB szerveren, melyek az eventlogban vannak… és csak utána piszkálni az Exchange oldalt. Különösen, hogy amit a KB cikkük előírt, azt pontosan beállítottuk.
És most itt állunk. Szószerint is.

Nos, eddig ez akár egy szokásos köcsögjózsis történet is lehetne.

De amitől hirtelen ledobtam magamról minden toleranciát és billentyűzetet ragadtam, az egy KB cikk volt. Az egyik fázisban a szakértő megadta a hozzáférését az OB KB cikkekhez, hátha én, Exchange szemszögből kiszúrok valamit. Hát… kiszúrtam.
Mivel nem publikus anyag, így a lényegi részből nem idézek. Nagyjából arról van szó, hogyan is kell pontosan kipreparálni az Exchange szervert a korrekt kapcsolathoz. Egy csomó jogosultáságállításról van szó, mind felhasználói, mind szerveroldali konfigurációkról. A közös mindegyikben, hogy a címtárban állítgatod az értékeket: hol a domain névtérben, hol a configuration névtérben. Kizárólag csak ezeken a helyeken.
És akkor most követek el egy bűnös kiszivárogtatást. Akit esetleg komolyabban is érdekel, lementettem az írást, nálam meg lehet tekinteni. Szóval ez annak a bizonyos KB cikknek (#4267) az utolsó mondata:

It might be necessary to restart affected servers, such as Domain Controllers and Exchange Servers, in order the changes to take effect.

Megégetni az architektet. Megégetni. Most.

Gondolj, bele, egy ilyen alkalmazásnak adunk mindenféle erős jogot egy nagy ügyfél nagy Exchange rendszerében. Ráadásul mosolyogva kell.

Minden jó, hajó a vége

Valamikor írtam róla, hogyan járt szerencsétlen ügyfelünk: az anyacége dömperrel beborított vagy 30000 kontaktot a címtárába. Szaladgáltak is szegények, mi lesz most a címlistákkal: végül egy illegalitásba hajló lépéssel megpatkoltuk a rendszert.

Aki nem olvasta át a két linket, röviden összefoglalom: szerencsére kiderült, hogy a távoli tartományban született kontaktok msexchoriginatingforest tulajdonsága megőrzi az eredeti forest értékét. A helyben született objektumoknál viszont ez üres. Azaz a GAL mögötti ldap filterbe ‘és’ kapcsolattal becsatoltunk egy !(msexchoriginatingforest=*) feltételt – így csak azok jelentek meg a globális címlistában, akiknek üres volt ez a tulajdonsága. Természetesen az eredeti GAL filtert kimentettük egy custom címlistába, hogy akik abban akarnak keresni, azért tudjanak.

Mindenki boldog volt.

Egészen az Exchange 2007 migrációig.

Igazából nem az a legnagyobb baj, hogy ebben a termékben kinyírták az ldap alapú szűrést. Hiszen bejött helyette az OPATH – és ha megszokod, rájössz, hogy ez tényleg jobb. Még csak nem is az a katasztrófa, hogy beszuszakoltak egy plusz réteget a filter és a címtár közé. Igaz, hogy mostantól a feltételekben nem direktben hivatkozol az objektumok tulajdonságainak értékére, hanem helyette ujjból szopott nevű változókat kell használnod… de ez maximum kényelmetlenség. A tragédia az, hogy nem definiáltak minden tulajdonsághoz változót. Költői kérdés: találd ki, használhatjuk-e OPATH filterben az msexchoriginatingforest tulajdonságra definiált változót? Nem… mert nincs. Nyugodtan böngészd át a választékot.

Mondtam, ugye, hogy a legnagyobb szopás az ldap filter az egész upgrade-ben?

Akkor mi legyen? Adódik, hogy szűrjünk rá a szerver nevére. Az ügyfélnél egy darab nagy teljesítményű központi szerver lesz, tehát még a szűrőfeltétel sem lesz túl bonyolult. Alapvetően működhetne is… csak éppen nem elegáns. Mi van, ha valamikor üzembeállítanak majd egy másik MBX szervert is? Mi van, ha egyszer átmigrálják a postafiókokat egy másik szerverre? Ki fog emlékezni rá, hogyan lett megbuherálva a GAL? Ráadásul…ugye az átállás ideje alatt még két szerver van, tehát mindkettőnek a nevét be kellene írni a feltételbe. Pedig a régi csak pár hétig fog még élni. Jó, majd utólag módosítjuk.
Meséltem már erről? Lehet. De ismétlés a tudás k. anyja.
Szóval, a GAL-t a set-globaladdresslist paranccsal tudjuk upgradelni. Exchange 2007 alatt ugyanis minden szűrős objektumnak két szűrője is van. (Logikus, hiszen illeszkednie kell mind a régi, mind az új rendszerhez.) A címtár preparálásakor meg is jelenik az új tulajdonság, de sehol, hangsúlyozom, sehol sem történik automatikus filter konverzió, amikor betoljuk az első MBX szervert az organizációba.
Magad uram, ha szolgád nincsen.
Címlistáknál, email address policy-knél nem is gond. De a GAL-nál igen. A set-globaladdresslist parancs ugyanis egylövetű. Egyszer beírhatod az OPATH szűrőt. A következő futtatáskor már azt kapod, hogy ‘Hohó, valaki nem bír magával!’. Nyilván adsiedit és purportedsearch… de nem lehetsz benne biztos, nem csináltál-e valami visszafordíthatatlant. Lehet, hogy valahol a mélyben elpattant egy fogaskerék, a szerver teliholdkor életre kel és szakrálisan feláldozza az éjszakai recepcióst. Vagy bármi. De hogy nem lesz supportált, az tuti biztos.
Márpedig, ha a szervernevekkel játszol, akkor kétszer is módosítanod kell a GAL-t.

De azért megpróbáltam körbejárni. Leginkább azért, hogy közben időt hagyjak ott hátul a megoldáskeresésnek.
Összedobtam az Exchange 2003-ban egy teszt címlistát. Varázslóval. Középső fül, szervernév megad. Nézzük az eredményt… hoppá. Brian… leestem a székről. Ott voltak benne a külföldi címek. Most én vagyok a hülye… vagy a varázsló? Szerintem az utóbbi. Nézzük csak a konkrét feltételt… jézusmária. Sőt, ez már inkább duplajézusmária erősségű volt. Ez az idióta kuruzsló ‘vagy’ kapcsolatba tette a szervernévre vonatkozó feltételt az első panelen bepipált ‘contact’ feltétellel. Így mindenki beleesett. Döbbenet.

Kitérő:

Ha csak lehet, ne használj varázslót.
Ha ez eddig nem lenne egyértelmű, elmagyarázom, miért.
Nézzük az előbbi példát, kattogtassunk össze egy címlistát, amelyikben az Exchange postafiókkal bíró felhasználók címei vannak. Első fül, ‘Users with Exchange mailbox’ checkbox. Ez lesz a szűrőfeltétel:

(&(&(& (mailnickname=*) (| (&(objectCategory=person)(objectClass=user)(|(homeMDB=*)(msExchHomeServerName=*))) ))))

Azaz mindenki, akinek nem üres a homemdb (melyik adatbázisban van) és az msexchhomeservername (melyik exchange szerveren van) tulajdonságának az értéke.

Jelöljük be mellé a külső emailcímmel bíró felhasználókat is. Ez ugyanazon a panelen a következő két checkboxot jelenti: ‘Users with Exchange mailbox’ és ‘Users with external mail addresses’. A szűrőfeltétel:

(&(&(& (mailnickname=*) (| (&(objectCategory=person)(objectClass=user)(!(homeMDB=*))(!(msExchHomeServerName=*)))(&(objectCategory=person)(objectClass=user)(|(homeMDB=*)(msExchHomeServerName=*))) ))))

Azaz mindenki, akinek nem üres a homemdb (melyik adatbázisban van) és az msexchhomeservername (melyik exchange szerveren van) tulajdonságának az értéke – illetve mindenki, akinek meg üres. Jópofa, mi? Ha belegondolsz, hogy beviszünk egy feltételt, majd ‘vagy’ kapcsolattal annak az ellenkezőjét is, akkor tkp megkapjuk az univerzumot. Ami nem baj, mert ugye pont azt kértük… csak éppen megkaphatjuk egyszerűbben is, sokkal kevesebb munkával.
A helyes, varázslótlanitott szűrő:

(&(mailnickname=*)(objectCategory=person)(objectClass=user))

Ha belegondolsz, hogy ez a szűrőfeltétel minden RUS futáskor végigmegy a címtáradon… ugye nem mindegy, mennyit kell tökölnie a feltétel kiértékelésén.

Kitérő vége.

Szóval nem tetszett a szerverneves vizsgálódás. Ldp-ből kinyomtattam mindenfajta objektumból egy-egy teljes tulajdonságlistát, majd egy kihúzófilc társaságában félrevonultam. Kerestem, hol lehet ezt az egészet megfogni.
Hamar kiderült, hogy a szervernévvel egész konkrétan nem. Az ugyanis a magyar kontaktoknál is üres, nemcsak a kintről betoltaknál.
Gyakorlatilag nem találtam semmit. Illetve találtam, de. Nekem, emberi aggyal egyből látszott…de látszik-e ez a programnak is? Ugye ott van a distinguishedname, mint paraméter. Ebben szépen benne van az objektum elérési útvonala is. Márpedig a letolt címek, mégha egy nagyon bonyolult OU struktúrában is, de egy OU-n belül vannak. Azaz a distinguishedname valahogy így néz ki: cn=blabla,,,ou=PamPam,ou=blabla,dc=blabla. A vastaggal jelölt rész mindegyik idegen címben megegyezik, és csak azokra jellemző. Nosza, nézzük csak meg azt az OPATH szintakszist. Jé, ez a nolike egész szimpatikus. Tud ez wildcardot? Tud. A distinguishedname tulajdonságra létezik változó? Létezik, méghozzá ugyanazzal a névvel. Mire várunk?

Hölgyeim és Uraim! Imhol az új GAL:

alias -ne $null -and distinguishedname -nolike ‘*ou=PamPam*’

Már csak be kell gépelni. Jelzem, elsőre úgysem fog sikerülni. A filterek beadása rendszeresen kész katasztrófa. Elsőre úgyis csak címlistákon gyakorlunk, tehát dobjuk be ezt a keresést egy már létező ‘teszt’ nevűbe:

set-addresslist -identity teszt domaincontroller dc.domain.hu -recipientfilter {alias -ne $null -and distinguishedname -nolike ‘*ou=PamPam*’} -whatif

A -whatif azért van a végén, hogy ne csinálja meg, csak írja ki, mi lett volna.
Nos?
Ha jól csináltuk, akkor egy kövér errort kaptunk. Azt mondja, ennél a tulajdonságnál nem használhatunk wildcard-ot.
Ez már maga a Turáni Átok. Miért, ó miért? Bakker, hiszen ezen tudtuk (volna) egyedül megfogni a külsős címeket.
Gugli. Ezen a fórumon valaki hasonlóba futott bele, választ persze nem kapott. Viszont a Szkriptelő Fiúk egy helyen elkottyantották magukat:

Alas, this won’t work, either. As it turns out, the DN is a “constructed” attribute. The DN isn’t actually stored in Active Directory, it’s constructed on-the-fly any time you request it. Thus you can’t do a wildcard search on the distinguishedName attribute. And don’t bother asking about the ADsPath attribute, which also contains the OU name; you can’t do a wildcard search on the ADsPath, either.

Nem örülök… de beletörődtem.

Viszont az agyam, az kiürült. Szórakozottan nézegettem a papírjaimat, meg a változókat. Aztán az agyam kezdett magára találni, szép lassan összerakta az újabb variációt. Nézzük csak, proxyaddress tulajdonság, melyet itt emailaddresses-nek hívnak. Határozottan jelzi a táblázat, hogy nyomjuk csak bátran neki a wildcardot, bírja. Csakhogy ez egy tömb. Hogyan szűrjünk rá? Ezt is megmondja: a tömb elemei vesszővel vannak elválasztva és az egész egy szép nagy sztring. Nocsak. Persze az SMTP cím nem megoldás, rengeteg fajta van a cégen belül, aztán meg ott vannak a külsős kontaktok is. Na de… itt van ez az őskövület. Az X400-as cím. Mely már az égegyadta világon semmire sem jó. Csakhogy ennek a ‘P’ paramétere (Private Management Domain Name) pont az organizáció neve. És X400-as címe mindenkinek van – hiszen ez csak az email address policy-n múlik.

Azaz a következő kisérlet:

alias -ne $null -and emailaddresses -like ‘*p=orgname*’

Na, ez már jó. Mennyire? Túl.
Ez ugyanis beleveszi az összes emailcímmel bíró public foldert is, azt meg mi nem igazán szeretnénk. De innentől már rutinmunka. Úgy csinálunk, mintha gyártanánk egy új címlistát, bejelölünk mindenkit az első panelen (vegyük észre, hogy a public folderek fel sincsennek sorolva, azokat csak EMS-ből lehet felvenni), majd az utolsó panelről ctrl+v-vel lekapjuk a recipientfilter paraméter értékét, beleírjuk az emailaddresses figyelést… és készen is vagyunk. Imhol.

set-addresslist -identity teszt -domaincontroller dc.domain.hu -recipientfilter {emailaddresses -like ‘*p=orgname*’ -and (RecipientType -eq ‘UserMailbox’ -or RecipientType -eq ‘MailContact’ -or RecipientType -eq ‘MailUser’ -or (RecipientType -eq ‘MailUniversalDistributionGroup’ -or RecipientType -eq ‘MailUniversalSecurityGroup’ -or RecipientType -eq ‘MailNonUniversalGroup’ -or RecipientType -eq ‘DynamicDistributionGroup’) -or (RecipientType -eq ‘UserMailbox’ -and ResourceMetaData -like ‘ResourceType:*’ -and ResourceSearchProperties -ne $null))}

Habár már éppen eleget dolgoztunk ma, de azért ellenőrizzünk. Számoljuk össze, hány emberből áll az egyik lista és hányból a másik. Apró baki, hogy Exchange 2007-ben már csak preview van az Address List tulajdonságlapján, számláló nincs. Na de ott van még a régi szerver! Meg tudja számolni a 2003-as Exchange System Manager a 2007-es címlista elemeit? Meg hát. Igaz, eleinte hőbörög, de aztán beletörődik és számol.
A jó hír az, hogy kicsi az eltérés. A rossz hír az, hogy van. Nyilván annak a húsz embernek nem vigasz, hogy csak huszan nem látszanak a listában. És persze az egyik biztosan a vezérigazgató.
Akkor mégsem végeztünk. Nyilván az történt, hogy a több ezer emberből húsznál ki van kapcsolva a recipient policy, manuálisan meg nem kaptak X.400 címet. Semmi gond, megkeressük, levadásszuk.
Nyilván szkripttel.
Egy általános keresőszkript mindig itt figyel a gépemen, pusztán csak a kilistázott adatokat kell konkretizálnom. X400-as cím… az ugye a proxyaddresses tömb része. Nem tudom, ki szeret tömböt boncolni, én nem igazán. Kerülő út? Persze, hogy van. Tudni kell, hogy létezik olyan, hogy textEncodedORAddress változó, ebben a felhasználó elsődleges X400-as címe figyel. Pusztán csak ezeket kell lekérni egy Excel táblába, majd vizuálisan kiszúrni, kinél nincs adat.

Innentől már tényleg csak a piszkos munka van hátra.

ClamAgent

Elkészült a legújabb elkövetményem. Ezt most remegő kézzel adom közkézre, mert ilyet még nem csináltam. Mit is? Portált. Pontosabban írtam egy programocskát (ilyen már volt) és ehhez készítettem egy web portált (ilyen még nem volt).
Ha valakit érdekel, hogyan lehet az Exchange 2007-hez ingyenesen vírusirtót fabrikálni, akkor az itt talál megoldást:
http://www.clamagent.org