Microsoft Lync Server
Header

El ROI en las Comunicaciones Unificadas

diciembre 30th, 2013 | Posted by Santiago Buitrago in Sin categoría - (0 Comments)

Algo en lo que pensamos antes de tomar la decisión de implementar una solución de Comunicaciones Unificadas es en el ROI (Retorno de la Inversión), para ello debemos analizar varios aspectos que debemos tener en cuenta:

  • Inversión inicial
    • Licenciamiento
    • Hardware
      • Servidores
      • Estaciones de Trabajo
      • Dispositivos Móviles
      • Gateways
      • Switchs
    • Consultoría e Integración
      • Auditoría
      • Piloto
      • Proyecto
      • Formación
      • Soporte
  • Ahorro de costes
    • Mayor productividad en las comunicaciones internas/externas
    • Telefonía
    • Viajes

 Para poder explicar esto me gustaría hacerlo sobre un diseño real que cualquier empresa podría adoptar, para ello os muestro el siguiente esquema:​

ROI Lync Server UC.jpg

Este esquema trata de representa una compañia la cual ha implementado Lync Server 2013 implementando también la parte de Telefonía Empresarial con un ITSP para abaratar el coste de las llamadas. Toda la plataforma de Lync Server 2013 se ha implementado en un Data Center con servidores virtualizados, en su versión Enterprise y con un TRUNK SIP con un ITSP de ámbito internacional para conseguir DDI de distintos paises. Esta empresa tiene sedes en todo el país (España) y sedes en el resto del mundo, en algunas cuentan con sistemas IP-PBX y otras solo con portátiles y clientes Lync 2013. Las sedes que cuentan con IP-PBX se han conectado mediante VPN (Cisco VPN IPSec Site-to-Site con Certificados Digitales) para conectar vía TRUNK SIP (Lync Server: Direct SIP, Trunk SIP e Inter-Trunk Routing, Direct SIP Lync 2013 –> Cisco CME 8.X (Parte I), Direct SIP Lync 2013 –> Cisco CME 8.X (Parte II)) a los usuarios con teléfonos conectados a la IP-PBX con los usuarios de Lync. Estos usuarios podrán recibir y llamar a cualquier usuario de Lync, participar en reuniones en línea pero solo con audio, de esta forma podremos tener un sistema híbrido sin tener que incurrir en gastos de migración para oficinas las cuales aún tienen sistemas IP-PBX sin amortizar.

La compañia tiene unos 140 consultores de ventas, los cuales más del 60% de su tiempo están fuera de las oficinas conectados vía DirectAccess (Windows Server 2012: DirectAccess (Actualizado 15-02-2013), Windows Server 2012: DirectAccess en un clúster con Windows NLB) para acceder de forma segura a la intranet de la compañía (SharePoint 2013), servidores de ficheros y Exchange Server 2013. ADemás, todos cuentan con dispositivos móviles de lo más variado en cuanto al sistema operativo: Windows Phone 8, IOS, Android y todos ellos cuentan con servicios de datos (3G o 4G) para poder consumir los distintos servicios empresariales (Lync, Exchange, CRM, SharePoint). Además, todas las llamadas a clientes se realizan mediante Lync lo que permite por un lado ahorrar más del 70% del coste de la llamada y mostrar el teléfono de cabecera de la compañia.

En el Data Center en donde tiene la implementación de Lync Server, también cuenta con los siguientes servicios:

  • Active Directory
    • 2 Controladores de Dominio
  • SQL Server
    • 2 Servidores configurados con Mirroring
  • Exchange Server
    • 2 Servidores de Buzones
    • 2 Servidores de Acceso de Cliente
  • TMG 2010 SP2 o UAG
    • 2 Servidores en Alta Disponibilidad
  • Lync Server 2013
    • 2 Front-END
    • 2 Mediation Server
    • 2 Edge
  • CRM Microsoft
    • 1 Servidor de CRM
  • SharePoint
    • 1 Servidor de SharePoint

Además en cuanto al hardware utilizado, hemos contratado con proveedor X de Ia siguiente infraestructura:

Con esta infraestructura que se ha desplegado, podremos dar servicios de Voz y Datos a los 500 usuarios de la compañía repartidos entre diferentes ubicaciones físicas por todo el mundo. En las sedes remotas que tenían PBX, se han reemplazado por el cliente Lync 2013 evitando así tener distintos mantenimientos de cada una de las PBX en cada ubicación, además de no tener hardware (teléfonos ni centralitas) ni costes de líneas RDSI, PRIMARIOS o RTB. Este mismo escenario se ha replicado en el 95% de las sedes de la compañía, permitiendo ahorrarnos el coste de 70 PBX y más de 140 líneas (dos por sedes) de voz (PRIMARIO, RDSI y RTB). Con la implementación de Lync de forma centralitada y la contratación de un ITSP (Internet Telephony Service Provider) cursaremos todas las llamadas de Voz vía TRUNK SIP. Esto nos reporta los siguientes beneficios directos:

  • Ahorro del 70% del coste de cada llamada
    • Sin establecimiento de llamada
    • Tarificación por segundos
  • Centralización de los DDI
    • Reducción de la complejidad de los planes de marcado, porque es el proveedor quien se encargará de entregar la llamada en cualquier parte del mundo. Aunque tenemos distintos DDI para tener numeraciones de distintos países, será el ITSP quien se encarga de entregar la llamada en cada pais.
  • IVR
    • Gestión centralizada
    • Multi idioma

