Avant-propos

Microsoft vient de sortir Windows 7, le nouveau système d’exploitation client que

nous attendions tous, celui qui nous a déjà fait oublier Windows Vista. Cependant
ce dernier a apporté une révolution majeure dans les technologies de déploiement
Microsoft et cela n’a pas été oublié par les professionnels de l’informatique, techniciens,
administrateurs systèmes ou décideurs. Microsoft a continué d’innover avec Win-
dows 7 et cela sur tous les plans (mobilité, sécurité, fiabilité, simplicité, administration,
etc.) en apportant de nouvelles expériences numériques et de nouveaux usages aux
utilisateurs finaux.
La sortie de Windows 7 ne fut pas un événement anodin, et certains partenaires
ont même été intégrés dans des programmes d’adoption appelés programmes TAP
(Technical Adoption Program) chez Microsoft. Windows 7 est un des produits qui a
été le plus bêta testé dans le monde. Les entreprises disposant d’un parc Windows 2000,
XP ou Vista envisagent prochainement de migrer vers le dernier système d’exploitation
de Microsoft. Cependant, ce projet de migration est complexe. C’est pourquoi il faut
se poser les bonnes questions pendant la phase de planification : « Nos matériels
et nos applications sont-ils compatibles vers Windows 7 ? », « Comment pouvons-
nous migrer les données des profils utilisateurs ? » ou encore « Quels sont les outils
disponibles pour déployer Windows 7 ? ». C’est ce type de questions que nous avons
traité dans cet ouvrage.
De plus il ne faut pas oublier que le support étendu de Windows 2000 se termine
le 30 juin 2010. Il en est de même pour Windows XP qui verra son support étendu
s’arrêter le 1er avril 2014. Cela signifie que les différents éditeurs de logiciels auront
largement abandonné leur support à ces systèmes d’exploitation bien avant ces dates
afin de se concentrer sur Windows 7. Cela va arriver rapidement et il faut noter qu’une
migration complète d’un parc est parfois complexe, coûteuse et peut prendre plusieurs
mois. Il est donc fortement conseillé de ne pas attendre ces fins de vie de cycle et
prévoir cette migration avant 2012.
D’après le Gartner Group, il ne faut pas non plus attendre le Service Pack 1
de Windows 7 attendu fin 2010 pour débuter les tests de compatibilité applicative
et de déploiement. Étant donné qu’un plan de migration d’un nouveau système
d’exploitation en entreprise demande généralement entre 6 et 18 mois, il faut anticiper
XVIII Windows 7 : déploiement et migration

son étude et prévoir le budget nécessaire. Le coût de migration d’un poste Windows
XP vers Windows 7 est estimé entre 1000 et 2000$ contre un coût estimé entre 339
et 510 $ pour la migration d’un poste Windows Vista vers Windows 7.
C’est pour toutes ces raisons qu’il est important de bien appréhender une migration
vers Windows 7 afin que ce projet soit une réussite au sein de votre entreprise. Nous
souhaitons ainsi vous accompagner lors de cette période à travers des méthodologies,
des explications, des pas à pas, des astuces et du vécu autour des différents outils
Microsoft permettant de répondre efficacement à une migration vers Windows 7.

À qui ce livre s’adresse-t-il ?

Ce livre s’adresse à toutes les personnes qui peuvent, de près ou de loin, être impliquées
dans un projet de déploiement et de migration vers Windows 7. Que vous soyez élève
ingénieur en informatique, administrateur système, consultant Microsoft, architecte
infrastructure ou que vous fassiez partie du service informatique d’une entreprise –
qu’il s’agisse d’une TPE, PME ou d’une grosse structure – ce livre est fait pour vous.
Si vous préparez des certifications Microsoft traitant des problématiques de
déploiement, ce livre vous apportera beaucoup car les connaissances requises y sont
largement présentées. Voici la liste des certifications sur lesquelles vous aurez beaucoup
de facilité après la lecture de notre ouvrage :
• 70-622 Pro : Microsoft Desktop Support – ENTERPRISE
• 70-624 TS : Deploying and Maintaining Windows Vista Client and 2007
Microsoft Office System Desktops
• 70-635 TS : Deploying Microsoft Operating Systems and Applications Using
Microsoft Deployment Toolkit 2008
• 70-401 TS : Microsoft System Center Configuration Manager 2007, Configuring
• Exam 70-686 Pro : Windows 7, Enterprise Desktop Administrator

Niveau de connaissances préalable

Le niveau de connaissances préalable est relativement élémentaire car nous avons
tenté d’être le plus clair dans nos explications pour vous permettre d’acquérir les
connaissances nécessaires pour vos projets de déploiement et de migration.
Ce livre est donc abordable par toutes personnes ayant un niveau de connaissance
réduit sur les fondements de l’informatique et sur les produits entreprises de Microsoft.
Vous devez simplement être en mesure de :
• mettre en œuvre et d’administrer un environnement Active Directory, DNS et
DHCP ;
• savoir utiliser l’invite de commandes Microsoft ;
• connaître en profondeur les systèmes d’exploitation client Windows.
Avant-propos XIX

Comment ce livre est-il structuré ?

