Desaparecio el SYSVOL de un controlador de dominio de nuestro Active Directory. Que hacer sin volverse loco {HowTo}

help-infoHoy vamos a ver como es el procedimiento que debemos realizar cuando tenemos en nuestro servidor controlador de dominio desapareció el share de SYSVOL y como regenerarlo para que nuestro Active Directory este operativo al 100% nuevamente. El procedimiento son 7 u 8 pasos, pero antes vamos a ver un poco de teoría al respecto.

Como siempre, hay que aclarar, que vamos a modificar el registro de nuestro equipo; y como siempre que hacemos esto, debemos asegurarnos de hacer una copia de seguridad de él y de que sabemos cómo restaurarlo si ocurre algún problema (Warning!).

Veremos cómo utilizar el valor del Registro Burflags para volver a generar la copia de cada controlador de dominio del árbol de volumen del sistema (SYSVOL) en todos los controladores de dominio de un dominio del servicio de directorio Active Directory común.

Para empezar, y entrar un poco mas en tema definamos el término SYSVOL; es una referencia a un conjunto de archivos y carpetas que residen en el disco duro local de cada controlador de dominio en un dominio y que replica el Servicio de replicación de archivos (FRS, File Replication Service). Los clientes de red tienen acceso al contenido del árbol de SYSVOL mediante las carpetas compartidas siguientes:

  • NETLOGON
  • SYSVOL

Obviamente esto es un procedimiento que no debe utilizarse como un estándar sino que debe ser considerado como un ultimo recurso, ya que implica un riesgo y deberíamos evaluar las distintas alternativas; como por ejemplo cuando no podemos hacer que el FRS funcione en controladores de dominio individuales del dominio.

Otro tema importante es que durante este procedimiento, nuestros controladores de dominio no atenderán ninguna solicitud de autenticación durante su duración. Esto ocurrirá sólo cuando se vuelvan a compartir las carpetas SYSVOL y NETLOGON, entonces el controlador de dominio autenticará las solicitudes. Por ende, este procedimiento no se debería realizar durante las horas de máxima utilización ya que implica una baja en los servicios.

Una buena practica es verificar periodicamente el rendimiento y el estado de FRS mediante herramientas de monitoreo, para poder evitar tener que realizar restauraciones authoritative y non-authoritative del conjunto de réplicas, y tambien podemos tener una idea de la causa que origina los errores de FRS. Al final de la nota incluyo el link de descarga de una de estas herramientas (UltraSound).

Sobre el Registro Burflags:

  • Si iniciamos FRS con el valor del Registro Burflags establecido en D4, FRS trata inicialmente los archivos y carpetas de su copia local del árbol de SYSVOL como autorizados para el conjunto de réplicas. Sólo se debería inicializar con la configuración D4 un miembro de un conjunto de réplicas de FRS.
  • Si iniciamos FRS con el valor del Registro Burflags establecido en D2, FRS realiza una sincronización completa de los archivos y carpetas desde un asociado de replicación directo o transitivo que aloje la copia autorizada de los archivos y carpetas del conjunto de réplicas.
  • Al iniciar FRS con la entrada del Registro Burflags establecida en D4, la configuración que generalmente se conoce como "restauración autorizada (authoritative restore)" para el contenido de un conjunto de réplicas de FRS, incluso aunque no se produzca ninguna restauración real del estado del sistema. Debemos considerar la configuración D4 como una regeneración de la parte de FRS del primer controlador de dominio de un dominio nuevo.
  • Al iniciar FRS con la entrada del Registro Burflags establecida en D2, la configuración  que generalmente se conoce como restauración no autorizada(non-authoritative restore), aunque no se produzca ninguna restauración del estado del sistema. Debemos considerar la configuración D2 como una regeneración de la parte de FRS del controlador de dominio de la réplica como si el controlador de dominio fuera nuevo.
  • Después de que cada uno de los equipos restaurados, autorizados o no, haya finalizado la inicialización, FRS empieza a poder utilizar varios maestros.
  • Si establecemos Burflags en D4 en un controlador de dominio único y en D2 en los demás controladores de dominio de ese dominio, podemos volver a generar el árbol de SYSVOL en ese dominio. Este proceso de regeneración masiva se conoce como hub, branch o reinicio masivo de FRS.

