por Roberto Mascarenhas Braga
Microsoft Student Partner
Microsoft Certified Professional


Desde o lançamento do Powershell muito se tem falado sobre as facilidades de gerenciamento permitidas pela nova linguagem de scripts/prompt da Microsoft. Realmente as possibilidade são infinitas. Recentemente tive a necessidade de automatizar uma tarefa no Active Directory de onde trabalho, o que motivou este artigo.

Ao pesquisar sobre as alternativas, deparei com o conector ADSI do Powershell (artigo da Technet Magazine - Windows Powershell Working with Active Directory).

Alguns exemplos interessantes de como usar o ADSI com o Powershell:

Operando com contas de usuário
$usuario= [ADSI]LDAP://CN=Roberto,CN=Users,DC=robertobraga,DC=net

Para conferir se o comando teve sucesso, digitar no prompt do Powershell o nome da variável e teclar enter.

Para recuperar um campo da conta como o "Description", por exemplo, utilizar a sintaxe:
[PS] C:> $usuario.Description


Combinando os "get" e "set" do Powershell com estruturas de controle e repetição, estes comandos permitem ir fundo no Active Directory. Apesar disso, o ADSI ainda exige certo esforço operacional e suas queries ainda estão um pouco longe da linguagem natural. Continuando minhas pesquisas, encontrei uma boa alternativa (gratuita!) que seria bem útil à resolução do meu caso.

Antes de falar sobre a solução, falemos sobre o problema. A estrutura de Active Directory do cenário em questão é relativamente complexa, com cerca de 3 mil estações de usuários (distribuídas em vários sites com links de longa distância MPLS convergindo para um site principal). Atualmente, os deploys de software são feitos via GPO. Visando otimizar os tempos de login e separar estações que estão em fase de deploy inicial de estações que estão em produção e com os softwares requeridos instalados, elaboramos a seguinte sequência de passos:

1) Computador ingressa no domínio no container padrão (Computers);
2) Computador é movido do container padrão para OU de deploy;
3) Computador é movido para a OU definitiva.

Desta forma, a carga de scripts e GPOs poderia ser distribuída entre operação normal e operações de deploy.  Para automatizar as tarefas do passo 2, resolvemos optar por uma soluição baseada no Powershell.

Voltemos a ele. As pesquisas sobre como operar com o Active Directory com o Powershell levaram a um produto (gratuito!)interessante, o Management Shell for Active Directory, da Quest Software. Outro produto que recomendo bastante é o Power Gui, interface para construir e testar scripts. Bem parecido com IDEs para o .NET Framework, o produto permite comentar e descomentar em blocos e fazer debugging interativo. Show!


Power Gui, construindo o script


Antes de mostrar o script em si, vale falar sobre as etapas da instalação. Instalei as ferramentas em uma máquina que utilizamos para tarefas agendadas, que roda Windows Server 2003 R2. Na sequência:

1) .NET Framework 3.5 - http://www.microsoft.com/downloads/details.aspx?FamilyId=333325FD-AE52-4E35-B531-508D977D32A6&displaylang=en
2) Powershell v 1.0 - http://www.microsoft.com/downloads/details.aspx?FamilyID=10ee29af-7c3a-4057-8367-c9c1dab6e2bf&DisplayLang=en
3) Quest Management Shell for Active Directory - http://www.quest.com/powershell/activeroles-server.aspx
4) Power Gui (na minha máquina cliente, para escrever o código do script) - http://www.powergui.org/downloads.jspa

Depois de instalar e testar as ferramentas, o script que move os computadores do container padrão (robertobraga.net/Computers) para a OU de deploy (robertobraga.net/Computadores/Deploy), ficou assim:

set-Location c:\
add-PSSnapin quest.activeroles.admanagement

$agora=get-Date
$ano=$agora.Year.ToString()
$mes=$agora.Month.ToString()
$dia=$agora.Day.ToString()