El tener un ITSP con presencial internacional, nos permite desde España (por ejemplo) contratar DDI de cualquier parte del mundo sin tener que negocionar nosotros directamente en cada país. Por lo que podemos tener DDI de USA, Brasil, China, España, Francia, UK, etc.. con un coste de 2€ / mensual, y además que todas las llamadas que nos realicen a estos números lo podremos conectar en cualquier sitio en donde el usuario que tenga asociado ese DDI haya iniciado sesión. Esto nos permite no tener oficinas físicas en cada país y tener numeración del mismo para que nuestros clientes puedan ponerse en contacto con nosotros a coste reducido, incluso a coste 0 si su proveedor tiene tarifa plana para llamadas nacionales. También podemos configurar un DDI en nuestro IVR de Lync y en distintos idiomas, lo que nos permite desplegar un sistema de respuesta automática (Lync 2013: Capacidades de los grupos de respuesta ,Lync: Grupos de Respuesta (Parte I), Lync: Grupos de Respuesta (Parte II), Lync: Grupos de Respuesta (Parte III)) de forma centralizada y que podemos gestionar para dar servicio a todo el mundo y todo esto desde un único TRUNK SIP y un ITSP (claramente todo en Alta Disponibilidad).

En Lync en plan de licenciamiento es bastante sencillo y aquí os dejo un resumen del mismo (Licenciamiento Lync Server 2013):
Licenciamient20Lync202013.jpg
Como sabemos el licenciamiento de casi todos los productos de MSFT es de pago único o como SA (Software Assurance), pero aquí debemos conocer el tipo de usuario que tenemos en la compañia porque no todos los usuarios deben tener las mismas funcionalidades. Básicamente se calcula por el número de Front-END de nuestra topología y las funciones habilitadas para cada usuario. Pero si queremos un usuario con todas las funcionalidades, podemos hablar de 300€ x Usuario (lo que inicialmente puede ser un coste considerable pero aquí tenemos que darle muchas vueltas). Si los usuarios tienen un alto porcentaje de llamadas internacionales, el coste de la licencia se verá contrarrestrado con el ahorro sustancial de las llamadas vía VoIP. Pero si el usuario tiene un perfil itinerante entonces el ahorre es mayor, puesto que si podemos ahorrarnos un viaje de negocio por mes (siendo pesimista)  y sustituirlo por una conferencia en línea ya nos hemos ahorrado el coste de la licencia. Además, estos usuarios itinerantes puedes estar en cualquier punto del mundo y en cualquier parte, imaginemos que nos encontramos en algún aeropuerto u hotel y necesitamos conectarnos a Lync para hacer una llamada a un cliente o queremos hablar con alguien de la compañía, únicamente debemos conectarnos a la wifi que tengamos disponible y cursar la llamada. Si es una llamada a otro usuario de Lync o usuario contectado a la IP-PBX (TRUNK SIP) el coste de la llamada son 0€, porque utilizamos nuestra conexión de datos o wifi pública pero a través de Lync y esto no tendría coste para la empresa. Si estamos fuera de nuestro país pero queremos llamar a algún cliente, la llamada igualmente se cursará mediante nuestro Lync Server y mediante el ITSP con el coste de la llamada que hemos contratado con el ITSP y en muchas de las ocasiones son llamadas locales para el ITSP de ahí que el coste de la llamada sea tan económica. Los ITSP internacionales tienen líneas de datos o acuerdos comerciales con otras compañías, las cuales cursarán las llamadas a través de ellos. De tal forma que si nuestro ITSP es de España y queremos cursar una llamada a USA, es posible que el ITSP envíe la llamada a un proveedor de USA para cursar la llamada en local (a nuestro cliente) pero a nosotros solo nos repercute el coste nuestro ITSP. De ahí que el coste de la llamada supere en muchas ocasiones el 70% de ahorro sobre las llamadas a la PSTN tradicionales con proveedores no IP.
 
Como todas las llamadas salientes están centralizadas en Lync y el ITSP contratado, la fuerza de negociación es mayor y la tarifas serán mucho más reducidas esto es otro de los beneficios de la centralización de las llamadas. Todas las llamadas que cursen los usuarios se podrán configurar para que muestra el DDI que queramos a los usuarios que reciben nuestras llamadas externas, de tal forma que si llamamos a USA desde España podrán ver un DDI de USA. Esto también es algo importante, debemos generar confianza y transparencia en nuestras comunicaciones y si podemos mostrar el DDI local para que también nos puedan devolver la llamada a ese DDI mejor que mejor.
 
Otro de los puntos fuertes de Lync como herramienta de Comunicaciones Unificadas, es la posibilidad de ver la disponibilidad de cualquier usuario que haya iniciado sesión en cualquier parte del mundo. Por lo que podemos tener un sistema de atención al cliente centralizado para todo el mundo y puedan enviar las llamadas a cualquier usuario consultando previamente su disponibilidad y no sujeto a la localización física como en otros entornos. Ver la disponibilidad nos ofrece la posibilidad de saber cuando podemos contactar con alguien, si está disponible o en alguna reunión en línea y lo de siempre, desde cualquier parte del mundo y desde cualquier dispositivo (compatible).
 
