Espéegy a porcelánboltban

Arról, hogy kijött az Exchange2010 SP1, szándékosan nem írtam semmit. Aki nem tudja meg tizenhét forrásból egy napon belül, az vagy traktorbelsőben él, vagy nem is érdekli a dolog. Azt is leírták sokan, sok helyen, hogy mi újdonságokat hozott a rendszerbe.

Foglalkozzunk most azzal, hogy mi mindent nyírt ki? Nem szándékosan persze, de hát így sikerült.

1.
Henrik Walther írt rögtön az elején egy cikket arról, hogy milyen meglepetésekre készüljünk fel.

2.
Aztán nem sokkal később az Exchange blogon jelent meg egy írás arról, hogy milyen problémák derültek ki nem sokkal az SP1 kibocsátása után.

3.
Végül Yuri Diogenes tett ki a blogjára egy cikket arról, hogy ne, hangsúlyozom, ne tegyél olyat, hogy a TMG E-mail Protection rendszeredben lévő Exchange 2010 Edge szerverre ráhúzod az SP1-et. Amennyiben mégis ilyet tettél volna, akkor ne, hangsúlyozom, ne nyúlj semmihez, mert csak tovább rontod a helyzetet. Várd meg a hotfixet, a fiúk a bányában ezerrel dolgoznak. (Hasonló tanáccsal szolgál a hivatalos ISA/TMG blog is.)

By JoeP szeptember 3, 2010 at 22:58  Tags:   Posted in: ISA, exchange  One Comment

ClamAgent & ClamSink

Amiről már rég írnom kellett volna.

Lassan másfél hónapja tetszhalott állapotából felélesztettem az Exchange-re szabott ingyenes vírusirtómat. Az új darab ugyan csak build számban tér el a régitől, mégis nagy lépés előre.

- ClamD használata. A korábbi verzió a ClamWin-t használta, mint motort. Ez azt jelentette, hogy minden egyes beérkezett csatolmányt lementett a temp könyvtárba, majd elindította rá a clamwin-t. A clamwin felolvasta a saját adatbázisát, majd a tempből a fájlt. Ez a műveletsor, mint látható igencsak disk intenzív ügy. A jelenlegi verzió ezzel szemben a csatolmányt egy TCP csatornán keresztül áttolja a ClamD-nek ahol megtörténik a vírus ellenőrzés. Ráadásul a ClamD csak időnként olvassa fel az adatbázist.

- MSI telepítő. A korábbi verzió kézi telepítése sem volt egyszerű. Ennél a verziónál ez már mintegy tizenöt lépés lenne a kézi telepítés ezért inkább készítettem egy msi-t ami tartalmazza a clamd-t a szükséges futtatókörnyezeteket, beállításokat.

- Pici hibajavítás. Az Exchange 2007 verzió 2010 alatt futtatva egy .NET osztály nevét írja a logba az értéke helyett. Egyébként az Exchange 2007 alatt is produkálja ugyanezt a hibát SP3-tól.

- Támogatás az Exchange 2010-hez. Lényegében nincs sok különbség a 2007-es és a 2010 verzió között, csak a 3.5-ös Frameworkre fordítottam és a 2010 transport dll-jeit használtam. A lényegi különbség a telepítő, ugyanis a 2007 és a 2010 másképp intézi a powershell plug-in-jeit így másképp kell telepíteni.

Folytatás következik (vannak még ötleteim). A cucc letölthető a clamagent.org-ról némi regisztráció után

By SUF augusztus 31, 2010 at 09:29  Tags: ,   Posted in: exchange  3 Comments

Javítsuk meg a semmit

Linux tűzfalat használok (jujj, de ez egy Exchange blog). Évek óta bosszant az Exchange Server Event Logban ez a bejegyzés.