Nous avons cherché à garder une cohérence à travers tout le livre pour que vous
puissiez avancer progressivement et être dès les premiers chapitres capables d’œuvrer
et de tester les outils après avoir acquis une bonne compréhension du sujet. Nous
passons en revue les différents niveaux technologiques de déploiement et cela de façon
croissante.
Nous commencerons au chapitre 1 par expliquer l’évolution des méthodes de
déploiement, en introduisant toutes les notions essentielles aux outils et méthodes
de déploiement Microsoft depuis l’arrivée du PC jusqu’à Windows Vista. Nous
terminerons en identifiant les besoins d’aujourd’hui tel que le multilinguisme et en
expliquant les méthodes de déploiement (LTI/ZTI).
Le chapitre 2 commence par la base de tout projet de déploiement Microsoft,
à savoir l’utilisation et la maîtrise du WAIK pour Windows 7. Nous verrons alors
les différents outils présents dans ce kit, ce qui vous permettra d’acquérir tout le
vocabulaire et la technique relatifs au déploiement Microsoft. Cela vous permettra
également d’attaquer sereinement le chapitre 3 qui ne sera qu’une mise en pratique
des scénarios les plus classiques de déploiement, des scénarios qui sont utilisés
quotidiennement par les IT Pro. Nous parlerons ensuite de WDS, le serveur de
déploiement par le réseau (PXE), qui nous permettra d’industrialiser à petite ou à
grande échelle le déploiement de Windows 7.
Le chapitre 5 est un des chapitres les plus importants car il aborde des problé-
matiques du déploiement et surtout des éléments techniques qu’il faut prendre en
considération avant tout projet de migration. Nous parlerons alors d’inventaires
matériels et applicatifs pour identifier les problèmes de compatibilité applicative et
verrons comment il est possible de les résoudre à travers des méthodes et des outils.
Ce chapitre correspondra à une partie importante de votre plan de migration.
Enfin dans les chapitres 6 à 11, nous présenterons MDT (Microsoft Deployment
Toolkit) 2010 et SCCM (System Center Configuration Manager) 2007, les deux
produits qui seront utilisés massivement par les entreprises pour déployer les systèmes
d’exploitation et en particulier Windows 7. Nous verrons en détail ces produits et vous
pourrez commencer par MDT, qui est gratuit, pour mettre en place des scénarios de
déploiement intéressants. Ensuite, vous apprendrez que SCCM apporte une plus-value
considérable à du déploiement Microsoft (OS, applications, etc.) et qu’il est encore
plus intéressant de le coupler à MDT pour la migration vers Windows 7.

Systèmes nécessaires
Idéalement il faut se munir d’une machine assez puissante où vous pourrez installer
Windows Server 2008 R2 accompagné du rôle Hyper-V (au minimum 4 Go de RAM)
pour faire fonctionner des machines virtuelles. Vous pourrez alors avoir un vrai
laboratoire pour effectuer les différents tests et cas pratiques du livre.
Cependant, vous pouvez également vous munir de :
• deux machines physiques (ou virtuelles) ;
– la première machine hébergeant toute la partie serveur (Active Directory,
DNS, DHCP, WDS et également MDT, SQL Server et SCCM). Si vous
XX Windows 7 : déploiement et migration

avez la possibilité de séparer les rôles AD, DNS, DHCP de la partie

WDS/MDT/SCCM sur une autre machine, cela sera parfait ;
– une machine cliente servant de test pour le déploiement. Cette machine
pourra être sous Windows 2000 SP4, Windows XP SP2 ou supérieur,
Windows Vista SP1 ou supérieur afin d’effectuer des tests de migration de ce
poste vers Windows 7.
• d’un équipement réseau de type concentrateur (Hub) ou commutateur
(Switch) ;
• de câbles réseaux Ethernet pour connecter les différentes machines ;
• d’un support média (clef UB, DVD, disque dur USB) afin de stocker des données
nécessaires à l’accomplissement de certaines parties du livre ;
• d’une connexion Internet pour télécharger l’ensemble des outils nécessaires.

Tous les outils traités dans ce livre sont disponibles sur le centre de téléchargement
de Microsoft. Les systèmes d’exploitation (Windows Server 2008 R2 et Windows 7)
sont disponibles sous forme de machines virtuelles VHD et peuvent donc être utilisés
dans Virtual PC, Hyper-V ou en VHD Boot. Les produits payants, c’est-à-dire SCCM
et SQL Server (hormis la version Express) sont disponibles en version d’évaluation.

Remerciements
Avant que vous vous lanciez dans la lecture de plus de 350 pages techniques liées
aux technologies de déploiement Microsoft, nous tenions à remercier les personnes
qui ont contribué, par leur expertise et leur temps précieux, à la réalisation de cet
ouvrage. Nous remercions tout d’abord nos mères respectives, Jacqueline Duchêne et
Annie Bories, pour avoir eu le courage de passer des heures à corriger les premières
versions de nos chapitres. Par ailleurs, le sujet de cet ouvrage est un domaine qui leur
est totalement inconnu et obscure. Merci infiniment !
Nous souhaitons ensuite remercier profondément nos deux relecteurs, Aurélien
Bonnin et David Sebban, pour leurs corrections bénéfiques. Leur expérience du terrain
a apporté une réelle plus-value à cet ouvrage, sans parler de leur niveau technique qui
les place parmi les meilleurs consultants sur les technologies de déploiement Microsoft.
Aurélien Bonnin est diplômé de l’ESI SUPINFO, il a débuté sa carrière en
2006 en tant qu’ingénieur d’études puis consultant spécialisé sur les technologies
Microsoft System Center. Après avoir fait de SCCM sa technologie de prédilection,
il a assuré la fonction de Leader Technique Télédistribution & Inventaire dès 2008
pour une société de services. En 2010, il a rejoint la société vNext comme Service
Line Manager au sein du département Core Infrastructure. Sa mission principale est
de développer l’activité autour de la gestion des postes de travail. Le dévouement
d’Aurélien autour des communautés techniques liées aux technologies System Center
l’a amené à être nommé Microsoft MVP (Most Valuable Professional) SCCM. Son
blog : http://myitforum.com/cs2/blogs/abonnin/
David Sebban est diplômé de l’EFREI, il a commencé à travailler sur les solutions
de déploiement lors de son stage de fin d’études dans l’équipe avant-vente de Microsoft.
Avant-propos XXI

Il débute sa carrière de consultant chez un partenaire et rentre chez Microsoft en 2005