Algo básico pero súper crucial en cualquier sistema de Comunicaciones Unificadas, es la opción de IM, porque nos permite ser más productivos y a su vez reducir en más del 30% la utilización del correo electrónico, tanto a nivel de almacenamiento como de mensajes enviados por minuto. Además por supuesto, de la inmediatez que nos ofrece y la sencillez del mismo, puesto que podemos pasar de un IM a una conferencia en línea en dos clics. Esto es algo muy interesante, porque podemos ir agregando servicios a un primer mensaje instantáneo entre dos usuario y terminar con reuniones en línea de 1000 usuario (Lync Server 2013: Reuniones Online de 1000 usuarios) y no solo usuarios de la compañia (Clientes, Socios de Negocio)
Grandes20Reuniones20Online.jpg
 
Las Comunicaciones Unificadas nos permiten entrelazar fuertes vínculos con nuestros clientes, puesto que nos permite tener video conferencias en alta calidad sin que para ello tengamos que desplegar complejos sistemas ni salas acondicionas para tal fin. Esto no significa que no tengamos dispositivios de alta calidad (Microsoft Lync Room System (Beta Version) Deployment Guide)
Smart_Lync_Room_Doc_1.png
 
Además de múltiples dispositivos multiplafoma para dar servicios a los usuarios más exigentes, que nos permiten utilizarlo en distintos ambientes:
Smart_Lync_Room_Doc_2.png
Otra de las opciones más interesantes, en la integración de la mensajería unificada de Exchange, lo que nos permite disponer de un buzón de voz conectado en Lync. Esto nos permite disponer de un buzón de voz corporativo para cada usuario, personalizable y disponible desde cualquier parte. Además, podemos utilizar nuestro buzón de voz de Lync como buzón de voz cuando nos llamen a nuestro terminal con la llamada simultáne habilitada (Enrutamiento al Buzón de Voz Corporativo (EnableVoicemailEscapeTimer))
Escape_Buzón_Corporativo_Esquema.jpg
 
Esto nos permite estar siempre disponibles para nuestros clientes y compañeros de trabajo, algo que hoy en día es un valor añadido para nuestra empresa. Debemos ser capaces de dar respuesta en el menor tiempo posible y desde cualquier parte, por lo que podemos estar en Brasil y recibir llamadas desde España y la persona que nos llama no saber en donde estamos físicamente. Aquí lo importante es conseguir una conexión de datos (3G/4G o Wifi) con cierta calidad para poder soportar una llamada con calidad, pero esto es algo que nos permitirá dar respuesta de forma efectiva en cualquier momento.
 
Como podéis apreciar, todo (o casi todo) pasa por centralizar la gestión de nuestras comunicaciones en un sistema de Comunicaciones Unificiadas y un ITSP que nos de soporte para nuestras llamadas de voz. Ahora bien, el ROI de estas soluciones dependerá el tamaño de la compañia y el propio funcionamiento de la misma. Una empresa con varias sedes, usuarios itinerantes y llamadas internacionales es una empresa ideal para pasarse a un sistema de Comunicaciones Unificadas.  Pero para ello tienen que darse como mínimo esas premisas, pero claro, debemos contar con la infraestructura necesaria para dar este tipo de servicios. Porque Lync como otras herramientas nos ofrecen múltiples servicios estupendos, pero las compañias se mueven por productividad y ahorro de costes en las inversiones y en muchas ocasiones estas inversiones se vuelven estratégicas. Esto hará que debamos ser capaces de ver más allá de la propia tecnología y ofrecer una solución con alto valor añadido  para la compañia, pero si nos apoyamos en un sistema de telefonía vía VoIP seguro que acertaremos. El ahorro de costes es inmediato y la transición es relativamente sencilla (en función del tamaño de la compañia), pero algo que debemos tener en cuenta es al usuario final. El usuario final que es quien al final utiliza los sistenas implementados, deben conocer a fondo la potencia de la misma, para que puedan valorar en su justa medida una herramienta de Comunicaciones Unificadas. Con Lync algo que mejorará es la conciliación familizar, puesto que permite que los teletrabajadores dispongan de los mismos servicios como si estuvieran en la oficina. Además, el coste de  implementación de la solución de acceso externo es prácticamente inexistente, porque al no necesitar VPN para consumir los servicios de Lync  hace que no tengamos que desplegar Firewalls ni concentradores VPN específicios, abaratando la solución tanto a nivel de coste del hardware como el mantenimiento posterior. 
 
El ROI es algo de lo que podríamos estar hablando días y dias, puesto que entran en juego muchos aspectos de la solución que debemos tener en cuenta:
  • Adquisición de Hardware o Outsourcing del mismo (IaaS)
    • Cambio del coste fijo al coste variable
    • Menor coste energético
  • Licenciamento
    • Instalación On-Premise
    • Instalación On-Line
    • Instalación Híbrida
  • Telefonía
    • Convencional
    • VoIP
  • Usuario
    • Formación
    • Adaptación

