Por que migrar o Active Directory?

A migração de um domínio Active Directory é uma das operações mais sensíveis em qualquer infraestrutura Windows corporativa. Empresas chegam a esse ponto por motivos diversos: consolidação após fusões e aquisições, modernização de domínios legados rodando em Windows Server 2008/2012, abandono de namespaces antigos (empresa.local) em favor de domínios alinhados ao DNS público, separação de unidades de negócio, ou simplesmente a necessidade de sair de uma floresta mal projetada que acumulou anos de débito técnico.

Independente do motivo, a regra é universal: a migração precisa ser transparente para o usuário final. Ninguém quer abrir um chamado às 8h de segunda-feira porque o colaborador esqueceu — ou nunca soube — a nova senha. É exatamente aí que entram o Active Directory Migration Tool (ADMT) e o Password Export Server (PES).

Este guia foi escrito a partir de migrações reais executadas pela equipe da Toda Solução em ambientes de software houses, ISPs e clientes de outsourcing de TI. Cobre desde o planejamento até a validação pós-migração, com os pontos onde a maioria dos administradores tropeça.

O que é o ADMT e por que ele ainda é relevante em 2026

O ADMT é a ferramenta oficial da Microsoft para migrar objetos entre domínios e florestas Active Directory: usuários, grupos, computadores, contas de serviço e suas relações de permissão. Apesar de a Microsoft não ter lançado uma nova versão major há anos (a versão 3.2 segue sendo a referência), o ADMT continua sendo a ferramenta mais robusta e gratuita para esse cenário, funcionando inclusive em domínios baseados em Windows Server 2019 e 2022.

A ferramenta executa três operações fundamentais:

1. Migração de objetos entre domínios de origem e destino, preservando atributos críticos.
2. Tradução de segurança (security translation), reescrevendo ACLs em servidores membro, file servers e estações para que o novo SID tenha as mesmas permissões do antigo.
3. Histórico de SID (SID History), que mantém o SID antigo associado ao objeto migrado, garantindo que recursos ainda não traduzidos continuem acessíveis durante a fase de coexistência.

O complemento indispensável é o Password Export Server (PES), um serviço instalado em um Domain Controller do domínio de origem que permite exportar os hashes de senha para o domínio de destino de forma criptografada. Sem o PES, a migração de senhas é impossível e cada usuário precisaria redefinir manualmente sua credencial — inviável em qualquer ambiente acima de 50 usuários.

Arquitetura recomendada para a migração

Antes de qualquer comando, vale desenhar a topologia. Em uma migração típica entre dois domínios (legado.local → empresa.com.br, por exemplo), você terá:

• Domain Controller de origem (DC-OLD): rodando o domínio legado, com o serviço PES instalado em um DC dedicado preferencialmente, não no PDC Emulator.
• Domain Controller de destino (DC-NEW): já promovido, com nível funcional adequado (recomenda-se Windows Server 2016 ou superior).
• Servidor ADMT: uma VM Windows Server 2019/2022 ingressada no domínio de destino. O ADMT roda no destino, não na origem — esse é um erro comum.
• Trust bidirecional entre os dois domínios, com SID filtering desabilitado durante a janela de migração (e reabilitado depois).
• Resolução DNS cruzada funcionando perfeitamente entre as duas florestas.

Em ambientes virtualizados que hospedamos em VMware HCI ou Proxmox/Virtualizor, recomendamos colocar o servidor ADMT em uma VM dedicada com pelo menos 4 vCPUs, 8 GB de RAM e disco SSD — a base de dados SQL Express utilizada pelo ADMT cresce rapidamente em ambientes com milhares de objetos.

Pré-requisitos que ninguém pode pular

A maioria das migrações falha não pela ferramenta, mas pelos pré-requisitos. Antes de instalar o ADMT, verifique e documente:

Do lado da rede e do DNS: os DCs de origem e destino precisam se enxergar mutuamente nas portas 53 (DNS), 88 (Kerberos), 135 (RPC), 389/636 (LDAP/LDAPS), 445 (SMB), 464 (Kerberos password), 3268/3269 (Global Catalog) e a faixa dinâmica RPC (49152–65535 em sistemas modernos). Se houver firewall entre os sites, libere essas portas explicitamente — não confie em "tá tudo liberado".

Do lado dos domínios: crie o trust bidirecional do tipo Forest Trust (se forem florestas distintas) ou External Trust. Valide com nltest /trusted_domains em ambos os lados. Confirme que os usuários administrativos usados na migração têm permissões em ambos os domínios — o ADMT pede credenciais separadas para origem e destino.

Do lado da auditoria: habilite a auditoria de gerenciamento de contas em ambos os domínios via GPO. Sem isso, o PES não funciona. As políticas necessárias são Audit account management (Success/Failure) tanto na Default Domain Controllers Policy de origem quanto na de destino. Após editar, force gpupdate /force em todos os DCs e aguarde a replicação.

