Mondd meg a neved és megmondom, ki vagy

A cím persze egy bugyuta paradoxon, ennek ellenére az Exchange esetében bosszantóan nem igaz. Amióta a termékkel foglalkozom, azóta igaz, hogy soha nem lehetett egyből megtudni az Exchange verzióját. A verziószámát igen, de abból a rendszergazdának kellett visszakeresnie, hogy pontosan milyen verziót, azon belül milyen szervízcsomagot, neadjisten rollup packot jelent a szám. Én ezt az oldalt szoktam használni, bár a RUP verziókra ez sem igazán működik. Azokhoz ez az oldal kell.

Szóval már akár működhetne is a dolog… ha megbízhatnál legalább a verziószámokban. De nem. Ha megnézed konzolból a Help/About menüpontot, akkor oké, ott megtalálod a korrekt verziószámot. De ha ugyanezt shellből - a mindenható shellből - szeretnéd megtudni… nos, így jársz.

Oké, oké, nem morgok, végülis egy tanácsadó ilyen apró trükkökből (is) él… de fiúk, muszáj volt ezt így megbonyolítani?

By JoeP március 9, 2010 at 20:25 Posted in: exchange One Comment

Szabálylista nyomtatása

Egyik ügyfelünknél megérett a helyzet arra, hogy gatyába rázzuk az ISA 2004 szerverük szabálylistáját. Évek hosszú során a tűzfal konfigurációja használhatatlanná evolválódott, bátran növelve ezzel az univerzum entrópiáját.

Ez egyben azt is jelentette, hogy nem halogathattam tovább a dokumentálás problémáját.

Az természetes, hogy az ISA konfig rendesen (automatikusan) mentve van. De ami nem igazán jött össze, az a szabályrendszer kiexportálása valami ember által emészthető formába. Fel is raktam anno az ISA Best Practice Analyzer-t, a Health Check része működött is, de az Isainfo a legváltozatosabb hibaüzenetekkel szállt el. Egy ideig még foglalkoztam is vele, de nem sok sikerrel. Más tool meg nem volt.
Maradtunk a mentéseknél.

De most nagyon kellett egy átlátható forma, mert konszolidálni monitorról, azt bizony nem lehet. Szöveges fájl, excel tábla… bármi, amit ki lehet nyomtatni, össze lehet firkálni.

Az első áttörés az volt, hogy az Isainfo-t kell használni. Nem, nem hülyültem meg… a helyzet az, hogy két Isainfo van. Az egyik az, melyet le lehet tölteni Jim Harrison oldaláról, a másik az, melyet beleintegráltak az ISA BPA-ba. A kettő között van egy árnyalatnyi különbség: az előbbi működik. Illetve van még egy: a két változat nem ugyanazt az xml struktúrát használja, azaz nem tudják egymás riportjait felolvasni.

Oké, feltelepítettem külön is (nem nagy ügy, javascript, fel kell csak másolni), elkészült az xml, majd a mellécsomagolt hta alkalmazással meg is tudtam jeleníteni. 1:0.

De hogy lesz ebből papír alapú lista? Hiába kerestem a ‘print’ nyomógombot, az istennek sem találtam. Hmm… hmm… Na jó, a gugli a barátunk (szószerint, mert egy igazi baráthoz méltóan már mindent tud rólunk), keressünk. Találtam is egy fórumot, ahol ezzel foglalkoznak. Odáig elmentek, hogy levelet írtak az alkotónak, hogy ugyan tegyen már bele egy ‘print’ gombot a programba. Erre ugyan nem jött válasz, de hamarosan megszületett a megoldás:

I sent Jim Harrison a suggestion to add printing to the HTA but got no reply. What I did was to hack out the right-click handler so that I can at least right-click => Print.

Azaz nyomj az alkalmazáson belül egy jobbklattyot és válaszd ki a menüből a print opciót.

Ugyanis mindenki ezerrel felejtette el, hogy ez nem exe, hanem hta alkalmazás. Azaz önállóan futtatható, web alapú. Azaz mindazon opciók működnek a jobbklattyra, mint amelyek egy böngészőben.

Innentől persze már egyszerű az élet. Jobb kattintás, Select All, majd az egész szöveg mehet át egy txt fájlba, melyet utána már úgy faragok, ahogy akarok.

By JoeP március 3, 2010 at 19:36 Tags: ISA Posted in: ISA One Comment

2010 CAS NLB

Véleményem szerint Exchange 2010 HA témakörben a legforróbb terület jelenleg a CAS NLB: egyszerűen szükség van rá, nem lehet megkerülni - viszont igazán optimális megoldás nem létezik.

Ezt írtam itt. És szemmel láthatóan nem csak engem zavar a dolog. Egy MVP kolléga ki is fakadt a blogján - segítve rajtam, mert így nem nekem kellett megírnom a cikket.

By JoeP március 3, 2010 at 18:17 Tags: exchange 2010 Posted in: exchange 2 Comments

Rasszista TLD

Kutyafuttában, mert tényleg őrült nagy hajtás van.

Belecsöppentem egy újabb remek nemzetközi projektbe. A héten megy az adatgyűjtés, illetve a tesztlabor összerakása. Nem kicsi laborról van szó, rögtön indulásképpen 5 tartományból álló erdőt kell összekötözni két másik erdővel.

A külső erdőknél igyekeztem semleges nevet választani. Az első az lett, hogy akarmi.akarhol. Szépen le is mentek vele a kísérletek. Ekkor derült ki, hogy az egyik partner élesben már Windows 2008 erdőt használ, tehát azt is le kell tesztelnünk. Így jött be még egy erdő, ennek roppant frappánsan az akarmi.akarhol.2008 nevet adtam. Tartomány működik, kliensgépet be lehetett léptetni.

A DNS rendszereket összelőttem, nslookup oda-vissza feloldott minden címet, minden tartományban. Oké, a biztonság kedvéért jöjjön egy ping. Semmi. Nincs ilyen cím.

Aha. Biztosan elgépeltem. A felfelé nyíllal elővettem a korábbi sikeres nslookup sort, átírtam pingre - nincs ilyen cím.

Aztakurva. Ezt meg akkor hogyan? Az nslookup feloldja a címet, a ping meg nem? Dehát nem ugyanazt az algoritmust használják? Mi van itt?

Egy bájos, nem túl gyakran kommunikált bug. Pedig valamikor mintha olvastam volna róla, csak most későn jutott eszembe: a TLD nem lehet szám. Azaz a tartomány nevében bárhol használhatok számot, de a legutolsó elem nem lehet az.

Lebontottam az új tartományt, létrehoztam egy másikat akarmi.akarhol.longhorn néven - és azóta is tökéletesen megy minden.

Csak éppen kiesett egy fél nap. Azon meg már nem is morgok, hogy valami, akármelyik fázisban, igazán figyelmeztethetett volna, hogy ‘hé, te, ez a cím nem lesz frankó mindenhol’.

By JoeP január 28, 2010 at 18:18 Tags: névfeloldás Posted in: active directory 4 Comments

Geek úr nyaral

Nem tudom, te hogyan vagy vele, én nagyon aggódós utazásszervező vagyok. Akkor nyugszom meg, ha előre minden le van foglalva, ki van fizetve. Igaz, ekkor meg azon szoktam parázni, hogy időben odaérünk-e mindenhová.

Tudtam, hogy hová akarunk menni a nyáron. Igaz, még január volt, de mivel konkrét eseményre terveztünk, az időpont biztos volt. Maga az esemény miatt jókora tömeg várható, a kiválasztott kemping pedig picike. Ráadásul éppen erős is a forint - ergo minden jel afelé mutat, hogy már most foglaljam le a szállást.

Elmentem a weblapra, megkerestem a Reservation menüpontot.

Erre feljött egy iframe-be ágyazott webes form. Kitöltöttem az adatokat, rányomtam a ’send’ gombra. Kaptam egy kövér 404-est.

Ez bizony baj. Lemenjek úgy, hogy nincs biztos szállás? Egy ilyen frekventált időpontban?

Akkor már inkább varázsoljunk.

Első lépés: keressük meg, melyik az az oldal, amely végül nem érhető el. Szerencsére a Wireshark mostanában gyakorlatilag bootoláskor indul, így nem okozott gondot a beröffentése. Eljátszottam ugyanezt a foglalást.

A webes formok adatait az OK gomb megnyomására egy POST paranccsal szokták elküldeni a webes alkalmazás számára. Rakjuk össze a HOST headert és a POST paraméterét: www.veniceincoming/camp/.okmailnew.asp. Ennek az alkalmazásnak kellene átadni a kép alján található szép nagy emaildest változó értékét.
Csakhogy az alkalmazás sztrájkol. Vagy kiment pisilni. Nincs.

Ami elsőre gyanús, az a ‘.’ karakter az URI-ban. Nem szoktak. Írjuk be anélkül az egészet a böngésző címsorába: és rögtön egy alkalmazásoldali hibaüzenetet kapunk.
Első lépésnek jó. Megvan az alkalmazás, a hiba meg jogos, hiszen tényleg nem adtam át semmilyen paramétert.

Nosza.

Alapvetően két stratégia közül választhatunk. Kezdjük az ‘ököllel szöget falbaverős’ technikával.

Megkértem a Wireshark-ot, hogy az elkapott csomagokból rekonstruálja a teljes forgalmat.

GET /camp/auk.asp HTTP/1.1
Host: www.veniceincoming.com
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/532.0 (KHTML, like Gecko) Chrome/3.0.195.38 Safari/532.0
Referer: http://www.campingsannicolo.com/uk/contattaci-italiano.htm
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Encoding: gzip,deflate,sdch
Cookie: ASPSESSIONIDSQRCQASS=CGGHHKLCBAPCGHMGBFPEJFIC
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6,hu;q=0.4
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

Ez volt a kemping weblapjának lekérése.

HTTP/1.1 200 OK
Date: Tue, 19 Jan 2010 18:19:33 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Content-Length: 26933
Content-Type: text/html; Charset=windows-1252
Cache-control: private

<!DOCTYPE html PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN”>

<html>

Innen jött egy bazi nagy HTML lap. Miért is? Ugye elment egy GET kérés, arra jött egy 200 OK válasz. Nemrég tanultuk, hogy ennek a válasznak a message blokkjában jön vissza a lekért oldal. Mi választja el a message és a header blokkokat? Üres sor. És tényleg.

</body>

</html>

POST /camp/.okmailnew.asp HTTP/1.1
Host: www.veniceincoming.com
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/532.0 (KHTML, like Gecko) Chrome/3.0.195.38 Safari/532.0
Referer: http://www.veniceincoming.com/camp/auk.asp
Content-Length: 342
Cache-Control: max-age=0
Origin: http://www.veniceincoming.com
Content-Type: application/x-www-form-urlencoded
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Encoding: gzip,deflate,sdch
Cookie: ASPSESSIONIDSQRCQASS=CGGHHKLCBAPCGHMGBFPEJFIC
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6,hu;q=0.4
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

emaildest=info%40campingsannicolo.com&cognome=Jozsef&nome=Petrenyi&
email=jpetrenyi%40gmail.com&fax=&mese_arrivo=05&giorno_arrivo=21&anno_arrivo=2010&
totale_notti=3&numero_adulti=4&numero_bambini=&V-TADU=0&V-B2%2F10=0&V-R%2BAUTO=0&
V-CAMP=0&V-TG=0&N-TX2=0&N-TX4=0&N-R4%2F5=1&N-SP=0&N-LAV=0&N-BICI=0&N-ELE=1&
N-PARK=0&N-PARK-M=0&Note=&Submit=Send

Itt történik a lényeg. Először vége van a nagy HTML oldalnak. (Nyilván közben kitöltöttem a mezőket és rányomtam a Send gombra.) A POST paranccsal indul az adatok feltöltése. Egy csomó fejléc mező után jön az üres sor, majd a message blokkban ott figyel az a karakterlánc, melyet a form rakott össze és melyet az alkalmazásnak már jó étvággyal el kellene fogyasztania.

HTTP/1.1 404 Not Found
Content-Length: 1635
Content-Type: text/html
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Date: Tue, 19 Jan 2010 18:20:12 GMT

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01//EN” “http://www.w3.org/TR/html4/strict.dtd”>
<!HTML><!HEAD><!TITLE>The page cannot be found</TITLE>

De nem teszi meg, ehelyett visszajön egy 404-es hibakód. (Emlékszünk, kliens oldali hiba.) Azaz nincs olyan weblap - jelen esetben alkalmazás, melyet meg akartunk hívni.
Az üzenet message blokkjában még ott van egy formázott HTML üzenet is, hogy a nem kockafejűek is értsék, miről is van szó.

Nos, itt van előttünk a teljes folyamat. Minden parancsot, minden fejlécet, minden message blokkot ismerünk. Azt is tudjuk, hogy a POST parancsban van elgépelve az alkalmazás neve.

Mire várunk? Putty.

Rácsatlakoztam a webszerver 80-as portjára. Soronként átmásoltam a parancsokat a Wireshark kimenetéből. Ahogy egy üres enter-rel jeleztem, hogy vége a parancsnak, rögtön meg is kaptam a weblapot.

Ha ez most egy böngésző lett volna, akkor értelmezte volna a HTML kódot és szép, színesszagos weblapom lett volna. De most szöveges kliensem van, abban meg így néz ki a weblap.
Képzeletben kitöltöttük a formot, vissza szeretnénk küldeni.

Vegyük észre, a küldés első sorát, a POST parancsot nem ész nélkül másoltam be. Töröltem a ‘.’ karaktert. A többi maradt. A message blokk utáni üres enter után el is ment a csomag.

Sajnos kiábrándító eredménnyel. Hiába találtuk meg az alkalmazást, hiába adtunk át neki egy teljesen szabályos adatcsomagot, az alkalmazás hibát dobott. Maximum annyi vigaszt meríthetünk, hogy ez egy 500-as hibakód, azaz kliensként már jók vagyunk, most a szerver dobta el az agyát.

Mondtam, hogy van egy másik módszer is. Egyszerűbb is, elegánsabb is… de kevesebbet lehet belőle tanulni.

Első lépésben lementjük az iframe-ben lévő weboldal forráskódját. Remélem, ezt nem kell külön részleteznem.

Megkeressük a form parancs action paraméterét. És tényleg, ott van a hibás hivatkozás az alkalmazásra. Kijavítjuk, méghozzá úgy, hogy nem a relatív hivatkozást hagyjuk benne - hiszen a HTML fájl most már itt van a lokális vinyónkon - hanem az abszolút URI-t. Elmentjük, megnyitjuk a böngészőnkben. Kitöltjük a formot, send.
Hiba.

Ugye látjuk, hogy ez szószerint ugyanaz a hiba, mint amilyet a Puttyban kaptunk - csak itt a böngésző jelenítette meg a szöveget.

A hibaüzenetből egyébként annyit lehet látni, hogy ez egy asp.net alkalmazás, méghozzá a nevéből itélve egy levélküldő alkalmazás. Valószínűleg az lett volna a terv, hogy az alkalmazás emailben elküldi a kempingnek a regisztrációs adataimat - csakhogy a formból rosszul hívják meg, nincs megadva az a cím, ahová a csomagot küldeniük kellene.

Ez ellen már nem segít semmilyen trükközés. Megkerestem a kemping emailcímét és elküldtem nekik szép, ember által is érthető szöveges formában a foglalási igényemet.

- Az írás egy hamarosan megjelenő könyv része. -

By JoeP január 20, 2010 at 01:53 Tags: network Posted in: általános 4 Comments

Éj a szerverszobában - 02

Oké, szorgalmatos rőzseszedegető anyókaként kezdjünk el gyűjtögetni.

Rögtön van egy rossz hírem. Az eventlog nagy. Nem, még annál is nagyobb. És nekünk ebből kell kimazsolázni durván egy hónap Online Maintenance bejegyzéseit.

Akár fel is vehetnénk középső névnek a Hamupipőkét.

Nos, akinek szerencséje van, az Windows Server 2008-ra telepítette az Exchange szerverét. Itt ugyanis már tudunk custom view-t generálni az eventlogon belül. A Windows Server 2003 kedvelői… most így jártak. Hamupipőke.

A fenti ábrán láthatók a custom view beállításai. Úgy gondolom, a kép magáért beszél.

Ha beállítottuk, akkor a következő nézethez jutunk. Mekkora öröm, már… csak és kizárólag az OM bejegyzéseket látjuk. Nem mintha ebből nem lenne durva még kinyerni az összetartozó adatokat… de legalább már van némi esélyünk.

A következő event azonosítók vonatkoznak az Online Maintenance folyamatra:

700: Online defragmentation is beginning a full pass on database XY
Az XY adatbázison elindult az offline defregmentálás.
701: Online defragmentation has completed a full pass on database XY
Az XY adatbázison befejeződött az offline defregmentálás. Ekkor kiír egy csomó adatot. Az általa jelzett időtartamokkal ( x sec) bánjunk óvatosan, köszönő viszonyban sincsenek a mért értékekkel. Viszont az átmozgatott lapok száma hasznos információ: egy lap 8 KB (Exchange 2003-ban 4K), tehát ebből megtudjuk, mekkora hely (whitespace) szabadult fel az adatbázison belül.
702: Online defragmentation is resuming its pass on database XY
Korábban lezárt folyamat folytatása. (Egy folyamat lezáródhatott úgy, hogy váratlanul nagy terhelés érte az adatbázist, illetve lezáródhatott úgy, hogy letelt a folyamatra engedélyezett időablak.)
703: Online defragmentation has completed the resumed pass on database XY
Lezárult egy olyan folyamat, mely menetközben meg lett megszakítva.
704: Online defragmentation of database XY was interrupted and terminated. The next time online defragmentation is started on this database, it will resume from the point of interruption.
Az XY adatbázis online defregmentálása meg lett szakítva.
717: Database checksumming background task has started.
Elindult egy Online Checksumming folyamat.
718: Database page zeroing background task has started.
Elindult egy Page Zeroing folyamat.
721: Database checksumming background task has completed.
Lezárult egy Database Checksumming folyamat.
722: Database page zeroing background task has completed.
Lezárult egy Page Zeroing folyamat.
723: Database checksumming background task encounters an error.
A Database Checksumming folyamat közben hiba történt.
724: Database page zeroing background task encounters an error.
A Page Zeroing folyamat közben hiba történt.
729: Database page zeroing has been paused.
A Page Zeroing folyamat félbeszakadt.

Na, kérem, mindent tudunk. Már csak dolgozni kell.

Az első feladat lesz a legkönyebb: ne csináljunk egy hónapig semmit. Hagyjuk az adatbázisokat az alapértelmezett értékeken - és várjuk, hadd gyűljenek a bejegyzések.

Az eventlogból kigyűjtött adatokat táblázatban összesítjük.

Igen, tudom, hogy erre a feladatra lehetne szkriptet is írni. De most levetkőzöm a rendszergazda mentalitást és azt javaslom neked is, hogy bogarászd ki egyenként az adatokat és szépen gépeld be mindet az Excel táblába. Hidd el, ennek hamarosan meglesz a jelentősége.
Ugyanis ahogy készen van a táblázat, jöhet az optimalizálás. Az egyetlen olyan feladat, amelyre nincs algoritmus. Csak te vagy és a józan ész.
Ezért fontos, hogy mire ide eljutsz, összebarátkozzál az adatbázisokkal. Ha egyenként gyűjtöd be az adatokat, akkor már menetközben össze fognak állni a történetek. Jellemük, viselkedésük lesz az adatbázisoknak. Lesz a lusta disznó. Lesz a lassú behemót. Lesz a szorgalmas cingár. Látod, hogy amíg az egyik nem és nem ér egy folyamat végére, mert mindig megszakad, addig a másik olyan sokszor zajlódik le, hogy rendszerint már nulla, vagy tíznél kevesebb lapot szabadít csak fel. Megtapasztalod, mitől függnek az időértékek.
Mire kitöltöd a táblázatot, előtted lesz az egész bagázs, mint osztályfőnök előtt a diákok az első év végén.

Optimalizáljunk.

Tételezzük fel, hogy CCR rendszerünk van, a backup a paszív node-ról megy, azaz az OM mehet az aktív node-on. Az egyszerűség kedvéért most ne foglalkozzunk a Database Checksumming folyamattal.

A munkaidőt természetesen tiszteletben tartjuk, tehát reggel 7 és este 7 között az üzleté a terep. Hétvégén viszont mi vagyunk, egész nap.
Ez annyi mint 5*12+2*24 = 108 óra.
Mennyi is jött ki a táblázatból?
21+9+9+21=60. Simán beleférünk. Mi itt a probléma?

Hát példul az, hogy az OM folyamatok nem annyira udvariasak, hogy pont az időintervallum elején induljanak el. Akkor általában már egy korábban félszakadt defrag fog folytatódni. Azaz, ha teljesen biztos akarok lenni abban, hogy egy héten belül biztosan lemenjen minden adatbázisra az OM, akkor dupla annyi időt kell kapniuk, mint amennyit mértünk. Ez 120 óra.
Annyi viszont nincs.
Jöhetnek a kompromisszumok.

A DB04 a VIP adatbázis. Itt nincs kompromisszum, sőt, ők inkább 44 órát kapnak, azt is összefüggően. A DB01 adatbázisban is vannak kritikus postafiókok, ők is megkapják a 42 órájukat. Viszont mi lenne, ha a maradék két adatbázis ugyanabban a szegmensben lenne? A szerver elbírja (úgyse dolgozik éjszaka rajta senki), és ha a maradék időt (108-44-42=22) adjuk oda nekik, akkor jó eséllyel mind a kettő le tud futni egyszer.

Itt is van. A VIP 44 óra és nem szakad meg, a DB01 42 óra, de azért már szakadozik, a többiek meg majd csak ellesznek valahogyan.
De ez már egészen jó kiindulási alap.

Már csak egy lépés van hátra, belőni a backupot. Habár a két folyamat független egymástól, de célszerű a mentést rögtön az OM utánra időzíteni, így gyorsan el is takarítjuk a felesleges logfájlokat.

És ugye nem felejtettük el, hogy negyedév múlva újra elvégezzük a vizsgálatot, megnézzük, hogy amit kitaláltunk, mennyire működik jól hosszú távon.

Hasznos linkek:

By JoeP január 4, 2010 at 20:58 Posted in: általános No Comments

Éj a Szerverszobában - 01

A háttérben tessék elképzelni az Éj a Kopár Hegyen dallamát. (Ugye, a Sátán fellátogat a Földre, az őt imádó boszorkányok szombatjára.)

Nos, azt mi csak hisszük, hogy amikor estefelé végre becsukjuk a szerverszoba ajtaját és hazaindulunk, akkor a szerverek kismacskaként összekucorodnak és békés dorombolás mellett várják, hogy majd reggel megint eléjük borítjuk az ennivalót. Szervereink - ha jól vannak nevelve - akkor bizony éjszaka sem pihennek. Ilyenkor jön el általában a backup ideje - és természetesen a különböző adatbázis-karbantartásoké is.

A mostani írásban az Exchange szerver adatkarbantartási folyamataival fogok foglalkozni.

A backup-pal speciel nem. Meg később se nagyon. Az Exchange-t illetően jelenleg ez a legképlékenyebb terület, ahol éppen nem technikai megoldások, hanem koncepciók rivalizálnak.

Az adatkarbantartás, azaz nevezzük már nevén, az Online Maintenance, mindig is benne volt a termékben, de soha nem került úgy igazán a reflektorfénybe. Olyan félénk fajta a szentem. Pedig nem kellene szégyenkeznie, mert nagyon fontos szerepe van. Viszont egészen a 2010-es verzióig olyannyira visszafogottan viselkedett, hogy amint nagyobb terhelés érte az adatbázist, rögtön leállt. Azaz hiába időzítettük be adatbázisonként, hogy minden este fusson le, ha ráindítottuk közben a backupot is az adatbázisra, akkor az OM kiszállt a partiból. Majd holnap - gondolta. De ha másnap is jött az erőszakos backup… akkor az OM soha nem futott le végig.

Részletesebben a 2007-es verzióval fogok foglalkozni, de azért vetünk majd egy pillantást a 2010-esre is.

Adatkarbantartás. Mit is takar ez a fogalom? Miket kell csinálni azokkal az adatokkal, hogy karbantartva érezzék magukat?

A következő folyamatokról van szó:

