Perdeu os compartilhamentos SYSVOL e NETLOGON depois de adicionar um novo Controlador de Domínio (DC) e agora todo gpupdate devolve erro? Este guia completo mostra, passo a passo, como restaurar a replicação, recuperar as Políticas de Grupo (GPOs) e garantir que o seu ambiente Active Directory volte a operar com saúde total.
Ambiente e sintomas do problema
Em uma floresta única com um único domínio foram promovidos dois servidores:
- DC principal – originalmente Windows Server 2008 R2, atualizado in‑place para Windows Server 2016 Datacenter sem incidentes.
- DC adicional – ingressou no domínio, replicou por cerca de uma semana e passou a apresentar no Event Viewer (ID 1058/1030):
The processing of Group Policy failed… Windows attempted to read the file \\DOMÍNIO\SYSVOL\DOMÍNIO\Policies\{GUID}\gpt.ini…
No DC adicional, as pastas SYSVOL e NETLOGON desapareceram. Após alterar a chave do Netlogon (HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\SysVolReady=1) os compartilhamentos voltaram, mas o conteúdo de políticas continuou ausente, mantendo o erro do gpupdate.
Por que o SYSVOL é crucial
Todo objeto de política (GPO) é dividido em duas partes:
- Metadata (objeto de diretório) replicado via AD DS.
- Conteúdo físico (scripts, modelos ADM/X etc.) armazenado em
\<domínio>\SYSVOL\Policiese replicado por FRS ou DFSR.
Se a camada de arquivos deixa de sincronizar, o AD continua mostrando o GPO, mas esta “capa vazia” gera falhas porque o cliente não encontra gpt.ini. O alvo, portanto, é restaurar a coesão entre metadados e arquivos.
Visão geral da correção
Há dois mecanismos históricos de replicação para a pasta SYSVOL:
- FRS (File Replication Service) – legado, depreciado no Windows Server 2016.
- DFSR (Distributed File System Replication) – padrão a partir do 2008 R2 (feature update).
O procedimento difere ligeiramente entre eles, mas o conceito é o mesmo: realizar uma sincronização não‑autoritativa no DC problemático (análogo ao antigo D2), forçando‑o a baixar um novo snapshot do DC saudável.
Fluxo de trabalho consolidado
| Etapa | Ação detalhada | Objetivo |
|---|---|---|
| 1. Verificar a saúde da replicação AD | repadmin /showrepl repadmin /replsum repadmin /showrepl * /csv > C:\temp\repl.csv | Confirma que metadados do AD estão íntegros. Todos os conectores devem exibir 0 fails. |
| 2. Criar backup de segurança | Imagem completa de todos os DCs + cópia da pasta SYSVOL local. | Garante ponto de retorno em caso de erro ou corrupção inadvertida. |
| 3. Identificar mecanismo de replicação | No DC principal verifique:reg query HKLM\System\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrating Sysvols /v LocalState Valor 3 = DFSR finalizado; sem chave ou valor diferente indica ambiente ainda em FRS. | Define qual procedimento (DFSR ou FRS) aplicar. |
| 4. Sincronização não‑autoritativa (DFSR) | net stop dfsr Renomear C:\Windows\SYSVOL\domain para domain.old net start dfsr dfsrdiag pollad Aguardar Event ID 4114 (replicação suspensa) seguido de 4614/4604. | Força o DC a descartar o conteúdo local e copiar um snapshot íntegro do parceiro. |
| 5. Cenário FRS legado | No DC saudável: definir BurFlags=D4. No DC problemático: definir BurFlags=D2. Reiniciar serviço NTFRS em ambos. | Equivalente DFSR acima, mas usando a semântica FRS (autoritativo × não‑autoritativo). |
| 6. Validar pós‑replicação | gpupdate /force dcdiag /v | find "failed" | O gpupdate deve concluir sem erro de leitura de gpt.ini. |
| 7. Checar acesso e credenciais | Acesso a \\dominio.local\SYSVOL via Explorer. Logado como Administrador do Domínio. Hora, DNS, roteamento e portas 445/135 liberadas. | Qualquer prompt de usuário/senha indica falha de Kerberos ou confiança entre servidores. |
Entendendo o que acontece em cada etapa
Etapa 1 – Repadmin: desfaz a tentação de culpar a replicação de arquivos quando, na verdade, o problema pode ser atribuível aos metadados. Um erro em repadmin deve ser resolvido antes de continuar.
Etapa 3 – Mecanismo: muitos domínios que começaram no Windows Server 2003 ou 2008 ainda executam FRS. Entretanto, o Windows Server 2019+ impede a promoção de DCs se o domínio não estiver em DFSR. Aproveite para planejar a migração definitiva usando dfsrmig.exe.
Etapa 4 – DFSR não‑autoritativo: ao renomear a pasta domain você evita conflito entre conteúdo corrompido e o novo snapshot. Quando o serviço DFSR inicia ele detecta pasta ausente, lê o AD e baixa arquivos confiáveis.
BurFlags no FRS: os valores são binários, mas pense assim: D4 diz “eu sou a cópia boa”, D2 diz “apague tudo e baixe de novo”. Sempre aplique D4 em um único DC.
Ferramentas indispensáveis na triagem
dcdiag /test:frssysvol– aponta permissões quebradas, ausência de compartilhamentos ou serviço FRS parado.dfsrdiag backlog /sendingmember:DC1 /receivingmember:DC2 /rgname:"Domain System Volume"– exibe fila pendente arquivo a arquivo.eventvwr.msc> Applications and Services Logs > DFS Replication – monitore IDs 4000, 5002, 2213.
Quando é melhor despromover e promover de novo?
Se o DC extra foi criado recentemente e não hospeda funções adicionais (DNS, DHCP, CA), muitas vezes é mais rápido:
- Executar
dcpromo /forceremoval(ou Server Manager ➜ Remove Roles nas versões mais novas). - Remover metadados órfãos (
ntdsutil → metadata cleanup). - Excluir o objeto do Sites and Services.
- Promover novamente, permitindo que o assistente crie
SYSVOLdo zero.
Boas práticas pós‑recuperação
- Verifique se o número de GUIDs na pasta
Policiesé idêntico em todos os DCs. - Abra a Group Policy Management Console (GPMC) e confirme que nenhum GPO exibe o triângulo amarelo.
- Documente o estado de replicação: um simples
repadmin /replsum /bydest /bysrc /sort:failagendado em task scheduler pode enviar e‑mail se surgir falha. - Se seu domínio ainda roda FRS, planeje imediatamente a migração para DFSR; além de suportado, oferece compressão, detecção via hash e topologia customizada.
- Use o log analítico do DFSR para caçar gargalos (por padrão escondido; habilite‑o via
wevtutil sl "DFS Replication").
Conclusão
Uma falha de réplica da pasta SYSVOL afeta diretamente a aplicação de políticas e, por consequência, a postura de segurança e configurações de todos os computadores do domínio. Seguindo o roteiro acima você:
- Diagnostica rapidamente se o problema é no AD ou no DFSR/FRS.
- Executa uma sincronização não‑autoritativa segura, sem correr risco de perder GPOs.
- Valida a saúde do domínio com
gpupdateedcdiag.
Manter a replicação íntegra não só elimina erros de Group Policy, mas também prepara o ambiente para upgrades futuros de DCs, migrações de versão do Windows Server e adoção de soluções de hardening baseadas em GPOs. Ao final, você devolve estabilidade à infraestrutura e ganha confiança para escalar o domínio com novos controladores quando necessário.