Deploying Windows 7 from A to Z

Microsoft Corporation
Published: January 2010

Abstract
Neste artigo, Jeremy Chapman, gerente de produto snior da Microsoft, documenta as etapas de
alto nvel para profissionais de TI para executar uma escala empresarial projeto inicial de
implantao de desktop com o Windows XP e se mudar para o Windows 7.

Copyright information
As informaes contidas neste documento representam a viso atual da Microsoft Corporation
sobre os assuntos discutidos at a data de publicao. Como a Microsoft deve responder s
condies de mercado, este documento no deve ser interpretado como um compromisso por
parte da Microsoft, e a Microsoft no pode garantir a exatido de qualquer informao
apresentada. Este documento apenas para fins informativos. MICROSOFT NO D
NENHUMA GARANTIA, EXPRESSA OU IMPLCITA, NESTE DOCUMENTO.
A Microsoft pode ter patentes ou solicitaes de patentes, marcas registradas, direitos autorais
ou outros direitos de propriedade intelectual sobre o assunto neste documento. O fornecimento
deste documento no fornece ao leitor nenhuma licena para as patentes, marcas registradas,
direitos autorais ou outros direitos de propriedade intelectual, exceto quando expressamente
previsto em qualquer contrato de licena da Microsoft.
Microsoft no faz qualquer representao ou garantia em relao a especificaes neste
documento ou em qualquer produto ou item desenvolvido com base neste documento. Microsoft
se isenta de todas as garantias expressas e implcitas, incluindo, mas no limitado s garantias
implcitas de comercializao, adequao a uma finalidade especfica, e liberdade de infrao.
Sem limitar a generalidade do exposto, a Microsoft no faz nenhuma garantia de qualquer tipo
que qualquer item desenvolvido com base nessas especificaes, ou qualquer parte de uma
especificao, no vai infringir qualquer direito autoral, patente, segredo comercial ou outro
direito de propriedade intelectual de qualquer pessoa ou entidade em qualquer pas. de sua
responsabilidade de buscar licenas para tais direitos de propriedade intelectual se for caso
disso. Microsoft no ser responsvel por quaisquer danos decorrentes de ou em conexo com
o uso dessas especificaes, incluindo a responsabilidade por lucros cessantes, interrupo de
negcios, ou quaisquer danos. Alguns estados no permitem a excluso ou limitao de
responsabilidade ou danos consequentes ou incidentais, a limitao acima pode no se aplicar a
voc.
2010 Microsoft Corp Todos os direitos reservados.

Contents
Implantando o Windows 7, de A a Z ......................................................................................5
Migrando arquivos e configuraes do usurio do Windows XP para o Windows 7 .............7
Gerenciamento de Aplicativos e Preparao para a implantao do Windows 7 ..................9
Application Compatibility ......................................................................................................10
Embalagem de Aplicao ....................................................................................................13
Escolhendo uma estratgia de imagem e construo de imagens do Windows 7 Sistema .14
Lio de Histria rpida para Imaging System ....................................................................14
Construindo sua Imagem .....................................................................................................16
Chegando a finas Imagens ..................................................................................................17
Automatizar a migrao do Windows XP para o Windows 7 End-to-End ............................18
Automatizando o processo de migrao de ponta a ponta-..................................................19
Mais truques para Automao ..............................................................................................23

Notes

Deploying Windows 7 from A to Z