A continuación se enumeran los usos válidos de un reinicio masivo del conjunto de réplicas de SYSVOL:

  • Los miembros de un conjunto de réplicas de FRS que estén en un estado incoherente pueden realizar una sincronización completa de todos los archivos y carpetas del árbol de SYSVOL más rápidamente de que lo tarda el proceso de copia de seguridad de los cambios que residen en los registros salientes de los asociados de replicación de nivel superior.
  • La mayoría de los miembros de un conjunto de réplicas de FRS tiene errores, por ejemplo, errores journal_wrap.
  • La tabla de identificadores de la mayor parte de los miembros del conjunto de réplicas contiene una descripción incompleta de los archivos que se deberían alojar en el conjunto de réplicas.
  • Los archivos de base de datos de FRS se ven comprometidos debido a una eliminación accidental, a errores del sistema de archivos o a errores del archivo de base de datos, como son los daños que se identifican mediante las herramientas de validación de la base de datos de JET.
  • La mayoría de los miembros de un conjunto de réplicas de FRS no puede replicar archivos y carpetas, y la configuración D2 o D4 masiva es una manera de reinicializar todos los miembros como si fueran nuevos.

Algunas consideraciones:

  • Si FRS está en estado de error en un único miembro, puede establecer BurFlags en D2 sólo en ese miembro.
  • Si vuelve a generar el árbol de SYSVOL debido a problemas del entorno o si una topología problemática ha afectado a la coherencia de los archivos y las carpetas de un conjunto de réplicas de FRS, puede que sólo aprecie un beneficio temporal. Por ejemplo, este escenario se produce cuando hay demasiados asociados de nivel inferior o se han producido demasiados cambios en el contenido replicado. En este caso, recomendamos que solucione la causa principal del problema subyacente. Por otra parte, los problemas que ocasionaron al principio que volviera a generar el árbol de SYSVOL pueden volver a producirse.
  • Para regenerar el árbol de SYSVOL, recomendamos que todos los controladores de dominio basados en Windows 2000 del dominio tengan instalado el Service Pack 3 (SP3) de Windows 2000 o una versión posterior del archivo NTFRS.exe. Si la versión del archivo NTFRS.exe es anterior a la del Service Pack 3 de Windows 2000, instale el Service Pack de Windows 2000 más reciente.

Una vez hechas las aclaraciones, veremos como es el procedimiento para volver a generar el conjunto de réplicas de SYSVOL del dominio.
  • Detenemos el servicio FRS en todos los controladores de dominio del dominio.
  • Copiamos todos los archivos y carpetas que deberían residir en el árbol de SYSVOL a una carpeta temporal en el controlador de dominio de referencia.
  • Comprobamos los puntos de unión y las carpetas requeridas en cada controlador de dominio del dominio.
  • Reiniciamos el servicio FRS en el controlador de dominio de referencia con el valor del Registro establecido en D4.
  • Reiniciamos el servicio  FRS en los demás controladores de dominio del dominio con el valor del Registro establecido en D2.
  • En el controlador de dominio de referencia, copiamos todos los archivos y carpetas a la carpeta raíz del conjunto de réplicas. De forma predeterminada, esta carpeta es C:\Windows\Sysvol\Domain.
  • Ahora, debemos verificar la coherencia de los archivos y las carpetas para todos los controladores de dominio del dominio.

Nota: Si un miembro de algún conjunto de réplicas se ha reiniciado con el valor del Registro Burflag establecido en D4, reinicie el FRS en los demás miembros del conjunto de réplicas con el valor del Registro Burflags establecido en D2. Esta configuración evita que haya carpetas huérfanas.

