Microsoft Lync Server
Header

​Vodafone y Microsoft han llegado a un acuerdo para integrar las comunicaciones fijas y móviles desde Lync. Esto nos permite tener un usuario de Lync para realizar llamadas de Voz a fijos y móviles desde el PC o dispositivo móvil, además tendremos un DDI asignado al usuario …
Lync_Online_Vodafone.JPG

Para los que no queréis tener una instalación On-Premises pero si tengáis contratado Office 365, con Vodafone podéis tener Telefonía Empresarial y así olvidaros de la telefonía tradicional. De poder disfrutar de unas comunicaciones unificadas al completo en Office 365, sin la complejidad de la instalación y mantenimiento de otras tecnologías. Tiene algunas limitaciones que podéis consultar aquí:  http://www.vodafone.es/empresas/es/tienda/soluciones-para-empresas/office-365/que-incluye/ pero estoy seguro que para muchas empresas que en España utilizan Lync de Office 365 podrán dar el paso de migrar sus entornos de telefonía a Lync.

 

Si alguien lo está utilizando, por favor, que deje algún comentario sobre su funcionamiento, instalación, calidad de las llamadas, etc..

​El esquema es igual que el anterior (Esquemas de red para nuestras implementaciones de Lync Server (Parte IV)) pero con la incorporación de las sedes remotas que tenemos conectadas mediante VPN vía IPSec (Cisco VPN IPSec Site-to-Site con Certificados Digitales). En un modelo con una topología simple de Lync, prácticamente no aumenta la complejidad de configuración si añadimos nuevos elementos a la red, estén directamente conectados o mediante VPN (pulsar en la imagen para verla a tamaño completo)

Topologías Lync 2013_Esquema_5_1.jpg

Con respecto al esquema y configuración anterior (Esquemas de red para nuestras implementaciones de Lync Server (Parte IV)) únicamente debemos crear una ruta estática en el EDGE para que los usuarios que están conectadas en las sedes remotas se pueden comunicar con usuarios externos. Pensad que los usuarios en las sedes remotas, lo normal es que tengan acceso directo a los servicios que tenemos en la sede central, para esto hemos configurado la VPN entre las sedes. De esta forma, la resolución DNS será interna y como tenemos configurado la VPN, los usuarios de las sedes remotas se conectarán a los distintos servicios de forma "directa":

  • Front-END de Lync
  • Exchange Server
  • Office Web App
  • Dominio

Pero debemos recordar, que cuando un usuario que se conecta de forma directa a los Front-END para conectarse con usuario externos, lo hará si o si mediante el EDGE, esté donde esté el usuario localizado. Siempre que un cliente resuelva el DNS con registros con las direcciones IP internas y se conecte, las conexión externa es siempre a través del EDGE. Ahora bien, como el EDGE tiene la interface conectada a una VLAN interna, debemos configurar la ruta estática necesaria para que pueda llegar a las otras subredes vía VPN. Esto es así, porque como en esa interface NO DEBEMOS configurar un Gateway, tenemos que indicarle quien será el dispositivo de próximo salto para esta interface que podrá llevarlo a la subred indicada:

Topologías Lync 2013_Esquema_5_2.jpg

Como todas las subredes de las VPN pertenecen a la subred 172.20., podemos configurar directamente la ruta estática siguiente: route add 172.20.0.0 mask 255.255.0.0 172.26.1.1 if N. También si queremos podemos afinarlo mucho más con rutas sumarizadas, pero para no complicaros muchos lo dejamos lo más amplio posible. Con esta ruta estática, todas las subredes para la red 172.20.0.0 serían accesibles desde el EDGE sin tener que volver a configurar más rutas estáticas.

