Month: October 2007

OCS demó

1. nap

Bill Gates tegnap jelentette be San Francisco-ban, hogy mostantól a Unified Messaging felé kormányozzák az úthengert. Én meg már másnap OCS tréningen ülök.
Naprakész-e vagyok?

A szobában fullasztó a meleg, a hapi gyakorlatilag felolvassa a slide-okat. A tegnapi, hajnalba nyúló címtárkonszolidáció érdekesen interferál a ma hajnali felkeléssel. A slide-ok sötétbarna háttéren fekete betűk, én az első sorból, ha nagyon meresztem a szemem, el tudom olvasni. A többiek… ők a többiek. Az anyag kinyomtatva nagyjából olyan hatású, mint amennyire markáns kontúrokkal bír az alagútban harcoló néger hadfi szájában a Negro cukor.

És pont mellettem függ a falon ez a plakát.

Hirdetőtábla a folyosón: 8-as szoba, HP Printer Management Professional Technical tanfolyam. Atyaisten, ezek egész nap itt fognak zörögni mellettünk.

Amiért érdemes lett volna eljönni, az a sok-sok laborgyakorlat. Csakhogy… khmm… ez még nagyon béta. Eleve a laborok lejártak még a nyáron (óraátállítás), a gépeket meg le kellett húzni a hálózatról. Mittudoménmiért. Emiatt viszont baromira belassult minden – és teljesen kiszámíthatatlanná vált. Kb. a harmadik laborgyak után adtam fel. Ez vacak. A füzet köszönő viszonyban sincs a gépekkel és a kettő külön-külön is rossz.
Érdeklődve várom a holnapot, amikoris Exchange Unified Messaging szervert fogunk boncolni. Ha az jó lesz, akkor visszavonok mindent – én végülis ezért jöttem.

2. nap

Rögtön az első laborgyakorlaton a hasbaakasztás: a harmadik feladatot ki kell hagynunk, nincs SIP-IP gateway. Anélkül viszont bohóckodás az egész.
No, akkor ma megint fejben futtatjuk a laborgyakorlatokat. Ezzel a számítógépem is mélyen egyetért: az első gyakorlathoz szükséges virtuális gép már 50 perce bootol.

A legvacakabb az egészben, hogy itt ülünk vagy húsz számítógép között – és nincs net. Egy csomó embernek tartozok emailekkel, jó lenne látni, mi folyik a blogon is, a munkahelyen is meglehetősen izgalmas dolgokat hagytam magam mögött… de se ma, se tegnap nem fértem hozzá, otthon meg megint lelombozódott a tabletpc-m, szóval masszív netmegvonásban szenvedek.

Függőség?

3. nap

Ma átfutottam a roadshow anyagait. Csak a korrektség kedvéért:

  • Amit én ott sötétbarna háttérnek láttam a kivetítőn, az a ppt-ben halvány narancssárga.
  • Az előadáson érthetetlenül halk videóknak itthon teljesen normális hangja volt.

Azaz két feketepont átcsoportosítva az oktatóközpontnak.

Az egyiknek sikerül, a másiknak nem

Van olyan, hogy nem csak a politikus, hanem a szoftvergyártó is elk elrontja. De hogy annyira büszke legyen rá, hogy erre a hibára vizsgakérdéseket is hegyezzen ki, az már azért valahol pikáns.

A 70-237-es vizsgáról van szó, ez a neve: PRO: Designing Messaging Solutions with Microsoft Exchange Server 2007.

