Page 3 of 18

AntiSpam Update

Van egy dolog, ami már jó ideje bosszant.

Az Exchange 2007/2010 lehetőséget biztosít arra, hogy a Hub Transport szerveren feltelepísük a Microsoft AntiSpam agent-jeit. Ezzel kapunk egy jól működő, nagy tudású spam szűrő infrastruktúrát.

Ez ugyan nem annyira hatékony, mint a ForeFront for Exchange, továbbá nincs benne vírusirtó, viszont ingyen van.

Amikor ez a lehetőség először megjelent az Exchange 2007-ben, akkor lehetőségünk volt arra, hogy a hozzá tartozó definíciós fájlokat automatikusan frissítsük (Ez a ForeFront nélkül 3 hetente történt). Ez a lehetőség egy adott ponton megszűnt. Pontosabban, ha nincs ForeFrontunk akkor az Exchange maga nem frissít, hanem ezt a Windows Update teszi meg helyette.

Ezzel viszont gond van. Én magam részéről szerveren sosem kapcsolom be a frissítések automatikus telepítését (csak az automatikus letöltést), mert a folyamatos üzem miatt az nem elfogadható, hogy a szerver újrainduljon, amikor az update-nek ehhez van kedve, ráadásul bizonyos környezetekben a biztonsági frissítések csak tesztelés után kerülhetnek az éles rendszerbe. Ebből adódóan nem csak a biztonsági frissítések, hanem az AntiSpam definició sem települ automatikusan, aminek pedig kellene.

A fenti állapotot kezelendő írtam egy kis javascriptet ami feltelepíti az AntiSpam definíciós fájlt. És csak azt. Ha ezt a kis scriptet (cscript.exe SpamUpdate.js) berakjuk a Task Scheduler-be akkor a fenti problémát megoldottuk.

A script innen tölthető le.

Utállak, de ha erőszakos vagy, bejöhetsz

Elolvastam ezt az írást és kedvet kaptam rá, hogy eljátsszak az induláskor létrehozott @outlook.com accountommal. Az eredmény nem volt rossz, bár még messze nem próbáltam ki mindent.
Viszont a Gmail accountom átszippantása, az érdekes volt. Szépen beállítottam mindent, de csak egy kövér errort kaptam vissza. Az MS help szépen leírta, hogyan lehet engedélyezni a Gmail-ben a letöltést, de ezt ugyan írhatta, régen be volt állítva, hiszen mindkét gépem Outlookjából így kapkodom le, mondjuk úgy, hogy biztonsági másolatként. Más lesz itt a baki.
Meg is lett. Belépve a Gmail inboxba, láttam, hogy a fiúk nagyon óvják a postafiókomat. Azt írták, hogy egy nagyon gyanús helyről, bizonyos hotmail.com-ról valaki be akart lépni a nevemben, de ők résen voltak és nem engedték meg neki. A bestyének. Az, hogy mind a két gépemről be szoktam lépni pop3-mal és leszedem az inbox tartalmát, az nem zavarta őket. A hotmail.com, na az már igen. Én meg néztem, mint Rozi a moziban, mert a Gmail help csupa általános marhaságot írt arról, hogyan tudnám mégis engedélyezni ezt az utálatos hotmailt. Aztán a végén csak kinyögték a megoldást: menjek el egy linkre, ott nyomjak meg egy gombot, ekkor elindul egy számláló és ha tíz percen belül megint megpróbálkozom a gyanús helyről, akkor arról a címről leveszik a lockolást.
Azért félelmetes dolog ez a technika.

Testcsel

A fejlődés egész egyszerűen visszafordíthatatlan.

Nézzünk is rögtön két példát. Az Outlook blog például ezért lelkesedik:

One of the new features in Outlook 2013 that I’ve heard a lot of positive feedback about is Quick Response, which lets you write replies or forwards without leaving your inbox. This feature came about when we observed that people using Outlook often have a number of reply windows open, taking up screen space and complicating their experience of using Outlook.
To simplify the experience of responding to email, Outlook 2013 now lets you reply directly from your inbox, without the hassle of opening a new window.

Hát, igen. A válaszlevél nem új ablakban nyílik meg, hanem a gyors betekintő panelben. Ez igen. Hol is láttam utoljára ilyesmit? Már nem emlékszem pontosan, de mintha G betűvel kezdődött volna.

És mi történik közben a másik oldalon? Figyeljük meg, milyen újítást vezettek be a Gmail fejlesztői?

How many times have you been writing an email and had to reference something in another message? Saving a draft, opening the old email, and then reopening your draft wastes valuable minutes. The new compose pops up in a window, just like chats (only larger).

Azaz bevezették, hogy az új email komponálás – beleértve a válaszlevél komponálását is – immár új ablakban nyílik meg.

Csodás, nem? Ezek az egyértelmű, kiszámítható trendek. Feltételezem, mindkét helyen hosszas kutatómunka előzte meg a GUI átalakítást, ahogy az ilyenkor megszokott.

Vissza a múltba

Kérdés jött az ügyféltől: hát mi most mit csináljunk? A helyzet röviden: lejárt a korábbi tanúsítványuk, meg szerették volna hosszabbítani, de a szolgáltató már nem volt hajlandó olyan SAN tanúsítványt kiadni, amelyikben belső név (cegnev.local) is szerepel. Ekkor viszont összedől az Exchange publikálásuk.

