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

Por muchas circunstancias nos podemos encontrar con este problema cuando estamos fuera de la organización y la conexión de DirectAccess no se establece y se queda Conectando ….

Error_DirectAccess_Certificado_Caducado_9.png
 

Si solo vemos la parte de cliente, lo primero que debemos hacer es comprobar lo siguiente:

  • Conexión a internet: basta con navegar en alguna web y comprobar que no tenemos problema
  • Resolución DNS: si tenemos internet lo normal es que la resolución DNS funcione bien, pero igualmente revisemos si encontramos el FQDN que hemos configurado en DirectAccess
  • Acceso al puerto 443 (IP-HTTPS): lancemos un telnet hacia el servidor de DirectAccess (FQDN o IP) al puerto 443: telnet directaccess.dominio.com 443
  • Comprobración CRL: Si hemos configurado el DirectAccess con certificados privados, debemos verifica que tenemos acceso a la URL en donde tenemos la CRL

Si una vez repasados estos puntos todo está aparentemen te bien, nos vamos directamente al servidor y a la consola de administración de DirectAccess y si es un problema del propio servidor lo veremos enseguida:

Error_DirectAccess_Certificado_Caducado_3.png

Por lo que el problema está claro, el certificado que teníamos asignado ha caducado y únicamente tenemos que renovarlo. Si abrimos la consola de certificados locales del servidor, podemos ver el certificado y si ha expirado:Error_DirectAccess_Certificado_Caducado_5.png

Lo que tenemos que hacer para solucionar este problema está claro:

Error_DirectAccess_Certificado_Caducado_6.png

  • Asignar nuevamente el certificado al servidor de DirectAccess

Error_DirectAccess_Certificado_Caducado_11.png

Una vez que se ha configurado el certificado que hemos importado, debemos esperar unos minutos y todo quedará funcionando:

Error_DirectAccess_Certificado_Caducado_1.png

Error_DirectAccess_Certificado_Caducado_8.png
 
Si ahora nos vamos a un equipo cliente, ya vemos que nos ha vuelto a conectar sin problema:
Error_DirectAccess_Certificado_Caducado_12.png

Como vemos todo se centra en el los certificados, bien sea por la CRL que no está accesible para los clientes de DirectAccess o como es en este artículo, el certificado ha caducado. El problema es muy sencillo de detectar y de solucionar, simplemente nos conectamos al servidor vemos el problema,  renovamos el certificado, importamos y lo asignamos a la configuración del servidor.

Espero que os sea de utilidad!!!

No suele ser muy frecuente, pero es posible que en alguna ocasión cuando queréis añadir a un agente a un grupo para nuestro RGS, nos encontramos con este error ..

Grupo_Añadir_Agente_Error_Duplicidad_1.png

Esto viene dado porque el servidor no hay podido actualizar la tabla dbo.Agents en la BBDD RSCONFIG en donde están  los agentes, por lo que tenemos dos opciones (una no soportada por Microsoft).

  1. Eliminar al agente en la tabla dbo.Agents de forma manual (no soportado por Microsoft): para ello abrimos la consola de administración de SQL, nos conectamos a la instancia de SQL en donde están las BBDD de Lync, pulsamos con el botón secundario del ratón y elegimos Editar las primeras 200 filas (si tenemos más de 200 agentes pues debemos ampliar el número a mostrar):

Grupo_Añadir_Agente_Error_Duplicidad_3.png

Buscamos el agente que queremos añadir y no nos está dejando, pulsamos con el botón secundario del ratón encima del usuario y pulsamos en Eliminar

Grupo_Añadir_Agente_Error_Duplicidad_2.png

2. Debemos esperar un tiempo hasta que se actualice de forma normal la BBDD de agentes, esto a veces (depende de la carga de trabajo del servidor) puede llevar algún tiempo. No debería ser mas allá de 5 minutos, pero en mi caso el servidor no había actualizado la tabla por más de 1 hora y necesitaba hacer el cambio si o si cuanto antes.

A veces tenemos que buscar alternativas para dar solución a algunos problemas, en este caso no tendrá mayor impacto sobre la infraestructura, pero al opción 1 no está soportada por Microsoft. Se supone que si esperamos un poco el cambio se realizará de forma automática. Si queréis ampliar algo de información, podéis acceder al siguiente KB de Microsoft: http://support.microsoft.com/kb/2393943

Espero que os sea de utilidad!!!