Avant-propos TAP ( Technical Adoption Program Gartner Group

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 programmesTAP (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 1^eravril 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êneet 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 BonninetDavid 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 deSCCMsa 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évNextcomme 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 Sebbanest 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 deMicrosoft 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 Ellerbachdirige 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 Cupet lesMicrosoft Student Partner. Il y a 4 ans, il a également co-créé les MicrosoftTechDays, multiplié par dix les trafics sur les sites WebMSDNetTechNet.

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.

L’évolution des méthodes de déploiement

1

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 duPC (Personal Computer)que le concept du déploiement a fait son apparition en entreprise : chaque PC est équipé de son propreOS (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 queBatch,le second. Une nouvelle version beaucoup plus riche a été développée pour Windows 98, appeléeMicrosoft 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’outilInfInst.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 futGhost 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’outilImage 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 exempleDeploycenterouDriveImagede PowerQuest,RapidDeployd’Altiris ou encoreGhostde 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 desHAL (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 Extensionou PAE). Il existe plusieurs types de couche HAL, que Windows peut utiliser tels queStandard PC, Advanced Configuration and Power Interface (ACPI) PC, ACPI Uniprocessor PC, ACPI Multiprocessor PC,MPS Uniprocessor PCetMPS 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 toucheF5au moment où l’assistant nous proposait d’appuyer sur la toucheF6, 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 particulierWinPE (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’outilERD Commanderde WinInternals ou encore le célèbreBartPE. 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 packagesMSI,WISE,NSISou encoreInstallShield. 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 celal’ORK (Office Ressource Kit)2003 ou encore Internet Explorer, disposant de son propre outilIEAK (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 deMDT (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 deLTI (Lite Touch Installation)et deZTI (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 surMSF (Microsoft Solutions Framework)etMOF (Microsoft Operations Framework), tout deux basés surITIL (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 formatWIM (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éeADS(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é estSUS (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é parWSUS (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 outilWSIM (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», leboot.iniest 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.sifs’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 OEMPnPDriverPathpour 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 fichierCmdlines.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 2007pour 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 deSCCM (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 imagesWinRE (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).