Do lado do registro: no DC de origem onde o PES será instalado, é necessário criar a chave de criptografia que será usada pelo PES. Isso é feito antes da instalação, com o comando executado no servidor ADMT:

admt key /option:create /sourcedomain:legado.local /keyfile:C:\Migration\peskey.pes /keypassword:*

A flag /keypassword:* solicitará a senha interativamente, o que é mais seguro do que passá-la no histórico do PowerShell. Esse arquivo .pes precisa ser copiado para o DC de origem onde o PES será instalado — guarde-o em um local seguro e apague depois da migração.

Instalação do ADMT no domínio de destino

Com os pré-requisitos validados, a instalação do ADMT 3.2 no Windows Server 2019/2022 exige uma observação importante: o instalador oficial reclama de pré-requisitos do SQL. A solução é instalar primeiro o SQL Server Express (recomendamos 2017 ou 2019) com a instância nomeada ADMT, e depois apontar o ADMT para essa instância durante a instalação.

# No servidor ADMT, após instalar SQL Express com instância ADMT
.\admtsetup32.exe

Durante o assistente, escolha a instância LOCALHOST\ADMT (ou o nome que você definiu). O instalador criará automaticamente o banco ADMT com as tabelas necessárias. A instalação leva poucos minutos.

Após instalar, abra o console ADMT (Active Directory Migration Tool no menu Iniciar) e valide que ele consegue listar os domínios de origem e destino. Se aparecer erro de RPC, revise as portas de firewall.

Instalação do Password Export Server no DC de origem

O PES precisa ser instalado em um Domain Controller do domínio de origem. Em ambientes com múltiplos DCs, escolha um que não seja o PDC Emulator e que esteja em um site bem conectado ao DC de destino.

Os passos são:

1. Copiar o arquivo peskey.pes (gerado anteriormente) para o DC de origem, em um caminho local como C:\Migration\.
2. Baixar e executar o instalador do PES (pwdmig.msi) compatível com a versão do ADMT — atenção: usar PES x64 em DC x64.
3. Durante a instalação, apontar para o arquivo .pes e fornecer a senha definida na criação da chave.
4. Definir uma conta de serviço para o PES. Recomendamos uma conta dedicada (não use a Administrator) com a permissão "Log on as a service" e membro de Domain Admins do domínio de origem.
5. Não iniciar o serviço ainda. Reinicie o DC após a instalação.

Após o reboot, abra services.msc, localize o serviço Password Export Server Service, ajuste o tipo de inicialização para Manual e o inicie apenas quando for executar a migração de senhas. Deixar o PES rodando 24/7 é desnecessário e amplia a superfície de ataque.

Há um ajuste de registro frequentemente esquecido: no DC de destino, você precisa permitir que o PES envie hashes. Crie o valor DWORD AllowPasswordExport com dado 1 em:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa

Reinicie o DC de destino após o ajuste. Sem essa chave, o PES inicia mas a migração de senhas falha silenciosamente — os usuários são criados, mas com senha vazia ou aleatória.

Ordem de migração: como evitar o pesadelo das permissões

Migrar AD não é só "clicar em next". A ordem dos objetos importa muito:

1. Grupos primeiro (sem membros). Migre a estrutura de grupos para que os SIDs já existam no destino antes da migração de usuários.
2. Contas de serviço. Identifique todas as contas usadas por serviços Windows, agendadores, IIS, SQL Server e bancos de dados. Migre-as separadamente e atualize cada serviço para usar a conta no novo domínio — esse é o ponto que mais derruba ambientes.
3. Usuários com senhas (via PES). Aqui o PES entra em ação. Marque a opção "Migrate passwords" no assistente e selecione o servidor PES configurado.
4. Membros dos grupos. Após migrar usuários, repita a migração de grupos com a opção "Update existing objects" para popular os membros.
5. Computadores. Por último, migre as estações e servidores membro. O ADMT aciona um agente remoto que reingressa a máquina no novo domínio e reinicia automaticamente. Faça isso fora do horário comercial.

Para cada etapa, sempre rode primeiro em modo Test (Test the migration settings and migrate later). O ADMT simula a operação completa e gera um log com tudo que aconteceria. Leia esse log com calma antes de rodar a migração real. Erros comuns que aparecem aqui: nomes de usuário duplicados, atributos UPN conflitantes, SIDs já existentes no destino.

Tradução de segurança nos servidores membro

Migrar o usuário não traduz automaticamente as ACLs dos arquivos no file server, das chaves de registro nos servidores de aplicação, ou das permissões em compartilhamentos. Por isso o ADMT oferece o assistente Security Translation Wizard.

Existem duas estratégias:

• Add (adicionar): mantém o SID antigo na ACL e adiciona o novo. Mais seguro, permite rollback. Use durante a coexistência.
• Replace (substituir): remove o SID antigo e coloca apenas o novo. Use quando a migração estiver finalizada e validada.