en tant que consultant spécialisé dans le déploiement de Windows. David devient
le référent technique sur BDD 2.5, BDD 2007, MDT 2008 et 2010. Durant quatre
ans, il va participer à tous les plus gros projets de déploiement de poste de travail
réalisés par Microsoft et va développer des liens forts avec l’équipe MDT de Microsoft
Corporation à Redmond. Il participe notamment aux programmes d’adoption rapide
(TAP) de Windows Vista et de Windows 7. Depuis 2009, David Sebban a rejoint
Nelite, une société partenaire de Microsoft afin de développer le secteur du conseil
autour du poste de travail. Son blog : http://blogs.nelite.com/blogs/dsebban/
Nous remercions chaleureusement notre préfacier, Laurent Ellerbach, qui a su
introduire avec brio notre ouvrage. Il a apporté un œil nouveau et différent à ce projet.
Laurent Ellerbach dirige actuellement l’équipe marketing de la division plate-
forme et écosystème chez Microsoft. Cela fait 13 ans qu’il est entré chez Microsoft.
Il a notamment créé les relations avec l’enseignement supérieur, donner accès
gratuitement aux produits Microsoft à des milliers d’étudiants en France, co-créé
Imagine Cup et les Microsoft Student Partner. Il y a 4 ans, il a également co-créé les
Microsoft TechDays, multiplié par dix les trafics sur les sites Web MSDN et TechNet.
Enfin, nous tenions à remercier l’équipe de chez DUNOD, qui a cru en notre projet
et nous a apporté tout l’encadrement nécessaire à la réalisation de cet ouvrage.
 1
L’évolution des méthodes
de déploiement

Objectifs
L’objectif de ce chapitre est d’introduire toutes les notions essentielles aux outils et
méthodes de déploiement Microsoft. Pour cela, nous retracerons dans un premier
temps l’évolution des méthodes de déploiement depuis l’arrivée du PC jusqu’à
Windows Vista, puis nous terminerons par des explications sur les scénarios d’usage
des méthodes de déploiement.

1.1 AVANT WINDOWS VISTA

C’est avec l’arrivée du PC (Personal Computer) que le concept du déploiement a
fait son apparition en entreprise : chaque PC est équipé de son propre OS (Operating
System) et donc d’une configuration personnalisée (pilotes, applications, etc.) pour
chaque collaborateur. C’est à partir de ce moment que les entreprises ont dû faire face
à de nouvelles problématiques et à de nouveaux coûts.

1.1.1 Les premiers outils d’automatisation

À cette époque, la solution de Microsoft pour le déploiement était l’utilisation
d’un fichier de réponses. Cela a réellement démarré avec Windows 95 car il était
possible d’effectuer une installation à distance à partir d’un serveur de distribution qui
partageait les sources d’installation. Il y avait deux outils pour Windows 95 permettant
2 Chapitre 1. L’évolution des méthodes de déploiement

de créer le fichier de réponses. Le premier, NetSetup, n’était pas simple et beaucoup

moins complet que Batch, le second. Une nouvelle version beaucoup plus riche a été
développée pour Windows 98, appelée Microsoft Batch 98. Il fallait donc démarrer
sur une disquette MS-DOS, puis exécuter le fichier SETUP.EXE suivi du fichier de
réponses (Msbatch.inf) créé préalablement. Généralement Batch 98 était couplé à
l’utilisation de l’outil InfInst.exe, ce qui permettait d’ajouter des pilotes d’installation
non présents par défaut dans le média d’installation de Windows 98. Notez que
plusieurs autres fichiers de réponses pouvaient être requis pour l’automatisation de
certaines parties de l’installation.

Figure 1.1 — Microsoft Batch 98 pour la création de fichiers de réponses

Cela signifie qu’avec Windows 95, il s’agissait d’une méthode classique d’instal-
lation de l’OS et non d’une méthode de duplication d’une installation existante
avec les applications, pilotes, etc. Ce n’est qu’avec Windows 98 et le fameux
Windows NT4, qui d’ailleurs avait récupéré toute l’interface de Windows 95, que les
méthodes de clonage ont vu le jour. Ces installations n’étaient pas encore entièrement
automatisées.
Le principe de clonage était de préparer une machine cible, d’y installer Windows,
ainsi que les pilotes et les applications, et enfin d’effectuer les personnalisations de
son choix. Ensuite, le technicien préparait le système d’exploitation destiné à être
cloné, c’est-à-dire qu’il obtenait une copie du contenu du disque dur, appelée dans le
jargon Microsoft, une image système. Il déployait ensuite cette image sur les postes
de travail ou serveurs en utilisant des outils tiers. Le seul moyen pour que le clonage
fonctionne avec NT4 était d’avoir des machines sensiblement identiques (carte mère,
mémoire, disque dur, etc.), car ce dernier n’était pas « Plug-and-Play ». L’énumération
1.1 Avant Windows Vista 3

et l’installation des périphériques « Plug-and-Play » sous NT4 s’effectuaient en début

