O que significa migrar SYSVOL de FRS para DFSR?
Migrar SYSVOL de FRS para DFSR altera a forma como os controladores de domínio replicam os ficheiros usados pelas Políticas de Grupo e pelos scripts de início de sessão. A tarefa exige um procedimento que abranja todo o domínio: determinar o estado atual, validar a replicação em cada controlador de domínio e avançar apenas quando as evidências sustentarem a fase seguinte.
Revisão técnica: 4 de outubro de 2026. Os comandos abaixo são exemplos baseados na documentação; não foram executados num domínio de produção.
O File Replication Service (FRS) foi marcado como obsoleto, conforme documentado nas orientações da Microsoft sobre a obsolescência do FRS. O DFS Replication (DFSR) passou a estar disponível para SYSVOL no nível funcional de domínio Windows Server 2008. O guia atual de migração do SYSVOL continua a ser o ponto de partida para o processo suportado.
Trate esta tarefa como um projeto de configuração e disponibilidade. Um sinal de replicação legada não demonstra um ataque, um controlador comprometido ou um GPO com problemas. Da mesma forma, a ausência de resultados não permite aprovar uma alteração irreversível. Defina quais as evidências de que o responsável pelo domínio necessita antes de agendar o trabalho.
Este projeto deve acompanhar o seu planeamento da atualização dos controladores de domínio Windows Server 2016, que aborda os sistemas operativos e os níveis funcionais. Mantenha evidências separadas para a migração do SYSVOL: substituir um DC ou rever o seu sistema operativo não constitui um registo do estado de migração de todos os controladores.
Como funciona: orientação global e convergência local
O emulador PDC mantém a orientação da migração definida através de dfsrmig /setglobalstate. Cada controlador de domínio tem de atingir o seu estado local correspondente. Por isso, um comando que altera a orientação global é o início de uma fase, não uma prova de que todos os controladores a concluíram.
A referência da Microsoft sobre os estados de migração do SYSVOL descreve estas fases estáveis:
| Estado | Comportamento da replicação | Evidências a recolher antes de continuar |
|---|---|---|
| Start — 0 | O FRS replica a pasta SYSVOL ativa. | Inventário completo dos controladores e uma situação inicial saudável. |
| Prepared — 1 | O DFSR replica uma cópia; o FRS continua a disponibilizar o conteúdo SYSVOL ativo. | Todos os estados locais convergiram, a cópia existe e a replicação funciona. |
| Redirected — 2 | A partilha SYSVOL ativa usa a cópia DFSR; o FRS continua a replicar o original. | Todos os estados locais convergiram, os mapeamentos das partilhas e a utilização das políticas foram validados. |
| Eliminated — 3 | O DFSR assegura a replicação do SYSVOL; o FRS deixa de replicar SYSVOL. | Convergência final e verificação operacional conservadas. |
Os estados locais podem ser transitórios durante o trabalho. Mantenha visíveis no registo de migração os controladores que estejam offline, inacessíveis ou ainda em transição. Não os retire da lista de aceitação apenas para que a alteração pareça concluída.
Deteção: criar um registo dos estados antes de alterar qualquer coisa
Ler o estado global no emulador PDC
Execute este comando de consulta no emulador PDC, conforme exigido pela referência do comando dfsrmig:
dfsrmig /getglobalstate
Em seguida, recolha o relatório de convergência de todo o domínio:
dfsrmig /getmigrationstate
O primeiro lê o estado global do domínio. O segundo compara os estados locais com essa orientação e identifica os controladores que ainda não a atingiram. A referência do comando alerta que ler o estado global noutro controlador pode produzir informações inconsistentes devido à latência da replicação do AD.
Interpretação ilustrativa, não uma saída observada: o estado global Prepared com um controlador ainda em Start ou num estado de transição significa que a aprovação de Prepared continua pendente. O estado global Redirected com todos os estados locais correspondentes satisfaz a verificação do estado, mas ainda exige a validação das partilhas e da replicação. O estado global Eliminated sem um relatório de convergência utilizável constitui uma evidência incompleta, não uma conclusão verificada.
Para cada recolha, registe o domínio, a identidade do PDC, o inventário dos controladores, a hora de recolha, o comando e a saída completa. Um controlador inacessível precisa de um responsável e de um plano de resolução. Conserve as recolhas anteriores para que os revisores possam distinguir o progresso de uma alteração do inventário.
Rever a subscrição LDAP e as evidências dos serviços
O provider do etc-collector inspecionado tenta uma pesquisa LDAP de subárvore sob o DN base configurado, com o filtro seguinte, solicitando cn e conservando no máximo um resultado do lado do cliente:
(&(objectClass=nTFRSSubscriber)(name=Domain System Volume (SYSVOL share)))
Este é o filtro literal do provider, apresentado como evidência de código e não como um comando de cliente LDAP pronto a executar. Na revisão do collector inspecionada (42bfefb), os parênteses no valor do nome não estão escapados. Uma verificação local apenas do parser, com a dependência declarada go-ldap v3.4.12, devolveu Filter Compile Error; o pedido de pesquisa não pode ser codificado com este filtro. Não foi executada qualquer consulta LDAP em produção para esta revisão.
Este defeito na recolha deixa o indicador FRS em false no provider inspecionado. Mesmo depois de uma consulta corrigida devolver com sucesso um objeto de subscrição, esse objeto, por si só, não identificaria todos os controladores, não determinaria qual o serviço que disponibiliza atualmente SYSVOL nem excluiria um vestígio da migração.
Em cada DC, registe também, em Services, o estado e a configuração de arranque do serviço File Replication (NTFRS) e do serviço DFS Replication (DFSR). Correlacione essas observações com o estado de migração e o mapeamento real das partilhas. Um serviço em execução, por si só, não demonstra uma replicação bem-sucedida do SYSVOL.
Use uma pequena matriz de evidências em vez de um único visto verde:
| Evidência | A que pergunta responde? | O que não pode demonstrar isoladamente? |
|---|---|---|
| Objeto de subscrição LDAP | Foi devolvido um objeto de subscrição FRS? | Utilização em execução, inventário completo ou saúde da replicação. |
| Estado global | Qual a fase de migração definida? | Conclusão em todos os DCs. |
| Relatório de convergência local | Os controladores atingiram essa fase? | Processamento de Políticas de Grupo de ponta a ponta. |
| Observações dos serviços | Que serviços estão em execução e configurados? | Conteúdo SYSVOL correto em todas as réplicas. |
| Verificações das partilhas e da replicação | A pasta esperada está a ser disponibilizada e replicada? | Remoção de segredos guardados em SYSVOL. |
Distinga as falhas de recolha dos resultados negativos no registo operacional. Este artigo não fornece uma consulta de ataque nem um Windows Event ID; a decisão baseia-se aqui em evidências da migração e da replicação.
Correção: avançar por etapas de aprovação documentadas (Remediation)
Passo 1 — Inventário, pré-requisitos e preparação para a recuperação
Identifique o responsável pelo domínio e o operador da alteração. Inventarie todos os DCs graváveis e RODCs, incluindo os sites remotos e os sistemas temporariamente offline. Registe o emulador PDC, o nível funcional, a compatibilidade do sistema operativo e a localização do SYSVOL. Confirme os pré-requisitos face ao guia atual de migração e às versões efetivamente instaladas.
Antes de começar, o procedimento da Microsoft para o estado Prepared exige verificações da saúde da replicação, espaço suficiente para a cópia do SYSVOL, o serviço DFS Replication em execução com arranque automático e cópias de segurança do estado do sistema. Recomenda também evitar alterações aos GPOs e aos scripts de início de sessão até todos os controladores atingirem Redirected.
Documente as localizações das cópias de segurança e a responsabilidade pela recuperação. Acorde como uma verificação falhada suspende a alteração, quem a diagnostica e que evidências permitem retomar o trabalho. Não considere a existência de uma tarefa de cópia de segurança como um teste de recuperação bem-sucedido.
O procedimento inclui estes exemplos de consulta separados:
net share
repadmin /ReplSum
Execute net share em cada DC e inspecione os mapeamentos de SYSVOL e NETLOGON. Reveja a replicação do AD e a replicação do SYSVOL de forma independente. Resolva as falhas existentes antes de iniciar a migração; uma transição de estado não deve tornar-se numa tentativa de reparação de um problema de replicação sem explicação.
Passo 2 — Aprovação de Prepared
Exemplo de alteração de estado: usar apenas depois das verificações iniciais e da aprovação da alteração. No emulador PDC:
dfsrmig /setglobalstate 1
Recolha novos relatórios do estado global e do estado de migração. Não avance até todos os controladores atingirem Prepared. Verifique a cópia DFSR e a sua replicação conforme descrito no procedimento de Prepared.
Mantenha uma entrada explícita de aceitação por controlador. Registe as exceções restantes com a pessoa responsável, não como uma nota informal fora do registo da alteração. Se for introduzido um novo RODC durante a migração, consulte o tratamento documentado dos RODCs antes de continuar; não acrescente comandos genéricos de criação ou eliminação de objetos a um procedimento de rotina.
Passo 3 — Aprovação de Redirected
Exemplo de alteração de estado: usar apenas depois da convergência de Prepared e da validação da saúde. No emulador PDC:
dfsrmig /setglobalstate 2
O procedimento para o estado Redirected exige estados locais consistentes antes de Eliminated. Valide os mapeamentos de SYSVOL e NETLOGON em cada DC e a saúde do DFSR; conserve as evidências da saúde do FRS enquanto a reversão continuar a ser relevante.
Acrescente uma verificação de aceitação operacional: os clientes representativos nos sites afetados têm de obter as políticas e os scripts esperados. Registe os clientes escolhidos, as políticas, as horas de recolha e os resultados. Esta é uma tarefa de validação proposta, não uma afirmação de que o processamento dos clientes foi testado para este artigo.
Passo 4 — Aprovar Eliminated separadamente
O procedimento para o estado Eliminated exige uma verificação bem-sucedida de Redirected e estados consistentes em todos os controladores. Reveja a replicação do AD, conserve cópias de segurança nos estados estáveis e confirme que o responsável pelo domínio aceita a perda da possibilidade de reversão da migração.
Exemplo de alteração de estado irreversível: não constitui uma recomendação imediata para um domínio desconhecido. No emulador PDC, apenas depois da aprovação desta etapa:
dfsrmig /setglobalstate 3
Recolha novos relatórios dos estados global e locais. Verifique novamente os mapeamentos das partilhas SYSVOL e NETLOGON, a replicação DFSR e o processamento das políticas. Reveja qualquer utilização restante do serviço FRS antes de o retirar: o procedimento da Microsoft condiciona a paragem e a desativação do FRS à existência de outras finalidades além de SYSVOL.
Registe a decisão final e as evidências, incluindo as anomalias por resolver. Não transforme a limpeza de um objeto LDAP num substituto da verificação em execução.
Como a EtcSec deteta esta situação
A verificação DFSR_NOT_CONFIGURED da EtcSec está implementada em ad/network/dfsr.go do etc-collector. O seu Detect() avalia as informações do domínio recolhidas:
| Entrada recolhida | Resultado |
|---|---|
UsingNTFRSForSYSVOL = true e FunctionalLevelInt >= 3 | Count 1, gravidade Low. |
| Indicador FRS em false ou nível funcional inferior a 3 | Count 0. |
DomainInfo ausente | Os valores predefinidos mantêm-se false e zero; Count 0. |
O código associa o nível 3 ao Windows Server 2008. Count é um sinal ao nível do domínio, não o número de DCs afetados. O provider define o indicador FRS apenas quando a sua pesquisa LDAP limitada é bem-sucedida e devolve um objeto. Um erro ou um resultado vazio deixa o indicador em false sem um indicador separado de erro de recolha neste sinal. Na revisão inspecionada, o filtro malformado descrito acima segue esse caminho de erro: este caminho de recolha deixa UsingNTFRSForSYSVOL em false, pelo que Detect() devolve Count 0 mesmo que o domínio use efetivamente FRS.
Um objeto de subscrição residual pode permanecer depois da migração. Por isso, um resultado positivo é um motivo para reconciliar LDAP com dfsrmig, as observações dos serviços e as evidências das partilhas. Não é uma prova do serviço de replicação efetivamente utilizado nem de um ataque.
O detetor não lê os estados globais ou locais de dfsrmig, a saúde do DFSR, a convergência da replicação ou os resultados das políticas nos clientes. Count 0 não prova que o DFSR esteja saudável nem que a migração esteja concluída. O texto da sua recomendação é uma orientação; não significa que um comando de verificação da saúde ou uma migração tenha sido executado.
Encerrar a alteração com a revisão do conteúdo
Replicar SYSVOL através do DFSR não remove os segredos dos seus ficheiros. Mantenha a revisão dos segredos cPassword do GPO SYSVOL como uma tarefa de conteúdo separada, com a gestão das credenciais e a limpeza sob responsabilidade independente da alteração de replicação.
Conserve um pacote final de evidências com o inventário, as cópias de segurança, o estado inicial, as verificações de convergência e de saúde de cada etapa, a decisão de Eliminated, se tomada, e a verificação final das partilhas e das políticas. Reconcilie o resultado do collector com esse pacote e documente quaisquer evidências LDAP desatualizadas ou limitações da recolha.
A decisão de conclusão deve poder ser revista por alguém que não tenha executado os comandos. Se um controlador, uma observação de serviço ou uma verificação de políticas continuar por resolver, indique explicitamente essa limitação e mantenha aberta a ação operacional correspondente.
Explore as paginas de identidade que sustentam este tema
