Solución de problemas de recursos compartidos SYSVOL y Netlogon que faltan

2025-01-15

En este artículo se proporcionan los pasos para solucionar problemas de los recursos compartidos y Netlogon que faltan SYSVOL en Windows Server 2012 R2.

Número de KB original: 2958414

Síntomas

SYSVOL y Netlogon los recursos compartidos no se comparten en un controlador de dominio. También pueden producirse los siguientes síntomas o condiciones:

La sysvol carpeta está vacía.
El controlador de dominio afectado se ha promocionado recientemente.
El entorno contiene controladores de dominio que ejecutan versiones de Windows anteriores a Windows Server 2012 R2.
Replicación DFS se usa para replicar la SYSVOL carpeta Compartir replicada.
El servicio de replicación DFS de un controlador de dominio ascendente está en estado de error.

Causa

Los controladores de dominio sin SYSVOL compartido no pueden replicar los controladores de dominio entrantes debido a que los controladores de dominio ascendentes (origen) están en un estado de error. Con frecuencia (pero no limitado a), los servidores ascendentes han detenido la replicación debido a un apagado desfasado (id. de evento 2213).

Solución

Esta sección contiene métodos recomendados para solucionar problemas y resolver faltantes SYSVOL y Netlogon recursos compartidos en controladores de dominio que se replican mediante el servicio replicación DFS.

El proceso reinicializa la replicación DFS si SYSVOL no se comparte en controladores de dominio según Cómo forzar una sincronización autoritativa o no autoritativa para SYSVOL replicado por DFSR (como "D4/D2" para FRS). No es necesario en la mayoría de los casos y puede provocar la pérdida de datos si se hace incorrectamente. Además, impide determinar la causa del problema y evitar futuras apariciones del problema.

A continuación se indican los pasos generales para investigar los recursos compartidos que faltan. Determine si el problema se debe a una repetición única o si los controladores de dominio ascendentes no pueden admitir la replicación mediante replicación DFS.

No es necesario eliminar la base de datos de replicación DFS del volumen y no se recomienda. Hace que replicación DFS considere que todos los datos locales del servidor no son autenticativos. Al permitir que replicación DFS recupere correctamente la base de datos (como se indica en el evento 2213), el último escritor seguirá ganando las versiones en conflicto de SYSVOL los datos.

Paso 1: Evaluación del estado de replicación DFS en todos los controladores de dominio

Evalúe cuántos controladores de dominio no comparten SYSVOL, ha registrado recientemente un evento Error y cuántos controladores de dominio están en un estado de error. Siga estos pasos.

Comprobación del SYSVOL recurso compartido

Puede comprobar manualmente si SYSVOL se comparte o puede inspeccionar cada controlador de dominio mediante el comando net view:
```
For /f %i IN ('dsquery server -o rdn') do @echo %i && @(net view \\%i | find "SYSVOL") & echo
```
Comprobación del estado de replicación DFS

Para comprobar el estado de replicación DFS en los controladores de dominio, puede consultar WMI. Puede consultar todos los controladores de dominio del dominio para la SYSVOL carpeta Replicada de recurso compartido mediante WMI como se indica a continuación:
```
For /f %i IN ('dsquery server -o rdn') do @echo %i && @wmic /node:"%i" /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo WHERE replicatedfoldername='SYSVOL share' get replicationgroupname,replicatedfoldername,state
```
Los state valores pueden ser cualquiera de:
0 = Sin inicializar
1 = Inicializado
2 = Sincronización inicial
3 = Recuperación automática
4 = Normal
5 = En error

Nota:

Dependiendo de la condición de un controlador de dominio, puede no notificar un valor de estado e indicar que no hay ninguna instancia disponible.
Comprobación de los registros de eventos para ver si hay errores o advertencias recientes