d’installation et non à la fin, lors de la phase du « Mini-Setup », qui n’existait pas à ce
moment. Cette phase du « Mini-Setup » est celle que nous connaissons aujourd’hui
(OOBE), qui correspond à l’assistant de fin d’installation de Windows (nom de
l’ordinateur, fuseaux horaires, nom d’utilisateur, etc.). Il fallait donc avoir autant
d’images que de types d’ordinateur ! Le déploiement et par conséquent la migration
vers Windows 2000 et 2003 étaient un sujet délicat.
La deuxième contrainte majeure de l’époque était que Windows NT4 avait un SID
(Computer Security Identifier) généré au début de l’installation. Le SID est un numéro
unique permettant à un ordinateur ou à un contrôleur de domaine d’identifier votre
ordinateur sur le réseau. L’image créée pour le déploiement embarque donc un SID. Si
celui-ci n’est pas modifié, les conséquences pour le parc informatique sont très lourdes,
en effet l’intégrité et la sécurité du Système d’Information sont touchées, sans parler
de toutes les conséquences et des nombreux problèmes et bugs. Au départ, Microsoft
ne proposait aucun outil pour changer le SID et à la demande des communautés
Microsoft, plusieurs entreprises ont développé des outils permettant sa modification.
Le premier fut Ghost Walker de chez Symantec. NewSID de chez SysInternals a
ensuite fait son apparition pour régénérer un SID. Il fallait exécuter l’un de ces outils
après l’installation de l’image et avant la jonction de l’ordinateur au domaine. Il était
difficile d’automatiser toutes ces étapes mais cela pouvait se concrétiser en utilisant des
scripts. Il fallait donc utiliser dans ces scripts un outil de génération de SID, puis l’outil
NETDOM de Microsoft pour automatiser la modification du nom de l’ordinateur et
sa jointure au domaine. Quand on y pense, c’était tout de même bien compliqué.
Pour revenir à l’automatisation des déploiements, c’est-à-dire à l’utilisation d’une
méthode de clonage et d’un fichier de réponses, il y a eu l’outil Image Preparation
appelé Preptool.exe pour Windows 98 qu’il fallait toujours coupler à Batch 98 /
InfInst.exe pour la création d’un ou des fichiers de réponses. Ces outils étaient déjà
disponibles sur le média d’installation de Windows 98. Peu de temps après, Microsoft
a sorti la première version de l’outil SYSPREP (System Preparation) pour Windows
NT4, soit le successeur de PrepTool. SYSPREP est venu révolutionner les mœurs et a
survécu à tous les âges. Celui-ci a vraiment facilité la vie des techniciens en proposant
la génération du SID lors de la phase du « Mini-Setup » et cela sans passer par un
outil annexe. Le SYSPREP a donc permis le nommage des machines, la jonction
de la machine au domaine, l’installation des pilotes tels que les imprimantes (grâce
à la célèbre variable « OemPnPDriversPath ») et ainsi de suite à travers le fichier
de réponse « sysprep.inf ». Il existait d’autres fichiers de réponses qui pouvaient
être utilisés pour différents besoins ou différentes méthodes de déploiement tels que
« Winbom.ini », « Oobeinfo.ini », « oeminfo.ini » ou encore « unattend.txt » qu’il
fallait renommer en « winnt.sif » pour une installation à partir d’un CD. Il était déjà
donc plus facile d’automatiser un déploiement, c’était tout simplement magique. À
l’époque de Windows NT4, l’outil SYSPREP devait être téléchargé sur Internet sous
le nom du package appelé « WIN_DEPLOY.EXE », où se trouvait également l’outil
PrepTool pour Windows 98. SYSPREP est donc arrivé avec Windows NT4 et non
avec Windows 2000, contrairement à ce que de nombreuses personnes pensent.
 4 Chapitre 1. L’évolution des méthodes de déploiement

1.1.2 Le déploiement PXE

À ce moment-là, Microsoft ne possédait pas encore d’outils de clonage. Il fallait donc
utiliser une solution annexe comme par exemple Deploycenter ou DriveImage de
PowerQuest, RapidDeploy d’Altiris ou encore Ghost de Symantec, ce dernier étant
d’ailleurs encore très utilisé dans de nombreuses sociétés. Le technicien utilisait donc
différents outils Microsoft pour préparer son image puis se servait d’un outil tiers pour
cloner le disque dur de l’ordinateur de référence. Il fallait ensuite distribuer cette
image sur les ordinateurs du parc informatique. La méthode la plus optimale était
de passer par le réseau. Pour cela il y avait la technologie PXE (Pre-boot eXecution
Environment), créée par Intel, qui est un environnement de démarrage par le réseau.
Pour exploiter cette technologie Microsoft avait créé RIS (Remote Installation
Service), qui était non seulement un composant optionnel dans Windows 2000
mais aussi le premier outil de clonage de la maison. Il fallait configurer l’ordre du
démarrage des ordinateurs clients dans le BIOS afin que le démarrage PXE soit en
première position. Le serveur RIS nécessitait la présence d’un serveur DNS, d’un
serveur DHCP et d’une infrastructure Active Directory. Celui-ci se reposait donc sur
plusieurs protocoles réseaux comme IP, UDP, TFTP mais également sur les concepts
de GUID (Global Unique Identifier).

Figure 1.2 — Connexion d’un client au serveur RIS

Lors du démarrage de l’ordinateur, il envoyait une requête BOOTP sur le réseau

afin de contacter un serveur DHCP pour l’attribution d’une adresse IP. Le serveur
DNS communiquait ensuite l’adresse IP du serveur RIS qui, après l’appui sur la touche
F12, fournissait au client le menu des images de démarrage (appelé « OS Chooser »)
présentes sur le serveur RIS. Dès que l’environnement de démarrage était chargé,
l’utilisateur devait s’authentifier (et fournir son GUID) sur le contrôleur de domaine
puis sélectionner une image d’installation de Windows.
Plusieurs produits tiers se sont reposés sur le serveur RIS tel que Ghost, qui a su très
bien l’exploiter. Il n’est pas étonnant de le voir encore présent dans de nombreuses
entreprises. Il faut se souvenir qu’à l’époque toutes les cartes réseaux des ordinateurs
n’étaient pas forcément compatibles PXE. Mais Microsoft fournissait un outil de
création de disquettes de démarrage (RBFG.exe), qui permettait de contacter le
serveur RIS. Il y a eu plusieurs versions de RIS permettant le déploiement de Windows
98, 2000, XP et de Windows Server 2003. Celui-ci était, comme dit précédemment, la
première solution de clonage de Microsoft. Il y avait donc deux modes de déploiement,
la méthode classique d’installation à distance basée sur les sources d’installation de
Windows (RISetup) et la méthode de clonage (RIPrep).
1.1 Avant Windows Vista 5

Figure 1.3 — Création d’une image RIPrep

