Faz tempo que tou pensando em escrever um material bacana sobre ADMT, migração e consolidação de domínios, e pretendo fazer isso aos poucos, aqui pelo nosso PortalTec…

Pretendo focar esse material em migrações de usuários, grupos, computadores e file servers… Nada de muito avançado, pois tem muita coisa em “voga” quando se fala de ADMT, e de migrações…

Antes de qualquer coisa, é interessante analisarmos muito bem o ambiente no qual queremos utilizar o ADMT, e “matar” um monte de broncas antes de começar, portanto é imprescindível olharmos para alguns pontos:

1 – Afinal, pra que eu uso o ADMT, migrar, consolidar, fazer café?
Pois então… O nome que tu vai dar pro que tu tá fazendo, não interessa muito no final das contas, mas sim o que está em volta (em termos teóricos) do ambiente que tu tens.
O Active Directory Migration Tool, que tem versões acompanhando os servidores desde Windows 2000 (atualmente na versão 3.2, para o Windows Server 2008 R2), serve basicamente para movimentação de objetos do Active Directory entre domínios que tenham uma relação de confiança estabelecida entre si.

Pra que eu faria isso?
Que tal:
- Tua empresa comprou outra empresa, e devido a política definida pela diretoria ou gerência de TI, os objetos do domínio da empresa comprada devem ser movidos para o domínio da tua empresa, centralizando o gerenciamento.
- Tu tem filiais estabelecidas e com domínios diferentes (tu deve te perguntar pra que isso, mas tem gente que faz…) e quer organizar a casa, e também centralizar o gerenciamento do Active Directory em um único Domínio.
- De outra forma, uma grande corporação, com várias empresas, decide vender uma das suas empresas e precisa desmembrar esta (e seus objetos) para um domínio externo, pra que não seja necessário fazer uma relação de confiança de TODO o domínio…

2 – O que eu preciso, pra utilizar o ADMT?
Bueno, pra que o ADMT rode numa boa, tu tem de considerar algumas questões muito importantes, e também muito simples.

– Resolução de Nomes funcionando adequadamente:
Essa, com certeza é a principal questão quando se utiliza o ADMT. É o principal requisito, por exemplo pra tu estabelecer uma relação de confiança entre os Domínios.
Tu podes fazer isso de duas formas, ou criando um Encaminhamento Condicional (Conditional Forwarding) entre os DNSs, ou fazendo da Zona Principal (normalmente, integrada ao Active Directory), uma Zona Secundária no outro domínio.
A questão é: TESTE MUITO a resolução de nomes pra não ficar vendido!!!

– Níveis Funcionais:
Para o ADMT 3.0 não é exigido nenhum nível funcional específico, porém este só funciona com Controladores de domínio 2000 ou 2003. Já o 3.2, exige que o Nível Funcional seja, no mínimo, 2003 Nativo.
Pra mais detalhes sobre estes requerimentos, dê uma olhada em:

http://technet.microsoft.com/en-us/library/active-directory-migration-tool-versions-and-supported-environments%28WS.10%29.aspx

– Relação de confiança entre os domínios de origem e destino
Essa, como se percebe, é a chave pro funcionamento do ADMT. Através da relação de confiança, pode-se interpretar a existência de objetos entre os domínios, e copiá-los, mergí-los, etc…
De fato, neste caso, a relação de confiança mais recomendada é a bi-direcional, porém pode-se em casos mais isolados, utilizar uni-direcional, desde que o DESTINO confie nos objetos da ORIGEM.

– Firewall sempre é um problema
Amigos… Uma das dores de cabeça que mais se encontra nestes tipos de atividade/projeto, são liberações de firewall entre os sites dos domínios.
Pra utiliação do ADMT, tu precisa, de pelo menos, acesso RPC entre os Controladores de domínio, acesso via LDAP, ICMP (o mais conhecido como PING, entre outros…) e DNS. Facil né?
Pois pense agora, que pra uma migração eficiente de Desktops, tu tem que ter acesso RPC a estes, juntando a isto, o serviço de registro remoto que precisa ser acessado pelo agente do ADMT para desktops, etc etc etc… Portanto, tente não ser muito “Xiita” com as liberações de firewall num caso destes. tanto o Firewall entre os sites, quanto o firewall pessoal dos desktops.
De preferência pense em desabilitar (e, ok, habilitar novamente depois…) o firewall pessoal do Windows, e as features de prevenção de ataques baseadas em conexão dos antivírus e suites de segurança em geral. Isso vai diminuir em muito tuas chances de erro.

