Solucionar problemas de replicación de SYSVOL

viernes, 18 de julio de 2014

En este artículo veremos cómo solucionar problemas de replicación del volumen del sistema o SYSVOL, este tipo de errores pueden detectarse de la siguiente forma:
Al realizar un gpupdate desde alguna estación cliente podemos recibir un mensaje de error que indica que ha fallado el procesamiento de la directiva de grupo:
"The processing of Group Policy failed. Windows attempted to read the file from a domain controller and was not successful."


Esta es una forma de detectar el error, la otra puede ser realizando un simple ejercicio, y se trata de observar el contenido de la carpeta SYSVOL en dos controladores de dominio, con lo cual se puede apreciar la existencia de diferencias, de igual forma si copiamos por ejemplo un archivo de texto en Servidor 1, podemos notar que no será replicado a Servidor 2


Si el contenido de la carpeta SYSVOL no se está replicando se experimentarán problemas con la aplicación de las directivas configuradas.
Antes de intentar corregir este inconveniente con la carpeta SYSVOL es recomendable realizar antes un análisis de la replicación en general entre los controladores de dominio para descartar que el problema solamente es a nivel de replicación de SYSVOL.
Lo primero que debemos hacer, es verificar los registros de eventos asociados a File Replication Service


Y allí debemos buscar con los eventos con ID 13568:
The file replication service has detected that the replica set is in jrnl_wrap_error
This indicates that the service is in a journal wrap state. Once you identify the DC that is in journal wrap condition, we must re-initializing SYSVOL replication. Before we start, we need to determine whether replication is being done by FRS (also known as NTFRS) or DFS-R.


El error básicamente lo que está indicando es que el servidor ha caido en un estado "journal wrap",  y en esencia cuando habla de journal se está refiriendo más exactamente al sistema de archivos, es decir a NTFS, y más específicamente a una característica de este sistema llamada NTFS Journal ó USN Journal, que de forma muy resumida se encarga de llevar un registro de los cambios hechos en un volumen con formato NTFS, y pues la replicación se basa en estos registros para saber qué información debe enviar al otro servidor (hablando en términos de SYSVOL), entonces al encontrarnos con este estado significa que hay inconsistencias entre el contenido del registro de un servidor con respecto al otro, las posibles causas de esto son las siguientes:
  • Se ha formateado el volumen
  • Se ha eliminado el registro NTFS USN journal del volumen o se ha truncado mediante una aplicación del comando chkdsk (el cual pudo encontrar entradas corruptas al final del journal).
  • El servicio de replicación se ha detenido por un período de tiempo prolongado.
El error también indica que una vez identifiquemos el servidor que ha caído en este estado (evento 13568), debemos reinicializar la replicación SYSVOL, además indica que se debe identificar cuál mecanismo de replicación se está usando FRS ó DFSR, pues entonces antes de iniciar de reiniciar la replicación SYSVOL revisemos cuál de los dos métodos estamos usando, para evitar esta revisión puede tener en cuenta lo siguientes, si está usando una edición de Windows anterior a 2008, por ejemplo 2003, la replicación será FRS, si está usando 2008 o superior será DFSR, pero atención!!! si tiene Windows Server 2008 pero fue actualizado desde una versión 2003 la replicación será FRS, aunque se puede migrar a DFSR, pero esto no lo trataremos aquí, sin embargo iniciemos el proceso de revisión.
Debemos ingresar a la siguiente rama del registro: 
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrating Sysvols\LocalState
Si el valor de la llave LocalState es 3, se está usandeo DFSR, si la llave no existe o tiene un valor diferente a 3 se está usando FRS.


En este caso, podemos observar que el valor es 0, pero se trata de un 2008 que fue migrado desde 2003, lo cual tiene sentido, por lo cual el método de reinicialización de SYSVOL que usaremos será para FRS.
Antes de iniciar el proceso es importante  determinar las causas del problema, ya que de otra forma no servirá de mucho hacer la reparación ya que pronto se volverá a presentar, por ello es importante por lo menos tener en cuenta lo siguiente:
  • Verificar que el servicio FRS ó DFSR según el caso, se encuentren corriendo.
  • Verificar que hay conectividad entre los servidores, mediante ping a la IP y al FQDN
  • Verificar que el servicio RPC esté arriba y que no exista un firewall bloquendo los puertos 135 y 445
  • Verificar que no exista lentitud en el canal de comunicación.
  • Verificar que no existan problemas físicos de disco duro o de memoria
  • Garantizar que los DC no pierdan conexión entre sí por períodos prolongados de tiempo.
