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

  • Artículo

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

Se aplica a: Windows Server 2012 R2, Windows Server 2008 R2 Service Pack 1
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.
  • La replicación DFS se usa para replicar la SYSVOL carpeta Replicada de Share.
  • 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 entrantes debido a que los controladores de dominio ascendentes (de 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 sucio (identificador de evento 2213).

Solución

Esta sección contiene los métodos recomendados para solucionar problemas y resolver los recursos compartidos que faltan SYSVOL en Netlogon los 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 dfsr (como "D4/D2" para FRS). En la mayoría de los casos, no es necesario y puede provocar la pérdida de datos si se realiza incorrectamente. Además, impide determinar la causa del problema y evitar futuras repeticiones 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.

La eliminación de la base de datos de replicación DFS del volumen no debe ser necesaria y no se recomienda. Hace que la replicación DFS considere que todos los datos locales del servidor no son autenticados. Al permitir que replicación DFS recupere la base de datos correctamente (como se indica en el evento 2213), el último escritor seguirá ganando cualquier versión en conflicto de SYSVOL datos.

Paso 1: Evaluar el estado de la 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 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 la replicación DFS en los controladores de dominio, puede consultar WMI. Puede consultar todos los controladores de dominio del dominio para la SYSVOL carpeta Compartir replicada mediante WMI de la siguiente manera:

    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:

    En función de la condición de un controlador de dominio, puede que no informe de un valor de estado e indique que no hay instancias disponibles.

  • Comprobación de los registros de eventos para ver si hay errores o advertencias recientes

    Si algún controlador de dominio no informa de que la SYSVOL carpeta Compartir replicada se encuentra 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 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 la replicación DFS está actualmente en pausa.

  • Comprobación de la configuración de actualización de contenido

    Determine si la 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 los controladores de dominio Windows Server 2012 (y versiones posteriores) de forma predeterminada. Sin embargo, también puede habilitarse manualmente en servidores de Windows Server 2008 R2.

    Para evaluar si la actualización del contenido está habilitada, 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 producido un error 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

  • Instalación de las actualizaciones adecuadas

    En el caso de los controladores de dominio que ejecutan 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 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 datos (si está presente) 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 usa software de copia de seguridad.

    En función de la situación, los archivos de directiva se pueden mover a Preexistente o Conflicto y Eliminar. El contenido preexistentey en conflicto y eliminado se purgará si la sincronización inicial se realiza varias veces en un servidor. Realice una copia de seguridad de 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 estado de error

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

Para entornos que tienen dos controladores de dominio

Determine si se detectó un apagado sucio (identificador de evento 2213) en cualquiera de los controladores de dominio. Es posible 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 la 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 antievento 4604), siga cómo forzar una sincronización autoritativa y no autoritativa para SYSVOL replicado con DFSR (como "D4/D2" para FRS) para establecer el primer controlador de dominio como autoritativo. No es necesario configurar el segundo controlador de dominio como no autenticado, porque ya está esperando a 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 que no estén presentes en el segundo pasarán a las carpetas Preexisten y Conflictos y Eliminados .

    3. Establezca el primer controlador de dominio como no autenticado 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 ha registrado un identificador de evento 4114 para indicar que la pertenencia está deshabilitada.

    4. Habilite la pertenencia del primer 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 de contenido no está habilitada o desencadenada en ambos controladores de dominio

    Si el primer controlador de dominio está en el estado del identificador de evento 2213 y el segundo controlador de dominio nunca ha completado la inicialización después de su promoción, 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). En cuanto finaliza la sincronización inicial, se registra el identificador de evento 4604, la señalización SYSVOL ha completado la inicialización.

    O bien, si el primer controlador de dominio está en el estado 2213 y el segundo controlador de dominio es correcto (SYSVOL se comparte), 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 sucio.

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

Determine si se detectó un apagado sucio y si la replicación DFS está en pausa en cualquier controlador de dominio (identificador de evento 2213). Es posible que un controlador de dominio esté esperando a completar la inicialización de después de la SYSVOL promoción. Registrará un evento 4614 que indica que la 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 producido un error 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 con 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 tenga la copia más actualizada de todo el SYSVOL contenido.

    O bien, si uno o más 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 directivas 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 pasarán a la carpeta Preexistente o Conflicto y Eliminado , o ambos.

    2. Establezca los controladores de dominio como no autenticados 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 alejarse de un controlador de dominio correcto seleccionando asociados directos de ella, recuperando más controladores de dominio de nivel inferior, 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 recuperación registren el evento. Puede que sea necesario forzar la replicación de Active Directory y, a continuación, ejecutar el dfsrdiag pollad comando en cada controlador de dominio para detectar la pertenencia deshabilitada rápidamente.

    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 desde la copia de seguridad o desde preexistente y en conflicto y eliminado según sea necesario.

  • Si la actualización de 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 alejarse de un controlador de dominio correcto seleccionando asociados directos de ella, recuperando más controladores de dominio de nivel inferior, 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 repeticiones del problema

Compruebe si los registros de eventos de la aplicación y del sistema notifican con frecuencia operaciones de recuperación de base de datos ESENT, problemas de rendimiento de disco o ambas. Los registros de eventos suelen coincidir con apagados inesperados del sistema, con errores de replicación DFS que no se detienen correctamente o 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 la replicación DFS se detiene antes de que se cierre la base de datos adecuada. En el reinicio del servicio, replicación DFS detecta esta condición y, a continuación, realiza la recuperación de la base de datos. WaitToKillServiceTimeout se puede usar para conceder a la 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 You receive DFSR event ID 2212 after you restart the DFSR service (Recibirá el identificador de evento DFSR 2212 después de reiniciar el servicio DFSR).

Después de restaurar la replicación DFS de , el estado de SYSVOLreplicació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 de la sección Comprobar estado de replicación DFS en Paso 1: Evaluar el estado de replicación DFS en todos los controladores de dominio).