3 – Tudo isso tá prontinho, e agora?

Agora tá na hora de tu parar e pensar DENOVO.
Pensar no que?
Na tua estratégia de migração.

Cada estrutura de Active Directory é muito peculiar (Best Practices, oi?!?!?), e por conta disso, não há uma receita de bolo infalível pra migração.
Posso dizer pra vocês, que sempre se divide em duas opções: Migração Completa, ou Migração em Fases.

A migração completa, consistem em transferir todos os objetos, sejam eles usuários, grupos, desktops, contatos, servidores, em uma única janela de manutenção (fim de semana, ou feriado prolongado).
Como vocês podem perceber, este tipo de migração só pode ser feito quando se tem um parque de desktops não muito grande. Isto porque, o que gasta mais tempo, é a migração de Desktops, e troubleshooting quando esta dá errado (e vai dar viu… eheheh).
Por experiência própria, acredito que pode-se chegar a um máximo de 200 Desktops pra considerar uma Migração Completa, ou seja, de uma vez só.
Quando o número de desktops ultrapassa a este, e tu tem várias filiais de uma empresa a serem migradas, opta-se por uma Migração em Fases.
Apesar de mais demorada, é a que mais traz segurança ao ambiente, e também a que melhor deve ser planejada.

Analisando estes dois pontos, vou dar duas dicas pra vocês:

Migração Completa:
Migre primeiro os usuários, selecionando o botãozinho mágico de “Migrar Grupos aos quais o usuário é membro”, e depois, preocupe-se com os desktops. Se sobrarem grupos que não foram migrados, certamente estes não estão sendo utilizados.

Migração em Fases:
Migre TODOS os grupos. Após vá migrando usuários e desktops conforme sua programação (por sites, por andares, por regionais, por setores…).

4 – SID History, o que é isto?

Uma das features mais legais do ADMT, pessoalmente falando, é o SID History.
Esse cara permite que tu, falando de forma bem simples e anti-técnica, coloque o SID original do objeto que tu migrou, “embaixo” do novo SID criado para ele quando transferido de domínio.
Pra que serve isso? Simplesmente pra manter tuas permissões de acesso originais no outro domínio, e ajudar na migração de File Servers, aplicações e tudo que envolva o objeto e seu SID.
O SID History é a “feature dos campeões” em migrações de larga escala, porém, grande ou pequena, simplesmente use a feature. Te garante a segurança que tu precisa e te facilita em qualquer RollBack.
O SID History depende de algumas modificações que são feitas, preferencialmente através do comando NETDOM, que veremos no decorrer dos labs que lhes apresentarei.

5 – Migração de Passwords, é possível?

É, é sim. E tu faz isso através do Password Export Service, mais conhecido como PES (e tu achou que só tinha um PES no mundo eletrônico, e ainda por cima, era futebol neh? eheheh).
O Password Export Service é um serviço, que é instalado no domínio de origem, e comunica-se com o ADMT no destino, através de uma senha definida na instalação, e faz esse trabalho de senhas de usuário pra ti.
Outras opções ao invés da migração de Passwords, são a criação de uma senha padrão para todos usuarios migrados, ou criação de senha randômica, feita pelo ADMT.

6 – Agora sim! Tudo pronto! Sei de tudo! Falta algo?

Sim, falta o mais importante.
O BACKUP!!!
Faça backup dos controladores de domínio, servidores de arquivos, reze um terço (ou a oração mais adequada a tua religião ou massa geradorade seres preferencial…) e vamos em frente!!!

Portanto pessoal, embora tenha escrito muita coisa, e mostrado nenhuma tela de LAB, aqui tem tudo (ou quase tudo) que é preciso pra vocês pensarem e começarem a trabalhar com o ADMT de uma forma bacana e segura.

Fiz uns labs bem legais, e vou reproduzindo aqui pra vocês. Dá um trabalho tirar prints e escrever abaixo deles, portanto leva um tempinho

Espero que tenham gostado da introdução, e comentem o que pode ser melhorado ou corrigido.

