Már egy ideje izgatottan várom a Lync mobil klienseket. Végre eljött a nap, megjelentek!
Mit is tudnak?
iPone/iPad
Presence, IM, Email Contacts, Enterprise Voice Calls, Voicemail, Dial-Out Conferencing, Call Forwarding
Android
Presence, IM, Email Contacts, Voicemail, Dial-Out Conferencing, Call Forwarding
Wp7
Presence, IM, Enterprise Voice Calls, Conferencing, Call Forwarding
Fontos és nem biztos, hogy elsőre egyértelmű: VOIP támogatás NINCS a szoftverben jelenleg! Lehet, hogy csak azért tartott 10 percig míg ezt felfogtam, mert nem vagyok egy kimondott Lync szakértő.
A Voip hiánya mindenesetre számomra igazán elszomorító. Persze mindent meg lehet magyarázni. Voip Wifin vagy 3G-n nem biztonságos, romlik a hangminőség ha lassú a hálózat, stb. Ez szerintem bullshit. Mindegy, ez van ezt kell szeretni.
Ha tehát valakit a mobil kliensből hívunk Lync hívással, akkor az történik, hogy a Lync szerver visszahív minket mobilon.
Ez 2012-ben (de még 2011-ben is szánalmas)
Ha valaki az asztali Lync klienséből vagy vállalati Lync telefonról hív minket, a hívás telefonhálózaton fog bonyolódni, hiába van mobil kliens a telefonunkon. IM és a presence viszont remekül működik. Kár, hogy szerintem a Chat egy rendkívűl felesleges, sőt káros dolog. Biztos öreg vagyok már 🙂
Mobil support telepítés
Lync Mobil Support élesítéséhez először is telepíteni kell az UC4-es javítást:
Lync Cumulative Update (CU4)
DNS
internal (lyncdiscoverinternal.domain.local)
Ha van akkor a a directorra vagy pool-ra, ha nincs, akkor a front-end szerverre vagy pool-ra mutat (cname)
external (lyncdiscover.domain.hu)
A reverse proxy szerverre pontosabban az itt publikált director szerverre vagy pool-ra mutat.
Ez elvileg az external web access FQDN.
Új Mobility web szerver portok
Belső mobility web szerver port beállítás:
Set-CsWebServer –Identity lync.domain.local -McxSipPrimaryListeningPort 5086
Külső mobility web szerver port beállítás:
Set-CsWebServer –Identity lync.domain.local-McxSipExternalListeningPort 5087
Topologia publikálás:
Enable-CsTopology –verbose
MCX szolgáltatás telepítése
Letöltés itt
Először telepíteni kell a dinamikus tömörítés IIS feature-t
ServerManagerCMD.exe –Install Web-Dyn-Compression
IIS7 esetén van még egy pár teendő:
A C:WindowsSystem32inetsrvconfigapplicationHost.config fájban
rá kell keresni erre: <Add name=”CSExtMcxAppPool
és be kell szúrni utána ezt:CLRConfigFile=”C:Program FilesMicrosoft Lync Server 2010Web ComponentsMcxExtAspnet_mcx.config” (a > jel elé)
aztán ez:<Add name=”CSIntMcxAppPool” után
ezt: CLRConfigFile=”C:Program FilesMicrosoft Lync Server 2010Web ComponentsMcxIntAspnet_mcx.config”
7.5ös IIS használatakor a telepítő automatikusan beállítja ezt is
MCX telepítés:
A McxStandalone.msi fájlt be kell másolni a C:ProgramDataMicrosoftLync ServerDeploymentcache4.0.7577.0setup mappába majd elindítani a C:Program FilesMicrosoft Lync Server 2010DeploymentBootstrapper.exe
(Ez mondjuk nekem fájt… Kb olyan mintha egy beta programot telepítenék.)
Tanúsítványok frissítése (cseréje)
A director és a front-end szervereken lévő tanúsítványok alternate nevei között szerepelni kell a két új FQDN-nek (lyncdiscoverinternal.domain.local,lyncdiscover.domain.hu)
Új tanúsítványt készíteni a legegyszerűbb a Lync deployment wizard segítségével.
ISA, TMG (reverse proxy)
A reverse proxy szerveren át kell alakítani a meglévő szabályt, vagy készíteni kell egy új szabályt ami hallgat az új autodiscover FQDN-re.
A cél port : 8080 és 4443
Tesztelés:
Management shell.
Test-CsMcxP2PIM -TargetFqdn <FQDN of Front End pool> -SenderSipAddress sip:<SIP address of test user 1> -SenderCredential <test user 1 credentials> -ReceiverSipAddress sip:<SIP address of test user 2> -ReceiverCredential <test user 2 credentials> –v
Szívások és egyebek.
A tanúsítványok frissítése és egyéb körülmények remekül megfektette a külső klienseket.
az edge szerveren az alábbi hibával lett tele az eseménynapló:
The certificate received from the remote server has not validated correctly. The error code is 0x80096004. The SSL connection request has failed. The attached data contains the server certificate.
Miért is?
Az edge szerver ugye nincs domain-ban. A cert szerveren meg pont a napokban frissítettük a CA cert-et.
Következmény: ad edge szerver nem bízott a director új tanúsítványában.
Megoldás: Importálni kell az érvényes root CA tanúsítványt az edge szerver (computer account) Trusted Root Certificate Authorities -ba.
Can’t connect to Exchange Web Server.
Rövid válasz: nem is fog 🙂
Kicsit pontosítok. Ha ilyesmi van a kliens mobil logjában: 0x80072f06, akkor szívás van.
A Lync mobil kliens nem támogatja a wildcard tanúsítványok (*.valami) használatát, még az Exchange szerveren sem. Tehát ha az Exchange szerveren ilyet használunk, akkor fáradhatunk el a legközelebbi szolgáltatóhoz és vehetünk egy új tanúsítványt. Persze a régit sem lehet kidobni. Minek is vesz az ember wildcard tanúsítványt? Ja igen, sok helyen használja ugyanazt mert így olcsóbb. Na ennek is lőttek.