Month: November 2008

Vazze

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

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

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

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

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

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

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

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

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

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

Management Tools
Completed
Elapsed Time: 00:00:07

Mailbox Role
Completed
Elapsed Time: 00:06:34

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

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

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

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

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

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

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

Ez nem fair

De tényleg. Azt hittem, hogy ezen a szinten már nem érhet meglepetés. Ha az ember profin hajt egykerekű bringát, akkor nem lehet kihívás a tricikli.

Címtárpreparálás, Exchange 2007 bevezetés előtt. Erről már mindenki leírt mindent, amit csak lehetett. Kockázatos művelet, de ha az ember odafigyel, meg bebiztosítja magát, nem lehet belőle baj.

Ment is minden. Egy ideig. A ‘setup /preparelegacyexchangepermissions’ simán lefutott. A ‘setup /prepareschema’ is… pedig ennél rágtam a legtöbbet a körmöm. Jöhetett a ‘setup /preparead’. Ettől már nem tartottam, hiszen ez már nem szánt olyan mélyen a címtárban.
Aztán kaptam egy valag hibaüzenetet:

The name property contains leading or trailing whitespace, which must be removed.

Hmm… elméletileg egy szavam sem lehet. A Microsoft standard-hez képest kifejezetten korrekt hibaüzenetet kaptam. Pontosan megmondta, mi a hiba.
Csak azt nem, hogy hol.
Hány olyan objektum van, amelyiknek van ‘name’ tulajdonsága? Az összesnek. Cca pár millió lehet az ügyfél rendszerében. Hogyan látod meg, ha whitespace van a név végén? Sehogy.

Na, ez a kihívás, nem a tű a szénakazalban.

Kezdjük szokás szerint a guglinál. Három találat. Elég vérszegény. Az első egy fórum, ahová egy hapi bedobta ugyanezt a kérdést. Választ nem kapott. A második ennek a fórumnak letükrözése. A harmadik meg egy pdf doksi. Azt írja a fazon, hogy nála a Recipient Policy-k között volt egy ilyen név.
Sokat nem segített. Mivel akárhol is kezdhetem a keresést, elkezdtem én is a Recipient Policy-knél. Van vagy húsz. Jobb kattintás, rename, bemeszelés. És a tizenvalahanyadiknál rámmosolygott a szerencse, egy kövér szóvégi whitespace képében.

15-20 perc várakozás, újabb kisérlet: siker.

Egy láthatatlan karakter valahol… mekkora retkes hiba már…

Tétova cluster

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

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

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

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

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

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

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

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

Erre bizony hamarosan megoldást kell találnunk.

A sóvárgó objektum

Lassan egy éve, hogy volt ez az üde, bájos eset. Nem, nem megünnepelni akarom az évfordulóját… egyszerűen csak szeretném lezárni.
Micsoda? Hogy mit kell még egy év után lezárni?
Nos, volt egy olyan hiba, mely akkor került bele a rendszerbe, de csak most lett kijavítva.

Szó se róla, hagytunk neki időt, hogy megoldódjon magától.

Január másodikán is hívott a helyi rendszergazda. Van egy felhasználója, akinek a nagy reszelésben elveszett az accountja. Ez nem is lenne gond, legfeljebb kap egy újabbat… de nem tudja kiosztani neki a régi emailcímét, mert azt mondja a rendszer, hogy ilyen cím már van. Pedig nem is.

Megnéztem. ADUC. Tényleg nem volt ilyen cím sehol… de kiadni mégsem lehetett. Miaf?
Gondolkodósarok.
Annyiszor elmondtam, leírtam… épp ideje volt, hogy magamtól is ráébredjek: az Exchange – szemben az ADUC-cal – nem az AD hagyományos ldap adatbázisát használja. Ekkor ugyanis az Exchange szerver nem látná a távoli tartományok domain partícióit – márpedig pont ott vannak a felhasználónevek és az emailcímek. Nem, ehelyett a globális katalógus ldap adatbázisát használja. Hogyan tudunk ebbe belenézni? Ldp, a portnál pedig a 3268-ast adjuk meg. Az ldp-nek van még egy nagy előnye az adsiedit-tel szemben: tud keresni. Rákerestem a felhasználó régi felhasználói nevére… és megtaláltam mind a két objektumot: az újat is, meg a beragadt régit is.
Ez bizony fogós probléma. Hogyan lehet a GC adatbázisból kitörölni egy bejegyzést, mely hivatalosan nincs is ott?

