Se ha liberado una nueva actualización del cliente Lync para móvil, la cual da soporte para Windows Phone 8.1 y corrige algunos errores:
Aquí tenéis el enlace de descarga: Lync 2013 Mobile 5.5.1277.0
Se ha liberado una nueva actualización del cliente Lync para móvil, la cual da soporte para Windows Phone 8.1 y corrige algunos errores:
Se ha liberado la actualización para el cliente Lync de MAC 2011 KB3007876, aquí tenéis el enlace de descarga: http://www.microsoft.com/en-us/download/details.aspx?id=36517. Esta actualización corrige los siguientes errores:
Update enables users to view call history in Lync for Mac 2011
Update for Lync for Mac 2011 enables users to store conversation history on an Exchange server
Location is not displayed in Lync for Mac 2011 when users join a wireless network
Error "One or more selected contacts cannot receive your calls" when you forward calls in Lync for Mac 2011
Delegation relationship is broken after a delegate signs in to Lync for Mac 2011
Computer shutdown is not processed when Lync for Mac 2011 is running
Update implements media resiliency mode in Lync for Mac 2011
Dial pad disappears when a user who is not enabled for EV joins a video conference or a video call in Lync for Mac 2011
Update enables users to interact with a contact from the call history in Lync for Mac 2011
Microsoft ha liberado una nueva actualización acumulativa para Lync 2013 (CU8) (http://www.microsoft.com/en-us/download/confirmation.aspx?id=36820), aquí tenéis el KB de esta actualización
Ahora os toca actualizar, pero siempre siguiendo el procedimiento adecuado: http://support.microsoft.com/kb/2809243
Es posible que estéis pensando en migrar vuestro Exchange, SharePoint o Lync a la nube, y con esto buscáis que vuestros usuarios puedan iniciar sesión en las aplicaciones nombradas con las mismas credenciales de vuestro dominio local. Para ello debéis realizar una serie de pasos antes, uno de ellos es la publicación del AD FS que habéis configurado en alguno de vuestros servidores On-Permises, y si tenéis un Reverse-Proxy (TMG, F5, KEMP, IIS ARR, etc..) debéis realizar una serie de configuraciones las cuales voy a comentaros si utilizáis TMG. Debemos disponer de un certificado digital de una entidad certificadora pública (DigiCert, Verising, Geotrust, etc..), tanto puede ser un certificado con un solo nombre, como SAN o Wildcard, aquí no tenemos problema con el tipo de certificado, lo que sí es que los nombres de dominio que tenga el certificado se deben corresponder con lo que vamos a publicar (lo de siempre vamos) y en base a los UPN que hayamos sincronizado con Office 365 porque harán referencia a los inicios de sesión de los usuarios. Una vez dicho esto, veamos cual sería la configuración del TMG, para ello nos vamos a la consola de administración y con el botón derecho hacemos clic encima de la opción Reglas de Firewall – Nuevo – Regla de Publicación Web
Escribimos uno nombre corto pero descriptivo para la regla de publicación que vamos a crear y pulsamos en Siguiente
Elegimos la opción Permitir y pulsamos en Siguiente
Selecionamos que queremos publicar una única web o un balanceador y pulsamos en Siguiente
Requisito inprescindible es que el servidor web que vamos a publicar sea bajo SSL y pulsamos en Siguiente
Escribimos el FQDN del nombre del servicio a publicar en interno (en mi caso es el mismo que el externo, tratando de tener un criterio único) y pulsamos en Siguiente
Especificamos una ruta del servidor web que vamos a publicar, en este caso escribimos /adfs/* (de tal forma que esta regla solo permitirá la conexión cuando se intente acceder aa /adfs/ y cualquier cosa de aquí en adelante) y pulsamos en Siguiente:
Ahora escribimos el nombre público con el que se publicará el servicio web, de tal forma que el TMG sepa que si le llega una petición con una cabecera adfs.asirsl.com tenga claro que esta es la regla que tendrá que aplicar, y en la ruta igualmente permitimos únicamente las conexiones desde /adfs/ hacia adelante. Si el nombre es diferente al interno es cuestión de que lo pongáis, eso si, este nombre debe tener su registro DNS de Tipo A (o CNAME, pero mejor A) en el servidor DNS externo):
Elegimos el Listener que previamente hemos configurado con el certificado que vayamos a utilizar y pulsamos en Siguiente
Ahora nos toca elegir el tipo de autenticación, debemos escoger No delegación, pero el cliente puede autenticarse directamente y pulsamos en Siguiente
Cómo último paso guiado por el asistente añadiremos al grupo Todos los Usuarios y pulsamos en Siguiente
Y por último pulsamos en Finalizar
Nos quedaria por ajustar varias cosas en esta regla, para ello la buscamos entre las directivas de Firewall, vamos a sus propiedades y configuramos las diferentes opciones tal cual os muestro:
Esto es a modo revisión, porque si lo recordáis esto es justamente lo que hemos configurado con el Asistente
También debemos configurar una cosa más a nivel del protocolo HTTP, para ello pulsamos con el botón secundario de ratón encima del protocolo de la regla de AD-FS 3.0 y pulsamos en Configurar HTTP:
Y desmarcamos las casillas que os muestro en la siguiente imagen:
Ahora sí que podempos aplicar los cambios pendientes en el TMG y si ya tenemos todas las configuraciones preparadas para iniciar sesión en Office 365 con nuestras credenciales de dominio, solo toca probarlo. Para ello nos vamos a https://login.microsoft.com, introducimos nuestro usuario y si estámos federados correctamente automáticamente nos redirigirá la petición a nuestro ADFS para autenticarnos, ahí es cuando entre en juego la regla que hemos creado:
Paso 1: Introducimos el usuario de nuestra organización
Paso 2: El sistema automáticamente nos intenta redirigir a la página de incio que hemos publicado anteriormente (adfs.asirsl.com)
Paso 3: Nos solicitará las credenciales, las introducimos y pulsamos en Aceptar
Paso 4: Ya estamos dentro de Office 365 accediendo con nuestras credenciales de dominio
Sin el momento de conectarnos revisamos el LOG del TMG, veremos las conexiones oportunas y si hemos iniciado sesión correctamente lo podremos ver con claridad:
Como podéis apreciar la publicación es sencilla y rápida, os llevará más tiempo la configuración de la sincronización, preparación del AD y el AD FS que esta regla. Si bien es cierto que esto no es complejo, únicamente debemos cumplir los requisitos previos y funcionará muy bien. Otra cosa es configurar los diferentes servicios con autenticación integrada, entornos híbridos, etc.. pero bueno eso para otro momento.
Espero que os sea de utilidad!!!
Cuando implementamos Lync como nuestra solución de Telefonía, algo que debemos tener en cuenta a la hora de configurar nuestros planes de marcos, directivas, rutas de voz, etc… es saber como queremos enrutar nuestras llamadas salientes si tenemos más de un ITSP. Lo lógico es que si tenemos varios ITSP queramos utilizarlos, bien porque tenemos diferentes costes de llamadas por ITSP, destino de llamada, etc… y por lo tanto debemos optimizar la utilización de los distintos ITSP para no incurrir en costes innecesarios y en caso de que alguno falle tengamos la posibilidad de seguir emitiendo llamadas en base a un criterio determinado. Lo normal sería que sí no tenemos conexión con un TRUNK SIP que hayamos configurado, tenemos que ver la forma de seguir emitiendo llamadas y con un criterio nos permite en todo momento decidir que otros TRUNK SIP utlizaremos. Y no solo cuando tengamos algún TRUNK SIP caído, sino porque queremos y debemos optimizar el gasto de nuestras comunicaciones de Voz. Para ello como sabéis, debemos crear diferentes directivas de Voz aplicadas a nivel Global, Sitio o Usuario, sobre las cuales definiremos en que orden se utilizarán los distintos TRUNK SIP y si lo haremos por balanceo (roound-robin) o por commutación por error.
Lo primero que debemos definir a que nivel vamos a crear nuestra directiva de voz: Global (modificarla más bien, no se puede eliminar), Sitio o Usuario, y debéis analizarlo de la siguiente forma:
Ahora lo que debemos hacer es realizar dichas configuraciones, para ello nos vamos al Panel de Control de Lync – Enrutamiento de Voz – Directiva de Voz y agregamos tantas Directivas de Usuario como necesitamos (en nuestro ejemplo 4). Yo he nombrado las Directivas de Voz de la siguiente forma:
ES: Pais
Llamadas-NMI: Llamadas Nacionales, Móviles e Internacionales
De esta forma solo con ver las directivas ya tengo claro cual es su función, de tal forma que como podéis apreciar tengo una por país:
Si entramos por ejemplo en ES-Lllamadas-NMI veremos que tenemos 4 usos de RTC ya en orden en el que queremos implementar la conmutación por error de alguno de los ITSP configurados en las rutas de cada uno de los usos de RTC que os muestro a continuación. Antes comentaros que los usos de RTC los he nombrado siguiendo el mismo proceso que las Directivas de Voz:
ES: País
RTC: Tipo (podemos quitarlo porque es obvio que es un RTC, pero lo he puesto así para que siempre tengamos claro de que estamos hablando)
Nacionales: Ámbio de la llamada
Si editamos el primer uso de RTC que se corresponderá siempre con el ITSP que está en el mismo pais que el grupo de usuarios al que les asignamos la directiva de voz en donde se encuentra este uso de RTC vemos la ruta que hemos añadido. Antes comentaros que los usos de RTC los he nombrado siguiendo el mismo proceso que las Directivas de Voz y los Usos de RTC:
ES: País
RV: Tipo (podemos quitarlo porque es obvio que es un RTC, pero lo he puesto así para que siempre tengamos claro de que estamos hablando)
Nacionales: Ámbito de la llamada
Si editamos la Ruta asociada esto es lo que veremos, los números permitidos y el troncal asociado:
El número es +34 porque con los Planes de Marcado ya he normalizado siempre la numeración y el troncal único porque no queremos balancearlo a través de varios troncales sin "control" (Round-Robin), sino que queremos gestionar la conmutación por error de forma controlada. Dicho esto y visto las configuraciones de un país, el resto son exactamente iguales solo que en la ruta le cambiamos los números permitos y el tronco asociado que será el de cada país. Con esto los usuarios tendrán una directiva de Voz asignada en la cual tendrán varios usos de RTC asociados en el orden que consideremos adecuado, del tal forma que si un usuarios quiere realizar una llamada y el tronco asociado en su Ruta está caído utlizará el siguiente uso de RTC para tratar de realizar la llamada y así consecutivamente si fallase el otro ITSP hasta recorse todos los usos de RTC disponibles. Si os habéis fijado yo he creado un una única ruta por cada uso de RTC, pero podríamos tener varias rutas una para llamadas Nacionales, Móviles, Internacionales porque cada una tendría un ITSP o SBC difernte para ajustar el coste de la llamada. Yo lo he hecho más simple, mostrando solo la ruta asociada a las llamadas Nacionales, pero vosotros ajustarlo en función de vuestras necesidades. La idea es tener claro el funcionamiento de la conmutación por error y la diferencia con respecto a tener dos o más troncos en una ruta. Con los diferentes Usos de RTC podefinir el orden de utilización y se utilizará la conmutación por error de forma ordenada, cosa que con la utilización de varios troncos asociados a una ruta no sería posible.
Ahora os muestro una capturas de las Microsoft Lync Server 2013 Debugging Tools en donde vemos como una llamada es enviada a un primer tronco y como no está disponible se envía al siguiente que si cursará la llamada:
Lo dicho, si queremos balancear las llamadas configuraremos varios troncos en nuestra RUTA y si queremos conmutación por error configuraremos varios usos de RTC y ajustaremos el orden de cada uno de ellos. En las rutas no podemos elegir el orden de los troncos y en los usos de RTC si podemos ordenarlos en la Directiva de Voz, lo que nos permite definir por donde se enviarán las llamadas.
Por último me gustaria comentaros la idea del primer esquema, que bien podría representar un escenario común en muchas empresas. Tener un escenario de líneas PRI e ITSPs, de tal forma que tengamos una implementación híbrida hasta que finalmente migrásemos toda la compañía a Lync. Para ellos las llamadas externas nacionales se cursarían a través del PRI y los ITSP, pero debemos dar soporte a conectar a los usuarios de teléfono de la IP-PBX con los usuarios de Lync.
Para ello contamos con la siguiente infraestrcutura:
Debemos realizar las diferentes configuraciones antes de configurar las directivas de Voz, Usos de RTC y Rutas correspondientes:
Y lo que queremos lograr es lo siguiente en base a dos criterios básicos (todos los usuarios estarían en el mismo país pero con llamadas Internacionales a cualquier país del mundo): Ahorro de Costes y Disponibilidad
Para las configuraciones de los TRUNK SIP o´Direct SIP aqui os dejo algunos artículos que os pueden ser de interés:
Ahora toca configurar el entorno, desde la conectividad, TRUNK SIP, Planes de Marcado (Reglas de normalización) Directivas de Voz (Usos de RTC, Rutas). Si alguien se anima que deje un comentario en el blog y os ayudo a realizar la configuración necesaria para dar cumplimiento al objetivo principal: Ahorro de Costes y Disponibilidad. Esto podemos plantearlo como un ejercicio práctico que es muy probable que neceiste/quiera un cliente que tiene pensado migrar a Lync toda su infraestructura de Voz, pero que a su vez debe ir integrando Lync poco a poco.
Espero que os sea de utilidad!!!