Como he venido comentando en este artículo, si contamos con ciertos aspectos claves como compañia, el ahorro de coste es casi de forma inmediata (VoIP).  Pero creo que algo muy importante en Lync sobre todo, es la posibilidad de federarnos con otras compañias o sistemas de mensajería públicos. Esto nos permite, a la vez que podemos conectarnos con compañeros de trabajo en cualquier parte del mundo, es poder conectarnos con otras compañias que tienen Lync o usuarios de Skype, Google, etc…

Federaciones_Lync_2013_Esquema.jpg

Funciones20de20UsuarioLync.jpg
 
Todo esto nos permite extender las comunicaciones más allá de nuestra compañia, añadiendo contactos de otras implementaciones de Lync o Sistemas de Mensajería Pública como Skype (cuenta con más de 300Millones de usuarios).
 
Como vemos podemos utilizar Lync para hablar y ver la posibilidad de otros usuarios de Lync de cualquier parte del mundo, podemos realizar y recibir llamadas en Lync desde cualquier parte del mundo y podemos integrarnos con sistemas IP-PBX de casi cualquier fabricante. Si utilizamos VoIP con un ITSP podemos  beneficiarnos de traspasarle la responabilidad de la gestión de la llamada, lo que nos permitirá minizar la configuración de nuestras reglas de marcado en Lync, puesto que nosotros le enviaremos las llamadas al ITSP mediante un TRUNK SIP siempre de la misma forma (formato E.164) y el se encargará de enviar la llamada a su destino sea cual sea el país de destino. Centralizando las llamadas podremos conseguir mejores precios en las llamadas, puesto que tendremos más consumo por parte de todos los usuarios. Con la integración con otros sistemas (IP-PBX) podemos realizar la migración a Lync de forma sencilla y transparente, algo esencial en cualquier proyecto. Y si contamos con dispositivos móviles de última generación, podremos utilizar Lync para conectarnos desde cualquier parte del mundo en cualquier momento, únicamente debemos tener una conexión de datos y tendremos acceso a los mismos servicios.
 
Como muestro en el esquema inicial, podemos observar que todos los usuarios de la organización pueden tener contacto entre ellos vía Lync – Lync o Lync – Teléfono. Pueden llamar a cualquier persona del mundo utilizando para ello la infraestructura se ha desplegado en el CPD, algo que nos aporta un valor añadido importante:
  • Posibilidad de crecimiento
    • Conexión a Internet
    • Almacenamiento
  • Disponibilidad
    • Eletrónica de red en HA
    • Sistemas Eléctricos rendundantes
  • Seguridad
    • Monitorización
    • Actualización
 En muchas ocasiones queremos implementar este tipo de soluciones en los CPD de las empresas, y esto desde mi punto de vista es un gran error por muy bien montado que estén (salvo excepciones). Porque hoy tenemos 10MB de internet, pero si necesitamos aumentarlo en el CPD es cuestión de minutos, en las oficinas de cada cliente sería cuestión de días, etc.. y con esto cualquier aspecto del dimensionamiento del hardware y seguridad física y lógica. Esto es algo que también debemos valorar para tener un ROI adecuado para nuestra compañía, porque ahorrarse dinero en llamadas no es el ROI único de Lync, porque para esto podríamos desplegar un sistema de telefonía IP  de cualquier otra compañía. Un sistema de Comunicaciones Unificadas es algo más y nos debe ofrecer una solución completa en todos los aspectos de las comunicaciones empresariales.
 
Yo diría que para el ROI en cuanto  la parte de Telefónica viene dado por:
  • Reducción de líneas tradicionales (PRIMARIOS, RDSI, RTB)
  • Eliminación de centralitas PBX, IP-PBX
  • Centralización de todas las comunicaciones
  • Centralización y reducción de los contratos de soporte
  • Facilidad de integración con nuevas sedes, clientes, etc…
  • Reducción de más del 70% de la factura telefónica
  • etc…

Las Comunicaciones Unificadas es algo que ha empezado a sonar y muy fuerte en toda las compañías de mundo, no solo por el ahorre de coste sino por los beneficios que ofrece al usuario final. Espero que no me haya liado mucho con las explicaciones, porque aun me han quedado cosas pendientes por comentar, pero creo que las principales han quedado documentados. En próximos artículos iremos viendo con más nivel de detalle el ROI de este tipo de soluciones

Espero que os sea de utilidad!!!

Windows Server 2012: DirectAccess en un clúster con Windows NLB

diciembre 23rd, 2013 | Posted by Santiago Buitrago in Windows Server - (0 Comments)

​Cuando implementamos un nuevo servicios en nuestra empresa o cliente, siempre debemos tener la posibilidad implementarlo en Alta Disponibilidad. DirectAccess es un servicio de acceso remoto que permite estar permanentemente conectado de forma segura a nuestra organización, y con la llegada de Windows Server 2012 se ha simplificado su implementación. Los requisitos en cuanto al direccionamiento IP Público es mejor que con Windows Server 2008, por lo que se ha vuelto un servicio muy demandado por las empresas. De ahí que necesitemos configurarlo en Alta Disponibilidad …