Nézzük a következő szituációt. (Ne örülj, a kérdés ilyen formában nem szerepel a vizsgán, itt csak az elv a lényeg.)
Van egy működő Exchange 2003 organizációd, benne egy Front-end és egy Back-end szerverrel. Ezt az egészet át szeretnéd slisszantani (transition) egy Exchange2007 organizációba, úgy hogy a végén legyen egy CAS/Mailbox/Hub Transport szervered. Milyen sorrendben tervezed megvalósítani a folyamatot?
Mivel utáljuk a komplikációkat, így egyszerűen azt mondjuk, hogy preparáljuk a címtárat, felhúzzuk a szervert a szükséges funkciókkal, majd átirányítjuk rá az owa.cegnev.hu címet, kiléptetjük a régi Front-end szervert, átmozgatjuk a postafiókokat, replikáljuk a public foldereket és a régi Back-end szervereket meghagyjuk az Sp1-ig. Működni fog? Nagyjából. De megdöbbentő módon, owá-n keresztül nem fogjuk elérni a public foldereket, hiába tartottuk meg a régi szervert is.
Mit ajánl ehelyett a módszer helyett a Microsoft? (Ugye, ezt is kell válaszolni majd a vizsgán.)
Azt, hogy húzzál fel először egy külön CAS szervert (HTR lehet rajta), majd egy másikra tedd a Mailbox/HTR szerepköröket. A többi már ugyanaz, mint az előbb. Azaz amíg nem jön ki az Sp1, addig nem egy, hanem két Exchange2007 szervered legyen – és a CAS ne legyen egy gépen a Mailbox szerepkörrel.

Természetesen ezt meg lehet tanulni. Hány olyan dolog van egyébként is, amit megtanultunk, de nem értünk?
De erre speciel van magyarázat.

Kicsit távolról futunk neki.
Az első sarokpont az, hogy az Exchange2007 Mailbox szerveren lévő public folderek webes protokollon keresztül nem érhetők el. Ezt mondjuk, tudtuk – de nem árt elismételni. (Majd Leonárd az Sp1.) Ezért kell a régi Back-end szerver, a public folderekkel.
Menjünk tovább. Amikor egy webes kérést le kell kezelni, az történhet átirányítással vagy proxyzással. Jelen esetben, amikor bejön a /public alkönyvtárra irányuló kérdés, akkor valaminek át kellene irányítania a kérést a régi Back-end szerverre. Ez az átirányítás nem működik az egyik esetben – és működik a másik esetben.

Merüljünk mélyebbre. Van két dll, a DaveX.dll és az ExProx.dll. Mindkettőben van olyan függvény, amely képes ennek az átirányításnak az elvégzésére. Csakhogy… a DaveX.dll ezt az átirányítást az FQDN alapján végzi. Pontosítok: a belső FQDN alapján. Azaz ül Átlag János felhasználó otthon, bedönget az owá-n, ott azt kapja, hogy menjen tovább az exhange-backend.cegnev.local szerverre – és erre azt mondja az Internet szolgáltatójának DNS szervere, hogy ‘mivan, vazze?’. Ezzel szemben az ExProx.dll sokkal intelligensebb, ő ezt tisztességesen le tudja rendezni, berkeken belül. Igenám, de ha a két dll együtt van jelen, akkor DaveX győz – az a DaveX, aki a Mailbox szerepkörrel települ.
Tehát ha egy gépen van a CAS/Mailbox funkció, akkor DaveX irányít, bele a semmibe. Ha külön van a CAS funkció, akkor ExProx irányít, a jó helyre.

Ennyi volt a mese. Látható, a rendszer két helyen is el lett cseszve. Valószínűleg egyszer majd ki is javítják ezeket a hibákat.
De addig vizsgakérdés lesz a körbedolgozásuk.

Az erő velünk van

Na, ja. Csak nem mindegy, mennyire körülményes kezelni. A végén még a saját kezünket vágjuk le vele.

Nemrég füstölögtem néhány enyhén szürkét arról, hogy mennyire értelmetlennek tartom a Powershell (tudom, Exchange Management Shell, de már annyira rááll a szám) parancsok bemagolásszintű visszakérdezését vizsgán. Úgy látszik, nem csak én, hanem egy fejlesztő társaság is, akik megalkották a PowerGUI-t.

