Actualizaciones de Software para teléfonos IP para Lync
agosto 26th, 2014 | Posted by in Lync Server - (0 Comments)Vodafone y Microsoft Lync en Office 365 (VoIP)
julio 23rd, 2014 | Posted by in Lync Server | Office - (0 Comments)
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..
Esquemas de red para nuestras implementaciones de Lync Server (Parte V)
julio 23rd, 2014 | Posted by in Lync Server - (0 Comments)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)
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:
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!!!
Paquete de Interfaz de usuario multilingüe para Microsoft Lync 2010 (Actualizado 11-07-2014)
julio 23rd, 2014 | Posted by in Lync Server - (0 Comments)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.
- http://www.microsoft.com/es-es/download/details.aspx?id=16366 (x32)
- http://www.microsoft.com/en-us/download/details.aspx?id=21719 (x64)
Direct Access: IP-HTTPS no funciona correctamente
julio 23rd, 2014 | Posted by in Sin categoría - (0 Comments)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 ….
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:
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:
Lo que tenemos que hacer para solucionar este problema está claro:
- Renovar el certificado e importarlo en el servidor (si tenemos un clúster de NLB (Windows Server 2012: DirectAccess en un clúster con Windows NLB) configurado, debemos importar el certificado en cada servidor):
- Asignar nuevamente el certificado al servidor de DirectAccess
Una vez que se ha configurado el certificado que hemos importado, debemos esperar unos minutos y todo quedará funcionando:
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!!!