Todos sabemos la importancia de SYSVOL en nuestra infraestructura de Active Directory. Cuidar la salud y estabilidad de nuestro directorio pasa obligatoriamente por comprobar el buen estado de replicación de esta carpeta compartida distribuida. La correcta aplicación de los GPOs en nuestra infraestructura depende fundamentalmente de que esta replicación se efectúe de forma correcta.

Herramientas como dcdiag.exe o el visor de eventos, nos ponen en guardia cuando se presenta algún tipo de dificultad en esta replicación. La cuestión que podríamos plantearnos sería: ¿Por qué se cae la replicación de SYSVOL tan frecuentemente?

Coloquialmente usamos esa expresión: “Se me ha caído el SYSVOL”, pero como siempre, entre el blanco y el negro hay muchos grises. SYSVOL ha utilizado siempre el protocolo FRS (File Replication Service), que además de realizar la replicación de forma eficiente, es capaz de recuperarse de la mayoría de los problemas de replicación, por ejemplo, los relacionados con caídas esporádicas de algún DC o de la infraestructura de comunicaciones.

No obstante, algunos de nosotros nos hemos enfrentado a la situación más desagradable de todas, que no es otra, que la incapacidad de SYSVOL para recuperarse. Salimos del paso realizando la típica restauración autorizada de SYSVOL, un procedimiento que debe emplearse para solventar este problema y, en cualquier caso, conocerse por si se diera el caso.

Pero vayamos a la raíz del problema. FRS es un protocolo que llegó a su plena madurez en época de Windows Server 2003 R2. Hoy en día se considera un protocolo obsoleto, entre otras razones porque Microsoft hace muchos años que no ofrece parches, y esto también podría llegar a ser un problema de seguridad. La razón de esto es que Windows Server 2008 nos presentó un nuevo protocolo para realizar la replicación de SYSVOL. Este protocolo es DFS-R (Distributed File Service Replication)

DFS-R es un protocolo moderno, vivo, al que Microsoft le da soporte pleno. Mejora los aspectos más débiles de FRS, por lo que los problemas mencionados relativos a la replicación ya son cosas del pasado.

Pero, a pesar de que tengas tus controladores de dominio en versión 2012R2 o 2016, ¿No seguirás replicando tu SYSVOL con FRS?

Imagínate en el escenario de un bosque nuevo. En este caso tendrás que crear tu primer controlador de dominio, que será el responsable de engendrar el propio bosque y el dominio de primer nivel. Bien, si eliges la versión 2008, 2008R2, 2012, 2012R2 o 2016 para este DC, el instalador del rol elegirá DFS-R como protocolo de replicación por defecto. Asunto zanjado.

La cuestión es que raramente vivimos este escenario, más bien, nos encontramos en uno del que venimos migrando desde tiempos inmemoriales (NT, 2000), que por supuesto usa FRS como protocolo de replicación.

En definitiva, aconsejamos acometer la migración de la replicación de SYSVOL lo antes posible por estas dos razones:

• Dotamos a nuestro directorio de un protocolo de replicación más robusto, seguro y eficiente.
• Pero, sobre todo, porque Windows Server 2019 solo replica SYSVOL mediante DFS-R. No podríamos agregar controladores de dominio de 2019.

El procedimiento de migración de SYSVOL es relativamente sencillo. Se utiliza una herramienta llamada dfsrmig (también existe su contrapartida en PowerShell) y básicamente consiste en lo siguiente.

1. Partimos de que nuestros DCs están replicando correctamente, tanto las particiones de Active Directory como SYSVOL por medio de FRS.
2. Que el nivel funcional del bosque sea al menos 2008. Esto garantiza que hemos retirados los DCs de 2003, que no pueden replicar por DFS-R. dfsrmig es una herramienta de uso asíncrono, es decir, al lanzarla, insta a los DCs a realizar ciertos cambios, pero no tenemos feedback del resultado, por lo que debemos volver a ejecutarla cada cierto tiempo para comprobar si esos cambios se han efectuado en todos los DCs.
3. En primer lugar, pasamos al estado de migración conocido como PREPARED, donde dfsrmig indica a los DCs que creen una carpeta llamada SYSVOL-DFSR.
4. A continuación, forzamos el cambio al estado REDIRECTED. Los GPOs se copian de la carpeta SYSVOL original de cada DC a la nueva carpeta SYSVOL-DFSR. La replicación DFSR-R comienza a funcionar, pero ADDS sigue utilizando el SYSVOL antiguo.
5. Cuando todos los DCs han informado que han alcanzado el estado redireccionado, podemos pasar al último, que se llama ELIMINATED. Una vez que todos los DCs alcancen este estado, se detiene el servicio FRS y se elimina la carpeta SYSVOL original.

Por supuesto que este procedimiento tiene detalles que no he comentado, pero a groso modo este sería así. Una vez realizado ya podrás agregar tus DCs de 2019 o quedarte más tranquilo respecto a la replicación de SYSVOL.

¿A qué esperas para ponerlo en práctica?