Les images RIPrep étaient donc beaucoup plus rapides à déployer. Cependant les
performances et les contraintes (une seule partition, tailles des disques durs distants,
pas de support du multicast, etc.) de l’outil laissaient à désirer ; ce qui n’a pas fait de
RIS un réel concurrent de la solution Ghost de Symantec. Le réel intérêt des images
RIPrep était qu’elles permettaient de déployer une image sur un ordinateur dont la
configuration matérielle était différente, à l’exception de la HAL que nous aborderons
ultérieurement. Les produits concurrents de l’époque ne le supportaient pas.

1.1.3 L’arrivée de Windows 2000

L’arrivée de Windows 2000 fut une révolution dans le monde du déploiement Micro-
soft. Pour la première fois nous avions un système d’exploitation serveur qui supportait
le « Plug-and-Play ». Le SYSPREP a d’ailleurs été intégré en 1999 dans chaque
média d’installation de Windows 2000 sous le nom du package « DEPLOY.CAB »
dans le dossier « SUPPORTS\Tools ». Même si le support du « Plug-and-Play » a
permis le déploiement d’une image sur un ordinateur différent de celui utilisé comme
ordinateur de référence, la version 1.0 du SYSPREP ne permettait pas la gestion
des contrôleurs de stockage de masse. Si vous aviez un disque dur (SCSI, etc.) qui
n’était pas pris en charge par Windows 2000, il fallait donc faire une image pour
chaque configuration. Il était possible de déployer la même image sur des ordinateurs
possédant des cartes audio, des cartes vidéo et des périphériques multimédias différents.
Il a fallu attendre la version 1.1 du SYSPREP pour supporter les contrôleurs de
stockage de masse. Cela a permis de réduire le nombre d’images. Il fallait ajouter la
section « [SysprepMassStorage] » dans « sysprep.inf », fichier de réponses qui pouvait
être créé avec l’outil Setup Manager (setupmgr.exe) disponible dans le package
« DEPLOY.CAB ». Le technicien exécutait l’outil SYSPREP (en version 1.1) avant
le clonage de l’ordinateur de référence afin de recréer la base de données des pilotes
« Plug-and-Play » lors du déploiement. Windows 2000 configurait automatiquement
les périphériques matériels si les pilotes étaient présents dans l’image.
6 Chapitre 1. L’évolution des méthodes de déploiement

La gestion de l’ensemble des périphériques pour le déploiement n’était plus un

problème. Cependant il restait la gestion des HAL (Hardware Abstraction Layer),
un élément sensible qui devait rester identique entre l’ordinateur de référence et les
ordinateurs cibles. Pour information, la HAL est un driver au niveau Kernel (noyau
Windows) qui fournit une interface entre le système d’exploitation et l’architecture
physique de la machine (processeur, architecture des bus I/O, etc.). Elle présente trois
composants : la DLL (hal.dll), l’exécutable de l’image du noyau de l’OS (ntoskrnl.exe)
et l’extension d’adresse physique (Physical Address Extension ou PAE). Il existe plusieurs
types de couche HAL, que Windows peut utiliser tels que Standard PC, Advanced
Configuration and Power Interface (ACPI) PC, ACPI Uniprocessor PC, ACPI
Multiprocessor PC, MPS Uniprocessor PC et MPS Multiprocessor PC.
La HAL permet la portabilité du système d’exploitation Windows (ou autres
systèmes utilisant une HAL) sur plusieurs types de processeur. Il était donc par exemple
très difficile à l’époque de déployer une image capturée à partir d’un ordinateur muni
d’un unique processeur, sur un ordinateur qui en disposait plusieurs. La HAL pouvait
être sélectionnée manuellement au début de l’installation de l’OS, en utilisant la
touche F5 au moment où l’assistant nous proposait d’appuyer sur la touche F6, pour
ajouter des pilotes de contrôleurs de stockage de masse. Nous pouvons également la
changer en passant par le gestionnaire de périphérique de Windows.

Figure 1.4 — Gestionnaire de périphérique sous Windows 7

Il n’y avait que trois méthodes possibles utilisant SYSPREP permettant de déployer
une image sur des ordinateurs dotés d’HAL différentes. La première était la plus simple
et s’effectuait par le fichier de réponses sysprep.inf. Il fallait renseigner la variable
« UpdateHAL » dans la section [Unattended]. La seconde était l’écrasement de la
HAL par celle qui correspondait le mieux à votre architecture (disponible sur le CD
d’installation de Windows). La dernière méthode et certainement la plus efficace était
de modifier le fichier « boot.ini ». Cela permettait, lors du démarrage, de sélectionner
la HAL de son choix, ce qui était fort pratique du fait qu’il suffisait de redémarrer en cas
de HAL non-supportée. Ces deux dernières méthodes étaient vraiment compliquées à
mettre en place mais tellement simples d’utilisation une fois implémentées.
L’époque Windows 2000 a également beaucoup fait parler de SMS (System Mana-
gement Service) 2.0, le produit de référence pour la migration de Windows 95 ou Win-
dows NT4 ou Windows 98 vers Windows 2000 (cf. http://technet.microsoft.com/en-
us/library/cc750182.aspx). Cela peut être surprenant mais il était déjà possible de
migrer les systèmes d’exploitation NT comme par exemple Windows 95 vers Windows
98 en utilisant le fichier « Apps.inf ».
1.1 Avant Windows Vista 7

1.1.4 L’arrivée de Windows XP