Todos los equipos de la red que tienen como servidor DNS, el servidor DNS interno, resolverán el FQDN edge.dominio.com con la IP interna (172.26.1.5) y tienen que ser alcanzable por todos los equipos que se conecten de forma intena. El resto de configuraciones no las completaremos aquí, pero sería básicamente que el enrutamiento estuviese correctamente configurado en los Switchs L3 de la red, sino no tendríamos conexión de forma alguna con las sedes remotas. Pero esto es algo que ya forma parte de la configuración de red, que tendría que realizarse para tener conectividad desde cualquier sede a los servicios centrales y al revés. Si quisiéramos configurar una VPN con Alta Disponibilidad (vamos que los dos routers de la sede Central fuesen los terminados de VPN de las sedes remotas), tendríamos que ir adaptando la configuración y sería más que recomendable utilizar protocolos de enrutamiento (siempre recomendabas para mantener una convergencia de la red lo más  óptima posible).

Como véis, si queremos conectar sedes remotas y extender los servicios que se ofrecen en la sede principal, debemos tener en cuanta pocas cosas a nivel de Lync. La conectividad con los Front-END y el resto de host de la red (servidores, equipos, impresoras, ETC..) ya viene implícito con la configuración de la VPN, lo único es que crear la rutas estáticas en el EDGE. También doy por hecho que no tenemos filtrados de algún otro tipo para tener que obligar a los equipos de las sedes a ir por las conexión externa, pero bueno, esto sería más una resolución DNS  que no fuesen los servidores internos, entonces los equipos resolverían los nombres públicos de los registro DNS que nos permiten encontrar los servidores de Lync y trataríamos de conectarnos por las interfaces del EDGE y el Reverse-Proxy, etc.. pero vamos, aquí contamos con resolución DNS interna (¿Qué registros DNS necesitamos para la configuración automática del cliente Lync 2010 y 2013?) y acceso "directo" a los servidores vía VPN con IPSec (Site-to-Site, DMVPN, MPLS, etc..).

Ya nos os comento nada de la configuraciones de los routers (NAT, Puertos, etc..), swtichs, etc.. porque esto debería estar igual que en los artículos anteriores en donde ya teníamos esta configuración de red con varias subredes, etc… aquí solo hemos añadido la sedes conectadas por VPN.

Espero que os sea de utilidad!!!

En la mayoría de las empresas con presencia internacional, tenemos usuarios de diferentes países y que hablan diferentes idiomas. ¿Qué ocurre si tenemos que implementar Lync para todos los usuarios? Siempre han existido los paquetes de idioma para la mayoría de los productos de MSFT, y Lync no va a ser una excepción. Por lo que podemos instalar el cliente Lync 2010 en cualquier idioma, o en el idioma nativo del país en donde se encuentre el usuario y luego instalar el MUI para permitir cambiar el idioma de la interface en cualquier momento.

Lo primero que debemos hacer es descargarnos el MUI de Lync 2010, aquí os dejo dos enlaces para los clientes de x32 y x64 respectivamente:
Lync_MUI_Download.png
Ahora debemos instalar la versión adecuada para nuestro equipo, algo sencillo y rápido:
Lync_MUI_1.png
Lync_MUI_2.png
Lync_MUI_3.png
Una vez se haya completado la instalación, debemos iniciar sesión y de momento el idioma no se habrá cambiado por supuesto. En mi caso es el Español y quiero cambiarlo a Inglés, así que iniciamos sesión
Lync_MUI_9.png
Ahora nos vamos a las Opciones de Lync – General y elegimo entre los 38 idiomas disponibles y pulsamos en AceptarLync_MUI_5.png
Nos muestra una alerta de que se cambiará el idioma en cuanto cerremos la aplicación (ojo, NO LA SESIÓN)
Lync_MUI_4.png
Ahora volvemos a iniciar el cliente de Lync y vemos que ya lo tenemos en inglés
Lync_MUI_6.pngLync_MUI_7.png
Lync_MUI_8.png
Esto resulta muy sencillo y práctico, ayudando al usuario a mejorar su experiencia con Lync. En próximos artículo veremos como podemos modificar el idioma del cliente en función del idioma del Sistema Operativo del equipo. Si queremos establecer el idioma de Lync a nivel de usuario, podemos crear una GPO y establecer el valor Language en la rama del registro  HKEY_CURRENT_USER\Software\Microsoft\Communicator y establecer el valor de Language según la siguiente tabla de idiomas:
 