Purge Indexes
A törölt pointerek fizikai eltávolítása az indexfájlból.
Tombstone Maintenance
A törölt elemek törölt státuszát jelző sírkövek menedzselése, lejárat esetén törlése.
Dumpster Cleanup
A törölt elemek - egy beállítható ideig - nem kerülnek törlésre, hanem egy átmeneti tárolóba esnek be. Ezt hívjuk Dumpster-nek. Amint letelik az idő, véglegesen törlődnek.
Public Folder Expiry
A nyilvános mappákban beállítható, meddig ‘élhet’ egy elem. Ezek lejártát vizsgálja a folyamat.
Age Folder Tombstone for Public Stores
Hasonló a korábban említett sírkő kezeléshez. A különbség annyi, hogy nyilvános mappa esetén a public folder replikációt is figyelembe kell venni.
Folder Conflict Aging for Public Stores
Azonos időben módosított nyilvános mappák konfliktusfeloldó folyamatának indítása. (Levelek küldése a két módosítónak.)
Update Server Versions for Public Stores
A nyilvánosmappa replikációkhoz kapcsolódó verziószámok frissítése.
Site Folder Check for Public Stores
Annak ellenőrzése, hogy az Administrative Group-on belül ne legyenek duplikált Site Folderek.
Cleanup Deleted Mailboxes for Mailbox Stores
Azoknak a postafiókoknak a kezelése, melyekhez már nem tartozik tulajdonos felhasználó.
Check Messages Table
Azoknak az elemeknek az eltávolítása, melyekre nem mutat pointer.
Online Defregmentation
Tulajdonképpen ez az a folyamat, amellyel nagyon sokan összekeverik az Online Maintenace folyamatot. Tény, hogy ez a leglátványosabb eleme, de azért bőven nem csak ez játszódik le.
Az Exchange adatbáziskezelésének a módszeréből következik, hogy a törölt elemek után lyukak maradnak az egy nagy fájlként látszó adatbázisban. Ezek a lyukak későbbi adattárolásra alkalmatlanok. Célszerűen az Online Defregmentation folyamat ezeket a lyukakat (whitespace) rendezi egy helyre, elérve azt, hogy az így kialakuló területek újra részt vehessenek az adattárolásban. Ezzel lehet biztosítani azt, hogy ha már az adatbázis mérete nem csökken, akkor ne is nőjön - feltéve, hogy az újonnan létrejövő elemek száma nem haladja meg jelentősen a töröltekét.
Database Checksumming
Normál Exchange szerver esetén mentés során megtörténik a tranzakciós logok rájátszása az adatbázisra, emellett pedig lefut még egy adatbázis-integritás ellenőrzés is. Amennyiben CCR Exchange clusterünk van, amelynél a passzív node-ról mentünk, akkor az aktív node-on lévő adatbázisokra soha nem fog lefutni az integritás ellenőrzés.
Ezt lehet úgy kivédeni, hogy engedélyezzük az Online Maintenance folyamatnak - mely ennél a felállásnál szigorúan az aktív node-on fut - hogy menetközben végezzen el egy integritás ellenőrzést is.
Database Page Zeroing
Az Exchange adatbázisban egy elem törlése nem jelenti azt, hogy fizikailag is ki lett radírozva az elem tartalma. Pusztán csak az index jelzi, hogy ott már nincs elem.
Amennyiben ez nekünk nem megfelelő, beállíthatjuk, hogy az Online Maintenance folyamat során a törölt elemek helyét nullával írja felül az Informaton Store szolgáltatás.

Az utolsó két folyamat csak az Exchange 2007 SP1 utáni rendszerekben működik és alapértelmezésben nincs bekapcsolva.

Mielőtt belecsapnánk a lecsóba, nézzük meg, mi a helyzet az Exchange 2010-ben.

A legnagyobb változás az, hogy kiszedték a karbantartási folyamatok közül az online defregmentálást. Ez innentől kezdve _állandóan_ fut, akármilyen terhelés is éri az adatbázist. Természetesen az Online Maintenance ütemezési lehetőségei továbbra is megmaradnak, csak éppen az elvégzendő feladat mennyisége csökkent.

Megváltozott a Database Checksumming is. Nem csak azért, mert átnevezték Database Scanning-re, hanem egy kicsit erőszakosabbá is tették. Na, nem nagyon, de ha egy adatbázis nem lett 3 napon belül egyszer átvizsgálva, akkor warning keletkezik az eventlogban.
Ennél is fontosabb változás az, hogy kétféle módban futtathatjuk:

Beállíthatjuk, hogy ez legyen az utolsó lépés az Online Maintenance folyamatban. Ez azért fontos, mert ha korábban olyan ablakot adtunk egy adatbázisnak, melyben szakadás volt, akkor az újraindulásnál nem az esedékes OM folyamat folytatódott, hanem mindig lefutott egy Database Checksumming. A hivatalos doksi szerint ez a mód főleg a kisebb adatbázisok esetében praktikus.
Jó kérdés, mi számít kisebb adatbázisnak?

This option works well for smaller databases that are less than 1 terabyte (TB) in size.

Aha.
Beállíthatjuk azt is, hogy az online defregmentáláshoz hasonlóan a Database Scanning is 7/24-ben menjen.

Oké, térjünk vissza az Exchange 2007-hez.

Mit is tanultunk, mekkora lehet maximum egy Exchange 2007 adatbázis? Attól függ. Általában 100 GB a felső határ, de ettől egy speciális esetben eltérhetünk. Ha ugyanis CCR clustert építünk és elválasztjuk egymástól a két éjszakai orgiát, azaz a backup a passzív node-ról fut, az Online Maintenance meg békésen elpöfög az aktív node-on, akkor a felső határ felugrik 200 GB-re. (Nyilván az egésznek az az értelme, hogy záros időn belül esélye legyen az OM-nek lefutni. Ha a backup állandóan megszakítja, akkor nem lehet nagy az adatbázis.) Értelemszerűen ebben a helyzetben kötelező a Database Checksumming is, hiszen a backup elvégzi ugyan a passzív node-on az adatbázis integritásellenőrzősőt, de az aktív node-on ez nem történik meg.

Kitérő:
Érdekes kérdés, hogy CCR esetében hogyan megy át az OM hatása a passzív node-ra? Addig oké, hogy az aktív node-on buzeráljuk az adatbázist, jobbra-balra pakolgatjuk az adattáblákban az adatokat, döntögetjük a sírköveket, meg ilyesmik - de hogyan gondoskodunk arról, hogy mindez megtörténjen a passzív node-on lévő adatbázissal is? A kulcs: minden OM során elvégzett művelet bekerül a tranzakciós logba, az pedig, mint tudjuk átreplikálódik és előbb-utóbb rá is játszódik a passzív példányra.

Hohó, mondhatja ilyenkor a ~~nagy horgász~~ gyanakvó adminisztrátor, de akkor az OM több szekérderéknyi logot fog generálni! Jó az nekünk? Annyira nem… de ha ügyesek vagyunk, akkor úgy állítjuk be a mentést a passzív node-on, hogy az a konkrét adatbázisnál az OM ablak után nem sokkal induljon, így egyből el is tudjuk tüntetni a rengeteg logot. (Természetesen az OM ablak alatt egy másik adatbázis mentése simán futhat.)
Látható, ez igazából egy nagy csiki-csuki, egy kifejezetten embert próbáló optimalizálási feladat.

Mondjuk, egyszer belőttük. Ülhetünk-e nyugodtan a babérjainkon a továbbiakban? Nyilván nem. Az adatbázisok mérete folyamatosan változik. (Nő.) Igazából nem is ez a baj, hanem az, hogy egymáshoz képest máshogyan nő. Azaz lehet, hogy most a DB01 adatbázisnak kell adnunk a rendelkezésre álló idő 15%-át, mert akkora, de lehet, hogy egy fél év múlva a többi beelőzi és már csak 5% járna neki.

Rossz hírem van. Ezt az optimalizálási folyamatot célszerű negyedévente végigjátszani.

Ezért nem árt, ha kidolgozunk rá egy rögzített folyamatot. Erről fogok írni legközelebb.

By JoeP december 17, 2009 at 20:31 Posted in: exchange No Comments

Megint variálok

Akik régebb óta figyelemmel kisérik a blogot, emlékezhetnek rá, hogy valamikor létezett egy szeparációs elv: a rövidebb, news jellegű írások a Technet blogra mentek, a hosszabb írások pedig ide. Ez az utóbbi időben felborult. Nem akarok túlzottan belemenni a részletekbe - vagy én voltam béna, vagy a Technet blog admin felülete, vagy csak a szokásos karmám, hogy amihez közöm van, az elromlik, de legalábbis bravúros nyomozást tesz lehetővé -, mindenesetre elég régóta már csak itt jelennek meg az írásaim.

Eddig. Úgy tűnik, megmozdult az állóvíz, talán újra megélénkül a Technet blog.

Az új felállás a következő lesz.

A news jellegű írások - mint például az utóbbi három - mennek a Technet blogra.
A tanulmány jellegű, hosszabb írások - mint például a korábban megjelent Exchange 2010 írások zöme - megjelennek itt is, ott is.
Az igazi, véres nyomozások történetei pedig maradnak itt.

Látható, hogy lesz némi átfedés. Az ok marha egyszerű: olvasómaximalizálás. Én nem tudom, hogy mit csináltok, de összehasonlítva a statisztikákat, még ilyen állapotban is jóval többen látogatják a Technet blogot, mint az Emaildetektívet. Azt viszont látnotok kell, hogy aki blogot ír, az azért teszi, hogy a mondanivalója minél több emberhez eljusson. (Mert pénzt, azt nem lehet keresni vele.)