Esquema DirectAccess_en_HA_1.jpg
En un primer artículo (Windows Server 2012: DirectAccess (Actualizado 15-02-2013)) había explicado como configurar DirectAccess con un único servidor, por lo que esto no lo volveré a comentar en este artículo. Partiendo de la base de que ya tenemos uno de los servidores de DirectAccess funcionando, estos son los pasos que debemos dar para configurar un segundo serrvidor de DirectAccess y posteriormente configurar el equilibro de carga con Windows NLB:
  1. Crear un certificado con la plantilla de Servidor Web para el servidor de ubicación de red (debemos importarlo en todos los servidores del clúster)
  2. Creamos un registro DNS con el nombre del certificado asignado al primer servidor del clúster NLB
  3. Si utilizamos máquinas virtuales en Hyper-V debemos habilitar la suplantación de dirección MAC en todos los servidores del clúster NLB
  4. Instalamos el ROL de Equilibrio de carga de red en los servidores del cluster (un máximo de 8 nodos)
  5. Instalamos el ROL de Acceso Remoto en el segundo servidor para configurar DirectAccess (pero no lo configuramos)
  6. Configuramos el Equilibrio de carga en el primer servidor de DirectAccess
  7. Añadimos el segundo servidor de DirectAccess (sin configurar) al Clúster de Equilibrio de carga
  8. Comprobación del funcionamiento del Clúster de Equilibrio de Carga

Pues teniendo claro estos puntos, vamos a empezar paso a paso a configurar el clúster de equilibrio de carga para DirectAccess pero antes os muestros lo datos de configuración IP de ambos servidores:

SRV-DA00

  • Interface LAN: 192.168.250.96 /24
  • Interface WAN: 172.16.0.3 /27
SRV-DA01
  • Interface LAN: 192.168.250.92 /24
  • Interface WAN: 172.16.0.5 /27

Ahora ya podemos empezar con la configuración del clúster de equilibrio de carga para DirectAccess, lo haremos punto a punto para no equivocarnos:

  1. Crear un certificado con la plantilla de Servidor Web para el servidor de ubicación de red (debemos importarlo en todos los servidores del clúster)

Debemos solicitar un certificado para el servicio de ubicación de red, con la plantilla del Servidor Web y de tal forma que podamos exportarlo con su clave privada para importarlo en todos los servidores del clúster. Para solicitar un certificado a nuestra CA  podemos hacerlo de varias formas, pero yo lo haré desde la consola de Certificados de Equipo Local (Inicio – Ejecutar – certlm.msc) y nos vamos al contenedor Personal – Certificados, pulsamos con el botón secundario del ratón y vamos a Todas las tareas – Solicitar un nuevo certificado

DirectAccess_HA_20_20.png

Pulsamos en Siguiente

DirectAccess_HA_20_21.png

En el listado de certificados de equipo disponibles tenemos la plantilla de Servidor Web y pulsamos en Se necesita más información para inscribir este certificado. Haga clic aqui para configurar los valores
DirectAccess_HA_20_22.png

Seleccionamos la opción de Nombre común en la opción Nombre de sujeto, escribimos el FQDN para el certificado y pulsamos en Agregar

DirectAccess_HA_20_23.png

En la pestaña Clave privada debemos habilitar la casilla Hacer exportable la clave privada (lo que nos permitirá exportarlo con la clave privada e importarlo en el resto de servidores)

DirectAccess_HA_20_24.png

Una vez que hemos completado los datos necesarios en la solicitud del certificado, únicamente debemos completar la solicitud y si todo ha ido bien ya tenemos nuestro certificados instalado en el primer servidor de DirectAccessDirectAccess_HA_20_25.png
Ahora debemos asignar este certificado en el servidor de ubicación de red en la consola de administración de DirectAccess, pulsamos en editar en el paso 3DirectAccess_HA_20_10.png
Pulsamos en examinar para seleccionar el certificado que hemos solicitado previamenteDirectAccess_HA_20_11.png

DirectAccess_HA_20_12.png

Una vez que lo hemos seleccionamos nos podemos encontrar con el siguiente error, esto es porque existe un proceso de verificación del certificado en cuanto al nombre del mismo y debe resolverlo vía DNS.
DirectAccess_HA_20_13.png

Como previdamente no hemos creado ( o sí, yo no lo he creado para poder mostrar este error) el registro DNS (Tipo A o CNAME) en el sevidor DNS interno, por lo que debemos crear un registro DNS con el FQDN del sujeto del certificado (en mi caso: directaccess.asirsl.com) y la IP debe corresponderse con la del servidor de DirectAccess. Una vez que tengamos esto creado, volvemos a inciar el proceso de asignación del nuevo certificado al servidor DirectAccess y debería dejarnos continuar con la configuración y pulsamos en siguienteDirectAccess_HA_20_14.png

Por defecto el FQDN del certificado se agrega como sufijo de nombre  sin servidor DNS preferido, de tal forma que el equipo intentará resolver el nombre con sus propios DNS y sin el tunel IPSec de DirectAccess conectado. Pensad que este servicio de descubrimiento de servidor de ubicación de red se utilizar para saber si estamos dentro o fuera de la red corporativa y que nuestro equipo trate de conectarse, pulsamos en siguienteDirectAccess_HA_20_15.png

Pulsamos en Siguiente
DirectAccess_HA_20_16.png

Pulsamos en ulsamos en Finalizar

DirectAccess_HA_20_17.png

Y por últimos debemos pulsar en finalizar para publicar los cambios en las GPO correspondientesDirectAccess_HA_20_18.png

Pulsamos en Aplicar para finalizar el proceso
DirectAccess_HA_20_19.png