Ha van egy mobil eszközünk, ami az ActiveSync for Exchange-el direct push módban beszélget akkor a kliens nyit egy TCP kapcsolatot a szerver felé, a szerver pedig jó sokáig hagyja várakozni a klienst. Némelyik tűzfal ebbe beleun és lekapcsolja a villanyt idő előtt. Ha ez megtörténik, akkor pakolja a fenti kedves üzenetet az Exchange a logba.

Két lehetőségünk van:

1. Megmondjuk az Exchange-nek, hogy ne várjon addig. Ezt a Program Files\Microsoft\Exchange Server\ClientAccess\Sync\web.config fájlban található heartbeat bejegyzések módosításával érhetjük el. Pontosabban ezekről beszélek: MinHeartbeatInterval, MaxHeartbeatInterval, HeartbeatSampleSize, HeartbeatAlertThreshold

2. Csökkenteni a heartbeat értékeket mégsem célravezető. Inkább a csomagok útjában álló tűzfallal kéne tudatni, hogy várjon vagy 30 percet (ez a Microsoft ajánlás)

Térjünk vissza a linuxhoz. A linuxon az ide tartozó bejegyzések a /proc/sys/net/ipv4 alatt találhatóak. Próbáltam kideríteni, hogy melyekhez kellene hozzányúlni. Végül is találtam erre vonatkozóan egy cikket.

Puff neki, ezek szerint a linux vonatkozó timeout-ja három nap (ennyit a 30 perces ajánlásról). Végig is néztem a sajátom beállításait, és valóban.

Akkor ki a tettes? Láthatóan mostmár senki. Július 5.-e óta megszűntek a bejegyzések. Valaki észbekaphatott valamelyik a mobilok és a tűzfal közötti szolgáltatónál és állítottak valamit.

Probléma lezárva.

By SUF augusztus 31, 2010 at 06:28  Tags: ,   Posted in: exchange  6 Comments

Lookeen

Ha téged is olyan munkahellyel vert meg a sors, ahol még mindig 150/300 MB postafióklimitek vannak, kéthavonkénti automatikus levéltörléssel, akkor tudom ajánlani a címben megnevezett programot. Ez ugyanis képes arra, hogy egybeindexeli a postafiókodat a szükségképpen összegyűlő 10-12 lokális pst-vel, majd egyszerre tud keresni mindenhol. Az indexelés a háttérben fut, a keresés pedig - értelemszerűen - gyors.

Egyébként volt már ilyen program, Lookout-nak hívták és írtam is már róla. De azt már az Outlook 2007-hez is csak hekkelés után lehetett feltenni (jelzem, Windows7 alatt már így sem működik, de lehet, hogy inkább egy Office SP vágja tönkre), azóta pedig gyakorlatilag eltűnt a térképről. A Lookeen fejlesztői nem titkolják, hogy ezt az űrt szeretnék betölteni: már a program neve is utal az elődre, a kinézete, a kezelői felülete pedig teljesen megegyezik vele. Egy, nem is apró különbség azért van, a Lookeen már fizetős. De ha vesztél már el tök azonos nevű, különböző pst-kben lévő folderekben, akkor legalábbis elgondolkodtató ez a 35 euró. (Ja, tud desktop search-öt is, de azt ma már mindenhol ingyen vágják az ember után.)

By JoeP augusztus 13, 2010 at 07:49  Tags:   Posted in: exchange, általános  2 Comments

Egy nagyon hasznos táblázat

Ma már a legkisebb cégeknél is jelen van az az igény, hogy a levelezést és a hozzá kapcsolódó információkat akár az argentín pampákon lovagolva is egyből elérjük. Nem is lenne ezzel különösebb baj, ha még ugyanezen legkisebb cégeknél is nem burjánozna ezerféle kütyü. Ember legyen a talpán, aki képes átlátni, hogy melyiken milyen operációs rendszer fut és melyik milyen módon, milyen szinten éri el a levelezőszervert.

