Category: 2010

Exchange 2010 – A Practical Approach

2009-12-05 / / 0 Comments

Ú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 –

Lehet egy node-dal több?

2009-11-25 / / 1 Comment

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?

Az IPv6 és az Exchange 2010 románca

2009-11-23 / / 5 Comments

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.

Tapétamániákusok, figyelem!

2009-11-19 / / 2 Comments

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.

Suta konzol visszalő

2009-11-01 / / 0 Comments

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.

OWA

2009-10-31 / / 0 Comments

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

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.

Közepes bizalom

2009-10-30 / / 0 Comments

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.

Die PST, die!

2009-10-29 / / 0 Comments

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.

MoMT

2009-10-28 / / 3 Comments

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.

DAG a kkv/soho szegmensnek is

2009-10-27 / / 3 Comments

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.

Egy kis esti adatbázis-kezelés

2009-10-27 / / 0 Comments

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?

Magas rendelkezésreállás

2009-10-26 / / 2 Comments

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.

DAG

2009-10-25 / / 0 Comments

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

Management Role Assignment Policy

2009-10-24 / / 0 Comments

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.

Discovery Search

2009-10-23 / / 2 Comments

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.

Management Role Group

2009-10-22 / / 1 Comment

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.

RBAC

2009-10-21 / / 1 Comment

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.

Powershell ISE

2009-10-20 / / 5 Comments

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.

Ha internet van, minden van

2009-10-15 / / 7 Comments

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.