Eltelik még egy kis idő, mire kiderül, hogy vajon a VMware, a Microsoft, a Google vagy az Amazon “felhő informatikája” lesz a nyerő. Addig is, kényszerűségből és kíváncsiságból egyaránt, elkezdtem használni egy szolgáltatást “az égből”.

Történt egyik nap, hogy a feleségem belépő szintű Nokia telefonja bemondta az unalmast: eltörött a bekapcsoló-gomb, de úgy, hogy folyton nyomva maradt, egy-két óra alatt lemerítve az akkumulátort és lehetetlenné téve, hogy akár egyetlen gombot is meg lehessen nyomni. Oldalbordám a maga szokásos egyszerűségével a “Kérek egy telefont, de most" kéréssel fordult felém. Szerencsére nem kellett vásárolni menni. Még tavaly ősszel kaptam egy új telefont (és azóta nem számoltam be róla, tudom.), de nem kellett leadnom a régit, így aztán áttettem a Nokiából a SIM kártyát az iPAQ 514-es Windows okostelefonba. Előtte a SIM-re mentettem a névjegyeket, így a számok is megmaradtak. Tudni kell, hogy a feleségem megrögzött “nem számítástechnikus”, tehát például a telefont kizárólag telefonálásra és SMS-ezésre használja. Fényképezés, naptár, e-mail, GPS, zenehallgatás, rádió, mobil böngészés stb. stb. kizárva. Ezek után nem kellett hosszú oktatás, és már kész is volt a csere.

Másnap kezdődtek a panaszok. Hogy azt mondja: ebben a telefonban a nevekhez csak egy telefonszám tartozik. Ez a telefon levágta a neveket, nem jeleníti meg az ékezeteket stb. Hát igen, a SIM kártya képességei korlátozottak. Mivel már a második telefonjánál hordoztuk SIM-mel a névjegyeket, és már a második alkalommal fordult elő mindez, elhatároztam, hogy a problémát kiírtom, méghozzá úgy, hogy az kényelmes legyen mindenkinek: Emőkének legyen egy kipofozott névjegyalbuma, nekem meg egy automatikus módszerem arra, hogy minden leendő telefonjában garantáltan és hibátlanul megjelenjenek a névjegyei, anélkül, hogy nekem bármilyen Nokia szoftverrel kellene bajlódnom.

A megoldást a Windows Live névjegyek szolgáltatásban találtam meg. Mivel egy viszonylag gazdag kommunikációs eszköztárral megáldott készülék az iPAQ 514-es, sok más mellett van rajta Wifi is. Ha van Wifi, akkor otthon van neki Internet elérése. Emellett a készülékre telepítettek gyárilag egy Windows Live kliens for Windows Mobile-t, ami hotmail levelezés-szinkronizálást, Messenger üzenetváltást és névjegyalbum-szinkronizálást tesz lehetővé. Pont úgy, mint egy Exchange-Activesync páros esetén. Annyi volt csak a teendőm, hogy egy alkalommal inicializálni kellett a Live beállításokat (Megadni a Live azonosítót, engedélyezni a szinkronizációt, megadni az ütemezés gyakoriságát stb.) és már össze is kötöttem a mobiltelefont a “felhővel”.

Tapasztalatok:

A kezdeti beállítás után a szinkronizáció stabil, adatvesztés nem történt. A Windows Live-val történő kapcsolattartás kétirányú. Ha valamit rögzítek egy valódi PC-s böngészőben, az lekerül a telefonra, ha pedig a telefonon a névjegyekben módosítok egy mezőt, az felkerül a “felhőbe” (Mondhatni: nyitható ajtó, forgatható kormány). A SIM névjegyeket nem lehet azonnal Live névjegyekké tenni, hiába sugallja ezt a kezelőfelület. Előbb a telefon memóriájába kell másolni, majd az átmásolt nevet már “Windows Live névjeggyé” lehet konvertálni. (A fenti középső ábrán látható két SIM névjegy). Live névjeggyé csak csatlakoztatott állapotban lehet konvertálni egy normál névjegyet. Állandó GPRS/EDGE/UMTS stb. kapcsolatnál ez nem gond, a feleségemnek viszont ilyen kapcsolat még luxus, marad a wifi. Így viszont kompromisszumot kell kötni: nevet fel lehet venni, de este, amikor hálózat és internet közelébe kerülünk, el kell végezni a konverziót és szinkronizálni kell. Még egyszer: állandó kapcsolat esetén ez nem probléma.

