MonthJuly 2008

MAPI profil direkt elérése Vista alatt

Ezt először nem hittem el. De tényleg nincs.
Akinek Vistája van és Outlook klienst használ, ne is keresse a Control Panelen belül a Mail ikont. Nincs. Megszűnt.
Pedig nagyon hasznos dolog volt. Nem kellett elindítanod magát az Outlook-ot a MAPI profilok menedzseléséhez. Sőt, olvastam olyanról is, hogy valakinek valami rejtélyes hiba miatt a profil kezelése Outlook alól egyáltalán nem működött – csak a Control Panelből.

Mit lehet ilyenkor tenni?

Program Files\Microsoft Office\Office12, azon belül pedig duplaklatty az MLCFG32.CPL fájlon.

Kínos.

Névtelen nulla

Habár a címkonvencióból annyira már nem látszik, de ez az írás az ún. ‘félresiklott projekt’ sorozat része. Akit érdekel a történet többi része is, itt, alul, a ‘félresiklott’ tag-re kattintva tudja elérni azokat.

Akkor csapjunk bele.

A világ legfeleslegesebb nyomógombjai – azaz az UI designer csapat újra száguld.

Leszedném a következő Exchange 2000 szervert. El is indult a telepítő, állítgatja le a szolgáltatásokat. Ekkor jutott eszembe, hogy sokkal biztosabb lenne a művelet, ha előtte én állítgatnám le kézzel a szervízeket, manuálba tenném mindet, újraindítanám a gépet – és utána esnék csak neki a leszedésnek. Gond egy szál se, aktív az ablakon a Cancel gomb, lényegi művelet meg még nem történt. Rákattintottam. Erre feljött egy ablak, hogy “Mit képzelsz? Csak úgy össze-vissza kattintgatsz? Itt fontos dolgok történnek, _nem lehet_ leállítani!”
Alatta két nyomógomb: Igen, Nem. Mindkettőre továbbmegy a remove. (Direkt kipróbáltam később, egy másik szervernél.)

Az anonymous, mint korlátozó lehetőség

Minden rendben. Pontosabban majdnem minden rendben.
A központi site-ról ugyanis nem látszódnak a vidéki telephelyen lévők free/busy információi, amennyiben Outlook 2007-et használunk – azaz nem lehet velük megbeszélést szervezni az egyre terjedő új céges sztenderd munkaállomásokól. Korábbi kliensekről megy, de hát tudjuk, az Public Folder alapú. A 2007-es viszont webes szolgáltatásokon keresztül működik: először SCP, aztán Autodiscovery, aztán Availability szolgáltatások. (Lsd. részletesen ezt a cikket .)
Nem túlzok, hetekig gyököltem rajta. No persze, nem 100%-ban ezen, de ha volt egy kis időm, törtem a fejem. Nézegettem a pfdavadminnal, mi is a helyzet. Ez első ránézésre hülyeség, hiszen ez a rész működik… de kíváncsi voltam, hogy rendben van-e a MAPI hozzáférés a központi site CAS szervere és a vidéki site CAS/MBX/HTR szervere között. (Az Availability szolgáltatás mögött megbújó EWS ugyanúgy MAPI-val dolgozik, mint a pfdavadmin.) És hopp! Rögtön egy hiba:

Could not expand https://utvonal/public%20folders/ : name cannot begin with the ‘0′ character, hexadecimal value 0×30. Line 1, position 416′

Hah! Rávetődtem.
Azt írták, hogy akkor van ilyen, ha nincs feltelepítve a .Net 1.1. Dehát, nem is mondta senki, hogy kell. .Net 2.0, az igen, azt tudom. Már majdnem fel is raktam, amikor elolvastam Jim McBee írását a témáról.

If you get this message, do NOT install the v1.1 Framework on an existing Exchange 2007 server. You run the risk of resetting some of the v2.0 Framework settings and, thus, breaking Exchange Server 2007! If you want to run PFDAVADMIN from the console of an Exchange 2007 server, you need to install the v1.1 .NET Framework prior to building Exchange.

Kár érte. De most már legalább tudjuk, hogy a pfdavadmint _nem_ futtatjuk szerverről, csak munkaállomásról. Mert nem lehet.