Si tenéis usuarios conectados vía DirectAccess tendrán que recibir la actualización de las directivas antes de poder volver a conectarse, tenerlo en cuenta antes de modificar la configuración. Ahora debemos exportar el certficado que hemos solicitado con el numbre nombre en este primer servidor de DirectAccess e importarlo en el almacén de certificados de equipo del otro servidor de DirectAccess. El proceso de importación es muy sencillo, pero igualmente voy a poner las capturas de pantalla (sin comentarios)

DirectAccess_HA_19.png

DirectAccess_HA_20.png

DirectAccess_HA_21.png

 

DirectAccess_HA_22.png
 
DirectAccess_HA_23.png
DirectAccess_HA_24.png
DirectAccess_HA_25.png
DirectAccess_HA_26.png
 
Además de este certificado, debemos tener importado también en todos los nodos del clúster el certificado utiizado para el IP-HTTPS y asignado a la interface pública. Por lo que debemos exportar el certificado (este certificado puede ser de una CA Pública) del servidor de DirectAccess que ya tenemos configurado e importarlo en el resto de servidores de DirectAccess antes de configurar el clúster

2. Creamos un registro DNS con el nombre del certificado asignado al primer servidor del clúster NLB

Esto es un paso muy sencillo, únicamente debemos ir al servidor DNS interno, abrir la consola de administración del servidor DNS y crear un registro Tipo A con los siguientes datos:

DirectAccess_HA_29.png

Esto es necesario para no encontrarnos con el error anterior de asignación del certificado de servidor de ubicación de red.

3. Si utilizamos máquinas virtuales en Hyper-V debemos habilitar la suplantación de dirección MAC en todos los servidores del clúster NLB

Esto debemos configurarlo para no tener problemas con el NLB y las direcciones MAC reales de las máquinas virtuales y cada interface de red.

DirectAccess_en_HA_1.png

4. Instalamos el ROL de Equilibrio de carga de red en los servidores del cluster (un máximo de 8 nodos)

Una vez que hemos habilitado la suplantación de dirección MAC en cada servidor de DirectAccess que formarán parte del clúster de Equilibrio de carga de red, debemos instalar justarmente esta esta característica de Equilibrio de carga en cada servidor. Para ello vamos a la consola de Administrador del Servidor – Administrar – Agregar Roles y Características y pulsamos en siguiente

DirectAccess_HA_10.png

Elegimos la  primera oción: Instalación basada en características o en roles y pulsamos en siguiente

DirectAccess_HA_11.png

Elegimos el servidor sobre el cual queremos agregar esta nueva característica y pulsamos en siguiente
DirectAccess_HA_12.png

DirectAccess_HA_13.png

En la sección de características seleccionamos Equilibrio de carga de red
DirectAccess_HA_14.png 

Pulsamos en Agregar características

DirectAccess_HA_15.png

Pulsamos en Siguiente

DirectAccess_HA_16.png

Pulsamos en Instalar

DirectAccess_HA_17.png

Una vez que finalice la instalación de la nueva características, pulsamos en Cerrar

DirectAccess_HA_18.png

Nota: Este mismo proceso debemos hacerlo en el resto de servidores que formarán parte del clúster

5. Instalamos el ROL de Acceso Remoto en el segundo servidor para configurar DirectAccess (pero no lo configuramos)

En el segundo servidor en el cual vamos a configurar el Acceso Remoto para configurar DirectAccess, debemos configurar el ROl de Acceso Remoto pero esto podéis verlo en este artículo: Windows Server 2012: DirectAccess (Actualizado 15-02-2013)

6. Configuramos el Configuramos el Equilibrio de carga en el primer servidor de DirectAccess

Hasta el momento tenemos dos servidores con el Rol de Acceso Remoto, pero solo uno configurado con DirectAccess. Ambos servidores los hemos unido al dominio y tienen el nuevo certificado instalado localmente. Esto lo vamos a necesitar porque el servicio de ubicación de red es algo común para todos los servidores de DirectAccess del clúster, y cuando alguno de ellos no esté disponible el otro debe tenerlo disponible para que los equipos puedan conectarse. También hemos configurado un registro DNS con el FQDN que hemos especificado en nombre común del certificado apuntando a la IP del servidor que ahora mismo tiene el DirectAccess configurado, y podemos comprobar que todo está correctamente configurado desde la consola de DirectAccess:

DirectAccess_HA_20_50.png
 
Además los dos servidores (máximo 8) que estarán en nuestro clúster tienen los siguientes direccionamientos IP:
 
SRV-DA00
  • Interface LAN: 192.168.250.96 /24
  • Interface WAN: 172.16.0.3 /27
SRV-DA01
  • Interface LAN: 192.168.250.92 /24
  • Interface WAN: 172.16.0.5 /27

Con todo esto configurado, debemos empezar la configuración del equilibrio de carga desde la consola de administración de DirectAccess y se iniciará un asistente que nos facilitará la configuración, pulsamos en siguiente

DirectAccess_HA_20_26.png

Como nuestra configuración la haremos basándonos en NLB de Windows, debemos elegir la primera opción: Usar el equilibrio de carga de red de Windows (NLB) y pulsamos en siguiente

DirectAccess_HA_20_27.png