Érdekes a mezők eltérő használata. A telefonban valószínűleg az Outlook mobile űrlapot használja a szoftver, a Live-nak pedig van egy másik, saját sablonja. (Tipikus MS betegség: az egyik csapat nem egyeztet a másikkal.) A szinkronizálás kiterjed a címre, mobil-, otthoni, és munkahelyi telefonszámra, névre, egyéb címekre stb. Mindkét oldalon megtalálható a “becenév” mező, ez azonban nem szinkronizálódik. Mindkét helyen létezik a “gyerekek” mező is, de ez sem szinkronizálódik. Végül a beosztás mező ugyan frissül, de nem tehető a névjegy kijelző sorába. Ez többféle problémát is felvet.

Először is vannak olyan emberek, akiknek ugyan tudjuk a nevét, de az nem fontos, sőt nem is keresünk rájuk. Náluk az a fontos, hogy mi a foglalkozásuk. A fenti képen látható egy festőmester névjegye. Úgy keresek rá a névre, hogy “Festő”, de a beosztás/foglalkozás nem jeleníthető meg kijelző-sorban. Ezért azt a trükköt kell alkalmazni, hogy az utónév mező után zárójelben odaírjuk a foglalkozást. Ez látszik a képen is. Hasonlóképpen lehetnek olyan névjegyeink, ahol meg egy másik személlyel kapcsolatosan van szükségünk információra. A kislányom óvodás társainak nincs (még) mobiltelefonja, viszont a szüleiket néha hívnunk kell. Általában ilyenkor is nehéz felidézni a felnőtt nevét, csak azt tudjuk, hogy “Anna anyukája”. Ugyanazt a trükköt kellett alkalmazni, mint a foglalkozásnál, az utónév mögé kellett zárójelben feltüntetni az ovistárs nevét.)

Korábban már írtam róla, hogy ez a rendszer valóban “élő”, vagyis mód van rá, hogy minden névjegy valódi tulajdonosa frissíthesse az adatait, ha pedig így tesz, akkor mi értesülhetünk róla, illetve a változások automatikusan átvezetőd(het)nek a névjegyeinkbe. Például a feleségem “előfizetett” az én adataimra. Ha az én mobil számom változik, az ő mobiltelefonjába ez szépen automatikusan átkerül. Nem is lenne ezzel semmi gond, ha a feleségem nem úgy szokott volna tárcsázni engem, hogy “férj”. Mivel a névjegy minden adatára előfizetett, azokat teljes egészében én kontrollálom. Csakhogy én meg nem írhatom oda a nevemhez, hogy “férj” hiszen ez a kapcsolat kizárólag a feleségemmel áll fenn, mással nem.  Még érdekesebb a helyzet “Apuci” és “Anyuci” esetében. A feleségem így hívja a szüleit. Világos, hogy anyósom nem írhatja a nevéhez, hogy “Anyuci”, mert ez a kapcsolat csak a gyerekeire vonatkozik, viszont a gyerekei sem írhatják, ha a névjegykártya frissítés tőle (mármint anyósomtól) származik. Ebben az esetben a megoldás a kétszeres név felvétel. Nem szép, de amíg a kapcsolat jellegét és a mezőszintű frissítését nem lehet állítani, addig ez marad.

Sokat foglalkoztam a problémákkal, pedig ezt a pár limitációt leszámítva igazán jól ment az átállás. A Live névjegyek pont úgy viselkednek, mint a telefonban tároltak, hívhatók a munkahelyi és otthoni számok, kereshetők is. Sőt, a Live-os élet legalább egy szempontból a vállalati verziók előtt jár: ha egy partnerünk egyben a Live Messenger partnerek között is szerepel, akkor láthatjuk a jelenlét információját is. (A képeken épp senki nem jelentkezett be.)

A kezelőfelület is a világ legegyszerűbb dolgai közé tartozik. A képerőnyő beosztását “Windows Live”-ra állítottam. Ha a szinkronizálás sorra állok és megnyomom a nagy középső gombot (kvázi: Enter), már indul a szinkronizálás. Mellékesen lejönnek a hotmail-es levelek is, de ezt a nejem nem használja, ahhoz elkéri tőlem esténként a notebookomat.

Érdekes volt, hogy a névjegyek összefésülése előtt 34 kapcsolata volt a feleségemnek – kizárólag e-mail címek. Ezek közül 30 viszont a telefonjában is szerepelt, de csak a telefonszámuk. Az összefésülés egy része automatikusan sikerült (ahol névegyezés volt), a többit nekem kellett észrevennem. Most, a rendrakás után összesen 140 körül van a névjegyek száma.

