Microsoft Lync Server
Header

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:

  • Global: Cuando todos los usuarios de Lync residan en el mismo país, puesto que todos utilizarán los mismos ITSP
  • Sitio: Cuando tenemos varios sitios configurados en el mismo o distintos país y que además tengamos diferentes ITSP o TRUNK SIP con Gateways locales, puesto que tendrán posiblemente configuraciones diferentes
  • Usuario: Cuando tengamos diferentes usuarios en diferentes países o usuarios habilitados para llamadas internacionales o tarificaciones adicionales  que no todos los usuarios deben tener.
Una vez que tengamos esto definido, debemos crear las directivas de voz correspondientes, para posteriormente crear los diferentes usos de RTC. En los usos de RTC es donde vamos a definir como se gestionarán las llamadas salientes. Debemos crear diferentes usos de RTC en función del tipo de llamada (Nacional, Internacional, Móviles, etc..) y luego definir el TRUNK SIP (que se corresponderá con cada ITSP o conexión con el SBC correspondiente) por el cual enviaremos las llamadas en base a la configuración de las rutas que hemos configurado.  Cada uso de RTC debe ser lo más específico posible, de tal forma que tengamos identificado de forma clara solo con ver el nombre del Uso de RTC tengamos claro que tipo de llamada se realizarán por cada uno. Luego en cada ruta definiremos por que TRUNK SIP enviaremos las llamadas, y aquí es donde debemos hacer especial hincapié. En este artículo me centraré en como debemos impletar las directivas de voz, usos de RTC y Rutas para enviar las llamadas vía los TRUNK SIP.  Además de mostrar como se pueden tener varios TRUNK SIP en una misma directiva de Voz asociando uno o varios usos de RTC. Los usos de RTC nos permiten enlazar las directivas de voz con las rutas, y las rutas es donde definimos la numeración que permitiremos y los TRUNK SIP que se utilizarán. Por ejemplo, podemos tener una Directiva de Voz para los usuarios de España, que tenga dos usos de RTC, uno para llamadas Nacionales (ITSP1) y otro uso de RTC para llamadas Internacionales (ITSP2), y cada uso de RTC tiene sus rutas en donde definiremos los números permitidos para llamar con su TRUNK SIP asociado. De tal forma que cuando un usuario de Lync llame a un número nacional utilizará el ITSP1 y cuando marque un número de ámbito internacional la llamada se cursará vía ITSP2. Ahora bien, si queremos implementar un sistema tolerante a errores en cuanto al ITSP o un sistma de balanceo de tipo round-robin en cuanto al TRUNK SIP que hemos configurado para cada ITSP. Esto es muy interesante si tenemos varios ITSP para cursar nuestras llamadas y queremos que en el caso de uno de ellos esté caido podamos utilizar otros de los que tengamos configurados. Pero también es cierto que queremos poder balancear las llamadas a través de varios ITSP que para nosotros son los TRUNK SIP configurados en cada ruta que hemos asignado a los usos de RTC que estos a su vez se aginan a cada directiva de Voz (Global, Sitio o Usuario).
 
Una vez dicho esto, veamos como podemos configurar estos dos escenarios de manejo de los TRUNK SIP implementando Balanceo (Round-Robin) o Conmutación por error. Para ello he preparado dos esquemas para poder explicarlo con una imagen acorde con cada argumento. Lo primero que veremos será como podemos configurar una directiva de Voz a nivel de usuario, en el cual tendremos un uso de RTC para todo tipo de llamadas (Móviles, Nacionales e Internacionales) porque todos los usuarios están en el mismo país y con un único sitio configurado en la topología. Con esto quiero decir que todos tienen las mismas necesidades de telefonía y ámbito de las llamadas, pero si tenemos varios ITSP a través de los cuales queremos balancear las llamadas salientes, lo haremos de la  y en el caso de que uno de los dos ITSP esté caido se utilice el activo.
 
