Erro 1053 na migração do SYSVOL para DFS Replication e AD FS MSIS7207 Evento 217: diagnóstico e solução

Se a migração do SYSVOL para DFS Replication travou e o serviço não inicia, ou o AD FS parou de publicar o WS‑Trust por causa de SPN, este guia prático mostra causas, diagnósticos e correções comprovadas para estabilizar seu Active Directory e a federação.

Índice

Erro na migração do SYSVOL para DFS Replication

Após migrar o SYSVOL do antigo FRS para o DFS Replication, é comum ver o evento 1053 no Visualizador de Eventos, indicando que um serviço do Windows não respondeu dentro do tempo limite ao iniciar. Em cenários de controlador de domínio, isso normalmente aparece junto a falhas do DFS Replication ou de serviços dependentes (por exemplo, Netlogon, Grupo de Políticas) logo após a desativação do FRS.

Sintomas observáveis

  • Serviço de replicação do DFS parado, iniciando e parando repetidamente ou apresentando tempo limite.
  • Pastas SYSVOL/NETLOGON não compartilhadas, GPOs desatualizadas em algumas sub-redes e scripts de logon inconsistentes.
  • Mensagens de “Access Denied” ou “The network path was not found” ao acessar \\domínio\SYSVOL.
  • Alertas no Gerenciador do Servidor sobre integridade de AD DS e replicação.

Causas prováveis

  • Credenciais de serviço inválidas após alterações de senha ou política de logon.
  • Dependências não iniciadas (ex.: RPC, Netlogon, Kerberos, DNS Cliente).
  • Conectividade instável entre DCs, amplificando atrasos de inicialização do DFSR.
  • Estado de migração pendente no dfsrmig (controladores ainda em modo Prepared ou Redirected).
  • Configuração corrompida do serviço, ponto de reanálise inconsistente do SYSVOL ou banco de dados do DFSR danificado.

Passo a passo recomendado

Execute as ações na ordem abaixo para cobrir desde erros simples até cenários de correção em profundidade.

PassoAçãoObjetivo
1Abrir services.msc, localizar o serviço que falhou e, em Propriedades → Logon, definir uma conta administrativa válida.Garantir que o serviço possua credenciais corretas.
2Na aba Dependências, confirmar que todos os serviços dos quais ele depende estão em execução.Eliminar falhas em cadeia.
3Reiniciar o servidor e validar se o serviço inicia corretamente.Verificar se o tempo‑limite continua a ser excedido.
4Executar dfsrmig /getmigrationstate e repadmin /replsummary para confirmar que todos os controladores concluíram as etapas da migração.Certificar‑se de que a migração para DFSR foi concluída com sucesso.
5Se persistir, remover e reinstalar o serviço ou, em cenários críticos, considerar uma reinstalação limpa do controlador já diretamente com DFSR.Resolver configurações corrompidas ou inconsistentes.

Verificações rápidas em linha de comando

Use estes comandos para identificar rapidamente gargalos e pendências de replicação:

dfsrmig /getmigrationstate
repadmin /replsummary
repadmin /showrepl * /csv
dfsrdiag backlog /rgname:"Domain System Volume" /rfname:SYSVOL /smem:<DCorigem> /rmem:<DCdestino>
dfsrdiag replicationstate
sc query DFSR
wevtutil qe Microsoft-Windows-DFSR/Operational /f:text /c:50

Validações pós‑correção

  • Compartilhamentos SYSVOL e NETLOGON visíveis e acessíveis a partir de estações em diferentes sub-redes.
  • GPOs aplicadas sem erros (gpupdate /force e gpresult /r sem falhas de processamento).
  • Estado de migração retornando “Eliminated” para todos os DCs e backlog próximo de zero.

Complementos essenciais

  • Verifique DNS e rede entre os controladores (resolução direta e reversa), pois falhas de conectividade são causa frequente do evento 1053.
  • Mantenha o nível funcional do domínio em pelo menos Windows Server 2008 para aposentar completamente o FRS (idealmente, níveis mais recentes).

Falha de SPN no serviço de federação

No AD FS, o evento 217 com MSIS7207 aparece quando o serviço não consegue abrir o endpoint WS‑Trust em https://<adfs>/adfs/services/trust/13/windowstransport porque o Service Principal Name do usuário de serviço configurado (muitas vezes Local System) não pode ser recuperado. Em ambientes corporativos, a prática recomendada é operar o AD FS com uma conta de serviço dedicada (idealmente uma gMSA) e registrar os SPNs correspondentes.

Como diagnosticar rapidamente

  • Verifique o status dos endpoints: Get-ADFSEndpoint | Sort-Object FullUrl | Format-Table FullUrl,Enabled,Proxy.
  • Liste SPNs atuais da conta de serviço: setspn -L DOM\svc_adfs (ou da gMSA).
  • Teste TLS e autenticação integrada: Invoke-WebRequest https://<adfs>/adfs/services/trust/13/windowstransport -UseDefaultCredentials.
  • Limpe tickets em servidores de teste: klist purge e repita o acesso para descartar credenciais em cache.

