Windows PowerShellAutomatizando o gerenciamento de diretórios

Don Jones

Um dos elementos mais prejudiciais à primeira versão do Windows PowerShell foi o cronograma. A equipe do Windows PowerShell sofreu alguma pressão para entregar o produto (havia um certo produto, chamado Exchange Server 2007, que dependia do Windows PowerShell) e a equipe do Active

Directory tinha muito a fazer naquele momento (um outro produto, chamado Windows Server® 2008, já estava em andamento). Por isso, o Windows PowerShell foi lançado com recursos de gerenciamento do Active Directory® inferiores ao esperado.

Na verdade, os recursos para o Active Directory não estão completamente ausentes do Windows PowerShell®. A equipe do Windows PowerShell fez um enorme esforço de última hora para incluir um suporte aceitável para ADSI (Interface de Serviços do Active Directory), uma tecnologia amigável para scripts já conhecida dos usuários do VBScript.

O método baseado na ADSI

A ADSI é semelhante à WMI (Instrumentação de Gerenciamento do Windows®) em sua forma de funcionamento. Você emite uma consulta, que é gravada com o uso de uma sintaxe especial. A consulta é transmitida a um computador remoto (como um controlador de domínio) e executada. O resultado da consulta é um objeto ou uma coleção de objetos do Active Directory (como um usuário ou um grupo) e você obtém uma referência àquele objeto com a qual pode trabalhar. É possível modificar propriedades do objeto ou executar métodos para salvar suas alterações, criar novos objetos, excluir objetos, e assim por diante. Para criar um usuário, por exemplo, você deve consultar a UO (unidade organizacional) ou o contêiner onde quer que o usuário resida. O objeto obtido tem um método Create, que pode ser usado para criar o usuário.

Em um nível muito básico, usar a ADSI no Windows PowerShell parece algo simples e direto. Por exemplo, este comando recupera um usuário e exibe seu atributo Company:

$user = [ADSI]"LDAP://cn=Ringo,ou=Singers,dc=company,dc=pri"
$user.Get("Company")

Você pode canalizar o usuário para Get-Member para ver suas propriedades e métodos. É uma pena que o Windows PowerShell 1.0 não conte com uma implementação realmente eficaz desses objetos de diretório. Como mostra a Figura 1, o shell não enumera os atributos de diretório do objeto nem exibe seus métodos — como o método Get que usei.

Figure 1** Piping the user to Get-Member to see its properties **(Clique na imagem para aumentar a exibição)

Esse suporte foi um pouco aperfeiçoado na CTP (Community Technology Preview) do Windows PowerShell 2.0, mas só até certo ponto. Conclui-se que o Microsoft® .NET Framework subjacente não permite aos administradores ver facilmente o que desejam, afinal o Framework foi projetado originalmente para desenvolvedores. O outro problema é que a equipe do Windows PowerShell não pode ir além disso, e um ótimo suporte para o Active Directory precisa vir de quem realmente entende de diretórios. Ou seja, da equipe do Active Directory. Tenho certeza de que isso acontecerá no seu devido tempo, afinal o Windows PowerShell ainda é muito recente. Mas o que você deve fazer enquanto isso?

Talvez você se lembre de que abordei o uso das tecnologias de ADSI incluídas no Windows PowerShell na edição de junho de 2007 desta coluna (technetmagazine.com/issues/2007/06/PowerShell). Sugiro que você releia a coluna se quiser obter mais detalhes sobre essa técnica "nativa". Nesta edição, quero mostrar algumas outras abordagens.

Um ecossistema avançado

O arquiteto do Windows PowerShell, Jeffrey Snover, geralmente menciona o ecossistema avançado que circunda o Windows PowerShell. Isso significa, simplesmente, que a equipe fez um ótimo trabalho garantindo que qualquer pessoa, e não apenas os programadores da Microsoft, possa estender os recursos do Windows PowerShell. Várias empresas já têm feito isso, criando cmdlets nativos do Windows PowerShell que permitem administrar seus produtos a partir da linha de comando — VMWare, IBM, Citrix e Foundry são algumas das principais empresas a atuar dessa forma até agora.