Debemos especificar las direcciones IP dedicadas para el adaptador externo, debe ser una IP diferente  pero de la misma subred que la interface externa (IP actual 172.16.0.3) y que configurará a posteriori como la IP principal del servidor. Y la IP actual (172.16.0.3) se convertirá en la VIP (IP Virtual) asignada al clúster, por lo que la IP que escribiremos aquí será la IP que tendrá el servidor cuando se complete la configuración del NLB, pulsamos en siguiente

DirectAccess_HA_20_28.png

Y aquí lo mismo pero para la interface LAN, la IP que colocaremos aquí será la DIP que se asingará como principal en la red LAN del servidor, y la IP actual será la VIP del NLB, pulsamoe en siguiente

DirectAccess_HA_20_29.png
 
Ahora nos muestra un resumen de la configuración y pulsamos en Confirmar para completar la configuración
DirectAccess_HA_20_30.png
DirectAccess_HA_20_31.png

Sí todo se completa correctamente, se actualizarán las distintas GPO y NLB

DirectAccess_HA_20_32.png

Pulsamos en Cerrar
DirectAccess_HA_20_33.png

7. Añadimos el segundo servidor de DirectAccess (sin configurar) al Clúster de Equilibrio de carga

Debemos darle tiempo suficiente para que se complete la configuación (5 min debería ser suficiente) y una vez se haya completado la configuración, debemos agregar un servidor al clúster. Para ello abrimos la consola de administración de acceso remoto, pulsamos en Configuración  y en las opciones de las Tareas en la parte de la derecha pulsamos en Agregar o quitar servidores
DirectAccess_HA_20_34.png

 

Nos muestra el único servidor que tenemos en el clúster, así que pulsamos en Agregar servidor …

DirectAccess_HA_20_35.png

Escribiemos el nombre del servidor que queremos agregar (SRV-DA01.ASIRSL.COM en nuestro caso) y pulsamos en siguiente
DirectAccess_HA_20_36.png

Ahora nos muestra las interfaces que tiene conectadas el servidor y el certificado que utilizará para presentar a los clientes (debe ser el mismo en todos los servidores, yo lo he importado previamente), pulsamos en Siguiente

DirectAccess_HA_20_37.png

Seleccionamos el certificado que utilizaremos para el servidor de ubicación de red, y tiene que ser el mismo en todos los servidores. Este certificado es el que previamente hemos solicitado, configurado, exportar e importado en nuestros servidores de DirectAccess y pulsamos en siguiente
DirectAccess_HA_20_38.png
Nos muestra el resumen de la configuración realizada y si está todo correcto pulsamos en agregar
DirectAccess_HA_20_39.png
Pulsamos en cerrar
DirectAccess_HA_20_40.png
Ahora ya tenemos dos servidores en nuestro clúster de carga equilibrada, pulsamos en Confirmar para finalizar la configuración
DirectAccess_HA_20_41.png
 
Ahora actualizará de forma automática la configuración de DirectAccess y las políticas de cliente y servidor
DirectAccess_HA_20_43.png
En el visor de eventos podemos ver como se ha configurado el clúster NLB y nos informa del servidor activo
DirectAccess_HA_20_49.png

Y sí nos vamos al servidor de virtualización, podemos ver la configuración de las direcciones MAC una vez que hemos configurado nuestro clúster NLB

DirectAccess_en_HA_3.png

En cuestión de minutos podemos ver que el clúster está funcionando correctamente y cada uno de los nodos activos y sin errores
DirectAccess_HA_20_52.png

8. Comprobación del funcionamiento del Clúster de Equilibrio de Carga

Ahora podemos y debemos realizar ciertas tareas para verificar que todo está correcto, como hemos configurado NLB en los servidores tenemos la consola de  Administración de Equilibrio de carga de red
DirectAccess_HA_30.png
DirectAccess_HA_31.png
 
Si queremos realizar cualquier adaptación del clúster podemos hacerlo desde esta consola, por si en algún momento tenemos que modificar algúna dirección IP o comportamiento del NLB. Si accedemos a las propiedades del clúster de la red interna o externa podemos verificar los datos configurados:
DirectAccess_HA_33.png
 
Sí ahora desconectamos uno de los dos servidores, el otro se hará cargo de la conexiones de los clientes DirectAccess. En este caso he apagado el servidor SRV-DA00 (principal) y los clientes se han conectado al SRV-DA01
DirectAccess_HA_20_51.png
 
Como vemos en ocho pasos tenemos un clúster de NLB configurado para DirectAccess, sencillo y muy estable.
 

Espero que os sea de utilidad!!!

DirectAccess: Error Network Location Server

diciembre 23rd, 2013 | Posted by Santiago Buitrago in Directivas de Grupo - (0 Comments)

El servicio de ubicación de red en DirectAccess es el encargado de determinar si estamos dentro o fuera de la red corporativa, de ahí la importancia del mismo. Si este servicio no está correctamente configurado los equipos con DirectAccess no tendrán acceso a los recursos internos de la empresa ..

DirectAccess_Error_Network_Location_Server_1.png
El problema viene dado porque el certificado no es el correcto (debe corresponderse con el nombre del servidor), que haya caducado, que no se pueda poner en contacto con la CRL o no está asociado a la interface correta. Teniendo esto en cuenta, únicamente debemos verificar que todo esto lo hemos chequeado y que todo está bien. Si hemos utilizado nuestra CA Internet (Windows Server 2012, Instalación de una CA) debemos configurar correctamente la URL de la publicación de la CRL y además que el cliente pueda tener acceso a él. En el certificado que nos presenta el servidor (el cual hemos configurado previamente) se indica cual es la ubicación de la CRL:
 