Ezért készült el ez a táblázat. (Értelemszerűen csak az Activesync alapú hozzáféréseket tartalmazza.)

By JoeP július 29, 2010 at 08:11  Tags:   Posted in: exchange  No Comments

Ki mennyire autoritatív?

Érdekes jelenségbe futottam bele a napokban. Különböző tartományok felé DNS lekérdezéseket kellett volna futtatnom - és nem igazán értettem az eredményeket.

De ehhez egy kis ismétlés.

Anélkül, hogy túlzottan belemennék a DNS részleteibe: tudjuk, hogy vannap primary zónák, vannak AD integrált zónák… de ezek most hidegen hagynak minket.
A finomságok a secondary és a stub zónáknál kezdődnek, illetve bejönnek a képbe a zónadelegálások is.

Secondary zóna:
A primary (elsődleges) zónát tükrözi le egy másik DNS szerverre, gyakorlatilag teljes egészében.

Stub zóna:
Szintén tükröz, de nem az egész zónát, hanem csak az A, NS és SRV rekordokat szedi le.

Zónadelegálás:
Megadjuk, hogy egy hozzánk tartozó zóna alzónájának ki a DNS szervere. Ez tetszőleges külsős DNS szerver is lehet.

És akkor a konkrét jelenség. Nemzetközi környezet, tartomány tartomány hátán. Szeretném megtudni az egyes tartományok MX rekordjait. Aztán nem mindegyikét kapom meg. Viszonylag hamar kiderült, hogy ahol stub zóna van, ott megkapom, ahol meg zónadelegálás, ott nem.
Mondanom sem kell, a névfeloldás mindegyik esetben tökéletesen megy - de az MX rekord beszerzése nem egy egyszerű kérés.

nslookup
ls -t MX kerdeses.domain

Stub zóna esetén vagy megkapom a kérdéses MX rekordot, vagy jogosultsági hiányosságból kifolyólag elutasítanak. Delegált zóna esetén viszont azt kapom vissza, hogy a zóna ismeretlen. Pedig - mint írtam is - a névfeloldás remekül megy, azaz dehogyis ismeretlen a zóna.

Keresgélés a neten. Azt írja a DNS hibakereső doksi, hogy ha nem autoritatív DNS szervert kérdezek, akkor jöhet ilyen üzenet. Ellenteszt: delegált zónánál kiegészítettem a lekérdezést:

nslookup
server a.zona.eredeti.dns.szervere.ahova.a.delegacio.mutat
ls -t MX kerdeses.domain

Láss csodát, egyből működött.

Ezzel akár már elégedett is lehetnék, de nem hagyott nyugodni a kisördög. Most akkor mi van a stub zónával? Gyors teszt: a stub zóna is non-authoritative választ ad, tetszőleges lekérdezésre. Azaz olyan rekord esetén is, mely egyébként már letükröződött a helyi DNS szerverre. Akkor meg miért működik az MX lekérdezés? Ha mindkét módszernél egyformán nem-autoritatív a kérdezett helyi szerver, akkor miért működik az MX lekérés a stub zónánál és miért nem a delegálásnál?
Nyilván azért, mert a stub egy hajszállal autoritatívabb, mint a delegálás.

By JoeP július 26, 2010 at 09:52  Tags:   Posted in: Windows server  No Comments

Javítócsomagok

Lassan el lehet kezdeni éles környezetbe is telepítgetni. ;))

TMG 2010 SP1

És aki esetleg lemaradt volna róla:

Exchange 2007 SP3

By JoeP június 24, 2010 at 06:27  Tags: ,   Posted in: ISA, exchange  3 Comments

Kis szar ablak

Hosszú szünet után visszatérés morgással.

Árulja már el nekem valaki fejlesztő, hogy mennyivel kerül többe egy olyan ablak, amelyiken vannak méretező kontrollok? Egész egyszerűen nem fér a fejembe, hogy a mai napig sokszor olyan kis szar ablakokat használunk a windows-ban, melyeket képtelenség felnagyítani.