Mihez nyúljak? Mármint magamon kívül. Nézzük meg azt a test-outlookwebservices parancsot!
Döbbenet.
A kimenetben az volt, hogy a távoli site CAS Exchange szerverén az EWS szolgáltatás 403-as hibával dob el. Ez ugye az Ekszessz Dániel. Viszont emellett _ugyanez_ a szolgáltatás tökéletesen működik _ugyanarra_ a felhasználóra az OAB tesztben.
Meg kell bolondulni. Ilyen nincs. Ha access denied egy webes szolgáltatás – egész konkrétan ugyanaz az Exchange.asmx progi, akkor igenis legyen következetes. Milyen már, hogy egyszer engedi, egyszer meg nem?

További guglizás. Hoppá .
A figurának pont ugyanaz a betegsége, mint nekem. A megoldás?

it was as simple as change to reject client certificates in IIS Directory security, edit, configuration.

A jó szószátyár nénikédet. Természetesen az IIS adminban _nincs_ ilyen ‘reject client certificates’ menü vagy nyomógomb. De hogyan lehetne másképpen? Metabase turka .
Hú, de ronda. Meg a többiek is: egy , kettő , három , négy .
Nem tetszik. Egyelőre mennek talonba.

Kulimunka következett. Hihetetlen mennyiségű jogosultságot néztem át. (Mert szimatra azért éreztem, hogy itt valami jogosultsági balhé van. Hiszen a 403, az azért elég konkrét utalás.) Felhasználókon, adatbázisokon, mi öröklődik, hol vannak esetleg elvágások, mi van a gyári csoportokkal, /domainprep újra, ki melyik csoportban mit is kap végül, mi van beállítgatva kliens oldalról… jojózott a szemem.
Innen külön üdvözlöm azt a GUI tervező zsenit, aki a jogosultságokat részletező ablakot _nem méretezhetőnek_ álmodta meg, még valamikor 1995 táján, az NT3.51-ben. Amikor szerveren a 640*480 felbontás már vad ollézást váltott ki az adminokból. Aztán külön csókoltatom azt a másik barmot, aki képes volt ezt az idiotizmust változtatás nélkül továbbvinni az újabb meg újabb termékekben.
Itt vagyok, 1600*1200-as monitorom van – és nézegethetek egy bélyeg méretű ablakot, ronggyá szkrollozva a csuklómat.
De itt sem találtam semmi használható nyomot.

Aztán kész. Eddig tartott a hajat vadul lobogtató vágta. Bár még agyalhattam volna a problémán, de vannak más ügyfeleink, vannak más munkáink, várnak az új szopások. Erre már nincs idő.
Eszkaláltunk a Microsoft felé.
Összeállítottam egy derék esetleírást (úgyis kellett dokumentálnom is). A támogató mérnök rögtön kért is pár napot, hogy átolvasgathassa.

Aztán közölte, hogy a test-outlookservices nem mérvadó, felejtsük el. Ez ugyanis szeret localhoston próbálkozni, de ott meg pofán vágják. (DisableLoopbackCheck: itt megtalálod a részleteket.) De jelen esetben ez irreveláns volt, mi 403-as errort kaptunk, nem 401-est.

Nyomoztunk tovább, a szokásos módon: a support irányított, én meg toltam az egeret. Aztán a srác egy helyen felsikított. (Na, jó, többször is, de ez hozta meg a megoldást.)
– Miért van engedélyezve az EWS webszolgáltatáson az anonymous access?
– Hát, izé. A fene tudja. Azt se tudom, mi volt a default. Még az is lehet, hogy fentről örökölte, hiszen egyszer már volt egy jogosultság reset. Lehet, hogy a sokadik kisérletezésnél vagy én vagy a helyi admin kattintottuk be, hátha ettől megjavul a Free/Busy terjesztés.
– Vegyük ki.
– Örömmel… de nem az a bajunk most, hogy túl szigorú az autentikáció? Ha elveszem az anonymoust, akkor csak tovább szigorítok.
– Nem. Ha az van beállítva, hogy anonymous, akkor _nem kér autentikációt_. Viszont később, amikor az EWS a kérelmező nevében fordul a Mailbox szerveren megcélzott postafiókhoz, pofára fog esni, mert mivel nem autentikálta a kérelmezőt, így a nagy büdös semmi nevében szeretne hozzáférni a mailboxhoz. Persze, hogy elhajtják.
– Azannya.