Por Jeremy Chapman, gerente snior de produto da Microsoft Corporation
Para uma viso completa do Windows 7 recursos, artigos, demonstraes e orientaes,
visite a Srie Springboard para Windows 7 no Windows Client TechCenter.
Para uma verso da Web deste documento, consulte o Windows 7 Implantando de A a Z
no Windows 7 Biblioteca Tcnica (http://go.microsoft.com/fwlink/?LinkId=180726).
Como a empresa cara implantao do sistema operacional, muitas vezes eu recebo pedidos
para uma "uma pgina" artigo sobre a realizao em escala empresarial, implantao de desktop
ou como migrar centenas ou milhares de computadores com o Windows XP para o Windows
7. Embora eu tenha visto todo o comprimento livros impressos na cabea de uma caneta, eu no
acho que possvel explicar todo o conjunto de tarefas de migrao do desktop ao passar de
uma verso do sistema operacional para outro dentro de uma pgina. Se voc est atualizando
um computador de Windows Vista , ou realizar uma instalao limpa em seu computador
pessoal (provenientes de qualquer verso recente do Windows), h uma pgina de orientao
disponvel no site da Microsoft: Instalar e reinstalar o Windows 7. Mas provavelmente no ir
satisfaz-lo se voc quiser realizar essas tarefas mais do que algumas vezes.
Vamos comear por afirmar algumas suposies:
1. 1. Voc um profissional de TI olhando para mover vrios computadores ou usurios de
Windows XP ou Windows Vista para o Windows 7.
2. 2. Os computadores que esto em transio para o Windows 7 tem os dados do usurio,
configuraes e aplicaes que de alguma forma (parcial ou totalmente) precisam ser
migrados para o Windows 7.
3. 3. Voc no quer transferir manualmente os arquivos do usurio por meio de cpia de
arquivos ou usar ferramentas de consumo operadas manualmente (como o Windows
Easy Transfer) do computador legado para o Windows 7.
4. 4. Voc prefere ter aplicaes ser parte do sistema operacional personalizado de instalar
ou automatizar a instalao do aplicativo como parte do processo de implantao total.
5. 5. No melhor dos casos, voc prefere que todo o processo to automatizada possvel.
6. Voc tem alguma experincia anterior com a instalao do sistema operacional,
implantao, ou de imagem do sistema.
Voc pode estar pensando: "Que tal utilizar os processos comuns de disco rgido clonagem ou
setorial de imagem para duplicar uma instalao de referncia?"
A boa notcia que, com os avanos da imagem sistema, voc no precisa mais passar horas
salvando os dados do usurio fora um antigo computador de clonagem, o disco rgido de um
computador de referncia e, em seguida, tomar o tempo para restaurar os dados que voc
salvou na primeira etapa . Embora o processo de clonagem do disco rgido , provavelmente, a
prtica mais comum utilizado, tem vrias desvantagens, incluindo:
O tempo necessrio para clonar cada sistema.
5

 A proliferao de imagens do disco rgido com base em vrios tipos de hardware.

Grandes tamanhos de imagem e do espao de armazenamento correspondente
consumida.
O custo potencial de disco rgido software de clonagem.
O excesso de tempo gasto na reconstruo e manuteno de vrias imagens.
Os processos manuais para ativar licenas de usurios finais.
Voc tem algumas opes ao migrar do Windows XP, e muitos deles dependem do tamanho e
complexidade do seu ambiente. Destacamos quatro principais opes para migrar do Windows
XP para o Windows 7 (ou Windows Vista), no artigo Escolhendo Estratgia de Implantao no
Microsoft TechNet. Na verdade, esse artigo vai para maiores detalhes do que este documento, e
ele faz um grande trabalho de apontar para ferramentas e recursos.
Eu estou usando bastante alguns termos como sinnimos ao longo deste documento. Quando
eu uso os termos como "migrar do Windows XP" ou "implantao de sistema operacional" ou "a
transio do Windows XP", eu estou falando sobre os seguintes passos principais que cobrem
em qualquer implantao de sistema operacional:
Coleta de dados do usurio e configuraes existentes (se existirem)
Instalao do sistema operacional
Instalar os drivers e aplicativos
Ativar o sistema operacional
Participar de um domnio (se necessrio)
A restaurao de dados e configuraes do usurio
Proporcionar a flexibilidade para personalizar as aplicaes que vamos instalar pelo papel
de usurio, ea aplicao de preferncia de idioma, localidade, fuso horrio, e assim por
diante com base nas necessidades do usurio.
Geralmente se referem a esse processo coletivo em vrios computadores como "implantao", e
h alguns termos outros vamos definir antes de concluir. Sees subsequentes referem-se a
cenrios de instalao, ento vamos definir as principais:
1. Refresque computador. Isto , quando um usurio tem um computador com arquivos,
configuraes e aplicaes. Estaremos instalando o novo sistema operacional para o
computador existente e assumindo o mesmo usurio que mantm computador. Neste
caso, vamos tentar manter os arquivos e configuraes do usurio localmente no
computador para economizar tempo, armazenamento e largura de banda de rede.
Alguns se referem a isso como uma "in-loco limpar e carregar" (sem realmente limpar os
dados do usurio) ou livremente como "modernizao" de um computador.
2. Substituir Computador. Isto , quando o usurio est recebendo um novo computador ou
um computador transferido de outro usurio e os dados e configuraes do usurio
precisa se mover para fora do computador antigo atravs de algum mtodo e sobre o
novo computador. Este cenrio tende a levar mais tempo comparado a atualizao do
computador e computador novo. Alguns referem-se a esta como "lado-a-lado", migrao,
mas no necessrio para os computadores de estar fisicamente perto uns dos outros,
ou de outro modo ligado a este cenrio.
6

3. Novo computador. Isto , quando no h nenhuma exigncia para migrar dados prexistentes de usurios ou configuraes. Novo computador usado para uma nova
contratao ou para um computador secundrio, ou se um computador antigo foi perdido ou
danificado e os dados do usurio no foi feito o backup. Alguns se referem a isso como "nu
metal" implantao, mas na maioria dos casos h alguma OEM pr-instalado sistema
operacional que vai substituir.
Agora temos listados os pressupostos para este documento, listados algumas razes pelas quais
voc pode querer olhar para o seu processo de implantao existente se envolve clonagem do
disco rgido, mais ou menos definido o todo se operacional processo de implantao do sistema,
e definiu os principais cenrios de instalao. At agora, tenho ido mais de uma pgina de
comprimento, mas isso fornece o pano de fundo para as prximas sees. Na seo seguinte,
vou descrever as opes e recomendaes para a migrao de dados do usurio e
configuraes quando se deslocam a partir do Windows XP para o Windows 7.

Migrating User Files and Settings from

Windows XP to Windows 7
Vou comear com a migrao de dados puramente com base nas etapas de automao na
cadeia eu listados na primeira seo e porque no h muitas coisas que me excita mais no
espao de implantao do Windows 7 do que o hard-link de migrao. Pense sobre as
velocidades de movimentos de arquivos grandes contra cpias de arquivos, que
essencialmente a vantagem da velocidade que dura-link migrao pode ter. Se voc de
internao como eu sou, e voc odeio esperar 3-4 horas por computador para o estado do
usurio para migrar de um sistema operacional para outro (especialmente considerando o
sistema operacional mais aplicaes combinadas muitas vezes leva menos de 45 minutos),
ento voc pode apreciar-dura ligao migrao como eu.
Para ser justo, voc pode usar tecnologias e tticas como perfis mveis e redirecionamento de
pasta, e voc pode no permitir a criao de locais de e-mail lojas, altura em que muitos dos
problemas associados migrao de estado do usurio pode ir longe. Mas, neste caso, eu vou
cobrir o caso tradicional do estado do usurio como parte do computador do usurio.
Se voc gerenciar os computadores desktop, voc provavelmente tem vrios usurios com
arquivos em cada localizao possvel em seus computadores, e h configuraes como
favoritos do Internet Explorer, conexes de rede sem fio, conhecidos e configuraes de
aplicativos que voc quer de volta no novo sistema operacional. Podemos lidar com todas essas
coisas, exceto para a migrao das aplicaes em si. Na maioria dos casos, ns vamos querer
testar a compatibilidade de aplicaes mais antigas, e no necessariamente tentar migr-los no
local do Windows XP para o Windows 7. Alm disso, podemos automatizar completamente a
instalao de aplicativos gerenciados em tempo de implantao ou captur-los como parte da
imagem personalizada do sistema operacional. Eu vou cobrir tudo isso na seo seguinte,
quando eu falar sobre gerenciamento de aplicativos.

Trazendo de volta para arquivos e configuraes do usurio, sabemos que os dados do usurio
so normalmente armazenados em um par de lugares:
"C: \ Documents and Settings" no Windows XP
"C: \ Users" no Windows Vista e verses mais recentes do Windows
Ento a questo que deve ser colocada ...
"No podemos usar um utilitrio como o Robocopy para mover os arquivos de" C: \ Documents
and Settings "para uma pasta em algum lugar da rede que nomeado para o computador e
depois copi-los de volta para o" C: \ Users "pasta depois de terminar? "
Bem, sim e no, no o que normalmente simples embora. A menos que voc tem normas
draconianas e polticas sobre o local onde os usurios podem salvar os dados em suas unidades
locais, isso no ser suficiente. Ns tambm temos que olhar atravs de configuraes no
registro que queremos manter no novo computador, criar e ativar as contas de usurio, e alguns
de ns pode querer bloquear alguns arquivos sejam migrados. Por exemplo, voc no pode
querer Joe no departamento de marketing para armazenar seu 100 GB de msica e vdeo
cobrana no seu computador gerenciado, assim que ns pode querer bloquear certos tipos de
arquivo no processo de migrao (esperamos que Joe sabe sobre isso com antecedncia para
ele tem tempo para fazer backup de sua coleo de mdia). Por outro lado, Joe pode no saber
onde seus arquivos do Microsoft Office Outlook PST so, e mesmo que pegar o arquivo PST
com nosso comando Robocopy, ele provavelmente vai chamar o Help Desk perguntando onde
seu cache e-mail depois 'tenho instalado o Windows 7.
A boa notcia que temos uma ferramenta para isso, o User State Migration Tool (USMT). A
notcia ainda melhor que se voc usar o Microsoft Deployment Toolkit (MDT) ou o System
Center Configuration Manager 2007 SP2, j parte do fim-de-final processo de implantao do
sistema operacional. Voc pode ter visto as demos de migrao do Windows XP para o Windows
7 ocorrem em apenas 18 minutos (sim, com vrios gigabytes de dados que est sendo migrado,
tambm), mas se voc no tiver, confira:
Como parte do MDT: Windows 7 ferramentas de implantao Parte 4 Demo
Como parte do Configuration Manager: Microsoft Cpula Gesto 2009 Demo Keynote
Ambas as demos usar o Hard-Link de recursos de migrao para o cenrio de atualizao do
computador (defini este e outros cenrios da primeira seo). Nos velhos tempos, a USMT
poderia apoiar uma atualizao do computador sem mover os arquivos no computador, mas foi
basicamente uma cpia de arquivo e d um duplo instanciao de arquivos localmente. Agora,
os arquivos no se movem no disco ao migrar do Windows XP que simplesmente transferir
ponteiros para arquivos para os locais apropriados no Windows 7. O ndice de hard links
consome cerca de 200 MB, assim voc no precisa de muito espao em disco livre para usar
hard-link Migrao. Pense em quanto mais rpido ele "passar" um arquivo de 1 GB contra
copi-lo para outro local no mesmo disco, por isso hard-link migrao muito mais rpido.
Realmente no importa se mover 5 GB ou 50 GB na migrao, os tempos sero bastante
semelhantes. A quantidade de tempo que depende do nmero de ficheiros que se movem, e no
o tamanho dos ficheiros.
O User State Migration Tool agora parte do Windows Automated Installation Kit (AIK). O USMT
instala simplesmente atravs de uma cpia de arquivo. Depois de instalar o Windows AIK, por
8

padro, as ferramentas USMT para sistemas operacionais de 32-bit e 64-bit esto localizados no
"C: \ Arquivos de Programas \ Ferramentas \ Windows AIK \ USMT" pasta.
Voc pode baixar o Windows AIK a partir do seguinte site da Microsoft: Windows Automated
Installation Kit para o Windows 7.
Voc pode executar uma atualizao simples computador com hard-link migrao usando normal
do Windows 7 mdia de instalao junto com os arquivos do USMT em uma unidade USB I
delinear esse processo em um par de locais:
Em forma de vdeo: migrando do Windows XP para o Windows 7
Na forma escrita no TechNet: Windows XP para o Windows 7 Migrao Hard-Link de
arquivos e configuraes do usurio
Este processo ir migrar rapidamente os arquivos da pasta-padro criado Windows.old quando
voc instalar o Windows 7 em um computador com o Windows XP. Se voc no seguir o
processo padro e formatar a partio do Windows durante o processo de instalao,
Windows.old no vai estar l para migrar. Ento lembre-se de seguir o processo de instalao
padro para manter seus dados e criar Windows.old.
Voc deve estar se perguntando neste momento ...
"E se eu estou fazendo uma substituio de computador e os dados precisam passar de
computador meus usurios velho que est executando o Windows XP para o meu novo
computador que est executando o Windows 7?"
Substituio de computador bastante comum, e as ferramentas so construdas para lidar com
isso. Normalmente, os dados so passados a partir do computador antigo para um
compartilhamento de rede e, em seguida, a partir do compartilhamento de rede para o novo
computador. Tanto o Configuration Manager e MDT pode ser usado para automatizar todo o
processo de migrao de substituio computador usando um compartilhamento de rede. Voc
pode at mesmo criptografar o armazenamento de migrao na rede (como o Configuration
Manager faz por padro) para garantir depsitos de dados no pode ser comprometida.
Outra adio til para as ferramentas de migrao para substituio de computador o suporte
para Volume Shadow Copy. Isso significa que podemos reunir arquivos mesmo que eles esto
em uso. Uma coisa a apontar com substituio de computador que voc no pode obter os
benefcios de velocidade do Hard-Link migrao, porque estamos merc da fsica de mover os
dados para um local externo de rede ou disco rgido externo.
E sobre os tipos e localizaes de arquivos que so migrados? O User State Migration Tool
adiciona um novo algoritmo para encontrar mais arquivos do usurio do que as verses
anteriores lanamentos de USMT. O arquivo de controle (MigDocs.xml) usa a lgica de deteco
compartilhado e abrangente arquivo com o Windows Easy Transfer. Ento, se voc usou USMT
no passado, e voc teve que modificar em larga escala os arquivos de controle anteriores (por
exemplo MigUser.xml) para adicionar a cobertura de arquivo, o MigDocs.xml novo deve ser uma
adio bem-vinda.
Existem outros mtodos para mover arquivos entre sistemas operacionais, mas USMT foi
desenvolvido especificamente para gerenciar a migrao de dados do usurio e de apoiar tantas
opes tradicionais quanto possvel para os clientes com um grande nmero de computadores
para gerenciar. USMT faz um grande trabalho migrao de arquivos e configuraes do usurio.
9

Para as pessoas que esto procura de uma interface de usurio para USMT, eu recomendaria
que voc us-lo em conjunto com o Microsoft Deployment Toolkit ou com System Center
Configuration Manager. Se voc j usou USMT no passado, sem muito sucesso, a verso atual
do USMT oferece vrias melhorias para aumentar a velocidade, flexibilidade e confiabilidade do
processo para fazer a migrao de parte da implantao do sistema operacional mais fcil e
previsvel.
Na prxima seo, eu vou tomar sobre o tema da gesto de aplicaes, incluindo a
compatibilidade de aplicativos e automatizar a instalao do aplicativo, bem como toque no
inventrio de hardware e compatibilidade.

Application Management and Preparing for a

Windows 7 Deployment
Se voc como a maioria gerentes de servios de desktop, voc provavelmente tem vrios
aplicativos que voc conseguir, e dependendo de seus usurios, pode haver vrios aplicativos
que voc no conhece. Existem alguns lugares onde "Usurio padro" ou "menos privilegiado
Usurio" contas no so a regra, e os usurios podem instalar qualquer aplicativos que eles
querem. Se isso soa familiar, ento voc provavelmente tem um pouco de trabalho a fazer em
termos de deteco, racionalizar e testar os aplicativos que os usurios tm de se preparar para
o Windows 7. Voc pode resolver problemas de compatibilidade, usando uma variedade de
abordagens, e vamos discutir todas estas abordagens em um minuto.
A prxima rea grande que voc precisa se preocupar como obter esses aplicativos ou
correspondentes verses mais novas nos desktops de seus usurios que esto executando o
Windows 7. H uma boa chance de que voc tenha sido clonagem discos rgidos nos ltimos
dcadas e no necessariamente tm pacotes de instalao automtica para todos os aplicativos
que voc deseja implantar para o novo Windows 7 ambiente. Algumas aplicaes no so
embaladas para a instalao silenciosa, tornando difcil para personalizar as instalaes de
modo a incluir apenas os aplicativos que so especficos para funes de usurio. Juntamente
com outros fatores, isso significa que h um grande nmero de organizaes que ter 20 a 50
aplicaes, presentes em qualquer estao de trabalho, mesmo que os usurios s precisam 510 dessas aplicaes, em mdia. Com as novas ferramentas de desenvolvimento, voc pode
salvar o seu dinheiro com essas aplicaes e instalar o que exigido por usurio, em vez de darlhes tudo. Isto vai poupar sobre o licenciamento e pode melhorar o desempenho do Windows, se
alguns desses aplicativos iniciar na inicializao. Eu vou falar sobre o processo de
empacotamento de aplicativos depois que cavar um pouco mais fundo na compatibilidade de
aplicativos.

Application Compatibility
Ao contrrio da crena popular, o processo de compatibilidade de aplicativos no comear com
os testes. O primeiro passo que voc provavelmente vai querer tomar a de coletar um
inventrio de seu ativos de hardware e software. Esteja preparado para descobrir mais
10

aplicaes do que voc pensou que tinha. Uma ferramenta que voc pode usar o Application
Compatibility Toolkit ou "ACT".
Voc pode baixar o ACT no site da Microsoft: Application Compatibility Toolkit.
O Application Compatibility Toolkit no uma varinha mgica que voc onda em aplicaes de
"faz-los trabalhar", mas fornece as ferramentas para inventariar seus aplicativos, hardware e
dispositivos; avaliar a compatibilidade de tempo de execuo de aplicaes durante a coleta de
dados e comparar o que que tiver recolhido a um banco de dados central gerida pela Microsoft,
com dados de compatibilidade de ISVs e da comunidade de profissionais de TI.
Quando eu apresentar o kit de ferramentas em eventos, muitas vezes eu me perguntei: "Espere,
voc acabou de dizer o Application Compatibility Toolkit descobre hardware e dispositivos, e no
apenas aplicativos?"
Sim, verdade. ACT encontra as aplicaes onde quer que residam e que tambm relata
hardware e dispositivos que so detectados. Uma coisa a destacar que, enquanto a maioria
das ferramentas de inventrio relegar-se apenas os dados encontrados em Adicionar / Remover
Programas, ACT tambm parece em vrios locais do registro (Executar, Executar uma vez,
manipuladores de extenso de nome de arquivo, caminhos de aplicao, e assim por diante) , e
de servios. ACT tende a encontrar qualquer aplicativo no sistema ou no iniciados pelo usurio,
enquanto ns estamos realizando um inventrio. Depois de implantar o peso leve agente pacote
de coleta de dados em ACT, ACT detecta as informaes nas estaes de trabalho dos usurios
do Windows XP e envia a informao de volta ao local de rede que voc especificar, em seguida,
processa os dados e relatrios suas concluses para voc.
Confira um vdeo no TechNet sobre pacotes de Coleta de Dados: Creating Data Collection
Packages to Generate an Application Inventory
O grfico a seguir mostra um inventrio de aplicativos de amostra no Application Compatibility
Manager:

11

Muitos departamentos de TI tm um inventrio que eles esto confiantes e que no

necessariamente querem implantar agentes para seus usurios- completamente
compreensvel. Neste caso, no h nada melhor do que usar o site compatibilidade consumidor
a pesquisar aplicaes e dispositivos, um por um?
Consumer compatibility site
Se voc tem mais de cerca de 20 aplicaes, usando o site de compatibilidade do consumidor
provavelmente no a melhor opo. Tambm publicamos a seguinte lista de conhecidos
aplicativos compatveis que voc pode usar para consultar o banco de dados de inventrio de
aplicaes:
Windows 7 Application Compatibility List for IT Professionals
Qual o prximo? Se voc tem um inventrio completo, extremamente provvel que voc no
vai querer mover todos os aplicativos que voc encontrar a partir do Windows XP para o novo
Windows 7 ambiente. Pode haver cinco jogadores diferentes meios de comunicao ou oito
aplicaes diferentes que ler arquivos PDF em computadores de seus usurios coletivos. Na
verdade, muitas empresas podem eliminar 90% ou mais das aplicaes eles inventrio porque
esto duplicados na natureza, com base em hardware, ou indesejada. Voc pode usar a
filtragem previsto no ACT para ajudar a reduzir a lista.
O grfico a seguir mostra uma categorizao de aplicativos usando o filtro de alternncia no
Gerenciador de compatibilidade de aplicativos:

12

Isto importante, porque muito mais fcil para testar 100 pedidos em comparao com 1000
aplicaes e muitas vezes voc pode reduzir a sua lista de inventrio em um par de horas. Eu,
pessoalmente, em vez testar 100 pedidos de 1000, e eu estou supondo que a maioria concorda.
Assista a um vdeo no TechNet sobre como trabalhar com estoques ACT: Analyzing Compatibility
Data Returned by Data Collection Packages
Agora que temos a lista de racionalizao de aplicativos e dados estticos de ISVs de saber se
eles so compatveis, a diverso comea com o teste desses aplicativos sem informaes ISV.
Voc deve achar que a maioria de seus aplicativos funcionam no Windows 7 e isso
especialmente verdadeiro para embalado (ISV) que foram lanados nos ltimos trs anos. As
aplicaes desenvolvidas in-house que voc teve h cinco anos ou mais pode exigir ateno
especial. Os principais problemas esto a olhar para aplicaes que gostam de correr em
contexto administrativo e tm livre reinado do computador em que so executados, as aplicaes
que esto bloqueados a um nmero especfico verso do Windows, Web ou aplicaes que
exigem o Internet Explorer 6. Se voc j implantou o Internet Explorer 8, e seus usurios
geralmente tm contas de usurio padro, ento voc no ter tanto trabalho para fazer. Voc
pode encontrar mais informaes sobre por que os aplicativos podem ter problemas de
execuo no Windows 7 no seguinte guia no TechNet: Understanding Application Compatibility.
Depois que descobrir o que no est funcionando, temos uma srie de opes para faz-los
funcionar:
Para pacotes de aplicaes de ISVs, a melhor abordagem sempre encontrar uma
aplicao que roda nativamente na verso do Windows que voc deseja instal-lo. s
vezes, existem atualizaes gratuitas para esses aplicativos e s vezes no. Usando o
aplicativo como planejado e testado pelo ISV para o Windows 7 garante que o ISV pode
13

apoiar seus usurios e voc estiver executando sua aplicao de uma forma que eles
testaram.
Para aplicaes internas desenvolvidas, a melhor abordagem recodificar o aplicativo para
que ele rode nativamente. Se voc no tem o cdigo fonte ou h um reparo fcil, voc
pode usar correes de compatibilidade (ou "shims") para obter o aplicativo para ser
executado sem recodificar ele.
Para mais informaes sobre shims, consulte o site TechNet seguinte: Managing Shims in an
Enterprise.
Tambm confira o vdeo sobre shims de aplicao comumente usados: Mitigating Application
Compatibility Issues with Common Compatibility Fixes
Se voc simplesmente no pode fazer um trabalho de aplicao, ento no necessariamente
"game over." Se voc j esgotou todas as outras opes para fazer a execuo do aplicativo
nativamente, ento voc pode usar o Virtual PC para executar o aplicativo em um Windows
ambiente XP. Virtual PC com integrao RemoteApp muito mais intuitivo para os usurios finais
do que tem sido ao longo dos anos. Com o Virtual PC, agora podemos publicar atalhos no
desktop do computador fsico ou no menu Iniciar para aplicaes que esto contidos na mquina
virtual, e os aplicativos podem ser executados individualmente, sem expor o conjunto desktop do
Windows XP. O trade-off que voc vai ter dois sistemas operacionais para gerenciar por
usurio.
Se voc chegar a este ponto e voc tem um ambiente gerenciado, eu recomendo que voc olhar
para o Microsoft Enterprise Desktop Virtualization para que voc possa gerenciar o ambiente
virtual. Para mais informaes, consulte Microsoft Desktop Optimization Pack.
Depois de ter trabalhado por todos os seus aplicativos, inventariados eles, racionalizou-los, e
mitigados incompatibilidades, voc pode pensar que a diverso acabou. Quase. Agora que tudo
conhecido por ser de trabalho, voc vai querer descobrir como instalar seus aplicativos de uma
forma automtica. Na seo seguinte, eu vou falar sobre abordagens para chegar a um fino
imagem. Mas se voc tem aplicaes de embalagem em sua imagem do sistema operacional
base e realizar setoriais captura de discos seus computadores de referncia ", ento voc pode
querer olhar para formas de reduzir sua contagem de imagem e usar o hardware e os benefcios
de idioma neutro no Windows 7 para obter uma nica imagem. Chegar a uma nica imagem em
uma organizao maior normalmente significa o trabalho de empacotamento de aplicativos
necessria.

Application Packaging
For some, application packaging and figuring out how to automate the installation of your
applications will be as easy as finding the silent installation commands from the vendor. Usually
these are found in installation guides, Internet forums, or by using the ever-handy /help or /?
commands in the command line.
For in-house developed applications, there is a decent chance that silent installation commands
dont exist for all of your applications and those applications will need to be packaged for the first
time or repackaged if the installer package didnt work with your new configuration. (Common
14

examples are 16-bit installers when moving to a 64-bit operating system or operating system
version checks in packages looking for Windows version 5.1).
There are a couple of tools to help you create Windows Installer packages as easily as possible.
These are handy because they tend to follow normal msiexec.exe silent installation commands.
Microsoft Application Virtualization also provides what is essentially a packaging mechanism with
the application sequencing it uses to create virtual applications. For more information about these
tools, see the following Web sites:

Flexera Software AdminStudio

Microsoft Application Virtualization

You can avoid packaging some applications by not including those applications in the standard
operating system build process and by prestaging installation files locally or making them
accessible to users on the network. In the cases where everyone in the organization needs the
application anyway, you can install those applications on your reference computer and create a
custom image using ImageX. Well talk about the balance of how many applications to include in
the custom image in the next section.

Choosing an Image Strategy and Building

Windows 7 System Images
Now that weve introduced deployment, data migration, and application compatibility, lets focus
on imaging. Now this is not the imaging that involves photos and cameras, but the imaging of
computer disks.

Quick History Lesson for System Imaging

Imaging tools have been around for a long time, and the most basic tools essentially back up an
entire hard drive, sector-by-sector. Then we can restore that drive, if desired, to the same
computer or another computer. This is basically a form of drive cloning, and it was popularized in
the 1980s and 1990s. Like I said in the first section, this type of imaging is fairly archaic when
used for deployment in the enterprise, because youll need to maintain an image per Hardware
Abstraction Layer (HAL) type. For people managing Windows XP, youll often see an image per
language or region as well. What does this mean? Usually it means tens or hundreds of images
to manage for many organizations, all requiring maintenance when Patch Tuesday or similar
events or updates come around.
But sector-based imaging cant be that bad right? Well, lets say you have everything centralized
and you have 20 images to manage and up to 20 computers in your lab. When that critical update
hits, well spend an hour rebuilding each of those computers, maybe an hour configuring them,
and then up to three hours recapturing the image with sector-based imaging tools. That means
100 hours per month if you maintain images monthly and 1200 hours per year. To be fair, you
arent clicking and configuring things manually the entire time, but its probably fair to say youll
spend two hours per system across all tasks, and youll eventually have terabytes of system
15

images to find space for. If you are using the System Preparation Tool (Sysprep) to generalize the
image for installation on other computers, you get only three passes of the tool per system image
over its lifetime. You generally need to capture each image before running Sysprep and
afterward, so you can start next month with an image before you ran Sysprep, or else you need to
start completely from scratch each time and apply all the changes since the last service pack.
Fast forward to 2003 when engineers were determining the future of system imaging, and along
comes the Windows Imaging Format or WIM file. At the time, I was working with the Systems
Management Server (SMS) and Solution Accelerator teams at Microsoft, and WIM was a
prerequisite for the Operating System Deployment Feature Pack released in 2004. WIMs are filebased and compressed images that can also save the contents of a drive. WIMs used with
Windows XP were a pretty good option from a deployment standpoint, based on the reduced
image size and ability to pass that package over the network, but they were still tied to one
Hardware Abstraction Layer (HAL) type.
Fast forward to around 2006 and the early iterations of Windows Vista
WIMs used for Windows Vista and Windows 7 imaging and deployment take on a whole new
meaning. Remember those tens or sometimes hundreds of images to maintain and up to five
hours per month per image? With Windows Vista and Windows 7, you can get down to a single
image per operating system architecture (for example, a 32 bit image and/or a 64 bit image). As
an example, right now I am in an airplane writing on a Fujitsu U820 ultra mobile Tablet PC uniproc
that I built using the same image Ive applied to my bigger and less airplane-friendly Lenovo T60P
15 multiproc laptop, in addition to countless other hardware types.
But it gets even better than only a single image to manage for all hardware (and languages by the
way, too). Remember the five hours or so we would spend building, configuring, and recapturing
that old sector-based image? We can mount the file-based images of Windows Vista or
Windows 7 to a file folder and service them offline. In other words, I need one computer in my lab
to use as a reference machine for all computers, I can use a free tool in the Windows Automated
Installation Kit called ImageX to capture and apply system images, and I dont necessarily even
need to use that reference computer in my lab to service my one image on Patch Tuesday. I can
mount the image in a folder on my image storage server, use the Windows 7 and Windows
Server 2008 R2 in-box tool called dism.exe (Deployment Image Servicing and Management, in
case youre wondering) and enumerate the contents of the image to see packages, updates,
drivers, and features. I can then modify these contents offline by using dism.exeagain without
building that reference lab computer. Those five hours it took you to apply the three critical
patches on Patch Tuesday can take as little as about two minutes to mount the image, ten
minutes to service it, and two minutes to unmount it. Im usually pretty happy if I can save four
hours and 45 minutes performing an otherwise boring, but necessary task. And instead of doing
it 20 times and using 20 physical computers, I do it once. Makes sense, right?
To show some of that, here is a video of Sysprep and ImageX that shows how to generalize and
capture a custom image: Preparing an Image using Sysprep and ImageX
Here is a video that shows dism.exe servicing an offline mounted Windows 7 image: Deployment
Image and Servicing Management

16

I had to take a brief excursion from the deployment task at hand to give the history lesson,
because in all my interactions and talks with IT pros and my desktop admin friends lately, I see
two common issues when it comes to imaging:
1. The majority of people I talk to are still using the sector-based imaging tools theyve been
using for decades.
2. The majority of people arent maintaining Windows Vista or Windows Server 2008 images, so
they arent able to perform offline image management.
Even more troubling are the situations where Windows Vista or Windows Server 2008 are in
place, but people are using the 20-year old tools and processes to manage them. They arent
using or aware of Sysprep, so they need an image per HAL type or lots of luck that the image that
has not been prepared with Sysprep installs on foreign hardware. (This scenario without using
Sysprep, albeit unsupported, is still somewhat common).

Building Your Image

Windows Vista and Windows 7 are delivered by a file-based WIM image and image-based setup.
That DVD you might have or the ISO file you downloaded contains a 2+ GB file called install.wim
in the Sources directory. The amazing thing about this WIM is that it actually can contain multiple
operating system captures. In fact, the Windows Server 2008 R2 Enterprise image contains eight
operating system variants and the 32-bit edition of Windows 7 Ultimate contains five variants.
This would normally be larger than the Windows 7 Enterprise install.wim with one variant or a
custom captured image with a single operating system image, right? Not really. WIMs use single
instancing of shared files, so you can have multiple operating systems available in an image that
might be about the same size as one captured operating system.
This is important as you determine your image strategy, because you could, for example, have
multiple operating systems of differing languages packed into a single WIM file, and even with
multiple languages these should only be marginally larger than a single language WIM image.
WIMs can also be used to compress and deliver data, so you can package multiple applications,
drivers, and packages into the data WIM, then mount and call them at install time by using
scripted operating system installations.
Now that you know a bit about WIM files, lets cover the basics of imaging strategy. There are
three primary strategies used for imaging and all are valid depending on the use case:
1. Thick Image. I like to refer to this as the old school approach to imaging where you
basically build a reference machine, install all possible applications to ensure users have the
applications they could ever possibly need and usually more. After that is done, you apply
software updates for the operating system and all the applications, then you use Sysprep on
the computer to capture the image. Then you make sure everything works and ensure that
Sysprep didnt affect any applications.
2. Thin Image. This approach takes things to the other extreme. Little or nothing is installed on
the reference computer, and you use Sysprep to capture that image. Or some will just use the
image as shipped in the Windows 7 retail DVD or ISO with zero customization. This strategy
assumes that youll be customizing the installation with applications and other necessary data
17

dynamically at deploy time. This also means that all of your applications are packaged for an
unattended installation, or you are willing to prestage them for users to install when they
want, or you use something like Application Virtualization (App-V) so application profiles
follow users regardless of the device they log on to.
3. Hybrid Image. In between Thick and Thin is a Hybrid Image, where applications that
everyone uses or needs are captured in the base image (perhaps your VPN software, your
antivirus software, your version of Microsoft Office, and the App-V client). Aside from those
core applications, additional applications are layered on at deploy time based on user needs.
All three of these strategies can be justified, though I personally tend to favor thin images. The
thick image approach is useful in situations where the company has a homogeneous
environment, uses a single language, and all users use and need exactly the same set of
applications. When using thick images in larger organizations, the trade-offs are that you pay for
several applications that may not be necessary for all users, images are larger and multiple
applications can affect performance, plus the image is more difficult to maintain, and flexibility is
greatly reduced.
Thin images are the most flexible and easiest to maintain, but customizations need to happen at
deploy time, and that means that applications are packaged for a silent install and application
updates can be installed silently as well. Installation speeds can be slower compared to thick
images because each application needs to install itself one-by-one at deploy time and more
automation is required. Hybrid images include many of the components of thick images, without
necessarily wasting licensing costs, required disk space, and often the performance hit of multiple
unused applications.

Getting to Thin Images

If you currently use thick images, you might be asking, What tools are there to move to thinner
images then?
Enter deployment task sequencing. Recognizing the limits of using thick images, many people
have developed task sequencing engines to not only install applications, but also perform the
other common operating system deployment tasks in an automated way. Task sequences are
extremely important for the Computer Refresh and Computer Replacement scenarios, because
they provide the following:
1. Validate that the target hardware can install the operating system
2. Capture user files and settings
3. Invoke an installation environment like the Windows Preinstallation Environment
(Windows PE)
4. Customize the installation environment
5. Apply the operating system image
6. Apply drivers required by the hardware and connected devices
7. Apply software updates
8. Apply applications based on your selections
18

9. Join the computer to a domain

10. Reapply user files and settings
11. Configure additional attributes such as BitLocker Drive Encryption or server roles
All of this is completely automated by using deployment task sequencingyou launch it for a
minute or schedule it centrally if using System Center Configuration Manager and the rest just
happens without you needing to touch the computer. For someone new to the space, it sounds
difficult to get configured, but these are standard in-box task sequences, from the following
sources:

Microsoft Deployment Toolkit

System Center Configuration Manager (the enterprise-class console)

Heres a video of what preparing a build looks like by using the Deployment Workbench in the
Microsoft Deployment Toolkit 2010: Deployment Workbench in Microsoft Deployment Toolkit 2010
The task sequence brings together the tools we need for the deployment to end-to-end. I like to
think of everything were using in terms of music. If you think of unattend files, the User State
Migration Tool, Windows PE, applications, and drivers as instruments, then the task sequence is
like the conductor and sheet music. The end product is a symphony of automation that you have
complete control over. When everything is finished and ready for automation, you can pick how
you want to deliver your builds.
Ill conclude this section with a video that shows a fully-automated migration with user data from
Windows XP to Windows 7 that I built myself (but did not narrate) using the free tools described
previously: Windows XP to Windows 7 Migration

Automating the Migration from Windows XP

to Windows 7 End-to-End
This is the fifth and final part of the series about deployment and all of the subtasks you need to
perform. Admittedly, I set out to write this on one page, and I think with small font and a decentsized plotter, you may just be able to get this to print onto a single page, but most people wont.
For the astute readers out there, you might be thinking two things, I just read several pages of
what is essentially intro content? or Wait, Jeremy, you forgot all about drivers!
To the first question, I was on the team that originally wrote the ominous 1500 pages of desktop
deployment guidance back in the Business Desktop Deployment (BDD) 2.0 and 2.5 days. Weve
streamlined that down to a couple hundred pages, but in doing so, we left out most of the
content about project management, business cases, Microsoft Solutions Framework, and so on.
The result is the often-requested, click-here, do this guidance, but if you crave the all-up project
management best practices content, weve posted archived versions of MDT and BDD releases:

See the abbreviated version of the MDT: Microsoft Deployment Toolkit 2010

See the full versions of the BDD and MDT: Business Desktop Deployment and Microsoft
Deployment Toolkit Archive

19

If youre one of those guys who refuses to use stuff branded as Windows XP SP2 or Windows
Vista because it doesnt look current, the archives may not be for you. If you want sample project
plans and project templates for deploying an operating system and you are alright replacing an
occasional Vista with a 7, then youll be able to get value. Heres a secret: the full set of
processes for deploying Windows XP is roughly the same as for deploying Windows 7. Sure the
tools have gotten better and cover more areas and scenarios and the operating system is more
flexible for imaging and offline servicing, but the overall process is basically the same it has been
for years.
Remember the BDD Wheel?

All of this still applies today to whatever operating system you are deploying. Even though I have
the source files for this image that we built using Microsoft Office Visio in 2003, fundamentally, I
could use that original graphic today with Windows 7. That is why Ive covered most of these
areas in the first four sections.

Automating the End-to-End Migration Process

I will answer the driver question as I go into the process automation. To be honest, I want to
downplay drivers a bit, because if youve installed Windows 7 (or even Windows Vista), youll
know that in-box driver coverage is in a whole new league compared to Windows XP on current
hardware. The important items like mass storage and network drivers are pretty well-covered, as
are most other driver categories. You will need to ensure that display drivers are included in your
process and that any other OEM-specific applets you want to keep are there, and well cover that
in a minute.
Relatively soon, youll need to think about the Windows activation method that youll be using for
Windows 7. Windows XP activation usually entailed that you bake a key into your unattend
20

process. You can still do that with the revised unattend.xml by using Windows System Image
Manager and a Multiple Activation Key (MAK), or you can set up a Key Management Service
(KMS). I recommend KMS, because we dont need to worry about managing keys in the build
process. When the system is online and can reach the KMS server, it activates automaticallyno
keys to manage or potential key leaks during the deployment itself.
Read more about this in the following guidance: Volume Activation
I was using fun a bit sarcastically in previous sections, but automating processes is truly the fun
part of deployment for me. Whether you are using Microsoft Deployment Toolkit 2010 or System
Center Configuration Manager 2007 SP2 to build your deployment task sequences, you basically
need to add the same ingredients to your build:
1. An operating system
2. Applications
3. Drivers
4. Packages
Here is what that looks like in the MDT 2010 Deployment Workbench:

I actually like my sequence of ingredients better, because the operating system is the only
required piece of the four I listed. If you have a thick image with applications, and you only want
to use the task sequence to capture and reapply the user state and maybe pull Microsoft software
updates from your update server or Windows Update, you can get by with only the operating
system image. For a thin image, you can get by with importing a set of flat Windows 7 retail
source files.
The next step we take is to add our packaged applications. We need the application source files
and the silent install commands. We can also set up application dependencies. For example, if
21

Microsoft Office Communicator is dependent on Microsoft Office 2007, by choosing to install

Communicator, well automatically preclude that by the entire Office package.
Like everything else in the Deployment Workbench, you right-click the item, select New
Application and follow the wizards. When youre done, youll have something that looks like the
following screenshot:

As you can see from the CommandLine field, install command lines vary dramatically depending
on the application youre installing. Now is also the time where you want to check for drivers that
were shipped as application installer packages and youll be treating them as applications in this
case.
Now you can add normal drivers with .inf extensions to the Out-of-Box Drivers menu. Drivers
will be installed automatically by default based on their Plug and Play (PnP) IDs, or if you want
total control, you can group them by hardware make and model using Selection Profiles in
MDT 2010. After youve imported drivers into the Deployment Workbench, it will look something
like this:

If you are using a straight Windows Deployment Services environment with Windows
Server 2008 R2, we can also use the driver store in Windows Deployment Services to keep
drivers centrally on our deployment server and have them install based on PnP IDs. Likewise,
System Center Configuration Manager has a great driver store to control how drivers are
installed. The last step you can take for driver installation is to opt through the deployment task
22

sequence to pull from Windows Update for updates and drivers. Chances are, between these
approaches and an optional call to Windows Update, that even untested devices will successfully
install with most (if not all) drivers ready to go.
The last ingredient well add to our build are packages. Packages can be Cabinet (.cab) or
Microsoft Update (.msu) files. There is a mechanism to do this in the Deployment Workbench and
in Configuration Manager. When we detect language packs in MDT, well even expose them as
optional packages (as opposed to installing everything that qualifies for our operating system).
After youve added packages, youll see something like this with varying package types:

At this point, we have all of our ingredients. MDT 2010 and Configuration Manager also have vital
components like USMT and Windows PE to migrate user files and give us an installation
environment for laying down the Windows 7 image. If you want to customize Windows PE, you
can do that by using MDT 2010, however, MDT will automatically create the custom Windows PE
environment for you as part of the standard build process. I introduced task sequences as the
glue that combines all of the migration processes together, and I listed the core steps in the last
section. Making all of this easier is the fact that the standard client and server task sequences in
MDT and Configuration Manager will do essentially everything they need to do, and in many
cases, you wont need to create any custom tasks. Here is what the task sequence looks like and
everything it does:

23

Among all of the steps, there are a couple of Inject Drivers steps that allow you to either rely on
the PnP ID mechanism by default or choose a selection profile from the drop-down list as seen
previously. After youve created the task sequence and everything else is done, you can start
testing. Now you can use a file server, Windows Deployment Services, or standalone media to
deliver your Windows 7 builds. This will perform all the steps I listed in the last section, and youre
on your way to migrating Windows XP computers to Windows 7 in a highly automated way.

Tricks for More Automation

Before I finish this article, I want to cover one last idea. When you get everything working by
using MDT 2010, the first thing youll probably want to do is remove some of the Lite Touch
Deployment wizard screens like Ive done in following video: Windows 7 Deployment Tools Part 4.
Here is the trick. You can modify a file called customsettings.ini in your MDT 2010 distribution
share. The file in located in the Deploy\Control folder. By using this file, you can eliminate one,
many, or all of the wizard screens by prepopulating the fields that you would otherwise have to fill
in, or you can skip screens and use the defaults in other cases. A completely automated
customsettings.ini file looks like the following screenshot:
24

Ive also added mandatory applications to control which applications are part of this build. By
using a similar customsettings.ini file with the standard client refresh task sequence, you will
automate all migration steps.
With that, you have the basis to start automating migration from Windows XP to Windows 7. In
less than 20 pages, I have covered a lot of ground, and Ive been pointing along the way for more
guidance per task. If youve gotten value out of this series, I would encourage you to:

Subscribe to our blog: Deployment Guys Blog

Keep checking back to the TechNet site for the latest content: Springboard Series for
Windows 7 on TechNet

25