Os arquivos da área de trabalhoGuia avançado para usuários do WIM e do ImageX

Wes Miller

Esta coluna se baseia em uma versão de pré-lançamento do WAIK (Kit de Instalação Automatizada do Windows) e do Windows Server 2008. Todas as informações aqui contidas estão sujeitas a alterações.

Em muitas das minhas colunas anteriores, abordei o ImageX e o formato WIM (Windows Imaging). Há alguns meses, na Tech•Ed, ouvi alguns comentários e dúvidas dos profissionais de TI que começavam a usar o WDS (Serviços de Implantação do Windows), o ImageX e o WAIK (Kit de Instalação Automatizada do Windows). Percebi que havia

necessidade de mais orientação para os usuários. Então, na coluna deste mês, eu gostaria de me concentrar no ImageX e no formato WIM, e em como obter o máximo deles. Juntos, o ImageX e o WIM permitem implantar facilmente o Windows Vista® e o Windows Server® 2008, e também o Windows® XP, o Windows Server 2003 e o Windows 2000.

Alterações no WAIK

Com a chegada da próxima versão do Windows Server 2008, você deve estar imaginando o que isso significa para o WAIK. A Microsoft planeja lançar uma versão atualizada do WAIK no mesmo período de lançamento do Windows Server 2008. Não há alterações significativas no formato WIM (a ferramenta ImageX e o formato permanecem inalterados); também não há mudanças no WDS para Windows Server 2003. Ao contrário dos rumores, o multicast não estará disponível no WDS para Windows Server 2003 — somente os servidores WDS executando Windows Server 2008 contarão com o novo recurso de implantação multicast para WDS.

O Windows PE 2.0 e a Instalação do Windows passarão por uma revisão para dar suporte aos seguintes recursos:

  • Implantação do Windows Server 2008 e do Windows Vista.
  • Implantação multicast via WDS a partir de um servidor WDS do Windows Server 2008.
  • Implantação de versões x64 e x86 do Windows Vista e do Windows Server 2008 a partir do Windows PE x86.

Em primeiro lugar, isso significa que o Windows PE 2.0 será capaz de implantar o Windows Server 2008 tão prontamente quanto implanta o Windows Vista, pois as mesmas ferramentas e processos funcionam para os dois. Em segundo lugar, quando seus servidores WDS estiverem executando o Windows Server 2008, você poderá utilizar a implantação multicast via WDS. Por fim, você poderá usar um disco Windows PE 2.0 x86 e, a partir dele, implantar uma imagem x86 ou x64 do Windows.

Mencionei esse último aspecto na Tech•Ed, na minha sessão sobre o Windows x64. Infelizmente, houve alguma confusão quanto a isso em blogs e na comunidade técnica do Windows. Isso não significa que a Microsoft distribuirá o Windows x64 e x86 em todos os DVDs do Windows Vista e do Windows Server 2008. Também não significa que você deve combinar imagens do Windows x64 e do Windows x86 em um único arquivo WIM (embora seja possível). Isso não gera a economia do armazenamento de instância única, embora permita transportar um só arquivo WIM.

Na verdade, significa que os clientes corporativos e os OEMs que dedicaram anos ao desenvolvimento de processos de implantação baseados em x86 (além de ferramentas e scripts personalizados) agora poderão implantar o Windows x86 ou x64 a partir do WIM usando a instalação de 32 bits — algo que os clientes corporativos vêm solicitando desde o lançamento do Windows x64, em 2005.

O ImageX no dia-a-dia

Usando /mount, /mountrw e /delete