Si algún controlador de dominio no notifica la SYSVOL carpeta Replicada compartida como en un estado 4 (normal), compruebe el registro de eventos de esos controladores de dominio para evaluar su condición. Revise cada controlador de dominio para ver si hay errores o advertencias recientes en el registro de eventos de replicación DFS, como el identificador de evento de advertencia 2213 que indica que replicación DFS está en pausa actualmente.
Comprobación de la configuración de actualización de contenido

Determine si replicación DFS desencadenó la protección de actualización de contenido en los controladores de dominio afectados. La actualización de contenido está habilitada en controladores de dominio de Windows Server 2012 (y versiones posteriores) de forma predeterminada. Sin embargo, también se puede habilitar manualmente en servidores Windows Server 2008 R2.

Para evaluar si está habilitada la actualización del contenido, la MaxOfflineTimeInDays configuración se establecerá en 60. Si la actualización del contenido está deshabilitada, MaxOfflineTimeInDays se establecerá en 0. Para comprobar MaxOfflineTimeInDays, ejecute el siguiente comando:
```
wmic.exe /node:%computername% /namespace:\\root\microsoftdfs path DfsrMachineConfig get MaxOfflineTimeInDays
```
Para consultar todos los controladores de dominio del dominio, ejecute el siguiente comando:
```
For /f %i IN ('dsquery server -o rdn') do @echo %i && @wmic /node:"%i" /namespace:\\root\microsoftdfs path DfsrMachineConfig get MaxOfflineTimeInDays
```
Para cada controlador de dominio habilitado para la actualización del contenido, evalúe si replicación DFS ha registrado un identificador de evento 4012 que indica que la replicación de la carpeta se ha detenido porque la replicación ha fallado durante más tiempo que el MaxOfflineTimeInDays parámetro .

Paso 2: Preparación de los controladores de dominio que están en estado de error

Instalar las actualizaciones adecuadas

Para cualquier controlador de dominio que ejecute Windows Server 2008 R2, instale primero las actualizaciones de replicación DFS para evitar la pérdida de datos y corregir problemas conocidos. Se recomienda usar la versión más reciente de replicación DFS. Consulte Lista de revisiones disponibles actualmente para las tecnologías del sistema de archivos distribuido (DFS) para obtener la versión más reciente de replicación DFS.
Copia de seguridad de SYSVOL datos

Realice una copia de seguridad de SYSVOL los datos (si están presentes) en cada controlador de dominio. Las copias de seguridad pueden ser una copia de archivo del SYSVOL contenido en una ubicación segura o, puede ser una copia de seguridad que use software de copia de seguridad.

En función de la situación, los archivos de directiva se pueden mover a PreExisting o Conflict y Deleted. Los contenidos preexistentes y conflictivos y eliminados se purgarán si la sincronización inicial se realiza varias veces en un servidor. Realice una copia de seguridad de los datos en estas ubicaciones para evitar la pérdida de datos.

Paso 3: Recuperación de la replicación DFS en los controladores de dominio en el estado de error

En función del número de controladores de dominio del dominio, seleccione el método adecuado para recuperar el servicio de replicación DFS.

Para entornos que tienen dos controladores de dominio

Determine si se detectó un apagado desfasado (id. de evento 2213) en cualquiera de los controladores de dominio. Es posible que encuentre que el segundo controlador de dominio está esperando a completar la inicialización de SYSVOL. El motivo es que, después de la promoción, registrará un evento 4614 que indica que replicación DFS está esperando a realizar la replicación inicial. Además, no registrará un evento 4604 que indique que replicación DFS ha inicializado SYSVOL.

Si la actualización de contenido está habilitada en ambos controladores de dominio

Si el segundo controlador de dominio espera a realizar la sincronización inicial (evento 4614 registrado sin el anti-evento 4604), siga el procedimiento para forzar una sincronización autoritativa y no autoritativa para SYSVOL replicado por DFSR (como "D4/D2" para FRS) para establecer el primer controlador de dominio como autoritativo. No tiene que configurar el segundo controlador de dominio como no autenticativo, ya que ya está esperando para realizar la sincronización inicial.