Mese nincs, google. Kiindulásnak pont jó volt, hogy a rossz felhasználó DN tulajdonságának értéke valami ilyesmi volt: “*CNF:GUID”. Meg is találtam, hogy ez egy vágyakozó objektum. Vágyik az elmúlásra.
Amikor kitörlünk egy objektumot, akkor az nem törlődik egyből. Ugye, nem kell magyaráznom, multimaster replikációs környezetben először a törlés tényének kell szétreplikálódnia, majd csak utána jöhet a tényleges megsemmisítés. Ez egész konkrétan úgy néz ki, hogy az ojjektum kap egy sírkövet, rajta a dátum, hogy mikor halálozott el. Innentől senki nem veszi komolyan… aztán pár hónap után (verziófüggő) eldől a sírkő is és az objektum ténylegesen is törlődik.
Igenám, de mi van a zombikkal? Képzeljük el, hogy lekapcsoltunk egy DC-t. A lekapcsolás pillanatában volt egy sírköves objektumunk. Telt-múlt az idő, az élő címtárból kitörlődött az objektum… aztán valaki visszakapcsolja a korábbi DC-t. Visszajön a sírköves objektum… de az AD nem tud mit kezdeni vele. Hiszen már rég a föld alatt kellene lennie. Törölni nem meri… de replikálni a biztonság kedvéért azért replikálja.
Ezek a vágyakozó objektumok. Angolul lingering objects. A CNF pedig annyit tesz, hogy conflict.

Hogyan került bele ez az objektum abba a bizonyos címtárba az ügyfélnél? Hát… ahogy a viccben is mondják, amit ott abban a másfél napban a kollégámmal csináltunk, örülj fiam, hogy nem nyerítesz.

De mindenesetre nyomon voltam. Megvolt a név, megvolt a jelenség. Már csak azt kellett megtalálnom, hogyan is lehetne eltávolítani az objektumot.

Ehhez sem kellett sokat keresgélnem: itt van a cikk. Javaslom, fusd át, mielőtt tovább olvasnál.
Durva.
Első olvasás után zsongott is rendesen a fejem: mikor, melyik GC-ről kell becélozni melyik GC-t? És mi ez a tömérdek GUID? Micsoda… mindegyik GC-t meg kell műteni? És mindezt egy nyomorult emailcímért?
Szóltunk az ügyfélnek, hogy ez egy kicsit durvább műtét, mint gondoltuk. Meg kellene várni egy csendesebb időszakot, amikor éppen nem heggesztjük ezerrel a címtárat. Rábólintottak.
Az más kérdés, hogy azóta folyamatosan rajta lógtunk a címtáron.

Végül eljött az az időszak, amikor már nem lehetett tovább várni. Hamarosan megszűnik az a bizonyos tartomány, márpedig a megszűnés után szinte reménytelen lenne eltávolítani a sóvárgó zombit.
Nekiugrottam a manuális eltávolításnak. Kövér error. Na jó, erre most nincs időm, ment a bejelentés a PSS-nek. A német sráccal lefutottuk a kötelező köröket, majd kipróbáltuk a meglehetősen beszédes nevű ‘repadmin /removelingeringobjects’ parancsot. Kiiírta, hogy minden fasza, eltávolította az összes lingeringet, nézzük meg az eventlogban, hogy mennyit. Egész konkrétan nullát.
– Ejha – füttyentett a mérnök. Ez mégsem lesz egy hétköznapi történet.

Nekiálltunk mi is a manuális eltávolításoknak. Kaptuk is az errorokat. De a hapi nem csüggedt.
Neki volt igaza… az egyik kombinációnál siker koronázta az erőfeszítésünket: az ldp kiírta, hogy eltávolította az objektumot.
– Oké – dőlt hátra székében a fazon – Megvan a módszer. Most már csak ezt kellene végigcsinálni mindegyik DC-nél.
A helyzet ugyanis az, hogy a zombi valamiért mégsem replikálódik szét mindegyik DC-re. Csak úgy, sztochasztikusan.
Javasolta, hogy próbálkozzak inkább a cikkben található szkripttel.
Nem mondtam neki, de eszem ágában sem volt. Ilyen kritikus műtétet rábízni egy ismeretlen szkriptre… egy ekkora címtárban… hiszen le se tudom menteni. Inkább kattogtatok.
Szóval azt mondja… az ldp-ből konnektálok egy DC-re. Aztán a command string megadásakor beírom egy másik GC GUID-ját, illetve a lingering objektum GUID-ját. Majd a commandnál végigmegyek az összes DC-n. Huszonegy DC, az annyi mint… 441 futtatás.

Izé… hol is van az a script?

Ez sem volt egy matyóhímzés. Egész konkrétan 5 darab fájlt kellett legyártani, GUID-hegyek torlaszoltak el másik GUID-hegyeket… de végül összeállt. Ráküldtem az éles címtárra, végiggondoltam, hogy hol is tárolom a munkakönyvemet, elolvastam egy gazdasági cikket… aztán egyszer csak lefutott a szkript. Dobáltam még egy kis dartsot, majd nagy levegő, teszt: felvettem a felhasználónál a korábban kiadott emailcímét.
És működött.

