Compartilhar via

Como solucionar problemas de compartilhamentos SYSVOL e Netlogon ausentes

Este artigo fornece as etapas para solucionar problemas de compartilhamentos ausentes SYSVOL no Netlogon Windows Server 2012 R2.

Número original do KB: 2958414

Sintomas

SYSVOL e Netlogon os compartilhamentos não são compartilhados em um controlador de domínio. Os seguintes sintomas ou condições também podem ocorrer:

  • A sysvol pasta está vazia.
  • O controlador de domínio afetado foi promovido recentemente.
  • O ambiente contém controladores de domínio que executam versões do Windows anteriores ao Windows Server 2012 R2.
  • A Replicação DFS é usada para replicar a SYSVOL pasta Compartilhar replicado.
  • O serviço de Replicação DFS de um controlador de domínio upstream está em um estado de erro.

Motivo

Os controladores de domínio sem SYSVOL compartilhamento não podem replicar a entrada porque os controladores de domínio upstream (origem) estão em um estado de erro. Freqüentemente (mas não se limitando a), os servidores upstream interromperam a replicação devido a um desligamento sujo (ID de evento 2213).

Resolução

Esta seção contém métodos recomendados para solucionar problemas e resolver compartilhamentos ausentes SYSVOL e Netlogon compartilhados em controladores de domínio que são replicados usando o serviço de Replicação DFS.

O processo reinicializará a Replicação DFS se SYSVOL não for compartilhada em controladores de domínio de acordo com Como forçar uma sincronização autoritativa ou não autoritativa para SYSVOL replicado por DFSR (como "D4/D2" para FRS). É desnecessário na maioria dos casos e pode causar perda de dados se feito incorretamente. Além disso, impede determinar a causa do problema e evitar ocorrências futuras do problema.

O que se segue são etapas gerais para investigar os compartilhamentos ausentes. Determine se o problema é causado por uma ocorrência única ou se os controladores de domínio upstream não podem dar suporte à replicação usando a Replicação DFS.

A exclusão do banco de dados de Replicação DFS do volume não deve ser necessária e é desencorajada. Isso faz com que a Replicação DFS considere todos os dados locais no servidor como não autoritativos. Ao permitir que a Replicação DFS recupere o banco de dados normalmente (conforme instruído no evento 2213), o último gravador ainda ganhará todas as versões conflitantes dos SYSVOL dados.

Etapa 1 – Avaliar o estado da Replicação DFS em todos os controladores de domínio

Avalie quantos controladores de domínio não estão compartilhando SYSVOL, registraram recentemente um evento de erro e quantos controladores de domínio estão em um estado de erro. Siga estas etapas.

  • Verifique o SYSVOL compartilhamento

    Você pode verificar manualmente se SYSVOL é compartilhado ou inspecionar cada controlador de domínio usando o comando net view:

    For /f %i IN ('dsquery server -o rdn') do @echo %i && @(net view \\%i | find "SYSVOL") & echo

  • Verificar o estado da Replicação DFS

    Para verificar o estado da Replicação DFS em controladores de domínio, você pode consultar o WMI. Você pode consultar todos os controladores de domínio no domínio para a pasta Compartilhar replicado usando o SYSVOL WMI da seguinte maneira:

    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

    Os state valores podem ser qualquer um dos seguintes:
    0 = Não inicializado
    1 = Inicializado
    2 = Sincronização inicial
    3 = Recuperação automática
    4 = Normal
    5 = Em erro

    Observação

    Dependendo da condição de um controlador de domínio, ele pode falhar ao relatar um valor de estado e indicar que nenhuma instância está disponível.

  • Verifique os logs de eventos em busca de erros ou avisos recentes

    Se algum controlador de domínio não relatar a SYSVOL pasta Compartilhar replicado como estando em um estado 4 (normal), verifique o log de eventos desses controladores de domínio para avaliar sua condição. Examine cada controlador de domínio em busca de erros ou avisos recentes no log de eventos da Replicação DFS, como a ID do evento de aviso 2213 que indica que a Replicação DFS está pausada no momento.

  • Verificar a configuração de Atualização de conteúdo

    Determine se a Replicação DFS disparou a proteção de atualização de conteúdo nos controladores de domínio afetados. A Atualização de Conteúdo está habilitada em controladores de domínio do Windows Server 2012 (e versões posteriores) por padrão. No entanto, ele também pode ser habilitado manualmente em servidores Windows Server 2008 R2.

    Para avaliar se a atualização do conteúdo está habilitada, a MaxOfflineTimeInDays configuração será definida como 60. Se a atualização do conteúdo estiver desabilitada, MaxOfflineTimeInDays será definido como 0. Para verificar MaxOfflineTimeInDayso , execute o seguinte comando:

    wmic.exe /node:%computername% /namespace:\\root\microsoftdfs path DfsrMachineConfig get MaxOfflineTimeInDays

    Para consultar todos os controladores de domínio no domínio, execute o seguinte 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 domínio habilitado para atualização de conteúdo, avalie se a Replicação DFS registrou uma ID de evento 4012 que indica que a replicação da pasta foi interrompida porque a replicação falhou por mais tempo do que o MaxOfflineTimeInDays parâmetro.

