Migración SYSVOL de FRS a DFSR: verificar cada DC antes de Eliminated

¿Qué es la migración SYSVOL de FRS a DFSR?

Una migración SYSVOL de FRS a DFSR cambia la forma en que los controladores de dominio replican los archivos utilizados para las directivas de grupo y los scripts de inicio de sesión. La tarea necesita un procedimiento para todo el dominio: establecer el estado actual, validar la replicación en cada controlador de dominio y avanzar solo cuando las pruebas justifiquen la siguiente etapa.

Revisión técnica: 4 de octubre de 2026. Los comandos siguientes son ejemplos basados en la documentación; no se ejecutaron en un dominio de producción.

File Replication Service (FRS) está en desuso, como indica la documentación de Microsoft sobre la retirada de FRS. DFS Replication (DFSR) pasó a estar disponible para SYSVOL en el nivel funcional de dominio Windows Server 2008. La guía actual de migración de SYSVOL sigue siendo el punto de partida del proceso admitido.

Trate esta tarea como un proyecto de configuración y disponibilidad. Una señal de replicación antigua no demuestra un ataque, un controlador comprometido ni una GPO que no funcione. Del mismo modo, la ausencia de hallazgos no puede autorizar un cambio irreversible. Decida qué pruebas necesita el responsable del dominio antes de programar el trabajo.

Este proyecto debe acompañar a la planificación de la actualización de controladores de dominio Windows Server 2016, que abarca los sistemas operativos y los niveles funcionales. Conserve pruebas separadas para la migración SYSVOL: sustituir un DC o revisar su sistema operativo no constituye un registro del estado de migración de todos los controladores.

Cómo funciona: dirección global y convergencia local

El emulador de PDC mantiene la dirección de migración establecida mediante dfsrmig /setglobalstate. Cada controlador de dominio debe alcanzar su estado local correspondiente. Por tanto, un comando que cambia la dirección global es el inicio de una fase, no una prueba de que todos los controladores la hayan completado.

La referencia de Microsoft sobre los estados de migración SYSVOL describe estas etapas estables:

Los estados locales pueden ser transitorios mientras avanza el trabajo. Mantenga visibles en el registro de migración los controladores desconectados, inaccesibles o todavía en transición. No los elimine de la lista de aceptación para que el cambio parezca completo.

Detección: crear un registro de estados antes de cambiar nada

Leer el estado global en el emulador de PDC

Ejecute este comando de consulta en el emulador de PDC, como exige la referencia del comando dfsrmig:

dfsrmig /getglobalstate

Después, recopile el informe de convergencia de todo el dominio:

dfsrmig /getmigrationstate

El primero lee el estado global del dominio. El segundo compara los estados locales con esa dirección e informa de los controladores que no la han alcanzado. La referencia del comando advierte de que leer el estado global en otro controlador puede producir información incoherente debido a la latencia de replicación de AD.

Interpretación ilustrativa, no una salida observada: un estado global Prepared con un controlador todavía en Start o en un estado de transición significa que el control de aceptación de Prepared sigue pendiente. Un estado global Redirected con todos los estados locales coincidentes satisface la comprobación de estado, pero aún requiere validar los recursos compartidos y la replicación. Un estado global Eliminated sin un informe de convergencia utilizable constituye una prueba incompleta, no una finalización verificada.

En cada captura, registre el dominio, la identidad del PDC, el inventario de controladores, la hora de recopilación, el comando y su salida completa. Un controlador inaccesible necesita un responsable y un plan de resolución. Conserve las capturas anteriores para que los revisores puedan distinguir el progreso de un cambio en el inventario.

Revisar las pruebas de suscripción LDAP y de servicios

El proveedor de etc-collector inspeccionado intenta una búsqueda LDAP de subárbol bajo su DN base configurado con el siguiente filtro, solicitando cn y conservando como máximo un resultado en el cliente:

(&(objectClass=nTFRSSubscriber)(name=Domain System Volume (SYSVOL share)))