Um dos meus exemplos favoritos desse ecossistema avançado é o software da Quest. A empresa oferece um conjunto de cmdlets gratuitos, não-comerciais, projetados para o gerenciamento do Active Directory. Você pode baixá-los em quest.com/powershell. Eles também oferecem a PowerGUI (powergui.org), uma interface gráfica do usuário gratuita e não-comercial baseada no Windows PowerShell, destinada aos profissionais que ainda não estão preparados para aderir totalmente à experiência de uso da linha de comando. A PowerGUI torna mais fácil o aprendizado para usar os cmdlets de gerenciamento do Active Directory. E, pode acreditar, você vai querer usá-los. Esses cmdlets proporcionam facilidade e capacidade sem precedentes para o gerenciamento do Active Directory (caso você queira ler mais sobre a PowerGUI, ela foi incluída na edição de janeiro de 2008 da coluna Toolbox, que pode ser encontrada em technetmagazine.com/issues/2008/01/Toolbox).

O método baseado no Windows PowerShell

Qualquer processo que envolva cmdlets é a verdadeira forma de trabalhar com o Windows PowerShell. Não é preciso lidar com scripts de aparência tradicional nem com objetos de programação extravagantes. Eis aqui a linha de comando da qual mais gosto. É uma única linha de comando que importa um arquivo CSV e usa as informações contidas nele para criar dezenas ou até mesmo centenas de novos usuários do Active Directory:

Import-CSV 'C:\provision1.csv' |
ForEach-Object {New-QADUser -organizationalUnit 'company.pri/Singers' -name ($_.'First Name' + '.' + $_.'Last Name') 
-samAccountName $_.'Logon name' -city $_.city -title $_.'Job title' -department $_.department} 

É mesmo um comando longo, mas é incrivelmente poderoso. Ele começa com Import-CSV, um cmdlet nativo do shell que simplesmente lê um arquivo CSV e retorna objetos. Cada linha do arquivo CSV é um objeto único e as colunas do arquivo CSV tornam-se propriedades do objeto. No meu arquivo Provision1.csv, as colunas têm nomes do tipo "Logon Name" e "First Name". Isso é interessante porque os nomes das colunas não são mapeados diretamente para os atributos de usuários do Active Directory. Acho que é comum arquivos assim utilizarem nomes de colunas que soem mais familiares, em vez de nomes específicos do Active Directory. Afinal, talvez você receba o arquivo de alguém do departamento de recursos humanos da sua empresa, e é provável que eles não saibam que Last Name é realmente o atributo sn do Active Directory.

Quando todos os dados no arquivo CSV tiverem sido importados e transformados em objetos, esses objetos serão canalizados para o cmdlet ForEach-Object, que executará um bloco de código — entre chaves na minha linha de comando — para cada objeto. Ou seja, esse script será executado uma vez para cada linha no arquivo CSV. No script, a variável especial $_ é uma referência ao objeto atual — ou seja, a linha atual do arquivo CSV.

Você pode ver que, para cada objeto, executo o cmdlet New-QADUser. Ele faz parte das dezenas de cmdlets no suplemento da Quest. O nome QADUser é digno de nota. O Q, como você deve ter adivinhado, significa Quest. Essa convenção de nomenclatura foi criada para evitar um conflito entre o eventual cmdlet New-ADUser que a equipe do Microsoft Active Directory provavelmente produzirá no futuro. Assim, se os dois cmdlets forem carregados no shell ao mesmo tempo, você e o shell poderão distingui-los facilmente.

O restante da linha de comando consiste em parâmetros do cmdlet New-QADUser. Ele começa especificando a organizationalUnit, o local onde você deseja que todos os novos usuários sejam criados. Em seguida, vem o atributo de nome, que defini como o conteúdo da coluna First Name, seguido de um ponto e do conteúdo da coluna Last Name.