Ma például megint egy levél útvonalát kellett volna feltérképeznem. Outlook, levél, options - és feljött az a hangyaf@sznyi ablak. Aztán nesze, görgessél jobbra-balra, fel-alá, próbálj összerakni egy ilyen bonyolult láncolatot úgy, hogy csak egy bélyegnyi ablakot kapsz rá.

De meggyőződésem, hogy a biztonsági jogosultságok állítgatása is azért kínai a legtöbb informatikusnak, mert kap egy ilyen egérmozi méretű ablakot, aztán turkáljon benne a 40-50 elemi jogosultság között. A jó ég áldja meg, mire a lista végére érek, már rég elfelejtettem, mi volt az elején, egyben meg ugye nem lehet látni a pici ablak miatt. Azon a kurva nagy felbontású képernyőn.

Ez egy akkora ergonómiai baromság, hogy nincs is megfelelő szó a minősítésére. És az MS oldalán szemmel láthatóan úgy gondolják, hogy ez így nagyon jó, hiszen még a Windows7-ben is ugyanolyan pici, méretezhetetlen ablakok vannak, mint az NT4-ben. Pedig biztos nem én vagyok az első, aki hőbörög.

By JoeP június 16, 2010 at 07:45   Posted in: általános  7 Comments

Tanujj tinó

Nincs ám elfelejtve ez a blog, remek ötleteim vannak - csak idő nincs hozzá.(Ha valaki tud nagy tételben olcsón, vevő vagyok rá.)

Most is csak egy gyors hivatkozás lesz, mondhatni a delicious helyett ide jegyzem fel ezt a remek linket. Yuri Diogenes egy postban összefoglalta, milyen linkeken jut információkhoz az, aki el szeretne mélyülni a TMG rejtelmeiben.
Csak annyit tudok hozzátenni, hogy hajrá, megéri.

By JoeP május 26, 2010 at 19:01  Tags:   Posted in: ISA  No Comments

Cache vagy nem Cache, ez itt a kérdés

Van egy kis bajom az Exchange szerverünk sebességével.

Az egyik gyanúsítottam, hogy néhány kliens nem Cached Mode-ban használja az Outlookot és ez terheli a szervert. Át kéne őket állítani.

Itt jön a kérdés, hogy melyeket. Hogyan tudjuk kideríteni, hogy mely klienseink mennek Online módban?

Így:

Get-LogonStatistics | Where-Object { $_.ClientMode -eq “Classic” } | ft -Property UserName,ClientMode

By SUF április 21, 2010 at 11:42  Tags: ,   Posted in: exchange  No Comments

Technet Wiki

Kicsit még béta, de nem tűnik rossz kezdeményezésnek. Wiki, azaz közösségi jellegű tartalomszerkesztés - Technet, azaz Microsoft technológiák.

Az Exchange részt megnéztem, sok cikk nincs kint, de azok rendesen hézagpótlók.

- link -

By JoeP április 16, 2010 at 10:36  Tags:   Posted in: máshol  No Comments

Könyvek, csak jönnek

Elnézést a keresztpostázásért, de gondolnom kell azokra is, akik csak a szakmai blogot olvassák.

Kapaszkodj, mert nem lesz egyszerű.

Amikor lezártam a TCP/IP Alapok könyvet, még volt bennem egy jó adag hiányérzet. Annyi virág nyílik az alkalmazás rétegben. Oké, hogy a DHCP és a DNS példaként be lett mutatva, de egy csomó izgalmas téma még kibontatlan maradt.

Kapóra jött, hogy tervben volt egy TMG könyv. Összedugtuk a fejünket és azt találtuk ki, hogy lesz egy közös könyv: én írok a webes protokollokról, ezek biztonságosabbá tételéről, GT pedig a TMG-ről.