Este es el filtro literal del proveedor, presentado como prueba del código y no como un comando de cliente LDAP listo para ejecutar. En la revisión del collector inspeccionada (42bfefb), los paréntesis del valor del nombre no están escapados. Una comprobación local exclusiva del analizador con la dependencia declarada go-ldap v3.4.12 devolvió Filter Compile Error; la solicitud de búsqueda no se puede codificar con este filtro. No se ejecutó ninguna consulta LDAP de producción para esta revisión.

Este defecto de recopilación deja el indicador FRS en false en el proveedor inspeccionado. Incluso después de que una consulta corregida devuelva correctamente un objeto de suscripción, ese objeto por sí solo no identificaría todos los controladores, no establecería qué servicio sirve actualmente SYSVOL ni descartaría un resto de la migración.

En cada DC, registre también en Services el estado y la configuración de inicio del servicio File Replication (NTFRS) y del servicio DFS Replication (DFSR). Correlacione esas observaciones con el estado de migración y la asignación real de recursos compartidos. Un servicio en ejecución por sí solo no demuestra una replicación SYSVOL correcta.

Utilice una pequeña matriz de pruebas en lugar de una única marca verde:

Distinga los fallos de recopilación de los resultados negativos en su registro operativo. Este artículo no proporciona ninguna consulta de ataque ni identificador de evento de Windows; la decisión se basa en pruebas de migración y replicación.

Corrección: avanzar por controles documentados (Remediation)

Paso 1 — Inventario, requisitos previos y preparación para la recuperación

Designe al responsable del dominio y al operador del cambio. Inventaríe todos los DC de escritura y RODC, incluidos los sitios remotos y los sistemas temporalmente desconectados. Registre el emulador de PDC, el nivel funcional, la compatibilidad de los sistemas operativos y la ubicación de SYSVOL. Confirme los requisitos previos con la guía de migración actual y las versiones realmente instaladas.

Antes de empezar, el procedimiento de Microsoft para el estado Prepared exige comprobaciones del estado de replicación, espacio suficiente para la copia SYSVOL, el servicio DFS Replication en ejecución con inicio automático y copias de seguridad del estado del sistema. También recomienda evitar cambios en las GPO y en los scripts de inicio de sesión hasta que todos los controladores alcancen Redirected.

Documente las ubicaciones de las copias de seguridad y las responsabilidades de recuperación. Acuerde cómo se suspende el cambio si falla una comprobación, quién lo diagnostica y qué pruebas permiten reanudar el trabajo. No considere la existencia de una tarea de copia de seguridad como una prueba de recuperación satisfactoria.

El procedimiento incluye estos ejemplos de consulta por separado:

net share

repadmin /ReplSum

Ejecute net share en cada DC e inspeccione las asignaciones SYSVOL y NETLOGON. Revise la replicación AD y la replicación SYSVOL de manera independiente. Resuelva los fallos existentes antes de iniciar la migración; una transición de estado no debe convertirse en un intento de reparar un problema de replicación sin explicar.

Paso 2 — Control de aceptación de Prepared

Ejemplo que cambia el estado: utilícelo solo después de las comprobaciones iniciales y la aprobación del cambio. En el emulador de PDC:

dfsrmig /setglobalstate 1

Recopile nuevos informes de estado global y de estado de migración. No continúe hasta que todos los controladores hayan alcanzado Prepared. Verifique la copia DFSR y su replicación como se describe en el procedimiento Prepared.

Mantenga una entrada de aceptación explícita por controlador. Registre las excepciones pendientes con la persona responsable, no como una observación informal fuera del registro de cambio. Si se introduce un nuevo RODC durante la migración, consulte su tratamiento documentado antes de continuar; no añada comandos genéricos de creación o eliminación de objetos a un procedimiento habitual.

Paso 3 — Control de aceptación de Redirected

Ejemplo que cambia el estado: utilícelo solo después de la convergencia Prepared y de validar el estado de funcionamiento. En el emulador de PDC:

dfsrmig /setglobalstate 2

