Migrar Nuestro Servidor de DirectAccess de Windows Server 2012 R2 a Windows Server 2016

Algo con lo que estamos todos los IT PRO muy acostumbrados es a “sudar en frío” cuando alguien nos dice … queremos migrar a nueva versión de xxxxx.  En muchos casos las migraciones son complejas, bien porque hay muchos servicios dependientes de la plataforma a migrar, porque hay muchos interlocutores a coordinar en la migración o simplemente porque es un proceso complejo en si mismo. En este caso, me gustaría comentaros mi experiencia con una migración de DirectAccess, la cual espero que os ayude a vosotros cuando os llegue el momento.

En  mi caso, lo que queríamos hacer era migrar nuestro servidor de DirectAccess en Windows Server 2012 a Windows Server 2016 sin que los usuarios se vieran afectados, puesto que además, muchos de ellos están por todo el mundo conectados a DirectAccess. La razón de la migración en nuestro caso, ha sido porque queríamos jubilar los HOST de virtualización de Hyper-V a una nube privada con un proveedor externo con VMWare. La instalación del primer servidor de DirectAccess es  muy sencilla, para los que no lo hayáis hecho nunca, aquí os dejo algunos artículos que he publicado en su momento:

Windows Server 2012: DirectAccess (Actualizado 15-02-2013)

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

Cómo unir un equipo a un dominio sin conexión y además configurarlo para DirectAccess

Espero que estos artículos a los que no hayáis podido probar DirectAccess o animen a hacerlo, es un servicio muy sencillo de configurar y muy potente.

Ahora que ya tenemos claro que es DirectAccess, como se configura y cual es su utilidad, veamos como es el proceso de migración. Lo primero comentaros, que no es una migración al uso de versión, sino que podemos convivir con más de un servidor de DirectAccess en nuestro dominio. Esto, claramente facilita todo el proceso, puesto que podemos configurar una nueva topología de DirectAccess y aplicarla a los equipos que queramos. Para ello, debemos tener en cuenta a varias cosas:

• Realizar backup de las GPO actuales para el servidor de DirectAccess actual
• Cuando configuremos la nueva topología de DirectAccess debemos crearlas con nombres diferentes a las GPO actuales, sino machacaremos las configuraciones actuales y queremos que todos los clientes se conecten al servidor actual de DirectAccess
• Crearemos grupos de seguridad nuevos para filtrar a quien se aplica la configuración de cliente del nuevo DirectAccess
• Los NLS los configuraremos hacia los controladores de dominio (test vía PINGo HTTP) u otros servidores que consideréis que siempre estarán activos en la red
• 1 IP Pública disponible en nuestro firewall para publicar el puerto 443 hacia la IP de la interface Externa (o interna si sólo tiene una tarjeta de red) del servidor de DirectAccess nuevo
• Cambiar el nombre de la conexión que creará en los equipos clientes de DirectAccess, para que sepáis desde el cliente que estáis tenéis la nueva configuración
• El certificado utilizado para DirectAccess, si tenéis un wildcard podéis utilizar el mismo en caso contrario, es cuestión de adquirir el que necesitamos con en el nuevo FQDN que hemos configurado en la nueva topología de DirectAccess

En cuanto a la topología de DirectAccess con respecto a la ubicación en la red, etc… es indistinta (siempre con unos mínimos), pero aquí os muestro algo de lo que nosotros hemos migrado:

Como podéis apreciar, los clientes (rojos) se conectan al servidor de DirectAccess (rojo) actual, y los clientes (verdes) se conectan al nuevo servidor de DirectAccess (verde). Todo están en el mismo bosque y dominio, es totalmente compatible con ello. Me repito, el proceso de configuración es muy simple, únicamente debemos fijarnos muy mucho en las siguientes opciones:

Importante, cuando inicies el asistente configuración y tengáis que publicar la configuración, fijaros que cambiáis el nombre de las GPO de configuración del servidor y clientes de DirectAccess, sino si que tendréis un problema. El resto es trivial, porque el FQDN a donde se conectarán los clientes de DirectAccess tiene que ser diferente a la actual, sino claramente no funcionará el cambio. El resto ya son configuraciones básicas, las cuales son en base vuestras propias configuraciones. Una vez que tengamos la publicación de la configuración finalizada, lo que haremos será  crear una OU en donde vincularemos la GPO Configuración del cliente de DirectAccess W2016 (en mi caso es esta, en vuestro caso el nombre que le pongáis). En esta OU, será donde iremos moviendo los equipos para que se les vaya aplicando la nueva GPO, de tal forma que les configurará la nueva conexión de DirectAccess. Bien, pero .. que ocurre con la otra GPO que también se nos está aplicando? Yo para evitar posibles problemas  de pérdida de conexión con el servidor de DirectAccess, tenía otra OU en donde tenía aplicada la GPO de clientes del actual (o antiguo) servidor de DirectAccess, por lo que en cuanto movemos a un equipo de OU, ya dejará de aplicarse la directiva antigua y se le aplicará la nueva:

De esta forma, me aseguro que no se le aplica la antigua y si la nueva. También la podemos aplicar en la misma OU de Portátiles (equipos conectados al antiguo servidor de DirectAccess) y poner la GPO Configuración del cliente de DirectAccess W2016 después de la Configuración del cliente de DirectAccess  para que fuese la última en aplicarse, pero yo he prefiero tener que mover los equipos poco a poco y así evitar que les afectase a todos y tuviéramos algún problema de conexión. Comentaros, que en la GPO no la he filtrado por ningún grupo de seguridad, algo que en DirectAccess lo hacéis aquí:

Y si lo vemos en la GPO, lo vemos desde aquí:

Esto también es algo que debéis tener en cuenta, puesto que como sabéis, las GPO de DirectAccess se establecen por defecto a nivel de dominio, por lo que sino filtráis a quien se aplicará, por defecto lo hará a cualquier equipo (portátil). Yo lo que suelo hacer, es que como es una GPO para equipos, lo filtro inicialmente por Usuarios del Dominio y ya no tengo problemas en que se aplique a nadie. Luego, muevo la GPO hacia la OU que quiero y luego si cambio la configuración de a quien se aplicará dicha GPO.

Bien, una vez que tenemos la configuración de DirectAccess hecha, tenemos que probarla!! Para ello, he utilizado una máquina virtual con Windows 10 Enterprise que tengo en mi equipo, la cual está unida al dominio y ubicada en la OU Portátiles que habéis visto antes, lo que me permite estar conectado al servidor de DirectAccess “antiguo”, luego muevo el equipo de OU hacia la de MIGRACION DA y en el equipo ejecuto un GPUPDATE y reinicio el equipo, en el próximo inicio la máquina se ha migrado al nuevo servidor de DirectAccess!!

Ahora, únicamente toca ir moviendo al resto de equipos de OU para que se vayan aplicando la nueva GPO y se vayan conectando al nuevo servidor de DirectAccess. Si los equipos se pasan por las oficinas en donde estén conectados directamente al servidor de DirectAccess, mejor que mejor, porque nos aseguramos al 100% que se aplica la directiva y no habrá problemas. Si lo hacen desde Internet, yo instruyo a los usuarios en el momento del cambio para que ejecuten un GPUDATE y reinicien. De esta forma, me aseguro que sino le ha generado ninguna alerta la ejecución de GPUPDATE, se les ha aplicado la nueva configuración y no tendrán problemas en cambiarse de servidor de DirectAccess.

En cuanto a tener dos OU y cada una con su GPO correspondiente, es simplemente por evitar posibles problemas de que no se apliquen correctamente. Si las filtramos por grupos de seguridad, el equipo se tiene haber reiniciado por lo menos una vez y actualizar sus membresías correctamente, etc.. algo que puede (no es lo normal)  “fallar”, no porque la tecnología sino porque el usuario no haya reiniciado el equipo en días, semanas, etc.. que sólo lo hiberne, etc.. así me evito todo esto y encima controlo el proceso de migración poco a poco. Voy moviendo de OU los equipos y poco a poco veo como se van conectando al nuevo servidor de DirectAccess.

El proceso como veis es sencillo, simplemente tener cuidado con el nombre de las GPO, a quien se aplican y como aplicaréis las GPO a los equipos clientes. El resto ya es pan comido, se conectan, terminamos de migrar todo y ya podemos retirar el servidor de DirectAccess y eliminar las GPO de clientes y de servidor de DirectAccess antiguas.

Insisto, en mi caso el proceso ha sido limpio y transparente. Además, he probado a mover de OU mi equipo dos veces, para que me conectase al nuevo servidor de DirectAccess y luego volver al antiguo. En ambas ocasiones, todo ha ido bien, sin problema alguno.

Espero que os sea de utilidad!!!