Éles bevetés
Magam sem gondoltam volna, de egy-két héttel a címtár rendezése után élesben is vizsgázott a rendszer. Egy szombat délutánra megbeszéltük Emőke volt egyetemi csoporttársával, hogy meglátogatjuk őket és személyesen is gratulálunk neki a nemrég született kisbabájukhoz. Előző nap megkérdeztük a pontos címet, és én meg rögzítettem a névhez az új adatokat.
Aki már “csomagolt be” három gyerkőcöt az autóba, az tudja, hogy egy elindulás az nem egy egyszerű történet. Nagy nehezen összeszedtük magunkat, indulás előtt pedig megkérdeztem Emőkét, hogy mi a pontos cím. Hát az a telefonban van. Hol a telefon? Az fent maradt a lakásban. – Nem mentünk vissza érte, az utca nevére emlékeztünk, beállítottam az közepét a célpontnak és elindultunk. Meg is érkeztünk annak rendje és módja szerint. No ekkor fel kellet volna hívni az vendéglátónkat, de a telefon otthon maradt. Sebaj, majd felhívom én – egy idegen ember jelentkezett be, ez a barátnő egy korábbi telefonszáma volt. No most légy okos! A feleségem benyitott a legközelebbi fodrászhoz, hátha ott ismerik. Nem ismerték. Nekem meg az jutott eszembe, hogy a saját mobilomról bejelentkeztem a feleségem Live fiókjába, és megnéztem a névjegyek között a keresettet. Telefon, siker!

Összegzés
Bár a rendrakás java része kézzel történt, a végeredmény megfelelő (10-ből 8-at adnék, ha értékelni kell.). A feleségemnek van egy olyan címtára, amelynek van egy automatikus másolata a “felhőben”. A napi tevékenységek során ez tulajdonképpen nem is lényeges. Telefon-váltáskor viszont az új eszköz Live kliense automatikusan lerántja majd a címeket és már megy is tovább az élet. Vagyis – nekem sem lesz többet ilyen munkám.

Azt mondod, hogy ez nagyon Microsoft központú megoldás? Hogy bezárom magam a Windows Mobil paltformba? Nem így van. A Windows Live for mobile más platformokra elérhető. Ezek: Blackberry, Nokia (E51, E52,, E55, E61i, E63, E65, E66, E71, E75, E90, N73, N76, N78-82, N85, N86, N93i, N95, N96, 2007 claccic, és vgy még további 2 tucat. A pontos lista itt elérhető); Ki nem próbáltam őket, de ha valaki igen, ossza meg velem a tapasztalatait.

A Showstopper szó eredetileg olyas valakit jelöl, aki egy előadás (tánc, színház stb.) során pozitív értelemben valami különlegeset tesz. Magyarul: lélegzetelállító. De a szoftvervilágban van egy másik jelentése is: olyan szoftverhiba (bug), amely akadályozza a szoftver kiadását. Ezt a kifejezést használták (és használják ma is) Dave Culter csapatában, amikor a Windows NT operációs rendszert megalkották. (Lásd még a Showstopper! című könyvet a Windows NT születéséről - milyen kétértelmű a cím!) Szoftvercég lévén a kifejezés gyorsan elterjedt a Microsofton belül és tágabb értelmet kapott: akadály, amely megállít egy folyamatot. Ügyfél eláll a vásárlási/bevezetési stb. szándékától. A projekt egy dolog miatt leáll, elhal stb.

Az elmúlt időszakban egy OCS próbarendszer összeállítását végeztem és összegyűjtöttem néhány olyan kritériumot, feltételt, amelyeket ha nem tudunk teljesíteni, egy OCS bevezetés számára "Showstopper" lehet. Íme - a teljesség igénye nélkül:

1. Windows Server 2003 Forest Functional Level. Ez azt jelenti, hogy nem lehet Windows 2000-es tartományvezérlő a hálózatban, csak 2003-as, majd az AD erdő- és tartományi funkcionális szintet legalább 2003-as szintre kell emelni.
2. PKI infrastruktúra. Elvileg nem lehetetlen 4-5 tanúsítványt beszerezni, de ha ez nem járható út, akkor legalább egy tanúsítványosztó kiszolgálóra és egy, belülről és kívülről is elérhető tanúsítvány visszavonási lista (CRL) helyre szükség van.
3. SRV rekordokat kezelő DNS szerver. A belső hálózatban ma már ez többnyire nem probléma, bár ismerek olyan céget, ahol még BIND 4-es DNS kiszolgálók futnak. A külső rekordokat viszont többnyire internet-szolgáltatók vagy például az Egységes Kormányzati Gerinchálózat DNS szerverei tárolják. Itt lehetnek gondok, nem árt az ellenőrzés.
4. Split DNS. Ez nem kötelező, de ha nincs, akkor a kliensek automatikus konfigurációja nem fog menni. A csoportházirend alkalmazása mentőöv lehet.
5. Tűzfal struktúra. A IT szervezetek többsége egyrétegű tűzfalrendszerrel üzemel. Ha az OCS-s kívülről is el szeretnénk érni, akkor kétrétegű (back-to-back) architektúrára lesz szükség.
6. Publikus IP cím az Audio/Video Edge kiszolgáló számára. Ha szeretnénk, hogy az OCS klienseink otthonról is működjenek, akkor az A/V Edge szerepkörnek meg kell adni, ami jár. Ezt nem Microsoft találmánya. Az A/V Edge egy pontosan az RFC 3489 szerint működő STUN szerver. (Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)). Az A/V Edge a DMZ-ben(*) található. Ha a jelenlegi DMZ-ben privát IP címekkel dolgoznak, akkor azok valóságos címekre fordítása több hónappal visszavetheti a projektet. Legrosszabb esetben pedig showstopper.
7. A/V Edge igényelte portok megnyitása a tűzfalon. Az A/V Edge általában kiveri a biztosítékot a hálózati tűzfalakat konfiguráló szakembereknél. Többnyire azért, mert ökölszabályok szerint dolgoznak ("kevés portot kinyitni"), ahelyett, hogy megértenék a konfguráció valóságos kockázatait. Ennek igazából nem kellene showstoppernek lennie, de a valóságban sajnos néha az.
8. A meglévő PBX típusa. Ez sem mindig showstopper, de a fellelhető dokumentáció valamint a kettős szaktudás (telefonos + IT-s) hiánya a telefonintegrációt meghiúsíthatja. A telefonintegráció sikerének titka: ismerni a PBX-et, kiválasztani a megfelelő media gateway-t és jól bekonfigurálni mind a kettőt, plusz az OCS-t. Nem triviális.

És mindez csak technológia. A licencek, árak, egyéb termékekkel való interoperabilitás megannyi buktató lehet, ha a projekt kritériumai között olyan súllyal szerepelnek. Az OCS projekteknél úgy lehet számolni, hogy az implementációs idő fele-kétharmada előkészület: DNS, AD, PKI, tűzfal, PBX - megannyi feltétel a sikerhez.

Ma végre kaptam egy új telefont. Végre - mert már hetek óta azt játszotta a régi, hogy a legváltozatosabb helyzetekben újraindult, amit ha nem vettem észre, akkor az engem hívók számára úgy tűnt, kikapcsoltam a telefonom. Ez egy mindenórás feleség esetén egyáltalán nem vicces, úgyhogytöbb kollégám telefonszámát is megadtam neki arra az esetre, ha engem nem tudna elérni, én meg félóránként azzal játszottam, hogy nézegettem, vajon be kell- lépnem újra a mobilomba. No, ennek van most vége.

Az itt látható készüléket kaptam, amely egy hamisítatlan Windows Mobile 6 alapú üzleti telefon. Smartphone, nem pedig PDA, vagyis inkább a telefonálásra hegyezték ki, mintsem hogy mini-PC legyen. Ezzel együtt nekem Nekem jónéhány olyan problémámat orvosolta, amely inkább PDA jellegű funkció. Ezekről dióhéjban:

• Bosszantó volt, hogy eddig a word, excel és powerpoint mellékleteket nem tudtam megnyitni. A Windows Mobile 5 vilgában csak a PDA változatokhoz volt Pocket Office, a samrtphone-okhoz nem. Elvileg lett volna lehetőségem egy nem nyilvános változat telepítésére, de nem bajlódtam vele. Most, hála a 6-os operációs rendszernek, az ilyen mellékleteket már meg tudom nyitni.
• Az értekezlet-szervező funkció a korábbi gépen elég kezdetleges volt. Nem tudtam, hogy kik vesznek részt a találkozón és nem tudtam áttenni új időpontra. Most mindkettő megoldódott.
• A Microsofton belül aktívan használunk Rights Management Services szolgáltatást. Mivel az ilyen leveleknél a küldő pontosan szabályozhatja azt, hogy mi történjen a tartalommal, vagyis meg lehet akadályozni, hogy az információ kiszivárogjon, a küldő többnyire "igen érdekes" véleményét fogalmazza meg, vagy tényleg "fontos, de másokra nem tartozó" információ van a levélben. No, ha valami ilyen érdekes, akkor fúrja is az ember oldalát, hogy mi lehet benne. Windows Mobil 5 esetén fúrhatja is, mert ahhoz nics beépített RMS kliens. A Windows Mobil 6-ban viszont van, csak aktiválni kell. Most már el tudom olvasni, amit igazán szeretnék.
• A Microsofthoz jövetelem előtt egy i-mate SP5i készülékem volt, amely tudott Wifi kapcsolatot. A Qtek 8500-ból ez kimaradt, az új készülékem viszont teljes Wifi támogatással rendelkezik, még a jó erős WPA2-PSK titkosítást is támogatja. Ha itthonról netezem, és ez néha előfordul, akkor végre nem kell GPRS-sel bajlódnom. Sőt, ez Redmondban is működni fog majd.
• A Qtek 8500 kamerája botrányos volt, és ez esetben nagyon finoman fogalmaztam. A mostani 1.3 Megapixeles viszont nagyon jól tudja azt az egyetlen funkciót, amire használni fogom: a névjegyekhez villámportré készítésére. Éles képet ad és viszonylag gyorsan reagál az elsütőgombra. Ennyi elég is.