O bien, si el segundo controlador de dominio es correcto y SYSVOL se comparte, siga estos pasos:
1. Realice una copia de seguridad de todo SYSVOL el contenido del primer controlador de dominio.
2. Evalúe si los datos del segundo controlador de SYSVOL dominio están actualizados. Si no es así, es posible que desee copiar los archivos actualizados SYSVOL en el segundo controlador de dominio desde el primer controlador de dominio. De lo contrario, los datos existentes presentes en el primer controlador de dominio no presentes en el segundo entrarán en las carpetas PreExisting y Conflict y Deleted .
3. Establezca el primer controlador de dominio como no autenticativo deshabilitando la pertenencia según Cómo forzar una sincronización autoritativa y no autoritativa para SYSVOL replicado por DFSR (como "D4/D2" para FRS). Confirme que se registra un identificador de evento 4114 para indicar que la pertenencia está deshabilitada.
4. Habilite la primera pertenencia del controlador de dominio y espere a los eventos 4614 y 4604 que notifican la finalización de la sincronización inicial. Si es necesario, restaure los archivos actualizados de PreExisting a la ubicación original.
Si la actualización del contenido no está habilitada o desencadenada en ambos controladores de dominio

Si el primer controlador de dominio está en estado de identificador de evento 2213, y el segundo controlador de dominio nunca ha completado la inicialización después de que se ha promocionado y no se ha desencadenado la actualización del contenido. Siga estos pasos:
1. Ejecute el ResumeReplication método WMI en el primer controlador de dominio como se indica en el evento 2213.
2. Una vez reanudada la replicación, registrará un identificador de evento 4602 que indica que replicación DFS inicializó la SYSVOL carpeta replicada y la especificó como miembro principal.
3. Ejecute el dfsrdiag pollad comando en el segundo controlador de dominio para desencadenarlo para completar la sincronización inicial (id. de evento 4614). Tan pronto como finalice la sincronización inicial, se registra el identificador de evento 4604, la SYSVOL señalización ha completado la inicialización.
O bien, si el primer controlador de dominio está en estado 2213 y el segundo controlador de dominio es correcto (SYSVOL es compartido), ejecute el ResumeReplication método WMI en el primer controlador de dominio. Registrará el identificador de evento 2214 al finalizar la recuperación de apagado desfasado.

Para entornos que tienen tres o más controladores de dominio

Determine si se detectó un apagado desfasado y si replicación DFS está en pausa en cualquier controlador de dominio (identificador de evento 2213). Es posible que encuentre un controlador de dominio a la espera de completar la inicialización de después de SYSVOL la promoción. Registrará un evento 4614 que indica que replicación DFS está esperando a realizar la replicación inicial. Tampoco registrará un evento 4604 que indique que replicación DFS ha inicializado SYSVOL.

Si la actualización de contenido está habilitada y hay tres o más controladores de dominio en el dominio.

La protección de actualización de contenido registrará un identificador de evento 4012 que indica que la replicación se ha detenido porque la replicación en la carpeta ha fallado durante más tiempo que el MaxOfflineTimeInDays parámetro . Para reinicializar la replicación DFS en los controladores de dominio afectados, siga las instrucciones de Cómo forzar una sincronización autoritativa y no autoritativa para SYSVOL replicado por DFSR (como "D4/D2" para FRS).

Si todos los controladores de dominio han registrado el evento 4012 y su estado es 5, siga las instrucciones de Cómo forzar una sincronización autoritativa y no autoritativa para SYSVOL replicado por DFSR (como "D4/D2" para FRS) para inicializar SYSVOLcompletamente . Es la única situación para establecer un servidor de replicación DFS como autoritativo. Asegúrese de que el controlador de dominio configurado como autoritativo tiene la copia más actualizada de todo el SYSVOL contenido.

