Búsqueda de sitios web

Política de grupo que no se replica entre controladores de dominio


Esta publicación proporciona las soluciones más adecuadas al problema por el cual las políticas de grupo no se aplican ni replican entre controladores de dominio en un entorno típico de Windows Server.

Si los GPO no se sincronizan o replican entre los controladores de dominio, podría deberse a los siguientes motivos:

  • Problemas del directorio activo.

  • Problemas con uno o más de los controladores de dominio según la configuración.

  • Problemas de latencia o lentitud del Servicio de replicación de archivos.

  • El cliente del sistema de archivos distribuido (DFS) está deshabilitado.

  • Conectividad de red al controlador de dominio.

Algunas máquinas cliente usarán un controlador de dominio basado en la membresía del sitio en el escenario donde tiene más de un controlador de dominio en un dominio. Por lo general, si cada sitio tiene varios DC, los clientes pueden elegir un DC en función del "peso", mientras que, por lo general, todos los DC tienen el mismo peso. ” También es posible que las máquinas cliente usen un DC en otra ubicación. Por lo tanto, si sus DC no se replican correctamente, es posible que los directorios SYSVOL alojados en estos servidores no tengan datos reflejados con precisión, en cuyo caso sus estaciones de trabajo obtendrán resultados diferentes según el DC al que apunten las máquinas cliente.

Política de grupo que no se replica entre controladores de dominio

En un escenario de caso típico, hay tres DC y uno de ellos, que es un DC 2012 antiguo, estará sujeto a desmantelamiento. Los otros dos son DC 2016, que es el nuevo y actualmente es el titular de FSMO. Ahora, existe el problema con la replicación de SYSVOL donde los cambios creados en DC 2016 no se replican en las políticas de SYSVOL de DC 2012.

Por lo tanto, si las políticas de grupo no se aplican y la replicación no funciona entre los controladores de dominio en la configuración de Windows Server en un entorno empresarial, si usted es un administrador de TI, las soluciones proporcionadas a continuación sin ningún orden en particular deberían ayudarlo a resolver el problema.

  1. Aplicar revisión de Microsoft

  2. Solución de problemas generales para problemas de replicaciones de DC

  3. Sincronizar datos SYSVOL (autorizados o no autorizados) usando FRS

  4. Póngase en contacto con el soporte técnico de Microsoft

Veamos la descripción del proceso en relación con cada una de las soluciones enumeradas.

1. Aplicación de revisión de Microsoft

Si tiene este problema en DC que ejecutan Windows Server 2008 R2 o 2012, antes de iniciar cualquier solución de problemas, primero debe aplicar la revisión de Microsoft a todos los DC (no es necesario para 2012 R2). Existe un problema conocido en los DC en los que los servidores mantienen abiertos los archivos después de editarlos, lo que parece que las ediciones funcionan, hasta que cierra y vuelve a abrir el GPO y descubre que no se aplican en absoluto. De manera similar, la replicación parece funcionar, pero algunas máquinas seleccionan la configuración mientras que otras no porque los mismos datos no se replican correctamente en todos los DC.

2. Solución de problemas generales para problemas de replicaciones de DC

Antes de continuar, puede realizar las siguientes tareas preliminares sobre la solución de problemas generales para problemas de replicaciones de DC. Al completar cada tarea, verifique si el problema se resolvió.

  • Forzar gpupdate. Puede comenzar ejecutando gpupdate desde la estación de trabajo que está experimentando resultados inconsistentes. Si obtiene un resultado que indica La política de la computadora no se pudo actualizar correctamente, entonces hay un problema general de entrega de GPO.

  • Compruebe los DC para las carpetas NETLOGON y SYSVOL. En el nivel más básico, un DC debe tener dos carpetas compartidas de forma predeterminada, NETLOGON y la carpeta SYSVOL. Si estas dos carpetas no están presentes en un controlador de dominio, tendrá un problema de AD y los GPO no se entregarán correctamente.

  • Fuerza la replicación mediante un script. Puede forzar la replicación con el script de GitHub.com. Sabiendo que las políticas de grupo consisten en archivos de dos partes ubicados en SYSVOL y un atributo de versión en AD, ejecutar el script es una forma rápida de replicar sus cambios en todos los DC dentro de su dominio.

  • Utilice herramientas de solución de problemas. Con herramientas de solución de problemas como DCDIAG.exe, GPOTOOL.exe o DFSDIAG.exe, si hay un problema de replicación, debería poder determinar qué DC o DC son los problemas. Una vez que esto se determine, deberá reconstruir el volumen del sistema (SYSVOL) en estos servidores designados. Si tiene más de un DC en un sitio, una manera fácil de hacerlo es simplemente degradar el DC problemático ejecutando DCPROMO, reinicie el servidor, y luego ejecute DCPROMO y reinicie una vez más. Si solo un DC reside en un sitio, puede usar la entrada de registro de Windows de Burflags para reconstruir el SYSVOL. Tenga en cuenta que degradar al único DC que reside en un sitio puede requerir que vuelva a unir a los clientes al dominio.