A ordem recomendada é: rodar Security Translation em modo Add logo após a migração de usuários, deixar coexistir por 2 a 4 semanas, e só então rodar em modo Replace após confirmar que tudo funciona. Em file servers com milhões de arquivos, o Security Translation pode levar horas — planeje a janela.

Para servidores Windows que hospedamos para clientes, executamos essa etapa via agente do ADMT instalado remotamente, monitorando o progresso pelo log central. É uma operação intensiva em I/O de disco; em servidores com discos mecânicos antigos, considere fazer em lotes.

Validação pós-migração

Migração concluída não significa migração bem-sucedida. Antes de declarar vitória, valide:

• Logon de usuários: teste com pelo menos 10 usuários reais de áreas diferentes (financeiro, comercial, TI, operacional). Não use só sua conta de admin.
• Acesso a compartilhamentos: abra mapeamentos de rede, OneDrive corporativo, pastas departamentais. Confirme que as permissões foram traduzidas.
• Aplicações integradas: ERPs, sistemas legados em ASP/PHP, terminal services, RDS, qualquer coisa que use autenticação integrada. Esses sistemas frequentemente cacheiam SIDs e podem precisar de reconfiguração.
• GPOs: as Group Policies não migram com o ADMT por padrão. Use o GPMC para fazer backup e import das GPOs entre domínios, e ajuste os filtros de segurança que apontam para SIDs antigos.
• Replicação: rode repadmin /replsummary e dcdiag /v em ambos os domínios para garantir que nada quebrou no processo.
• Auditoria: revise os Event Logs dos DCs procurando erros 4769 (Kerberos) e 4625 (logon falhado) — picos aqui indicam que algum sistema ainda tenta autenticar contra o domínio antigo.

Decommissioning do domínio antigo

Resista à tentação de desligar o domínio legado no dia seguinte. A regra prática é manter o domínio antigo operacional por no mínimo 90 dias após a migração, com o trust ainda ativo e o SID History preservado nas contas migradas. Esse período cobre:

• Sistemas que rodam apenas mensalmente (faturamento, fechamento contábil).
• Backups antigos que precisam ser restaurados ocasionalmente.
• Aplicações esquecidas que ninguém lembrou de listar no inventário.

Após esse período, execute a remoção do SID History (Remove SID History no ADMT), quebre o trust, e só então desative os DCs do domínio antigo. Faça dcpromo reverso ou Uninstall-ADDSDomainController em vez de simplesmente desligar — DCs órfãos no AD são uma fonte recorrente de problemas anos depois.

Quando faz sentido contratar suporte especializado

Migrações de AD são projetos de risco controlado, mas o custo de errar é alto: usuários impedidos de trabalhar, sistemas críticos inacessíveis, dados de auditoria comprometidos. Para ambientes acima de 200 usuários, com múltiplos sites, file servers extensos ou aplicações legadas que dependem de autenticação Windows integrada, vale envolver um time que já passou por esse processo dezenas de vezes.

A Toda Solução oferece consultoria e execução de migrações de Active Directory para clientes corporativos, incluindo o planejamento da arquitetura, configuração do trust e PES, execução em janela monitorada, tradução de segurança em file servers e suporte durante o período de coexistência. Em conjunto com nossos serviços de Windows VPS e servidores dedicados, é possível inclusive migrar a infraestrutura completa para nosso datacenter Tier III em Imbé/RS durante a operação, modernizando o ambiente de uma só vez.

Se sua empresa está planejando uma migração de AD ou consolidação de florestas, entre em contato com nosso time pelo painel.todasolucao.com.br ou pelos canais comerciais — montamos um plano de migração específico para o seu cenário antes de qualquer execução.

---

FAQ rápido

O ADMT funciona com Windows Server 2022? Sim, o ADMT 3.2 funciona normalmente em Windows Server 2019 e 2022 como servidor ADMT, e migra objetos para domínios com nível funcional 2016 e 2019.

Preciso licenciar o ADMT ou o PES? Não. Ambas as ferramentas são gratuitas e fornecidas pela Microsoft. Você só licencia o Windows Server e o SQL Express usado.

Posso migrar Azure AD / Entra ID com ADMT? Não. O ADMT é exclusivo para Active Directory on-premises. Para migrações envolvendo Entra ID, use ferramentas como Azure AD Connect, Microsoft Identity Manager ou soluções de terceiros como Quest Migration Manager.

Quanto tempo dura uma migração típica? Para 500 usuários, 50 servidores e 1 file server de 5 TB, planeje 3 a 4 semanas de projeto: 1 semana de planejamento e pré-requisitos, 1 fim de semana para a janela principal de migração, e 2 semanas de coexistência e ajustes finais.

Existe alternativa ao ADMT? Sim, há ferramentas comerciais como Quest Migration Manager for AD e Binary Tree Active Directory Pro que oferecem mais automação e melhor experiência em projetos grandes. Para a maioria dos cenários até 1.000 usuários, o ADMT cumpre o papel sem custo adicional.