Eis aqui algumas dicas importantes para usar as opções /mount, /mountrw e /delete com o ImageX:

  • Monte um volume com /mountrw se pretende editá-lo.
  • Você deve montar um WIM em um diretório vazio, eliminando a confusão com os arquivos possivelmente armazenados em um diretório já existente, e também para impedir que o ImageX emita uma mensagem de aviso desnecessária.
  • Não se esqueça de aplicar /unmount /commit à sua imagem de leitura/gravação se quiser salvar as alterações feitas. Muitas vezes, já fiz alterações e me esqueci de confirmá-las (e assim as perdi).
  • Excluir arquivos com /mountrw e excluir imagens de volume com /delete não serve para recuperar espaço. Na verdade, isso pode até mesmo consumir mais espaço. Para obter mais detalhes, consulte a seção desta coluna sobre /export.
  • Você só pode montar um único arquivo WIM uma vez para acesso de leitura/gravação. Dois usuários não podem editar o mesmo WIM de uma só vez e não é possível editar duas imagens de volume ao mesmo tempo.
  • Até mesmo no modo somente leitura (/mount), você deve limitar o número de imagens de volume montadas simultaneamente, pois o driver tem uma dependência em relação à quantidade de memória de pool não paginado do Windows disponível no seu sistema para cada imagem montada. Isso resulta em um limite que pode variar por sistema (ou por arquitetura de sistema). Não recomendo tentar montar simultaneamente mais do que cinco imagens.
  • Fazer edições significativas com /mountrw quase não demandará tempo no momento das alterações, mas poderá fazer com que /commit demande um tempo considerável, pois precisará compactar e armazenar todos os novos dados de arquivo.
  • Use /delete e /mountrw com cautela. Quando as alterações forem confirmadas, não poderão mais ser desfeitas.
  • Não é possível executar /delete com apenas uma imagem de volume em um arquivo WIM (em vez disso, exclua o arquivo WIM inteiro ou acrescente outra imagem de volume).
  • Para obter rapidamente uma árvore de diretórios com o conteúdo de uma imagem de volume, em vez de /mount, use este comando:
ImageX /dir <path_to_wim_file> <image index>
  • Se estiver editando dois arquivos WIM ao mesmo tempo, procure não aplicar /unmount a eles ao mesmo tempo; estabeleça uma seqüência para seus eventos de montagem/desmontagem, de forma que um não bloqueie o outro.

O ImageX foi criado especificamente para espelhar a forma como OEMs e clientes corporativos afirmam usar as ferramentas. A Figura 1 mostra o processo.

Figura 1 Usando o ImageX

Figura 1** Usando o ImageX **

Convém destacar que a Etapa 5 é crítica pois, na realidade, uma imagem passa por alterações constantes. Assim, era preciso que a captura e a modificação da imagem fossem feitas com o máximo possível de rapidez e facilidade.

Por isso, é possível acrescentar uma imagem adicional (usando a opção /append) a uma imagem já criada. Inicialmente, a equipe de desenvolvimento imaginou que seria útil poder acrescentar mais um SKU (versão do Windows) à imagem anterior. No entanto, quanto mais eu trabalhava com clientes corporativos no estágio inicial do desenvolvimento do Windows Vista, mais ouvia falar que ele era usado para implantar X rapidamente, depois recapturar X1, onde havia sido feita uma das modificações da Etapa 2. Isso permitia recapturar a imagem com rapidez, pois apenas um número restrito de arquivos havia sido modificado.

Quando a equipe compreendeu isso, percebeu que talvez não fizesse sentido manter a imagem original em todas as situações. Mais adiante, nesta coluna, abordarei a opção /export, adicionada especificamente devido a esse cenário e ao que será apresentado em seguida.

Alterações constantes

Logo de início, a equipe de desenvolvimento decidiu que os arquivos WIM deveriam ser editáveis. Como já havia sido decidido que um formato de imagem baseado em setores não funcionaria (consulte a coluna de dezembro de 2006 em technetmagazine.com/issues/2006/12/DesktopFiles para ler uma explicação), era preciso criar uma solução capaz de montar facilmente os arquivos de forma nativa, como parte do sistema de arquivos do Windows, e de fazer alterações nas imagens de volume montadas no arquivo WIM. Isso representava mais algumas "partes móveis", como gosto de chamá-las. É relativamente fácil montar uma imagem baseada em setores. Contudo, montar um formato de arquivamento proprietário como o WIM exigiria algumas ferramentas bastante específicas.

O formato precisava de acesso a partir do prompt de comando, dispensando as extensões do Shell do Windows normalmente usadas para manipular arquivos ZIP e CAB de forma nativa. Infelizmente, esses manipuladores somente permitem ao Windows Explorer o acesso abstrato a um objeto.

