Os arquivos da área de trabalhoPersonalizando serviços de implantação do Windows

Wes Miller

Sumário

Substituindo o que você possui
Examinando a pilha
Programa de inicialização de rede
Provedor PXE do WDS
TFTP Daemon
Armazenamento de dados de configuração da inicialização
Windows PE
Servidor de transporte
Multicast personalizado
Conclusão

Por três meses, tenho me aprofundado no WDS (Windows Deployment Services) — suas origens, uma visão geral, um exame mais próximo de alguns tópicos avançados como WDSUtil e multicast. Neste capítulo final da série, vamos dar uma olhada em onde e como você pode personalizar e configurar o WDS para atender às necessidades da sua organização. A maioria das ferramentas da Microsoft é projetada com alguma quantia de configurabilidade. Mas é quando o pneu tocar a estrada que você normalmente descobrirá se as ferramentas atenderão às suas necessidades ou, com mais freqüência, que elas exigem alguns ajustes para funcionar nos seus cenários.

Substituindo o que você possui

Uma pergunta que os leitores me fazem com freqüência ultimamente é: "Eu tenho x (uma tecnologia de implantação existente). O WDS funcionará para mim e ele possui recurso de paridade com x?". Com a desaprovação do ADS (Serviços Automatizados de Implantação), uma área de interesse particular é: "Como posso executar uma implantação rápida de alto volume ou o reprovisionamento de servidores — o WDS pode fazer isso por mim?".

Embora o WDS não tenha sido projetado como uma substituição 1:1 para o ADS — e, de fato, faltam nele alguns componentes principais para que seja considerado um substituto real —, com um pouco de trabalho você pode fazer com que o WDS substitua o ADS. Da mesma forma, se algum aspecto do WDS não estiver funcionando para você do modo em que ele está, você descobrirá que muitos de seus componentes podem ser substituídos — com graus variáveis de complexidade e engenharia. Vamos dar uma olhada na implantação por WDS e examinar as partes que você pode desejar personalizar e como você poderia fazer isso.

Examinando a pilha

A Figura 1 mostra os componentes do processo de implantação do WDS. Cada uma dessas etapas pode ser personalizada até um determinado nível. Eu codifiquei por cores cada etapa para refletir o que acredito ser a complexidade (geralmente as habilidades de desenvolvimento) envolvida na substituição ou personalização dela. Quanto mais escuro for o azul, mais difícil provavelmente será para personalizar aquela etapa.

Figura 1 Complexidade de personalização do WDS

A dificuldade em personalizar cada etapa realmente, é claro, depende das habilidades da sua equipe (desenvolvimento ou script) e sua compreensão do WDS, do WIM (Windows Imaging Format), do Active Directory ou de qualquer outra tecnologia que você queira integrar, como SQL ou ADSI. Vamos examinar cada uma dessas etapas, pensando nas maneiras em que você pode querer personalizá-las e os métodos que podem ser usados.

Programa de inicialização de rede

É duvidoso que você precise criar um NBP (programa de inicialização de rede) personalizado para substituir os fornecidos com o WDS, mas é possível. O WDS inclui NBPs para uso com sistemas sem periféricos (geralmente servidores) ou sistemas que você pode ou não solicitar por F12, e assim por diante. Esses NBPs podem ser pré-configurados no Active Directory usando o WDSUtil, ou você pode substituir Startrom.com pelo NBP que deseja usar para todos os sistemas que não estejam pré-configurados (por exemplo, se todos os seus sistemas forem sem periféricos ou se você nunca desejar solicitar por F12).

Infelizmente, não existe muita documentação disponível sobre como criar seu próprio NBP (consulte msdn.microsoft.com/library/bb870970.aspx para obter algumas informações). Um NBP é um executável de 16 bits muito pequeno com fortes limitações e requer habilidades de programação específicas. Eu geralmente recomendo o uso de NBPs existentes fornecidos com o WDS, a menos que você esteja tentando atender a um requisito muito específico e você possua uma equipe de desenvolvimento com as habilidades apropriadas.

