Kicsit lemaradtam róla, hogy publikus a jó hír.
Az új BPOS ügyfeleknek mostantól a Hosted BlackBerry Service szolgáltatásért nem számítanak fel díjat, az Office 365-ben is ingyenes lesz!
A szolgáltatás nem kevés errőforrást emésztett fel eddig a Microsoftnál, viszont a RIM-hez fog átkerülni az Office 365-ben, nem a Microsoft, hanem a RIM üzemelteti BES szervereket, ők adják a supportot és a plusz szolgáltatásokért ők fognak számlázni. Maga az email szolgáltatás a jelenlegi formájában ingyenes lesz, gondolom az egyéb szolgáltatásokért ( pl. alkalmazás management ) fognak csak pénzt kérni. Gyakorlatilag teljes értékű BES szolgáltatásra is lesz lehetőség.
Úgy néz ki többet és ingyen kapunk :)
Elkezdték kiküldeni a parnereknek, a nyilvános Office 365 béta meghívókat! Mi is megkaptuk az eddig belső béta hozzáférés mellé. Akik regisztáltak a bétára, nekik is folyamatosan küldik ki a meghívókat.
Ugyan béta a neve, de ez már a végleges változat a kódon már nem fognak módosítani és a bétából, próbaváltozatra és véglegesre is lehet majd migrálni.
Mivel nyilvános én is írhatok végre részleteket, eddig az NDA miatt nem tudtam. Hamarosan sok új cikket olvashattok.
A live meeting már nem külön termék a Lync megjelenése óta, hanem beleintegrálódik a Lync-be. Eddig két külön termék volt a live meeting és az office communicator. Egyre többször fordul elő, hogy meetingeket már Lyncben szerveznek, pl. mi is már ezt használjuk. Az online meetinghez való csatlakozáskor 4 opció van:
- Lync kliens van a gépen telepítve
- Lync Attendee kliens van telepítve - ez egy ingyenes lebutított változat, de az online konferencia szempontjából teljes értékű
- Silverlight segítségével a böngészőben fut
- Microsoft Office Communicator 2007 R2 vagy Microsoft Office Communicator 2007 van telepítve
A böngészőben futó Silverlight-os klienst a fenti oldalról lehet elindtani, de ez csak akkor jelenik meg, ha nincs Lync kliens a gépen. Ha van, akkor a meeting url-re kattintva rögtön a Lync indul.
Előfordulhat, hogy mindenképp a web klienssel szeretnénk csatlakozni:
- beta Lync kliens van a gépen
- Lync kliens van a gépen, de központilag tiltva van a külső kommunikáció
- túl szigorúak a tűzfal szabályok a cégnél
Ha a Lync kliens fenn van a gépen akkor a kliens fog elindulni, nem jön fel a web app. Szerencsére van módszer arra, hogy kikényszerítsük a webes klienst, hozzá kell adni a következő url-t a meeting url-jéhez:
?sl=1
Pl. ha az eredeti url https://join.microsoft.com/meet/demo/02NQW1Z3 volt akkor https://join.microsoft.com/meet/demo/02NQW1Z3?sl=1 -re kell módosítani. Így már fixen a web kliens jön fel.
Csak egy gyorshír: Amikor írtam az előző cikket, eszembe jutott, hogy írtam anno a Microsoftosoknak, hogy javítsák ki a workload poster-t, amiről az edge szerveres postban írtam. Azóta már javították is, innen letölthető.
Bekerült egy jó nagy piros nyíl az edge server és a kliens közé:
Ismét egy Lync cikk, ígérem nem csak Lyncről lesz szó, de a BPOS jól működik. BPOS-nál nehezebb ilyesmibe belefutni, maximum az ügyfélszolgálattal kell küzdeni, ha IMAP-t szeretne az ember fia, de ez majd egy másik blogposzt lesz.
Lync-et szeretnénk már kizárólag használni midenféle telefonálásra a cégben. Egyrészt kényelmesebb beírni pl. a keresőbe egy ügyfél nevét és már rögtön hívni is, másrészt így bárhol ahol van internet kapcsolat működik, mintha az irodában lennénk...
Ennek egy akadálya volt eddig, nem tudtunk Lync-el hívást átadni - communicatorral működött - , emiatt meg kellett tartanunk a voip telefonokat, ami még helyet is foglal az asztalon. Belenéztem a konfigurációba, de első ránézésre nem találtam meg a hiba okát, idő meg az év végi hajtás miatt nem igazán maradt.
Így néz ki az infrastruktúra ebből a szempontból:
A probléma az, ha a PSTN ( ISDN telefonvonal ) felől jön egy hívás, akkor az egyik Lync kliens nem tudja átadni a másiknak a hívást.
Először a logok bogarászásával kezdtem Lync oldalon, de nem sok eredményre vezetett, egyszerűen túl részletes a log, másrészt a SIP logban csak információként jelenik meg a probléma. ( Csak utólag, amikor tudtam mit nézzek találtam meg )
Ezután megpróbáltam összerakni a scenáriókat, hogy mikor nem megy. Ebből az jött ki, ha az Asterisk is benne van a buliban, akkor nem működik a kliensek közti hívás átadás.
Az Asterisk felületén nem volt semmi olyan hibaüzenet hívás átadáskor, ami előrébb vitt volna.
Elővettem a Wireshark-t és elkezdtem nézni mi történik:
A Lync Mediation szervertől jön a kérés:
REFER sip:412@192.168.1.16;transport=TCP SIP/2.0
FROM: <sip:8410@192.168.1.22>;epid=395FFF507A;tag=e58e617337
TO: <sip:412@192.168.1.16>;tag=as3b03031d
A válasz az Asterisktől:
SIP/2.0 202 Accepted
SIP/2.0 481 Call leg/transaction does not exist
Nincs meg a lába azt mondja. Nahát :) Utánanéztem a SIP doksiban, a REFER úgy működik, hogy nem a PBX ( telefonközpont ) kezeli le a hívásátirányítást közvetlenül. Az a kliens, aki át akarja irányítani a hívást megkéri a a proxy-t, hogy szóljon a másik kliensnek, hívja fel azt a számot, ahova a hívást áttettük. Ennek az az előnye a hagyományos hívás átadáshoz képest, hogy egyrészt a hívott azt látja hívóként, akit átadtak, másrészt nem kell keresztül mennie mindig a sip proxy-n a hívásnak.
Igen ám, de ehhez a sip proxynak - jelen esetben az Asterisk - tudnia kell beszélnie mindkét klienssel közvetlenül. Most kivel beszélget? A Lync Mediation Szerverrel a másik kliensről nem is tud! Tehát ezt a lábat hiányolta!
Ezután már könnyen megtaláltam a Lync doksiban, a trönk konfigurációnál van egy "Enable refer support" néven a Lync Control Panel/Voice Routing/Trunk Configuration alatt van egy jelölőnégyzet. Innen kiszedve a pipát már ment is. ( Ha sietős indítsátok újra a Mediation szolgátatást )
Ilyenkor már normál INVITE-okat küld a Lync és végre működik az átirányítás.
Összegezve: Ha nem certifikált PSTN gateway-t használtok Lync-hez és nem megy a hívásátadás, ki kell kapcsolni az Enable refer support opciót a Trunk Configuration -nál.
Ebbe most futtottam bele, hátha segít valakinek, leírom. Megcsináltuk, hogy a Lync szerverűnk tudjon kommunikálni az MSN-es felhasználókkal is. A részletekre nem térek ki benne van a doksiban, hogyan kell engedélyezni. Kell hozzá nyilvános certificate és a Microsoftnál is kérni kell, hogy állítsák be a domainhez a cég Edge szerverét. A 2011-es MSN klienssel kell működnie a hang és videó hívásnak is, de nem megy rögtön, az alábbi hibaüzenet jelentkezik:
"Cannot complete the call.
There was an encryption mismatch between you and <msn>. Contact your support team with this information."
A probléma az, hogy alapból úgy van beállítva a Lync, hogy csak titkosított hívásokat engedélyez. Ezt kell módosítani a Lync szerveren egy adminisztrátorként indított PowerShellből:
set-csmediaconfiguration -encryption supportencryption
Ezután újra kell indítani a Lync klienset és menni fog az MSN audio/video hívás.
Mégvalami:
Ha fel szeretnétek venni egy msn címet a Lyncbe, a simán beírt cím nem működik, mert akkor federálni szeretne a Lync és nem fog sikerülni. Az esetek többségében a domain nincs beállítva úgy, hogy az MSN legyen az alapértelmezett üzenetküldő. ( Ez érthető )
Ha fel szeretnétek venni a gazsi@freemail.hu címet a Lync-be, akinek MSN-je van, a következőképp lehet:
gazsi(freemail.hu)@msn.com
Rögtön az év első napján kaptam a levelet, hogy megkaptam az MVP címet a Microsofttól. Jól kezdődik az év :)
"Microsoft is pleased to recognize you as a Microsoft Most Valuable Professional for your exceptional contributions and commitment to technical communities worldwide over the past year. Microsoft is happy to present you with the MVP Award as our special way of saying thanks for making a difference. We appreciate your outstanding contributions in Office365 technical communities during the past year."
"Az MVP címet a Microsoft azoknak a szakértőknek ítéli oda, akik elméleti tudásukat és gyakorlati tapasztalataikat önkéntesen és aktívan megosztják a felhasználókkal, a világ különféle online és „offline” közösségeivel.
A Microsoft az 1990-es évek elején indította el az MVP Awards Programot, hogy elismerje a nagyközönség azon tagjainak munkáját, akik idejüket és tekintélyes műszaki szakértelmüket a többi felhasználó megsegítésére, támogatására fordítják. A Microsoft MVP címet azok a szakértők kapták, akik a legkiemelkedőbb teljesítménnyel járultak hozzá az online és ”offline” technikai közösségeken belül elérhető ismeretekhez.
A legtöbb MVP már több mint 15 éves technikai tapasztalatra tekinthet vissza saját szakterületén. A címmel rendelkező szakértők között vannak publikáló szerzők, Microsoft-termékhez kapcsolódó webhely üzemeltetők, nyilvános előadók, oktatók és professzionális fejlesztők is.
Az MVP cím egy évre szól és az előző évi tevékenységek alapján kerül kiosztásra. Meglehetősen sokoldalú szempontrendszer alapján ítélik oda, s Magyarországon a jelöltekkel együtt is kevesebb mint 20 fő rendelkezik ilyen elismeréssel."
update: Megnéztem az MVP oldalon, ez a 3. kiadott Office 365 MVP cím a világon
Bár nem teljesen kapcsolódik a BPOS Office 365-höz, azért megosztom veletek hátha tanulságos, milyen jellegű problémákba lehet belefutni, ha mi állunk neki Lync szervert telepíteni/konfigurálni. Microsoft Online-on jóval egyszerűbb a helyzet csak bekattingatni az admin interfészen, ha esetleg baj van szólni a támogatásnak.
Van nálunk üzemben egy Lync szerver, amit már nagyon gyakran használunk az ügyfelekkel és a Microsofttal is a federáció révén. A federációra lehetőség lesz az Office 365-ben is, Berlinben az oktatáson láttam is, tényleg csak pár kattintás a beállítása az admin interfészen, fel lehet venni a domaineket vagy meg lehet adni, hogy bárkivel/senkivel federálunk és kész.
A helyi szerverre telepített Lync esetén a federációhoz egy Edge szerver kell, ami egy másik gépet igényel, nem lehet a Lync szerverre telepítve. (*) Fel is telepítettem a szervereket a doksi szerint, nem is volt velük baj, a külső elérés és a federáció is remekül működött. Azt kivéve, hogy a beszélgetés vagy alkalmazás megosztás nem működött, ha az egyik felhasználó a belső LAN-on volt a másik pedig valahol NAT mögött (NAT nélkül remekül ment). Még telepítéskor használtam a Microsoft által publikált Lync Protocol Workload Poster -t, amit ajánlok mindenkinek, mert a certificatek és hálózati forgalom elég jól össze vannak foglalva. A hibát okozó esetben nagyon leegyszerűsítve az alábbiak szerint néz ki:
Mivel szerettük volna használni kívülről is a Lync-et, ma este nekiestem megtalálni a hibát. Mielőtt a wireshark-ot előszedtem volna, első dolgom a kliens naplózás beállítása volt. Ez egy jelölőnégyzet az általános opciók között és a user profil Tracing nevű könyvtárába ( pl. c:\users\username\tracing ) teszi a logokat, ez elég részletes, megtaláltam a hibát, de okosabb nem lettem tőle:
12/21/2010|20:46:01.172 1324:1328 TRACE :: CRTCMediaController::OnStreamingEvent[00344780] - 0864F900, event=RTC_ME_STREAM_STOPPED, type=RTC_MT_AUDIO, dir=RTC_MD_CAPTURE, reason=RTC_ME_CAUSE_CONNECTIVITY_CHECK_FAILURE
Nem maradt más hátra nekiestem a Lync Edge Logoknak. Ez akár nagyon részletes is tud lenni, még az adott .c fájl sora is szerepel benne, ahol a hiba előjött. Itt már több infó volt:
TL_ERROR(TM_Tdi) [0]08B8.0514::12/21/2010-20:09:38.732.000000b1 (MediaRelay,ConnectAddrInterface:tdix.c(6958))ConnectAddrInterface: failed to connect, status=c000023c?
TL_ERROR(TM_Tdi) [0]08B8.0514::12/21/2010-20:09:38.732.000000b2 (MediaRelay,ConnectAddrInterface:tdix.c(6966)) Connecting 192.168.001.023-3478 -> 010.000.000.077-3778
192.168.1.23 a Lync edge szerver címe
10.0.0.77 a belső hálózaton figyelő Lync kliensé
Hoppá! A Lync Edge szerver közvetlenül kapcsolódik a klienshez? A probléma megértéséhez tudni kell, hogy az Edge szervernek legalább 2 hálózati kártyája van, az egyik az internetre csatlakozik, a másik a belső hálózatra. Mivel egy gépen az alapértelmezett átjáró csak 1 lehet normál esetben, ezért ez kifele az internet felé kell, hogy mutasson. A másik interfész csak a belső háló egy subnetjét látta, ezen volt a Lync szerver is, viszont a klienshez nem volt útvonala, hiszen a workload ábra alapján nem is kell. A doksiban írtak erről, hogy állítsunk be route-okat kézzel a belső LAN felé, de nálunk nem láttam értelmét, hiszen csak az ugyanazon a subneten lévő lync szerverhez kapcsolódik. Hát nem.
Egy parancs kiadása az edge szerveren megoldotta a problémát és már minden flottul működik:
route add -p 10.0.0.0 mask 255.0.0.0 192.168.1.1
(*) Újdonság a Lync szerveren, hogy a Mediation Gateway-t már rá lehet telepíteni a Lync Pool-ra, egy szerverrel kevesebb kell! Ha federáció is kell a mininum két szerver szükséges a 3 helyett.
Végül a teljes poszter:
Ma publikálták a szolgáltatás leírásokat is, véletlenül rábukkantam:
Office 365 Beta szolgáltatás leírások
Ebben részletesen le van írva melyik szolgáltatás mit fog tudni, majd mazsolázok belőlük.
Ez lesz a neve az új szolgáltatásnak szolgáltatásnak. ( Wave 14 , Union ) Ez gyakorlatilag a 2010-es változatát takarja a szolgáltatásoknak.
Szerintem sem volt szerencsés egy akronímát használni egy a Microsoft számára ilyen fontos termék megnevezéséhez. Főleg ha a egy amerikai számára pl. a BP inkább egy sziktokszó, az olajszennyezés miatt. A link mostantól él.
Frissítés:
- A fő különbség a BPOS-hoz képest, hogy az Office Professional Plus licenc is része a csomagnak.
- Az átállásra minden cégnek 12 hónapja lesz. Ez az egyik fő előnye a felhőnek: a MS végrehajta helyettünk az új verzióra migrációt.
Frissítés2:
- Windows XP Home támogatva lesz, de federáció nélkül
Frissítés3:
- 24$ , 22,75 EUR lesz az ára a teljes csomagnak, a legkissebb csomag 2$
Előfordult már, hogy ügyfelünk kérte, egy bizonyos emailre bejövő leveleket szeretne megkapni külső címre is. Az admin interfészen viszont ilyen funkció nincs, tehát első körben látszólag nem megoldható a feladat.
Több megoldása is van a dolognak, a legegyszerűbb:
Létrehozunk egy új nevet ( contact ) a felügyeleti központban, arra a címre, ahova szeretnénk küldeni a levelet:
Ezután más teendőnk nincs, írni kell a technikai támogatásnak, hogy az adott postaládába érkező leveleket továbbítsák erre a névre (is). A végén az "is"-nek fontos tartalma van, lehet csak továbbítani a levelet és lehet a mailboxban eltárolni és továbbítani.
A másik megoldás, hogy létrehozunk egy terjesztési listát és annak tagjaként vesszük fel a "nevet", de ez csak bizonyos esetekben megoldás. Pl. ebben az esetben nem lehet beállítani a csoportot alap email címnek, más címről fog érkezni a válasz alapesetben.
Az Exchange Online egyik hasznos funkciója, hogy egy webes böngészővel is bármikor elérhető az Outlook Web Access és ezzel a levelezés. Gondolom ezzel nem mondok nagy újdonságot. Ezzel nap mint nap általában nem dolgozik senki, viszont olyankor kell amikor fontos, hogy az irodai környezettől távol is elérje az ügyfél a leveleket. Ilyenkor se irodai laptop se PC nincs a közelben. Ez nem is gond, bármilyen PC-ről, aminek van internet kapcsolata elérhető az OWA. A dokumentáció alapján:
https://mail.emea.microsoftonline.com
Ezzel csak egy a baj: Amikor az ügyfélnek szüksége van rá távol a céges informatikától, erre a címre nem fog emlékezni, mennyivel jobb lenne egy mail.cegnev.hu cím. Baj nincs, egyszerűen létre kell hozni a cegnev.hu DNS-ben egy CNAME rekordot:
mail.cegnev.hu CNAME mail.emea.microsoftonline.com.
Amint ez kész van, rögtön működik a http://mail.cegnev.hu cím. Nem elírás http-vel is megy, ez csak egy átirányítás. Oda kell figyelni a mail.emea.microsoftonline.com. végén lévő pontra, ez a legtöbb DNS szerverben vagy felületen szükséges, ha nem adjuk meg mail.emea.microsoftonline.com.cegnev.hu -ra fog menni az átirányítás.
Egy új szolgáltatást indított a Microsoft, meg tudjuk nézni a szolgáltatások aktuális és múltbeli állapotát. Ez hasznos lehet a hibakaresés elején, hogy vajon az ügyfélnél vagy a Microsoftnál van-e a probléma.
Az európai szerverek elérhetősége alábbi címen érhető el:
https://health.emea.microsoftonline.com
A Current részen az éppen aktuális státusz látható ( amikor betöltöttük az oldalt vagy refresh-t nyomtunk ), az előző napoknál az egész napra vonatkozóan kapunk információt.
Egy valós admin felhasználónevet és jelszót kell megadni bejelentkezésnél.
Találtam egy új képet a Chicagoban található adatközpont konténereinek belsejéről, elég jól néz ki, megosztom veletek. Ami picit megdöbbentett az a hatékonyság. Az egész adatközpontot 45 (!) ember üzemelteti, beleértve a biztonsági őröket és a komplexum üzemetetőit is és persze a takarítókat is. ( Gondolom őket nem engedik a gépek közelébe :) ) Közülük összesen 3 Microsoft alkalmazott... Megdöbbentő.
Ezt még régebben találtam, de ide illik. Dublinban ez a kis erőmű szolgáltat 5,4 Megawattnyi generátor teljesítményt - ami 22 MW-ra bővíthető -, ha esetleg elmenne az áram:
|
A ZOMPUTER vezetője vagyok, rendszermérnök, a kezdetektől, 2009 óta foglalkozom a Microsoft felhőszolgáltatásaival. Több száz ügyfélnél összesen több mint 50 ezer felhasználó felhős bevezetésében vettem részt a világ 25 országában. Rendszeresen tartok felhős előadásokat a partnereknek. 2010 óta vagyok Office 365 MVP, amely címmel a világon 3.-ként tüntettek ki. |