Windows XP a ensuite vu le jour et les cas de migration étaient toujours d’actualité.
Les entreprises ont toujours besoin de nouveaux OS supportant les nouvelles configu-
rations matérielles, pour apporter plus de performance. Cet OS a également apporté
de nombreuses technologies dont en particulier WinPE (Windows Preinstallation
Environment) 1.0. C’est une version allégée de Windows qui est venu remplacer
MS-DOS. On peut appeler WinPE, l’OS minimal (32 ou 64 bits). Il permet de
préparer un ordinateur à l’installation de Windows. À cette époque, WinPE n’était
distribué qu’aux constructeurs et aux entreprises ayant souscrit un contrat de licence
en volume sur Windows XP ou sur Windows Server 2003 (WinPE 1.2). Il n’était donc
pas très connu et était fourni dans un kit d’outils appelé OPK (OEM Pre-installation
Kit). C’est pourquoi la majorité des techniciens utilisaient des outils tiers, des outils
de récupération du système basés sur WinPE tels que l’outil ERD Commander de
WinInternals ou encore le célèbre BartPE. Ensuite il y a eu Windows PE 2004 (1.5)
avec Windows XP SP2 et Windows PE 2005 (1.6) avec Windows Server 2003 SP1.
Ces versions ont permis le support du WMI, la détection du « Plug-and-Play » ou
l’ajout de pilotes (réseaux, disques, etc.) dans WinPE grâce à l’outil « Drvinst.exe ».
L’arrivée de Windows XP a également soulevé la problématique de la migration des
profils utilisateurs en apportant deux outils. Même si à l’époque de Windows 95, NT4
et Windows 98, la migration des données des utilisateurs était d’actualité du fait de la
création de scripts complexes ; Windows XP a été le premier OS sur lequel Microsoft
a poussé les entreprises à utiliser deux outils de taille. Le premier était l’assistant de
transfert de paramètres et de fichiers (FASTWIZ.EXE), dédié aux particuliers, TPE et
petites PME ; cet outil permettait de se passer de l’assistance du service informatique.
Le second était l’USMT (UserState Migration Tool), composé de deux exécutables
(scanstate.exe et loadstate.exe) et dédié à du déploiement à grande échelle de façon
automatisée. La version utilisée d’USMT pour le déploiement de Windows 2000 et
Windows XP était la version 2.6. Nous pouvions donc migrer les profils utilisateurs
d’un Windows 95, 98, NT4, Windows 2000 et Windows XP. La version 2.6.1 a permis
le support du 64 bits.

Figure 1.5 — L’assistant Transfert de fichiers de paramètres de Windows XP

8 Chapitre 1. L’évolution des méthodes de déploiement

USMT existe toujours et nous l’aborderons en détail dans les chapitres suivants.
Un autre point sur lequel la migration était délicate était la compatibilité des
applications sur Windows XP. Il y a eu beaucoup de bruits à ce sujet, voire peut-être
plus qu’au moment de la sortie de Windows Vista. Il y avait premièrement l’assistant
de compatibilité qui était simple mais qui ne permettait pas de résoudre des problèmes
plus complexes. Puis il y avait l’outil ACT (Application Compatibility Toolkit),
en versions 2.5 et 2.6, qui permettait à l’époque de diagnostiquer et de résoudre
les problèmes de compatibilité applicative pour les déploiements de Windows 2000
et Windows XP. La version 3.0 avait suivi pour supporter Windows Server 2003 et
également inclure des fonctionnalités pour inventorier les applications présentes sur
les postes clients. Enfin n’oublions pas que Windows XP avait apporté une nouvelle
version du SYSPREP mais il avait fallu attendre le SP2 pour obtenir un gain de
fonctionnalités. Le SYSPREP était non seulement disponible en téléchargement
pour ses dernières versions, mais aussi disponible dans le package « DEPLOY.CAB »
où était stocké le nouveau « setupmgr.exe », permettant la création des fichiers de
réponses.

Figure 1.6 — Assistant Gestion d’installation

Comme celui utilisé pour Windows 2000, cet outil permettait de créer un fichier
de réponses pour l’une des trois méthodes classiques de déploiement Windows
(l’installation sans assistance, l’installation SYSPREP et l’installation via RIS). À
l’aide d’outils de Microsoft et/ou des produits tiers, le déploiement devenait réellement
entièrement automatisé. Nombre d’entre nous se souviennent des méthodes utilisées
pour les installations entièrement automatisées. Nous pouvions utiliser la technique
du « slipstreaming » pour intégrer les Services Packs et certaines mises à jour le
supportant dans les sources d’installation de Windows (commutateur /INTEGRATE).
Nous passions plusieurs heures à rechercher les commutateurs d’installation silencieuse
pour les packages MSI, WISE, NSIS ou encore InstallShield. Il y avait la méthode
traditionnelle d’installation des applications grâce au fichier « svcpack.inf » qui
s’effectuait en GUI (Graphical User Interface) à la fin de l’installation de l’OS. Il
fallait souvent jouer avec des fichiers de réponses pour l’installation d’application
telle qu’Office 2003, qui nécessitait pour cela l’ORK (Office Ressource Kit) 2003
ou encore Internet Explorer, disposant de son propre outil IEAK (Internet Explorer
Administration Kit).
1.1 Avant Windows Vista 9

Figure 1.7 — L’arborescence $OEM$

Tout le monde se souvient de l’arborescence « $OEM$ » qui permettait de stocker

les fichiers (pilotes, applications, etc.) et d’effectuer automatiquement des opérations
de copies vers un disque, vers le bureau de l’utilisateur, vers le dossier par défaut des
fonds d’écran ou des thèmes Windows. En personnalisation, il était même possible de
remanier toute l’apparence des fenêtres d’installation.

1.1.5 Les nouvelles solutions pour Windows XP et Windows Server 2003

Un accélérateur de solution Microsoft avait vu le jour à ce moment, permettant de
fournir de bout en bout des guides pour la planification, la construction, les tests
et le déploiement des éditions de Windows XP et d’Office 2003. Ce n’est autre que
BDD (Business Desktop Deployment) que nous connaissons aujourd’hui sous le
nom de MDT (Microsoft Deployment Toolkit) qui sera traité en détail dans le
chapitre 6. La version 1.0 est sortie en 2003 à la conférence IT Forum et était déjà
basée sur WinPE. Suite aux retours des premiers testeurs, la version 2.0 est arrivée à
la conférence IT Forum de 2004 en proposant une version Standard et une version
Enterprise se reposant sur AD, RIS, SYSPREP, SQL Server 2000 et le fameux SMS
2003 pour les fonctionnalités d’inventaire et de distribution d’applications. C’est
à ce moment précis que les concepts de LTI (Lite Touch Installation) et de ZTI
(Zero Touch Installation) ont pris tout leur sens, que nous aborderons à la fin de
ce chapitre. BDD a introduit la volonté de regrouper les différents outils (USMT,
ACT) au sein de sa solution. C’était un réel Framework de scripts prêt à l’emploi pour
les administrateurs, sans parler de toute la méthodologie basée sur MSF (Microsoft
Solutions Framework) et MOF (Microsoft Operations Framework), tout deux basés
sur ITIL (IT Infrastructure Library). La version 2.5 a suivi, proposant de nouvelles
fonctionnalités, tel que le monitoring en temps réel du déploiement à travers MOM
10 Chapitre 1. L’évolution des méthodes de déploiement