Abraços!
Thiago Tietze

Acredito que muita gente não utilize esse tipo de procedimento, mais pela “dificuldade” de colocar o endereço completo das OUs (distinguished name, ou DN), do que a dificuldade de utilização dos comandos em si. Portanto, seguem algumas dicas:

Requisitos para utilização:

Os dois comandos estão disponíveis desde o Windows 2003 Server, ficando disponíveis na instalação das ferramentas administrativas de Active Directory.
Estes comandos podem ser utilizados também no Windows 2000 (copiando os executáveis para o sistema operacional…) porém necessitam ao menos o Service pack 3 instalado para que todos os parâmetros sejam correspondentes. O parâmetro -inactive, por exemplo, não pode ser utilizado em Service Packs anteriores.
Tendo cumprido com estes requisitos, em um Controlador de Domínio, abra o prompt de comando e rode quaisquer dos comandos.

Utilizando dsquery e dsget juntos:

Ambos os comandos se utilizam do tipo de objeto, para colher os dados, portanto temos a sintaxe:

dsquery ou dsget <computer ou user ou group ou contact…> -parâmetros

O dsquery é utilizado para trazer a lista de objetos aos quais se quer colher informações, em um formato que pode ser utilizado pelo dsget, para que as informações sejam mostradas.
Por exemplo:

Se rodarmos o comando:

dsquery computer “ou=Domain Controllers,dc=portaltecnologia,dc=net”

A saída no prompt de comando, será a lista de computadores dentro da OU “Domain Controllers”, mostrada em Distinguished Names conforme abaixo:

“CN=DC01,OU=Domain Controllers, dc=portaltecnologia,dc=net”
“CN=DC02,OU=Domain Controllers, dc=portaltecnologia,dc=net”
“CN=DC03,OU=Domain Controllers, dc=portaltecnologia,dc=net”

O dsget, concatenado ao dsquery “aproveita” cada linha saída e a utiliza para pegar informações do objeto representado. Portanto, se rodarmos:

dsquery computer “ou=Domain Controllers,dc=portaltecnologia,dc=net” | dsget computer –samid -disabled

Temos a saída correspondente a cada objeto, apresentando seu sAMAccountId e se este objeto está desabilitado ou não:

samid        disabled
DC01$        no
DC02$        no
DC03$        no

Portanto, as possibilidades são muito grandes.

Exemplos de Utilização:

*    Relatórios de usuários e máquinas desabilitadas.
*    Relatório de usuários que necessitam trocar senha.
*    Report de SID de objetos.
*    Relatórios com múltiplos parâmetros.
*    Relatório de máquinas inativas na rede, em semanas, utilizando o parâmetro “-inactive”.

Estes são exemplos simples e de utilização muito prática com o dsquery/dsget, porém existem outros parâmetros e objetos que podem ser pesquisados e listados.

A melhor fonte de informações sobre estes comandos é justamente o “manual” do Technet, com todos os parâmetros e funções fornecidas:
http://technet.microsoft.com/en-us/library/cc755162%28WS.10%29.aspx
http://technet.microsoft.com/en-us/library/cc732952%28WS.10%29.aspx

Façam bom proveito, e assim que tiver mais comandos úteis, compartilho por aqui!!!

Abraços!

Thiago Tietze

Quando você cria um usuário ele é criado na CN=Users. Você pode mudar para uma OU onde você pode atribuir GPOs com suas políticas da empresa.

Requisitos:

• nível funcional do domínio no mínimo windows 2003
• domain ou enterprise admin
• PDC emulator online e acessível
• OUs devem ser criadas antes de rodar o comando

O comando está localizado em: C:\Windows\System32.

Fontes:
http://technet.microsoft.com/en-us/library/cc771655%28WS.10%29.aspx
http://technet.microsoft.com/en-us/library/cc770619%28WS.10%29.aspx

[]s
Tiago Souza

Para ver o vídeo acessem o link abaixo:

http://www.msit.com.br/PublicacaoDetalhes.aspx?id=4&type=v

[]s
Tiago Souza

http://blogs.technet.com/b/heyscriptingguy/archive/2010/07/20/hey-scripting-guy-how-can-i-use-windows-powershell-to-identify-inactive-user-accounts-in-active-directory-domain-services.aspx