Idioma_Lync_2010_user.png
Espero que os sea de utilidad!!!

​En Lync Server 2010 y 2013 tenemos un servicio ubicaciones diseñado para E911 (sería el 112 en Europa), pero en este caso vamos a ver como podemos utilizarlo para mostrar la ubicación de los usuarios de Lync. De tal forma que cuando un usuario inice sesión en Lync, podamos de forma automática mostrar su ubicación en función de en que subred haya iniciado sesión, un punto de acceso wireless, un switch determinado, etc…

Ubicacion_usuarios_Lync_Lis_1.jpg

Lo primero que debemos hacer es configurar los orígenes de donde vamos a sacar la información de la ubicación, para ello tenemos los siguientes cmdlets:

  • Set-CsLisLocation: Crea una ubicación o modifica una existente en la base de de datos de configuraciones de ubicaciones (E911)
  • Set-CsLisPort: Nos permite  asociar un puerto y una ubicación
  • Set-CsLisServiceProvider: Nos permite crear o modificar la información sobre el servicio web que nos ofrece un proveedor de enrutamiento de E911
  • Set-CsLisSubnet: Nos permite crear una asociación entre una ubicación y una subred IP
  • Set-CsLisSwitch: Nos permite crear una asociación entre una ubicación y un switch de red, utilizando para ello la MAC del Switch (ChassisID)
  • Set-CsLisWirelessAccessPoint: Nos permite crear una asociación entre una ubicación y un punto de acceso inalámbrico, utilizando para ello el BSSID

Como vemos tenemos múltiples formas de configurarlo, pero yo soy voy a mostrar lo que podéis utilizar de forma más sencilla:

  • Set-CsLisSubnet: Nos permite crear una asociación entre una ubicación y una subred IP
  • Set-CsLisWirelessAccessPoint: Nos permite crear una asociación entre una ubicación y un punto de acceso inalámbrico, utilizando para ello el BSSID

En todas las empresas con Lync tienen una o varias subredes (misma ubicación u oficinas conectadas mediante VPN) y uno o varios puntos de acceso Wifi. Claramente un switch también lo vamos a tener, pero la configuración es muy similar en ambos casos.

Veamos primero como hacerlo con los Puntos de Acceso inalámbricos, de tal forma que podamos asignar una ubicación a los usuarios que estén conectados a un punto de acceso en concreto. Lo primero que debemos conocer es el BSSID (dirección física (MAC) del punto de acceso al que nos conectamos), yo os lo voy a mostrar en dos AP de Cisco desde cli: Show dot11 bssid

AP2

 

Ubicacion_Lis_AP_4.png
AP3

 

 

Ubicacion_Lis_AP_5.png
 
Ahora que ya tenemos la MAC de cada punto de acceso, vamos a configurar una nueva ubicación mediante el punto de acceso, para ello tenemos el siguiente cmdlet:

 

Set-CsLisWirelessAccessPoint -BSSID 00-3a-99-2b-b2-30 -Country ES -CompanyName "ASIR INTRASITE" -Location Ponteareas-AP2

Ubicacion_Lis_AP_2.png

Set-CsLisWirelessAccessPoint -BSSID 00-3a-99-3c-34-d0 -Country ES -CompanyName "ASIR INTRASITE" -Location Ponteareas-AP3

 

Ubicacion_Lis_AP_2-1.png
El parámetro obligatorio es el BSSID, sino sería imposible saber a que punto de acceso estamos conectados, pero como vemos tenemos más parámetros disponibles:

 

  • Description
  • Location
  • CompanyName
  • HouseNumber
  • HouseNumberSuffix
  • PreDirectional
  • StreetName
  • StreetSuffix
  • PostDirectional
  • City
  • State
  • PostalCode
  • Country