Um último fato interessante: o parâmetro de cidade irá, na verdade, alterar o atributo l (ou Locality-Name) do Active Directory. O cmdlet também aceita um parâmetro chamado l, que faz a mesma coisa. Em geral, os parâmetros relacionados a atributos do Active Directory podem usar o nome do atributo ou o rótulo de texto da ferramenta Usuários e Computadores do Active Directory.

O outro método baseado no Windows PowerShell

O Active Directory é um armazenamento hierárquico e um dos pontos fortes do Windows PowerShell é a capacidade de expor qualquer armazenamento hierárquico como uma unidade de disco. Isso permite usar um conjunto familiar de comandos, como Dir, Del, Ren, Copy, e assim por diante, para gerenciar diversos armazenamentos. Infelizmente, o Windows PowerShell 1.0 não foi lançado com um fornecedor PSDrive para o Active Directory, ou seja, o shell não tem como expor o Active Directory em si como uma unidade.

Mas, felizmente, o ecossistema avançado volta a entrar em cena com as PowerShell Community Extensions. Esse suplemento gratuito, de código aberto, está disponível em codeplex.com/powershellcx. Depois de instaladas, as PowerShell Community Extensions permitem simplesmente direcionar o shell para o seu nome de domínio, para que você comece a gerenciar o diretório como se fosse uma unidade:

CD COMPANY:
CD SINGERS
DIR

Esses comandos farão a alteração para o domínio COMPANY e para a UO Singers e, depois, exibirão uma lista de objetos, conforme mostrado na Figura 2. A partir daí, posso usar comandos como Del para excluir um usuário, Md para criar uma nova UO, e assim por diante. Há algumas armadilhas no fornecedor PSDrive das Community Extensions. Basicamente, elas estão relacionadas a funções que esperaríamos ter implementadas, mas que não estão disponíveis porque nem tudo é mapeado para a forma como o próprio Active Directory trabalha. E é preciso ter muita cautela: fazer a alteração para a raiz do seu domínio e executar o recurso del * irá, na verdade, excluir todos os objetos no domínio, desde que você tenha permissão. Por padrão, não será pedida nem a sua confirmação. A linha de comando é mesmo poderosa, mas isso traz riscos para alguém que não tenha conhecimento e cautela suficientes.

Figure 2** Using the PowerShell Community Extensions to direct the shell and manage the directory **(Clique na imagem para aumentar a exibição)

Comece hoje mesmo a usar o shell

Meus alunos sempre perguntam o que podem fazer hoje com o Windows PowerShell. Afinal, nem todos os produtos da Microsoft foram reprojetados para usar o Windows PowerShell e, à primeira vista, pode parecer que o Windows PowerShell ainda está em um período de espera para tornar-se realmente interessante.

Na verdade, já é interessante. Embora a Microsoft ainda não tenha instrumentado o Active Directory para o gerenciamento via linha de comando, outros já fizeram algumas tentativas e saíram-se muito bem. Você pode usar o Windows PowerShell para realizar diversas tarefas administrativas, inclusive automatizar algumas das mais demoradas e cansativas, como a criação de lotes de novos usuários. O grande truque é descobrir o que a comunidade tem feito para aumentar a utilidade atual do Windows PowerShell (talvez você queira explorar o site PowerShellCommunity.org, co-patrocinado pela Microsoft, que eu ajudo a administrar). Com as ferramentas certas carregadas no Windows PowerShell, comece a criar scripts para aquelas tarefas administrativas demoradas que você não quer fazer e torne-se um administrador bem mais eficiente.

Don Jones é co-autor do livro Windows PowerShell: TFM, 2nd Edition (Windows PowerShell: TFM, 2a edição), autor do livro VBScript, WMI, and ADSI Unleashed (Liberando o potencial de VBScript, WMI e ADSI) e diretor do site PowerShellCommunity.org.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..