Első körben az volt a reakcióm, hogy szolgáltatót gyorsan kirúgni és keresni helyette egy másikat, amelyik nem ennyire vaskalapos. De mielőtt válaszoltam volna, a biztonság kedvéért futottam egy kört a guglin, és… eltátottam a számat.

  • http://help.securepaynet.net/article/6935?ci=72665&prog_id=wittyweb&isc=ssl-01
  • Ha jól értelmezem, akkor a tanúsítványszolgáltatók összedugták a buksijukat és arra jutottak, hogy az internet biztonságosabbá tétele érdekében legkésőbb 2016 októberéig mindegyikőjük visszavonja az összes olyan, általa kiadott tanúsítványt, amelynek akár a Primary Domain, akár a Subject Alternate Name mezőjében belső név, vagy privát IP cím szerepel.
    Ezzel gyakorlatilag ki is nyírták az összes olyan Exchange publikálást, ahol a belső tartományt nem split DNS alapon hozták létre, azaz a belső tartomány neve nem egyezik meg a cég külső nevével. Azaz hiába örvendeztünk pár évvel ezelőtt, hogy vége a tengernyi szopásnak, használhatunk SAN tanúsítványt az Exchange publikálásokhoz… ennek vége. Elvették a játékunkat.

    Informatikai közhely, hogy a biztonság és a kényelem egymást kizáró fogalmak: ha szigorítom a biztonságot, csökken a kényelem. Mindenki ismeri a sztorit, hogy az egyre hosszabb, egyre bonyolultabb jelszavak elméletileg növelik a biztonságot, de csak egy ideig, mert ha a felhasználó már képtelen lesz megjegyezni, akkor leírja egy papírra és kiragasztja a monitorra. Nesze neked, biztonság.
    Úgy néz ki, most is elértünk erre a szintre. Mit fog csinálni az egyszeri rendszergazda? Az, amelyiket komoly felvilágosító munkával éppen nemrég sikerült meggyőzni, hogy felejtse el a saját tanúsítványt és használjon szolgáltató által kiadottat? Szó nélkül visszatér a saját tanúsítványra. Itt olyan SAN tanúsítványt állít ki, amilyet akar, a terjesztését meg megoldja valahogyan. Mert akkorát szigorítottak a biztonságon, melyet már nem tud lekezelni.

    Illetve… van egy másik út, a mazochizmus útja. Nem, nem arra gondolok, hogy átnevezzük a tartományainkat, vagy létrehozunk egy új Active Directoryt és átmigrálunk bele mindent. Ez már nem mazochizmus, hanem öngyilkosság. Ellenben visszautazunk a múltba. Oda, amikor az Exchange 2003 publikálásoknál még nem volt SAN tanúsítvány. Persze azóta a világ sokkal bonyolultabb lett, de az elv maradt a régi:

    Végeztünk? Hát, ha szigorúan az Exchange könyvtáraira gondolunk, akkor igen. De mi is van az Outlook Anywhere mögött? Az RPC over HTTPS, mely gyakorlatilag két könyvtár az IIS default site alatt. Igen, default. Tehát ezeket is duplázni kell az új site alá. Létezik new-rpcvirtualdirectory parancs? Nem igazán. Mi a megoldás?
    Hekk.
    Meg kell keresni a default web site alatt az ApplicationHost.config fájlt, átmásolni az új site alá, majd átmásolni az rpc, rpcwithcert virtuális könyvtárakra vonatkozó részeket, értelemszerűen módosítva a sitenév bejegyzéseket. (Részletesen itt olvasható a módszer. Senkit ne tévesszen meg, hogy ez az RD Gateway szolgáltatásra vonatkozik, a gyakorlatban ugyanazokat a virtuális könyvtárakat használja, mint az Outlook Anywhere. Egy korábbi, az RD Gateway-t is érintő írásomban az egyik módszer konkrétan úgy is kezdődik, hogy a TMG-n használjuk az Exchange varázslót a publikáló szabályhoz.)

    Haladjunk tovább:

    • Az új site-hoz kötözzük hozzá a tanúsítványszolgáltató által kiadott tanúsítványt (melyben már nincs benne a cegnev.local név).
    • A reverse proxy-n (ISA, TMG, etc) gondoskodjunk róla, hogy az új site szolgáltatásai legyenek kipublikálva. (A nevekre figyeljünk oda, amennyiben szükséges, forgassuk a könyvtárneveket is.)

    Nagyjából ennyi. Az Exchange már működik. De olyan nagyon azért ne sóhajtsunk fel:

    • Mi lesz a Sharepoint szolgáltatásokkal?
    • Mi lesz az RD Web oldalunkkal?
    • Végül mi lesz az OCS\Lync szolgáltatásokkal?

    Agyhalál. Biztonságos internet. Ja.

    Mail Flow

    Jézusom…

    Látjátok, amit én is?

    • Front End Transport Service (Ne már ne, ez rámászott a Client Access szerverre.)
    • Hub Transport Service (Na, ezt legalább ismerjük. Vagy mégsem? Mit keres ez a Mailbox szerveren?)
    • Mailbox Transport Service (Hoppá: a Transport maradék része is visszamászott a Mailbox szerverre.)

    Hé, emberek, hová tűnt Daemon Hill a HUB Transport szerepkör?

    Együtt működés

    Ügyfél úgy érezte, itt az ideje, hogy felrobbantsa felújítsa az informatikai rendszerét. Előbb-utóbb sor került a levelezésre is. A következő peremfeltételek szorongatták a projektet:

    • A telepített rendszernek a meglévőnél robusztusabbnak kell lennie. (Ezt nem volt nehéz megígérnünk.)
    • Licenszelési szempontból támadhatatlannak kellett lennie. Ez egész konkrétan azt jelentette, hogy mivel a felhasználók számához képest egynyolcadnyi Windows és Exchange CAL állt rendelkezésünkre, a többieknek valamilyen alternatív, de valamelyest igényes levelezést kellett biztosítanunk. (A maradék 7/8 egyébként laptopos-bolyongós külsős ember.)
    • Természetesen mindenki ragaszkodott hozzá, hogy mindenhonnan elérje a levelezését, minimum webes felületen és mobiltelefonon. Nyilván az utóbbit push metódussal.
    • A cégnek egy darab publikus IP címe van. A határon egy Cisco eszköz kezeli le a forgalmat.
    • A költségkeret adott volt. Emiatt fel kellett használnunk a korábbi licenszeket, így is éppenhogy maradt csak valami zsé új hardverre és licenszekre.
    • A meglévő rendszerhez képest Augeias istállója chipgyár tisztasággal bírt. Természetesen úgy kellett elvégezni az átalakítást, hogy minél kevesebb fennakadás legyen.
    • Függetlenül attól, hogyan oldjuk meg a levelezést, az összes alkalmazottnak ugyanazt a névteret – @cegnev.hu – kellett használnia. Egymás között is.
    • A meglévő levelezés nem veszhetett el, át kellett kerülnie az új levelezőszerverekre. Szerencsére public foldert nem használtak.

    Hosszas tanakodás után egy Exchange-Zimbra kooperáció mellett döntöttünk. Zimbra esetében nyilván az Open Source Edition jöhetett csak szóba. A webes elérés evidens volt, a mobilokhoz pedig jó lesz a Z-push.
    A router mögé egy ISA 2006 SP1 került. Sokat nem válogathattunk, ehhez volt licensz. Első elképzeléseink szerint majd ez osztja szét jól a https forgalmat.
    Ja.

    A TCP/IP-ből következően egy socketre (IP:port) csak egy listenert tudunk rakni. A HTTPS működéséből következően egy website-hoz csak egy tanúsítványt tudok hozzárendelni. Eddig oké.
    Csakhogy az ISA belekeverte a mókába az autentikációt is, méghozzá listener szinten. Azaz ha olyat akarsz csinálni, hogy egy IP címen fogadsz a 443-as porton különböző belső szervereknek szánt forgalmat (a tanúsítvány SAN vagy wildcard), és ezek a belső szerverek háklisan autentikálnak… akkor nagy bajban vagy. Mert a listener autentikál. Pontosabban, meg lehet neki mondani, hogy ne autentikáljon, de ekkor senkinek sem autentikál és ráadásul még ez sem igaz… de erről majd később.

    Akkor nézzük, miből élünk. Egy külső IP címünk van, azaz a socketből már csak a porttal tudunk játszani. Tudnánk. Csakhogy az Android alap Activesync kliense – legalábbis a Samsung telcsiken – nem enged portszámot beírni. Mivel a külsősök között informatikus még csak elvétve sincs, szóba sem jöhet, hogy letöltetünk velük valami appot. Ha létezik egyáltalán jó ingyenes. Tehát a Z-push és az Exchange ActiveSync (EAS) https forgalomnak ugyanazon a porton kell bejönnie, azaz ugyanaz a listener kell, hogy lekezelje. Ugyanazzal az autentikációval. Fincsi. (Nagyjából igaz ez a webes elérésekre is. A felhasználó kiszalad a világból, ha ilyen címet kell megjegyeznie, hogy https://exchange.cegnev.hu:50443/owa.)

    Oké, nézzük, be tudjuk-e gyötörni egy autentikáció alá ezt a négy forgalmat. Az OWA és az EAS berakható, jelenleg is így működik. A listener FBA-t használ, azaz formon keresztül bekéri a credential adatokat, valamelyik DC-ről autentikál, az autentikáció delegáció basic, azaz http/basic autentikációval dobja át a credentialt az Exchange szervernek. Mivel az egész kommunikáció HTTPS alatt megy, így a basic nem probléma. Viszont, mivel az autentikációt – beleértve az autentikáló szervert is! – a listenerben állítjuk, a Zimbra esetében gond lesz. Lehetne úgy persze, hogy a Zimbra felhasználókat felvesszük az AD-be, majd onnan autentikál a levelezőszerver – de ez már Windows CAL. Az meg nincs.

    From Segédlet

    Mik a szóbajöhető opciók? Domain, egyéb AD, Radius. Az első kapásból kiesik. A másodiknál fel kellene húzni egy Samba szervert a Zimbrán, a harmadiknál pedig kellene egy-egy Radius szerver mind a Windows tartományba, mind a Zimbra mellé. (Ez egy külön szépség a listener struktúrában. Egy listener csak egyféle autentikációt ismer. Habár azt meg tudom csinálni, hogy a bejelentkezéskor megadott domainnév alapján más és más Radius szerver autentikáljon, de azt nem, hogy a bejelentkezéskor megadott domainnév alapján az egyik esetben Windows LDAP tartományból, a másik esetben külső Radiusból autentikáljon.)
    Na jó. Kérdés a linuxos kollégához: meg-e lehet-e oldani? E? Fejcsóválás. Ha sima postfix lenne, akkor menne, de a Zimbra ennél kompaktabb cucc. Ha a megkerülésével piszkálnak bele az alatta lévő dolgokba, azok nem maradnának ott állandóan.

    Jó. Ez az irány nem működik. Az Exchange autentikációs beállításai nem jók a Zimbrának.

    From Segédlet

    Akkor mi a jó? Nem húzom az időt, egyfajta beállítással tudtam csak átgyömöszölni a Zimbra forgalmát: a listeneren kikapcsoltam az autentikációt, a szabályban pedig az autentikáció delegálásánál azt adtam meg, hogy a kliensek a célszerveren közvetlenül autentikálnak. Ekkor feljött a Zimbra FBA autentikációs képernyője. Ez ugyan nem öröm, hiszen általánosságban azért csak jobb az, ha már a tűzfal lerendezi az autentikációt, de ez van. Igenám, de jó lesz-e ez az Exchange-nek? Elméletileg jó lehet. A nagykönyv szerint, ahogy korábban is írtam, az a helyes beállítás, ha a listeneren form-based autentikációt állítunk be, a szabályban a delegálásnál basic autentikációt, az Exchange szerveren pedig szintén basic-et. (A tanúsítványokról most nem értekeznék külön. Az se volt egyszerű kör, de végül mind a két rendszert befaragtuk ugyanazon CA alá.) Ezt a konfigot rúgtam fel, úgy, hogy beraktam az autentikáció nélküli listenert, a szabályban átírtam a delegálást közvetlenre, az Exchange szerveren meg engedélyeztem az FBA-t. Bentről szépen működött is – kintről viszont azt kaptam vissza, hogy a szerver elzárkózott a kapcsolat elől. Jött némi vajákolás, engedélyeztem az FBA-t közvetlenül az Exchange IIS alatt is az OWA könyvtáron, de nulla eredménnyel. Megnéztem az ISA logot – és jó magasra felugrott a szemöldököm. Beérkezik kintről a https, az ISA terminálja… majd az Exchange felé már http-n megy tovább, mely próbálkozást az Exchange – jogosan – undorral dob el. De miért? A szabályban a bridging fül alatt nincs engedélyezve a http. Akkor ezt most hogyan? Ellenteszt. Visszaállítottam mindent, rögtön https-sel próbálkozott az ISA, az Exchange pedig elfogadta. Furdalt a kiváncsiság, megnéztem az itthoni tesztrendszeremben ugyanezt TMG-vel – és ugyanez lett az eredmény is. Fura. Ha azt mondom a TMG-nek, hogy ne erőlködjön az autentikációval egy linux szerver felé, akkor nem is variál… ha viszont ugyanezt mondom neki egy Exchange szerverrel kapcsolatban, akkor átvált http-re, még akkor is, ha ez nincs neki engedélyezve.

    Nos, ennyi volt a történet. Szomorú sóhajjal arrébb rúgtam az ISA szervert és betettünk elé egy Apache proxyt. Ez ugyanis nem tűzfal, de nem is fenyegetés elleni gateway, azaz nem foglalkozik az autentikációval. Terminálja a HTTPS kapcsolódást, a host header alapján tudja, milyen irányba kell továbbdobnia a kérést, immár egy új HTTPS kapcsolattal. Azaz az OWA és EAS mehet az ISA egyik hálókártyájára, a klasszikus listenerrel, a Zimbra forgalma meg mehetne az ISA másik lábára a ‘ne nyúlj hozzá’ listenerrel. (Azért használtam feltételes módot, mert a linuxos vonalnak nem ez lett a vége, de így is lehetett volna.)

    Megjegyzem, ha az ISA tudná az SNI-t (Server Name Indication), akkor még sokkal egyszerűbb lenne a dolog, akkor már a HTTPS terminálása előtt tudná a megcélzott host nevét, és ennek alapján ő maga tudna forgalmat szeparálni. De nem tudja. (Talán az UAG. De azt nem ismerem.)

    Tulajdonképpen ezzel a webes eléréseket lerendeztük. Az SMTP, na az szintén jó móka volt, de most hagyjuk. Ugyanis hátravolt még egy publikáció: egy belső RDS szerver alkalmazásait is ki kellett publikálnunk a külsősök felé. RdWeb, RDGW. Csakhogy: 1 IP cím. Az RDGW pedig ugyanazon a 443-as porton szeretne nyomulni, amelyiken már így is nagy a zsúfoltság. Az Exchange listenerje nem volt jó neki, innentől úgy gondoltam, ugyanazzal a trükkel bánok el vele, mint a Zimbrával: az Apache átdobja egy újabb virtuális kártyára, azon pedig olyan listenert csinálok neki, amilyet szeretne.
    Jó. De milyet szeretne?

    • Egyik módszer
      Ez egy tipikus MS howto a Technet Library-ből. Semmi extra, a jó öreg “pofabe” módszer: a listener nem autentikál, a delegáció pedig közvetlen.
    • Másik módszer
      Ez egy cikk az isaserver.org-ról, Marc Grote írta. Határozottan unortodox módszert követett, a listener autentikáció integrated (azaz ntlm), a delegáció kerberos constrained.
    • Harmadik módszer
      Egy másik cikk a Technet magazinból, viszont ezt két MS nagyágyú jegyzi: Shinder és Diogenes. A trükk az, hogy mivel itt ugyanazt az /RPC/* website-ot publikáljuk, mint az Outlook Anywhere esetében, hát csináljunk meg mindent az Exchange varázslóval. A listener autentikáció basic, a delegálás közvetlen.

    Erre szokták azt mondani, hogy a bőség zavara. Kipróbáltam mind a hármat. Egyik sem működött.
    Ahhoz már hozzászoktam, hogy nekem valahogy mindig jobban emelkedik a pálya, mint másoknak, de azért a függőleges fal még mindig meg tud lepni.
    Az RDS szerver oldalán minden rendben volt, rdweb, rdgw, tanúsítványok, házirendek. (Pedig itt sem volt egyszerű a pálya, ha próbáltál már eligazodni a kilométer hosszú nevek között egy _magyar_ nyelvű szerveren, akkor tudod, miről beszélek.) Odáig mindegyik módszerrel eljutottam, hogy az rdweb oldalon megjelentek az rdp ikonok. (A harmadik módszernél pluszban felvettem az /rdweb/* útvonalat.) Utána viszont állandóan csak autentikációs ablakokat kaptam, akármit is csináltam, akármilyen credential-t adtam meg.
    A megoldás természetesen pofonegyszerű, de az autentikációra utaló hiba megzavart, ezért állandóan csak azzal gyötörtem magamat. Beletelt egy napba, mire a fejemre csaptam és felhúztam a DMZ-be egy Windows7 gépet és közvetlenül arról próbálkoztam. Természetesen mind a három módszer működött, szó sem volt autentikációs hibákról.
    Egész egyszerűen az Apache nem tudja proxyzni az RPC over HTTPS-t, azaz nem fog menni az RDP over HTTPS sem. Amíg csak az RDweb-ig megyek, addig oké, az tiszta HTTPS… de utána váltunk, az indián meg elhasal. Kész szerencse, hogy az Outlook Anywhere nem volt benne a projekt szkópjában, mert az sem működne.

    A többi már nem túl érdekes. Az ügyfél kapott egy ultimátumot, miszerint vagy szerez egy másik IP címet, vagy kilógatjuk az RDS szervert valami lehetetlen porton, persze ebben az esetben övé a felelősség a biztonsági kockázatért. (Sőt, ha már lúd, legyen kövér, ebben az esetben kérünk még egy IP címet és kiváltjuk az Apache proxyt is. Mert mégiscsak egy spof, meg plusz kockázat.)
    De ez már nem technológia probléma.

    Egysorosból többsoros

    Aki rendszeresen Powershell környezetben tevékenykedik, annak ez az írás nem fog sok újdonságot tartalmazni. Nekem viszont meglepetés volt. Meg örülök is neki, hogy rátaláltam a trükkre.

    Van valami, amit meg szeretnél csinálni egy csomó objektummal. A nevük lista formájában megvan egy txt fájlban. Tipikus szkript feladat, kell egy foreach ciklus, ebbe betoljuk valahogy a neveket és kész.
    Igenám, de mi van, ha nem lehet egy parancsban megfogalmazni a ciklus magjában lévő tevékenységet? A szintakszis durván úgy szól, hogy foreach { }, ahol a kapcsos zárójelek közé kerül az elvégzendő tevékenység. Nekem viszont két parancsot kellett volna beletennem.
    Az első próbálkozásra szószerint kiröhögött a PSH: a szkript blokkba megpróbáltam több szkript blokkot beleágyazni, valami ilyesformán: { {a} {b} }. A második próbálkozásom az volt, hogy megpróbáltam a két parancsot egybegyúrni, a PSH végülis pont erről híres, de sehogyan sem sikerült. Harmadikra nekiugrottam a guglinak, de vagy én felejtettem el, hogyan kell keresni, vagy senkit sem izgatott eddig a probléma.
    Kénytelen voltam a saját eszemet használni. (A gugli korában. Szégyen.)

    A feladatnak van egy korrekt megoldása, nem parancsot adok ki, hanem beleírom az egészet egy szkriptbe, majd lefuttatom. Ott egyszerűen új sort kell kezdeni minden parancsnak. De ehhez eszembe kellett volna jutnia, hogyan kell szkriptet futtatni. (Ja, nem mondtam, ez nem egy kényelmesen elvégzendő feladat volt, hanem egy hirtelen felmerült igény, tizenvalahány óra szopás munka után.) Annyira emlékeztem, hogy van valami trükközés, de arra már nem, hogy végülis mi. Alternatív megoldás lehetett volna az ISE használata, de abba meg az Exchange plugint kellett volna valahogy belegyógyítanom, és az sem ment fejből. Félretettem az elképzelést B tervnek, én pedig tovább gyötörtem a parancskámat.
    Véletlenül jöttem rá a megoldásra. Még csak gépeltem be az egyik próbálkozást, amikor félrenyomtam, backspace helyett entert. És kaptam egy új promptot: >>. Szótlanul nézegettem a képernyőt, majd egy idő után bejelzett a mintafelismerő központom.

    “egyik”,”másik” | foreach {
    >>

    Ez teljesen olyan, mintha szkriptfájlba írnám a parancsot! Próbaképpen beírtam az egyik parancsot, enter, jöhetett az új parancs, enter, zárás, üres enter… és már futott is.

    “egyik”,”másik” | foreach {
    >> $valtozo=bonyolult művelet
    >> new-valami -identiy $_ -alias $valtozo -firlefranc
    >>}
    >>
    _

    Ne húzdd a szád, mondtam előre. Aki rengeteget piszkálja a PSH-t, annak ez triviális. Én már elég régóta inkább dizájnnal foglalkozom, mint operációval, nekem ez az interaktív szkript üzemmód újdonság volt. De tetszik.

    Viszont, hogy legyen hozzáadott érték is, összeszedtem, mi kellett volna ahhoz, hogy szkriptet futtassak. Egyszerűen a shellből elnavigálok abba a könyvtárba, ahol a szkriptfájl van, majd így futtatom: .\myscript.ps1.

    Ha pedig az ISE mellett döntöttem volna, akkor ezeket a parancsokat kellett volna elsőnek kiadnom:

    • Exchange 2007:
      Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin
    • Exchange 2010:
      Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010

    Export-mailbox, szomorodj meg

    Hajnalban megállt az export. Azt mondta, hogy

    Export-Mailbox : Error was found for XY (xy@cegnev.hu) because: Error occurred in the step: Approving object. An unknown error has occurred., error code: -2147221219 At line:1 char:2312
    + CategoryInfo: InvalidOperation: (179:Int32) [Export-Mailbox], RecipientTaskException
    + FullyQualifiedErrorId : 7D782610,Microsoft.Exchange.Management.RecipientTasks.ExportMailbox

    Próbáltam utánajárni, mi is lehet ez. Volt a neten minden, zárjam be az Outlookot (ki sem volt nyitva), állítsak be valós default gateway-t (be volt), vagy futtassak le egy fixmapi nevű programot. Pusztán kíváncsiságból ráküldtem ismét, minden módosítás nélkül ugyanazt a parancsot, amelyen elhasalt. (Természetesen az exportálandó postafiókok közül kivettem a már készeket.) Simán vette az akadályt, most is az fut.

    Megvan, mi lehetett a probléma: alvás közben nem imádkoztam elég intenzíven. Aztán eddig tartott a deikus töltet.

    Ideges? Á, egyáltalán nem vagyok az. De reggel simán bevettem a savcsökkentő (kék) gyógyszerem helyett az éjszakai (fehér) koleszterincsökkentőt.

    Halott ember visszalő

    Ezt írtam korábban:

    Itt már lejjebb adjuk az igényeket, eszébe se jusson windowsupdate-tel foglalkozni.

    Naív dolog volt azt hinni, hogy a windowsupdate ennyiben fogja hagyni. A nagy kapkodásban a kolléga ugyanis automatikus beállításon hagyta, én meg elfelejtettem leellenőrizni – őszintén szólva, egyikünknek sem jutott eszébe, hogy egyáltalán létezik – az a dög pedig, mármint a windowsupdate, hajnalban restartolta a gépet, teljeskörűen ignorálva azt, hogy milyen fontos processz fut rajta.
    Kora reggel, még félig kinyílt szemmel néztem rá a monitorra és elhűlve láttam, hogy nem látok semmit. Megszakadt a session. Meg a jókedvem. A kiadott utasítás ugyanis úgy nézett ki, hogy a get-mailbox parancs kimenetele volt belecsövezve az export-mailbox parancsba. Csakhogy a get-mailbox a jó ég tudja, milyen alapon rendezi sorrendbe a postafiókokat, de hogy nem ABC sorrendben, az biztos. Kénytelen voltam lehúzni egy listát, kimazsolázni, hogy kinek készült már el a pst-je, a többiek nevét pedig úgy összerakni egy szövegszerkesztőben, hogy be lehessen tolni az export-mailbox parancsba. Mindezt kora reggel, még kávé előtt.
    Oké, elkészült, parancs átmásol a PSH ablakba, enter – váratlan PS hiba. Ó, hogy szomorodj meg! De most legalább már tudtam a megoldást. Szerver, kliens újraindít. (Közben gyors kávé.) Beléptem a kliensre, parancs átmásol a PSH ablakba, enter – és ismét váratlan PS hiba. De most tényleg váratlan, mert még én sem számítottam rá. Egyből le is konyult az orrom. Ez most már minőségileg más helyzet, innen hogyan tovább? Aztán eszembe jutott egy fontos momentum: újraindítás közben elfelejtettem imádkozni. Tehát újraindítottam a klienst és a szervert _még egyszer_, közben barbár imákat mormoltam és a biztonság kedvéért elővettem a legcsúnyább nézésemet is. És most már elindult a szkript. Hogy az informatika egzakt tudomány? Persze, királyfi.

    Egyébként tényleg hihetetlen ez az egész és nevezhetném groteszk balszerencse-sorozatnak is, de vegyük észre, hogy van azért mögötte nem átgondolt, kapkodós gányolás is. Ha még emlékszünk, az Exchange 2007 trágya, félkész állapotban jött ki a piacra, és a nagyon várt, de időhiány miatt kimaradt funkciókat utólag hegesztgették bele, service és rollup pack-ek segítségével. Ilyen utólag beleműtött dolog volt az export-mailbox kibővítése a pst fájlok kezelésével. Ezen különösen látszik az utólagos toldozgatás, hiszen egy alapvetően szerveroldalon optimális folyamatot raktak ki a kilens oldalra, azért, mert ott már volt pst-t kezelni tudó MAPI motor, az Outlook. Igaz, emiatt a teljes adatbázismennyiséget át kell tolni kétszer a hálózaton, a feldolgozást egy erőforrásait tekintve sokkal-sokkal gyengébb gépen kell futtatni (Exchange 2007 esetén 32 bites kliensen), és akkor még nem is beszéltünk a kliensgépek speciális nyűgeiről, mint például a tipikusan automatikusra állított windowsupdate szolgáltatás, vagy éppen a rafinált csoportházirendek.

    Na, mindegy, újabb fél nap csúszás, azaz most már egy teljes nap.

    Powerhell

    Nevezhetjük szerencsének, de eddig még sikerült megúsznom a postafiókok nagy tömegben történő exportálását pst fájlokba. Eddig. Háát…

    A környezet ránézésre nem túl veszélyes. 230 postafiók, 160 GB adatmennyiség. A szerver jól méretezett. A kliens, amelyikről a másolást végezni kell – a lehetőségekhez képest – szintén.
    Ezen azért rugózzunk egy kicsit, mert később fontos lesz. Exchange 2007, az export-mailbox követelménye 32 bites(!) Outlook 2007, szigorúan 32 bites(!) Windows 7-en. Erre kell még egy 32 bites Exchange 2007 admin csomag.
    Még a tesztfázisban összeraktam egy virtuális kliensgépet, hogy ismerkedjek a folyamat dinamikájával. Másra nem is volt jó, mert diszk, az nem volt mögötte, de sikerült bejátszani a parancsot, eljátszottam a nyelvi beállításokkal, szóval felkészültem.
    A migrációra a helyi emberünkkel közösen összeraktunk egy kliensgépet. Az éles indulás előtt ezen is teszteltem egy kicsit, minden működött, mint egy svájci óra.
    Eldördült a startpisztoly, levélforgalom leállít, a kliensen parancs kiad, elégedetten hátradől. Kábé 10 percig. Ekkor kezdett el sikítozni a Windows, hogy eldobta az agyát. Konkrétan elfogyott a memóriája. Ezzel párhuzamosan a másolás is beállt, mint a gerely. Kilőttem a taszkot. Fejvakarás. Nem túl sokáig, mert a helyzet hamarosan világossá vált. A Windows ugye 32 bites, ebben a maximum RAM 4 GB lehet. Volt még a pagefile, a kettő együtt 10 GB. Az export-mailbox egyszerre 4 szálat indít és balszerencsémre rögtön az első csoportban benne volt a titkárság postafiókja, nem is mondom, mekkora mérettel. Lúzer hiba volt. Felnyomtam a virtuális memóriát 40 GB-re, restart, aztán elkezdtem újra.
    Nem indult el. A powershell fél perc szutykolódás után váratlan hibát dobott, a legsemmitmondóbb 1000-es hibaüzenettel. Újraindítás már volt, tehát ebben sem reménykedhettem. Mi romolhatott el? Persze, játszottam még a parancs maxthreads paraméterével, de el se jutott odáig a folyamat, a powershell sorra dobta a váratlan hibákat. Pedig addigra már megszokhatta volna.
    A leginkább logikus gondolat az volt, hogy amikor erőszakosan kilőttem a powershell processzt, akkor megsérülhetett valami alkotóeleme és azóta a PS nem tér magához. Telepítsük újra! Ahogy azt Móricka elképzeli. Mivel Windows 7 esetében már beépítve jön a PS 2.0, így nem lehet külön letölteni. Feature-ként sem lehet eltávolítani, majd visszarakni. Ekkor szóltam a kollégának, hogy B terv, kezdjen el telepíteni egy másik munkaállomást. Itt már lejjebb adjuk az igényeket, eszébe se jusson windowsupdate-tel foglalkozni. Én pedig előre menekültem. Rakjunk fel WMF3 CTP2 csomagot, abban van Powershell 3. Aztán majd meglátjuk, mit csinál. Semmit. Fel sem települt. Azt mondta, hogy neki szigorúan angol nyelv kell, ez meg nem az. De meg lehet engesztelni egy angol language pack-kel. Töltsük le! Hát, nem. Nyelvi csomag eleve a Windows Update-ről szedhető le, ultimate és enterprise Windows 7 esetén. Csakhogy mi itt professional verzióval szopunk. Elvileg leszedhető az MSDN-ről a teljes csomag, de mire a 2 GB lejön, addigra a kolléga újrahúzza a gépet. És még ekkor sem garantálja senki, hogy nyelvet tudok váltani, hiszen a professional eleve nem lehet többnyelvű.
    Csapásváltás. Menjünk vissza a legutóbbi rendszermentéshez, töltsük vissza, aztán telepítsünk mindent újra attól a ponttól. Röpke félóra alatt meg is csináltam, restart, újabb próba, újabb váratlan PS elszállás.
    Hát, ezzel nem jutottam sokat előre.
    Közben kolléga felhúzta az új gépet, gyorsan kipreparáltam, maxthreads a biztonság kedvéért kettőre állítva, aztán hajrá. Nem hiszed el: ezen is váratlan Powershell hiba történt. Meg lehetett volna mintázni rólam a bambaság szobrát.

    Vicc.

    – Doktor úr, nagy baj van!
    – Mi a panasza?
    – Ha megnyomom a lábam, fáj! Ha megnyomom a derekam, fáj! Ha megnyomom a tarkóm, fáj! Milyen betegség az ilyen?
    – Valószínűleg eltörött az ujja.

    Azaz ha több kliensen is ugyanazzal a hibával száll el egy folyamat, akkor lehet, hogy a szerver a hibás. Mágikus restart. A biztonság kedvéért a kliensen is. Másolás elindít, összes végtaggal imádkozik. És igen, ez volt a probléma, a Powershell váratlanul jól működik.

    Vegyük észre az eset szépségét. A 32 bites kliensen elindított, 32 bites Exchange modullal feljavított Powershell (aka EMS) menetközben meghívogatja a 32 bites Outlook MAPI motorját, ezen keresztül próbálja meg leszívni a szerverről a levelezési tartalmakat és kirakni pst fájlokba. Aztán elfogy a RAM, ki kell lőni a taszkot, és mi hal meg tőle? A szerver. Finom.

    Mindegy, elméletileg örülhetnénk is… csakhogy itt a háromnapos ünnepre terveztünk egy háromnapos átállást. Ebből elveszett a péntek délután, az export legjobb esetben is csak szombat délre fejeződik be és igencsak csipkedhetjük magunkat, hogy ezt a fél napot behozzuk valahogy.

    Én mindenesetre halk sóhajjal betoltam az Alvin albumot az mp3 lejátszóba.

    Ott szorít, ahol szűkebb

    Egy nagyon jó nyomozás leírása Paul-tól. Érdemes végigolvasni, megnézni, hogyan gondolkodott, milyen eszközöket használt és hogyan göngyölítette fel az esetet. Majd hasonlítsuk össze, hogyan oldottam meg anno én egy ránézésre teljesen különböző, de valójában ugyanarra a konfigurációs hibára visszavezethető problémát, pusztán a józan eszem és a Salvador Dali-féle paranoiac-critical módszer segítségével.

    A message tracking log használata – másképpen

    Minden Exchange admin nagy barátja a message tracking log, rendszerint ennek segítségével tudjuk átrugdosni a dögöt az utca másik oldalára, azaz így bizonyítjuk, hogy a levél rendben kiment az Exchange organizációból, a továbbiakban pedig legyenek kedvesek a fogadó oldali rendszergazdát zaklatni.

    Paul Cunningham mutatott be egy másik lehetőséget, melyhez szintén a jó öreg MTL-t használjuk: addig gyötörjük, amíg nem összesíti nekünk a napi levélforgalmainkat. Hasznos információ? Igen. Hozzá lehet férni valami egyszerű módon? Tudomásom szerint nem.
    A megoldást nem teszteltem, nem tudok beszámolni gyakorlati tapasztalatokról – de mindenképpen használható ötletnek tűnik.

    IE9 + Windows Update

    Telepítettem egy új Windows Server 2008 R2-t (a régi megdeglett, fátylat rá, hogy miért). Felraktam az összes szükséges update-et, de folyton közni, hogy márpedig ő IE9-et akar telepíteni (pedig már fenn van).

    Elkövettem egy Windows Update reset-et (SoftwareDistribution, catroot2 mappa töröl). A Windows Update friss meleg ropogósnak tűnik. Mint amit még sosem futtattak. Lefuttatom. Még mindíg közli, hogy kéne neki egy IE9.

    Gugli a mi barátunk:

    http://social.technet.microsoft.com/Forums/en-US/winservergen/thread/2c252dbe-c833-424d-9b75-4948bb8fb816

    Jó hosszú. Összefoglalva:

    1. Szedd le az IE9-et (a Programs and Features alatt, ha megjeleníted az update-eket akkor látod és le is tudod szedni)

    2. Rebbot

    3. Töltsd le a standalone telepítőt innen: http://windows.microsoft.com/en-US/internet-explorer/downloads/ie-9/worldwide-languages

    4. Telepítsd fel /update-no kapcsolóval

    5. A Windows Update-ből rakd fel a felkínált cumulative fix-et.

    A lelkes TMG

    Apróság, nem is akkora nagy szívás, de a kognitív energiák elszivárgása képes némi fogcsikorgatást előidézni.

    Van a DMZ-ben egy levelezőszervered – mondjuk egy Exchange Edge – és az SMTP portját egy TMG szerveren keresztül szeretnéd kipublikálni. Ez nem lehet komoly feladat, a varázsló 2004 óta szinte semmit sem változott. Illetve…

    From Segédlet

    Ez bizony egy zavarbaejtő kérdés. Azt mondja, van másik, van jobb… miért használod ezt a régi szutykot?

    Ne dőljünk be neki.

    Ha ugyanis az általa felajánlott E-mail Policy varázslóval publikálunk, akkor a szerverünk SMTP portja nem lesz elérhető kintről. Még ha véres verítékkel szétkonfiguráljuk a TMG-t, akkor sem. Egy apróságot ugyanis elfelejt a kuruzsló közölni: E-mail Policy-t csak és kizárólag akkor tudunk használni a TMG-n, ha telepítünk rá egy Exchange Edge szervert is.

    Az már egy teljesen más téma, hogy a fenti felállásban igencsak elgondolkodtató, hogy az Edge szervert ne a DMZ-be tegyük, hanem a TMG-re. Az integráltság ugyan növekszik – és ezzel vétünk a KISS-elv ellen – de megspórolunk egy Windows Server 2008 R2 licenszt. Amennyiben viszont más gyártó smarthostját használjuk, akkor nyomjunk pánikszerűen egy No-t és haladjunk tovább.

    Internet Database Availability Group

    Amikor elkezdtem olvasni Scott cikkét, egyből elcsöppent a nyálam. Épp mostanában van egy olyan munkám, hogy bár az ügyfélnek nincs túl sok pénze, de szeretne egy olyan HA megoldást két telephelyen, melyek még akkor is működnek, ha a Föld megsemmisül. Üzletpolitikailag meg nem mondhatjuk azt, hogy nem.
    Szóval olvastam, olvastam, és bár a működését elsőre még nem láttam át teljes mélységében, de nagyon tetszett a dolog. Végülis nem akárki írta a cikket, aki Scott Schnollnál többet tud az Exchange HA területről, az már festi magát. És pont most jöttek ki vele, pont amikor égető szükségünk lenne rá. Remek.

    A lelkesedésem egészen addig tartott, amíg észre nem vettem az írás végén a tag-eket.

    ps.
    Persze, folyamatosan nyüzsgött agyam hátterében a kisördög: mi is van azzal a kritikus round-trip latency-vel, az adatbázisok rpcclientaccessserver paramétereivel, na meg a CAS proxyzásokkal? De olyan jó lett volna hinni benne, hogy ezt mind-mind megoldották.