(Microsoft Operations Manager) 2005. Peu de temps après, est sorti le Feature Pack
OSD (Operating System Deployment) pour SMS 2003 SP1 sur lequel BDD 2.5
s’appuyait. C’était une grande évolution avec la possibilité d’intégrer nativement
USMT dans le déploiement, de personnaliser le WinPE, et introduisant pour la
première fois le format WIM (Windows Imaging) en version 0.9 et la méthode de
déploiement que nous connaissons dès à présent avec SCCM.

Figure 1.8 — La marguerite de BDD 2.5

Windows Server 2003 avait introduit une nouvelle technologie de déploiement

d’OS appelée ADS (Automated Deployment Services). ADS était prévue et opti-
misée pour le déploiement de serveurs uniquement, à savoir Windows 2000 et toutes
les versions 32 bits de Windows Server 2003. Il était également possible de déployer
Windows XP avec ADS mais cela n’était pas supporté par Microsoft. Cela signifie
qu’à l’arrivée de Windows Server 2003, les entreprises avaient le choix d’utiliser
RIS ou/et ADS pour le déploiement d’OS sans l’utilisation d’outils complémentaires
(SMS/BDD). La force d’ADS était caractérisée par le fait qu’il supportait le multicast,
ainsi que les différents systèmes de fichiers (FAT, FAT32, NTFS) et cela sur plusieurs
volumes. Il était basé sur des séquences de tâches et ne nécessitait aucune infrastructure
AD pour fonctionner. Le lancement du déploiement avec RIS était activé par
l’administrateur et non par l’utilisateur. Ces technologies n’ont pas réellement changé
les mœurs par rapport à l’utilisation antérieure des IT. Seule l’utilisation de RIS
comme serveur de déploiement PXE était très utilisée. Le Service Pack 2 de Windows
Server 2003 a d’ailleurs introduit le successeur de RIS, WDS (Windows Deployment
Services), que nous verrons en profondeur dans le chapitre 4. Ce dernier a permis de
gagner en automatisation.
L’un des derniers outils dont nous n’avons pas encore parlé est SUS (Software
Update Services), qui permettait d’avoir une gestion centralisée des mises à jour
1.2 La naissance du WAIK avec Vista 11

Windows sur l’ensemble du parc informatique. Cela évitait à tous les clients de
télécharger les mises à jour. Il a été remplacé par WSUS (Windows Software Update
Services), qui est utilisé par SCCM, mais cela ne sera pas évoqué dans l’ouvrage.

1.2 LA NAISSANCE DU WAIK AVEC VISTA

L’arrivée de Windows Vista a fait une coupure avec le passé par rapport à la politique
de Microsoft, en fournissant pour la première fois un kit d’outils et de documentations
dédiés au déploiement de système d’exploitation Windows nommé WAIK (Windows
Automated Installation Kit). C’est l’équivalent de l’OPK pour les OEM ; la grande
différence est qu’il est ouvert à tous et bien évidemment gratuit. La première version
du WAIK embarque le nouvel outil WSIM (Windows System Image Manager) pour
créer les fichiers de réponses. Il remplace le « Setup Manager ». WinPE 2.0 fait son
apparition avec beaucoup de nouveautés telles que :
• ImageX : un outil de gestion et de personnalisation des images WIM.
• PeIMG et Drvload : deux outils permettant l’ajout de pilotes dans WinPE.
• BDCEdit & Bootsect : deux outils pour la gestion du secteur de démarrage.
• Support du SSL : le SSL (Secure Socket Layer) est intégré dans WinPE.
• Support du Plug-and-Play : les périphériques sont détectés et installés lorsque
WinPE démarre.
• Support du démarrage : il est maintenant possible d’avoir une image WIM
sur lequel on peut démarrer l’ordinateur, ce qui est le cas pour Windows Vista
(boot.wim).
• Disque RAM : lorsqu’un démarrage s’effectue à partir d’un média en lecture
seule, WinPE crée un disque virtuel en RAM (lettre X:) accessible en écriture
avec 32 Mo de mémoire.

Il est possible de personnaliser d’avantage son image WinPE (WMI, HTA...). Le

format d’image WIM est maintenant standardisé, qu’il s’agisse d’images WinPE ou
d’images d’installation de Windows. C’est pour cela que dans le DVD d’installation
de Windows Vista nous retrouvons 2 fichiers WIM, le « boot.wim » correspondant à
l’image WinPE et, « install.wim » correspondant aux fichiers d’installation de Win-
dows. Plusieurs outils et technologies tels que les images de démarrage MS-DOS sont
remplacés par les images WinPE. « Sysocmgr.exe » est remplacé par « ocsetup.exe » et
« pkgrmgr.exe », le boot.ini est remplacé par un nouvel environnement de démarrage
appelé BCD (Boot Configuration Data). L’exécutable pour l’installation de Windows
est maintenant « Setup.exe ». Il remplace « Winnt.exe » ainsi que « Winnt32.exe »
utilisés dans les anciennes versions de Windows. Cet exécutable est maintenant
entièrement en GUI et l’automatisation d’installation par le fichier de réponses
Winnt.sif s’effectue maintenant avec le fichier « Autounattend.xml ». Il suffit de
le placer à la racine du DVD d’installation ou sur un média amovible. Le temps des
multiples fichiers de réponses au format INI est à présent révolu, tout est désormais basé
sur un unique fichier de réponses (unattend.xml) au format XML. Cela signifie que les
12 Chapitre 1. L’évolution des méthodes de déploiement