Routing Failover Trunk Esquema Round Robin.jpg
Este esquema representa un Mediation Server con dos TRUNK SIP (ITSP1 y ITSP2) para los usuarios de España, que tienen asignada una directiva de Voz (ES-Llamadas-ITSP-LB), esta a su vez una ruta de Voz (ES-RTC-NACIONALES-LB) y por último una ruta (ES-RV-NACIONALES-LB) con los dos TRUNK SIP (ITSP1 y ITSP2) para las llamadas nacionales. Aquí tenéis las capturas de pantalla para que podáis ver la configuración comentada, para ello nos vamos al Panel de Control de Lync – Enrutamiento de Voz – Directiva de Voz – Agregar Directiva de Usuario
Routing_Failover_Trunk_10.jpg
Pulsamos en Agregar para crear nuestro uso de RTC en donde asignaremos una única ruta en donde configuraremos los diferentes TRUNK SIP previamente configurados desde el configurador de Topología:
Routing_Failover_Trunk_14.jpg
Ahora debemos agregar una nueva ruta en donde definiremos los números iniciales del número marcado por el usuario que se permitirán en esta ruta, de tal forma que tenga coincidencia con esta ruta. En este caso yo tengo un plan de marcado con varias reglas de normalización para que todos los números marcados por los usuarios los normalice al estándard E.169, de tal forma que siempre que el número se haya normalizado a +34 y el número marcado se aplicará estar ruta:
Routing_Failover_Trunk_15y.jpg
Por último en esta ruta debemos añadir los troncos (TRUNK SIP) que hemos configurado previamente en la topología:, para ello pulsamos en Agregar
Routing_Failover_Trunk_16y.jpg
Ahora debemos elegir los troncos (TRUNK SIP) que queremos utilizar en esta ruta
Routing_Failover_Trunk_8.jpg
Ahora como vemos tenemos los troncos (TRUNK SIP) asociados a esta ruta, ojo!! los troncos no se pueden cambiar de orden desde aquí, si queremos cambiarlos de orden debemos volver a agregarlos en el orden que queramos. De todas formas, si agregamos más de un tronco aquí se utilizarán como balanceo de tipo Round-robin (esa es la idea):
Routing_Failover_Trunk_17.jpg
Con esto ya tenemos lo que queríamos, tener varios troncos asociados en una misma ruta la cual está asociada al uso de RTC añadido a nuestra política de voz. De esta forma los usuarios a los cuales le apliquemos esta configuración tendrán tres troncos (TRUNK SIP con distintos ITSP o Gateways) para cursar llamadas utilizándose de forma alterna. Aquí os dejo una prueba de tres llamadas a destinos nacionales y cada uno se ha cursado en un tronco diferente, si hubiese una carta o n llamadas se realizarían utilizandos vía round-robin los tres troncos asociados a nuestra ruta:
 
Llamada 1: Tronco 195.x.x.x
Routing_Failover_Trunk_11.jpg
Llamada 2: Tronco trunkcme.asirsl.com
Routing_Failover_Trunk_12.jpg
Llamada 3: Tronco 195.x.x.x (porque el 192.x.x.x lo había desconectado manualmente para poder apreciar el funcionamiento)
Routing_Failover_Trunk_13.jpg
 
En este caso como habéis podido apreciar, tenemos tres troncos configurados en nuestra RUTA y que se utilizarán utilizando round-robin. En el caso de que no esté disponible alguno de ellos, el sistema utilizará de igual forma el resto de troncos. Por lo que si queremos balancear las llamadas a través de varios troncos (TRUNK SIP) esta es la forma de  hacerlo, una Directiva de Voz – Uso de RTC – Ruta (con varios troncos). El "problema" que tiene este sistema es que no podemos definir porque tronco saldrán las llamadas, los utilizará todos y además en el orden que le toque. Depende del escenario que vayamos a desplegar será o no el correcto, pero desde luego para balancear la carga de llamadas a través de varios ITSP, SBCs, etc.. es la forma de hacerlo.
 
Ahora vamos a ver como podemos configurar un sistema de llamadas tolerante a errores de algún TRUNK SIP que tengamos configurado. Imaginaros que tenemos una implementación de Lync de ámbitos internacional y que tenemos usuarios de varios paises pero con una sola implementación de Lync con un único sitio (gestión centralizada de las llamadas). Configuraremos distintas políticas de Voz , usos de RTC y Rutas "principales" para cada país. En cada país hemos contratado un ITSP (no haría falta obligatoriamente que fuese así, pero esto es otro debate) para ajustar el coste de la llamada nacional a cada país. Pero además, lo que queremos es que los usuarios nunca se queden sin poder cursar llamadas aunque para eso en determinados momentos tengamos que utilizar el ITSP de otros páis. Os recuerdo que esto es un ejemplo forzado, más lejos de la realidad de un entorno de buenas prácticas de diseño de elección de los ISTP, Sitios de Lync, etc. es simplemente para ver de forma clara la utilización de los Usos de RTC y Rutas para loas directivas de Voz de Lync para un sistema de conmutación por error de los ISTP. Dicho esto, aquí os dejo un esquema de un Mediation Server con los 4 TRUNK SIP (España, Francia, Inglaterra y Argentina) (pulsar en la imagen para verla a tamaño completo):
 