Espero que les sea de utilidad. Saludos, Roberto Di Lello.

Información Adicional:

  • UltraSound: es una herramienta eficaz que mide el funcionamiento de los conjuntos de réplicas de FRS proporcionando información histórica y clasificaciones del estado de estos conjuntos. Es un sistema de monitoreo sofisticada que utiliza proveedores del Instrumental de administración de Windows (WMI), un servicio de recopilación de datos, una base de datos de Microsoft SQL Server Desktop Engine (MSDE) y una interfaz de usuario eficaz. Link de descarga.
Roberto Di Lello

Acerca del autor: Roberto Di Lello

Hola, soy Roberto Di Lello trabajo como Consultor Senior en Infraestructura, especializado en Tecnologias Microsoft con mas de 25 años en la industria. He sido galardonado como MS-MVP en Active Directory-Enterprise Mobility por 10 años, y actualmente soy MVP Windows Insider, ademas de poseer otras certificaciones de Microsoft. He trabajado en distintos projectos que involucran Migraciones, Implementaciones, y soporte de Active Directory y Microsoft Exchange, y en los ultimos años me he desempeñado armando equipos de trabajo para diferentes paises y areas de sistemas, he planificado a distintas migraciones a datacenters (ambiente cloud y mixtos). He tenido la oportunidad de participar como miembro del staff de Microsoft en eventos internacionales como ser TechEd NorteAmerica y MS Ignite (NA) al ser Trainer Certificado por Microsoft (MCT).

You May Also Like

4 Comments

  1. buenas,

    he seguido esta pagina ya hece tiempo, y les quiero pedir una ayuda con respecto a un nuevo reto que he iniciado.
    tengo virtualizado 2 servidores con Windows Server R2 Standar, el primero es mi controaldor de dominio principal y el segundo es micontralador de dominio de respaldo y tambien tengo instalado exchange 2010.
    en lo que quisiera que ma ayudaran es en la configuracion full del eschange para que se pueda enviar y recibir correos y como registrar el MX.

  2. Iver, disculpa mi demora en contestar pero estuve medio complicado con los tiempos.

    Para configurar tu Exchange 2010 te recomiendo ver las siguientes notas:
    * Preparando nuestro Active Directory en Windows Server 2008 r2, para la implementacion de Exchange Server 2010 – Parte 1{HOWTO} https://www.radians.com.ar/blog/?p=1117
    * Preparando nuestro Active Directory en Windows Server 2008 r2, para la implementacion de Exchange Server 2010–Parte 2 {HOWTO} https://www.radians.com.ar/blog/?p=1120
    * Preparando nuestro Active Directory en Windows Server 2008 r2, para la implementacion de Exchange Server 2010–Parte 3 {HOWTO}: La instalacion de Exchange Server 2010. https://www.radians.com.ar/blog/?p=1169

    Por el tema de los DNS y los MX, deberías tener una IP Publica, y registrar en los DNS el registro MX; si utilizas los DNS de tu ISP, debes pedirles a ellos que hagan la registración.

    Muchas gracias por participar del blog y ayudar a que siga creciendo! Te cuento que hay mucho material en el. Te invito a que veas los labs, videos, tutoriales, notas. Si querés buscar un tema o necesitas ayuda, tenés la solapa AYUDA donde explico un poco como hacerlo, sino también tenés el buscador de google.

    Espero te sean de utilidad. Saludos!

  3. que tal
    gracias por responder

    esas indicaciones ya las habia leido, la situacion actualmente esta que puedo enviar correos, pero no puedo recivir correos desde afuera, y ya registre el MX.

    que me recomiendas que revise.
    quedo atento a una respuesta.

  4. Iver, lo que tenes que verificar son los registros mx en tu DNS publico. Generalmente esto los tiene tu ISP, puedes hacerlo con NSLOOKUP
    nslookup -q=mx nombreDeDominio NombreDNSPublico
    Y obviamente verificar que tus firewalls permitan el trafico.

    Best Regards | Saludos

Comments are closed.