La necesidad de identificar si se trata de replicación FRS ó DFSR se debe a que el proceso de reinicialización es diferente para cada una, debido a que hemos identificado que la replicación es FRS iniciaremos con este proceso.
Reinicializar carpeta SYSVOL en sistema con replicación FRS
Para este caso tenemos dos tipo de replicación de SYSVOL autoritativa y no autoritativa.
Es recomendable siempre intentar la no autoritativa, para ello debemos garantizar conectividad con otro servidor que del cual deseamos replicar la información que necesitamos.
El primer paso es detener el servicio de replicación a través del comando net stop ntfrs


Luego abrir la siguiente rama desde el editor del registro.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup


Debemos modificar el valor de la llave BurFlags el cual se encuentra establecido en 0 a D2, con lo cual la llave queda de la siguiente manera:


Con esto le hemos indicando al sistema que se trata de una restauración no autoritativa de SYSVOL., en este artículo no se tratará la restauración autoritativa
Por último volvemos a iniciar el servicio de replicación con el comando net start ntfrs


Después de esto el proceso puede tardar varios minutos dependiendo de la cantidad de información a replicar, al finalizar se generará un evento 13516


De esta forma hemos terminado de restablecer la replicación SYSVOL con FRS

Reinicializar carpeta SYSVOL en sistema con replicación DFSR

Para este caso no he generado screenshots ya que el problema se presentó en un servidor con FRS, sin embargo pondré los pasos.
1. Debemos abrir la consola adsiedit.msc y navegar hasta la siguiente ruta en cada uno de los DC:
CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=,OU=Domain Controllers,DC= 
establecer el siguiente valor msDFSR-Enabled=FALSE
2. Forzar la replicación a través de todo el dominio.
3. Ejecutar el siguiente comando en los servidores que semarcarán como no autoritativos: dfsrdiag polladd
4. Se generará un evento 4114 indicando que SYSVOL ni seguirá siendo replicado.
5. En la misma ruta del paso 1 volver a establecer el valor a true msDFSR-Enabled=TRUE
7. Volver a forzar la replicación a través de todo el dominio.
8. Se generará un evento 4614 indicando que la operación finalizó.

Importante: Los procesos descritos en este artículo tanto FRS como DFSR solo tratan la restauración no autoritativa de SYSVOL

9 comentarios:

Manu dijo...

Les paso este enlace. aca esta con DFS R y las respectivas imagenes:
http://kpytko.pl/active-directory-domain-services/authoritative-sysvol-restore-dfs-r/

Cómo puedo lograr... dijo...

Buenas mi amigo, gracias por presentar este log ya que es lo mismo que se esta presentadno en donde trabajo, tengo tres DCs, digamos que el DC1 tiene todos los roles, y los otros dos (DC2 y DC3), pero donde aplico los pasos para FRS??? Supongo que toca es DC2 y DC3 verdad o unicamente en DC1???? y estan en ambiente de producción, que consideraciones se deben tener?? De antamno te agradezco inmensamente.

César Herrada dijo...

Hola! debes hacerlo en el DC que tiene el problema, el que te registra el evento 1568, el cual replicará nuevamente el contenido desde otro DC.

Un saludo

Cómo puedo lograr... dijo...

Hey CESAR, hermano muchisimas gracias!!! Tu solución ha funcionado de maravilla!!

Fuerte abrazo desde Bogotá Colombia!!

César Herrada dijo...

Hola! me alegra mucho que todo marche bien, estamos en la misma ciudad. Un abrazo!

Unknown dijo...

muy buen tutorial, me salvo la vida, muchas gracias

Miguel Pita dijo...

Muchas gracias por tu tutorial, me ha solucionado un buen problema.

Unknown dijo...

Y si el que presenta el error es el que tiene todos los roles FSMO, no tendré problemas al realizar la replica no autoritativa?.
Si fuera el secundario no me complicaría tanto.

Victor dijo...

Excelente solucion gracias por compartir, me funcion perfecto, Saludos.

 

Temas por fecha

Lo más visto

Comunidad

Comunidad
Comunidad Técnica

Visitas