Get-QADComputer -SearchRoot 'robertobraga.net/Computers' -SizeLimit 0 -ErrorAction SilentlyContinue |
Where-Object {$_.Name -cnotmatch "^SRV*"} |
Move-QADObject -NewParentContainer  'robertobraga.net/Computadores/Deploy' |
Export-Csv c:\ScriptComputers\$ano$mes$dia.csv -force

Alguns comentários sobre o script:
set-Location c:\
add-PSSnapin quest.activeroles.admanagement
Por ser um cmdlet externo, é necessário garantir que os cmdlets da Quest estejam disponíveis quando o script for rodar. O comando add-PSSnapin garante isso.

$agora=get-Date
$ano=$agora.Year.ToString()
$mes=$agora.Month.ToString()
$dia=$agora.Day.ToString()
(...)
Export-Csv c:\ScriptComputers\$ano$mes$dia.csv -force

Como o script vai rodar como uma tarefa agendada, foi importante gerar logs das operações de mover contas de computador. Utilizando o cmdlet Export-Csv podemos obter essa listagem em uma apresentação mais agradável (lembram de como gerar um CSV com VBS? :-) ).

Get-QADComputer -SearchRoot 'robertobraga.net/Computers' -SizeLimit 0 -ErrorAction SilentlyContinue |
Where-Object {$_.Name -cnotmatch "^SRV*"} |
Move-QADObject -NewParentContainer  'robertobraga.net/Computadores/Deploy' |

Agora a "mágica"! Utilizamos três cmdlets. O primeiro, Get-QADComputer, permite (como era de se esperar), recuperar informações sobre contas de computador no diretório. O parâmetro -SearchRoot permite definir onde pesquisar. Adicionamos também parâmetros para garantir que não tivéssemos limites na quantidade de registros retornados.

No script, este primeiro cmdlet faz pipelining (representando pelo sinal "|" de pipe) para um nativo do Powershell, o Where-Object. Este cmdlet permite fazermos restrições no conjunto de resultados obtidos. Desta forma, para cada registro obtido (representado por $_), checaremos se ele não começa com "srv" ou variantes. Isto foi necessário para garantir que servidores (no nosso padrão de nomenclatura, srv-xxx) não fossem movidos para a OU de deploy.

Por final um último pipelining, com o cmdlet Move-QADObject. Ele exige um único parâmetro, o novo destino de um objeto capturado via Get-QADComputer. É interessante aqui pensar no Active Directory como um banco de dados, em que mudamos o valor de um campo. O campo em questão seria o "endereço" de determinado objeto. Mudando o "endereço", nada mais fazemos do que mover o objeto.

Para completar os procedimentos, adicionaremos o script como uma tarefa agendada. No Windows Server 2003 R2, o caminho é o seguinte: Start > Control Panel > Scheduled Tasks > Add Scheduled Task. Na listagem, escolher o Windows Powershell. Nas próximas telas é possível definir a frequência de execução e o horário.

Outra configuração importante é definir a conta com qual o serviço rodará. A boa prática recomenda que uma conta de serviço apenas para esta finalidade seja criada, com as permissões necessárias (no caso, mover contas de computador).

Ao terminar as configurações, marcar a opção "Open Advanced Properties for this task when I click Finish". Na caixa de diálogo aberta, colocar a seguinte sequência de comandos em "Run":

powershell.exe -noprofile -Noninteractive -command "& 'C:\ScriptComputers\ScriptComputers.ps1' "

Esta sequência de comandos indicará ao Powershell que, ao inicializar, deverá carregar o script ScriptComputers.ps1 (o script que move os computadores). Agora é só esperar data e hora agendadas para que os computadores comecem a ser movidos.

Algumas referências úteis:
Blog do time do Powershell
ActiveRoles Management Shell for Active Directory - Administrator's Guide (PDF - 200Kb)
Blog do Vinicius Canto - MVP scripting
Script Center - Powershell