Sysvol y netlogon comparten importancia en Active Directory
> Qué es sysvol y los contenidos que incluye.
Sysvol es un componente importante de Active Directory. La carpeta Sysvol se comparte en un volumen NTFS en todos los controladores de dominio de un dominio en particular. Sysvol se utiliza para entregar la directiva y los scripts de inicio de sesión a los miembros del dominio.
De forma predeterminada, sysvol incluye 2 carpetas
1.Directivas – (Ubicación predeterminada – %SystemRoot%\Sysvol\Sysvol\nombre_dominio\Directivas)
2.Scripts: (Predeterminado ubicación – carpeta %SystemRoot%\Sysvol\Sysvol\domain_name\Scripts)
Nota – podemos ir adelante y cambiar estas ubicaciones predeterminadas.
> Imprtancia de la cuota Sysvol.
Sysvol contiene 2 carpetas, a saber, Directivas y scripts.Directivas
: En la carpeta Directivas existen todas las directivas de grupo definidas en un dominio particular. Consulte la captura de pantalla
Tenga en cuenta que puede ver que 3 GPT están disponibles en la captura de pantalla anterior. Al crear una nueva directiva de grupo en Active directory, se crea un conjunto de carpetas en la carpeta Directivas.
Por ejemplo, estoy creando una Política llamada deshabilitar salvapantallas en mi dominio y vinculando esa política a mi unidad organizativa. Cuando presione el botón crear nueva política en GPMC, Creará una carpeta de nombre de GUID en la carpeta Políticas que se asociará para Deshabilitar el GPO del salvapantallas.
Para hacer esto simple, la captura de pantalla superior tiene 3 GPT que significan que 3 Directivas de grupo están presentes en la prueba.dominio de tld.
Por lo tanto, cuando realice cambios en objetos de directiva de grupo concretos, los cambios se confirmarán en la carpeta de nombres de GUID asociada en Sysvol.
Conclusión
La importancia de la carpeta Sysvol es que contiene el GPT, y cada vez que un administrador realice cambios en cualquiera de las directivas , esos cambios se confirmarán en la carpeta de nombres de GUID asignada y luego se replicarán en todos los controladores de dominio.
> Métodos de replicación Sysvol.
Sysvol se puede replicar en todos los controladores de dominio mediante la Replicación del Sistema de Archivos Distribuido (DFS-R) si el nivel funcional del dominio Este enlace es externo a TechNet Wiki. Se abrirá en una nueva ventana. es Windows Server 2008 o superior, o se replica mediante el Sistema de replicación de archivos (FRS).
Para FRS, la programación SYSVOL es un atributo asociado a cada objeto Conjunto de réplicas NTFRS y a cada objeto de conexión NTDS. FRS replica SYSVOL utilizando los mismos objetos de conexión intrasitarios y la misma programación creada por KCC para la replicación de Active Directory. FRS utiliza dos protocolos de replicación para SYSVOL:
conexión SYSVOL dentro de un sitio. La conexión siempre se considera activada; cualquier programación se ignora y los archivos modificados se replican inmediatamente.
Conexión SYSVOL entre sitios. La replicación SYSVOL se inicia entre dos miembros entre sitios al comienzo del intervalo de 15 minutos, suponiendo que la programación esté abierta. La conexión se trata como un programa de activación. El socio ascendente ignora su programación y responde a cualquier solicitud del socio descendente. Cuando se cierra la programación, el socio ascendente desengancha la conexión solo después de que el contenido actual del registro de salida, en el momento de unirse, se haya enviado y confirmado.
> Errores y problemas comunes de sysvol.
A . Faltan recursos compartidos de Sysvol y Netlogon.
Tome un senario, cuando agregue un nuevo controlador de dominio a su dominio y vea que no hay una carpeta sysvol y netlogon disponibles en el controlador de dominio
Nota: El recurso compartido de Netlogon no es una carpeta llamada Netlogon En el controlador de dominio . De hecho, es una carpeta donde se almacenan todos los scripts de inicio de sesión. Como se mencionó anteriormente, la carpeta de scripts en la carpeta sysvol actuará como recurso compartido Netlogon (Ubicación – %SystemRoot%\sysvol\sysvol\<nombre DNS de dominio>\scripts)
Esto ocurre principalmente si la replicación de sysvol borken. En algunos casos, después de agregar un nuevo controlador de dominio, la replicación de sysvol puede tardar algún tiempo.(Aproximadamente tenéis que esperar algunas horas).
B. Error de ajuste de diario
FRS es un sistema de replicación multi-maestro que se encarga de replicar el contenido de Sysvol entre todos los DC del dominio (también puede replicar datos normales, pero estamos interesados principalmente en la replicación de Sysvol en la entrada del blog).
Con el cuidado y mantenimiento adecuados, los FRS Post-SP2 en W2k3 son bastante estables y zumban felizmente mientras no haya una condición externa, como una interrupción de la red o problemas de disco que causen que se descomponga (suponiendo que los datos que está replicando no sean completamente inadecuados para replicar como .Archivos PST, datos de perfil o contenido que cambia con frecuencia).
El problema de FRS más frecuente es donde se produce un Envoltorio de Diario; echemos un vistazo más de cerca a lo que sucede durante un Envoltorio de diario debajo del capó.
La forma en que funciona FRS es que tiene una base de datos interna que contiene todos los archivos y carpetas que está replicando y cada uno de ellos tiene un ID global (GUID) único. La dababase también contiene un puntero a la última operación de disco NTFS (en el Diario USN/Diario NTFS) que procesó el servicio FRS.
Si un usuario cambia un archivo o carpeta en un disco, sucede lo siguiente:
1) NTFS recoge la operación y se realiza una entrada en el Diario NTFS.
2) FRS monitorea el Diario NTFS en busca de cambios y señala que se ha realizado un cambio en ese archivo.
3) FRS mantiene un registro del último evento de diario NTFS que procesó y comprueba si ya lo ha procesado.
4) Si aún no lo ha procesado, examina si es un archivo que debe replicarse.
5) Si se debe replicar, el archivo entra en el proceso normal de estadificación,replicación, etc.
6) FRS incrementa la entrada en su base de datos sobre el evento de diario NTFS que ha procesado para que no lo vuelva a considerar.
Ahora simplify simplifiquemos un poco las cosas.
– Nuestro disco contiene un archivo y una carpeta (e:\Test y prueba.txt).
– Nuestro diario NTFS tiene un tamaño de 10 entradas (el tamaño predeterminado del diario NTFS en RL es de ~512 Mb, dependiendo de su nivel de sistema operativo/SP).
– Nuestra base de datos FRS contiene tres entradas
– > un GUID para E:\test
– > un GUID para E:\test\test.txt
– > Una referencia a la última entrada del Diario NTFS que procesamos (digamos #4)
Operaciones normales:
– > Alguien hace un cambio para probar.txt.
– > El Diario NTFS se actualiza a #5.
– > FRS señala que el diario NTFS dice que se ha realizado un cambio para probar.txt y ve que no ha procesado ese cambio.
– >Escenificar/Replicar y actualizar la base de datos FRS para reflejar que hemos procesado esa entrada del Diario NTFS.
Ahora, un administrador detiene el servicio FRS durante 30 minutos.
– Alguien hace 10 cambios a la prueba.txt
o El Diario NTFS se actualiza 20 veces y ahora está en el # 24 (recuerde que tenemos un límite de tamaño de registro de las últimas 10 entradas, por lo que es necesario envolver).
o FRS se detiene, por lo que no está monitoreando el registro del diario NTFS.
En este punto, tenemos cambios en el disco que FRS no conoce. FRS aún conoce la última entrada del Diario NTFS que procesó y la comparará con el Diario NTFS actual la próxima vez que se reinicie.
La próxima vez que se inicie el servicio FRS, verá que ha perdido operaciones NTFS en el disco (la última vez que procesó la operación NTFS #4, pero el Diario NTFS ahora está en el #24 y solo tenemos un registro que se remonta a 10 entradas, por lo que nos faltan las operaciones #5-#14 de la base de datos.
Esto es cuando FRS se queja de que ha alcanzado un estado de ajuste de diario, el registro de diario NTFS se ha ajustado y no conoce el estado actual de las cosas en el disco.
El impacto de esto en un DC afectado es que FRS no establecerá la clave de registro IsSysvolReady para indicar al servicio Netlogon que todo está bien, por lo tanto, Sysvol no se compartirá y el DC no podrá autenticar completamente a los usuarios hasta que se haya resuelto la condición de ajuste de diario.
Compartir manualmente Sysvol o establecer la clave de registro IsSysvolReady en 1 no son métodos válidos para resolver este problema y no abordan el problema real.
Para que FRS se recupere de un ajuste de diario, básicamente tendrá que comenzar desde cero y restablecer la base de datos de FRS y comenzar a contar el Diario NTFS a partir de los valores actuales que tiene.
Esto significa:
– Replicación de datos de un socio entrante existente (El enfoque de restauración de FRS d2 o no autorizado).
– Hacer que sus propios datos sean autoritarios y dejar que todos los demás se replicen de usted (el enfoque de restauración de FRS d4 o autoritativo).
El enfoque d2 es bastante simple de realizar, sin embargo, los requisitos son que tenga una buena conexión de red con el socio de replicación entrante y el tiempo que tomará depende de la cantidad de datos que se replicarán frente a la capacidad del enlace
Por otro lado, esto puede no ser siempre suficiente y puede verse obligado a optar por la opción d4.
Son los errores más comunes cuando se considera sysvol en Active Directory.
Finalmente, cuáles son los pasos que podemos seguir cuando se encuentran los errores anteriores.
> Solución de problemas de mensajes de error Sysvol
A . Faltan recursos compartidos de Sysvol y Netlogon.
Como mencioné antes, podría ser un problema con la replicación sysvol rota entre controladores de dominio.
¿Cómo puedo forzar la replicación Sysvol en un directorio activo
Puede reiniciar el servicio FRS para forzar la replicación FRS
Para reiniciar el servicio FRS, inicie servicios.msc desde la opción Ejecutar en el Menú Inicio
y reinicie el servicio FRS y obtendrá el ID de evento 13516 en el registro de eventos de FRS esto asegurará que el estado de FRS esté bien.
Replicación de Sysvol a través de NTFRSUTL
Si desea forzar la replicación de sysvol entre dos controladores de dominio en un directorio activo, utilice el procedimiento siguiente
Opción de línea de comandos NTFRSUTL FORCEREPL para forzar la replicación
Puede usar el nuevo comando ntfrsutl forcerepl para imponer la replicación independientemente de la programación de replicación predefinida. Esto solo se implementa para el conjunto de réplicas Sysvol del controlador de dominio.
ntfrsutl forcerepl / r / p
Este comando fuerza a FRS a iniciar un ciclo de replicación. Debe especificar el equipo, setName y DNSName.
Nota En este comando, se utilizan los siguientes marcadores de posición:
= Conectar con el servicio NtFrs en esta máquina.
= El nombre del conjunto de réplicas.
= El nombre DNS del socio entrante desde el que forzar la replicación.
Por ejemplo:
ntfrsutl.exe forcerepl DestinationDC / r «Volumen del sistema de dominio (Compartir SYSVOL)» / p SourceDC.domain.com
Las comillas de este ejemplo son necesarias cuando se utiliza la opción / r. Si las comillas no están presentes, el comando no funcionará.
Si lo anterior no ayuda, entonces,
El método más popular para resolver esto está debajo de MS KB.
SÍNTOMAS:
Después de instalar Servicios de dominio de Active Directory en un nuevo controlador de dominio completo o de solo lectura basado en Windows Server 2008 en un dominio existente, el recurso compartido SYSVOL está presente. Sin embargo, el recurso compartido NETLOGON no está presente en el nuevo controlador de dominio.
Nota Este artículo no se aplica si faltan recursos compartidos NETLOGON y SYSVOL.
CAUSA:
Este problema ocurre cuando el servicio Netlogon lee el indicador SysvolReady en el registro muy rápidamente. A continuación, el servicio Netlogon intenta compartir la carpeta \Windows\SYSVOL\domain\scripts antes de que el Servicio de Replicación de archivos NT (NTFRS) cree esta carpeta.
SOLUCIÓN ALTERNATIVA:
Advertencia Pueden producirse problemas graves si modifica el registro incorrectamente con el Editor del registro o con otro método. Estos problemas pueden requerir que reinstale el sistema operativo. Microsoft no puede garantizar que estos problemas se puedan resolver. Modificar el registro bajo su propio riesgo.
Para solucionar este problema, establezca el valor del registro SysvolReady Flag en «0» y, a continuación, vuelva a «1» en el registro. Para ello, siga estos pasos:
– > Haga clic en Inicio, haga clic en Ejecutar, escriba regedit y, a continuación, haga clic en Aceptar.
– > Busque la siguiente subclave en el Editor del registro:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
->En el panel de detalles, haga clic con el botón secundario en el indicador SysvolReady y, a continuación, haga clic en Modificar.
– >En el cuadro Datos de valor, escriba 0 y, a continuación, haga clic en Aceptar.
– > De nuevo en el panel de detalles, haga clic con el botón secundario en la bandera SysvolReady y, a continuación, haga clic en Modificar.
– >En el cuadro Datos de valor, escriba 1 y, a continuación, haga clic en Aceptar.
Tenga en cuenta que esto hará que Netlogon comparta SYSVOL, y la carpeta scripts estará presente.
MÁS INFORMACIÓN:
El problema que se describe en la sección» Síntomas » ocurre en el siguiente escenario:
NTFRS primero coloca cambios en la siguiente ubicación:
\Windows \ SYSVOL \ domain \ DO_NOT_REMOVE_NtFrs_PreInstall_Directory
Luego, NTFRS notifica a Netlogon que comparta SYSVOL estableciendo la entrada de registro SysvolReady en «1.»
NTFRS luego mueve y cambia el nombre de los archivos desde la ubicación mencionada en el paso 1 a la siguiente carpeta:
\Windows\SYSVOL\domain
Sin embargo, si el servicio Netlogon lee la entrada SysvolReady en el registro muy rápidamente, el servicio Netlogon intenta compartir la carpeta \Windows\SYSVOL\domain\scripts antes de que NTFRS cree esta carpeta. Por lo tanto, el recurso compartido NETLOGON no se crea.
B . Error de ajuste de diario
Si se produce un error de ajuste de diario, podemos establecer un valor de blurflag en D2 en el registro de un controlador de dominio donde se generan eventos de error de ajuste de diario. Al hacer esto, el controlador de dominio volcará las carpetas preexistentes y comenzará a replicar contenido nuevo desde uno de sus socios de replicación de FRS.
O
Podemos establecer blurflag en D4 que hace exactamente lo opuesto a lo anterior . Es decir , cuando configura D4 en un controlador de dominio perticular, sus datos actuarán como Autor, Como resultado, todos los controladores de dominio de su dominio se replicarán desde el controlador de dominio donde este blurflag está establecido en D4
Nota: Configurar BlurFlag en D4 es la última opción , el 90% de los casos se resolverán configurando blurflag en D2.
| Artículos publicitarios | Preguntas frecuentes de Windows |
|---|