3. Sincronizar datos SYSVOL (autorizados o no autorizados) usando FRS

La jerarquía de carpetas de SYSVOL, presente en todos los controladores de dominio de Active Directory, se usa principalmente para almacenar dos conjuntos importantes de datos replicados entre DC, pero la replicación de SYSVOL se realiza por separado de la replicación de Active Directory. Uno puede fallar mientras que el otro es completamente funcional. En algunos casos, la replicación de SYSVOL puede fallar y no puede reanudarse sin una intervención manual, en cuyo caso, deberá realizar una sincronización autorizada (para un controlador de dominio) o no autorizada (más de un controlador de dominio) de los datos de SYSVOL mediante FRS.

Las instrucciones a continuación no se aplican si el Servicio de replicación de archivos (FRS) no está en uso porque el servicio ha quedado obsoleto, aunque aún puede estar en uso en los dominios de Active Directory que se crearon en Windows Server 2008 y versiones anteriores. Para determinar si FRS está en uso, ejecute el siguiente comando en un símbolo del sistema con privilegios elevados en un controlador de dominio:

dfsrmig /getmigrationstate

Si el resultado muestra que el estado de la migración es Eliminado, FRS no está en uso.

Para realizar una sincronización autorizada o no autorizada de datos SYSVOL mediante FRS, siga estos pasos:

  • Dado que se trata de una operación de registro, se recomienda que haga una copia de seguridad del registro o cree un punto de restauración del sistema como medida de precaución necesaria.

  • Para la sincronización no autorizada, asegúrese de que exista otro DC en el entorno y que su copia de los datos de SYSVOL esté actualizada navegando a %systemroot%\SYSVOL para comprobar las fechas modificadas de la directiva de grupo archivos de plantilla y/o archivos de script.

Una vez hecho esto, puede proceder de la siguiente manera:

  • Detenga el servicio de replicación de archivos.

  • Presione la tecla de Windows + R para invocar el cuadro de diálogo Ejecutar.

  • En el cuadro de diálogo Ejecutar, escriba regedit y presione Entrar para abrir el Editor del Registro.

  • Navegue o salte a la ruta de la clave de registro a continuación:

HKLM\CCS\Services\NtFrs\Parameters\Backup/Restore\Process at Startup
  • En la ubicación, en el panel derecho, haga doble clic en la entrada BurFlags para editar sus propiedades.

  • En el campo Vdatos de valor, escriba D4 (para autorizado) o D2 (para no autorizado) por su requisito.

  • Haz clic en Aceptar o pulsa Intro para guardar el cambio.

  • Salga del Editor del Registro.

  • A continuación, inicie el Servicio de replicación de archivos.

  • A continuación, inicie el Visor de eventos y verifique el registro de eventos del Servicio de replicación de archivos en los Registros de aplicaciones y servicios para el evento informativo 13516. Este evento puede tardar unos minutos en aparecer.

  • Una vez que haya aparecido el evento 13516, ejecute el siguiente comando:

net share
  • Ahora, confirme la presencia de los recursos compartidos SYSVOL y NETLOGON en la salida.

En un dominio con un DC, los datos de SYSVOL en sí no deberían haber cambiado durante este procedimiento. En un dominio con más de un DC, es posible que deba realizar una sincronización no autoritaria de SYSVOL en uno o más de los otros DC después de que se haya completado la sincronización autoritativa comprobando los registros de eventos de FRS de los otros DC en busca de errores o advertencias. eventos. También puede comparar los datos en la jerarquía de carpetas SYSVOL del DC afectado con los datos correspondientes en un DC bueno conocido para confirmar que los datos coinciden.

4. Póngase en contacto con el soporte técnico de Microsoft

Si el problema de la Política de grupo no se replica entre los controladores de dominio persiste, es posible que deba ponerse en contacto con el Soporte profesional de Microsoft. Cobran por incidente y los boletos deben iniciarse en línea solo, ya que no aceptan llamadas telefónicas para crear un boleto.

¡Espero que esta publicación te ayude!

¿Cómo se solucionan los problemas de replicación entre los controladores de dominio?

Primero, puede usar Microsoft Hotfix, que funciona bastante bien en la mayoría de los casos. Después de eso, puede forzar la actualización de los cambios usando el símbolo del sistema. Por otro lado, también puede usar sincronizar la configuración de SYSVOL usando FRS. Si desea aprenderlos en detalle, debe consultar las guías mencionadas anteriormente.

¿Cómo verifico el estado de mi replicación?

Para ver y diagnosticar errores o problemas de replicación de AD, puede ejecutar la herramienta Asistente de soporte y recuperación de Microsoft O ejecutar la herramienta de replicación de estado de AD en los DC. Puede leer el estado de replicación en la salida de repadmin /showrepl. Repadmin es parte de Herramientas de administrador de servidor remoto (RSAT). Cuando cambia una política de grupo, es posible que deba esperar dos horas (90 minutos más una compensación de 30 minutos) antes de ver cambios en los equipos cliente. En algunos casos, algunos cambios no surtirán efecto hasta que se reinicie la máquina.

Artículos relacionados