Provedor PXE do WDS

Com o RIS (serviços de instalação remota), comentários comuns que recebíamos dos clientes eram sobre o desejo de usar um armazenamento de dados que não fosse o Active Directory para informações do sistema do cliente — com mais freqüência, SQL Server. Com o WDS, o design inclui uma infra-estrutura conectável para provedores PXE (ambiente Pre-Boot eXecution). Isso significa que com o trabalho de desenvolvimento, você poderia usar outro armazenamento de apoio, além do Active Directory para informações PXE.

O WDS vem com seu próprio provedor que usa o Active Directory; o SCCM (System Center Configuration Manager) agora se conecta também ao WDS e implementa um provedor seu. A documentação sobre como escrever seu próprio provedor é muito escassa e não existem muitos códigos de exemplo disponíveis (embora o Windows SDK forneça alguma documentação e alguns exemplos), então a tarefa não é para os humildes. A menos que você tenha requisitos muito específicos para esse aspecto do processo de inicialização, eu novamente recomendaria não tentar um provedor PXE personalizado.

TFTP Daemon

Às vezes, os clientes investiram em seu próprio TFTPD (Daemon de protocolo de transferência de arquivos simples) antes que o WDS surgisse. Como os servidores PXE não funcionam bem juntos, isso muitas vezes significa se estabelecer em apenas um.

Na minha experiência, isso normalmente significa adotar um TFTPD existente, tipicamente baseado em Linux, e persuadi-lo a inicializar outros SOs. Com a infra-estrutura original usada pelo RIS você não poderia fazer isso. Mas quando a inicialização de RAMDisk virou norma, você poderia, e ainda é possível fazer isso usando imagens de inicialização baseadas no WDS.

Uma coisa a se ter em mente é que você está vagando por uma área tecnicamente não-suportada com relação à Microsoft e uma que muito provavelmente poderá causar problemas difíceis de se diagnosticar. Além disso, com o TFTPD aprimorado no WDS, você pode muito bem estar se distanciando de um melhor desempenho. Idealmente, recomendo que você use o TFTPD do WDS existente e tente usar tempos limite, pré-configurações e/ou bordas da rede do PXE para definir que clientes são inicializados de qual servidor PXE, em vez de tentar desviar um servidor existente para que se ajuste.

Armazenamento de dados de configuração da inicialização

Com o RIS, nunca foi possível, no nível da inicialização, especificar o que deveria ser inicializado, você sempre precisava passar pelo OS Chooser e selecionar uma opção (configuração, Windows PE —ambiente de pré-instalação do Windows — ou inteiramente outra coisa). O WDS, uma vez que ele usa um carregador completo para inicialização de rede, também suporta a personalização do armazenamento BCD (dados de configuração da inicialização) fornecida a clientes. O BCD padrão para cada arquitetura reside em RemoteInstall\Boot\<arch>\Default.bcd, onde <arch> é a arquitetura específica do sistema que está sendo inicializado.

Você pode personalizar esse BCD para cada cliente e o cliente o usará para inicializar. Você poderia, por exemplo, configurar uma entrada BCD para iniciar a configuração, outra para executar o WinRE (ambiente de recuperação do Windows) e ainda outra para executar um teste de memória — ou você poderia ter uma entrada de configuração totalmente automatizada como padrão e uma manual (ou experiência de configuração personalizada) como uma opção selecionada pelo usuário. (Para obter mais informações, vá para "How to Modify the BCD Store Using Bcdedit" — Como modificar o armazenamento BCD usando Bcdedit — em go.microsoft.com/fwlink/?LinkId=115267.)