Van ezen túl még néhány olyan tulajdonsága, amelyet a régi gépen is elő lehetett volna bányászni, de valahogy bonyolult vagy nehézkes volt:

• Internetmegosztás. Egy külön kis miniprogram két paraméterrel: mi a PC-kapcsolat (USB vagy Bluetooth), illetve mi az Internet kapcsolat (GPRS). A funkció önmagáért beszél. Ha van mobil térerő, akkor van internet hozzáférésem.
• A mikroSD kártya, ahogy azt a képen is láthatjátok, könnyedén behelyezhető. A Qtek esetén ezt csak akkumulátor eltávolításával lehetett megtenni.

Végezetül még egy szimpatikus dolog: olyan töltővel látták el a készüléket, amelynek USB csatlakozója van, vagyis így egyetlen kábellel lehet a töltőt használni és a notebookot a mobillal összekötni. Ráadásul ez egy nem túl egzotikus kábel, tehát még boltban is kapható, ami a Qtek esetén nem így volt.

Összességében egy jobb készülékkel vágok neki a jövő évnek. Hogy elég lesz-e az majd elválik, de a bemutatkozó néhány óra jó volt.

Budai Petinek köszönhetően megjelent az OCS 2007-ről írt cikkem a HWSW portálon. Ha lemaradtál a TechNet-ről, itt egy újabb lehetőség.

Jó olvasgatást!

Ma délelőtt össze kellett állítanom egy kis tervezési silabuszt az Office Communications Server 2007 -hez. Nem volt nagy kaland, mert az OCS 2007 nyilvános bétájának nyilvános dokumentációja tartalmaz egy tervezési útmutatót (planning guide). Egy kis böngészéssel hamar rá lehet jönni, mikor érdemes Standard illetve Enterprise verzióval számolni, illetve mikor kell standard vagy Enterprise CAL-t vásárolni. A képeken egyetlen szerep hiányzik, ez pedig az OCS Director szerver. A Director egy hitelesítési felület, standard szerverrel megoldható és bármelyik mintaarchitektúrába  beilleszthető. Az OCS Director-t a belső hálózaton kell elhelyezni, redundanciáját hardveres load balancer biztosíthatja.

Funkcionalitás:

• Üzenetküldés, webkonferencia, audio-konferencia

OCS igények:

• 1 db OCS 2007 Standard Server
• x db Standard CAL (IM és jelenlét)
• y db Enterprise CAL (konferencia)

Funkcionalitás:

• Üzenetküldés, webkonferencia, audio-konferencia
• Külső felhasználók becsatlakozása

OCS igények:

• 2 db OCS 2007 Standard Server
• 1 db http Reverse Proxy (például, de nem kizárólag ISA Server 2006)
• x db Standard CAL (IM és jelenlét)
• y db Enterprise CAL (konferencia)

Funkcionalitás:

• Üzenetküldés, webkonferencia, audio-konferencia
• Külső felhasználók becsatlakozása
• Telefonintegráció

OCS igények:

• 2 db OCS 2007 Standard Server
• 1 db http Reverse Proxy (például, de nem kizárólag ISA Server 2006)
• 1 db Advanced Media Gateway (külső gyártó)
• x db Standard CAL (IM és jelenlét)
• y db Enterprise CAL (konferencia és telefon)

Funkcionalitás:

• Üzenetküldés, webkonferencia, audio-konferencia
• Külső felhasználók becsatlakozása
• Telefonintegráció
• Több telephelyes telefonintegráció

OCS igények:

• 2 db OCS 2007 Standard Server
• y db OCS 2007 Standard Server a Mediation Server szerepkörhöz
• 1 db http Reverse Proxy (például, de nem kizárólag ISA Server 2006)
• x db Advanced Gateway (külső gyártó)
• y db Basic Gateway (külső gyártó)
• x db Standard CAL (IM és jelenlét)
• y db Enterprise CAL (konferencia és telefon)