Como resultado, a solução WIM envolve um driver (wimfltr.sys) e o ImageX, que funciona como método para carregar efetivamente o driver e lida com a interface de montagem do WIM. O driver serve para adicionar uma abstração ao sistema de arquivos do Windows, conforme mostrado na Figura 2. Ao executar um comando desse tipo, você solicita que o ImageX carregue o driver wimfltr.sys, de forma que o driver sobreponha a primeira imagem de volume (aquela presente nos comandos usados aqui) à montagem de diretório vazia, como você pode ver a seguir:

Figura 2 Montando uma imagem de volume WIM

Figura 2** Montando uma imagem de volume WIM **(Clique na imagem para aumentar a exibição)

ImageX /mount iso\sources\boot.wim 1 mount 
ImageX /mountrw iso\sources\boot.wim 1 mount 

Esse é o comportamento padrão no WAIK. Assim, ao explorar ou gerar uma listagem de diretório no diretório de montagem, você vê a raiz da Imagem de volume 1 em boot.wim. É claro que usar /mountrw ou /mount determinará se o diretório será somente leitura ou leitura/gravação (consulte a barra lateral "Usando /mount, /mountrw e /delete" para obter mais detalhes).

O recurso /mountrw foi criado, a princípio, para adicionar facilmente drivers e outros arquivos ou conteúdos habilitados para xcopy, configurar arquivos de resposta ou modificar o registro offline de um arquivo WIM montado para alterá-lo conforme a necessidade (veja a Figura 3). Não foi criado para adicionar ou remover aplicativos inteiros (uma vez que aplicativos instalados com o MSI não podem ser instalados offline).

Figura 3 Modificando um arquivo WIM montado

Figura 3** Modificando um arquivo WIM montado **(Clique na imagem para aumentar a exibição)

É fundamental entender que, ao fazer alterações no arquivo WIM montado, você não está alterando diretamente o verdadeiro arquivo WIM (pelo menos, não de imediato). Em vez disso, está alterando um cache do arquivo WIM que é, efetivamente, uma mesclagem da sobreposição e das alterações feitas por você. Como destaco na barra lateral, isso já me causou problemas. Quando terminar, não se esqueça de usar as opções /unmount e /commit, pois somente assim suas alterações serão confirmadas no arquivo WIM. Caso contrário, serão completamente perdidas.

Quando você salva suas alterações confirmando-as, está solicitando que o driver faça as alterações no arquivo WIM propriamente dito. O driver acrescenta os dados de arquivo adicionais (observe que, se você fez muitas alterações, isso significa que /commit poderá demorar um tempo considerável, pois somente com essa opção os dados de arquivo serão adicionados ao WIM).

Além disso, ao contrário de um formato de imagem baseado em setores, você pode ter alterado um ou mais arquivos na imagem de volume. Assim, não são mais arquivos de instância única (a não ser que o mesmo arquivo já tenha sido armazenado uma vez), o que resultará na perda dos dados de arquivo originais. O WIM, ao contrário de um volume NTFS ou FAT, não marca um arquivo como excluído. Deixa de fazer referência a ele, mas não o apaga. Então, se você fizer edições freqüentes com /mountrw, usar /append para adicionar muitas imagens ou usar /delete para excluir uma imagem de volume, isso somente fará com que o arquivo WIM perca as referências aos dados de arquivo. Os dados de arquivo relacionados não serão totalmente descartados.

Por isso, a equipe de desenvolvimento criou a opção /export, também conhecida, de certa forma, como "desfragmentador do WIM".

Exportação

Observações importantes sobre /export

Quando a opção /export é usada para criar um novo arquivo WIM, é possível especificar qual o tipo de compactação a ser usado, em vez de aceitar o tipo de compactação padrão usado no momento. Se você alterar o tipo de compactação atual, a exportação poderá levar um tempo considerável.

Quando usada, na verdade, como /append (para adicionar uma imagem de volume a um arquivo WIM já existente), a opção /export não permite modificar o atributo /compression do arquivo WIM.

Você poderá especificar a opção /boot se estiver exportando uma imagem de volume totalmente nova do Windows PE 2.0.