Aztán összeállt az anyag első fele. Az én blokkom három részből állt: jó 50 oldalon összefoglaltam a TCP/IP Alapok könyv lényegét, a maradék 170 pedig felszántotta - jó mélyre eresztett ekevassal - a webes protokollok témát (HTTP, FTP, SMTP), beleértve a biztonsági megfontolásokat (TLS, SSH, IPSec, VPN, RADIUS) is.
Jó erős anyag lett. Nézegettük. Nemcsak, hogy megállt a saját lábán, de még a kávét is ágyba hozta. Úgy döntöttünk, hogy inkább önálló kötetként adjuk ki, méghozzá hozzácsapva a TCP/IP könyvhöz. Mert utólag végigolvasva, sokkal inkább ahhoz passzol, mint a TMG-hez. (Mely blokk szintén bőven erős lesz ahhoz, hogy önállóan is megálljon.)

Most jön a kavarás része:

  • A teljes kéziratból kiemeltem azokat a részeket, melyeknek inkább a TCP/IP Alapokban volt a helye. Ezekkel szépen bővült a könyv.
  • Örömteli hír, hogy rengeteg visszajelzés érkezett a korábbi (1.1) könyvhöz. Ezekből lettek levelezések, tisztázások, melyek következtében egyrészt bővült az anyag, másrészt világosabb lett. Itt kell beismernem, hogy volt olyan terület az 1.1-ben (TCP folyamszabályozás), ahol alapvetően rosszul értelmeztem a koncepciót. Egy kedves olvasó helyretette a folyamatokat a fejemben, én pedig átírtam az egész fejezetet. (Részletes lista a könyv végén.)

Emiatt a két pont miatt váltott a könyv fő verziószámot. mostantól 2.0.

  • A kéziratból leválasztottam a bevezető fejezetet. Ebből a műtét során egy 42 oldalas füzet lett. Ez az anyag a keresztségben a ‘TCP/IP - 1 óra alatt’ nevet kapta. Bárkinek, akit elrémisztene a 350 oldalnyi bitekkel tömött szöveg, de azért szeretne egy átfogó képet kapni a TCP/IP működéséről, bátran tudom ajánlani.
  • A maradék 161 oldal pedig önálló könyvként jelent meg, pontosabban a TCP/IP Alapok könyv második köteteként.

Lássuk a végeredményt:

Fontos látni, hogy az utolsó két kötet képez egy egységet, mely nem kompatibilis az 1.1 verzióval. Ha érdekel a téma, akkor nyugodtan dobd ki a korábbi verziót és töltsd le ezt a kettőt. (És elnézést azoktól, akik kinyomtatták. Megnyugtatásként közlöm, hogy ekkora strukturális átalakítást már nem tervezünk, maximum hibajavítások lesznek még.)

Ezzel párhuzamosan nyilván bővült a letölthető könyvek listája is, immár 8 könyvre mutatnak linkek. (Kihasználom a lehetőséget és szólok, hogy az első kettőt mostanában ne töltsd le, ezerrel írom, illetve szerkesztem át az anyagot.)

By JoeP április 12, 2010 at 13:33  Tags:   Posted in: általános  No Comments

Exchange 2010 SP1

Tegnap óta ettől hangos az Exchange blogoszféra, gondoltam, én sem maradok le.

Nem, az SP1 még nem jött ki. Várhatóan hamarosan, de legalábbis idén még ki fog jönni. (És akkor elkezdhetnek végre a magyar döntéshozók is gondolkozni az Exchange 2010 bevezetéseken.)

Most az első publikus infók jelentek meg arról, mi minden lesz benne.