El procedimiento para el estado Redirected exige estados locales coherentes antes de Eliminated. Valide las asignaciones SYSVOL y NETLOGON en cada DC y el estado de DFSR; conserve las pruebas del estado de FRS mientras siga siendo pertinente la reversión.

Añada una comprobación de aceptación operativa: los clientes representativos de los sitios afectados deben obtener las directivas y los scripts esperados. Registre los clientes y las directivas elegidos, las horas de recopilación y los resultados. Es una tarea de validación propuesta, no una afirmación de que se haya probado el procesamiento del cliente para este artículo.

Paso 4 — Aprobar Eliminated por separado

El procedimiento para el estado Eliminated exige una verificación Redirected satisfactoria y estados coherentes en todos los controladores. Revise la replicación AD, conserve copias de seguridad en los estados estables y confirme que el responsable del dominio acepta perder la reversión de la migración.

Ejemplo irreversible que cambia el estado: no es una recomendación inmediata para un dominio desconocido. En el emulador de PDC, solo después de aprobar ese control:

dfsrmig /setglobalstate 3

Recopile nuevos informes de estado global y de estados locales. Vuelva a verificar las asignaciones de recursos compartidos SYSVOL y NETLOGON, la replicación DFSR y el procesamiento de directivas. Revise cualquier uso restante del servicio FRS antes de retirarlo: el procedimiento de Microsoft condiciona la detención y deshabilitación de FRS a si sirve para otros fines además de SYSVOL.

Registre la decisión final y las pruebas, incluidas las anomalías pendientes. No convierta la limpieza de objetos LDAP en un sustituto de la verificación en ejecución.

Cómo detecta EtcSec esta configuración

La comprobación DFSR_NOT_CONFIGURED de EtcSec está implementada en ad/network/dfsr.go de etc-collector. Su método Detect() evalúa la información de dominio recopilada:

El código asocia el nivel 3 con Windows Server 2008. Count es una señal de dominio, no el número de DC afectados. El proveedor solo establece el indicador FRS cuando su búsqueda LDAP limitada tiene éxito y devuelve un objeto. Un error o un resultado vacío deja el indicador en false, sin un indicador separado de error de recopilación en esta señal. En la revisión inspeccionada, el filtro mal formado descrito antes sigue esa ruta de error: esta ruta de recopilación deja UsingNTFRSForSYSVOL en false, por lo que Detect() devuelve Count 0 aunque el dominio utilice realmente FRS.

Un objeto de suscripción residual puede permanecer después de la migración. Por tanto, un resultado positivo es un motivo para contrastar LDAP con dfsrmig, las observaciones de servicios y las pruebas de recursos compartidos. No demuestra el servicio de replicación efectivo ni un ataque.

El detector no lee los estados globales ni locales de dfsrmig, el estado de DFSR, la convergencia de replicación ni los resultados de directivas del cliente. Count 0 no demuestra que DFSR funcione correctamente ni que la migración esté completa. Su texto de recomendación es un consejo; no significa que se haya ejecutado un comando de comprobación o una migración.

Cerrar el cambio con la higiene del contenido

Replicar SYSVOL mediante DFSR no elimina los secretos de sus archivos. Mantenga la revisión de secretos cPassword de GPO en SYSVOL como una tarea de contenido separada, con la gestión de credenciales y la limpieza bajo responsabilidades independientes del cambio de replicación.

Conserve un paquete final de pruebas que contenga el inventario, las copias de seguridad, el estado inicial, las comprobaciones de convergencia y funcionamiento de cada control, la decisión Eliminated si se tomó y la verificación final de recursos compartidos y directivas. Contraste el resultado del collector con ese paquete y documente cualquier prueba LDAP obsoleta o limitación de recopilación.

La decisión de finalización debe poder ser revisada por alguien que no haya ejecutado los comandos. Si queda sin resolver un controlador, una observación de servicio o una comprobación de directivas, indique explícitamente esa limitación y mantenga abierta la acción operativa correspondiente.