É claro que a maior parte da tarefa pesada do WDS ocorre no Windows PE — então ajustar o Windows PE para atender às suas necessidades pode ser uma área crítica de foco para uma experiência personalizada. O WDS, por padrão, fornece um modelo padronizado para configuração, que inclui a experiência de configuração completa. Às vezes, as necessidades da sua implantação podem significar que isso não funcionará para você. Nesse caso, você pode criar sua própria imagem de inicialização do Windows PE. Vamos começar do início.

Além de usar o BCD para indicar que imagem usar, você também pode especificar a imagem personalizando o MAO (objeto de conta da máquina) para um computador no Active Directory. No RIS, um atributo de MAO específico armazenava cada item (que arquivo Startrom e Unattend — SIF — usar). Com o WDS, eles são armazenados como pares de nome-valor na entrada netBootMirrorDataFile. Por exemplo, a imagem de inicialização e o arquivo Unattend a ser usado por um determinado computador são armazenados nessa entrada. A forma das entradas é uma lista delimitada por ponto-e-vírgula de pares de nome-valor. As entradas para modificar a imagem de inicialização e o arquivo Unattend são BootImage e UnattendFilePath, respectivamente.

É claro que você poderá descobrir que deseja abandonar completamente a experiência de configuração existente e apenas criar a sua própria. Talvez você precise de mais configurabilidade, mais automação ou uma compilação automatizada pelo SQL Server. Você pode querer fazer como alguns clientes fizeram com o RIS e o Windows PE no início e compilar seu próprio front-end para configuração. As principais tarefas que você precisa realizar, independentemente da experiência de configuração escrita, são:

• Descobrir qualquer informação por máquina ou por usuário. Essas informações podem ser obtidas da entrada do usuário ou do SQL Server ou de um arquivo de texto, por exemplo.
• Copiar e aplicar uma imagem de configuração para o sistema do cliente. Essa tarefa pode ser realizada usando a configuração diretamente, usando ImageX para aplicar uma imagem de um compartilhamento de rede ou por multicast (simplesmente copie a imagem e aplique-a via ImageX).
• Fornecer um arquivo Unattend (como Unattend.xml ou sysprep.inf, dependendo da versão do Windows que está sendo implantada) para a configuração ser concluída.
• Automatizar qualquer etapa de migração pós-configuração que você deseje executar (ou qualquer etapa para aplicar funções no caso do Windows Server 2008).

O ADS iniciou o conceito de seqüências de tarefas que permite a etapas reprodutíveis serem atribuídas a um ou mais computadores. Como o ADS não foi projetado ou suportado para o uso com o Windows XP, você não poderia usá-lo para implantar o sistema operacional. Mas a seqüência de tarefas do ADS é realmente apenas de scripts estruturados e você pode executar as mesmas etapas usando um processo de configuração personalizado.

Sou fã do Microsoft SQL Server há algum tempo (desde a versão SQL Server 6.5), então meu instinto é criar tal estrutura usando o SQL. É claro que você precisa adicionar a funcionalidade do SQL à sua compilação do Windows PE para fazer isso. Além disso, você poderia escrever sua própria GUI — um HTA (aplicativo HTML) ou executável compilado — ou usar o WSH (Windows Script Host) para executar uma experiência de configuração apenas de linha de comando minimalista. O HTA ou WSH também precisariam ser adicionados ao Windows PE para que fossem utilizados.

A complexidade em projetar sua própria experiência de configuração completamente depende das suas habilidades e sua imaginação. Tenho visto sistemas bem elegantes definidos apenas pelo uso de SQL e WSH ou HTA — que são habilidades relativamente fáceis para alguém aprender. É muito importante, no entanto, ter em mente as restrições mencionadas em colunas anteriores:

• O Windows PE não apresenta o subsistema WOW (Windows no Windows), então você precisa compilar uma vez para cada arquitetura que pretende suportar.
• Você não pode usar o Visual Basic 6.0 se precisa implantar o Windows PE via x64 ou IA64.
• Você pode usar o Visual Studio 2005 ou 2008 para compilar aplicativos, mas deve compilar um aplicativo do Visual C++ não-gerenciado, uma vez que o Microsoft .NET Framework — qualquer versão — não é suportado no Windows PE.
• Sem um .NET Framework, você também não pode usar o Windows PowerShell para automação.