Funkcionalitás:

• Üzenetküldés, webkonferencia, audio-konferencia
• Külső felhasználók becsatlakozása
• Telefonintegráció
• Több telephelyes telefonintegráció
• Webes azonnali üzenetküldés
• Csevegés, wegkonferencia és hivásadatok archiválása

OCS igények:

• 2 db OCS 2007 Standard Server
• 1 db OCS 2007 Standard Server a Web Access hozzáféréshez
• 1 db OCS 2007 Standard Server az archiváláshoz
• y db OCS 2007 Standard Server a Mediation Server szerepkörhöz
• 1 db http Reverse Proxy (például, de nem kizárólag ISA Server 2006)
• x db Advanced Gateway (külső gyártó)
• y db Basic Gateway (külső gyártó)
• x db Standard CAL (IM és jelenlét)
• y db Enterprise CAL (konferencia és telefon)

Funkcionalitás:

• Üzenetküldés, webkonferencia, audio-konferencia
• Redundancia

OCS igények:

• n db OCS 2007 Enterprise Server
• 1 db hardveres load balance (külső gyártó)
• 1 db SQL Server
• x db Standard CAL (IM és jelenlét)
• y db Enterprise CAL (konferencia)

Funkcionalitás:

• Üzenetküldés, webkonferencia, audio-konferencia
• Redundancia
• Terhelés-elosztás
• Háttértár redundancia

OCS igények:

• n db OCS 2007 Enterprise Server
• 2 db hardveres load balance (külső gyártó)
• 1 db SQL Cluster
• x db Standard CAL (IM és jelenlét)
• y db Enterprise CAL (konferencia)

Funkcionalitás:

• Üzenetküldés, webkonferencia, audio-konferencia
• Redundancia
• Terhelés-elosztás
• Háttértár redundancia
• Külső hozzáférés – terheléselosztással redundancia nélkül

OCS igények (pontosan a kép szerint):

• 9 db OCS 2007 Enterprise Server
• 2 db OCS 2007 Standard Server
• 2 db hardveres load balance (külső gyártó)
• 1 db SQL Cluster
• x db Standard CAL (IM és jelenlét)
• y db Enterprise CAL (konferencia)

A DMZ-ben lévő Edge kiszolgálók skálázása:

Különálló vagy konszolidált szerverek

OCS igények (pontosan a kép szerint):

• 4 db OCS 2007 Enterprise Server
• 1 db Reverse Proxy Server (például, de nem kizárólag ISA 2006)

Funkcionalitás:

• Üzenetküldés, webkonferencia, audio-konferencia
• Redundancia
• Terhelés-elosztás
• Háttértár redundancia
• Külső hozzáférés – terheléselosztással
• Telefonintegráció több telephellyel
• Redundáns adatközpont

OCS igények (pontosan a kép szerint):

• 21 db OCS 2007 Enterprise Server
• 12 db hardveres load balance (külső gyártó)
• 6 db OCS 2007 Standard Server
• 1 db SQL Cluster
• 1 db SQL Server
• x db Standard CAL (IM és jelenlét)
• y db Enterprise CAL (konferencia és telefon)

Az elmúlt egy-két napban egyik ügyfelünknek egy ajánlatot készítettünk. Ennek részeként ígértünk egy hangsúlyozottan nem teljeskörű összehasonlítást a különböző Outlook verziókról. Meglepődve tapasztaltam, hogy ilyet csak részletekben lehet összeszedni, úgyhogy végül magam gyűjtöttem a szempontokat. Íme a lista. Figyelem! Nem hivatalos - csak a saját véleményem. Ha valaki hibát találna benne, akkor feltétlenül jelezze. (A táblázat publikálásának külön története van, az majd egy külön bejegyzés lesz.)

Update: Figyelem! A teljes táblázatot csak akkor látjátok, ha a webnaplóbejegyzéseket külön megnézitek. A címlapra "nem fér ki".

• AD Sémabővítést igényel, ezért éles rendszerben egyáltalán nem ajánlatos kezdeni vele. Ha pedig van már működő LCS 2005, akkor különösen nem ajánlott ott turkálni.
• PKI Az OCS 2007-et meg kell erőszakolni, hogy ne használjon tanusítványokat. Egyszerűbb egy gyors PKI implementáció  Ha az sehogy nem megy, akkor legalább a szükséges tanusítványokat be kell szerezni valahogy.
• IIS Kötelező tartozék, intenzíven használja úton útfélen.