A tudásáról nagyjából képet alkothatunk, rögtön a telepítés elején.

Nagyítás

Jól látható, hogy alapvetően három területre koncentrál: Exchange 2007, Operation Manager 2007 és Network. Ezekhez szép színes grafikus felületet kapunk, ráadásként pedig egy Powershell szkript editort.

Nagyítás

A fenti kép egy kicsit olyan, mint az az állatorvosi ló. Igyekeztem úgy sarokba szorítani a programot, hogy lehetőleg minél többet áruljon el magáról. Éppen ezért direkte olyat kértem tőle, mely kimaradt az Exchange Management Console-ból: kértem egy statisztikát az egyik felhasználóm postafiókjáról. (EMS-ben ez ugye úgy nézne ki, hogy get-mailboxstatistics 25ezer paraméter.) Az akciópanelen látszik, hogy a képernyőkimenetet mindenféle formátumú fájlokba irányíthatjuk. Lenyitottam a Tools menüt, bemutatva, hogy a GUI-ból is meghívhatjuk a szkript editort – és természetesen ez igaz visszafelé is. Végül alul látható, két nyomógomb: ezek közül a ‘Powershell Code’ feliratú az eddigi tevékenységünket naplózza vissza, értelemszerűen PSH kódban.

Még egy érdekesség.

Nagyítás

Az ugye tiszta, hogy bármelyik kattogtatás végeredménye egy Powershell parancs vagy szkript lesz. Ezt a szkriptet az adott menüpont tulajdonságaként kérdezhetjük le. A fenti képen például a Computers, azaz számítógépek listájának szkriptje látható – mely PSH szkriptbe ágyazott ADSI lekérdezésekből áll.

Szóval GUI. De nehogy azt hidd, hogy ellene vagyok a szkript alapú menedzselésnek, isten ments. Határozottan örülök a dolgok ilyetén alakulásának – csak éppen elijeszt a hatalmas paraméterkupac, és a körülményes keresgetés. Ezért is örülök én inkább a csomaggal adott szkript editornak.

Nagyítás

Ehhez a képhez véleményem szerint nem szükséges semmilyen magyarázat.

És hogy mennyibe kerül? A program jelenleg tokkal-vonóval ingyenes (béta), köszönhetően a Quest Software támogatásának. Ami biztos, az az, hogy a szkript editor ingyenes is marad. Azaz… hajrá, irány kipróbálni. Ahogy Dimitrij mondta, ‘Notepad for Powershell’.

ps:
Mondjuk, azért érdekes hintapalinta ez:

  • Először elkészül a Powershell (leánykori nevén Monad).
  • Aztán elkészül az EMS modul, mely tulajdonképpen a Powershellbe beépülő snapin.
  • Utána az Exchange fejlesztőcsapat elkészít egy MMC3 snapin-t, mely gyakorlatilag egy varázslókkal sűrűn telepakolt grafikus felület a leggyakrabban használható EMS/Powershell parancsok végrehajtásához.
  • Végül jön egy csapat, aki elkészít egy grafikus felületet, mely tudja mindazt, melyet az Exchange fejlesztők – ki tudja, miért? – kihagytak az általuk gyártott GUI-ból. Nem mellékesen odatettek egy script editort, melynek segítségével tényleg felszabadíthatjuk agyunk azon területeit, melyet eddig a parancs paraméterek foglaltak le.

Jogos lehet a kérdés: akkor most hogyan is állunk a szkript vs. GUI fronton?

Hátbatámadás

Érdekes hibakeresési módszert olvastam Dave Goldman blogjában. Azt mondja, vannak olyan esetek, amikor a Powershell úgy fut lyukra, hogy semmilyen értelmezhető hibaüzenetet sem ad vissza. Én ugyan még nem találkoztam ilyennel, de hiszek neki.