A opção /export foi criada em resposta aos dois cenários mencionados anteriormente, e também a alguns outros cenários mais complexos descobertos pela equipe. Em poucas palavras, /export permite exportar uma imagem de volume já existente (ou duas, ou três). Isso significa que é possível, usando os arquivos WIM X e X1 mencionados anteriormente, criar um novo WIM apenas com X, apenas com X1 ou com X1 e Y1, exportado de outro arquivo WIM.

Imagine um cenário onde você faça modificações em X e use /append para adicionar as alterações como X1. Você decide excluir X, pois essa imagem foi substituída por uma nova para o trimestre. Você pode usar a opção /delete e o ImageX perderá as referências à imagem X. Mas, se quiser economizar espaço eliminando todas as informações relacionadas a X, você precisará executar este comando:

ImageX /export source.wim 2 destination.wim "New image for Q4CY07"

Isso exportará a segunda imagem de volume para um novo arquivo WIM com o novo nome, eliminando completamente as informações anteriores da Imagem de volume 1. Também é possível exportar a partir de imagens WIM distribuídas, se você quiser remontá-las em um só arquivo WIM (assunto que abordarei mais adiante nesta coluna). As imagens distribuídas não podem ser editadas com /mountrw — um motivo pelo qual talvez você queira remontá-las. É importante observar que não existe comando /import para o ImageX, pois /export é capaz de criar novos arquivos WIM ou de fazer acréscimos aos já existentes. Consulte a barra lateral "Observações importantes sobre /export" para obter mais informações sobre o assunto.

Isso também é fundamental se você vai executar peimg /prep: embora esse comando prepare sua imagem do Windows PE para ser usada, não apaga nada no WIM. O ideal, como parte do seu processo de liberação do Windows PE, é que você prepare a imagem e a exporte para um novo arquivo boot.wim. Observe que o processo de inicialização somente procura pelo arquivo WIM em \sources\boot.wim. Por isso, verifique se ele foi nomeado corretamente e se está marcado como uma imagem de volume de inicialização.

Já mencionei que provavelmente você vai querer otimizar suas imagens executando /export nelas, quando for descomissionar imagens de volume antigas ou combinar várias. Você também vai querer fazer isso se tiver feito várias edições com /mountrw ou /delete. Caso contrário, seu arquivo WIM continuará a crescer com o passar do tempo (por motivos misteriosos que você não conseguirá diagnosticar). Se estiver usando regularmente /mountrw ou /delete, avalie a possibilidade de acrescentar /export ao seu fluxo de trabalho para garantir que as imagens sejam otimizadas ao máximo.

Distribuição

Outro problema que se apresentou, logo de início, foi a provável necessidade de que os arquivos WIM se ajustassem a várias mídias de CD ou DVD. Previmos que o Windows seria fornecido em mais de um CD (e possivelmente em DVD, como ocorreu) e, por isso, incorporamos o suporte à distribuição no WIM e no ImageX.

Como já mencionei, uma imagem distribuída criada com /split é basicamente somente leitura. Não é possível usar /capture para capturá-la diretamente em uma nova imagem distribuída, nem montá-la com o ImageX ou adicioná-la com /append. Por isso, recomendo que você só divida seu arquivo WIM quando tiver terminado o fluxo de trabalho padrão e estiver pronto para a liberação. Ou seja, faça todas as suas edições no arquivo WIM normal e considere a divisão como parte do processo de liberação para o cenário de implantação.

No que se refere à aplicação, as imagens distribuídas podem representar um desafio. Recomendo usar o ImageX em vez da instalação quando for trabalhar com imagens distribuídas. Recomendo também aplicar as imagens via rede (para obter um desempenho ideal sem ter de gerar uma imagem do disco a partir do qual está fazendo a aplicação) ou então copiá-las diretamente para a unidade e depois aplicá-las (mas observe que você ficará limitado ao disco, que estará lendo e gravando em si mesmo no momento da aplicação).

Em busca de validação

Quando você usa o ImageX, move uma grande quantidade de dados — e dados muito importantes. Uma pergunta que ouvi muitas vezes na Tech•Ed deste ano foi: "Como posso garantir que minhas imagens são válidas?". Bem, isso não é assim tão fácil, mas também não é tão difícil.