Routing Failover Trunk Esquema Failover.jpg
La idea es que para los usuarios de cada país el ITSP que primero utilicen sea el de su país y luego en orden descendente y por cercanía geográfica el resto de ITSPs del resto de paises. De tal forma que un usuario de España primero utilizará el ITSP1, luego el 2 (Francia), 3 (Inglaterra) y 4 (Argentina) y para el resto de usuarios del resto de países más de lo mismo invirtiendo el orden:
 
Routing Failover Trunk Esquema Failover 1.jpg
Para implementar esta configuración debemos hacer lo siguiente:
  1. Crear una directiva de voz para usuarios
  2. Crear un uso de RTC
  3. Crear una RUTA con el tronco del ITSP del país de los usuarios
  4. Añadir en el orden correcto el resto de usos de RTC del resto de directivas de voz asignadas a los usuarios de los diferentes países

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:

Routing Failover Trunk_2.jpg

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

Routing_Failover_Trunk_4.jpg

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

Routing_Failover_Trunk_5.jpg

Si editamos la Ruta asociada esto es lo que veremos, los números permitidos y el troncal asociado:

Routing_Failover_Trunk_6.jpg

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:

Routing_Failover_Trunk_1.png
Este tema es muy amplio y cada diseño se tendrá que ver con mucho detenimiento para no incurrir en costes de llamadas innecesarios y para obtener un sistema de conmutación por error o balancear las llamadas a través de varios ITSP. Recordad que si implantamos un sistema de Conmutación por Error, solo se pasará al siguiente uso de RTC si la llamada no se puede cursar por la ruta del primer RTC. Pero eso no quita también que podemos tener un sistema de conmutaciónp por error combinado con un sistema balanceado. Para ello tendriamos que configurar los usos de RTC que necesitemos y ordenarlos según nuestras preferencias y en las rutas asociadas  a cada RTC podríamos tener más de un tronco asociado. De esta forma tendríamos lo mejor de las dos configuraciones, y es posible que en muchos casos fuese lo más acertado. Porque de esta forma tendríamos varios troncos para cada país (siguiente con el ejemplo de este artículo), por lo que tendríamos redundancia de tronco, pero en el caso de que todos los troncos no estuviesen disponibles se utilizarán otro Uso de RTC de otro país. Si bien es cierto que si esa fuese la configuración, los troncos deberían ser de diferentes ITSP para obtener redundancia total y que los costes fuesen iguales, porque pensad que no podemos definir porque tronco se cursarían, porque a nivel de RUTA los troncos utilizan Round-Robin (se alternan las llamadas salientes).
 

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.

Routing Failover Trunk Esquema.jpg

Para ello contamos con la siguiente infraestrcutura:

  • 1 Mediation Server
  • 1 SBC
  • 1 Gateway
  • 1 IP-BPX
  • Varios ITSP

Debemos realizar las diferentes configuraciones antes de configurar las directivas de Voz, Usos de RTC y Rutas correspondientes:

  • Trunk SIP entre Lync y el ITSP1
  • Trunk SIP entre el SBC y el ITSP2
  • Trunk SIP entre el Gateway (Cisco en este caso) y el ITSP3
  • Direct SIP entre el SBC y la IP-PBX
  • Direct SIP entre el Gateway y la IP-BPX (podrías ser también con H.323)
  • Direct SIP entre el Gateway y el Mediation Server
  • Direct SIP entre el SBC y el Mediation Server

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

  • Realizar llamadas externas a través de los 3 ITSP (ITSP1, ITSP2, ITSP3), para ello utilizaremos conmutación por error (varios usos de RTC y Rutas con un solo tronco)
  • Comunicar a los usuarios de Lync con los usuarios de la IP-PBX, primero a través del SBC y si falla a través del Gateway
  • Las llamadas a números nacionales se realizarán a través de la IP-PBX, puesto que tenemos una tarifa plana donde no tienen coste este tipo de llamadas , pero en el caso de que falle se tendrán que cursar a través de los ITSP (orden: ITSP1, ITSP2, ITSP3)

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!!!