Etapa 2 – Preparar os controladores de domínio que estão em um estado de erro

  • Instale as atualizações apropriadas

    Para todos os controladores de domínio que executam o Windows Server 2008 R2, primeiro instale as atualizações da Replicação DFS para evitar a perda de dados e corrigir problemas conhecidos. É uma prática recomendada usar a versão mais recente da Replicação DFS. Consulte Lista de hotfixes atualmente disponíveis para tecnologias DFS (Sistema de Arquivos Distribuído) para obter a versão mais recente da Replicação DFS.

  • Fazer backup de SYSVOL dados

    Faça um backup dos dados (se houver) em cada controlador de SYSVOL domínio. Os backups podem ser uma cópia de arquivo do SYSVOL conteúdo para um local seguro ou pode ser um backup que usa software de backup.

    Dependendo da situação, os arquivos de política podem ser movidos para PreExistente ou Conflito e Excluídos. Os conteúdos PreExisting e Conflict e Deleted serão removidos se a sincronização inicial for feita várias vezes em um servidor. Faça backup dos dados nesses locais para evitar a perda de dados.

Etapa 3 – Recuperar a Replicação DFS nos controladores de domínio no estado de erro

Com base no número de controladores de domínio no domínio, selecione o método apropriado para recuperar o serviço de Replicação DFS.

Para ambientes que têm dois controladores de domínio