DirectAccess_Error_Network_Location_Server_5.png
Esta configuración en vuestra CA se realiza configurando las extensiones
DirectAccess_Error_Network_Location_Server_6.png
 
Una vez que habéis configurado correctamente las extensiones, que podéis resolver a nivel de DNS la URL en donde está la CRL , debemos volver a emitir un certificado al servidor de DiretAccess. Una vez que lo tenemos en el almacén de certificados de equipo local, vamos a configurarlo desde la consola de administración de DirectAccess:
DirectAccess_Error_Network_Location_Server_8.png
Pulsamos en Examinar
DirectAccess_Error_Network_Location_Server_7.png

y seleccionamos el certificado correcto que acabamos de emitir
DirectAccess_Error_Network_Location_Server_9.png

Finalizamos la configuración y desde la consola de administración de DirectAccess nos vamos a la opción Panel de Estado y podremos observar cuando termine de actualizar la configuración que se ha resuelto el problema
DirectAccess_Error_Network_Location_Server_2.png

Como podéis aprecicar no tiene mucha historia este "problema", siempre y cuando tengamos nuestra CA en condiciones a todos lo niveles.

 
Espero que os sea de utilidad!!!

AnyConnect was not able to establish a connection to the specified secure gateway

diciembre 23rd, 2013 | Posted by Santiago Buitrago in Lync Server - (0 Comments)

Sí sois de los que utilizáis el cliente Cisco AnyConnect en Windows 8 es posible que os hayáis encontrado con este problema:

​Cisco_VPN_SSL_Error_1.png
Es igual que otro que os había comentado si utilizáis el cliente VPN IPSec de Cisco (Cisco Secure VPN Connection Terminated Locally by Client), y es tan parecido que la solución también es muy parecida. Debemos acceder al registro y modificar una clave que tiene una cadena de texto errónea. Para ello abrimos el registro de nuevo equipo (Inicio – Ejecutar – Regedit) y nos vamos a la rama Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vpnva
Cisco_VPN_SSL_Error_2.png
Si editamos la variable DisplayName veremos que tiene una serie de caracteres que debemos borrar @oem20.inf,%vpnva_Desc%;Cisco AnyConnect VPN Virtual Miniport Adapter for Windows x64
Cisco_VPN_SSL_Error_3.png
Y quedaría así
Cisco_VPN_SSL_Error_4.png

Ahora probamos a conectar y veremos que nos conecta perfectamente

Cisco_VPN_SSL_Error_5.png
 
Espero que os sea de utilidad!!!

GPO: Asignar un dominio predeterminado para iniciar sesión

diciembre 9th, 2013 | Posted by Santiago Buitrago in Directivas de Grupo - (0 Comments)

Desde Windows Vista (de forma nativa) tenemos una opción muy interesante para especificar el dominio predeterminado para iniciar sesión desde una GPO de nuestro dominio. Esto es muy interesante cuando tenemos varios dominios o cuando hemos configuración una relación de confianza entre dominios de distintas empresas. Es posible que existan nombres de usuarios que sean iguales en ambos dominios, por iguales me refiero únicamente al nombre del usuario excluyendo la parte del dominio. Desde Windows Vista ya no elegimos el dominio al que nos queremos conectar al iniciar sesión, simplemente introducimos nuestro nombre de usuario y si existe en local tratará de iniciar sesión con esta cuenta local o sino existe con el dominio por defecto a menos que escribamos el nombre de dominio con el formato de correo electrónico, ahí sabrá perfectamente a que dominio nos queremos conectar. Pero para evitar confusiones por parte de los clientes cuando se da la circustancia de que el último usuario que ha iniciado sesión en el equipo lo haya hecho en local o bien que se haya conectado a otro dominio de los disponibles, es posible que querramos establecer el dominio predeterminado para iniciar sesión, para esto tenemos la siguiente directiva a nivel de equipo: Asignar un dominio predeterminado para iniciar sesión bajo la siguiente ruta de la directiva: Configuración del equipo – Plantilas administrativas – Sistema – Inicio de sesión. Debemos escribir el nombre del dominio al cual por defecto se conectará el usuario que puede ser diferente al que se ha unido el equipo:

GPO_Dominio_predeterminado_para_iniciar_sesion_1.png
 
Si esto mismo queremos configurarlo para los equipos en Windows XP debemos crear la siguiente clave en el registro vía GPO:
 
Key: HKLM\software\microsoft\windows nt\currentversion\winlogon\
Value: defaultdomainname (REG_SZ)
Data: NOMBRE_DOMINIO
 
GPO_Dominio_predeterminado_para_iniciar_sesion_2.png
GPO_Dominio_predeterminado_para_iniciar_sesion_3.png
 
Cada una de las directivas de las aplicaremos a las OU en donde tenemos los equipos a los cuales queremos aplicar esta configuración, de esta forma los usuarios tendrán el dominio por defecto al que se tienen que contectar.
 
Espero que os sea de utilidad!!!