Nueva actualización del Esquema de Lync por excelencia en cuanto a los servicios, puertos, registros dns, etc… muy muy bueno!!​

Lync_2013_poster_Octubre_2014.jpg
 
Aquí os dejo lo documentos para que podáis descarglo en formato PDF o Visio:
 

 

Seguro que os será de utilidad!!!

Microsoft ha liberado nuevas actualizaciones de software para teléfonos IP de Lync:

Microsoft® Lync™ Phone Edition for Polycom® CX500, Polycom® CX600 and Polycom® CX3000 is the first generation of software designed specifically for the phones from Polycom to interoperate with Microsoft® Lync™ Server…
 
Microsoft® Lync™ Phone Edition for Aastra 6721ip and Aastra 6725ip is the first generation of software designed specifically for the phones from Aastra to interoperate with Microsoft® Lync™ Server 2010 or Microsoft® …
 
Microsoft® Lync™ Phone Edition for HP 4110 and HP 4120 is the first generation of software designed specifically for the phones from HP to interoperate with Microsoft® Lync™ Server 2010. and Microsoft® Lync™ Server 2013…

 

Algo que me ha gustado desde siempre en Windows Phone era la posibilidad de anclar contactos en la pantalla de inicio, de tal forma que si son contactos frecuentes puedo directamente abrir una conversación pulsando en el icono correspondiente:

Live Tiles de Lync -17.jpgLive Tiles de Lync -18.jpg

 

Y claramente esto lo quiero hacer en Windows 10, ahora que el menu de inicio se ha rediseñado nuevamente y me parece muy útil tener el contacto disponible desde el menú inicio. Voy a empezar por el final para que os déis cuenta de lo que quiero tener:
 
Live Tiles de Lync -12.png
 
La idea es pulsar en el botón de inicio y a un solo clic tener disponible una sesión de mensajería instantánea con un usuario, varios o una llamada de teléfono (llamadas frecuentes). Para ello lo que haré será crear varias accesos directos utilizando parámetros de la línea de comandos que iniciarán Lync según se requiera. Aquí os expongo primero una lista de los comandos disponibles:
 
Extensión Formato de datos Acción
tel:
URI de tel.
Abre la ventana Conversación para una llamada de audio pero no marca el número especificado.
callto:
tel:, sip: o URL de tel que se puede editar
Abre la ventana Conversación para una llamada de audio pero no marca el número especificado.
sip:
URI del SIP
Abra la ventana Conversación con el Identificador uniforme de recursos (URI) del SIP especificado en la lista de participantes.
Sips:
URI del SIP
Si Lync 2013 está configurado para usar el protocolo de seguridad de la capa de transporte (TLS), funciona exactamente igual que sip:. Si no está usando TLS, muestra un cuadro de diálogo para informar al usuario de que se requiere un nivel de seguridad más alto.
conf:
URI del SIP de la conferencia a la que se va a unir
Si el URI es automático, crea instancias del foco y solo abre una vista de la lista. En caso contrario, abre una vista de la lista pero no envía INVITE.
 
im:
URI del SIP
Muestra la ventana Conversación solo de mensajería instantánea con el URI del SIP. Acepta varios URI del SIP especificados entre corchetes angulares de apertura y cierre (<>) sin ningún separador.

Pues ahora que ya tenemos claro lo que queremos, vamos ello. Lo primero es que vamos a crear los accesos directos que queramos en la siguiente ubiación %USERPROFILE%\AppData\Roaming\Microsoft\Windows\Start Menu\ de tal forma que luego podamos buscarlos y asignarlos al inicio. Lo primero nos vamos a la carpeta en cuestión y creamos los siguientes accesos directos: 

  • Mensajería Instantánea con un usuario: sip:UR del SIP
  • Mensajería Instantánea con varios usuarios: sip:<URI del SIP><URI del SIP>
  • Una llamada de teléfono a un número especificado previamente: tel:URI del Teléfono
Veamos como crearíamos los acceso directos para cada uno de los ejemplos que os comento:
 