Nagy sóhaj.

Halálra replikálva

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

Ez utóbbi van most.

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

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

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

RTFM.

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

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

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

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

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

While we will have a full list of issues fixed when the Rollup releases, some of major issues are:

Exchange 2007 CAS cannot copy the OAB from the OAB share on Windows Server 2008-based Exchange 2007 CCR clusters

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

Angol tudósok

Oké, ez csak egy figyelemfelkeltő cím.

Valójában amerikai tudósokról lesz szó.

Kaliforniai egyetemeken megpróbálták tudományos módon (mérések, extrapolálás) meghatározni, mekkora hasznot hoznak a spam jellegű cuccok. Rászálltak a Storm botnetre, mértek, szabtak, következtettek – majd kijött egy becsült összeg.

De nem ez a lényeg. Hanem a végkövetkeztetés: a spambizniszben a legjövedelmezőbb tevékenység… az antispam termékek előállítása.
És az ember ne legyen paranoiás.

Az elfelejtett screencast

A tegnap publikált hat screencaston túl készült egy hetedik is, amiről teljesen elfeledkeztem. Ez egy alapozó lett volna az Informatika Tisztán csoportmunka részéhez, ami a végleges előadások összerakásánál kimaradt. Erről el is feledkeztem tegnap, így ezt most adom közre.

POP3 – SMTP

A demo kicsit benéz a motorháztető alá. Bemutatja, milyen forgalom zajlik a pop3 és az smtp protokoloknál a kliens és a szerver között, pontosabban arról szól, hogyan tudunk egy telnet kliens segítségével levelet küldeni és fogadni.

Exchange Screencastok

Az elmúlt két évben gyártottam összesen 6 db screencastot az Exchange 2007-el kapcsolatban. Ebből kettő még a termékbejelentés körül készült, a maradék négy pedig az idei Informatika Tisztán előadássorozathoz. Ez utóbbi négy valahogy sosem jutott el az interneten való megjelenésig (vagy csak én nem találtam meg őket). Itt most közreadom mind a hatot némi magyarázattal.

Certificate

Arról szól, hogyan készítsünk saját Windowos Certificate Authority-vel tanúsítványt az Exchange 2007-hez

Exchange 2007 – WM6

Bemutatja, hogy az Exchange 2007 és a Windows Mobile 6 együttes használata milyen újdonságokat hozott a mobil kommunikációban

Outlook Anywhere

Az Outlook Anywhere (leánykori nevén RPC over HTTP) és az Autodiscovery szolgáltatás konfigurációja szerver és kliens oldalon

Sharepoint Integráció

Kétirányú SharePoint integráció bemutatása. Hogyan lehet az Outlook Web Accessből Sharepointon tárolt dokumentumokat elérni, valamint hogyan lehet Exchange naptárat a Sharepoint felületre publikálni

User Import

Egy egysoros PowerShell script ami képes csv fájlból Exchange felhasználók tömegét gyártani

Windows Mobile Konfiguráció

Windows Mobile 6-os eszköz konfigurációja az Exchange 2007 ActiveSync-hez.

DataViz RoadSync 4.0

Megjelent a DataViz RoadSync nevű termékének új, 4.0-ás változata.

Azoknak, akik esetleg nem ismernék, ez a termék teszi lehetővé az ActiveSync for Exchange használatát nem Microsoft operációs rendszerrel rendelkező mobil eszközökön (pl. Symbian S60, Symbian UIQ, stb.).

Újdonságok:

– HTML levél kezelés

– Taszk szinkronizálás

– Névjegyhez kapcsolt fénykép kezelés

– Pop-Up értesítés az új levelekről

– Gyorsbillentyűk használata

– S60 3d Edition FP2 eszközök kezelése

Ez a hír már kb. egy hetes, úgy terveztem, hogy kipróbálás után írok a szoftverről, kicsit bővebben, ezért vártam vele. Ma végre sikerült felraknom a jó öreg Nokia E60-asomra. Kicsit csalódtam, mert lassabb lett a korábbi változatnál és az én készülékemen nem kezeli a HTML leveleket (ehhez S60 3d Edition FP1 a minimum verzió). A csalódottságom egyértelműen a telefonomnak és nem a szoftvernek róható fel.

További infók: http://www.dataviz.com

Outlook kapcsolók

Ezt leginkább csak magamnak.

Néhány kapcsoló Outlook indításakor:

  • /Cleanviews
  • /CleanProfile
  • /CleanReminders
  • /CleanRules
  • /ResetFolders
  • /Rpcdiag

Különösen ez az utolsó tűnik izgalmasnak.