– Ilyenkor nyúljunk vissza a gyökerekhez – javasolja. (Hogy ehhez mit szólnak a gyökerek, arról nem szól a fáma.) Végülis az egész Powershell .net alatt íródott, így a hibakódot el lehet kapni a System.Exceptions objektumon keresztül.

Nosza, csapjunk bele. Írjuk be a hibát okozó parancsot, regisztráljuk, hogy nem jött értelmezhető hibaüzenet, majd olvassuk ki a hibát:

  • $hiba = $error[0]

Utána pedig nézzük meg, mit mutatnak az egyes tulajdonságok. Pl:

  • $hiba.Exception.StackTrace
  • $hiba.Exception.InnerException
  • $hiba.Exception.InnerException.StackTrace

Majd ha még ez sem elég, akkor a kapott hibakódot betáplálhatjuk az err.exe programba és még több információval leszünk gazdagabbak.

Gondoltam, megnézem, hogy is néz ki ez a gyakorlatban. Mint írtam, én még nem tudtam olyan hibát produkálni, melyről ne kaptam volna vissza hibaüzenetet – de mi lenne, ha leellenőrizném, hogy tényleg jó-e a hibaüzenet? Be is írtam egyből, hogy
get-publicfolder -identity kiskutyafule

A következmények alább láthatóak:

Az err.exe kimenetele pedig itt:

Nálam átment a vizsgán.

Mikor léptél be utoljára?

Aki már egy-két évnél régebben van az IT üzemeltetési szakmában, kilométerekről megérzi, mikor akarja a főnöke felvetni neki, hogy ‘Te, milyen jó lenne, ha egy szkriptben legyűjtenéd, kik azok a felhasználók, akik egy hónapja nem léptek be a rendszerbe.’. Ilyenkor kell pánikszerűen kivenni az éves garantált szabadságot és megvárni, amíg magától kihúny a láng a vezéri koponyában.
Miért is? Hiszen ez tulajdonképpen egy érték a felhasználó objektum egyik tulajdonságán. Ki kell olvasni oszt jól van.
Lelkes padavanok bele is szoktak ebbe a hibába esni. Legyűjtik, boldogan leadják a listát. Aztán jön a pofára esés: a listával szembesített felhasználók egy idő után karóval felfegyverkezve szándékoznak elbeszélgetni a lista készítőjével.
Mi történhetett? Hát, például az, hogy ezt a bizonyos értéket a tartományvezérlők khmm… közösülnek replikálni. Azaz ha pontos értéket szeretnénk tudni, akkor a korrekt módszer az lenne, hogy a lekérdezés során letámadjuk az összes tartományvezérlőt, majd kiválasztjuk a legközelebbi dátumot.

Nos, ezzel már készen is lennénk… de azért jogosan horgad fel a népharag: mi az már, hogy egy objektum tulajdonsága nem replikálódik? Azt mondja erre a Microsoft, hogy ha ezt a tömérdek adatot sűrűn replikálnák, akkor belehalna a hálózat. Lehet… végül is lehet. De akkor is bosszantó, hogy nem bízzák ránk a döntést, hanem azt mondják, így van, és kész.
Tulajdonképpen nem mondják. Nézzük csak meg az alábbi képet:

Van egy tulajdonság a tartomány objektumon. Úgy hívják, hogy msDS-LogonTimeSynchronization. Alapértelmezetten üres, ekkor 14 naponta replikálódik az az érték, hogy egyes felhasználók mikor léptek be utoljára. Ha ide beírjuk, hogy 1, akkor ez az érték lecsökken egy napra.
Nem mondom, hogy innentől naprakészek leszünk – de azért ekkor már sokkal jobban megközelítjük a valóságot.
Sokkal jobban, mint azok a szerencsétlenek, akik Windows2000 tartományban tengetik az életüket. Nézzük csak meg, nekik milyen lehetőségeik vannak:

Ennyi. Semmi msDS-LogonTimeSynchronization. Marad az összes DC nyaggatása adsi szkriptekkel.