Mensajería Instantánea con un usuario
Live Tiles de Lync -3.png
Mensajería Instantánea con varios usuarios:
Live Tiles de Lync -7.png

Una llamada de teléfono a un número especificado previamente 

Live Tiles de Lync -6.png

En cada acceso directo solo tenemos que especificar la línea de comandos y por último escribir el nombre con el que lo queremos identificar y pulsar en Finalizar

Live Tiles de Lync -4.png

Ahora ya tenemos nuestros tres acceso directos a los servicios comentados:

Live Tiles de Lync -5.png
Si ejecutamos cada uno de ellos nos abrírá las distintas ventanas con la mensajería instantánea o la llamada de teléfono:
 
Mensajería Instantánea con un usuario 
Live Tiles de Lync -18.png
Mensajería Instantánea con varios usuarios: 
Live Tiles de Lync -8.png
 
Una llamada de teléfono a un número especificado previamente  
Live Tiles de Lync -1.png
 
Ahora bien, nos queda tenerlo en el menu inicio, para ello pulsamos la tecla Windows del equip y buscamos los ficheros que hemos creado:
 
Live Tiles de Lync -10.png
Y ahora vamos añadiendo los iconos al inicio pulsando con el botón secundario del ratón encima de cada uno de ellos y pulsamos en Pin to Start
Live Tiles de Lync -11.png
Y ya tenemos nuestros iconos disponibles en el menú de inicio
Live Tiles de Lync -12.png
 
Desde aquí ya podemos cambiar el tamaño de los iconos, moverlos o eliminarlos cuando queramos
Live Tiles de Lync -13.png

Y por último si queremos cambiar el icono que nos muestra, simplemente vamos al acceso directo y se lo cambiamos, para ello vamos a las propiedades del acceso directo y pulsamos en Change Icon …

Live Tiles de Lync -14.png
y elegimos el icono que queramos aplicar ..
Live Tiles de Lync -15.png
Y con esto ya tenemos nuestros iconos preferidos en los accesos directos de Lync
Live Tiles de Lync -16.png
Aquí os dejo el enlace de Microsoft en donde podéis encontrar la información sobre los parámetros de la línea de comandos de Lync 2013: http://technet.microsoft.com/es-es/library/gg398376.aspx
Espero que os sea de utilidad!!!

Como sabréis Google ayer anunció que había un problema de seguridad que afecta al protocolo SSL 3.0, como bien describe en el siguiente artículo:

Vulnerabilidad en el Protocolo SSL 3.0.JPG

Dicha vulnerabilidad se llama POODLE y aquí tenéis un PDF en donde biene correctamente descrita la vulnerabilidad: https://www.openssl.org/~bodo/ssl-poodle.pdf . Esto afecta a todas las implementaciones en donde utilicemos SSL 3.0, algo que como bien indica ya no se debería utilizar puesto que ya un protocolo muy antiguo con más de 15 años. Si trabajáis con IIS, TMG u otro serivicio que utilice SSL deberíais deshabilitar el uso de SSL 3.0, para ello debemos crear las siguientes claves de registro en los servidores afectados y reiniciarlos para que se hagan efectivos los cambios. Antes de ponernos manos a la obra podéis verificar si vuestro servicio está afectado o no por este problema, para ello podéis acceder a la siguiente web y especificar vuestras URLs: http://www.poodlescan.com/. Si vuestra web tiene habilitado SSL 3.0 o 2.0 os lo indicará, mirar este ejemplo en donde lo he habilitado a propósito para poder ver la advertencia que nos muestra:
 Vulnerabilidad en el Protocolo SSL 3.0 -1.JPG
En el caso de que el servicio no estuviese afectado, nos mostraría la siguiente pantalla:
Vulnerabilidad en el Protocolo SSL 3.0 -2.JPG
Si resulta que en nuestro servidor utilizamos SSL 3.0 debemos crear las siguientes claves de registro para deshabilitarlo:
 
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client]
"DisabledByDefault"=dword:00000001
Vulnerabilidad en el Protocolo SSL 3.0 -3.jpg
 
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server]
"Enabled"=dword:00000000
Vulnerabilidad en el Protocolo SSL 3.0 -4.jpg
Es posible que también tengáis habilitado el SSL 2.0, pues lo deshabilitaremos de la misma forma, creando una clave en el registro:
 
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client]
"DisabledByDefault"=dword:00000001
Vulnerabilidad en el Protocolo SSL 3.0 -5.jpg
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client]
"Enabled"=dword:00000000
Vulnerabilidad en el Protocolo SSL 3.0 -6.jpg