Antes de publicar los cambios, vamos a crear también varias ubicaciones por la subred en la que nos encontremos, para ello tenemos los siguientes cmdlets:

Set-CsLisSubnet -Subnet 192.168.100.0 -Country ES -CompanyName "ASIR INTRASITE" -Location Ponteareas
Ubicacion_Lis_AP_2-2.png

 

 
Set-CsLisSubnet -Subnet 192.168.250.0 -Country ES -CompanyName "ASIR INTRASITE" -Location CPD
Ubicacion_Lis_AP_2-3.png
 
Una vez que hemos añadido los puntos de acceso y/o subredes (cada uno lo que quiera o ambas cosas), lo que nos queda es publicar los cambios para que se vean reflejados en los usuarios de Lync (deben cerrar y abrir nuevamente la sesión en sus clientes Lync). Para publicar las ubicaciones, tenemos el siguiente cmdlet: Publish-CsLisConfiguration

 

 

Ubicacion_Lis_AP_3.png
 
Antes de ver el efecto que tiene esta configuración sobre los usuarios, vamos a ver las distintas ubicaciones creadas con los cmdlets correspondientes:

 

Get-CsLisSubnet | ft AutoSize

Ubicacion_Lis_AP_3-2.png

Get-CsLisWirelessAccessPoint | ft AutoSize

 

Ubicacion_Lis_AP_3-3.png
 
Ahora sí, vamos a probar que verían los usuarios cuando se conectan en una subred determinada o a alguno de los puntos de acceso definidos:

 

Sin ubicación definida

Ubicacion_Lis_AP_1.png

Location Ponteareas

 

Ubicacion_Lis_AP_1-1.png
Location CPD

 

 

Ubicacion_Lis_AP_1-2.png
Location Ponteareas-AP3

 

 

Ubicacion_Lis_AP_1-3.png
 
Y así según nos vayamos moviendo de subred o punto de acceso, por último comentaros que la base de datos de ubicación se actualizar cada 4 horas, pero si queremos cambiarlo podemos hacerlo con el siguiente cmdlet:

 

Set-CsLocationPolicy -LocationRefreshInterval 1

Ubicacion_Lis_AP_6.png

y si queremos ver la configuración que hemos modificado tenemos el siguiente cmdlet:

Get-CsLocationPolicy

Ubicacion_Lis_AP_7.png

Por último me gustaría puntualizar varias cosas:

  • Solo se puede establecer las ubicaciones a usuarios que se conectan en interno (conexiones directas los Front-END como en el esquema), no a los usuarios que se conecten vía EDGE.
  • La ubicación si no se actualiza de forma automática si nos movemos de subred o punto de acceso, para esto tendremos que cerrar e iniciar sesión en Lync nuevamente

En el esquema que os muestro al inicio del artículo, he puesto varias ubaciones vía subred y un punto de acceso. Además, hay dos ubicaciones remoas que podéis configurar también vía Set-CsLisSubnet porque son usuarios de Lync que se conectan vía VPN a los Front-END de forma directa, no así el usuario remoto que lo hace vía EDGE. Lo comento porque luego los cmedlets que he puesto no refleja lo puesto en el esquema, simplemente es una referencia gráfica de lo que podríais implementar.

Espero que os sea de utilidad!!!

​En ocasiones podemos encontramos con este "problema" cuando iniciamos sesión con el cliente Lync 2013 y el dominio SIP no coindice con el nombre común y nombre de sujeto en el certificado del Servicio Web de Lync Server. Aquí el problema no es si tenemos el certificado raíz de la CA que ha emitido el certificado, siempre y cuando lo tengamos instalado claramente, pero de todas formas el error sería otro (esto lo comento por aclararlo)