• SQL. Elvileg megvan a saját ingyenes változatával is, de Enterprise Edition esetén komolyabbra is szükség lehet.
• ISA 2006. Csak akkor játszik, ha külső felhasználók számára is ki szeretnénk publikálni a szolgáltatást, de akkor mindjárt kettő tűzfalra is szükség lesz. Elvileg nem ragaszkodik az ISA-hoz, csak ahogy írtam: nagyon-nagyon szereti  
• MSMQ. Archiválásnál nem fogjuk tudni megkerülni.

Kivirul az OCS 2007, ha Exchange-dzsel, Sharepointtal, Outlookkal és egyéb MS megoldásokkal találkozik, de ezek egyike sem kötelező.

Ajánlom átfutni a még márciusban kipublikált OCS 2007 telepítésemnél felvett képeket. Bár szöveges beszámoló egyelőre nincs, meg lehet nézni, hogyan tippeltem meg én a válaszokat a varázsló kérdéseire  (Elárulom, hogy aztán nálam elindult)

Készítettem egy új képalbumot és betettem kb. 90 képet, amelyek az elmúlt két nap kalandjának termékei. Ennyi ideig tartott, amíg minden összejött, hogy az Office Communication Server 2007 legújabb (egyelőre csak belső) bétája elinduljon. Mindezt úgy, hogy igazából nem is ütköztem akadályba, az OCS-nek egy relatív egyszerű architektúráját hoztam létre, és az előfeltételek (AD, PKI, SQL) már készen álltak. Egy kicsit (na jó, nem is kicsit!) ijesztő lehet, de ez bizony egy meglehetősen összetett termék - ehhez mérten a tudása is óriási. Szándékaim szerint többször írok majd a termékről és a tapasztalataimról is. Most legyen itt csupán néhány tény, a többiről később.

Szóval az Office Communication Server 2007 a "Live Communication Server 2005" utódja, de az elmúlt két évben elnyelte magába a korábban csak megvehető szolgáltatásként létezett Live Meeting szervert is. Mire jó az OCS 2007? Aki használt már MSN Live Messengert (és ki ne használta volna), az a kliens oldalt már ismeri. Az OCS - többek között - az azonnali üzenetküldő rendszer szerver oldali része. Az azonnali üzenetküldésen túl azonban ad-hoc hang- és videókonferenciára is képes, sőt komplett értekezleteket, előadásokat is lehet vele létrehozni. Ez utóbbi lényegében a sokak által már ismert technet webcastok, csak éppen egy generációval több szolgáltatással.

Az albumról annyit, hogy egy ún. konszolidált (egy kiszolgálóra sűrített) telepítést végeztem el, ahol egy egyetlen tagból álló Front-End Pool-t hoztam létre. Ez a kiszolgáló négyféle konferencia-típus lebonyolítására lesz majd képes. A háttérben (egy másik kiszolgálón) egy SQL szerver dolgozik, a későbbiekben pedig lesz egy Director szerver és egy Edge szerver is a DMZ-be. Az OCS-ről, az demó architektúrájáról, a telepítésről és a funkciókról majd egy más alkalommal írok. 

A Live Communication Server (LCS) azt ígéri, hogy olcsóbb lehet a vállalaton belüli, vagy távoli felhasználókkal a komunikáció. Tegnap azt próbáltam ki, hogy vajon az LCS kliense, az Office communicator segítségével lehet-e legalább hang kapcsolatot felépíteni két gép között, ha a kliens egy Windows Server 2003 Terminal RDP munkamenetben fut. A tesztre azért volt szükség, mert egy egész telephelyet terminál ablakba szorítunk, ott pedig igen sok kereskedő van, akiknek szükségük lenne olcsó kommunikációra, például LCS szolgáltatásokra.

Az eredmény sajnos negatív. Sőt! A neten találtam egy beszélgetést, ahol egy MS illetékes úgy nyilatkozott, miszerint a következő (longhorn) verzió TS szolgáltatása sem fogja támogatni a "távoli mikrofon"-t. 

A helyzet azért lehet nem katasztrofális. A skype már működő modelljét követve a Microsoft is megjelenteti az Office kommunikátort okostelefonokra, Microsoft Office Communicator for Windows Mobiles (MOC) lesz a neve, ha majd elkészül. Ha belegondolok, eléggé szédítő a megoldás. Íme a hozzávalók:

• Wifi-képes Windows Mobile 5 okostelefon
• MOC for Windows Mobile kliens (gondolom ingyen) 
• Wifi hálózat
• LCS 2005 Server + LCS kliens licence
• Egyéb alapok (PKI, SQL, AD stb. stb.)

Vizionált eredmény:

1. Beérkezem az irodába, a mobilom automatikusan rácsatlakozik a Wifi hálózatra, a MOC kliens pedig bejelentkezik az LCS-be. Bárki szeretne hívni, akár PC-ről, akár egy másik mobil kliensről, láthatja, hogy elérhető vagyok-e, esetleg épp tárgyalok, vagy nem is vagyok a hálózatban. Hívhatnak és "ingyen" tehetik, mert a vállalati hálózatot használja a rendszer.
2. Távoli okostelefonok pl. VPN vaqy LCS Access Proxy segítségével a vállalati hálózatba bejelentkezve a fenti eredményt érhetik el. Költség: a mobil eszköz internetforgalma. (A beruházást most nem taglalva)

Azt jósolom, hogy ez a jelenleg még kissé futurisztikus - több high end jellegű technológiát magában foglaló - konfiguráció borzasztó gyorsan fog terjedni, ami lenyomja mind az okostelefonok, mind a mobil internet árakat - ezzel együtt persze mind a szolgáltatóknak, mind a gyártóknak óriási üzletet jelenthet. (Nem kell túl okosnak lenni ehhez, a Skype is erre indult.) Az mondom továbbá, hogy:

1. A DECT meghal
2. Kritikus lesz az együtműködési képesség a jelenlét alapú rendszere, mint az LCS és a VOIP telefonközpotok között
3. A hálózat és annak minősége elsőrendű fontosságúvá válik
4. A Wifi magasabb energiaigénye miatt nő a nyomás a hosszabb élettartamú akkumulátor fejlesztésére

Miért gondolom, hogy mindenki "csináld magad" mobilhálózatot akar majd? Mert ezzel teljesül a fogyasztó egyik örök álma: "a távirányító pedig az én kezemben van!"

Nem hiszitek? Három éve hol volt a Skype?

• Chat - természetesen
• A felhasználók saját kontaktlistát állíthatnak fel. (De ez az admin távolról piszkálhatja :-))
• Videotelefon. Kipróbáltuk egy másik telephelyi kollégával. Akadásmentes, és jobb a hangja, mint a telefoné. Szlovén telefonszámla felszámolás előtt :-)

Amit nem tud - a jelenlegi konfiguráció mellett (tekintsük ezt jövőbeli feladatoknak)

• Renote user VPN nélkül
• Titkosított csatorna (PKI hiányzik)
• Archiválás (az MSMQ-val most még nem álltam neki birkózni)
• Nem vállalati felhasználó becsatolása a felhasználók közé (pl. partnerek)
• Valamiféle együttműködés a jelenlegi telefonos rendszerrel

Sajnos a feladatok egy része újabb felhőkarcoló-építés (PKI, talán tűzfalváltás, DMZ felhasználása stb.), az pedig lassan fog menni. Hiába, nem 50 órás egy nap. A telefonrendszerrel való integrálás pedig tényleg "határeset", az Ericsson központunk nekem többnyire fekete doboz.

A Blackberry egy érdekes szolgáltatás, Magyarországon is kapható. Azt csinálja, hogy a Blackberry alkalmazást futtató mobil eszközre a Blackberry szolgáltatás előfizetésen keresztül kinyomkodja az Exchange postaládába érkező leveleket egy Blackberry szerveren keresztül méghozzá úgy, hogy a tűzfalon nem kell külön portot nyitni, csak egy Outbound kapcsolatot kell engedélyezni. A technológia push jellegű, vagyis nem kell időről időre nézegetni (se időzítve, se kézzel, hanem a Blackberry szerver "szól" a mobil eszköznek, hogy jött egy új levél. Az egész annyira fürge, hogy előbb megérkezik a Blackberry mobilra a levél, mint az Offile cache-es Outlook 2003-ba!

Az egész rendszerben két nagyon szép dolog van és néhány csúnya. Nagyon szép a "push" megoldás és az, hogy mind a levél, mind a mellékletek 2K-s darabokban jön le, vagyis csak akkor jön az újab 2K, ha azt a felhasználó kifejezetten kéri. A "push" gyorssá teszi a rendszert, a 2K-s rendszer pedig olcsóvá. A csúnya az egészben, hogy csupa-csupa Blackberry termék az egész rendszer. Az eredeti szolgáltatás óta már javultak, a mobil hardvert elválasztották a mobil  szoftvertől (így már nem csak Blackberry eszközön vásárolható Blackberry szolgáltatás), de az egész így is gyanúsan monopolisztikus.

Mától az a kérdés, hogy az egész megoldás meddig fog élni. A Június 6-i Steve Ballmer prezentációban ugyanis elhangzott, hogy új Exchange SP2 várható, továbbá a szinkronizáció az OMA kliensekkel "push" jellegű lesz. Úgy tűnik, hogy a Blackberry versenyelőnye elpárolgott.