Cómo forzar la sincronización autoritativa y no autoritativa para la replicación de sysvol replicada por DFSR
En este artículo se presenta cómo forzar una sincronización autoritativa y no autoritativa para la replicación de sysvol replicada por DFSR.
Se aplica a: Windows Server 2012 R2
Número KB original: 2218556
Resumen
Imagine la siguiente situación:
Desea forzar la sincronización no autoritativa de la replicación de sysvol en un controlador de dominio (DC). En el Servicio de replicación de archivos (FRS), se controlaba a través de los valores de datos D2 y D4 para los valores del Registro, pero estos valores no existen para el servicio de replicación de sistema de archivos Bur Flags distribuido (DFSR). No puede usar el complemento administración DFS (Dfsmgmt.msc) ni la herramienta Dfsradmin.exe línea de comandos para lograrlo. A diferencia de las carpetas replicadas de DFSR personalizadas, la replicación de sysvol está protegida intencionadamente de cualquier edición a través de sus interfaces de administración para evitar accidentes.
Cómo realizar una sincronización no autoritativa de replicación de sysvol replicada por DFSR (como D2 para FRS)
En ADSIEDIT. Herramienta MSC, modifique el siguiente valor y atributo de nombre distintivo (DN) en cada uno de los controladores de dominio (CONTROLADORES) que desea que no sea autoritativo:
CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name>,OU=Domain Controllers,DC=<domain> msDFSR-Enabled=FALSEForzar la replicación de Active Directory en todo el dominio.
Ejecute el siguiente comando desde un símbolo del sistema con privilegios elevados en los mismos servidores que estableció como no autoritativo:
DFSRDIAG POLLADVerá el identificador de evento 4114 en el registro de eventos DFSR que indica que la replicación de sysvol ya no se replica.
En el mismo DN del paso 1, establezca msDFSR-Enabled=TRUE.
Forzar la replicación de Active Directory en todo el dominio.
Ejecute el siguiente comando desde un símbolo del sistema con privilegios elevados en los mismos servidores que estableció como no autoritativo:
DFSRDIAG POLLADVerá el identificador de evento 4614 y 4604 en el registro de eventos DFSR que indica que se ha inicializado la replicación de sysvol. Ese controlador de dominio ha realizado ahora un D2 de replicación de sysvol.
Cómo realizar una sincronización autoritativa de replicación de sysvol replicada por DFSR (como D4 para FRS)
Establezca el tipo de inicio del servicio de replicación DFS en Manual y detenga el servicio en todos los controladores de dominio del dominio.
En ADSIEDIT. Herramienta MSC, modifique el siguiente DN y dos atributos en el controlador de dominio que desea hacer autoritativo (preferiblemente el Emulator de PDC, que suele ser el más actualizado para el contenido de replicación de sysvol):
CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name>,OU=Domain Controllers,DC=<domain> msDFSR-Enabled=FALSE msDFSR-options=1Modifique el siguiente DN y un atributo único en todos los demás controladores de dominio de ese dominio:
CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<each other server name>,OU=Domain Controllers,DC=<domain> msDFSR-Enabled=FALSEForzar la replicación de Active Directory en todo el dominio y validar su éxito en todos los controladores de dominio.
Inicie el servicio DFSR en el controlador de dominio que se estableció como autoritativo en el paso 2.
Verá el identificador de evento 4114 en el registro de eventos DFSR que indica que la replicación de sysvol ya no se replica.
En el mismo DN del paso 1, establezca msDFSR-Enabled=TRUE.
Forzar la replicación de Active Directory en todo el dominio y validar su éxito en todos los controladores de dominio.
Ejecute el siguiente comando desde un símbolo del sistema con privilegios elevados en el mismo servidor que estableció como autoritativo:
DFSRDIAG POLLADVerá el identificador de evento 4602 en el registro de eventos DFSR que indica que se ha inicializado la replicación de sysvol. Ese controlador de dominio ha realizado ahora una D4 de replicación sysvol.
Inicie el servicio DFSR en los otros DCs no autorizados. Verá el identificador de evento 4114 en el registro de eventos DFSR que indica que la replicación de sysvol ya no se replica en cada uno de ellos.
Modifique el siguiente DN y un atributo único en todos los demás controladores de dominio de ese dominio:
CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<each other server name>,OU=Domain Controllers,DC=<domain> msDFSR-Enabled=TRUEEjecute el siguiente comando desde un símbolo del sistema con privilegios elevados en todos los DCs no autoritativo (es decir, todos menos el anteriormente autoritativo):
DFSRDIAG POLLADDevuelve el servicio DFSR a su tipo de inicio original (automático) en todos los equipos.
Más información
Si establece la marca autoritativa en un controlador de dominio, debe sincronizar de forma no autoritativa todos los demás controladores de dominio del dominio. De lo contrario, verá conflictos en los DCs, que se originaron en los DCs en los que no estableció auth/non-auth y reinició el servicio DFSR. Por ejemplo, si todos los scripts de inicio de sesión se eliminaron accidentalmente y se volvió a colocar una copia manual de ellos en el titular de roles Emulator PDC, hacer que ese servidor sea autoritativo y el resto de servidores no autorizados garantizaría el éxito y evitaría conflictos.
Si hace que cualquier DC autoritativo, el PDC Emulator como autoritativo es preferible, ya que su contenido de replicación de sysvol está más actualizado.
El uso de la marca autoritativa solo es necesario si necesita forzar la sincronización de todos los DCs. Si solo repara un controlador de dominio, haga que no sea autoritativo y no toque otros servidores.
Este artículo está diseñado con un entorno de 2 DC en mente, para simplificar la descripción. Si tenía más de un controlador de dominio afectado, expanda los pasos para incluir todos ellos también. También supone que tiene la capacidad de restaurar datos eliminados, sobrescritos, dañados, y así sucesivamente. anteriormente si se trata de un escenario de recuperación ante desastres en todos los controladores de dominio del dominio.