Determine se um desligamento sujo foi detectado (ID de evento 2213) em qualquer um dos controladores de domínio. Você pode descobrir que o segundo controlador de domínio está aguardando para concluir a inicialização do SYSVOL. O motivo é que, após a promoção, ele registrará um evento 4614 que indica que a Replicação DFS está aguardando para fazer a replicação inicial. Além disso, ele não registrará um evento 4604 sinalizando que a Replicação DFS inicializou SYSVOL.

  • Se a atualização de conteúdo estiver habilitada em ambos os controladores de domínio

    Se o segundo controlador de domínio aguardar para fazer a sincronização inicial (evento 4614 registrado sem o antievento 4604), siga o Como forçar uma sincronização autoritativa e não autoritativa para SYSVOL replicado por DFSR (como "D4/D2" para FRS) para definir o primeiro controlador de domínio como autoritativo. Você não precisa configurar o segundo controlador de domínio como não autoritativo, pois ele já está aguardando para fazer a sincronização inicial.

    Ou, se o segundo controlador de domínio estiver íntegro e SYSVOL for compartilhado, execute as seguintes etapas:

    1. Faça backup de todo SYSVOL o conteúdo do primeiro controlador de domínio.

    2. Avalie se os dados do segundo controlador de SYSVOL domínio estão atualizados. Caso contrário, talvez você queira copiar arquivos atualizados SYSVOL para o segundo controlador de domínio do primeiro controlador de domínio. Caso contrário, todos os dados existentes presentes no primeiro controlador de domínio não presentes no segundo irão para as pastas PreExisting e Conflict e Deleted .

    3. Defina o primeiro controlador de domínio como não autoritativo desabilitando a associação de acordo com Como forçar uma sincronização autoritativa e não autoritativa para SYSVOL replicado por DFSR (como "D4/D2" para FRS). Confirme se uma ID de evento 4114 está registrada para indicar que a associação está desabilitada.

    4. Habilite a associação do primeiro controlador de domínio e aguarde os eventos 4614 e 4604 que relatam a conclusão da sincronização inicial. Se necessário, restaure todos os arquivos atualizados de PreExisting para o local original.

  • Se a atualização de conteúdo não estiver habilitada ou disparada em ambos os controladores de domínio

    Se o primeiro controlador de domínio estiver no estado de ID de evento 2213 e o segundo controlador de domínio nunca tiver concluído a inicialização depois de ter sido promovido e a atualização do conteúdo não tiver sido disparada. Execute as seguintes etapas:

    1. Execute o ResumeReplication método WMI no primeiro controlador de domínio, conforme instruído no evento 2213.

    2. Depois que a replicação for retomada, ela registrará uma ID de evento 4602 que indica que a Replicação DFS inicializou a SYSVOL pasta replicada e a especificou como o membro primário.

    3. Execute o dfsrdiag pollad comando no segundo controlador de domínio para dispará-lo para concluir a sincronização inicial (ID do evento 4614). Assim que a sincronização inicial for concluída, a ID do evento 4604 será registrada, a SYSVOL sinalização terá concluído a inicialização.

    Ou, se o primeiro controlador de domínio estiver no estado 2213 e o segundo controlador de domínio estiver íntegro (SYSVOL compartilhado), execute o ResumeReplication método WMI no primeiro controlador de domínio. Ele registrará a ID de evento 2214 na conclusão da recuperação de desligamento sujo.

Para ambientes que têm três ou mais controladores de domínio