Correção recomendada

  1. Criar ou designar uma conta de serviço dedicada no domínio (ex.: DOM\svc_adfs) ou uma gMSA.
  2. Registrar os SPNs necessários para a nova conta: setspn -S host/<adfsFQDN> DOM\svc_adfs setspn -S http/<adfsFQDN> DOM\svc_adfs
  3. Reconfigurar o AD FS para usar essa conta em vez de Local System (via fsconfig.exe ou Gerenciador do AD FS → Configurações de Serviço → Conta de Serviço).
  4. Reiniciar o serviço do AD FS e confirmar, via Get-ADFSEndpoint, que o WS‑Trust está habilitado e ativo.
  5. Validar certificados (cadeia e correspondência com o FQDN) e rotas de rede; problemas aqui também impedem a publicação do endpoint.

Notas importantes

  • SPN mal configurado ou duplicado causa falhas Kerberos. Para encontrar conflitos: setspn -X.
  • Se sua organização usa Web Application Proxy, atualize a confiança após alterar a conta de serviço para evitar discrepância de credenciais.
  • Prefira gMSA para rotação automática de senha e menor esforço operacional.

Verificações pós‑correção

  • Endpoints essenciais do AD FS habilitados e sem erro de autenticação integrada.
  • Eventos de erro deixam de ser gerados e o acesso interno via Windows Integrated retorna HTTP 200.
  • Proxies WAP conseguem renovar confiança e publicar as aplicações.

Conectividade de rede entre controladores

Falhas de rede pioram a transição de FRS para DFSR e impedem a publicação de serviços do AD FS. Antes de culpar serviços, valem testes estruturados de DNS, portas e latência fim‑a‑fim.

Boas práticas
• Testar resolução DNS de ambos os lados (nslookup, ping).
• Garantir que portas de replicação RPC 135, 49152‑65535 e portas do AD FS (TCP 443, TCP 49443) estejam abertas.
• Monitorar latência e perda de pacotes com pathping.

Checklist de portas e serviços

ComponentePortasObservações
Replicação do AD e DFSRRPC 135 e intervalo dinâmico 49152‑65535Permitir epmapper e alocação dinâmica de RPC nos firewalls.
SMB e SYSVOLTCP 445Acesso a \\domínio\SYSVOL e \\domínio\NETLOGON.
AutenticaçãoUDP/TCP 88, 464, 389, 636Kerberos, LDAP e LDAPS.
AD FSTCP 443 e, quando aplicável, TCP 49443Verificar compatibilidade de TLS e inspeção SSL em firewalls.

Testes práticos de rede

nslookup &lt;dcFQDN&gt;
ping &lt;dcFQDN&gt;
Test-NetConnection -ComputerName &lt;dcFQDN&gt; -Port 135
Test-NetConnection -ComputerName &lt;dcFQDN&gt; -Port 445
Test-NetConnection -ComputerName &lt;adfsFQDN&gt; -Port 443
pathping &lt;dcFQDN&gt;

Ajustes de DNS que evitam dores de cabeça

  • Conferir registros SRV em ldap.tcp.dc._msdcs.<domínio>.
  • Garantir encaminhadores, zonas de pesquisa direta e reversa consistentes entre sites.
  • Re‑registrar registros do DC: ipconfig /registerdns e nltest /dsregdns.
  • Executar dcdiag /test:DNS /e /v para validação abrangente.

Procedimentos avançados para casos persistentes

Se, após as correções básicas, o ambiente continuar instável, considere intervenções controladas com janela de manutenção e backup prévio.

Sincronização autoritativa do SYSVOL no DFSR

Quando um DC está inconsistente e não converte sozinho, é possível promover um membro conhecido como “fonte de verdade” e forçar a reconciliação. Em alto nível:

  1. Parar o serviço DFSR no DC problemático e no DC de referência.
  2. Desabilitar temporariamente a replicação do grupo do SYSVOL no DC que será autoritativo e marcar o estado autoritativo no objeto de replicação.
  3. Forçar leitura do AD com dfsrdiag pollad e reiniciar o serviço.
  4. Reativar o grupo no(s) demais DCs e aguardar a conclusão do backlog.

Observação: a execução detalhada exige conhecimento de atributos de replicação no AD. Faça em ambiente de testes primeiro e documente o estado anterior.

Recriação limpa de um controlador de domínio

Se o controlador demonstra falhas de serviço recorrentes, reconsidere a manutenção prolongada. Muitas vezes é mais rápido e seguro:

  1. Transferir ou apreender funções de mestre de operações, se necessário.
  2. Remover o DC com Uninstall-ADDSDomainController (forçando metadados apenas em último caso).
  3. Instalar novamente como DC já em ambiente exclusivamente com DFSR.
  4. Verificar replicação, SYSVOL, GPOs e catálogos globais.