Ez a duplikáció egyedül azt a kemény magot zavarhatja, akik kitartóan olvassák ezt a blogot, de olvassák a Technet blogot is. Hát… remélem, hogy vagytok olyan nagy fiúk, hogy le tudjátok kezelni azt a várhatóan havi egy-két duplikátumot. (-;

By JoeP december 15, 2009 at 00:13 Tags: administrativa Posted in: általános 3 Comments

RUP1 for Exchange 2010

Ilyenkor azért tudok örülni, hogy erről a változatról nem írok könyvet.

- Exchange 2010 Rollup Pack #1 -

By JoeP december 10, 2009 at 00:56 Tags: exchange 2010, news Posted in: exchange One Comment

Exchange backup módok

Habár a végén belekerült egy kis reklám is, és a cikk részletesen az Exchange 2003 mentésével foglalkozik, de mindenképpen a kötelezően elovasandó írások közé tartozik.
Ha tudni szeretnéd, mi is zajlik pontosan adatbázis-mentés közben, akár egy streaming, akár egy VSS mentés során, akkor feltétlenül fusd át.

Link:
- Exchange Backup és Restore -

By JoeP december 8, 2009 at 11:35 Posted in: exchange No Comments

Exchange 2010 - A Practical Approach

Úgy látszik, másnak is megtetszett az ingyenkönyv-modell.

Eddig - tapasztalatom szerint - csak egy-egy fejezeteit szokták kirakni a netre a nagyobb könyveknek… és nemritkán a letöltésekhez meg kellett adnunk egy csomó adatot, emailcím ellenőrzés… ismerjük.

Ehhez képest ennél a könyvnél csak egy emailcímet kérnek, de azt sem ellenőrzik le, szóval mehet akármi. A könyv pedig teljes. Igaz, van a végén vagy tíz oldal reklám, de legfeljebb nem olvassuk el.

Gyorsolvasással átfutottam, nem is rossz. Olyan jó 300-as szint, őrült nagy mélyfúrást ne várjunk tőle, viszont szépen össze lettek szedve a dolgok. És ami külön tetszett, az az 5. fejezet bevezetése. Nagyon szépen, közérthetően írta le a szerző, mi is történik az adott esetekben az adatbázis matyizása közben.

- letöltés -

By JoeP december 5, 2009 at 19:31 Tags: ajánlás, exchange 2010 Posted in: exchange No Comments

Lehet egy node-dal több?

Scott Schnoll Exchange 2010 High Availability (HA) előadása után gondolkodtam el néhány dolgon. Van ugyanis egy olyan HA matek, amellyel eddig egy Exchange mérnök még nemigen találkozott.

Történelmileg volt ugye az SCC, azaz a Single Copy Cluster. Ez viszonylag egyszerűen nézett ki, volt egy közös diszk - rajta a quorummal - aztán voltak a node-ok, ha jól emlékszem, maximum négy. (Nem néztem utána, annyira nem is lényeges most a pontos szám. A gyakorlatban én eddig maximum 3 node-ra épülő clusterrel találkoztam.) Hogyan nézett itt ki a HA?

Ha kidőlt a közös diszk, vagy akár csak a közös diszken lévő quorum, akkor összedőlt a cluster is. (Hányszor hallottam már olyanról, hogy valaki megörült, hogy milyen sok hely van a Q: meghajtón és elkezdett fájlokat másolni rá. Aztán amikor megtelt és lehalt a cluster, akkor meg volt csodálkozás.)
Ha node dőlt ki, akkor amíg volt másik node, addig nem volt baj. A cluster működéséhez elég a diszk (quorum+adat) és egy node.

A Windows Server 2003 SP1 után kijött egy patch, mellyel a termék már ismerte a File Share Witness technikát. Ez volt az első lépés a demokrácia irányába. A Windows 2008 Server ezt már helyből tudja, sőt ki is bővítette - de erről majd később.

Az Exchange természetesen igyekezett kihasználni az új játékszert. Az FSW megteremtette a lehetőséget a logshipping elven működő clusterezési technikák előtt. Pontosabban, a logshipping lokális és standby módban megy mindenféle clusterezés nélkül, csak a CCR-hez kell az FSW. De ahhoz nagyon.
Igaz, ez azért elég korlátozott rendszer. Például maximálisan két node lehet. Azaz ha van egy FSW és a két node, akkor kapunk egy három komponensből álló rendszert, ahol kettőnek mindig működnie kell, hogy a rendszer egésze is működjön.
Vegyük észre, hogy mekkora különbség ez az SCC-hez képest. Ott ugyanis a qourumnak mindenképpen működnie kellett. Itt már csak egy szavazásra egyszerűsödött le a helyzet: a játékosok felénél többnek (min. 50.000000001%) élnie kell ahhoz, hogy a cluster működjön.

Exchange 2010-et már csak Windows Server 2008-ra telepíthetünk. Csakhogy itt már nem csak egy szimpla FSW van a spájzban, hanem jóval több alapanyagból főzhetünk.

Node Majority
Csak a node-ok játszanak, más nem. Ha a felénél több él, akkor működik a cluster.
Node and Disk Majority
Bejön a képbe egy ún. witness disk. Ez az a merevlemez, amelyiken a quorum található. Innentől kezdve a játékosok száma megnő eggyel.
Node and File Share Majority
Ez a korábbi FSW. A quorum nem diszken lakik, hanem kikerül egy megosztásba és ez a megosztás (witness share) is belép a játékosok közé.
No Majority
Gyakorlatilag a korábbi SCC modell. A quorum diszk az adu ász, mely mindent visz.

És mindemellett a node-ok száma maximum 16 lehet.

Lássuk, mi jön ki ezekből az alapanyagokból.

Az Exchange 2010-ben a quorum diszket, mint olyat, kidobták. Így a négy lehetőségből rögtön kiesik kettő, marad az 1 és a 3.
Nagy kérdés, hogy ezek közül mikor és melyiket alkalmazzuk? A válasz az, hogy felejtsük el. Egész egyszerűen ezt nem mi fogjuk eldönteni.

Miért?
Elmagyarázom.

Legyünk egy izgága Exchange rendszergazdák. Éppen most döntötte el a cég, hogy a magas rendelkezésreállású Exchange 2007 CCR rendszert lecseréli egy szintén magas - sőt, ha lehet, akkor még magasabb - rendelkezésreállású Exchange 2010 rendszerre. Rutinból elkezdünk rajzolni: akkor lesz egy FSW a Hub Transport szerveren és - mivel itt már lehet - legyen akkor 3 node. Mert minél több node, annál nagyobb a biztonság. Megtervezzük. Megcsináljuk. Üzemel.
Aztán egyik nap kidől az egyik node. A szempillánk sem rebben. Éppen a darabokra szerelt gépben turkálunk, amikor valaki véletlenül kirúgja a másik node 220-as csatlakozóját a falból. Csak kacagunk rajta. Egészen addig, míg egy óra múlva munkakönyvvel a zsebünkben repülünk kifelé az ablakon.

Mi is történt?

Van négy játékos: 3 node és 1 FSW. Kidől egy node. Megvan a többség? 3:1, azaz igen. Kidől még egy. Most megvan? 2:2. Mennyinek kell lennie a többségnek? Min. 50.000000001%-nak. Ez bizony nincs meg.
Azaz vetettünk a céggel még egy plusz vasat súlyos milliókért és egy fikarcnyival sem lett megbízhatóbb a rendszerünk - hiszen ha belegondolunk, a 2 node + 1 FSW rendszer is pont egy node kiesést bírt el. Mindezt wálság idején. Nyilván kirúgtak.

Következő munkahelyünkön egyszer csak azt a feladatot kapjuk, hogy bíráljuk el egy külső konzulens ajánlatát. Átfutjuk és egyből kiszúrjuk, hogy az illető úgy képzelte el a magas rendelkezésre állású Exchange 2010 rendszert, hogy abban 3 node van.
- Hah! - rontunk be Vezérigazgató Bálinthoz - Ez a konzulens egy idióta sarlatán! Abszolút felesleges pazarlás 3 node-ból álló clustert tenni az Exchange 2010 alá!

Ezzel rögtön két hibát követtünk el. Egyrészt nem tudtuk, hogy a konzulens a vezérigazgató unokaöccse. Másrészt szembesítés után a konzulens higgadtan, okosan elmagyarázza, hogy ő úgy képzelte, miszerint az Exchange cluster Node Majority quorum modellt használna, azaz a négy játékos közül az FSW-t hagyná el. A plusz node-nak pedig nem a node szintű redundancianövelés a célja, hanem az adatbázis szintű redundanciáé. Ráadásul ha 3 node-ot használ, akkor nem kell méregdrága (DAS) diszktömb a node-ok mellé, hanem egyszerű, RAID vezérlő nélküli vincseszterek is megteszik, melyeket itt lent a Közértben lehet venni kilóra. Ezzel nem csak ezt érik el, hogy a 3 node olcsóbb lesz, mint a kettő(1), hanem sokkal olcsóbbak lesznek a későbbi bővítési lehetőségek is, feltéve, hogy a Közértben nem fogy el a lemez.

Ezek után Bálint bólint - és már megint repülünk.

Nos, pont azért, hogy ne rúgjanak ki olyan sok Exchange rendszergazdát, a fejlesztők úgy döntöttek, hogy kiveszik a döntést a humanoidok kezéből. Amikor összerakunk egy DAG-ot, akkor páratlan számú node esetén automatikusan Node Majority tipusú cluster jön létre, páros számú node esetén pedig Node and File Share Majority tipusú. Természetesen a váltás dinamikus, ahogy bővítem vagy szűkítem a DAG-ot, úgy változik automatikusan a modell is.

(1) Természetesen ez csak nagy adatbázisok esetében igaz. De mikor nem nagy egy Exchange adatbázis? Különösen akkor, ha az Exchange 2010-ben levették róluk a féket és azt mondták a postafiókoknak, hogy szaporodjatok, sokasodjatok és töltsétek be a Földet?

By JoeP november 25, 2009 at 23:04 Tags: exchange 2010 Posted in: exchange One Comment

Hiányzó képek

A biztonság jó dolog.

Csak épp néha piszokul bosszantó.

Vegyük elő kedvenc Outlookunkat és tapasztalni fogjuk, hogy a beérkezett levelek egy jó részében nincsenek képek, csak egy kék figyelmeztető sáv, hogy ha akarjuk, akkor letölthetjük a képeket, de ez biztonságilag kockázatos.

Miért van ez így? Miért van az, hogy bizonyos levelekben vannak képek és bizonyos levelekben nincsenek?

A HTML formátumú levelekbe a képeket két módszer szerint tudjuk berakni.

Az egyik az úgy nevezett Online HTML. Ebben az esetben a levélben van egy img tag, aminek az src attributuma egy web szerveren tárolt képre mutat. Ennek a megoldásnak az az előnye, hogy az elküldött levél maga viszonylag kicsi lesz, mert a képek nincsenek benne. További előny, hogy a küldő tud a háttérben statisztikát vezetni arról, hogy az adott levelet megnyitották-e (ha letöltötte a címzett a képet, akkor megnyitotta a levelet). Előny lehet még a feladó számára, hogy a képet utólag is tudja módosítani*. Ennek a megoldásnak vannak hátrányai is. Az Outlook az ilyen levelekre rakja fel a fent említett kék csíkot és nem tölti le a képeket. Ha valamiért a címzett, vagy a küldő web szervere offline, akkor nem tudunk hozzáférni a képekhez.

A másik az Offline HTML, amelyben az img tag src attributuma egy cid bejegyzést tartalmaz ami a levélben magában lévő rejtett csatolmányra mutat. Ez tartalmazza a képet magát. Előnye, hogy mindig elérhető a címzett számára, az Outlook nem szűri ki, ugyanakkor hátránya, hogy nagyméretűek lesznek a levelek tőle.

Vajon az Outlook miért szűri ki az első levél típusban szereplő képeket?

Mert ez a gépre nézve potenciális támadást is hordozhat. Az elmúlt években több olyan sérülékenység is napvilágra került, amit a Windows képfeldolgozó motorjában találtak és speciálisan formázott képfájlal kihasználhatóak voltak. Tehát, ha nem töltöm le a képet, akkor nem tud kárt okozni.

De engem zavar, hogy állandóan kézzel kell letöltenem a levelet. Ki lehet kapcsolni?

Igen, de nem érdemes, az ok az előbb taglalt biztonság.

Jó, de akkor mi a megoldás? Hogyan lehetne elérni, hogy azoknál a leveleknél, amiknél én szeretném automatikusan letöltődjenek a képek (pl. rendszeres, olvasott hírlevelek).

Erre van megoldás. Ha megnézzük az Outlook biztonsági beállításai között találunk egy ilyet:

Trusted Zone

Bekarikáztam a lényeget. Tehát, ha a kép forrását berakjuk az Internet Explorer Trusted Zone-ba akkor a képet automatikusan le tudjuk tölteni.

Ok. Akkor rakjuk be. Na, ezzel lesz némi gond. Nincs olyan gomb, menü, valami az Outlookban, ami ezt megtenné nekünk. Ha van egy levelünk, aminek a linkjeit használni szeretnék, akkor szükségünk lenne a levél HTML forrására, hogy ki tudjuk másolni a megfelelő linket. Sajnos ezzel sem rendelkezünk, ugyanis ezt az Outlook eldugja előlünk.

Mit tehetünk? Programozunk.

Írtam egy pici Outlook makrót, ami beköltözik a levél context menüjébe és ha ott rábökünk a Trust Picture Source menüpontra, akkor a levélben (vagy levelekben) lévő img src attributumokból kibogarássza a web oldalak címeit és berakja őket a Trusted Zone-ba.

A dolog működik, csak egyetlen szépséghibája van. A működés eredménye, csak az Outlook újraindítása után látható. A kód Outlook 2007-en működik (a korábbiakon nem).

Akkor rakjuk fel!

Nyissunk az Outlookban egy VBA ablakot (Alt+F11) A ThisOutlookSession-on jobb egérgomb, View Code.

Ide másoljuk be ezt:

Option Explicit
Private TrustPictureContextMenus As TrustPicturesMenu
Private WithEvents objOL As Outlook.Application
Private Sub Application_Quit()
    Set TrustPictureContextMenus = Nothing
End Sub
Private Sub Application_Startup()
    Set TrustPictureContextMenus = New TrustPicturesMenu
End Sub

Ezek után a Class Modules ágon jobb egérgomb, Insert/Class Module. Majd a keletkezett modult nevezzük át TrustPicturesMenu-re.

A kód ablakba pedig rakjuk be ezt:

Option Explicit
Private WithEvents objOL As Outlook.Application
Private WithEvents objTrustPictureButton As Office.CommandBarButton
Private Sub Class_Initialize()
    Set objOL = Outlook.Application
End Sub
Private Sub objTrustPictureButton_Click(ByVal Ctrl As Office.CommandBarButton, CancelDefault As Boolean)
    Dim RE As Object, REMatches As Object
    Set RE = CreateObject(”vbscript.regexp”)
    With RE
        .MultiLine = False
        .Global = True
        .IgnoreCase = True
        .Pattern = “<img\b[^>]*src=”"(https?)://([^/]*)[^""]*”"[^>]*>”
    End With
    ReDim Sites(1, 0) As String
    Dim objItem
    Dim SiteFound As String
    Dim ProtocolFound As String
    Dim SiteInArr As Boolean
    Dim SiteMatch
    Dim Site
    Dim i
    For Each objItem In objOL.ActiveExplorer.Selection
        Set REMatches = RE.Execute(objItem.HTMLBody)
        For Each SiteMatch In REMatches
            SiteFound = LCase(SiteMatch.SubMatches(1))
            ProtocolFound = LCase(SiteMatch.SubMatches(0))
            SiteInArr = False
            For i = 0 To UBound(Sites, 2)
                If Sites(0, i) = SiteFound And Sites(1, i) = ProtocolFound Then
                    SiteInArr = True
                    Exit For
                End If
            Next
            If Not SiteInArr Then
                If Sites(0, UBound(Sites, 2)) <> “” Then
                    ReDim Preserve Sites(1, UBound(Sites, 2) + 1)
                End If
                Sites(0, UBound(Sites, 2)) = SiteFound
                Sites(1, UBound(Sites, 2)) = ProtocolFound
            End If
        Next
    Next
    Dim DomainPartArr
    Dim HostPart As String
    Dim DomainPart As String
    Dim j, k
    For i = 0 To UBound(Sites, 2)
        DomainPartArr = Split(Sites(0, i), “.”)
        DomainPart = “”
        HostPart = “”
        For j = 0 To UBound(DomainPartArr) - 2
            HostPart = HostPart + DomainPartArr(j)
            If j < UBound(DomainPartArr) - 2 Then
                HostPart = HostPart + “.”
            End If
        Next
        For k = j To UBound(DomainPartArr)
            DomainPart = DomainPart + DomainPartArr(k)
            If k < UBound(DomainPartArr) Then
                DomainPart = DomainPart + “.”
            End If
        Next
        RegKeySave “HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\” _
                    & DomainPart & “\” & HostPart & “\” & Sites(1, i), 2, “REG_DWORD”
    Next
End Sub
Sub RegKeySave(i_RegKey As String, i_Value, Optional i_Type As String = “REG_SZ”)
    Dim myWS As Object
    Set myWS = CreateObject(”WScript.Shell”)
    myWS.RegWrite i_RegKey, i_Value, i_Type
End Sub
Private Sub objOL_ItemContextMenuDisplay(ByVal CommandBar As Office.CommandBar, ByVal Selection As Selection)
    Dim objItem As Object
    Dim blnFoundItem  As Boolean
    Dim objCBB As Office.CommandBarButton
    For Each objItem In Selection
        If objItem.Class = olMail Or objItem.Class = olPost Then
            blnFoundItem = True
            Exit For
        End If
    Next
    If blnFoundItem = True Then
        Set objCBB = CommandBar.Controls.Item(1)
        objCBB.BeginGroup = True
        Set objCBB = CommandBar.Controls.Add(msoControlButton, , , , True)
        objCBB.Style = msoButtonWrapCaption
        objCBB.Caption = “Trust Picture Source”
        objCBB.BeginGroup = True
        Set objTrustPictureButton = objCBB
    End If
End Sub

Mentsük el az egészet.

Ezek után, már csak a kód biztonsági beállításokat kell megtennünk, hogy a dolog működjön (digitális aláírás, miegymás )

Használata:

Odanavigálunk kiszemelt levelünkhöz, nyomunk rajta egy jobb egérgomot és…

Context Menu

* Erről van egy történetem. Van egy ismerősöm, aki az egyik magyar banknál dolgozott biztonsági szakértőként. Egy spammer banda az ő bankjuk nevében küldött megtévesztő leveleket (phishing). A rosszfiúk elkövették azt a hibát, hogy Online HTML levelet küldtek, amiben a logo a bank honlapjára mutatott. Az ismerősöm fogta magát és kicserélte a logót a honlapon egy figyelmezetésre, melyben jelezte, hogy a levél hamis és a tartalmát senki se vegye figyelembe.

By SUF november 24, 2009 at 16:24 Posted in: általános No Comments

Az IPv6 és az Exchange 2010 románca

Egy újabb bájos jelenség. Dave Goldmann címlistamágus blogjában olvastam egy aranyos sztorit.

Az Exchange 2010 ugye már csak Windows Server 2008 oprendszerre megy fel. Ez a windows viszont már helyből beépített IPv6 tudással települ fel. Ez az emberek egy részét nem szokta zavarani - de a szerverüzemeltetők között akad rendesen paranoiás alak is, akik úgy vélik, hogy amire nincs szükség, az ne is legyen fent. És kiveszik a pipát az IPv6 checkbox elől.

Nos, ők járnak úgy, mint David. Az Exchange 2010 szerverük harakirit követ el.

By JoeP november 23, 2009 at 20:54 Tags: exchange 2010 Posted in: exchange 5 Comments

Tapétamániákusok, figyelem!

A TechEd-en egy előadáson tette ki az elóadó - Charlie Chung - ezt az ábrát egy ppt slide-ra. Én úriemberként csak diszkréten csikorgattam a fogamat: normális vagy, barátom? Egy ilyen bonyolult ábrát kivetíteni? Hát emellett akár fel is olvashatnád visszafelé az Alice Csodaországban-t (úgy sem lenne több értelme), akkor sem figyelne senki arra, miről is beszélsz. Egy ilyen bonyolult, ellenben roppant fontos ábra láttán mindenki igyekszik pillanatok alatt minél többet felszívni belőle. Dehogyis jut ilyenkor agysejt az előadó szövegének dekódolására.

Tiszta szerencse, hogy a Microsoft elérhetővé tette mindkettő diagramot a neten. Tehát mindenki, akit érint, mindenki, aki éppen nem tud milyen háttérteret a Windows képernyőjére, innen le tudja tölteni az Exchange 2010 Transport Server szerkezeti diagramjait.

By JoeP november 19, 2009 at 22:37 Tags: exchange 2010 Posted in: exchange 2 Comments

Megyen a log vándorútra

Nagyjából éppen a bokáig érő lószarban sárban cuppogtam Moritzburg környékén, amikor egyik ügyfelünk nem kicsit bonyolult Exchange mailbox szervere úgy döntött, hogy torkonszúrja magát. No nem nagyon, de két mailbox adatbázis és a public folder adatbázis leállt. Kolléga rávetődött az incidensre. Hamar rájött, hogy a leállást az okozta, hogy betelt egy log partíció. Egy olyan partíció, ahová ez a 3 adatbázis dolgozott.

Kitérő:

Igen, ilyet teljesítményproblémák miatt nem szoktak csinálni. Csakhogy egész egyszerűen az ügyfélnél annyi adatbázis van, hogy nincs annyi betű az angol ABC-ben, hogy minden log könyvtárhoz külön partíciót rendeljünk. Így a 3 legritkábban használt, legkisebb adatbázis log fájljait egy partícióra tettük.

Nos, a két pici mailbox adatbázisból az egyik bevadult. Nem, nem a korábbi bevadulás, ennek üzleti okai voltak. A vadulás miatt elszabadultak a logfájlok, betelt a partíció, méghozzá olyan gyorsan, hogy a riasztás után már cselekedni sem maradt időnk - aztán leállt mindhárom adatbázis.

Kitérő:

Maga az Exchange mailbox rendszer a következőképpen nézett ki: CCR rendszer egy aktív és egy passzív node-dal, melyhez kapcsolódott egy SCR rendszer egy passzív node-dal.

Tehát ez volt a játszótér és adott volt a feladat. Az ügyfél nyilván ki volt kattanva, hiszen mi az, hogy egy ilyen bonyolult cluster elérhetetlenné válik - és természetesen azt várta el, hogy minél hamarabb megint elérhetőek legyenek az adatbázisok. Kolléga fogta, és a CCR mindkét node-ján elmásolta ugyanazt a nagy kupac régi - ergo már biztosan rájátszott - logot mind a public folder, mind a bevadult adatbázis logkönyvtárából, felmountolta az adatbázisokat és minden be is indult szépen. Az adatbázisok működtek, sőt, a konzol alapján a log replikáció is egészséges volt. Problem solved.

Egészen addig mindenki nyugodt volt, amíg el nem érkezett a mentés ideje. De elérkezett. Le is ment - majdnem minden adatbázisra. Egy, csak egy szaladt hibára, az a bizonyos vad adatbázis. Mely ugye nem véletlenül vadult be, a hirtelen megnövekedett üzleti igények okozták a hízást - azaz meglehetősen fontos adatok kerültek az adatbázisba.

Kolléga még megnézte az eseutil /mh paranccsal, hogy konkrétan milyen log fájlok hiányoznak a passzív node-on - de a válasz az volt, hogy semmi. Rá lett küldve egy reseed (update-storagegroupcopy), de csak annyit csinált, hogy a passzív node-on kiürült a logkönyvtár.

Ekkor érkeztem vissza szabadságról és rögtön meg is kaptam a feladatot.

Helyzetfelmérés:

Az adatbázis megy, ránézésre a log replikáció egészséges, az ügyfél nyugodt.
Ezzel szemben az aktív node-on rengeteg log van, a passzív node-on egy sem. Az adatbázisok azonos méretűek, azaz a reseeding sikerült.
Az SCR node-on az a bizonyos partíció fullon volt, a replikáció az említett adatbázisokon állt. Szemmel láthatóan az SCR-rel senki sem foglalkozott.
Viszont mivel nem sikerült a mentés, az aktív node-on pár óra múlva megint elfogy a hely, szóval nagyon gyorsan ki kell találni valamit.

Ergo egyfelől meg kellett akadályoznom az újabb leállást, másfelől össze kellett kötözgetnem a szálakat, mert itt valami nagyon félrement.

A feladat első része volt az egyszerűbb. Kerestem egy üres partíciót (későbbi fejlesztésekre volt is félrerakva egy, de a későbbi szó pont azt jelenti ugye, hogy nem mostani), majd átirányítottam ide a logolást.
Ránézésre olyan egyszerűnek és logikusnak tűnik - de nem az. Nem véletlen, hogy a kollégám sem így próbálkozott. Neki ugyanis sietnie kellett.
Első lépésben ugyanis suspendbe kell rakni a log replikációt. Ez még nem is fáj.
Második lépésben dismountolni kell az adatbázist, ráadásul bizonytalan ideig. Ez már fájt az ügyfélnek, nem is mentek bele szó nélkül. Amikor közöltem velük, hogy ez van, törődjenek bele, nincs más lehetőség, rögtön jöttek, hogy bezzeg a kollégám meg tudta oldani máshogyan. Na, ez a szakma kellemetlen része. Elmagyarázni az ügyfélnek a szakmai finomságokat, úgy, hogy közben a mundér becsületét is megvédjük. Végül azért sikerült tisztáznom, hogy a múltkori az egy gyors, ideiglenes megoldás volt, én viszont már a végleges megoldáson dolgozom.
Ha ezzel megvagyunk, akkor jön a move-storagegrouppath parancs, valahogy így:

move-StorageGroupPath -Identity ‘adatbázis‘ -LogFolderPath ‘ujlogkonyvtar‘ -SystemFolderPath ‘ujsystemkonyvtar‘ -configurationonly

Vagy hogy érthetőbb legyen, konkrét példával:

move-StorageGroupPath -Identity ’server\vad-adatbazis’ -LogFolderPath ‘Z:\exchsrvr\log’ -SystemFolderPath ‘Z:\exchsrvr\log’ -configurationonly

Határozottan felhívom a figyelmet a configurationonly paraméterre! CCR környezetben a logkönyvtárt ugyanis nem lehet csak úgy átrakni. A parancs hatására a következők történnek:

Az AD konfigurációs névterében az érintett storage group tulajdonságainál átíródnak a log, illetve system könyvtárak útvonalai.
Emellett az új könyvtár (z:\exchsrvr\log) meg lesz osztva, méghozzá egy GUID névvel. Ha visszanézzük, akkor ez a GUID a storage group azonosítója. A megfelelő jogosultságokat szintén beállítja a parancs.

Végül ha ezen túlvagyunk, akkor manuálisan átmásoljuk a lecsatolt adatbázis log és system fájljait a régi helyről az újra, majd felmountoljuk az adatbázist. Ha nem rontottunk semmit el, akkor el is indul.
Látjuk, az időbeli bizonytalanságot a logfájlok másolása jelenti. Viszont amíg a másolás folyik, addig szét is tud replikálódni a címtárban a változás.

Ezzel a sürgős résszel meg is volnánk, jöhet a kötözgetés.

A biztonság kedvéért ráküldtem én is egy reseedet. Hátha apucitól jobban elfogadja. De semmi. Vágjunk mélyebbre. Újraindítottam a passzív node-on a replikációs szolgáltatást.
És végre történt valami. A replikáció státusza elmozdult az egészséges állapotból. Initializing. A végtelenségig. Vártam rá egy kicsit, aztán eluntam. Ennél még a kamu egészséges visszajelzés is jobb volt. Újabb reseed.

Jobb híján nézelődtem, gondolkodtam. A log könyvtár átmozgatása rendberakta az SCR-t, tökéletesen működik. Azért ez is valami: van egy aktív CCR node-om és egy passzív SCR node-om.
Aztán egy kellemetlen gondolat. Eddig azt mondtam, hogy a logfájlok másolása sértett meg valami ismeretlen dolgot az Exchange rejtett mélységeinek szövetében. De akkor a public folder adatbázisok logshipping folyamatának sem kellene működnie. Aztán mégis működik.
Hjaj. De bonyolult az élet.

Get-storagegroupcopystatus. Mindenki healthy. Egészségükre. Aztán hoppá. A CopyQueueLength értéke a vad adatbázisnál 14234. Mit ír erről a manuál? Azt, hogy ha az értéke nagyobb 3-nál, akkor baj van. Hmm. Ide azért most nem kell fejszámolóművész, itt baj van.

Test-replicationhealth. Minden passed - kivéve a vad adatbázis copy queue értéke. Az viszont nagyon nem.

További nézegetés. Hoppá. Nincs a passzív node-on edb.chk. Ezt azért volt nehéz észrevenni, mert abszolút nincs semmi más sem a könyvtárban. Ez azért magyarázza, miért nem ment le a mentés. (Akinek újdonság lenne: az Exchange az edb.chk fájlba írja, melyik lognál indult a mentés, azaz a mentés után meddig kell törölni a logokat.) Lehetséges, hogy nem csak a backup használja ezt, hanem a log replikáció is? Nagyon lehet, hiszen egy normális reseed úgy indul, hogy törli az edb.chk-t és az adatbázist.
Akkor lehet, hogy nem is jó a látszólag jó reseed?

Mint az ínyenc, aki a legfinomabb falatokat a végére hagyja, én is elővettem végül az event logot. Volt is benne érdekesség.

Ez legalább világos beszéd, végre. Habár az eseutil /mh szerint nem hiányzik neki logfájl, de az eventlog szerint mégis hiányzik a 84679-es számú. (Azért ezen ne lepődjünk meg. Az eseutil csak az adatbázis épségével foglalkozik - és az adatbázisok tökéletesen jók. Itt a logshipping szakadt össze, de ahhoz az eseutil meg nem ért.) Természetesen ilyen nevű logfájl nincsen. De ennyi szívás után az ember már csak legyint és átszámol hexába: 14AC7. Ilyen nevű log már lehet. De hol? Hát például a kolléga által félrementett logok között, melyeket szerencsére nem töröltünk.
Mi lenne, ha bemásolnám az aktív node logkönyvtárába?
Bemásoltam. Egy perc focilabda rugdosás (az új irodámban nincs darts tábla) - és ott van a log a passzív node-on is. Vérszem. Az az, amit kaptam. Bemásoltam a sorban következő 10 logot az aktív node-ra. Egy percen belül megjelentek a passzív node-on is. Ujjé. Elkezdtem név alapján bogarászni az éles log könyvtárat és a mentett logok könyvtárát. Úgy tűnik, hogy az egyik a zsák, a másik meg a foltja. Ha a félremásolt logokat átmásolnám az éles logkönyvtárba, akkor zárt lenne a sor.

Persze ehhez több hely kell.

Újabb telefon az ügyfélnek. Leállnánk pár percre, ugye nem baj? Ügyfél füle egy kicsit rángatózik.

Átmásoltam a logokat egy nagyobb partícióra. (Igen, ez már adatbázispartíció volt. De csak a mentésig lesznek itt a logok, addig meg kibírják.)

Utána pedig megtörtént a nagy családegyesítés. Elvonultam gyakorolni a külső csavarást a nyomtató asztalának lábai közé. 20 perc műlva néztem vissza - és a logok szorgalmasan másolódtak át a passzív node-ra. Remek.

Legyen teljes a győzelem: újabb get-storagegroupcopystatus. A CopyQueueLength értéke szépen le is csökkent… de miaf… elkezdett növekedni a ReplayQueueLength értéke. Ugyan - hessegettem el a kellemetlen gondolatot - ez most kapott hirtelen 14000 logot, persze, hogy nem tudja ilyen tempóban rájátszani. Hagyjuk békén, holnap reggel majd meglátjuk, mi lesz a vége.

Eljött a holnap reggel. A győzelem érzésével gépeltem be a jó öreg get-storagegroupcopystaus parancsot - és a ReplayQueueLength értéke 500 körül volt. Az első gondolatom rögtön az volt: miért? A nullát el tudtam volna fogadni. A 14000 körüli értéket szintén. De miért pont 500?
A magyarázat gyorsan jött. Konzol, gyors vizuális pásztázás: a vad adatbázisnál a logshipping státusza failed. Aha. 500-nál besokkalt, aztán azóta coki.

Hát. Tulajdonképpen előrébb vagyunk. De a beteg még mindig kómában fekszik.

Most már nem álltam neki ködöt rágni, mentem egyből az eventlogba.

Keressünk rá a hibakódra. Azt írja, hogy a 1216 azt jelenti, hiányzik néhány tranzakciós log. Kérdezzem le az eseutil /mh paranccsal, mely logok hiányoznak. Lekérdeztem. Semmilyen log sem hiányzik.

Bakker. Mégis köd. Azért ez már kezd bizarrá válni: egyfelől azt mondja, hiányzik neki x darab log, ahhoz, hogy rájátssza végre az összes logot arra az adatbázisra, amelyikre már jó egy hete rá van játszva az összes log - másfelől pedig konkrét kérdésre azt mondja, hogy nem is hiányzik neki egy log sem.
Csak éppen nem indul el a rájátszás.

Ekkor már teli csőrrel gyakoroltam a védhetetlen bombákat a szerverszoba ajtajára.

Végül visszadaráltam az elejére. Emberek, végülis… már van edb.chk fájlunk a passzív node-on. Ez jó hír.
Töröljük gyorsan le. Azaz küldjünk rá egy reseed-et. Mert mi van, ha az a baj, hogy az adatbázis - amelyikre már rá van játszva minden log - nincs szinkronban a logkönyvtárban lévő edb.chk-val, mely még csak nemrég jött létre, a replikáció befejeztével. A reseed ugyanis törli mindkettőt, majd újra létrehozza, immár szinkronban.

És tényleg.

A ReplayQueueLength értéke egyből lenullázódott, a logshipping meggyógyult. A pezsgőbontással vártam még tíz percet, mert ez a nyomorult replikáció képes megint elromlani - de nem.

Tanulság:

Amíg elő nem varázsolom valahonnan a hiányzó logokat, addig felesleges a reseed. Nincs értelme. Nincs edb.chk.
Ha megvannak a logfájlok, akkor vissza kell másolni az aktívra, a logshipping beindul, legyártódik az edb.chk. Ekkor viszont kötelező a reseed, mert ez hozza összhangba a két node-ot.

Végül egy kényelmetlen gondolat:

És akkor mi van, ha közben töröltem a logokat?
Nos, végső esetben az SCR-en ott kellett lenniük.
De mi van, ha onnan is töröltük? Gáz.
Szóval óvatosan azzal a közvetlen logpiszkálással.

ps.
Elkiabáltam. Utólag derült ki, hogy az SCR node-on sem megy a rájátszás, ott is újra kellett seedelni az adatbázist és a logokat.

By JoeP november 6, 2009 at 01:34 Tags: exchange 2007 Posted in: exchange 2 Comments

Suta konzol visszalő

Ez az utolsó sajtcetli - és ez most tényleg az.

Ha már annyira leírtam a menedzsment konzolt, hadd említsek meg róla egy pozitív dolgot is. Tudtátok, hogy a 2010-es EMC-be már több Exchange organizációt is fel tudunk venni? (Feltéve persze, hogy megvan hozzá a jogosultságunk és fizikailag is elérjük a szervereket.)
Ez persze eddig még nem egy nagy kunszt.

Bravúrszám akkor lesz belőle, amikor kiderül, hogy az így bekonnektált organizációk között grafikusan tudunk postafiókokat mozgatni.

Nem részletezem. Tessék végigondolni.

By JoeP november 1, 2009 at 20:15 Tags: exchange 2010 Posted in: exchange No Comments

OWA

Nejem, amikor meglátta a monitoromon az akronimhalmazt, ennél az egynél jelzett be boldog sikkantással, hogy végre egy, melyet ismer. Nem akartam elvenni a kedvét, de a helyzet az, hogy ez az OWA már nem a jól ismert régi OWA.

Kezdjük ott, hogy már a rövidítés sem ugyanazt takarja: Outlook Web App. Oké, tudom, nem ettől szoktunk a nadrágba pisilni.
Az átnevezés mögött viszont egy komoly változtatás van.

A felső kép - az URL-ből is látszik - az OWA képernyőjének fejlécét mutatja. Az alsó kép pedig az ECP fejlécét.
Hasonlít? Ja. És akkor ahhoz mit szólsz, hogy az OWA webalkalmazásból az ‘Options’ linkre kattintva átmész az ECP-be, az ECP-ből pedig a ‘My Mail’ link az OWA-ba tesz át? Külön bejelentkezés nélkül? Gyakorlatilag folyamatosan tudod váltogatni, hogy melyik alkalmazásban mit csinálsz - olyan szinten, hogy egy idő után össze is mosódik, hogy most melyikben vagy. Mindegy. Outlook Web App - és ez betakarja mindkettőt. Én például elsőre külön felvettem a kedvencek közé mindkét linket - aztán egy idő után már meg se néztem, melyikre kattintok. Mindegy.

Formulázva ez így nézne ki:

OWA(Outlook Web App) = OWA(Outlook Web Access) + ECP.

A képlet jobb oldalán álló ECP-ről már írtam, most az ugyanazon oldalon álló OWA-ról kellene. Csakhogy a probléma ugyanaz, mint korábban az ECP-nél is. A termék újdonságairól írni nem lehet - csak demózni, elmutogatni azokat. Nem is akarok most ebbe mélyebben belemenni, egyszerűen csak felsorolok néhányat:

Házirendből konfigurálható

Ez abszolút új. Gyakorlatilag sebészi pontossággal tudjuk szabályozni, hogy weben keresztül mely részeit használhatják a felhasználók a levelezőrendszer szolgáltatásainak. A képen éppen egy olyan házirendet láthatunk, amelyikben letiltottam az autosignature használatát. Lehetőségből pedig van bőven, a gördítősávból látható, hogy nem is fértünk bele egy ablakba. (Azért ilyenkor el tudnék beszélni azzal a GUI-ból felmentett szerencsétlennel, aki szerint a mai képernyőfelbontások mellett is van értelme átméretezhetetlen ablakokat kitenni a képernyőre.)
Természetesen a lehetőségek nemcsak házirend formájában érhetők el, beállítgathatjuk postafiók szinten is.

Böngészőfüggetlen

Erről már volt szó korábban, Ajax (Asynchronous JavaScript and XML) azért kell.

Conversation View

Ezt már egyszer próbáltam megmutatni, de 800*600-ban nem igazán sikerült. Nagyobb felbontásban azért már jobban látszik. Egész pontosan a kép jobb oldaláról beszélek, ott látható, hogy az a levél, amelyre a középső panelen ráálltam, milyen láncba illeszkedik. Tessék észrevenni, hogy az alsó levelet a ‘Sent Items’-ből vakarta elő, a felette lévő levelet viszont már az ‘Inbox’-ból… azaz tényleg képes mutatni az egész levelezési szálat. Mint a Gmail.

Chat

Igen, tényleg van… de csak akkor, ha van OCS2007 szerverünk és össze van lőve az Exchange rendszerrel is.

Filterek, kibővített helyzetérzékeny menük

Ez úgy ránézésre nem nagy dolog… de praktikus. Egyfelől gyorsan tudunk váltani nézetek között, másfelől gyorsan tudjuk elérni az új rendszer extra szolgáltatásait is.

By JoeP október 31, 2009 at 20:05 Tags: exchange 2010 Posted in: exchange No Comments

Közepes bizalom

De jó is lenne néha.

Mit értek ez alatt?

Minden cégnek van holdudvara: partnerek, vendorok, ügyfelek. (Nyuszi barátai és üzletfelei.) Olyan szervezetekről van szó, amelyekkel sűrűn kell kommunikálnunk. Annyira nem bízunk meg bennük, hogy beengedjük őket a saját informatikai hálózatunkba - de borzasztó jó dolog lenne, ha látnánk egymás címlistáit, illetve a megbeszélések szervezéséhez szükséges free/busy adatokat.

Ehhez kellene kitalálni valami korlátozott megbízhatóságot használó modellt.

Először nézzük meg, milyen lehetőségeink vannak most.

Inter-Org Replication Tool, a free/busy információk szinkronizálásához: határozottan bonyolult eszköz, ráadásul teljes trustot igényel az AD-k között.
GalSync a címlisták szinkronizálására: ez egy MIIS/ILM szerveren alapuló címlista szinkronizáció, mely szintén nem egyszerű és borzasztó drága. Viszont nem igényel trust-ot.

Most pletykálok. Van egy multi ügyfelünk, ahol amerikai kezdeményezésre minden országban elkezdték a fenti két eszköz rendszerbeállítását, nyilván amerikai központtal. Kábé három éve. Kezdtük a Galsync-kel. Már majdnem működik. Az Inter-Org Replication Tool bevezetése pedig még a tervezésnél sem jár.

Nem valami biztató. Ehelyett született meg az ún. Federation Trust kapcsolat.

Már megint a felhő. Most mondd azt, hogy a Microsoft nem veszi komolyan a cloud computing-et.

Miről is van szó? Van a felhőben valahol egy Microsoft Federation Gateway szerver. Amikor közepes megbízhatóságú kapcsolatot szeretnék, akkor fogom magam és hozzácsatlakozok ehhez a szerverhez, egy Federation Trust kapcsolattal. Ez a kapcsolat tanúsítvány alapú, maga a cert az Exchange szervert igazolja. (Ennek komoly tanúsítványnak kell lennie, a sajátot nem fogadják el.) Az üzletfeleim szintén kiépítenek ilyen Federation Trust kapcsolatokat. (Sőt, nemcsak ők, hanem számomra vadidegenek is, nyilván.) Majd ha ez kiépült, akkor organizáció szinten hozok létre ún. sharing policy-ket, melyekben megadom, hogy:
a. Kire vonatkozzon?
b. Mit engedek neki.

Gyakorlatilag ennyi. Én még azért elfilózgattam a világ furcsaságán: bizalomról van szó, bizonyos szintű bizalmas kapcsolatok kiépítéséről - és rögtön az első lépésben fogalmam sincs róla, hol van a Microsoft Federation Gateway. Ugyanis ez egy olyan paraméter, amit nem lehet megadni. Az Exchange 2010 beépítetten tudja.

By JoeP október 30, 2009 at 20:31 Tags: exchange 2010 Posted in: exchange No Comments

Die PST, die!

Azt hiszem, egyetérthetünk abban, hogy ez az egész pst cucc már rég megérett a kidobásra. Egy dolog miatt nem tehetjük meg: nincs olcsó alternatívája.

Pontosabban, nem volt.

De előtte nézzük meg, mi is a baj a pst-vel? Leginkább az, hogy kígyó simaságú. Akármennyire is szeretnénk felelősen üzemeltetni a rendszerünket, a pst kisiklik a felügyeletünk alól. Ami addig nem is baj, amíg a felhasználó tudatában van, hogy pst-t használ, tudatában van, hogy rendszeresen mentenie kell, hogy a régi formátumú pst nem lehet 2 GB-nál nagyobb… meg ilyenek. A gyakorlatban ugyanis az van, hogy a felhasználó simán legyártja a pst-t, de nem tudja róla, hogy az egy fájl a vincseszteren, használja az autoarchivot és azt hiszi, hogy az a szerverre mentett. Aztán jön egy gépcsere, újratelepítéssel és jönnek az óriási sírások az elveszett borzalmasan fontos levelekről. A pst sérülésekről már nem is beszélve. Meg arról, hogy nem működik rájuk a Discovery (emlékszünk, a spionkodás), illetve egy notebook ellopása üzleti titkok kiszivárgásához vezethet.
Szükség viszont van rá, hiszen a postafiókok kvótázottak, ott nem tárolhatunk sokáig anyagokat - márpedig levelet nem törlünk, mert soha nem tudhatjuk, mikor lesz rá szükség. És akkor még nem beszéltünk egy kínzó dilemmáról: a pst-ket OWA-n belépve nem látjuk, ergo nagyon alaposan kell mérlegelnünk, mely leveleket húzzuk ki a personal storage-ba.

Ebből a bosszantó körből próbál kilépni az úgynevezett Personal Archive, azaz leánykori nevén Archive Mailbox (AMBX).

A filozófia viszonylag egyszerű: legyen a felhasználónak a normális postafiókja mellett egy jóval nagyobb arcív postafiókja is. Ugyanabban az adatbázisban. A két postafióknak legyenek különbözőek a kvótái. Engedjük meg a felhasználónak, hogy szabadon áthúzogathasson ide leveleket, engedjük meg neki, hogy autoarchivot állíthasson be rá, sőt, mi magunk is tudunk úgynevezett retension policy-t rátenni, mely idő alapján dobálja ki automatikusan az archív postafiókba a leveleket.

Ennyi. Nem egy Enterprise Vault, de ingyenes eszköznek teljesen jó.

Első körben mondjuk elgondolkoztam, mi értelme is van ennek az egésznek - hiszen nem kellene külön két postafiókot kezelni, egyszerűen a felhasználó kapna egy jó nagy kvótát (normál + archív) és tárolhatna mindent egy postafiókban.
Végül két érvet találtam a Personal Archive mellett:

Rákényszeríti a felhasználót arra, hogy archívumban gondolkozzon. Hogy felelősen kezelje az anyagait, illetve vegye észre, hogy valakik felelősen kezelik helyette.
Amennyiben az Outlook-ot cached módban használjuk, akkor csak a normál postafiók szinkronizálódik le az ost fájlba.

Akkor nézzük a Personal Archive konkrét tulajdonságait.

Csak és kizárólag Outlook 2010-ből, illetve OWA-ból látszik. (Ilyenkor belegondolok, hogy kis hazánkban nem ritka még az Outlook 2000, mint céges sztenderd.)
Az előbb leírtam, de leírom még egyszer: látszik OWA-ból. Azaz a világ bármely pontjáról, ha az OWA ki van publikálva.
Gyárilag beépítve jön egy Default Retention policy. Ha egy felhasználónál engedélyezem a Personal Archive-ot, akkor ez élből ráesik. A tartalma: a két évnél öregebb leveleket kidobja az archívba.
Archív kvótának a Microsoft 30 GB-ot ajánl. (Mondjuk egy ekkora postaládától a 2007-es Exchange esetében biztos infarktust kaptunk volna.)
A Personal Archive-ot le lehet csatolni egy felhasználó postafiókjáról és 30 napon belül oda lehet adni más felhasználónak.

Végül néhány sceenshot arról, hogyan is néz ez ki valójában.

Így kell engedélyezni egy felhasználónál. Nem egy pilótavizsgás eljárás.

Imhol a konfigurálási lehetőségek: átírhatjuk a nevét.

Itt pedig a kvótát állíthatjuk be.

Természetesen nem csak egyes postafiókonként tudjuk a személyes arcívumokat menedzselni: shellből teszőleges rugalmassággal állíthatunk elég sok mindent.

By JoeP október 29, 2009 at 19:39 Tags: exchange 2010 Posted in: exchange No Comments

MoMT

Ez az acronym a MAPI on Middle Tier kifejezést takarja.

Azt hiszem, ezt az újdonságot is lehet simán a szeletelt kenyérhez hasonlítani.

Ez valójában egy állatorvosi ló, ilyen felállás a valóságban nincsen. Viszont ha berajzoltam volna mindenféle klienst, mindenféle kapcsolódási lehetőséggel, mindenféle szerverekhez, akkor simán Burda szabásmintát kaptunk volna.

Nézzünk meg néhány tipikus kapcsolatot:

A legtriviálisabb: a kliens közvetlenül, MAPI-n keresztül kapcsolódik az adatbázishoz. Amióta az Exchange 4.0 kijött a piacra, ez azóta így van.
Hazudtam. OWA-n, Activesync-en, Outlook Anywhere kapcsolaton keresztül jövő kliensek HTTP-n keresztül érik el a CAS szervert és csak az megy tovább a mailbox szerverhez.
Persze nem csak postaláda elérésről beszélünk, a címlistát például GC-től kapjuk. (Javaslom, ne menjünk bele a részletekbe. Bonyolult.) Tudni kell, hogy vannak olyan kliensek (Outlook 2002 és attól visszafelé), akik azt hiszik, hogy az Exchange mailbox szerver egyben GC is. Az MBX szerver megtartja őket ebben a hitükben és a DSProxy funkción keresztül begyűjti a kliens számára szükséges címeket.
Aztán vannak olyan kliensek, akik közvetlenül a GC-től gyűjtik be a címlistát.
A cached módba kapcsolt kliensek számára a CAS szerver szedi össze a címlistákat.

Hót zavaros. Ráadásul rögtön az első pont annyira idejétmúlt, hogy ihaj. Mióta is ismerjük a háromrétegű alkalmazásarchitektúrát? Jó régen. Ez ugye azt mondja, hogy legyen egy vékony kliens (pl. egy böngésző), legyen a köztes rétegben az alkalmazás intelligencia (webszerveren futó alkalmazás) és legyen mindez mögött egy adatbázis-motor. A struktúrának számtalan előnye van. A magam részéről tényleg nem is értettem, hogy az Exchange 2007 már miért nem így jött ki.

Hogy is?

Hát úgy, hogy a kliens HTTP-n keresztül csatlakozik a CAS szerverhez - és csak ez, azaz a CAS nyit egy MAPI sessiont a mailbox szerverek felé. Kis lépés egy embernek, de óriási lépés egy Exchange organizációnak.

Sorolom.

Az adatbázis-kezelés eltűnt egy felhőben. A kliensnek nem kell tudnia, éppen melyik adatbázis-szerveren található a postafiókja, hova is kellene konnektálni a MAPI profilban.
Történik egy failover, az egyik szerver elérhetetlenné válik. Mivel DAG-ot használunk, így aktivizálódik egy másik szerveren lévő adatbázis-pédány. Mit érez meg ebből a kliens? Régen azért volt egy kábé egyperces kiesés, amíg a failover megtörtént. Most nincs. A CAS tartja a kapcsolatot, majd a failover után már a másik adatbázist használja.
Lehetőségünk van online postafiók-mozgatásra. Nem részletezem, az elv nyilván ugyanaz, mint a failover esetében.
Exchange adminok tegyék kezüket a szívükre: nem sápadtak-e el mindig, amikor egy kliens telefonált, hogy nem éri el az Exchange szervert, pedig tíz perccel ezelőtt még elérte? Ilyenkor rendszerint kifogyott a mailbox szerverből az RPC. A MAPI ugyanis RPC hívásokon keresztül dolgozik, egy RPC kapcsolatot pedig menedzselni kell, mely memóriába, processzoridőbe és IO-ba kerül. Bármelyik is fogyott el, a kliensek leszakadtak a szerverről. Nézzük, mi van a MoMT esetében? A kliensek gyakorlatilag a CAS szerverre kapcsolódnak, HTTP-n keresztül. Sokkal többen mehetnek egyidőben. A CAS pedig jóval kevesebb RPC-t nyit, mint a töméntelen kliens együtt. Hogy egész konkrét legyek: a hagyományos felállásban maximum 64.000 RPC kapcsolatot tudott fogadni egy szerver, a MoMT esetében ez a szám felugrik 250.000-re.
Essen szó az árnyoldalakról is: a DSProxy kinyiffant, így az Outlook 2002 és az előtti kliensek bajban lesznek. Illetve dehogy: használják majd az OWA-t.
Végül az adatbázis-kezelés bármilyen lehet. Akár SQL is.

Ez utóbbinál időzzünk el egy kicsit. Ez ugyanis egy rendszeresen felröppenő spekuláció (elképzelted, ahogy egy spekuláció lapul a fűben, aztán felröppen?). Az SQL-ben ugyanis általában jártasak az emberek, míg az ESE nagyon sok embernek ködös. Az SQL-t kézben tudjuk tartani, az ESE meg olyan… izé: eseutil, isinteg. Borzalmas.

Nyilván amint kiderült, hogy az adatbázis-kezelés átköltözik a felhőbe, egyből beindultak a találgatások. Ezeket megelőzendő írt az Exchange csapat egy rövid hírt, miszerint átállították az adatbázis-kezelést SQL-re. Majd egy meglehetősen semmitmondó és ködös magyarázat után közölték, hogy végérvényesen az ESE mellett döntöttek.
Értelemszerűen pont emiatt a ködös magyarázkodások miatt az olyan öreg összeesküvéshívők, mint például David Sengupta, meg vannak róla győződve, hogy a történetnek még nincs vége.

By JoeP október 28, 2009 at 20:21 Tags: exchange 2010 Posted in: exchange 3 Comments

DAG a kkv/soho szegmensnek is

Most már hivatalosan is lehet róla beszélni, meg egyébként is pont illik a sorozatba. Szóval, itt van egy link Henrik Walther blogjára: a DAG benne lesz az Exchange 2010 Standard verziójában is. (Bár gyanakvóbb olvasók már sejthették, ha máskor nem, akkor biztosan, amikor azt írtam, hogy kinyírták az LCR-t is.)

ps.
Kicsit hülye a cím, a magam részéről meglepődnék, ha egy soho cég egyáltalán birtokolna saját Exchange szervert és nem hosztolt email szolgáltatást használna.

By JoeP október 27, 2009 at 22:44 Tags: exchange 2010 Posted in: exchange 3 Comments

Egy kis esti adatbázis-kezelés

Ha már a DAG-gal foglalkozunk, nem mehetünk el egy másik nagyívű változtatás mellett.

Az Exchange 2010-nek igen durván átírták az adatbázisok kezelését végző részét. Illetve magukat az adatbázisokat.

Kezdték ott, hogy megváltoztatták az adatbázisok sémáját. Korábban egy postafiók adatait több adatbázisból kellett összeszedegetni. (Nem, nem több edb-re kell gondolni. Az edb fájl az egy nagy bináris blob, amin belül további kis adatbázisok találhatók.) A sémaváltozás lényege, hogy immár egy postafiók összes adata egy belső adatbázisban található. Ezzel két dolgot értek el: egyrészt kinyírták a SIS-t, másrészt begyorsították az adatbázis-kezelést.
Tudni kell, hogy a SIS (Single Instance Storage) trónja már a 2007-es Exchange szervernél is erősen ingott. Arról van ugye szó, hogy ha küldök egy levelet 10 embernek, akkor a levelet az adatbázisban csak egy példányban tároljuk, ahová az egyes postafiókokból pointerek mutatnak. Exchange 2007 alatt ez már csak a csatolásokra volt igaz - a 2010-nél pedig még azokra sem.
Mit nyertünk vele? Sebességet. Az Exchange fejlesztői már korábban is határozottan jelezték, hogy a sebesség vs tárhely optimalizálás vitában a sebességre szavaznak.

Hogyan lesz ebből sebességnövekedés? Az Exchange 2010 öszes adatbázis-kezelésre vonatkozó átalakítás mögött egy elv húzódott: a sok apró adatművelet helyett kevés, nagyobb adatterületet mozgató műveletek legyenek. A magyarázat roppant egyszerű: a sok kis műveletnél a fej össze-vissza ugrál a lemezen, míg a kevés, nagy műveleteknél sorfolytonosan tudunk dolgozni. Arról nem is beszélve, hogy az IO műveleteket adminisztrálni kell: minél kevesebb van belőlük, annál gyorsabban megy az adatkezelés. Értelemszerűen, ha átalakítjuk a sémát úgy, hogy az összetartozó adatok egymás mellett legyenek, a page méretet 8 KB-ról 32 KB-ra növeljük… ezzel mind-mind gyorsítottunk.

Persze ha ez így van, akkor jogosan kérdezheted, hogy miért nem lépték ezt meg korábban? Nos, a nagy adatbázisdarabokat valahogy kezelni is kellett, mégpedig a memóriában. Mióta vannak nagy memóriaterületeink? A 64-bites váltás óta. Melyik az egyértelműen és szigorúan 64-bites verzió? A 2010-es.

Persze nem csak sebességnövekedésről van szó. Tavasszal olyan értékeket mondtak Redmondban, hogy fel sem írtam: biztos voltam benne, hogy az én angolom béna és félrehallottam. De azóta többször meg lett erősítve írásban is, szóval a számok valószínűleg igazak: egy szerveren 100 vagy 150 adatbázis lehet (remélhetőleg házon belül egyszer majd lefocizzák a végleges számot), egy adatbázisról 16 másolat létezhet és egy adatbázis maximális mérete 2 TB. Nyilván az ajánlott postafiókok mérete is 2-10 GB közé szór, illetve a Personal Archívé 30 GB.

Impozáns, nem?

Természetesen ehhez nem csak gyorsítani kellett az adatbázis-kezelésen, kellett hozzá más is. Például az, hogy az adatbázisok alá mehet nyugodtan az olcsó hardver. Azért egy SAN fajlagos adattárolási költségével kalkulálva ezek a méretek minden IT vezető pulzusát felgyorsítanák. És kellett még egy nagyon fontos dolog: az Online Maintenance felpiszkálása. Még a 2007-es termékben is az Online Maintenance úgy viselkedett, mint egy határozatlan szűzlány. Be kellett időzíteni, hogy mikor dolgozhat az egyes adatbázisokkal, de ha munka közben intenzív tevékenységet észlelt egy adatbázison (pl. backup), akkor szégyenlősen visszavonult. Hogy majd legközelebb. Az Exchange 2010-ben az Online Maintenance _folyamatos_ és határozott.

Sokat lehetne ezeken a számokon agyalni. Én csak egy aspektusra hívnám fel figyelmet. Azért ezek a számok elég nyomós érvek arra nézve, hogy az Exchange fejlesztők miért utálják a backup/restore folyamatokat. Belegondoltál már egy 2 TB-s adatbázis visszatöltési idejébe?

By JoeP október 27, 2009 at 20:50 Tags: exchange 2010 Posted in: exchange No Comments

Magas rendelkezésreállás

Az előző írásban ész nélkül beleszaladtunk a DAG-ba, pedig a magas rendelkezésreállással kapcsolatban nem csak erről van szó.

Nézzük meg ezt a képet. Érdekes módon mindkét középső panelen az adatbáziskezelés a téma. A jobb szélső akciópanalen láthatjuk is, hogy melyik panelen, miket lehet csinálni.

Vajon miért lett két panelre szétbontva a munka?

Azért, mert a felső panel az organizáció szinten egyedi adatbázisokat mutatja és itt az adatbázis paramétereit lehet állítgatni. Az alsó panelen viszont a másolat adatbázisok szerepelnek - itt a replikáció paramétereit láthatjuk, ha lekérjük a tulajdonságlapot.

És ami a legszebb az egészben, az az, hogy a felső panelen láthatjuk, most éppen a Database Management tabon belül vagyunk, a DAG… az egy egészen másik tab.
?
A helyzet az, hogy adatbázisokat tükrözni, log shippinget megvalósítani tudunk DAG nélkül is. Ezt a 2007-es verzióban úgy hívták, hogy Standby Cluster Replication: egy adatbázisról tetszőlegesen sok másolat létezhetett - és ha az aktív adatbázis megsérült, vagy a szervert líbiai terroristák felrobbantották, a rendszergazda aktivizálta az egyik passzív adatbázist és az élet ment tovább.

A DAG ennél több. A DAG a Cluster Continuous Replication örököse(1). A DAG az, aki tudja az automatikus átállást.

(1) Mind a Local Continuous Replication, mind a Single Copy Cluster némán kimúltak. Nem fértek bele a koncepcióba.

A képen egy csomó ismerős dolgot láthatunk: member servers, witness server, witness directory, network jellegű erőforrások. Mind-mind mutatja, hogy itt a háttérben - miután egy varázslóval gyorsan végigrohantunk a telepítésen - tulajdonképpen egy NFS tipusú failover cluster jött létre.

Olyannyira, hogy a DAG látszik a Failover Cluster Management konzolból is. Bár sasszemű kollégák kiszúrhatják, hogy ez nem az igazi CCR clusterre jellemző minta, sokkal inkább az ún. standby clusterre hasonlít. (A Services and Applications folder alatt nincs semmi, pedig ott kellene vigyorognia a CMS névnek, azaz a DAG nevének. Mely azért a DNS-be bekerült.)

Nézzünk végre konkrétumokat.

Az első képen egy viszonylag egyszerű DAG megvalósítást láthatunk. Két szerver - és minden megy rajta. Nem csak a Mailbox szerepkör fut rajtuk, hanem a CAS és HTS is. Korábban mi minden kellett a magas rendelkezésreállású szolgáltatáshoz? Két MBX szerver a CCR-hez, legalább egy CAS/HTS szerver a maradék Exchange funkciókhoz. 2 enterprise licensz, 1 standard. DAG esetében egy vas - licenszestől - kipottyant.

Nézzük meg jobban az ábrát. Vészcsengő kinél jelzett be? Fent a kliens, el akarja érni az adatbázis szervert… egy load balanceren keresztül?! Adatbázisszerver… NLBS mögött? Ordítóan durva hiba lenne… ha a kliens közvetlenül érné el az MBX szervereket. De az Exchange 2010 struktújában nem így megy. Stay Tuned.

Ez már egy komolyabb DAG. Látható, hogy itt már leszedtük az MBX szerverekről a többi szerepkört, azok külön tömbben feszítenek az MBX szerverek előtt.
Két dolgot kell nagyon észrevenni az ábrán. Az egyik az MBX szerverek száma. Emlékszünk, CCR esetén két node volt. Snitt. SCR szervert akármennyit tehettünk mellé, de CCR-t nem. Ez a korlát immár a múlté - jelenleg 16 szerver a limit. A DAG-ban - hasonlóan a CCR-hez - nem feltétel, hogy a node-ok egy telephelyen legyenek. (Az egy Exchange organizáció viszont igen.) Egy hardverkövetelményt viszont kegyetlenül be kell tartani: a telephelyek közötti késleltetés nem lehet nagyobb 250 miliszekundumnál.
A másik: az aktív és passzív adatbázisok mellett feltűntek a Lagged adatbázisok is. Ez meg mi? Aki játszott már komolyabban SCR rendszerekkel, annak számára nem ismeretlen a fogalom. Ott ugyanis külön szabályozhatjuk, hogy a passzív adatbázisra mennyi kivárással (lag) játszódjon rá a log, illetve a rájátszás után mennyi idő múlva törlődjön fizikailag.
Mire is jó ez? Nos, nem árulok el nagy titkot, ha azt mondom, hogy az Exchange fiúk határozottan utálják a backup/restore eszközöket. Igyekeznek is bedobni minden trükköt, hogy kiváltsák ezeket. (Szvsz nem fog sikerülni.) A lagged adatbázis az egyik ilyen trükk. Amíg nem játszatom rá a logokat az adatbázisra, addig az az adatbázis a múltat mutatja. A maximális kivárás 14 nap. Tudom, most azt kérdezed, hogy és akkor mi van a dumpsterrel? Az is van. De. A dumpster a kuka. Ahová a törölt elemek kerülnek - és ahonnan azok egy bizonyos ideig még előbányászhatóak. (Jut eszembe, kuka ügyben is történtek komoly előrelépések.) De mi van, ha nem törlés jellegű adatmódosítás történt? Teszem azt, Vezérigazgató Árpád vett a lengyel piacon egy kínai e-book readert és amikor összeszinkronizálta az Exchange szerverrel, akkor felülírta az összes kontakját mandarin karakterekkel? Törlés nem történt, kritikus adatmódosítás igen. Ilyenkor jöhet a talonban őrizgetett lagged adatbázis.

Foglaljuk össze, akkor HA téren mik is a fejlemények:

Nem kell drága hardver. Nincs szükség közös háttértárolóra, nincs szükség SAN-ra. Bele kell lapátolni egy jó nagy kupac merevlemezt a gépbe (JBOD) vagy hozzákapcsolni egy diszktornyot (DAS), oszt jól van. Sima SATA2-es lemezek is bőven megteszik.
Olcsó elemekből, a mennyiség növelésével érünk el nagy megbízhatóságot. Ez az álmoskönyv szerint is jó skálázhatóságot jelent.
A redundancia adatbázis szinten szabályozható.
Tulajdonképpen az SCR/CCR rendszerek kombinációit használjuk, úgy, hogy a részletekkel nem kell foglalkoznunk(2).

(2) Tudom, te is olyan vagy, aki szeret a részletekkel foglalkozni. De nem mindenki ilyen.

By JoeP október 26, 2009 at 20:35 Tags: exchange 2010 Posted in: exchange 2 Comments

DAG

_Nem_ csak azért ez a kedvenc témaköröm, mert a kajakomnak is ugyanez a neve.
A magam részéről tényleg ezt tartom az egyik legjelentősebb architekturális változásnak.

DAG: Database Availability Group. Azaz magas rendelkezésreállás, Exchange módra.

De beszéljünk előbb egy kicsit az Exchange 4.0-ról.
Abban ugyanis olyasmi van, ami az Exchange 2010-ben már nincs.
Storage Group.

Hogyan lett ez a szegény SG kegyvesztett? Bár pontosabb lenne a kérdés, hogy hogyan is lett ez ennyire kegyelt?

Tények jönnek.

Egy merevlemezre a folyamatos írás sokkal-sokkal gyorsabb, mint a kevert írás/olvasás. Az írás ugyanis sorfolytonos, míg az olvasás véletlenszerű fejmozgással jár.
A tranzakció alapú adatbáziskezelés során a logfájlokba gyakorlatilag folyamatos írás történik, minimális olvasással.

Tehát olyan helyeken, ahol alaposan megtervezték az Exchange környezetet és fektettek hangsúlyt a sebességoptimalizálásra is, ott célszerűen az adatbázisokat egy magas rendelkezésreállású diszktömbre tették, a tranzakciós logokat pedig - logonként - külön vincseszterre, illetve tükörre.
Hogyan is nézett volna ki ez konkrétan? Ahány adatbázis, annyi tranzakciós log, azaz annyi merevlemez. Annyi kártya vagy annyi LUN. Ráadásul ezek a logok nem igényeltek ám olyan nagy helyeket, miközben a vásárolható merevlemezek alsó kapacitása folyamatosan kúszott felfelé. És - bármennyire pitiánernek is tűnik első látásra - de az angol ABC betűinek a száma véges. 20 használható betűm van. (Ez mondjuk a 2007-esig még nem okozott gondot.)

A fentiek miatt találták ki a Storage Group fogalmát. Gyakorlatilag az történt, hogy több adatbázis kezelését vonták úgy össze, hogy egy tranzakciós log tartozzon hozzájuk. Ez már mehetett külön vincseszterre.

Az elv működött is szépen, egészen a 2007-es Exchange feltűnéséig. Ebben a termékben jelentek meg a különböző szines-szagos CR technológiák és kavarták meg rendesen az állóvizet. Mindegyik szép is jó is, hasznosak, praktikusak… csak éppen van egy apró hátulütőjük: csak akkor működnek, ha egy Storage Groupban egy, azaz maximum egy adatbázis található.
Az Exchange 2007-ben még volt annyi játékterünk, hogy eldönthettük, használunk-e CR-t, vagy sem. Bár sok érv nem szólt amellett, hogy ne használjunk, de még választhattunk.
Ezt a lehetőséget műtötték ki a 2010-ből. Függetlenül attól, hogy kell-e CR technológia - aka logshipping -vagy sem. Innentől már csak egy adatbázis lehet egy Storage Groupban. Így viszont nincs értelme magának az SG-nek sem… azaz kikukázták.

De nem csak ennyi történt. A hierarchia csökkenhetett volna úgyis egy szintet, hogy az adatbázisok továbbra is szerverekhez kötődnek - de ha már vágtak, akkor rendeset vágtak. Az adatbázisok a továbbiakban az organizációhoz kötődnek - azaz organizáció szinten kell egyedi névvel bírniuk -, a szervereken immár csak tartózkodási preferenciájuk lesz. Azaz amennyiben létrehozunk egy DAG-ot, akkor az abban szereplő adatbázisoknál adhatjuk meg, hogy a körbe bevont szerverek közül melyiken milyen preferenciával tartózkodjanak. (Értelemszerűen a DAG-on belül mindegyik adatbázis példányai között log shipping kapcsolat alakul ki.)

Anélkül, hogy elmerülnénk - egyelőre - a technikai mélységekbe, az elv megértése végett nézzünk most végig egy sorozatot.

Nagyítás

Létrehoztunk egy DAG-ot. Van hozzá öt szerverem, öt adatbázisom. Szerverenként három adatbázist kezelek. A prioritásokat a sorok jelentik, nyilván az első sor jelenti az aktív adatbázis példányokat.

Nagyítás

Patch kedd. Lekapcsoljuk a 2-es szervert, és vadul nekiállunk foltozni. Látható, hogy a DB4, mely korábban ezen a szerveren volt aktív, most az 5-ös szerverre mászott át. A DB5, DB1 adatbázisokkal nincs semmi dolgunk, azoknak továbbra is működik az aktív példányuk.

Nagyítás

A takarítónő bevonul a szerverszobába és porszívózni akar. Kihúzza az egyik rack-et a konnektorból - és leáll a 3-as szerver is. Mit veszünk észre ebből? A DB2 immár az 1-es szerveren lett aktív, a DB3-nak és a DB4-nek még van aktív példánya. Igaz, a DB4-nek viszont már nincs passzív példánya.
A takarítónő pedig fütyürészve tolja a porszívó csövét.

Nagyítás

Befejeztük a hotfixek felrakását, visszaindítottuk a szervert. Az adatbázisok soványmalacvágtában tolják vissza a menetközben keletkezett logokat, majd ha ez megtörténik, a 2-es szerveren lévő DB4 aktívvá válik.

Nagyítás

A takker is befejezte a munkát, visszadugja a rack konnektorát, a helyi emberünk megkapta a riasztást, kisétál, visszakapcsolja a szervert. Az előző fázishoz hasonlóan itt is beindul a logok másolása, egészen addig, amíg ki nem alakul a kavarások előtti helyzet.

Mit vettek ebből észre a felhasználók? Gyakorlatilag semmit. Mindig volt valahol aktív adatbázisuk. (Hogy a váltásokat hogyan vészelték át szakadás nélkül? Erre később fogok kitérni.)

By JoeP október 25, 2009 at 20:21 Tags: exchange 2010 Posted in: exchange No Comments

Management Role Assignment Policy

Akkor azon már túl vagyunk, hogyan tudunk kisebb adminisztratív feladatokat kiszórni egyes kiválasztott embereknek. Most azt kellene megvizsgálni, hogyan tudunk tömegesen plusz jogosultságokat adni a felhasználóknak - természetesen csak a saját postafiókjaikra.

Mit is értek ez alatt? Minden postafióknak vannak tulajdonságai, azoknak pedig értékei. Mondjuk display name és ‘Kovács János’. Ebből a kupacból lehet - lehetne - mazsolázgatni, hogy miket módosíthat a felhasználó és miket csak a rendszergazda.

Van ennek értelme? Valamilyen szinten van. (Anno Jim McBee is így gondolta, hiszen már az Exchange 2003-hoz is gyártott egy hasonló funkcionalitású eszközt.) Nagy cégnél dolgozó kollégák biztosan tapasztalták már, hogy például valaki átköltözött a 306-os szobából a 308-asba, de ez a változás az életben nem lett átvezetve a címtárban. Sőt, nem ritkán még a névváltozások is csak hosszú késéssel futnak át a rendszeren. Megváltozik valakinek a mobilszáma? Van akkora rend és fegyelem(1), hogy a telefonkiadó személy értesíti az AD adminisztrátort a változásról?

(1) Megjegyzem, van, ahol van. De legalábbis a szándék. Igazán nagy cégnél nyilván ez az egész nem így működik, hanem vannak kiemelt adatbázisok (HR, HW/SW leltár) először ezekben vezetjük át a változásokat, majd onnan fognak átszivárogni a módosítások a másodlagos adatbázisokba (AD, CMDB).

Mindenesetre kisebb, kevésbé szabályozottan működő cégeknél értelmes alternatíva lehet, hogy magukra a felhasználókra bízzuk, hogy ezeket az apróbb jelentőségű változásokat maguk is adminisztrálhassák. Nyilván az emailcímüket, felhasználói nevüket nem módosíthatják - de a többi módosítás delegálása már pusztán csak bátorság és cégkultúra kérdése.

Ennyi az elv. Amitől viszont nekem égnek állt a szőr a hátamon, az az Exchange 2010 alap hozzáállása. Erősen bízom benne, hogy ez csak RC tulajdonság.
Arról van szó, hogy - a general fültől eltekintve - defaultban mindenki módosíthat minden adatot a postafiókján. A későbbiekben pedig mi szigoríthatunk majd házirendekkel a hozzáféréseken.

Mint látható, egy átlagos felhasználóval (Vidor) belépve csak a felső mezők szürkék, alatta mindent szabadon szerkeszthetünk, sőt, még el is menthetjük.

Legyen akkor az a feladat, hogy vegyük el az adatmódosítási jogot Kukától.

Kezdjük megint a get-command *role* paranccsal. Nem akarom most már annyira szájbarágósan levezetni, a policy-t a következőképpen fogjuk legyártani:
new-roleassignmentpolicy ‘Alap’

A szerepet a már ismert módon keressük meg.

Nem, ne lepődjünk meg a szövegen. Elsőre ugyan úgy tűnhet, hogy ez éppen hogy engedélyezné a módosítást… de higgyjél nekem, én végigcsináltam. Ez fogja _letiltani_.

A policy és a szerep összekapcsolása:
new-managementroleassignment –name ‘Alap-MyBaseOptions’ –policy ‘Alap’ –role ‘MyBaseOptions’

A policy ráhúzása egy postafiókra már rutinfeladat:
set-mailbox kuka –roleassignmentpolicy ‘Alap’

Ha az összes postafiókra akarjuk ráküldeni:
get-mailbox | set-mailbox -roleassignmentpolicy ‘Alap’

Értelemszerűen a parancs első felét pofozgatva finomíthatjuk a szűrést.

Elméletileg készen vagyunk. Nézzük is meg, mit csináltunk:
get-managementroleassignment -identity “Alap-MyBaseOptions” |fl

Ami elsőre feltűnhet: a RecipientReadScope és a RecipientWriteScope tulajdonságok értéke ‘Self’-re változott - azaz a felhasználó ténylegesen csak a saját postafiókjához fér hozzá. Aztán megint érdemes megvizsgálni a Distinguished Name paramétert. Ez most szemmel láthatóan nem a domain névtérben lévő objektumra mutat, a policy a konfigurációs névtérben keletkezett. Szerencsére meg is tudjuk nézni, ha az Active Directory Site & Services konzolból bemegyünk a Services folderbe és követjük a képen látható útvonalat.

Imhol. Látható, kincset találtunk. Nem csak a házirendek találhatók itt meg, hanem egyéb objektumok is: összerendelések, szerepek, szkópok. Igen, szerepek. Ha legközelebb keresnünk kell, elég, ha ide nézünk be. (Mondjuk, itt viszont csak név van, description tulajdonság nincs.)

Egy dolog van már csak hátra: teszteljünk. A kicsi adminokhoz hasonlóan a plusz postafiók jogosultságokat is az ECP-n keresztül érvényesíthetjük.

Nem is kell sokat magyaráznom. Kukával belépve az égegyadta világon minden szürke.

Végül álljon itt egy újabb értetlenkedés. Ha megnézed a szerepköröket, van azért ott egy csomó érdekes My* kezdetű szerepkör: MyContactInformation, MyProfileInformation, hogy mást ne mondjak. Szorgalmasan megcsináltam mindegyikhez a házirendet, rácsorgattam a felhasználóra - de az összes eredmény csak az lett, hogy onnantól a felhasználó nem tudott belépni az ECP-be.

RC.

Nos, ezzel nagyjából ki is veséztük a jogosultságokkal kapcsolatos változásokat. Jöhetnek az adatbázisok.

By JoeP október 24, 2009 at 20:15 Tags: exchange 2010 Posted in: exchange No Comments

Discovery Search

Az előző írásban létrehoztuk a szorcs nevű MRG-t, belepakoltuk Tudort. Most már csak tesztelni kellene.

De mivel?

Itt bizony komoly filozófiai problémába ütköztünk. Csináltunk egy kicsi admint. A gyakorlatban csinálhattunk volna akár száz különböző szerepkörűt is. Le van szabályozva, mit tehetnek. Oké. De hogyan fognak hozzáférni a rendszerhez? Telepítsünk mindenkinek Exchange admin tools-t? Na ne. Powershell ISE? Egy jogásznak?

Bajban vagyunk. Pontosabban lennénk, ha nem lenne a termék része az Exchange Control Panel, barátainak ECP.

Ez ismét egy webes szolgáltatás, a Powershell ISE cikkben látszik is az ábrán. Egy olyan webes szolgáltatás, melyhez először be kell autentikálnunk(1), aztán az RBAC alapján annyit adminkodhatunk… amennyit engedtek.

(1) Live ID vagy Form-Based Authentication (FBA). Mondjuk megnézném, ki az a Microsofton kívül, aki Live id alapú azonosítást használ.

Van is egy ábra, én ijesztgetésnek szoktam használni. A közepét ne is várd, hogy elmagyarázom. Az maradjon meg a fejlesztőknek.

A felső blokk a böngésző. Habár a Microsoft ki szokta hangsúlyozni, hogy bármilyen böngészőn elmegy(2), azért az Ajax ismerete feltétel. Lynx-en nem fog futni.

(2) Ez olyannyira így van, hogy tavasszal Redmondban Firefox-szal demózták.

Az a szaggatott vonal a tűzfalat jelképezi. Az ECP áthasít rajta, a 80-as porton.
Alul pedig látjuk, hogy az ECP mögött - minő meglepetés megint a Powershell, pontosabban az Exchange tudással felvértezett Exchange Management Shell áll. (Mivel webszolgáltatás, így nyilván megint WinRM-en keresztül.)

Ennyi elmélet után gépeljük be: https://xch10-xch.xch10.tst/ecp, majd lépjünk be mondjuk Kukával.

Nézzük, mit látunk. Pontosabban, mit nem látunk. Nincs neki legördülő menüje, szegény csak a saját postafiókjához fér hozzá. Azt nem mondanám, hogy semmi érdekes nincs, hiszen tele van a kép érdekességekkel(3) - de a Discovery Search funkcióval kapcsolatban tényleg nem látunk semmit.

(3) Az ECP pont az az újdonság, melyet írásban nem lehet bemutatni. Semmi kedvem 150 screenshot-ot betolni a blogra - anélkül meg nem megy. Viszont biztos vagyok benne, hogy hamarosan lesz egy csomó screencast a témáról. Ha már eddig nincs.

Menjünk tovább Tudorhoz.

Hoppá. Van legördülő menüje és van Mailbox Search tabja. Sőt, látható, hogy van is egy bribe11 nevű sikeres keresése. Ha erre kattintunk, láthatjuk a keresés konkrét paramétereit.

Például a szövegmezőben ott van a kulcsszó. A többi beállítás ablakát nem nyitom ki, a nevekből könnyen elképzelhető, mi rejtőzik mögöttük. Talán a Storage Location beállítás érdemel egy kis külön figyelmet: itt azt adjuk meg, melyik postafiókba kerüljön az eredmény. Ide nem kerülhet ám akármilyen postafiók, gyárilag létezik egy spéci mailbox (Discovery pampam qrvahosszúGUID), csak azt lehet kiválasztani.

Végül nézzük, mi történik, ha Tudor meg is akarja tekinteni a keresés eredményét?

Pofonvágták. Nincs joga.

Helyes. Pont így is akartuk.

Csakhogy… akkor hogyan tudjuk _mi_ megnézni a keresés eredményét? Azt mondja a net, hogy létezik egy beépített Management Role Group, Discovery Management néven. Csak ennek a tagja tudja megnézni a keresés eredményét. Megnéztem… és a csoport üres volt. Gyorsan beledobtam Hófehérkét, vártam 10 percet, megnéztem - és ő már látta az eredményt.
Remek.

De azért a kisördög nem hagyott békén. Én is csináltam egy MRG-t, volt egy gyári is… mivel tud többet a gyári?

get-rolegroup -identity “Discovery Management” | fl

Látszik, hogy két szerepkör van hozzárendelve a csoporthoz: Legal Hold, Mailbox Search. Ezzel bizony nem vagyok kisegítve, a Legal Hold egyfajta cenzúrázásra visszatartási jogot jelent, a másikat meg mi is beállítottuk. Akkor? A megoldás kulcsa a Discovery mailbox jogosultsági tábláján látszik.

Tehát a Discovery Management MRG csak úgy mellékesen Full Access jogot is kapot a Discovery mailboxra. Így könnyű.

Oké, ennyi mellébeszélés után nézzük meg végül, mi is lett a keresés eredménye.

Hát, itt látunk is valamit… meg nem is. Egy újabb sorjás eszköz, egy újabb bájos hasraesés.

A helyzet az, hogy ez a csomó minden, amit én most irkálok, egy előadáson alapszik. A konkrét projektor 1024*768-as felbontást tudott, tehát a demózásra használt virtuális gép képernyője 800*600 lett. Ez teljesen kiakasztotta az Exchange 2010 webes szolgáltatásait. Egész egyszerűen erre a képernyőméretre nem készültek fel.
Tessék megnézni alaposan az ábrát. Direkt úgy vágtam ki, hogy teljesen lehessen látni a virtuális gép ablakát. Jobboldalt alul látható, hogy ott lenne még anyag, csak éppen kilóg a képernyőről. Ha kilóg, hát kilóg - mondhatnánk… ha lenne gördítősáv. De nincs. Vagy elfogyott a gyárban, vagy a böngésző gondolja azt, hogy azért még csak kifértünk.
Ernő elszámolta a pixeleket is.
Aztán ha még jobban megnézzük az ábrát, akkor jobb felül, a sárga részen láthatjuk egy fekete téglalap szélét. Megsúgom, az a felhasználó adatait tartalmazná… ott lehetne látni azt, ki van belépve és ott lehetne kilépni is. Azaz nemcsak a függőleges gördítősáv fogyott el, hanem a vízszintes is.

És akkor az ábra. Erről túl sokat nem is lehet mondani. A folder neve a keresés neve lett, alatta pedig felhasználónként folderekre bontva láthatóak az érintett levelek. Jobb oldalon pedig a híres-nevezetes conversation view lenne látható, ha befért volna a képernyőre. (Nyugi, később már nagyobbra állítom a felbontást.)

Ezzel elég jól körbejártuk az MRG, ECP, Discovery témaköröket - nem beszéltem viszont még a házirenden alapuló jogosultságosztásról.

Legközelebb az jön.

By JoeP október 23, 2009 at 20:49 Tags: exchange 2010 Posted in: exchange 2 Comments

Management Role Group

Jó, ez mind szép. De hogyan lehet ezeket a jogosultságokat létrehozni, beállítani, konfigurálni?
Csak és kizárólag shellből.

A feladat: hallottuk valahol, hogy meg tudjuk adni bizonyos felhasználóknak azt a jogot, hogy szavakra, kifejezésekre kereshessenek egy komplett adatbázisban. A Microsoft ezt némi eufémizmussal Mailbox Discovery-nek nevezi - de nyugodtan használhatjuk rá a spionkodás kifejezést is. Értelemszerűen nem is adjuk meg boldog-boldogtalannak ezt a jogot - de például egy jogásznak, vagy egy biztonsági főnöknek talán(1). Csak és kizárólag ezt a jogot.

(1) Ezzel azért óvatosan. Tudomásom szerint - bár nem vagyok jogász, tehát ha valakinek pontosabb infója van, javítson - Magyarországon, amennyiben a cég nem iratott alá engedélyező jellegű nyilatkozatot a felhasználókkal, akkor nem is turkálhat a postafiókjaikban.

Oké. Hogyan induljunk el?

Offline help, az ugye nincs. Csináljunk úgy, mintha semmilyen kerülő úton sem férnénk hozzá az internethez. Így legalább meglátjuk, mennyire készséges eszköz is a shell.

Tehát: annyit tudunk, hogy szerepeket akarunk kiosztani. Először is szeretnénk csinálni mondjuk egy MRG-t.
Nagy bátran gépeljük be:

get-command *role*

Szerencsére nem is olyan sok. Értelemszerűen a new* kezdetű parancsok érdekelnek. Ez a new-rolegroup például határozottan szimpatikus.

get-help new-rolegroup -detailed

Nem, nem csak ennyit mond. A -detailed kapcsoló ránkborítja rendesen az információkat. De ez a lényeg. Mit is kell összeraknunk, ha azt akarjuk, hogy Tudor legyen a jogosult?

new-rolegroup -name szorcs -roles ?? -member Tudor

Nem is olyan bonyolult. Igenám, de honnan lesznek meg a szerepek nevei?

Kitérő:
A korábbi get-help parancs nemcsak a szintakszist adta vissza, hanem példákat is. Például ezt.

Nagyon jó példa! - csillant fel a szemem. Kiadni csak azt a jogot, hogy resetpassword. Be is gépeltem az ábrán található sort, persze felhasználóként Tudort megadva. Kövér errort kaptam. Azt mondta, hogy nincs ilyen szerepkör. Lányos zavaromban kipróbáltam mindenféle elgépelést, de semmi. Később megtaláltam a szerepeket a GUI-ban is (meg fogom mutatni) - és ott sem volt.

Tekintsük ezt a még kicsit sorjás RC bájos baklövésének.

Kitérő vége.

Menjünk vissza arra a *role* képre. Van-e ott olyasmi, amelyből megtudhatjuk a szerepek neveit, funkcióit? Értelemszerűen most a get* kezdetűek érdekelnek.
Nicsak: get-managementrole.
Lőjünk bele egyet. A sörétespuskával.

get-managementrole | fl

Ez a parancs az összes létező szerepről kiírja az összes létező tulajdonságot, az összes létező értékkel egyetemben. A szöveg pár percig csak görögni fog a képernyőn.
Nem baj. Amikor megállt, nézzük meg az utolsó szerepnél, hogy milyen tulajdonságai is vannak. Van például name és van description. Bőven elég nekünk.

get-managementrole | fl name, description

No, most is lesz szorgalmas görgés a képernyőn, de már jóval kevesebb. És utána kényelmesen végignézhetjük, milyen beépített szerepkörök vannak és mit is tudnak pontosan.
A fenti ábrán bejelöltem, hogy mi is kell nekünk: Mailbox Search.

Tehát a korábbi parancs valami ilyesmi lesz:

new-rolegroup -name szorcs -roles “Mailbox Search” -member Tudor

Le is fut. Meg is csinálja. Nézzük is meg.

get-rolegroup -identity szorcs | fl

Hát nem szép?

Nézzük végig, fentről lefelé.

RoleAssignments…? Adtunk meg assignment-et? Nem. Létrejött magától. Végülis… minden adott volt, hogy létrejöhessen.
Egyedüli tag Tudor. Pont így szerettük volna.
DistinguishedName… Van neki. Méghozzá láthatjuk, hogy ez egy valami a Microsoft Security Groups OU-ban.

Lám, lám, egy univerzális biztonsági csoport, benne egyedül Tudor. De ne legyenek illúzióink, a háttérben azért ez jóval több, mint egy univ.sec. csoport - láttuk, milyen extra tulajdonságai, pontosabban összerendelései vannak.

Kész. Már csak le kellene tesztelni.

Itt meg fogunk ismerkedni egy újabb nagyszerű eszközzel: Exchange Control Panel.

Legközelebb.

By JoeP október 22, 2009 at 20:05 Tags: exchange 2010 Posted in: exchange One Comment

RBAC

Oké, túljutottunk a telepítésen. Itt az idő, hogy megvizsgáljuk, mit is kaptunk.

Nyilván neki lehet úgy is állni, hogy elkezdünk össze-vissza kattogtatni a grafikus felületen, aztán figyeljük, hogy mi történik. Csak éppen nem javasolt. Az RBAC-ról speciel a GUI-n keresztül egész konkrétan semmit sem fogunk megtudni.
Pedig az egyik leglényegesebb változás.

A rövidítés azt takarja, hogy Role-Based Access Control.

Gondoljuk el, hogy mennyire kényeztetett el eddig minket az Exchange, ha a jogosultságok finomhangolásáról volt szó?
Van ugye 4 admin jogkörünk:

Organization admin: Maga az Atyaúristen.
Server admin: Atyaúristen, csak kicsiben: képességeinek korláta egy Exchange szerver.
Recipient admin: Szintén az Olümposz lakója: ő a postafiókok terén mindenható.
View-only admin: Ő sem kispályás: mindent lát egy organizációban.

Egyébként pedig léteznek még a mezítlábas gyalogok, az úgynevezett júzerek.

Bármi ettől eltérő jogosultságot szerettünk volna kikeverni, be kellett merészkednünk a security descriptorok, access tokenek sűrű, sötét dzsungelébe. És ebben nem is az ismeretlen dzsungel volt a fő baj, hanem az, hogy a nagynehezen összefércelt jogosultságaink upgrade esetén mentek a levesbe.

Szerencsére itt van az RBAC. Illetve lesz.

Két irányban tágítja a lehetőségeket:

Lehetővé teszi ún. kicsi adminok létrehozását. Rengeteg előregyártott szerepkört tartalmaz, de a lista custom szerepkörökkel is bővíthető. Ezeket a szerepeket hozzárendelhetjük univerzális csoportokhoz, a csoportokba pedig behajigálhatunk felhasználót, csoportot, recipientet.
Többlet lehetőségeket biztosíthatunk az egyes felhasználóknak, természetesen csak a saját postafiókjaikra. Nem meglepő, hogy erre a célra házirendeket fogunk felhasználni.

1. Management Role Group

Az ábrán láthatjuk részletesen is, milyen környezetben létezhetnek a kicsi adminok.
Létezik egy Management Role Group (MRG). Ez egy univerzális group, ide szórjuk be a konkrét szereppel megbízott felhasználót, csoportot, recipientet. A másik oldalon létezik egy vagy több szerepkör. Mint írtam, ez lehet beépített, vagy általunk gyártott. (Első körben mindenképpen az előbbi. Ahogy elnéztem, nem túl egyszerű dolog szerepet gyártani.)
A kettő között egy összerendelés, egy Management Role Assignment hoz létre kapcsolatot. Ennek az összerendelésnek még van egy scope paramétere is, miszerint az MRG a címtár egyes névterein belül - eltekintve persze a schema névtértől - mihez fér hozzá írás/olvasás jogosultságokkal.

2. Management Role Assignment Policy

Itt elkövettem egy apró bakit, mert szerettem volna a két eset közötti hasonlóságot bemutatni. A valóságban természetesen nem a felhasználók esnek rá a házirendre, hanem pont fordítva.
Tehát. Létrehozunk egy Management Role Assignment Policy-t (MRAP), melyet majd valahogyan (powershell, powershell) ráküldünk bizonyos recipientekre. A jobb oldalon ugyanazok a szerepek találhatók, mint az előző ábránál. Alul pedig a Management Role Assignment kapcsolja össze a házirendet a szerepekkel. Fontos eltérés, hogy ebben az esetben nincs értelme scope-ról beszélni, hiszen a felhasználók a saját postafiókjaikhoz férnek hozzá.

Végül összefoglalva a két eset:

Nagyítás

Ennyit az elméletről. A folytatásban kinevelünk egy nem is kicsi admint, akinek megadjuk azt a jogot, hogy az egész adatbázisban kereshessen (de az külön állítható, hogy meg is tekinthesse a keresés eredményét), illetve házirendből beállítjuk, hogy bizonyos felhasználók ne tudják módosítani a postafiókjukhoz kapcsolódó ún. nem túl fontos tulajdonságokat.

By JoeP október 21, 2009 at 22:25 Tags: exchange 2010 Posted in: exchange One Comment

Powershell ISE

Jó. Van egy zsír új Exchange 2010 szerverünk. Piszkálhatjuk konzolból és piszkálhatjuk shellből. Remek.

Egészen addig, amíg el nem bökjük.

Én ugyanis egy hanyag mozdulattal lehúztam a két shortcut-ot a desktopra: ne kelljen keresgélnem, legyenek mindig kéznél. Csakhogy - a fene tudja, miért - de tönkrement a felhasználóm profilja. Nem gond, adminnal belép, profil töröl, felhasználó újra belép. Igenám… de a gyári shortcut-ok a profillal együtt elvesztek.

Ritka hülye helyzet. Van egy teljesen jól működő Exchange 2010 szervered… csak éppen nem férsz hozzá. Oké, a konzol nem probléma. Egyrészt egy üres MMC konzolba is fel lehet venni, másrészt a bin könyvtárban ott van a gyári konzol is. Viszont a konzol ebben a verzióban leginkább csak dekoráció: az igazán komoly dolgokhoz már a shell kell. Naná.

Hogyan is indul a 2007-es EMS? Elindítjuk a Powershell 1.0-át, úgy, hogy paraméterként megadjuk neki az Exchange Extension plugint. Akkor keressünk rá a neten, hogy 2010-nél mi a helyzet.
Szomorú. Azt írják, hogy ugyan el lehet indítani így is, de nem kapunk teljes értékű shellt.
De akkor hogyan indítsam?

Máshogy. Plugin dugaszolás helyett kapcsolódni kell. Találtam ugyanis egy másik írást arról, hogyan lehet rákapcsolódni egy Exchange 2010 számítógépre másik gépről, úgy, hogy megkapjam a shellt. Vad? Ne mondd már. Jó egy éve azt lehet mindenhol olvasni, hogy a Powershell 2.0 már engedni fogja a távoli hozzáférést. Ami esetleg vad lehet, az az, hogy a lokális gépről próbáljuk távoli eléréssel elérni a helyi powershellt. De ha jobban belegondolsz, ez sem olyan szokatlan, hiszen az előző cikkben láthattad, a gyári shortcut is ezt csinálta.

Tehát:

Elindítok egy üres powershell ablakot.
Beírom egymás után a következő két sort:
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://<FQDN of Exchange 2010 server>/PowerShell/ -Authentication Kerberos
Import-PSSession $Session

Teszt: get-mailbox | fl name. Működik.
Na, ez már valami.

Csak éppen nehézkes és egyáltalán nem elegáns. Például a két parancsot be lehetne tenni egy szkriptbe és azt a szkriptet paraméterként átadni a powershell-nek. Meg lehet csinálni? Meg.

De létezik egy sokkal szebb és praktikusabb megoldás is. A Windows Server 2008 R2-nek, illetve a Windows 7-nek része az ún. Powershell ISE, azaz az Integrated Scripting Environment. (Úgy tudom, Windows 2003 szerverhez, Vistához és XP-hez meg letölthető.)

Mit is tud ez?

Nagyjából ezt.

Kaptunk egy programozói környezetet. Van interaktív ablakunk (legalsó rész), ahová be tudunk gépelni parancsokat, melyeknek az eredménye a középső - output - ablakban jelenik meg. A felső blokkban pedig szkripteket írhatunk, méghozzá akár többet is, hiszen szemmel láthatóan a szkriptekhez tabok tartoznak. Emellett felhívnám még a figyelmet a debug menüpontra. (A helyzetérzékeny help-ről nem is beszélve.)

Hogyan lesz ebből Exchange Management Shell indító shortcut-unk? Hát úgy, hogy azt a bizonyos másfél sort kirakjuk egy ps1 fájlba, majd gyártunk egy shortcut-ot a Powershell ISE-nek, paraméterként meghíva a szkriptünket. Így az induláskor egyből be is töltődik, rögtön meg is lehet futtatni az F5-tel.

Feladat megoldva. Még mindig fogalmam sincs, mi rejtőzik valójában a gyári shell shortcut mögött - de már nem is érdekel. Van jobb.

Mielőtt még lezárnánk ezt a témát, egy gondolat erejéig érdemes elmeditálni, mit is csinál ez a másfélsoros szkript. Első sor: definiálunk egy változót. Második sor: nyitunk egy sessiont, melynek paraméterei az előzőleg definiált változóban vannak. Mik is ezek a paraméterek? Egy név, egy URI… de micsoda URI! Leírom, hogy nálam ez konkrétan hogyan nézett ki:
http:\\xch10-xch.xch10.tst\powershell
Azaz léteznie kell az Exchange szerveremen egy powershell nevű webszolgáltatásnak.

És tényleg. Létezik. Tehát amikor egy sessiont nyitok, akkor ehhez a powershell webszolgáltatáshoz kapcsolódok- mely mögött a WinRM dübörög -, megkérem az Exchange modult, mindezt kerberos autentikációval.

Amellett, hogy szemmel láthatóan ez a felület sokkal praktikusabb, az ISE-nek van még egy óriási előnye. El is hangzott, de ha Windows7-et használsz, meg is győződhetsz róla: menjél be az Accessories/Powershell menübe - ott lesz az ISE. Ha belemásolod a fenti másfélsoros szkriptet - esetleg kipreparálod, hogy induláskor betöltődjön - akkor úgy tudod a munkaállomásodról menedzselni az Exchange 2010 szerveredet, hogy nem kellett hozzá semmiféle admin tools-t telepítened. Akár egy mezei felhasználó gépéről is tudsz adminkodni, ha éppen olyan szorult helyzetbe kerülsz.

Ja, hogy akkor majd tud a mezei felhasználó is? Nem, nem. Arra való az RBAC.

De erről majd legközelebb.

By JoeP október 20, 2009 at 16:04 Tags: exchange 2010 Posted in: exchange 5 Comments

Még mindig a telepítés

Ez egy nagyon rövid írás lesz.

Tessék alaposan tanulmányozni az ábrát, elolvasni a szöveget.

Majd vizsgáljuk meg az alapbeállítást.

Óvatosan, emberek.

By JoeP október 19, 2009 at 19:26 Tags: exchange 2010 Posted in: exchange 6 Comments

Itt a cédé, hol a cédé

Persze nem csak Exchange fronton történnek érdekes dolgok mostanában. Például - igaz, kényszerből - átálltam a munkahelyi gépemen Windows7-re. Azt kell mondjam, hogy határozottan tetszik, okos, gyors, jól kezelhető. Már azon töröm a fejem, hogyan fogom tudni meglépni a tömeges átállást az otthoni hálózatban.

Két furcsaságot azért tapasztaltam.

Én elvből ellene vagyok annak, hogy user adatok legyenek a C: meghajtón. A telepítések után majdhogynem az az első dolog, hogy a user könyvtárat átmozgatom a D:-re. Windows 7 alatt viszont library struktúra van (tetszik), melynek a gyökérpontján nem lehet változtatni. Ha mozgatni akarok, akkor az alatta lévő összes foldert kell átmozgatnom, egyenként. Nem egy világfájdalom, de egy kicsit kényelmetlen.

A másik viszont tényleg furcsaság. Már telepítés során létrehoztam a két szükséges partíciót, a DVD olvasóm emiatt a keresztségben az E: nevet kapta. Nem is volt ezzel semmi baj, amíg be nem dugtam egy USB hordozható merevlemezt, mely lecsapott az E: betűre. A DVD olvasóm eltűnt. Oké, Disk Management, átállítottam a hordozható lemezt valahová máshová, gép újraindít - volt DVD olvasóm. Csakhogy ugyanezt eljátszotta később az USB kulcsokkal is. (A sajátommal nem, mert azt átraktam az F:-re és onnantól nem ütköztek - de az idegen kulcsokkal igen.) Eluntam, átraktam a DVD olvasót az U: betűre, így legalább nyugtom lesz. Gondoltam én.

Ez ugye egy munkahelyi gép, ahol a net use paranccsal fixen be van konnektálva mindenféle kapcsolat. Nyilván betűütközés nincs, nem is lehet.
Aztán egyszer kellett volna DVD-t írnom… de hiába nyomogattam a burn gombot, nem történt semmi. Megnéztem… és megint nem volt DVD-m. A dolog kezdett komolyan idegesíteni, hiszen a megszokott USB eszközökön (PDA, egér) kívül nem volt bedugva semmi. Turkáltam, keresgéltem, nyomogattam a refresh, rescan gombokat… de hiába. Végül kínomban lefutattam a net use parancsot, megnézni mi is van ott… és láttam egy olyan bejegyzést, hogy K: \\szerver\e$. Azannya. Lehet, hogy ez az E$ üti ki a DVD olvasót? Dacára annak, hogy az eredetileg E: egységet már átraktam U:ra?
Teszt. Töröltem a K: kapcsolatot, gép újraindít… és azóta van DVD-m.
A dolog azért is különösen érthetetlen, mert a share-ek között nincs E$, ott már csak az U$ látszik.

Kezdek újra hinni az ufókban.

By JoeP október 18, 2009 at 19:49 Tags: windows 7 Posted in: általános No Comments

Ha internet van, minden van

Igenám… de ha nincs, akkor mi is van?

Bár nem is ez az igazi kérdés. Hanem az, hogy miért feltételezték a fejlesztők azt, hogy internetkapcsolat, az mindig lesz?

Kezdjük rögtön az elején. Az Exchange 2010-nek vannak szigorú előfeltételei. Ezek közül néhányat elég a netről letölteni, viszont ott van a .net 3.5sp1, amelynél csak a trailert tudod lekapni, a telepítés maradék része online megy. (Vagy WSUS-ról, persze. De pont a .net 3.5 sp1 esetében láttam már WSUS-on keresztüli nem túl normális települést egy ügyfélnél.)

Itt volt az a pont a tesztlabor összerakásánál, ahol megakadtam. Eredetileg úgy képzeltem, hogy az egész labor csak a virtuális hálón belül lesz látható - nemhogy az internet felé, de még csak a céges háló felé sem fog látszani. De hát a .net… ideiglenesen benyitottam a cég felé, onnan meg kifelé a netre. A sikeres telepítéshez még be kellett konfigurálnom a winhttp proxy beállításait, aztán hajrá. Fel is szaladt a .net, el is távolítottam a plusz hálózati kártyát.
Mentem tovább.

Eljutottam odáig, hogy végignyomkodtam a setup GUI-t, az pedig lelkes tüzijáték mellett közölte, hogy sikerült a telepítés. Aztán megkérdezte, hogy most rögtön szeretnék-e belépni a menedzsment konzolba? Persze. Tekerés, homokóra… majd közölte, hogy a gépen nincs Exchange szerver.
Miközben a háttérben még durrogtak a petárdák.
WTF?
Elindítottam a shellt, de hasonlóan jártam. Az azt mondta, hogy nem fut az IIS, meg a WinRM. Naná, hogy futott mindkettő.

Nem kicsit néztem ki hülyén a fejemből.

Aztán szerencsére beugrott a megoldás. Hiszen mind a shell, mind a konzol powershellre épül, az pedig lokálisan is távoli elérést használ, azaz a winrm-en keresztül szeretne kapcsolódni a szerverhez. Mivel a winrm fut, a gond csak ott lehet, hogy a szerver nem találja magát. Miért is? Mert a winhttp-ben bentmaradt a proxy konfigurálás, a hálókártya meg már ki lett szedve. Az Exchange szerver nem találta meg a proxy szervert, emiatt meg nem találta meg magát. Ahogy töröltem a winhttp proxy beállítását, egyből lett konzolom, shellem.

Sóhaj. A lényeg, hogy immár minden rendben.

A megkönnyebbülés addig tartott, amíg valamit meg nem akartam nézni a beépített Help-ben. Nincs. Nincs offline Help. Csak olyan van, mely egyből a netre akar tenni.

Itt kezdtem el meredten nézni a plafont. Mi ez az idiotizmus? Miért kellene egy Exchange szervernek internet kijárat? A CAS szervert ISA szerveren keresztül érjük el, úgy, hogy ki van publikálva a 443-as portja. A HTS szerver elé ma már kötelezően kell egy smarthost - mely ugye lehet akár egy Edge Trasnport szerver is. A Mailbox szervernek pedig abszolút semmi köze nincs az internethez. Hogyan gondolják akkor, hogy nincs offline Help?
Jó, nyilván megoldható. Általában úgyis rdp-n keresztül lépek be, tehát a gazdagép böngészőjéből tudok keresni… de akkoris kényelmetlen.
Meg szemléletileg fura.

By JoeP október 15, 2009 at 19:04 Tags: exchange 2010 Posted in: exchange 7 Comments

A setup csapat valószínűleg még mindig be van lőve

Hosszú sorozatot indítok el ezzel az írással. Nemrég tartottam egy - számomra is meglepően hosszú - előadást az Exchange 2010-ről. Nem tudom, más hogyan csinálja, nálam felkészülés során egy csomó cetli szokott keletkezni, melyeket aztán vagy felhasználok, vagy sem.

Ezekről a fecnikről fogom előszedni sorban a témákat.

Még egy megjegyzés. A sorozat az RC verzióval megtapasztalt élményekről szól. Az RC ugye feature tekintetben lezárt, de működni még nem működik hibátlanul - márpedig az MS ebben az utóbbiban nagyon jó. Ergo minden morgásnál tessék hozzáérteni, hogy jó eséllyel a végleges verzióban ezek javítva lesznek. (A sorozat végére valószínűleg elérhető lesz az RTM is, abban le fogom ellenőrizni a számomra fájó hiányosságokat - és remélhetőleg revideálnom kell majd az írásokat.)

Csapjunk bele.

Az Exchange 2007 messze kiemelkedően legrosszabb, legvacakabb, legfrusztrálóbb része a setup alkalmazás volt. Rengeteg írásban mondtam már el a véleményemet… bár néha úgy érzem, hogy még mindig nem dühöngtem eleget.

Nyilván borzasztóan kiváncsi voltam, ehhez képest milyen lesz ez a modul az új termékben.

Háát…

Problémába ugyan nem ütköztem, bosszantó kellemetlenségekbe inkább. Ráadásul úgy, hogy a laborkörnyezetben abszolút zöld mezős telepítés folyt, a címtár is, az Exchange organizáció is frissen lett kialakítva, maga az Exchange szerver teljesen általánosan tartalmazta a három fő szerepkört - igazából észre sem lett volna szabad vennem magát a telepítő programot.

Észrevettem.

Bár először csak szélesen vigyorogtam. A Microsoftnak ugyanis sikerült megoldani azt a régóta fennálló kellemetlen problémát, hogyan is tudnák rávenni az olvasót parancssori telepítésnél, hogy olvassa el a licensz szerződést. Születtek persze erre korábban is megoldások, pl. egy felhívás, hogy olvasd el… de ezzel a módszerrel ugye nem lehetett úgynevezett határozottan ráutaló magatartást kicsiholni a felhasználóból.
Lássuk, mit izzadtak ki a hegyek.

Az történik, hogy amikor elindítod a programot, elindul egy várakozási ciklus. A program megvárja, hogy elolvasd az általa jelzett címen található szerződést. Az idő múlását pöttyök kirakásával jelzi. Ha elveszítenéd a türelmedet és nyomsz neki egy kövér space-t, azzal azt jelzed, hogy nem fogadtad el a szerződést. Végig kell várnod azt az időt, amennyi a programtervezők (feltéve, hogy volt ilyen) szerint arra kell, hogy elolvasd a szerződést.
Mókás.
Elsőre.

Csakhogy a fenti várakoztató eljárás a program minden futásakor elindul. Márpedig egy címtár preparálás - még ha minden simán megy - akkor is négy futtatást igényel.

De az asztalomon a tíz párhuzamos csík nem ekkor keletkezett. Hanem a harmadik lépésben, ahol elfelejtettem megadni egy paramétert. (Szűz telepítés, meg kell adni a keletkező organizáció nevét.)

Nézzük végig, mi történt. Kiadtam a ’setup /p’ parancsot. Megjelent a szerződésolvasós abuzálás. Kivártam. Aztán a telepítő bőszen elkezdte felolvasni a szükséges fájlokat. Majd amikor felolvasta, akkor írta vissza, hogy elfelejtettem megadni egy paramétert.
Érted. Végigváratta velem a szerződés tanulmányozására szánt időt, felolvasta a fájlokat - és csak ekkor vizsgálta meg az általam beadott parancsot és vette észre, hogy hiányzik egy paraméter.

Egyszerűen nem túl sok értelmes magyarázat adódik a húzásra. Oké, lehetne mondani, hogy önmagában a setup.exe-ben nincs benne az a tudás, hogy melyik indítási üzemmódhoz milyen paraméterek szükségesek és ezt egy xml fájlból olvassa fel - de ez sem ad magyarázatot arra, miért kell megvárni az ellenőrzéssel a licenszolvasási nyaggatást. Jelzem, nem is az az 1-2 perc zavar, amíg várnom kellett (el tudtam tölteni hasznosan), hanem az ijeszt meg, hogy ha enyire felületesek még ilyen egyszerű esetben is, akkor mire számíthatok bonyolultabb forgatókönyvek esetén?
Féljek annyira, mint a 2007-esnél?

ps.
Találd ki, hogy amikor végre eljutottam a setup GUI-hoz, mi volt a harmadik képernyő?
Úgy van: a licensz szerződés. Melyet le kellett okéznom.

By JoeP október 15, 2009 at 01:47 Tags: exchange 2010 Posted in: exchange One Comment

Helyesírás-ellenőrzés kinyírása a Chrome-ban

Ezt leginkább csak magam számára írom ide emlékeztetőnek. (Mostanában rendszeresen telepítek újra gépeket és mindig turkálnom kell egy csomót, mire megtalálom az érintett fájlt.)

Tehát az alapvetően kikapcsolhatatlan helyesírás-ellenőrzőt úgy lehet kikapcsolni, hogy bezárjuk a böngészőt, megkeressük a felhasználói profilban a nyelvre utaló bdic fájlt (nálam pl. en-GB-1-1.bdic), megnyitjuk egy txt editorral, kitöröljük a tartalmát majd visszamentjük 0 méretű fájlként. Ha csak letörölnénk, a Chrome újra legyártaná.
Amit nem részleteztem az az, hogy pontosan hol is van a fájl. Nos, ez operációs rendszertől függően változik, nekem most Windows 7 alatt egész pontosan a c:\users\enyimnev\appdata\local\google\chrome\application\dictionaries könyvtárban található.

By JoeP október 14, 2009 at 11:05 Posted in: általános 7 Comments

New kid on the block

Nehogy már pont itt ne írjam meg: publikus lett a TCP/IP alapjairól írt könyvem.

By JoeP október 14, 2009 at 00:53 Tags: network Posted in: máshol No Comments

Breaking News

Azt írják, hogy alig egy órája kirugdalták az Exchange 2010-et az utcára.

Sok sikert, öreg harcos.

By JoeP október 9, 2009 at 00:30 Tags: news Posted in: exchange 2 Comments

Vicc

Van egy meglehetősen rejtélyes hibánk. Időnként az Address List szolgáltatás megáll a CCR clusteren és ilyenkor nem tudunk új postafiókokat létrehozni. A workaround az, hogy ráküldünk egy failover/failback párost, azaz gyakorlatilag újraindítjuk az AL szolgáltatást is magába foglaló System Attendant szolgáltatást.
Nyilván ez így még nem igazán kielégítő, emiatt turkáltam egy kicsit a neten. Így találtam meg a KB viccrovatát. Kicsit régi a történet, ma már nem is aktuális… de jó.

You cannot create a new mailbox or enable a mailbox in an Exchange Server 2007 environment on February 29, 2008

By JoeP szeptember 17, 2009 at 13:58 Tags: exchange 2007 Posted in: exchange 4 Comments

Már a Google is megbuggyant?

Egyre inkább törzshasználója leszek a Google Office rendszernek. Ez nem baj, ami praktikus, azt célszerű használni is. Kezdődött a Google Calendarral, mellyel végre sikerült egybeintegrálni a család összes tagjának egyéni Outlook naptárait és végre körtelefonálgatások nélkül tudok szinházi programot szervezni, nyaralásokat, rövidebb kirándulásokat tervezni. A következő lépés a Google Reader megjelenése volt, ezt végre már tudom PDA-n, mobilon is olvasni. A FeedDemon itt szerepelt le csúnyán. (Meg a hibás megjelenítésen, meg a lokális keresés hiányán, meg ugye külön alkalmazás, szemben az állandóan nyitva tartott böngészővel.) Aztán belépett a használt alkalmazások közé a Google Documents. Ha valamit gyorsan fel kell írnom valahová és azt szeretném, hogy mindig kéznél legyen, akkor ez majdnem(1) tökéletes. (Gondolatok, linkek szakmai írásokhoz, témák, melyekről majd írni akarok a blogban - bármelyikben(2) - de még rajzötletek is simán elférnek.) Elméletileg lenne erre tökéletes megoldás is az MS-től: a Onenote, PDA szinkronon keresztül. Csak éppen tré. Nem működik. (Ha belejavítok egy már létező és korábban összeszinkronizált szövegbe akármelyik gépen, a módosítás nem megy át a másikra. Ha egy bejegyzés átszinkronizálódott egy másik gépre, akkor már csak úgy lehet törölni, ha off-contact állapotban törlöm mindhárom eszközről.) Az Office-ba épített Notes… azt meg hagyjuk.

(1) Csak azért majdnem, mert nem tudom a PDA-ra úgy rászinkronizálni, hogy a doksik offline is meglegyenek.

(2) Elméletileg erre jók lennének a blogadmin felületek is, de mégsem. Kényelmetlen elmenni az oldalra, belépni, aztán beírni a cuccot a draftokhoz. Ráadásul ekkor keverednek a már kész, de még nem publikált, illetve a még csak piszkozat írások. Inkább fordított folyamat zajlott le: a blogpiszkozatok kerültek át a Google Document-be.

Szóval így álltunk. Egészen pár nappal ezelőttig, amikortól is a következő képet kapom, ha átváltok a Calendar-ra.

Hiába vártam utána akármennyit is. Minden más Google alkalmazás tökéletesen működik. Kipróbáltam más böngészőből is: IE alatt megy a Calendar. Átmentem más gépekhez. Végül se az otthoni, se a munkahelyi, se a tabletpc nem tudta elérni a Calendar-t Firefox-ból, ellenben mindenféle létező egyéb böngészőből simán ment.
Végiggondoltam a dolgot. Végülis, nekem nem olyan fontos, hogy a háttérben állandóan figyelő Google Office Firefox-on fusson - egyik funkciója sem FF plugin specifikus.

Emiatt döntöttem a Chrome mellett. (Ha már Google.)

Az otthoni két gépre simán fel is szaladt, kicsi, gyors - és mivel csak egy célra használom, nem érdekel, hogyan viselkedik úgy általában a neten.

Csakhogy. A munkahelyemen már megráztam a pofonfát.
A Chrome ugyanis nem olyan, hogy letöltöd és lefuttatsz egy exe fájlt. Az interneten keresztül akar telepíteni. Initializing… initializing… nem sikerült neki. Feldobott egy hibamegoldó ablakot, de a tippek nem segítettek. Jöhetett a jó öreg proxycfg -u parancs, de most hiába. Az se sokat segített, hogy a Chrome oldaláról le lehetett tölteni egy 500KB-os fájlt, mert ez csak trailer. Később ez se tudott túljutni az inicializálós fázison.
Szétnéztem a neten… és megtaláltam ezt. Hát… azért ez elég rendesen gáz. Habár a hiba nem pont ez, de van az oldalon egy link egy _teljes_ telepítőkészletre. Letöltöttem. Elindítottam. Aztán ez is beleveszett az inicializációs folyamatba.
Továbbolvastam a hozzászólásokat. Volt még ott link egy könyvtárra, amelyben komplett Chrome installációk voltak becsomagolva… de valahogy az útvonal neve (buildbot) nem tetszett. Vártam, vártam… aztán ráböktem arra a piros ikszre az inicializálós ablak jobb felső sarkában. Erre feljött az üzenet, hogy a telepítés sikeres volt. ???
Elindítottam. Működött. Beírtam egy címet. Közölte, hogy nem éri el a weblapot.
Aha. Proxy.
Nézzük, proxy konfigurálás. Rákattintottam a gombra - és behozta az IE connection paneljét.
Itt estem le a székről. Hát annyira szarul megy már a Google-nek is, hogy nem fér bele a mérnök munkaidejébe egy beállítóablak legyártása? Hogy bekérje, milyen proxy is van?
De ezzel még nincs vége. Ugyanis nálam az IE is be van állítva, tehát elméletileg át kellett volna tudnia venni az értékeket. Csak éppen a cégnél szkript adja fel az éppen aktuális proxy-t. És azok a zseniális fiúk a Chrome-nál ezt már nem bírták lekezelni.
Így most választhatok:

Bekonfigurálom az Internet Explorert egy fix proxyra, elvesztve ezzel a szkript okozta rugalmasságot.
Törlöm a francba a Chrome-ot, és - a Firefox hiba miatt - a nagyobb erőforrásigényű Internet Explorert használom a Google Office-hoz. Vicces. Meg persze reménykedek, hogy valakinek eszébe jut majd berakni egy adatbekérő panelt a Chrome proxy beállításaihoz.

By JoeP szeptember 10, 2009 at 01:57 Tags: KiMivelSzív Posted in: általános 10 Comments

Szorgos hétköznapok

A feladat első lépése: telepítsünk HP Blade szerverre Windows Server 2008-at. Nem nagy ügy, virtual media bekonnektálva, nextnextfinish. ILO-ról beléptem, a hálókártyát beállítottam, a hardveres kolléga fellapátolta a PSP-t… aztán más projektre szólított a kötelesség. Miután ott eljutottunk odáig, hogy a labda már az ügyfél oldalán pattogott, jöhettem vissza a blade szerveremhez. Melyet időközben tokkal-vonóval, cage-dzsel, storage-dzsal átcipeltek egy másik épületbe. Ez ugye az alkalmazástelepítőt nem érdekli, a lényeg, hogy a drót túloldalán ott ficánkoljon a vas.

Nos, ez ficánkolt. Például az általam beállított IP címen nem tudtam elérni. ILO. A kártya DHCP-n volt. Visszaállítottam. Erre közölte, hogy ilyen konfigja már van egy hálózati kártyának, akarom, hogy azt törölje? Na, a hülye megőrzött valami régi értéket… persze, töröld, fiam.
Gépnév? Ez is átalakult valami random krikszkraksszá. Visszaneveztem, újraindítás. Megint nem lehetett elérni RDP-n. ILO. A hálókártya megint DHCP-s lett. Ekkor tűnt föl, hogy megváltoztatta Local Area Connection mögött a számot. Mi a fene? Ez minden újraindításkor újradetektálja és új kártyának ismeri fel a meglévő hálókártyáját? Visszakonfiguráltam. Megint figyelmeztetett, hogy ilyen konfig már van. Töröld, b+. Az OK után kiváncsiságból visszanéztem: kitörölte a DGW értékét. Visszaírtam.

Mehettünk tovább.

Átnéztem a rendszertervet - és kiderült, hogy más IP tartományba kerültünk, mint amit 1 hónappal ezelőtt tudtam. Már remegő kezekkel mentem be az IPv4 beállítások közé. Átírtam az IP címet, újraindítottam a szervert. Mondanom sem kell, megint elveszett. ILO. Újabb szám a hálókártya neve mellett - és persze DHCP-s. Káromkodás. Visszakonfiguráltam, dühösen lenyomtam a figyelmeztetést, miszerint egy nemlétező hálózati kártyának is ugyanez a konfigurációja. Dögölj meg. A beállítás után visszanéztem: és eldobtam a billentyűzetet. Nem csak a DGW-t törölte ki, hanem visszaállította a régi IP címet is. Kijavítottam. Leokéztam. Visszanéztem. Megint átírta az IP címet.

Ekkor néztem körbe, hová van elrejtve a kandikamera.

Gép újraindítás. Jé, most nem lett DHCP-s. IP konfig, beírtam a DGW-t, átírtam az IP címet - és végre bele is törődött, nem bírált felül.

Oké. Next.

Léptessük be a tartományba. Belépett. Kért egy újraindítást. Ajjaj.

Természetesen megint DHCP-s lett, valami lehetetlen címmel. ILO. Megint befaragtam. Megint visszaragadta a régi IP címét, miközben törölte a DGW-t. Újraindítás. Megint befaragtam. Jó lett.
Huh.
Innentől már volt net. SP2. Gondolom, kitaláltad: újraindítás, DHCP, befaragás, régi IP cím, Default Gateway, újraindítás, befaragás.
Windowsupdate. Újraindítás. DHCP, bef, rIP, DGW, újr, bef.
Itt történt egy érdekesség: az időközben felugrott maliciózus kódokat kirugdosó program mellékesen megjegyezte, hogy volt valami conflicker.b a gépen, de letúrta.
Bakker.
Amíg átmentem a másik projektre, a gép csak úgy állt ott, mint szende lófütty a vadvirágos réten… a conflicker meg beporozta. Szóltam a permetezős kollégáknak, hogy fertőtlenítsenek. Nem mintha nem bíznék meg a maliciózus removal tool-ban… de nem bízok meg. Nos, jelzem, hogy meg lehet - a gép tiszta lett. Csakhogy a kolléga nekiállt feldobni egy SEP-et - és találd ki, mi lett belőle? Újraindítás. DHCP, bef, rIP, DGW, újr, bef.
Pedig itt már azt hittem, hogy megvan a bűnös, innentől már rendben lesz minden.

Bevadultam. Kitöröltem az összes hálókártyát. Becsörtettem a registry-be, kitöröltem minden olyan GUID nevű objektumot, ahol a Connection alobjektumban szerepelt a ‘Local Area Connection’ string. Végül újratelepítettem a HP PSP-t.
Újraindítás. Nos, az eddig letiltott két hálókártya eltűnt. Maradt az az egy, amelyiken link is volt. És átváltott DHCP-re. Bef, rIP, DGW, újr, bef.

Ekkor már keményen délután volt. Az egész napom azzal ment el, hogy egyszerűen csak hozzá akartam férni egy géphez. Közel 9 órát töltöttem el ILO felület előtt - és ha volt már hozzá szerencséd, akkor tudod, mennyire frusztráló is tud ez lenni.

Kész. Projekt lefújva. Ezek voltak az első gondolataim. Másik hardver nincs, ez lett volna egy cluster első node-ja… de egy ennyire kiszámíthatatlan hálózati kártyával öngyilkosság lett volna belevágni. Jön egy failover, aztán DHCP-re vált a kártya. Jól néznénk ki.

Ekkor kezdtem alaposabban gondolkodni. Tényleg nem értem néha magamat. Nagyon szűk határidő, sok feladat - és egy egész napot végigszívok egy lehetetlen hibával, lehetetlen körülmények között - ahelyett, hogy egyből gugliznék. Vagy nák.
Viszont még csak elképzelésem sem volt, hogyan fogalmazzam meg a jelenséget, emiatt kiindultam abból a ritka hülye üzenetből, miszerint egy régi, már nem használt hálózati kártyámnak is ugyanaz a konfigurációja, mint a mostaninak.
Nem írom le a teljes vadászatot, több ugráson keresztül ugyan, de eljutottam ide . Ránézésre baromira nem stimmel. XP. Meg nem konnektált hardverek a Device Manager-ben.

Device Manager displays only non-Plug and Play devices, drivers, and printers when you click Show hidden devices on the View menu. Devices that you install that are not connected to the computer (such as a Universal Serial Bus [USB] device or “ghosted” devices ) are not displayed in Device Manager, even when you click Show hidden devices.

Ez a lényeg kérem, a dőlt betűs rész. Ghost egységek. Hát mi a fene lehet ez, mint egy kupac szellemként rejtőzködő, valójában nem létező hálókártya? Gondold el: van egy hálózati kártya, melyet egyszer így ismert fel, egyszer meg úgy. És ezeket váltogatja. Ilyenkor úgy érzi, hogy kivettem egy hálókártyát és betettem helyette egy másikat. A réginek megőrzi a konfigurációját - mert hátha egyszer vissza fog kerülni - az újat meg DHCP-re rakja. Aztán amikor én beállítom az újon ugyanazt a konfigot és azt mondom neki, törölje a régi hálózati kártyát - akkor nem magát a kártyát törli, hanem csak a konfigját. Jön a következő boot, ekkor a másik kártyának ismeri fel - és kezdődik minden előlről.
Nyilván valami hasonlóra gondoltam én is - de a Device Manager-ben hiába kapcsoltam be a Show Hidden Device opciót, ez csak az ellenség megtévesztése volt. Nem mutatott ez semmit, maximum a szélben lengedező lófüttyöt azon a vadvirágos réten.

Előtte ugyanis el kell indítani egy command promptot adminisztrátori joggal, majd beadni neki, hogy:

set devmgr_show_nonpresent_devices=1

Vigyázat. Én legalábbis megszoptam. Ha ezután elindítottam a Control Panelből egy Device Manager-t, akkor a Show Hidden Device után megint a jólismert árvalányhajas lófütty jött. Ez ugyanis már másik session-nak számít. Azaz nem vagánykodásból kell a promptból indítani a konzolt.

start devmgmt.msc

Na, ekkor jött meg az összes fantom hálózati kártya. Mind a tizensok.

(A kép már egy későbbi állapotot ábrázol - de jól láthatóak a piros X-szel megjelölt fantom hálókártyák.)

Egyenként kitöröltem a bagázst - és minden rendben lett. Félórán keresztül csak restartoltam, IP címet állítgattam… de tényleg minden rendben.
Aztán eltöltöttem még egy kis időt, mire gatyába ráztam a WINS és DNS szervereket - szegények, mit képzelhettek erről az állandóan máshogy bejelentkezgető hostról - és kész. Jöhet a cluster.

Első lépés: faiover cluster feature telepítése. Lement. Reboot. Na?
Úgy van. DHCP. Csak most ugye megspékelve azzal, hogy a a failover cluster a régi adapterhez rendelődött hozzá, az újnál meg semmi. Illetve lófütty. Hálókártyák rendezése, failover cluster le, failover cluster fel, restart. DHCP. Bef, rIP, DGW, újr, bef.

Péntek éjfél. Ekkor fejeztem be aznapra, mert sürgős kardbadőlhetnékem támadt.

Szombat: új nap, új remények. Először eltávolítottam a rendszerből a HP NIC drivereket, hogy ne tudja keverni, milyen hálókártyának ismeri fel. Nem segített. Sóhaj, partíció töröl, operációs rendszer újratelepül. Kisérletképpen HP PSP nélkül. És csodák csodája, minden muzsikál. A 3 hálózati kártya masszívan tartja magát, se a gépátnevezés, se a tartományba léptetés nem hatja meg. Huh. Ellenteszt. Felraktam a HP Support Pack-ot, restart. DHCP. Bef, rIP, DGW, újr, bef.
Oké. Megvan a bűnös. Valamelyik program/driver a csomagból behülyíti a Windows-t.
Partíció radír, Windows újratelepül. Belépek… erre a hálózati kártyán még mindig ott volt az előző domaintagságra utaló hálózati név. Hát ez meg hogyan élte túl a teljes újratelepítést? Megnéztem a hálózati részt, ott vigyorgott a fantom kártya. Azannya. Újabb gyalu, a biztonság kedvéért 5 GB-vel kisebb új partícióra. Ha ezt is változatlanul éli túl a hálókártya, akkor elnevezem David Copperfield-nek.(1)

(1) Persze én voltam a hülye. Egyszerűen csak DHCP-re váltott, IP címet kapott, azon meg felismerte a tartományt. Csak nekem volt furcsa, hogy frissen telepített oprendszer már tartományt mutat.

De nem. Teljesen szép, szűz Windows 2008 jött fel. Oké. Hálózati kártya bekonfigurálva, gép átnevezés, reboot.
DHCP. Bef, rIP, DGW, újr, bef. Kardbadőlés.
Abszolút üres Windows, sehol semmi - és ott vigyorog a fantom kártya. Ami a reboot előtt az éles kártya volt. Aznapra ennyi jutott a sikerélményekből.

Vasárnap. Sebnyalogatás.

Hétfő. Ekkor már valamennyire állnia kellett volna a clusternek… ehhez képest legszívesebben már rég elhantoltam volna azt a szutyok vasat. Új ötlet. Hardveres kollégával konzultálva kiderült, hogy a gépben egy duálportos és két single portos hálókártya van. Mivel a cage csak három hálózati kimenettel rendelkezik, így az egyik hálózati kártyát letiltották - csakhogy ez pont a duál portos egyik portja lett. Lehet, hogy ettől hülyült meg a Windows. Mivel nekem elég a két hálózati kapcsolat, így váltunk: letiltják a duál portost és marad a két másik.
Kolléga elutazott a szerverekhez, átkonfigurálta.
Teszt.
Két fantom hálózati kártya vigyorgott vissza. Meg a tükörből az őrület. Aztán a remény fénye: lehet, hogy ez a két fantom még korábbi kisérletezések maradéka? Töröltem, Scan for new hardware… és nincs több fantom. Kezdtem reménykedni. Megint Scan. Még mindig jó. Kérem… én nem ehhez vagyok szokva. Elkezdtem őrült módon mindenfélének átnevezgetni a gépet, majd újraindítgattam. (Később csak az volt egy óra, míg a WINS szervereket kipucoltam.) De tartotta magát a gép, nem jöttek elő a fantomkártyák. Jöhetett a tartománybaléptetés, a HP PSP csomag… meg minden más.
28 órányi munka alatt eljutottam oda, hogy elkezdhettem bekonfigurálni az operációs rendszert. Miközben az egész cluster elindítására volt 3 munkanapunk. Szerencsére volt közben egy hétvége - az ugye nem számít, maximum csak nekem, de az meg megint nem számít. Így ha hajnalig nyomom, akkor esély van utolérni magunkat. (Kedd reggelre igértük a működőképes clustert.)

Szóval így.

By JoeP szeptember 7, 2009 at 21:22 Tags: blade, network Posted in: Windows server 3 Comments

Proxycfg

Csak jelzem, hogy élek.

Apró feljegyzés, leginkább magamnak.

Windows Server 2008. SP2-t felraktam. Már csak a maradék hotfixek hiányoztak. Windowsupdate, azt mondta, szétnéz… majd hibaüzenet.
Rutinos öreg róka már gépelte is be, hogy: proxycfg. Erre jött a válasz, hogy: miről beszélsz?
Hmm. Nincs. Végre egy kis izgalom. (Ezt tessék ironikusan érteni.)

De van helyette netsh. Így:

netsh
winhttp
show proxy

És igen, a beállított érték ‘direct access’ volt.

set proxy isaserver:8080
show proxy

És kész. Innentől már söpört is a windowsupdate.

By JoeP szeptember 4, 2009 at 13:28 Tags: ISA Posted in: Windows server No Comments

Trükkös HTTPS

Az ember már azt hiszi, ismeri az ISA szervert - aztán az mégis meg tudja lepni.

Jött a kérés az ügyféltől, hogy egy kollégájuk szeretne elérni egy weblapot a 8443-as porton. - Na, megint egy istentől, embertől elrugaszkodott webmester - gondoltam - akinek túl kerek szám a 80-as.

De gond egy szál se, pillanatok alatt összedobtam a megfelelő szabályt.
- Teszteljetek! - írtam vissza.

Nem működött.

Ekkor néztem meg jobban, miről is van szó. Jé, ez https. Persze, csaptam a fejemre, csak én lehetek annyira vak, hogy nem ismerem fel, hogy a portszám csak egy számjegyben különbözik a 443-as https porttól.
- Aha, szóval ez egy szupertrükkös webmester - konstatáltam - aki így akarja átvágni a rosszfiúkat. Szvsz elég béna megoldás, ha én portszkennelnék, simán felvenném ezt is a listára, oszt jól van. Cserébe szopatják a tűzfal mögül érkezőket.

Na, mindegy, nézzük, mi van a logban.

The specified Secure Sockets Layer (SSL) port is not allowed. ISA Server is not configured to allow SSL requests from this port. Most Web browsers use port 443 for SSL requests.

Kösz, Csoki. Most, hogy már tudom, hogy a legtöbb böngésző a 443-as portot használja az SSL-hez, most már biztosan nyugodtabban fogok aludni.

Némileg persze bosszantott, hogy nagyon nem értettem ezt az egészet. Miért nem engedélyezett? Hiszen tettem rá szabályt. Nehogymár ne lehessen tűzfalszabállyal egy tetszőleges portot kiengedni? A webproxy nem fogadná el? Azon lehet ugyan https portot állítani, de az nagyon nem erről szól. (Akar a fene proxykat láncolni.)

Irodalmazás. Azaz google.

Nos, kérem a megoldás az, hogy az a kis egyszerű webproxy fogadja a kéréseket a saját bekonfigurált portján - általában 8080 - majd ha https-re kell továbbmennie, akkor bepróbálkozik a 443-as porton. Ha ettől eltérő portot adok meg az URL-ben - mint ahogy a szorgos user ezt is tette - akkor döbbenet és lefagyás következik. Az a port nincs engedélyezve a webproxy számára, mint kimenő ssl port.
Természetesen létezik rá megoldás, Shinder bácsi - ki más - írt is róla: el kell menni a www.isatools.org oldalra, le kell tölteni az isa_tpr.js szkriptet (van 2006-os is)… aztán a többit már lásd ott.

Azért ez a rész külön tetszett :

Note that if you have unbound the Web Proxy filter from the HTTP protocol, then Firewall and SecureNAT client connections made through the ISA firewall will not be redirected to the Web Proxy Filter. In this case, you can create a Protocol Definition for the alternate SSL port and then create an Access Rule allowing outbound access to that protocol.

By JoeP augusztus 12, 2009 at 23:43 Tags: ISA Posted in: ISA No Comments

Ki mivel szív?

Ez anno a régi Technet magazin egyik népszerű rovata volt. (Csak ott az utolsó szót egy szivecske rajz helyettesítette.)

Az egyik kedvenc rovatom volt: a mai napig úgy tartom, hogy egy hiba behatárolásából, megoldásából sokkal többet lehet tanulni, mint egy tisztán elméleti fejtegetéseket tartalmazó cikkből. (De a legtöbbet a kettő kombinációjából: az az ideális, ha a szerencsétlen rendszergazda miután leírta a megoldást, odaírja/odalinkeli mellé az elméletet is.)

Az egyik jó hír, hogy Jim Mcbee-nek eszébe jutott végre a blog jelszava(1). Egyből el is eresztett 8 új írást. A másik jó hír, hogy az egyik egy igen érdekes hibát és annak megoldását tartalmazza.

(1) Illetve beindult az RSS feed-je. Mert ahogy látom, írni írt… csak az RSS reader nem látta.

By JoeP július 26, 2009 at 09:59 Tags: KiMivelSzív Posted in: exchange No Comments

Pislant a hálókártya

Erre az esetmegoldásra nem leszek büszke, de tanulság azért akad benne.

Nagyon fontos ügyfél (habár hülyeség, mindegyik az) telefonál, hogy megállt a cégnél az internetelérés. Különböző okok miatt az ISA webproxy-ra gyanakszik. Mivel internet nélkül nincs élet, így a bejelentés magas prioritású.
A megoldást nehezíti, hogy magát a belső hálózatot nem mi üzemeltetjük, abszolút semmi hozzáférésünk sincsen. Csak az ISA-t kezeljük mi.

Megnéztem a logokat, mi is a helyzet a webforgalommal: a 80-as porton remekül hasítottak a bitek, még a vizsgálat közben is. Leellenőriztem, hogy ez valós forgalom-e. Az volt. Ment vissza a levél: Kedves Ügyfél, te valamit nagyon benéztél, az ISA-n gyönyörűen megy a http.

Amire jött az indignált válasz, hogy márpedig ez nem megy. Biztos, hogy jó forgalmat néztem?

Bakker. Nem. Hiszen a böngészők webproxy kliensek, akik a webproxy filter listening portján érik el az ISA-t. A 80-as porton csak akkor megy webes forgalom, ha nem webproxy kliens forgalmaz. A konkrét esetben a webproxy filter egy lehetetlen porton (na jó, annyira nem, de akkor sem írom le) figyelt, arra rákeresve rögtön dőltek is a denied connection üzenetek.

Hát, ez már mindjárt más. Akkor itt tényleg baj van.

Event log. Tele volt gyönyörű kövér 14118-as hibákkal. Azt mondja:

Description: The Web Proxy filter failed to bind its socket to IP address port xxxx. This may have been caused by another service that is already using the same port or by a network adapter that is not functional. To resolve this issue, restart the Microsoft Firewall service. The error code specified in the data area of the event properties indicates the cause of the failure.

A részletes hibakód: 0×80072740.

Néhány perc keresgélés után meg is lett a magyarázat. (Komolyan mondom, ma egy informatikusnál az internetes keresési képesség a második legfontosabb készség. Az első az angol nyelv ismerete.) Itt van a KB cikk.
(Ne keverjük össze ezzel a másik cikkel: habár a hibaüzenet ugyanaz, de ez az írás arra az esetre vonatkozik, amikor IIS is fut az ISA mellett.)

Akkor most mi is a hipotézisünk? A hétvégén valószínűleg volt egy rövid időszak, amikor leesett a link az ISA szerver belső lábáról. Ekkor a Windows Server 2003 le is kapcsolta a konkrét hálózati kártyát. Ezt hívják úgy, hogy Media Sense… és feature. Igenám, de amikor visszajön a link és feléled a hálózati kártya, az ISA szerver webproxy filtere nem képes rákapaszkodni a kijelölt portjára. Támadhatják őt a böngészőkből a kliensek, nincs bind. (A pikáns az, hogy a netstat szerint persze ott figyel a megadott porton.) Megoldás? Újra kell indítani a Microsoft Firewall klienst.
Majd.
Eddigre ugyanis az ügyfél morogva beröffentett egy linux proxy-t, mondván ők nem érnek rá. Annyiból igazuk is volt, hogy az ISA nem csak az internet felé forgalmaz, hanem a nagyon fontos anya- és társvállalatok felé is, azt a forgalmat meg még egy percre sem lehet megszakítani szolgáltatás újraindításával.
Majd este.

Addig volt időm körbenézni - és sikerült be is igazolnom a hipotézist: abban a 10 percben, amikor az ISA log szerint megállt a webproxy filter, ott figyelt két bejegyzés a system event logban is:
Warning Event 4: Adapter xxxxxxx Adapter Link Down.
Majd pár perccel később:
Information: Adapter xxxxxxx Adapter Link Up.

A többi már annyira nem érdekes, késő este újra lett indítva a szervíz, minden a helyére került.

Ja, a tanulság: ISA szerveren lehet, hogy nem hülyeség letiltani a Media Sense opciót.
(Windows Server 2008-ban alaphelyzetben le is van.)

By JoeP július 21, 2009 at 22:03 Tags: ISA Posted in: ISA 5 Comments

Bitvadász vagy-e?

Haladva a korral - ugye tudjuk, előbb-utóbb a Microsoft is nyílt forráskódú lesz (Open Specific Documentation) - egy újabb adag technikai dokumentum került ki az internetre. Hogy egész pontos legyek, az Exchange 2010 működéséhez szükséges MS protokollok teljes és részletes leírása.

A doksik nyitólapja: Microsoft Exchange Server 2010 Beta Protocol Documentation.
De ha nem akarjuk egyenként letöltögetni a pdf fájlokat, akkor az utolsó linkről egy nagy tömörített fájlban is lekaphatóak.

Használati utasítás:

Először nyissuk meg az MS-OXPROTO fájlt, az egy jó nagy nyitódokumentáció.
Keressük meg benne a minket érdeklő protokollt.
Majd nyissuk meg a megadott fájlt.

Én kiváncsiságból az Autodiscovery működését néztem át - MS-OXDISCO - és meg vagyok vele elégedve: tisztességesen részletes.

By JoeP július 20, 2009 at 23:18 Tags: exchange 2010 Posted in: exchange No Comments

Sorvezető

Ha ISA 2006 szerveren keresztül szeretnénk Exchange 2007 webszolgáltatásokat kipublikálni, ahhoz ma már nem kell remegő kézzel nekifogni. Az internet tele van cikkekkel, írásokkal, tényleg minden információ begyűjthető. Konkrétan itt van egy MS cikk, ez alapján nem lehet semmi gond.

Vagy mégis?

Nos, amennyiben az Exchange szervered alatt Windows Server 2008 fut, akkor azért fognak érni meglepetések.

Nem akarom végig leírni a folyamatot, az említett cikk tényleg nagyon jó. Itt inkább csak a buktatókat gyűjteném össze.

Először is, a Windows 2003-as CA szerver nem fog tudni neked SAN tanúsítványt gyártani. A következő paranccsal lehet erre rábeszélni:
certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
Majd újra kell indítani a Certification szolgáltatást.

Oké. Fogod, elindítod a böngészőt az Exchange szerveren, rácsatlakozol a http://ca-server.cegnev.hu/certsrv/ weblapra - és már nem emlékszem pontosan, mit kapsz válaszul, de nem a megszokott nyitólapot. Valami olyasmit mond, hogy ez a tartalom a számodra nem érhető el.
Kedves.
A magyarázat itt található: http://support.microsoft.com/kb/922706.
A Windows Server 2003 alatti tanúsítványosztogató weblap olyan activex kontrollt használ, melyet a Windows Server 2008 / Vista undorral lök el magától. A megoldás: fel kell telepíteni egy patch-et a CA szerverre, hogy úgy is tudjon tanúsítványt osztogatni, ahogy az újabb fiúk kérik.

Akkor most már mehetünk is vissza a weblapra. De mégsem. Azt mondja, immár a helyi böngésző, hogy a CA weblapjának https-en keresztül kellene jönnie. Addig ő nem fogja megmutatni a tartalmat.

Kitérő: Szeneslapáttal igazítanám meg a frizuráját annak, aki ezt az egész nevetségesen idióta ‘Enhanced Security’ módú Internet Explorert kitalálta. Tipikusan az, amikor átesünk a ló túloldalára: használhatatlanná tesszük a terméket és a végtelenségig elbonyolítjuk az egyébként is meglehetősen érthetetlen konfigurálást. Ráadásul úgy tudom, W2k8 szerver alatt kikapcsolhatatlan - miközben ott már épp elég védelmet jelentene az UAC is. Amióta ez van, azóta az az első, hogy telepítem a Firefox-ot a szerverekre is. Szerveren úgyse nézeget az ember pornó oldalakat.

Fogcsikorgatás. Nyilván valahol át kell kattintani valamit, melynek a neve még csak nem is utal arra, hogy mit befolyásol. Szerencsére itt van a net, ahol egy sorstárs már megtalálta rá a workaround-ot.
Hurrá. Elérhető lett a CA weblapja.

Lehetne igényelni az Exchange tanúsítványát… de ez mégsem ennyire egyszerű. Amennyiben az Exchange szerverünk Windows Server 2003 alatt fut, akkor - ahogy a cikk is írja - powershell-ből tudunk tanúsítványt generálni. Csakhogy jelen esetben már W2k8 az alap, ezen már van grafikus felület is. Összedobunk egy custom MMC konzolt, felvesszük bele a Certificates (local machine) snapin-t. A Personal folderen jobbkattintunk, majd a lenti képen elmegyünk a ‘Create Custom Request’ menüponthoz.

Tulajdonképpen mehetnénk a ‘Request New Certificate’ menüpontba is, hiszen itt van, LAN-on belül a CA szerver, mindenki domaintag, ne kelljen már bináris fájl tartalmát kopipasztázgatni. Mehetnénk… de nem működik. A varázsló második ablakán minden szürke - és közli, hogy nekem bizony nincs lehetőségem webserver tanúsítványt igényelnem. Márpedig hidd el nekem, hogy ha nekem nincs meg ez a jogom, akkor senki másnak sem.
Marad a custom request.

Maga az igény összerakása nem túl bonyolult, egy kicsit szokni kell az újfajta grafikus elemeket, de nem vész. Rá kell kattintani minden izére, meg bigyóra, megnézni, mi is van mögöttük. (Shinder bácsi írása elég jól képbe rakhat bárkit.)
Az alábbi ábrán azt a részt emelném ki, amitől SAN lesz a tanúsítvány.

Igen, az alternatív nevek. Ahogy az előző linken is van - meg máshol is - beírtam a Subject mezőbe CN-ként a külső nevet, az Alternative Name alá meg az összes szóbajöhető lehetőséget, beleértve azt is, hogy bentről esetleg rövid névvel nyomul valaki. Amit a Subject mezőbe írtam, azt nyilván már nem írtam be az Alternative Name alá is. Aztán végigmentem a láncon, igényeltem, kiadtam, importáltam, majd exportáltam végül megint importáltam… szóval ahogy az első linken szépen le van írva - végül jött kintről az OWA teszt.

Nem sikerült. Azt írta ki, hogy a tanúsítvány nem erre a weblapra szól. A Firefox ennél imformatívabb volt, kiírta azt is, hogy mely weblapokra lenne jó ez a tanúsítvány: csak azokra, amelyek az Alternative Name mezőben szerepeltek. A Subject, az nem jött szóba.

Hozzáteszem, nem vagyok tanúsítvány guru. Fogalmam sincs, mennyire kötelező a Subject alatt CN tipusúnak megadni a nevet, nem tudom, lehet-e ott is DNS formátumot használni. Mindenesetre az egyszerűbb utat választottam, az Alternative Name alá is bedobtam a külső nevet - ahogy az ábrán is láthatod. Működött.

By JoeP július 16, 2009 at 22:40 Tags: exchange 2007, ISA Posted in: pki 6 Comments

Odahaza ne próbáljátok ki

Kollégám futott bele az esetbe. Látszólag ez is X aktaként indult.

Nagy cég, kétszintű domainszerkezet. A felhasználók is és az Exchange 2003 szerverek is a child domainban vannak. Alapvetően minden szépen működik.

A feladat: az Exchange 2007 óvatos beterelgetése.

A címtár preparálása rendben megtörtént, legalábbis a cég alkalmazottja szerint. (A francokat.) Kolléga kiment, szétnézett, látszólag tényleg rendben volt minden.: a csoportok létrejöttek, a séma módosult, az ég kék volt és a madarak csicseregtek.

CAS szerver, HTS szerver rendben be is épült. Jött volna a Mailbox szerver, de a telepítő feldobott egy figyelmeztetést:

Nem tűnik annyira veszélyesnek, nem villog, nem piros… de akkor is, mi lehet ez? Azt mondja, a forest root tartományban nincsen RUS. De hiszen van! Konzolból látszik, adsiedit-ből látszik, a tartományi replikáció nem jelez hibát. Akkor ott RUS-nak kell lennie.

Agyalás. Internet. Kérdések az üzemeltetőkhöz: a setup /preparelegacyexchangepermissions lement minden tartományban?
Persze, hiszen ha paraméter nélkül adják ki, akkor az mindenhol megtörténik.
A setup /preparedomain is lement mindenhol?
Igen.

Ötlet semmi.

Egyáltalán, fontos-e ez egyáltalán? Fórumon valaki felvetette ugyanezt, egy MVP kolléga leoltotta, hogy szarni bele, nem fontos.
Annyiból igaza van, hogy ha a forest root tartományban nincs felhasználó, nincs Exchange szerver, az Exchange 2007 meg úgyis feleslegessé teszi a RUS-t, akkor ki a fenét érdekel, hogy most létezik-e belőle példány a forest root-ban vagy sem?
Annyiból viszont nincs igaza, hogy az AD egy bonyolult, nehezen átlátható rendszer. Ezt tovább bonyolítani csak úgy lehet, ha az adott szinten biztosak vagyunk benne, hogy minden jól működik. Ha nem teljesen százas az AD és ráteszek egy Exchange 2007 szervert, ki garantálja, hogy nem buknak ki váratlan és rejtélyes hibák?

Aludtunk rá egyet.

Másnap leültünk beszélgetni, hátha a közös gondolkodás előrébb visz. És tényleg.

Kitaláltunk egy hipotézist. Mi van, ha - még évekkel ezelőtt - nem történt meg az Exchange 2003 szintű domainprep a forest root tartományban? Most meg a fiúk rányomtak egy setup /preparelegacyexchangepermissions-t, mely kiírta, hogy nincs RUS - aztán ettől megijedve csináltak egyet? Ekkor egy látszólag jó rendszert kapunk - de a domainprep elmaradása miatt az Exchange 2007 nem érzékeli a forest root RUS-t.

Kolléga nekiugrott, tesztrendszeren lemodellezte. Bingo. 2003-as domainprep nélkül pont ehhez a szituációhoz jutottunk. Tulajdonképpen meg is kaptuk a választ: tudjuk, mi okozta a jelenséget, tudjuk, hogy nem fogja zavarni a 2007-es Exchange-t - mi kell még?

Például az, hogy lehet-e javítani? Hiszen van tesztrendszerünk, miért ne néznénk meg?

Kolléga ráküldte - a már 2007-esre preparált tartományra - a 2003-as domainprep-et. Na, ott volt ám csikorgás, meg füstölés. Fogaskerekek sikítottak, recsegett a fém. Végül lement a domainprep - de egy bizarr rendszert kaptunk. Az adminisztrátorok például kapásból le lettek tiltva (deny) egy csomó Exchange objektumról. Ijesztő volt.
Ekkor jött a kisérlet második fele. Kolléga megküldte a tartományra újból a 2007-es preparációkat - és gyönyörűen kiegyenesedett minden.

De az éles rendszeren valószínűleg nem próbáljuk ki.

By JoeP július 9, 2009 at 20:24 Tags: exchange 2007 Posted in: exchange 2 Comments

Bizonytalan vagyok. Vagy nem?

Van egy CCR rendszerem, rengeteg adatbázissal. A hiba: az egyik adatbázis nem mountolható. A copy status: initalizing.
Vizuális vizsgálat: az adatbázis is, a logfájlok is szépen a helyükön vannak. Átnéztem a passzív node-ra… ott is.

Oké, mountoljuk fel. Nem megy, kiírja, hogy hiányzik neki egy logfájl. Nem mondom, hogy a popsimat vertem földhöz örömömben, de éreztem egy kis kellemes bizsergést. Itt van, végre élesben is ki lehet próbálni, mit ér a CCR. Az update-storagegroupcopy parancsot használtam már annyit a passzív node-on, hogy unom - ezzel szemben most van lehetőségem először alkalmazni a restore-storagegroupcopy parancsot az aktív node-on.

Azt írta ki, hogy ‘database was already marked as available for a mount, no action was taken‘. Azaz szerinte minden frankó, ez egy mountolható adatbázis.
Még egyszer megnéztem a passzív node-ot, megvolt az adatbázisról és a logfájlokról a replika. Oké. Fogtam, kitöröltem az aktív node-on az adatbázist.
Na, erre legyen bőr a képeden azt mondani, hogy mountolható!

Azt mondta.

Letöröltem az összes logfájlt is. Újabb restore. Megint azt mondta, hogy minden rendben, ez egy mountolható adatbázis. Miközben se adatbázis nem volt a partíción, se egy nyomoronc logfájl.
Irígyeltem az optimizmusát.

Futottam még egy bátortalan kört, hogyan lehetne _mindenképpen_ ráfuttatni a restore parancsot… de nem lehet. A -force kapcsoló sajnos nem ezt jelenti.
Törődjünk bele, ha az Exchange úgy gondolja, hogy minden rendben, akkor nincs visszaállítási lehetőséged. Még akkor sem, ha tokkal-vonóval hiányzik az egész adatbázis.

Nyilván a körbedolgozás működött. Elindítottam egy failovert, a korábbi passzív node-on ezután már felállt a problémás adatbázis, fel is lehetett mountolni. Ekkor a korábbi aktív node-on, mely most ugye már passzív lett, ki lehetett adni az update-storagegroupcopy parancsot, melynek van egy bűvös -deletexistingfiles kapcsolója. Na, ez képes gyökeresen elrendezni a terepet, csak a sávszélesség bírja.
Aztán jöhetett egy failback, és újra minden rendben.

By JoeP július 8, 2009 at 16:54 Tags: exchange 2007 Posted in: exchange 2 Comments

MI SE, még mindig

Tehát ott jártunk, hogy boldogan lejelentettük, miszerint itt van az összes cím, barátaim, feleim, levelezzetek.

Aztán jött az indignált újabb bejelentés. Oké, a cím ott van, de ha levelet küldenek neki, akkor másodpercen belül hibaüzenet jön vissza. A levelet nem lehet kiküldeni.

Nézzük, mi is van az NDR-ben? A következő felhasználó nem létezik: IMCEAEX_******@cegnev.hu.
Naná, hogy nem. Szépen is néznénk ki, ha létezne. Ja, hogy mi is ez az IMCEAEX***? Írtam már róla, olvasd el bátran. De ha nem akarod, rövid összefoglalás: ez egy kapszulázás. Ha valakinek nincsen SMTP címe, akkor az Exchange az egyéb címéből (x.400) szigorú szabályok alapján gyárt egy meglehetősen bonyolult smtp címet, majd ezzel küldi el a levelet. Aztán a válasznál meg - a szigorú szabályok ismeretében - kikapszulázza, azaz az IMCEAEX_****@cegnev.hu címből visszafejti az x.400 címet és oda küldi tovább a levelet.
Nos, ez mind szép, de hogyan kerül ez a sáros bakancs az asztalra? Itt a _címzett_ kapott IMCEAEX címet! Az Exchange 2007 ennyire optimista lenne? Azt mondja, nem lát a címzettnél SMTP címet, tehát abszolút vaktában hasra üt, legyárt egy IMCEAEX_****@cegnev.hu címet és bízik benne, hogy ha a túloldalon kikapszulázzák, akkor pont lesz olyan x.400-as cím? Bizony, így. Ne tudd meg, mennyi felháborodott levelet kaptam, hogy honnan meri az Exchange a @cegnev.hu tartományba küldeni a török, cseh, lengyel és még mittudoménmilyen leveleket? Hát ennyire hülyék vagyunk?

Ehe. Mosoly nyáladzó szájszéllel. Igen, reménytelenül debilek vagyunk.

Aztán elkezdtem kisérletezgetni… és a helyzet egyre durvább lett. Küldtem egy új levelet. Kiválasztottam a címzettet a Worldwide címlistából. Kiváncsiságból ránéztem a tualjdonságlapjára, gyönyörűen ott voltak a tulajdonságai, köztük a jó SMTP cím is. Oké. Elküldtem. Már jött is vissza az NDR, benne az IMCEAEX-es címmel.

Miaf?

Eljátszottam ugyanezt OWA-ból is. Tökéletes. A levél elment. Hát ezt meg hogyan? Elméletileg mindkét levél ugyanazt az útvonalat kell, hogy bejárja. Hát itt már semmi sem úgy működik, ahogyan működnie kellene?

Nézzük meg EMC-ből, látjuk-e az összes kontaktot. Feljött egy hibaüzenet. Lehet, hogy pont a mi emberünk sérült? A hibaüzenetre kattintva üres ablak jött elő. Hmm… lehet, hogy 40000 kontaktnál várni kell egy kicsit? Otthagytam éjszakára. Másnap reggel még mindig üres volt az ablak. Hmm. Ott van egy üzenet az alján, hogy a ‘ctrl+c’ kiteszi vágólapra a szöveget. Legyen. És tényleg, a notepad-ben már ott is volt a lista. Lehet, hogy valami idióta fehér betűkkel írta ki az ablakban fehér háttérre a listát? Már ezen sem lepődnék meg. Mindenesetre kellemetlen, a keresett cím nincs a hibások között. (Megjegyzem, itt is látok cuclizási lehetőséget: a hibás címek azért hibásak, mert space van a display név elején, illetve végén. Főbelőni. Mindet.)

Egy gyors, de bátortalan pillantás a GC adatbázisba. (Ugye tudod: ldp, a 3268-as porton.) Ott volt szépen a kontakt.

Eddig tartott a dal. Habár szívesen elmolyoltam volna még napokat a problémán, de mivel priority2-vel jelentették be, így ha nem akartam SLA-t sérteni, eszkalálnom kellett. PSS.

Hosszú beszélgetések. Lista, hogy miket küldjek el.
Aztán az ldp dump-ban a Sólyomszem Brigád kiszúrta, hogy a vizsgált kontaktnak üres a legacyExchangeDN értéke. (Konkrétan, nem szerepelt a dump-ban. Ugye tudjuk, hogy az ldp csak azokat a tulajdonságokat listázza, melyeknek van értéke.) Szinte hallani lehetett, ahogy a felfelé görgetett kőgolyó átbillent a csúcsponton.
- Ez baj - hívott vissza a mérnök.

Adtunk a kontaktnak. Mármint értéket.

Itt kellett megemelnem a kalapomat. Azt, hogy üres a legacyExchangeDN - különösen a korábban belinkelt cikk alapján - valószínűleg előbb-utóbb én is megtaláltam volna. De mit kellett volna beírnom? A kontaktnak volt vagy tíz x.500-as címe. Melyik legyen a legacyExchangeDN?

A mérnök segített: egyik sem. A legacyExchangeDN mindig a _helyi_ objektum helyzetére vonatkozik. Hiába tolják ki ugyanazt a kontaktot Amerikából Japánba, Grönlandra és Budapestre - a legacyExchangeDN értéke mindenhol más és más kell, hogy legyen. Míg az x.500 címe pedig annak a nyomát mutatja, hogy az objektum honnan hová lett migrálva.

Itt kezd a szituáció logikussá válni. Az elején, mondjuk, nem néztem volna ki belőle. Hogyan is működik a MIIS? Legyártja a távoli címtárban a kontakt objektumot. Ír neki legacyExchangeDN értéket? Hát, miért írna, amikor arra találták ki a helyi RUS-t? Majd amikor az végigmegy a recipienteken, akkor beírja a helyes értéket. (Hasonlóképpen békén hagyja a ShowInAddressBook értéket is. Ezt majd beállítják a helyiek.)

Ja, hogy az Exchange 2007-ben nincs RUS? Cucl.

Megoldási lehetőségek?
Elvégezni a RUS munkáját - azaz valamilyen jól definiált pontban mindenhová, ahol üres a legacyExchangeDN mező értéke, beírni a jó értéket. Yep. Mi lesz a jól definiált pont? Hát, nemrég derült ki, hogy az MIIS szinkronizáció után úgyis szkriptből kell frissítenünk a címlistákat. Akkor nincs is más hátra, mint ki kell bővíteni a szkriptünket.

Ja, a legszebbet meg nem is mondtam. Honnan tudod, hogy az adott környezetben mi lenne a kontakt helyes legacyExchangeDN értéke? Mindegy. Nem kell tudnod. Elég, ha felolvasod a kontakt objektum tulajdonságait, majd visszaírod. Ekkor a rendszer automatikusan beírja a legacyExchangeDN értéket.
Így: get-mailcontact “user-alias” | set-mailcontact.
Nyilván, tömeges módosításnál játszani kell a szkóppal (nem elég az alias), meg illenék rá is vizsgálni, hogy üres-e az érték vagy sem… dehát ez már mind iszonyúan részletkérdés.

By JoeP május 26, 2009 at 01:35 Tags: exchange 2007, miis Posted in: active directory, exchange 4 Comments

MI IS helyett MI SE

Irkáltam már arról az ügyfelünkről, akik kinyitották a szelencét és rájukborult 40000 kontakt. (Egyik, másik, harmadik.) Köszönik szépen, élnek még… de ez a rengeteg cím, melyet csak a dolgozók kb 5%-a használ, továbbra is komoly problémát okoz nekik.

Különösen úgy, hogy a közelmúltban álltak át Exchange 2007-re.

A legszebb ugyanis az volt, hogy elméletileg semmi problémát sem lenne szabad okoznia ennek a tömérdek címnek… de valahogy éreztem, hogy nem lesz ez olyan sima menet.

Akik nem akarják elolvasni a kilométer hosszúságú előzményeket, azoknak összefoglalom:

Trükkös módon a Global Address List mögött kicseréltem a keresőfeltételt, így csak a helyi címek kerültek bele. Ezt mindenki boldogan használta.
Létrehoztam egy Worldwide nevű listát, mely mögé odatettem az eredeti GAL keresőfeltételét. Ha az az 5% külföldre akarat írni, akkor címlistát váltott.

Még egy technikai előzmény. Az egyes nemzeti leányvállalatok között a címlista szinkronizáció úgy zajlik, hogy a tengerentúlon egy MIIS szerver felolvassa a felhasználók smtp és egyéb címeit, beledolgozza egy adatbázisba, majd mindenkinek a címtárába visszatolja a címeket, mail kontakt objektum formájában. Ez az a bizonyos negyvenezer, ki dalolva ment.

Az átállás után kezdtek rendeződni a sorok, kezdtek beérkezni az első rejtélyes panaszok.

(Nem tudom, ki hogy van vele, nekem ez a legnehezebben elviselhető időszak. Én általában beleadok apait-anyait, heteken, hónapokon keresztül megfeszítetten dolgozok, hogy időre tökéletesen működjön az új rendszer. Ez általában össze is jön, maximum a haragosaim száma növekszik. És amikor hátradőlnék, arcomon az elégedett mosoly, miszerint ‘használjátok, népeim, nektek csináltam…’ majd várnám a dicséreteket… azok valahogy nem jönnek. Egy csepp sem. Ezzel szemben beindulnak a hőbörgések. Hogy micsoda szar ez. Nem tudja ezt, meg azt. Ja, meg minden máshol van. És rossz! Majd jön, hogy mindezért ki is a felelős? A megrendelő persze elkezdi védeni a seggét, hogy ők sem így akarták. Eh.
Nyilván oktatással mindezt ki lehetne védeni, de az ügyfél helyett nem tudom tanítani a felhasználóit, különösen, hogy ezt rendszeresen nem rendelik meg. Így pont akkor, amikor a legfáradtabb vagyok, pont akkor, amikor az asszertív szóról maximum annyi jut eszembe, hogy biztosan egy perzsa hadvezér lehetett, szóval pont ekkor kellene türelmesen elmagyaráznom az embereknek, hogy nem szar, csak más.
Nem szokott sikerülni.
És a legdurvább az, hogy az esetek 1-2%-ában a bejelentőnek tényleg igaza van. Csak ez nem derül ki elsőre. Ilyenkor még elnézést is kell kérnem a végén.)

Nos, ilyen elnézéskérős esetekről lesz most szó.

Az első bejelentés az volt, hogy néhányan hiányolták a Worldwide listákról a külföldi ismerőseiket. (Ja, mondanom sem kell, külföldre leginkább a VIP-ek leveleznek. Ezt, mint türelmetlenségi faktort tessék figyelembe venni.) Megnéztem… és tényleg. Először felrémlett bennem a GAL és annak cefettül bonyolult szerver- illetve kliensoldali függőségei… de aztán lehiggadtam. A Worldwide lista sima Address List, azaz egy szűrő a Global Catalog adatbázisra.
De akkor hogyan lehet, hogy nem kerül bele egy kontakt? Ugyanis a címtárban megnéztem, a kontakt objektumot a MIIS rendesen beletojta az OU-ba.
Aztán később eszembe jutott, hogy valahol olvastam már ilyesmiről. Aztán még később eszembe jutott, hogy nem is olvastam, hanem írtam. Ebben a könyvben. (Igen, öregszem. Igen, én is leszek szenilisek.) Konkrétan arról van szó, hogy az Exchange 2007-ből kiműtötték a RUS-t. Ez a szolgáltatás nem csak a recipient policy-k betartásáért felelt, hanem minden kötegelt, asszimetrikus műveletért. (Mi is az, hogy asszimetrikus? Bekattintok valamiket, aztán csak pár óra múlva fut le egy kötegelt folyamat, mely érvényesíti a hatásokat.)
Tipikusan ilyen folyamat volt a címlisták tagságának érvényesítése is: a RUS megvizsgálta az egyes címlisták szűrőfeltételeit, majd minden recipient objektumra bejegyezte annak a címlistának a nevét, amelyiket a szűrőfeltétel eltalált. (Nem, nem röptében történt a szűrőfeltétel érvényesítése. Ezt nem igazán bírták volna a GC-k.)
Az Exchange 2007-ben ez megváltozott. Amikor létrehoztunk egy recipient objektumot, akkor egyből rá is esett minden, aminek kellett. Ha bármit piszkáltunk rajta, akkor szintén. De kötegelt folyamatok már nincsenek.
Látjátok már a kiskaput? Amikor a MIIS tojja be a kontaktot, akkor megkerüli a folyamatot. Létrejön egy új kontakt, de nem jegyződik be rá, hogy ő mind az ‘All Contact’, mind a Worldwide címlistának a tagja lesz. Nem is lesz. Jogos az ügyfél reklamációja.

Szerencsére a megoldás nem túl bonyolult: mivel a kontaktok éjjel jönnek, reggelre be kell időzíteni két EMS parancsot:

update-addresslist -identity “All Contact\”
update-addresslist -identity Worldwide

Ahogy mondani szokás, az ördög a részletekben lakik. A mocsok.

Időzítettél már be EMS parancsot Windows 2008 szerveren? Ráadásul olyat, melyhez Exchange Organization Administrator (Atyauristen) jogosultság kell?
Egy élmény.

Létrehozol egy kellő erősségű felhasználót, nem lejárós jelszóval.
Létrehozol egy könyvtárat ‘d:\scripts’ néven, úgy, hogy csak az Atyauristen nevű felhasználónak legyen benne írási joga.
Létrehozol egy frank-drebin.ps1 nevű fájlt, melybe beleírod a fenti két parancsot.
Elindítod a Task Scheduler konzolt és ugyanazzal a mozdulattal beveszel egy marék Seduxent.
Beidőzíted a taszkot, beállítod a felhasználót, tesztelsz. Természetesen nem fog történni semmi. Hogyan is gondoltad, hogy egy Exchange szerver fel fogja ismerni az Exchange Management Shell (ps1) parancsát?
Indul a vajákolás. Először is szeretnéd látni, mit is ír ki futás helyett a szkript. Ehhez volt régebben a /i (interactive) kapcsoló. A grafikus felületen nyoma sincs. Parancssorban? A-ha. /IT lett belőle. De nem is ez a lényeg. Hanem az a megjegyzés, hogy ilyesmi csak akkor van, ha a felhasználó ténylegesen be is van jelentkezve. Eszedbe jut, hogy volt egy rádiógomb, miszerint
- Run only when user is logged on
- Run whether user is logged on or not
Nos, bármilyen furcsa is, az első jelenti az interaktív futást, a második a nem interaktívat. Tudnak fogalmazni a fiúk, szó se róla.
Most már látod, hogy egyszerűen az operációs rendszer nem tud mit kezdeni a .ps1 fájlokkal. Megkíméllek a rengeteg utánajárástól, a következőket kell beírnod:
- A program/script mezőbe: c:\windows\system32\windowspowershell\v1.0\powershell.exe
- Az add argument mezőbe: -psconsolefile “c:\exchsrvr\bin\exshell.psc1″ -command “. ‘d:\script\frank-drebin.ps1′”
Feltéve, hogy az Exchange alkalmazást a C:\exchsrvr könyvtárba telepítetted.
Azt hiszed, mi, hogy működik? Hát nem. Megjelent az eddig még csak barlangjában szunyókáló UAC. Nem fog lefutni a szkripted, mert hiába vagy maga az Atyauristen, ha nem Atyauristen módban indítottad. Na jó, de hol lehet? A fene tudja. Nézzük meg a runas parancsot… semmi. Csak a jó öreg /savecred van, de az már kilenc évvel ezelőtt is maximum vicc volt. (Jelszót beleírni a parancsba… egy mindenható felhasználónál. Aha.) Na jó, nem csigázlak, ezt a csekkbokszot kell bebillentened: ‘Run with highest privileges’. Biztos ugyanaz a mókus fogalmazta, aki az előző objektumot. Még az is lehet, hogy ideológiát is gyártott hozzá: security through obscurity, azaz hülye ember ne tudja már beállítani. Mintha ez a fajta védekezés valaha is ért volna akár egy koszvadt hajítófát is.

És nagyjából ennyi. A szkriptünk minden reggel lefut, a nevek pedig megjelentek a Worldwide címlistában.

Csak éppen levelet nem lehet küldeni nekik.

De ez már majd a következő írás témája lesz.

By JoeP május 25, 2009 at 11:09 Tags: exchange 2007, miis Posted in: active directory, exchange 6 Comments

« Older Entries

március 2010
H	K	S	C	P	S	V
« jan
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30	31

Motto:

Archívum

Blogroll

Kategóriák

Utolsó megjegyzések

Meta

Cimkék