Determine se um desligamento sujo foi detectado e se a Replicação DFS está pausada em algum controlador de domínio (ID de evento 2213). Você pode descobrir que um controlador de domínio está aguardando para concluir a inicialização após SYSVOL a promoção. Ele registrará um evento 4614 que indica que a Replicação DFS está aguardando para fazer a replicação inicial. Ele também não registrará um evento 4604 sinalizando que a Replicação DFS inicializou SYSVOL.

  • Se a atualização de conteúdo estiver habilitada e houver três ou mais controladores de domínio no domínio.

    A proteção de atualização de conteúdo registrará uma ID de evento 4012 que indica que a replicação foi interrompida porque a replicação na pasta falhou por mais tempo do que o MaxOfflineTimeInDays parâmetro. Para reinicializar a Replicação DFS no(s) controlador(es) de domínio afetado(s), siga as instruções em Como forçar uma sincronização autoritativa e não autoritativa para SYSVOL replicado por DFSR (como "D4/D2" para FRS).

    Se todos os controladores de domínio tiverem registrado o evento 4012 e seu estado for 5, siga as instruções em Como forçar uma sincronização autoritativa e não autoritativa para SYSVOL replicado por DFSR (como "D4/D2" para FRS) para inicializar SYSVOLcompletamente. É a única situação para definir um servidor de Replicação DFS como autoritativo. Verifique se o controlador de domínio configurado como autoritativo tem a cópia mais atualizada de todo SYSVOL o conteúdo.

    Ou, se um ou mais controladores de domínio estiverem bloqueando a replicação devido à atualização do conteúdo, cada um deles deverá ser recuperado de forma não autoritativa. Siga estas etapas:

    1. Faça backup de todo SYSVOL o conteúdo do(s) controlador(es) de domínio. Normalmente, as edições de política são feitas no Emulador PDC, mas isso não é garantido. Todos os dados presentes nos controladores de domínio recuperados que não corresponderem aos parceiros irão para a pasta PreExisting ou Conflict and Deleted , ou ambas.

    2. Defina os controladores de domínio como não autoritativos desabilitando a associação, conforme descrito em Como forçar uma sincronização autoritativa e não autoritativa para replicados por DFSR SYSVOL (como "D4/D2" para FRS). Você deve estar ciente da topologia de replicação e deve se espalhar de um controlador de domínio íntegro selecionando parceiros diretos dele e, em seguida, recuperando outros controladores de domínio downstream e assim por diante. A ID do evento 4144 será registrada para confirmar que a associação está desabilitada. Verifique se todos os controladores de domínio que exigem recuperação registram o evento. Pode ser necessário forçar a replicação do Active Directory e, em seguida, executar o dfsrdiag pollad comando em cada controlador de domínio para detectar rapidamente a associação desabilitada.

    3. Habilite a associação e aguarde até que os eventos 4614 e 4604 relatem a conclusão da sincronização inicial. Restaure todos os arquivos necessários do backup ou de PreExistente e Conflito e Excluído conforme necessário.

  • Se a atualização de conteúdo não estiver habilitada ou disparada e houver três ou mais controladores de domínio no domínio

    Se a proteção de atualização de conteúdo não for disparada, execute o ResumeReplication método WMI nos controladores de domínio afetados. Você deve estar ciente da topologia de replicação e deve se espalhar de um controlador de domínio íntegro selecionando parceiros diretos dele e, em seguida, recuperando outros controladores de domínio downstream e assim por diante. Depois que a replicação for retomada, a Replicação DFS registrará os eventos 2212, 2218 e, em seguida, 2214 (indicando que a Replicação DFS inicializou a SYSVOL pasta replicada).

Prevenção de ocorrências futuras do problema

Verifique se os logs de eventos do aplicativo e do sistema estão relatando frequentemente operações de recuperação de banco de dados ESENT, problemas de desempenho de disco ou ambos. Os logs de eventos normalmente coincidem com desligamentos inesperados do sistema, com a Replicação DFS não parando normalmente ou falhas no subsistema de disco. Considere atualizar os drivers do sistema, instalar atualizações apropriadas no subsistema de disco ou entrar em contato com o fabricante do hardware do sistema para investigar mais. Você também pode entrar em contato com o Atendimento ao Cliente da Microsoft para ajudar a avaliar a integridade do sistema e o comportamento da Replicação DFS.

O SCM (Gerenciador de Controle de Serviço) usa o tempo limite padrão de 20 segundos para interromper um serviço. Em algumas implementações complexas da Replicação DFS, esse valor de tempo limite pode ser muito curto e a Replicação DFS é interrompida antes que o banco de dados apropriado seja fechado. Na reinicialização do serviço, a Replicação DFS detecta essa condição e faz a recuperação do banco de dados. WaitToKillServiceTimeout pode ser usado para conceder à Replicação DFS mais tempo para confirmar alterações no banco de dados durante o desligamento. Para obter mais informações, acesse o artigo Você recebe a ID de evento DFSR 2212 depois de reiniciar o serviço DFSR.

Depois de restaurar a Replicação DFS do , a integridade da SYSVOLReplicação DFS deve ser cuidadosamente monitorada no ambiente para evitar esse cenário. Recomenda-se a revisão regular dos logs de eventos da Replicação DFS, a coleta de relatórios de integridade da Replicação DFS e a coleta do estado da replicação (usando a consulta WMI na seção Verificar estado da Replicação DFS na Etapa 1 – Avaliar o estado da Replicação DFS em todos os controladores de domínio).