O fator mais importante a respeito do WIM que você precisa entender é que, assim como a maioria dos formatos de arquivamento, ele pode ser corrompido. Em geral, esse tipo de dano ocorre quando um arquivo WIM é transmitido via rede. Desde o início, com o Windows Vista, percebemos problemas específicos com placas de rede específicas — se elas descartavam pacotes, o arquivo WIM era corrompido, e nem sempre de uma forma fácil de diagnosticar. Essa situação, na verdade, refletia outra ocorrida anos antes, quando o arquivo driver.cab aumentou de tamanho. Isso produziu danos aleatórios semelhantes. Em geral, se você obtiver relatórios de imagens defeituosas ou falhas na instalação, convém verificar que tipos de NICs estão em uso nos sistemas que geraram esses relatórios. Isso vale para o uso apenas do ImageX ou executando o WDS.

Então, como é possível saber se uma imagem está ou não em bom estado? Em primeiro lugar, você pode usar a opção /check. Isso dispensa outras verificações de integridade no arquivo WIM e verifica, antes da aplicação, se o WIM não foi corrompido. Execute /check também no momento da aplicação, para validar a imagem (embora leve mais tempo).

Além disso, se você está tendo problemas — ou simplesmente quer ser meticuloso — pode executar um utilitário de hash nos arquivos antes da captura e após a aplicação. Também é possível fazer a verificação após a captura, montando a imagem e refazendo o hash — o que não é ruim como método para garantir a captura correta de uma imagem.

Você vai querer ter certeza de que suas imagens estão sendo capturadas corretamente desde o início. A opção /check e o formato em si foram projetados como pontos de verificação, e não como ferramentas de recuperação para reparar uma imagem capturada de forma incorreta.

Inicialização e sinalizadores

Já mencionei que é possível usar /boot para capturar uma imagem de volume WIM do Windows PE e inicializá-la. Você deve encarar isso simplesmente como um setor de inicialização em uma imagem de volume específica. Ele só pode existir em uma imagem de volume por WIM e só é válido para o Windows PE 2.0. Observe que você não pode inicializar o Windows PE 1.x via WIM, pois isso simplesmente não é possível.

Talvez você encontre referências a sinalizadores nas imagens de volume do Windows. Os sinalizadores são usados somente pela Instalação do Windows. Um sinalizador de 2 em uma imagem de volume significa que essa imagem contém o Windows PE e a instalação. Um sinalizador de 9 significa que contém apenas o Windows PE. Qualquer outro sinalizador ou a ausência dele significa que a imagem não pode e não será usada pela instalação. Observe que você pode definir sinalizadores em uma imagem depois que ela for capturada, usando o ImageX para modificá-la. Recomendo usar o WAIK (e, como opção, o Business Desktop Deployment Solution Accelerator) para criar sua imagem de inicialização do Windows PE via WIM, pois os sinalizadores serão definidos corretamente logo de início.

Uma observação para os usuários do HTA

Recentemente, ouvi vários relatos de usuários sobre problemas na execução de arquivos HTA no Windows PE 2.0. Infelizmente, parece haver um problema com os arquivos HTA contendo qualquer script significativo. Veja, na Figura 4, a captura de tela do exemplo de arquivo que criei, e observe o erro de script retornado. Esse problema foi relatado por vários clientes e eu mesmo o experimentei.

Figura 4 Erro de script do HTA

Figura 4** Erro de script do HTA **(Clique na imagem para aumentar a exibição)

Felizmente, a correção é relativamente simples. Ao preparar sua imagem, adicione suporte a XML e também a HTA. A dependência ausente no componente de HTA parece estar incluída no módulo suplementar de XML, solucionando o problema.

Gostaria de agradecer a Bruce Green, desenvolvedor do ImageX, e a Minxiao Zhou e Raja Ganjikunta, da equipe de teste de implantação do Windows, pelo auxílio na preparação desta coluna.

Wes Miller é gerente de desenvolvimento da Pluck (www.pluck.com) em Austin, no Texas. Ele já trabalhou na Winternals Software, em Austin, e na Microsoft, como gerente de programas e gerente de produtos do Windows. Ele pode ser contatado pelo email technet@getwired.com.

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