Você pode, é claro, usar um utilitário de imagens de terceiros via WDS também, se quiser escrever sua própria experiência de configuração. Embora eu ache que os formatos WIM e ImageX possam atender à maioria dos cenários de implantação, podem existir certos requisitos que sua ferramenta de imagens existente atende para você.

Da mesma forma, certos cenários podem exigir um particionamento personalizado — você pode estar implantando o Windows Vista com BitLocker, ou compilando sistemas do Windows XP e armazenamento dados de perfis em um segundo volume, ou talvez você esteja implantando um sistema do Windows Server e deseje criar um volume separado no mesmo disco para registro. Qualquer uma dessas opções requer automação de DiskPart, que, como nas versões anteriores, pode ser feita pela alimentação de um script (qualquer formato de arquivo) no DiskPart que contenha os comandos que você deseja executar e termine com exit (sair) — para encerrar o DiskPart.

Criar sua própria experiência de configuração não é para os medrosos, uma vez que você está basicamente recompilando o executável de configuração (ou pelo menos espelhando sua funcionalidade) e pode haver muito a se projetar e compilar. Mas tudo se reduz a quanta funcionalidade você deseja compilar nele por padrão e em que você está compilando (HTA ou WSH ou uma linguagem de programação compilada).

Servidor de transporte

Se não estiver usando a maior parte da funcionalidade nativa no WDS (como o Active Directory) ou estiver projetando sua própria solução personalizada completa, o servidor de transporte pode atender suas necessidades e não apresentar requisitos que você não deseja. A tabela da Figura 2 (reproduzida de "Utilizando o servidor de transporte" em go.microsoft.com/fwlink/?LinkID=115298) descreve o que está incluído como parte da função do servidor de transporte do WDS.

Figura 2 Servidor de implantação versus Servidor de transporte

Quando digo que o servidor de transporte é um item complicado a implementar, não é a função em si que é difícil; essa, é claro, é facilmente implantada (veja a Figura 3). É a implementação da configuração personalizada ao redor do servidor de transporte que requer trabalho. Usar a função de servidor de transporte remove com eficiência a maior parte da facilidade de uso incorporada ao WDS como uma função.

Figura 3 O servidor de transporte pode ser útil para cenários de implantação personalizados (clique na imagem para ampliá-la)

Multicast personalizado

Esteja você usando ou não a função de servidor de transporte — mas especialmente se estiver — há um ótimo exemplo a ser feito usando multicast se você estiver fazendo uma implantação de vários sistemas. O ADS apresenta um recurso de multicast muito eficiente, que você pode duplicar usando o WDS com multicast. O WDS apresenta em si o multicast, mas se você estiver compilando sua própria solução personalizada, poderá aproveitar o multicast usando WDSMCast, como mencionei mês passado (veja a Figura 4). Lembre-se de que você precisa transferir o(s) arquivo(s) de imagem a ser(em) implantado(s) e, em seguida, eles devem ser aplicados. Geralmente, isso significa que você precisa de espaço em disco local suficiente para a imagem ser armazenada e, em seguida, aplicada.

Figura 4 Executando o WDSMCast (clique na imagem para ampliá-la)

Conclusão

O WDS proporciona uma eficiência significativa em si só — provavelmente suficiente para várias organizações atenderem suas necessidades. Mas se você estiver procurando compilar sua própria solução que vá além dos limites do WDS, poderá certamente fazê-lo — você é limitado apenas pela sua imaginação, seu cronograma e suas habilidades.

Wes Miller é gerente sênior de produto técnico da CoreTrace (CoreTrace.com), em Austin, no Texas. Anteriormente, ele trabalhou na Winternals Software e como gerente de programa da Microsoft. Entre em contato com ele pelo email technet@getwired.com.