différentes étapes que nous connaissions par le biais de l’utilisation de ces multiples
fichiers de réponses (unattend.txt, winbom.ini, etc.) sont maintenant incluses dans
ce qu’on appelle les étapes de configuration (windowsPE, generalize...). Nous les
présenterons en détail dans le chapitre suivant. Notez que l’arborescence $OEM$ est
toujours supportée.

Figure 1.9 — Différences entre Windows XP et Vista au niveau des fichiers de réponses

La gestion des pilotes est devenue simple. Ceux qui ne sont pas disponibles dans
les sources d’installation de Windows peuvent être installés par le fichier de réponses
et cela par le biais de différentes étapes, ainsi qu’à l’aide du gestionnaire de package
qui est une nouveauté de Windows Vista. Il s’agit d’un outil permettant d’appliquer
des mises à jour, des packs de langue, etc. Nous le retrouvons dans le panneau de
configuration de Windows Vista. La variable OEMPnPDriverPath pour l’ajout de
pilotes a donc disparu, ainsi que l’outil « update.exe ». L’exécution de commandes
additionnelles pendant l’installation ne s’effectue plus avec le fichier Cmdlines.txt
mais à travers le fichier de réponses ou le fichier « Setupcomplete.cmd ».
Un des plus grands changements pour les entreprises, sans parler des outils, est
que Vista n’est pas dépendant de la HAL ! Celle-ci est détectée au premier démarrage
de l’ordinateur. Cela signifie qu’il n’y a plus de questions à se poser concernant la
configuration matérielle sur laquelle nous allons déployer Windows Vista. Il ne reste
plus qu’à penser 32 bits ou 64 bits, soient deux images par type d’OS, ce qui implique
une réduction considérable du nombre d’images pour le déploiement. Le SYSPREP tire
donc parti de cette évolution et a donc considérablement changé. Les commutateurs
« /bmsd » et « /clean » ont été supprimés. La commande « sysprep/release » s’est
transformée en « sysprep/generalize/oobe », puis le commutateur « /factory » a été
remplacé par « /audit ». Ainsi, nous retrouvons l’outil SYSPREP directement dans le
dossier « C:\Windows\System32\sysprep » prêt à l’emploi.
Les éditions Standard et Enterprise de BDD 2.5 ont été fusionnées pour devenir
BDD 2007 pour le déploiement de Windows XP, Windows Vista et Office 2007. On
a affecté plusieurs mises à jour pour BDD 2007. Ce dernier se repose maintenant sur le
WAIK et permet d’utiliser plus facilement USMT 3.0 et ACT 5.0 dans son outil. Il est
toujours possible de faire du ZTI avec SMS 2003 SP2 et son pack de fonctionnalités
OSD. BDD 2007 pouvait s’installer sur un Windows XP ou sur un Windows Server
1.3 L’arrivée du SP1 de Windows Vista et de Windows Server 2008 13

2003. C’est cet accélérateur de solution qui a réellement marqué les esprits sur les
différents scénarios d’usage du déploiement Microsoft.
La version 2008 de BDD est ensuite arrivée en bêta incluant le déploiement de la
bêta de Windows Server 2008, y compris la version Core. Cette bêta de BDD 2008 a
permis de faire du déploiement multicast avec le WDS de Windows Server 2008. Il y
a de nouvelles séquences de tâches et les scripts ont été énormément enrichis. Le ZTI
est maintenant possible avec la nouvelle version de SMS, qui est maintenant connu
sous le nom de SCCM (System Center Configuration Manager). Nous l’aborderons
en détail dans les chapitres suivants.

1.3 L’ARRIVÉE DU SP1 DE WINDOWS VISTA

ET DE WINDOWS SERVER 2008

Il y a eu ensuite la version 1.1 du WAIK à la sortie du SP1 de Vista et de Win-

dows Server 2008. Cette version du WAIK a apporté WinPE 2.1 qui est devenu
beaucoup plus complet et beaucoup mieux documenté. Nous avons maintenant la
capacité de déployer des imagines 32 ou 64 bits à partir d’une image WinPE 32 bits ;
les ordinateurs UEFI (Unified Extensible Firmware Interface) sont maintenant
supportés. « DPInst.exe » (disponible dans le WDK – Windows Driver Kit) et
« PostReflect.exe » sont deux nouveaux outils pour l’installation des pilotes. Il y a
également l’outil « VSP1Cln.exe », qui permet de supprimer les fichiers d’installation
de Vista nous donnant la possibilité de gagner de la place sur le disque dur. Les
images WinPE peuvent être maintenant démarrées à partir du disque dur et également
être converties en ISO avec l’outil « oscdimg.exe ». Enfin nous savons créer des
images WinRE (Windows Recovery Environment) qui correspondent à la console
de récupération disponible lors du démarrage des médias d’installation de Windows
Vista et Server 2008. Au sujet de Windows Server 2008, il est complètement supporté
pour l’installation des rôles, des services et des fonctionnalités de l’OS lors d’un
déploiement.
MDT 2008, qui est en fait le nom final de la bêta de BDD 2008, est sorti afin
de fournir le support de Windows Server 2008 RTM et de Windows Vista SP1. Une
mise à jour de BDD 2007 (Update 2) a également permis le support de ces OS. Cette
version se repose sur la nouvelle version du WAIK et permet d’aller encore plus loin
dans la méthodologie du déploiement. Il est possible de configurer automatiquement
l’installation d’une infrastructure Active Directory, DNS et DHCP. Nous avons pu
remarquer la première et dernière mise à jour pour MDT 2008 (Update 1), qui a réglé
différents bugs dont une révision du management pack pour SCOM (System Center
Operations Manager).