Fluxo prático de correção ponta a ponta

  1. Checar credenciais e dependências do serviço com falha.
  2. Validar portas, DNS e latência entre DCs e servidores de federação.
  3. Conferir estado da migração do SYSVOL e backlog de replicação.
  4. Normalizar SPNs do AD FS e mover para conta de serviço dedicada.
  5. Reiniciar serviços, validar endpoints e compartilhamentos.
  6. Aplicar procedimentos avançados somente se os itens anteriores não resolverem.

Perguntas frequentes

É possível manter o FRS em paralelo ao DFSR?

Não é recomendado. Em ambientes modernos, o FRS está obsoleto. Conclua a migração e elimine o FRS para reduzir riscos e viabilizar controladores recentes.

Quais sinais indicam que a migração terminou de fato?

dfsrmig /getmigrationstate retorna todos os DCs em Eliminated, backlog próximo de zero, compartilhamentos do SYSVOL consistentes e GPOs aplicando em todos os sites.

Trocar a conta de serviço do AD FS derruba o acesso externo?

A troca é transacional, mas proxies WAP precisam atualizar confiança. Planeje uma breve janela, sincronize certificados e confirme o pass‑through após a mudança.

Como monitorar a saúde da replicação ao longo do tempo?

Automatize coletas periódicas de repadmin /replsummary e dfsrdiag backlog, com alertas para picos de fila, e acompanhe o log operacional do DFSR.

Resumo consolidado

ItemProblema raizAção imediataAção preventiva
SYSVOL com erro de serviçoServiço não inicia após migração para DFSRReconfigurar logon do serviço, checar dependências, confirmar estado da migraçãoPlanejar migração completa e aposentar FRS
Federação com falha de SPNSPN ausente ou incorreto usando Local SystemCriar conta de serviço, registrar SPNs corretos, reconfigurar AD FSGestão centralizada de SPN e validação periódica
Replicação e federação entre sitesConectividade de rede instávelTestes de DNS, portas e latência; ajuste de firewallMonitoramento contínuo da rede entre DCs

Comandos prontos para uso

Replicação e migração do SYSVOL

:: Estado da migração
dfsrmig /getglobalstate
dfsrmig /getmigrationstate

\:: Sumário de replicação AD
repadmin /replsummary

\:: Backlog do SYSVOL entre membros
dfsrdiag backlog /rgname:"Domain System Volume" /rfname\:SYSVOL /smem:\ /rmem:\

\:: Estado do serviço e logs operacionais
sc query DFSR
wevtutil qe Microsoft-Windows-DFSR/Operational /c:100 /f\:text 

Federação e SPN

:: SPNs
setspn -L DOM\svc_adfs
setspn -S host/<adfsFQDN> DOM\svc_adfs
setspn -S http/<adfsFQDN> DOM\svc_adfs
setspn -X

\:: Endpoints do AD FS
Get-ADFSEndpoint | Sort-Object FullUrl | Format-Table FullUrl,Enabled,Proxy

\:: Teste de WS-Trust com autenticação integrada
Invoke-WebRequest https\://\/adfs/services/trust/13/windowstransport -UseDefaultCredentials 

Rede e DNS

nslookup &lt;dcFQDN&gt;
Test-NetConnection -ComputerName &lt;dcFQDN&gt; -Port 135
Test-NetConnection -ComputerName &lt;dcFQDN&gt; -Port 445
Test-NetConnection -ComputerName &lt;adfsFQDN&gt; -Port 443
pathping &lt;dcFQDN&gt;
dcdiag /test:DNS /e /v

Checklist de campo para encerrar a ocorrência

  • Serviço do DFSR iniciando sem eventos de tempo limite.
  • Compartilhamentos do SYSVOL e NETLOGON acessíveis em todos os sites.
  • Backlog do DFSR controlado e estado de migração Eliminated.
  • SPNs do AD FS corretos e sem duplicidade.
  • Endpoints do AD FS habilitados, teste de WS‑Trust bem‑sucedido.
  • Portas e DNS verificados; métricas de latência dentro do aceitável.
  • Registro de lições aprendidas e plano de prevenção aplicado.

Boas práticas para o dia seguinte

  • Aplicar monitoramento do backlog do DFSR e de eventos‑chave do AD FS.
  • Adotar gMSA onde possível para serviços sensíveis a SPN.
  • Padronizar templates de GPO e revisão de permissões do SYSVOL.
  • Revisar firewalls entre sites e habilitar exceções de RPC dinâmico.
  • Sustentar nível funcional do domínio compatível com controladores modernos.

Seguindo estas etapas, a replicação do SYSVOL via DFS Replication tende a estabilizar e o endpoint do AD FS volta a operar, restabelecendo um ambiente de diretório e federação funcional, previsível e moderno.

Índice