Röviden összefoglalva:

  • A triviális rész: tömérdek patch, beleértve a korábbi Rollup csomagok tartalmát is.
  • A Personal Archive postafiókok külön adatbázisba pakolhatók. Innentől tényleg lesz értelme a koncepciónak. (Eddig ugyanis nem sok volt.)
  • PST import. A szanaszét burjánzó PST-ket akár a felhasználó is képes lesz betolni a személyes archív postafiókjába.
  • Még mindig a régi levelek kezelése: bejött egy segédprogram a Retention Policy tag-ek létrehozásához.
  • Kicsit tuningoltak a discovery funkción is: egyrészt bejött egy search preview lehetőség, másrészt kiszűrték a keresési eredményekből a duplikátumokat. (Emlékszünk, a discovery az az eufemizált neve a full adatbázisos keresésnek.)
  • Reszeltek egy csomót az OWA-n is. Sokkal gyorsabb lett, kiszedték belőle a lassú, bosszantó folyamatokat. Másrészt a felhasználói élményen is javítottak, át lett szabva a kezelői felület. (Hogy a netbook felhasználók is örüljenek.) Ja, és lesznek OWA skinek is.
  • IRM integráció OWA-ba, Activesync-be.
  • Egy csomó új, eddig csak EMS-ből elérhető taszk kapott grafikus felületet az EMC-ben.

Akit bővebben is érdekelnek a részletek:

By JoeP április 8, 2010 at 13:18  Tags:   Posted in: exchange  No Comments

Mythbuster

Ezt írtam korábban.

Utána egy csajszi Mythbuster stílusban verte a fejünkbe, hogy miket kell mondani, hogyha az Exchange kellemetlen tulajdonságairól faggatnak. Háát… a backup részt továbbra is csak kerülgették, mint macska a forró kását.

Nos, a varázsnak vége, a mítoszrombolás nyilvános lett. Igaz, itt csak éppenhogy érintve (nálunk másfél órás előadás volt), de a lényeg benne van. Pontosabban, a lényeg itt van: Large Mailbox Vision whitepaper.

By JoeP március 29, 2010 at 21:48  Tags:   Posted in: exchange  2 Comments

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:   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:   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:   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.

Nagyítás

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.

Nagyítás

Nagyítás

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.

Nagyítás

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.

Nagyítás

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.

Nagyítás

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.

Nagyítás

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.

Nagyítás

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.

Nagyítás

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.

Nagyítás

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:   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.

Nagyítás

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

Nagyítás

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.

Nagyítás

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.

Nagyítás

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.

Nagyítás

É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:   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: ,   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: ,   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.

  1. 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.
  2. 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.
  3. 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é.
  4. 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:   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:   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:   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.

Nagyítás

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.

Nagyítás

Nagyítás

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:   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:   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.

Nagyítás

Nagyítás

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ó

Nagyítás

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

Nagyítás

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. :-P

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:   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.

Nagyítás

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:   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).

Nagyítás

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.

Nagyítás

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

Nagyítás

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

Nagyítás

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:   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.

Nagyítás

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.

Nagyítás

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:   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:   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:   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ó.

Nagyítás

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.

Nagyítás

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.

Nagyítás

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.

Nagyítás

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.

Nagyítás

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:   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:   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.

Nagyítás

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.

Nagyítás

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

Nagyítás

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.

Nagyítás

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.

Nagyítás

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:   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.

Nagyítás

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.

Nagyítás

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.

Nagyítás

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.

Nagyítás

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?

Nagyítás

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.

Nagyítás

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

Nagyítás

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.

Nagyítás

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.

Nagyítás

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:   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*

Nagyítás

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

Nagyítás

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.

Nagyítás

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.

Nagyítás

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

Nagyítás

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

Nagyítás

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.

Nagyítás

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:   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:

  1. 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.
  2. 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

Nagyítás

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

Nagyítás

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:   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?

Nagyítás

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.

Nagyítás

É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:   Posted in: exchange  5 Comments

Még mindig a telepítés

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

Nagyítás

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:   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:   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ő.

Nagyítás

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:   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.

Nagyítás

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.)

Nagyítás

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:   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:   Posted in: máshol  No Comments