Por último debemos reniciar el servidor para completar el proceso, de tal forma que nuestro servidor no sea vulnerable por POODLE. Comentaros que si tenemos un Proxy Inverso (TMG, IIS ARR, etc..) podemos realizar este cambio únicamente en servidor y ya quedaríais igualmente protegidos, aunque lo suyo sería también configurar de forma manual los servidores que publicamos a través del proxy inverso. Las claves de registro para el TMG serían las mismas que las anteriores, pero a mayores debemos configurar las siguientes claves (más información: http://www.isaserver.org/articles-tutorials/configuration-security/improving-ssl-security-forefront-threat-management-gateway-tmg-2010-published-web-sites.html):

 
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\SecurityProviders\SCHANNEL\AllowInsecureRenegoClients]
"Enabled"=dword:00000000
 
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\SecurityProviders\SCHANNEL\DisableRenegoOnServer]
"Enabled"=dword:00000001
Vulnerabilidad en el Protocolo SSL 3.0 -7.jpg
Una vez establecidos estos valores (y los de deshabilitar SSL 3.0) reiniciamos el servicio de Firewall del TMG y ya quedaría correctamente protegido. Mirad el antes y después de una análisis desde la utilidad de DigiCert Certificate Agent (utilidad que nos permte analizar de forma remota los certificados instalados en nuestros servidores):
 
TMG con SSL 3.0 HABIILTADO
Vulnerabilidad en el Protocolo SSL 3.0 -8.jpg
TMG CON SSL 3.0 DESHABILITADO Y CON TLS 1.0 (SI ES POSIBLE DESHABILITARLO TAMBIÉN), 1.1 y 1.2 HABILITADO
Vulnerabilidad en el Protocolo SSL 3.0 -9.jpg
Si queremos habilitar o deshabilitar TLS en los servidores, podemos hacerlo de la misma forma que hemos hecho con el SSL 3.0 pero con las claves adecuadas para TLS:

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client]
"DisabledByDefault"=dword:00000000
 Vulnerabilidad en el Protocolo SSL 3.0 -11.jpg
 
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server]
"Enabled"=dword:00000000
Vulnerabilidad en el Protocolo SSL 3.0 -11.jpg

Y así todo igual con las versiones TLS 1.1 y TLS 1.2 :

 

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client]
"DisabledByDefault"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server]
"Enabled"=dword:00000000

 
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
"DisabledByDefault"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
"Enabled"=dword:00000000
 

Aquí os dejo los ficheros .reg en función de lo que queráis deshabilitar:

SSL 2.0 para IIS: Deshabilitar SSL 2.0.zipDeshabilitar SSL 2.0.zip

SSL 3.0 para IIS: Deshabilitar SSL 3.0.zipDeshabilitar SSL 3.0.zip

SSL 3.0 en TMG (opciones de seguridad a mayores): Deshabilitar SSL 3.0 en TMG.zipDeshabilitar SSL 3.0 en TMG.zip

En la web de DigiCert tenéis información suficiente también sobre este tema, por lo que no dejéis de visitarla: https://blog.digicert.com/sslv3-vulnerability-poodle/?mkt_tok=3RkMMJWWfF9wsRokuq7JZKXonjHpfsX56ekqW6S0lMI%2F0ER3fOvrPUfGjI4DScdgI%2BSLDwEYGJlv6SgFQrLAMbdw0bgKXRA%3D Aquí encontraréis información de como deshabilitar SSL 3.0 para IIS, Apache y Nginx:

IIS: https://www.digicert.com/ssl-support/iis-disabling-ssl-v3.htm

Apache: https://www.digicert.com/ssl-support/apache-disabling-ssl-v3.htm

Nginx: https://www.digicert.com/ssl-support/nginx-disabling-ssl-v3.htm

DigiCert ha puesto a disposición de lo miembros registrados una utilidad para verificar nuestros servidores con SSL: Certificate Inspector, desde la cual escribimos el FQDN de nuestro servidor y lo chequerá en línea mostrando más información que si únicamente tenéis SSL 3.0 habilitado en vuestro servidor. 

Espero que os sea de utilidad!!!