Ele mostra alguns comandos para trabalhar com o módulo Active Directory no Power Shell. Você pode usa-lo para pesquisar contas inativas no AD. É muito útil na manutenção diária do seu domínio, fiz uma pesquisa rápida usando:

PS C:\Users\tiago.souza> Get-ADUser -Filter * -Properties “LastLogonDate” |
>> sort-object -property lastlogondate -descending |
>> Format-Table -property name, lastlogondate -AutoSize 

Nessa brincadeira encontrei diversos usuários que já efetuavam logon há um bom tempo. Você pode fazer algo semelhante usando o mmc do Active Directory, em Saved Queries, mas esse comando lhe permite variar algumas opções, visite o link para saber mais.

[]s
Tiago Souza

• Active Directory in Hyper-V environments, Part 1
• Active Directory in Hyper-V environments, Part 2
• Active Directory in Hyper-V environments, Part 3

[]s
Tiago Souza

Uma leitura legal pra quem pretende virtualizar controladores de domínio no Hyper-V:

• http://technet.microsoft.com/pt-br/library/virtual_active_directory_domain_controller_virtualization_hyperv(WS.10).aspx

Não tem muito segredo, mas sim algumas observações interessantes no documento. Pra não ter dor de cabeça futuramente vale a pena seguir as boas práticas do link.

[]s

Tiago Souza

C:\WINDOWS\system32>schupgr.exe
Opened Connection to SERVER
SSPI Bind succeeded
Current Schema Version is 47
Upgrading schema to version 47
The schema has already been upgraded. Rerun setup to upgrade this DC.

No exemplo acima é 47, Windows Server 2008 R2.

Veja as versões x sistema operacionais.

13 – Windows 2000
30 – Windows 2003 e 2003 SP1
31 – Windows 2003 R2
44 – Windows 2008
47 – Windows 2008 R2

Há mais 2 maneiras de descobrir a versão do schema, eu particularmente acho essa mais rápida e fácil, para saber as outras visite o seguinte blog da Microsoft onde o colega Gilson Banin descreve as demais formas: http://blogs.technet.com/technetbr/archive/2008/09/16/tr-s-03-maneiras-de-identificar-qual-vers-o-do-active-directory-pela-vers-o-do-schema.aspx.

[]s
Tiago Souza

Ao tentar rodar o ADPREP /FORESTPREP de um CD Windows Server 2008 R2 x64, a seguinte mensagem poderá aparecer.

C:\support\adprep>adprep /forestprep

The image file C:\support\adprep\adprep.exe is valid, but is for a machine type other than the current machine

Isso acontece porque você está rodando a versão x64 em um DC 2003 x86, você deve localizar a versão 32 bits do ADPREP e rodar novamente.

C:\support\adprep>adprep32.exe /forestprep

 ADPREP WARNING:

 Before running adprep, all Windows 2000 Active Directory Domain Controllers in the forest should be upgraded to Windows 2000 Service Pack 4 (SP4) or later.

 [User Action]

If ALL your existing Windows 2000 Active Directory Domain Controllers meet this requirement, type C and then press ENTER to continue. Otherwise, type any other key and press ENTER to quit.

c

Opened Connection to SRVDC01

SSPI Bind succeeded

Current Schema Version is 30

Upgrading schema to version 47

Connecting to “SRVDC01″

Logging in as current user using SSPI

Importing directory from file “C:\WINDOWS\system32\sch31.ldf”

Loading entries……………………………………………………….

Agora é só aguardar carregar tudo e pronto.

[]s
Tiago Souza

É bem interessante, o formato é parecido com aqueles resumos de cursinho, faculdades, etc. Ele aborda as principais novidades de Active Directory no Windows Server 2008 R2. Ele pode servir de guia de estudos para o exame: 70-640: TS: Configuring Windows Server 2008 Active Directory.

Para fazer o download clique no link abaixo:

http://www.portaltecnologia.net/downloads/windows2008r2/active_directory_-_windows_server_2008_r2.pdf

Ou acesse o site do Daniel Donda, na área de downloads, onde tem mais materiais interessantes:

http://www.mcsesolution.com/component/option,com_phocadownload/Itemid,66/view,sections/

Obrigado Daniel.

[]s
Tiago Souza