O bien, si uno o varios controladores de dominio bloquean la replicación debido a la actualización del contenido, cada uno de ellos debe recuperarse de forma no autoritativa. Siga estos pasos:
1. Realice una copia de seguridad de todo SYSVOL el contenido de los controladores de dominio. Normalmente, las modificaciones de directiva se realizan en el emulador de PDC, pero no se garantiza. Los datos presentes en los controladores de dominio recuperados que no coincidan con los asociados entrarán en la carpeta PreExisting o Conflict y Deleted , o ambas.
2. Establezca los controladores de dominio como no autenticativos deshabilitando la pertenencia, como se describe en Cómo forzar una sincronización autoritativa y no autoritativa para dfSR replicada SYSVOL (como "D4/D2" para FRS). Debe tener en cuenta la topología de replicación y debe fan out desde un controlador de dominio correcto seleccionando asociados directos de ella, recuperando controladores de dominio de bajada adicionales, etc. El identificador de evento 4144 se registrará para confirmar que la pertenencia está deshabilitada. Asegúrese de que todos los controladores de dominio que requieren el registro de recuperación del evento. Puede ser necesario forzar la replicación de Active Directory y, a continuación, ejecutar el dfsrdiag pollad comando en cada controlador de dominio para detectar rápidamente la pertenencia deshabilitada.
3. Habilite la pertenencia y espere a que los eventos 4614 y 4604 notifiquen la finalización de la sincronización inicial. Restaure los archivos necesarios de la copia de seguridad o de preexisting y Conflict y Deleted según sea necesario.
Si la actualización del contenido no está habilitada o desencadenada, y hay tres o más controladores de dominio en el dominio.

Si no se desencadena la protección de actualización de contenido, ejecute el ResumeReplication método WMI en los controladores de dominio afectados. Debe tener en cuenta la topología de replicación y debe fan out desde un controlador de dominio correcto seleccionando asociados directos de ella, recuperando controladores de dominio de bajada adicionales, etc. Una vez reanudada la replicación, replicación DFS registrará los eventos 2212, 2218 y, a continuación, 2214 (lo que indica que replicación DFS inicializó la SYSVOL carpeta replicada).

Prevención de futuras apariciones del problema

Compruebe si los registros de eventos de aplicación y sistema notifican con frecuencia operaciones de recuperación de bases de datos ESENT, problemas de rendimiento de disco o ambos. Los registros de eventos suelen coincidir con los apagados inesperados del sistema, con replicación DFS que no se detiene correctamente o los errores del subsistema de disco. Considere la posibilidad de actualizar los controladores del sistema, instalar las actualizaciones adecuadas en el subsistema de disco o ponerse en contacto con el fabricante de hardware del sistema para investigar más a fondo. También puede ponerse en contacto con los Servicios de soporte al cliente de Microsoft para ayudar a evaluar el estado del sistema y el comportamiento de replicación DFS.

Service Control Manager (SCM) usa el tiempo de espera predeterminado de 20 segundos para detener un servicio. En algunas implementaciones complejas de replicación DFS, este valor de tiempo de espera puede ser demasiado corto y replicación DFS se detiene antes de que se cierre la base de datos adecuada. Al reiniciar el servicio, replicación DFS detecta esta condición y, a continuación, realiza la recuperación de la base de datos. WaitToKillServiceTimeout puede usarse para conceder a replicación DFS más tiempo para confirmar los cambios en la base de datos durante el apagado. Para obtener más información, vaya al artículo Recibirá el identificador de evento DFSR 2212 después de reiniciar el servicio DFSR.

Después de restaurar la replicación DFS de SYSVOL, el estado de replicación DFS debe supervisarse cuidadosamente en el entorno para evitar este escenario. Se recomienda revisar periódicamente los registros de eventos de replicación DFS, recopilar informes de estado de replicación DFS y recopilar el estado de replicación (mediante la consulta WMI en la sección Comprobación del estado de replicación DFS en el paso 1: evaluar el estado de replicación DFS en todos los controladores de dominio).