Tehát, értelmezzük. Ha megadom, hogy anonymous, azaz bárki jöhet, akkor azzal tulajdonképpen lehetetlen feladat elé állítottam az EWS-t… hiszen hiába van mellette az is bepippantva, hogy ‘integrated’, az anonymous miatt nem fog autentikációt kérni. És ebben a pillanatben az EWS még nem tudja, hogy én most az OAB-ot kértem el (amelyhez nem kell spéci jogosultság, tehát az anonymous is elviheti), vagy valaki Free/busy információja kell, melyhez viszont kellene jogosultság, pontosabban credential… de az anonymous miatt nem lett credential bekérve. Tehát azzal, hogy kiszélesítettem a kört az anonymous hozzáférésre, tulajdonképpen hazavágtam azokat, akik nagyon szívesen megadnék a nevüket, jelszavukat. Csak nem fogja megkérdezni senki.

De tényleg ez volt a megoldás. Mindenhonnan kivettük az anonymous hozzáférést – és beindult a Free/Busy információk terjesztése.
Ez egy hihetetlen levelezőrendszer.

Apu, hod med be?

Az a rengeteg alkalmazás a másik számítógépre? Jó kérdés. Rengetegszer láttam már, hogy valaki tűzfal mögött akart elérni egy akármilyen alkalmazásszervert, megnyitott érzésre portokat… majd végül, belefáradva a nyomozásokba, bebillentette az any-any szabályt.

Nos, itt egy – szószerint – kimerítő lista arról, hogy mely alkalmazás mely portokat használja.

Mivel ez azért alapvetően levelezéscentrikus blog, itt van egy másik írás arról, hogy konkrétan az Exchange 2007 milyen portokat használ, amikor dolgozik.

Desszertként pedig álljon itt egy leírás arról, hogyan lehet az Exchange RPC szolgáltatásait egyetlen portra koncentrálni – azaz tűzfalbaráttá tenni. Igaz, ez Exchange 2000/2003-ra íródott, de a cikk végén megjegyzik, hogy a beállítások remekül működnek 2007 alatt is.

Hányan is tolongunk?

Trika blogjáról jutottam el erre az oldalra. Igazi, vasárnap délutáni nézegetnivaló: hány embernek van a világon valamilyen vizsgán szerzett Microsoft minősítése?
Kezdjük rögtön a legnagyobb számmal: MCP – 2,296,561. Hát, ez jó nagy tolongás. Kellene harcolniuk rendesen, ha kitennék őket egy lakatlan szigetre.
Szűkítsük a kört. MCSE+M – 9186. Sokkal jobban hangzik.
Menjünk tovább: MCTS for Exchange: 7399. Meglepően sok, hiszen azért nem lehet olyan régóta ebből vizsgázni.
Van még lejjebb: MCITP, Enterprise Exchange Administrator – 2236. Azért még itt is harcolnánk egy-egy majomcombért.
És ezzel számomra vége is. Aranyéletük az architect-eknek lehet, remek kétjegyű számok állnak a soraikban. Na meg a Microsoft Virtual Earth 6.0 alá fejlesztőknek.

ISA Server 2006 Sp1

I’m swamped in the snow.
Ugye, mi azt mondjuk, hogy ‘el vagyok havazva’, az amerikaiak meg, hogy ‘I’m swamped’. Nos, ha lehet fokozni a kifejezés erejét, akkor én most be vagyok mocsarasodva into the hó.

De a blog is kezd pókhálós lenni, így ha hosszú cikkben nem is, de legalább említés szinten ejtek pár szót arról, hogy kijött az ISA 2006 Sp1.

Igen, tudom, az a blog neve, hogy Email és a Detektívek. Mit keres itt akkor az ISA?

Tessék csak megnézni a feature listából ezt a tételt:

Support for use of server certificates containing multiple Subject Alternative Name (SAN) entries
Certificates with multiple SAN entries are now supported at the web-published servers.
Previously, ISA Server was able to use only either the subject name (common name) of a server certificate, or the first entry in the SAN list.

Illetve meg lehet nézni az előzményeket.

Mi is az a SAN? Jelen kontextusban Subject Alternative Name. Érintett benne rendesen az Exchange 2007 is. Anélkül, hogy elmerülnék a részletekben: a SAN tanusítvány olyan tanusítvány, mely nem csak egy névre szól, hanem tartalmazhat alternatív neveket is. Márpedig ha a CAS szerverünket kintre is és bentre is publikálni akarjuk valós tanusítvánnyal, akkor SAN tanusítványt kell használnunk.

Nos, összeállt a kép?

Exchange 2007 SP1 Update Rollup 3

Megjelent az Exchange 2007 SP1-hez a harmadik rollup csomag. Letölthető innen.