Migráció .pst fájlból

Egy partner keresett meg a kérdéssel, hogyan lehet a legegyszerűbben .PST fájból importálni BPOS-ba a leveleket. A válasz nagyon egyszerű.

Amikor a Sign in klienset telepítjük és konfiguráljuk az Outlookot, akkor a régi Outlook profilt a kliens megtartja és létrehoz egy új profilt a BPOS-hoz. Átállítja úgy az Outlookot, amennyiben nem a Sign In kliensből indítjuk, akkor rákédezzen a használni kívánt profilra. Alapból az Outlook egy Outlook nevű profilt hoz létre, a Sign In kliens pedig a bejelentkezési nevet adja meg profil névként.

A művelet a következő:
- Az Outlookot úgy indítjuk, hogy a BPOS-be jelentkezzen be
- File/Open/Import/Import from another program or file/Outlook Data file (.pst)    
  (Fájl/importálás és exportálás/Importálás másik programból/Outlook adatfájl vagy valami hasonló magyarul)
- Ezután mutassunk rá a .pst fájra és ennyi. Az Outlook gyorsan betölti helyben az .ost fájlba a tartalmat és közben el is kezdi szinkronizálni a szerverre

Gyors és egyszerű, kb 20 felhasználóig ez a legjobb mód. Ráadásul maga az importálás nagyon gyors, a szinkronizálás később megy a háttérben és a felhasználó rögtön eléri az összes levelét. Arról nem is beszélve, hogy csak egyszer teszik meg - felfelé - az adatok a felhőben az utat. A többi migrációs megoldásnál felköltöznek az adatok a felhőbe, utána pedig az Outlook letölti.

Outlook file import BPOS .pst

Office 365 közösségi oldal

Eddig csak azoknak volt eléhető, akik rendelkeztek privát béta eléréssel, vagy nekünk MVP-knek, de ezentúl mindenki számára nyitott az Office 365 közösségi oldal, ahol a partnerek és ügyfelek is, tudnak egymásnak segíteni a problémák megoldásában. A blogok, a fórum, a wiki oldalak mindenki számára elérhetőek és sok hasznos információt tartalmaznak.

Ingyenes Blackberry szolgáltatás az Exchange Onlinehoz

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

Nyilvános az Office 365 béta, elkezdték kiküldeni a meghívókat

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. 

Lync web app kikényszerítése Lync konferenciához való csatlakozáskor

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

Lync Web Client

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.

Lync Workload poster javítva

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

Lync Edge Server Workload Poster

Lync hívás átadás

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:

Lync Asterisk Refer

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.

Lync hanghívás és videóhívás MSN-el

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

MVP lettem

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

MVP Logo

"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

Lync Edge Szerver

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:

Lync workload

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:

Office 365 Beta szolgáltatás leírások

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.

Office 365

Office 365

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.

www.office365.com

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$

Tipp: Levél továbbítás külső címre

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:

BPOS New contact új név

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.

Tipp: Könnyen megjegyezhető Outlook Web Access cím, mail.cegnev.hu

Outlook Web Access Microsoft Online

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.

Health Dasboard

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

Microsoft Online health dasboard

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.

Tartalom átvétel