Az áprilisi Office frissítéssel elérhető a Lync új változata, a Skype Vállalati verzió (Skype for Business). A működési szempontból nem sok változás történt, de a felhasználói felületen annál több. Az Office 365 szerver oldali részét a Microsoft frissíti legkésőbb május végéig. Akinek felhős telepítésű Lync kliense van, hamarosan megkapja a frissítést.
Az újdonságok:
Kimenő hívás esetén kicsörög a hívó asztali telefonja és a szerver kapcsolja a hívott felet. Skype for Business 2015 szerver szükséges hozzá.
Kereshetőek a Skype felhasználók
A hívás egy kicsinyített ablaka a többi felett látszik
Jelezhetjük a hívás minőségét a rendszergazdáknak
A tárcsázó és hívás kezelő gombok könnyebben elérhetőek
Helyi Lync szerver esetén a program a régi kinézetű lesz, akkor is, ha feltelepítjük az új vállalati verziót:
Ebben az esetben van még teendőnk a Lync szerver oldalon, de nem kötelező Skype for Business szerverre frissíteni. Először a következő frissítésekre van szükség:
Lync Server 2010 - February 2015 Cumulative Update (4.0.7577.710) for Lync Server 2010
Lync Server 2013 - December 2014 Cumulative Update (5.0.8308.857) for Lync Server 2013.
A kliens megjelenését a rendszergazdák beállíthatják vagy registry beállítással (GPO-ból is) vagy kliens házirenddel. A részletek megtalálhatóak itt és itt.
Az alábbi PowerShell paranccsal átállítható az egész szervezetben a megjelenés ( azoknál a felhasználóknál, ahogy a Global házirend aktív ):
Set-CsClientPolicy -Identity Global -EnableSkypeUI $true
Ezt követően a felhasználók az alábbit tapasztalják:
Felírom magamnak is, hogy később emlékezzek rá, frissítések után a Lync szerveren előfordul, hogy a Enable-CSTopology parancs hibával fut le:
Get Forest State
Warning: Ace DOMAIN\RTCUniversalGlobalReadOnlyGroup; Allow; ReadProperty; None; None
Warning: One or more group access control entries (ACEs) are not ready.
Ilyenkor a megoldás a Forest prep újra futtatása. Sajnos ez már csak PowerShellből fog menni, figyeljünk oda, hogy a megfelelő AD jogosultságokkal rendelkező felhasználóval futtassuk a Lync Server Management Shellből a következő parancsot:
Enable-CsAdForest
Egy ügyfélnél üzemeltük be a Lync-et és elkezdték használni a konferencia szolgáltatást is. A Lync Attendee kliens való arra, hogy akinek nincs Lync kliense, hozzá tudjon kapcsolódni egy konferenciához, amit egy cégen belülről - ahol van Lync infrastruktúra - indítottunk. Tipikusan egy külső cég, ahhonnan hozzá szeretnének a konferenciához csatlakozni. Az Attendee kliens felhasználói (user level) változatának telepítéséhez nincs szükség rendszergazdai jogra.
Az ügyfélnél jelezték, hogy nem működik az egyik partnerüktől a csatlakozás és nagyon fontos lenne.
Alapesetben a Lync Attendee közvetlenül próbál kapcsolódni, ha ez nem sikerül az IE proxy beállításait használja és úgy csatlakozik. Ebben az esetben azért nem működött, mert a proxy authentikációt használtak a partnernél és ez nem támogatott. A kerülő megoldás az lett, hogy kivételt kellett definiálni a proxy szerverben: a sip.microsoft.com címre ne kérjen a proxy authentikációt.
Sokáig kellett rá várni, de a Microsoft végre kiadta a Lync 2010 Resource Kit-et, ami fejezetenként letölthető az alábbi képre kattintva:
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
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:
|
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. |