Lync_No_Puede_Comprobar_Que_El_Servidor_Es_De_Confianza_1.png
Como sabemos el cliente Lync 2013 utiliza un descubrimiento automático para encontrar el servidor del Lync (¿Qué registros DNS necesitamos para la configuración automática del cliente Lync 2010 y 2013?), de ahí que en la misma instalación con el cliente Lync 2010 no tengáis problemas de acceso y con el 2013 os muestre esta alerta.  Aquí os muestro dos capturas de Wireshark una de un cliente Lync 2010 y otra de Lync 2013 con un mismo servidor y cuenta de usuario:
 
Cliente Lync 2010: como podemos apreciar el nombre de dominio (oculto por razones obvias) es XXX.XXX y el nombre de dominio del servidor de Lync es srv-lync00.grupoXXX.XXX, vamos que no es el mismo nombre de dominio que el dominio SIP de los usuarios, pero igualmente como el certificado es de confianza y el nombre del servidor coincide con el nombre del certificado (Certificado SAN) no tiene problema y conecta al usuario sin mostrar advertencia alguna:
Lync_No_Puede_Comprobar_Que_El_Servidor_Es_De_Confianza_Lync_2010.png
Cliente Lync 2013: como podeoms ver el cliente 2013 busca los registros lyncdiscoverinternal.xxxx.com, lyncdiscover.xxxx.com, etc…  y el nombre del servidor es el mismo (que con el cliente 2010)  srv-lync00.grupoxxxx.com y tiene un nombre de dominio diferente al dominio SIP y ahí está el "problema", puesto que con el modelo de seguridad del cliente Lync 2013 en la resolución de nombres nos mostrará una advertencia por si estamos seguros de que nos estamos conectando al servidor adecuado.
Lync_No_Puede_Comprobar_Que_El_Servidor_Es_De_Confianza_6.png
Para corregir este problema, sino podemos cambiar los nombres asignados a los certificados, debemos crear un GPO y configurar los dominios SIP que queramos añadir de confianza para el usuario. Para poder configurar las directivas de Lync, primero debemos descargarnos las plantillas Office 2013 Administrative Template files (ADMX/ADML) and Office Customization Tool (Plantillas ADMX Office 2013 y Configuración Lync 2013) y luego reailzar la siguiente configuración: Configuración de Usuario – Directivas – Plantillas administrativas : xxxx – Microsoft lync 2013 – Directivas de características de Microsoft Lync – Lista de confianza de dominio
Lync_No_Puede_Comprobar_Que_El_Servidor_Es_De_Confianza_3.png
Y añadimos los nombres de dominio SIP en los que tengamos este problema, porque recordar si que iniciamos sesión con un usuario que su dominio SIP está como nombre común y sujeto en el certificado del servicio web de Lync no os mostrará alerta alguna: * Fijaros que pode defecto los dominios lyn.com, outlook.com, lync.glbdns.microsoft.com y microsoftonline.com ya son de confianza y no los podemos agregar
Lync_No_Puede_Comprobar_Que_El_Servidor_Es_De_Confianza_4.png
Una vez que se aplique a todos los usuarios, ya nos mostraré el error de certificado y se conectará de forma transparente. Si este cambio queréis hacerlo sobre equipos que no están en el dominio, debéis modificar el registro del usuario y añadir los dominios SIP manualmente. Para ello debemos acceder a la siguiente ruta del registro HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Lync y crear un nuevo Valor de Cadena con el nombre TrustModelData y escribir los nombres de dominio SIP que queramos configurar:
Lync_No_Puede_Comprobar_Que_El_Servidor_Es_De_Confianza_2.png
Ahora la próxima vez que iniciéis sesión con vuestro cliente Lync 2013 y se den las mismas circunstancias en cuanto al nombre común y sujeto del certificado del servicio Web de Lync Server, ya no mostrará la alerta e iniciará sesión de forma normal.
 
Espero que os sea de utilidad!!!