GERER LES PILOTES (0) – Introduction

La gestion des pilotes dans le cadre du déploiement de systèmes d’exploitation reste aujourd’hui une étape fastidieuse même si l’arrivée de Windows Vista l’a simplifié. En effet, nous devrons adapter nos méthodes de déploiement selon le type de pilotes, le produit de déploiement adopté et selon le système d’exploitation cible … pas simple donc !

C’est la raison pour laquelle j’ai souhaité publier une série d’articles sur la gestion des pilotes dans les solutions de déploiement Microsoft. Cette série sera composée des articles suivants :

  1. Introduction
  2. Extraire les pilotes utilisés par un poste de travail
  3. Intégrer ces pilotes dans un master à l’aide de dism.exe
  4. Gérer les pilotes dans WDS 2008 R2
  5. Gérer les pilotes dans MDT 2010 Update 1
  6. Gérer les pilotes dans SCCM 2007 SP2
  7. Gérer les pilotes dans SCCM 2012

Tout au long de cette série j’illustrerai mon propos en prenant l’exemple de l’intégration et le déploiement des pilotes de modèles que j’ai eu l’occasion de côtoyer.

Ce premier article a pour objectifs de planter le décor, à savoir vous présenter les différents types de pilotes, les solutions Microsoft de déploiement d’OS et les interactions entre ces différents éléments. Pour rédiger cette série, j’ai repris un très bon article de Ben Hunter en essayant d’y apporter des précisions.

Pourquoi est-ce plus simple d’installer des pilotes ?

Principalement pour deux raisons :

  • D’une part, à partir de Windows Vista/2008, lorsque vous allez créer une image de référence (= un master), l’outil de préparation du système (syprep.exe) va s’occuper de supprimer toute adhérence du système d’exploitation à la couche matérielle nécessaire à sa conception. En d’autres termes, si je créé un master Windows 7 à partir d’un Lenovo SL500, mon master n’aura aucune trace de ce matériel. Et ça change tout ! Dites adieu aux écrans bleus après le déploiement de ce master sur des postes qui ne sont pas des Lenovo SL500 et bonjour au véritable GOLD MASTER : ce master unique pour tous les postes de travail. Le saint Graal des déployeurs est désormais accessible.
  • D’autre part car la suite d’outils de déploiement fournis avec Windows 7, le Windows Assistant Installation Kit (WAIK), présente un outil (dism.exe) qui va nous donner la possibilité de gérer nos masters hors-ligne. Pour faire court, je vais monter mon image dans un dossier, en modifier le contenu (travail sur dossiers et fichiers, ajout de pilotes, de mises à jour, changement des paramètres de langues, etc.), puis démonter mon master en enregistrant les modifications. A l’occasion des prochains déploiements de cette image, les pilotes seront déjà présents, les mises à jour s’installeront lors du premier redémarrage de la machine, etc. En un mot : MAGIQUE ! vous économiserez donc beaucoup de temps.

Le tableau suivant présente les fonctionnalités accessibles sur un master hors-ligne selon l’OS contenu dans le master :

Fonctionnalité Windows XP Windows 7
Monter l’image hors ligne oui oui
Fichiers / dossiers : modifications oui oui
Ajout de pilotes oui
Ajout de mises à jour oui
Activation de fonctionnalités oui
Changement des paramètres régionaux oui
Upgrade de version ouiDe Professionnel vers entreprise

Mais … il existe plusieurs types de pilotes

Comme je vous le disais dans l’introduction tous les pilotes ne sont pas conçus de la même manière. Il existe deux catégories de pilotes :

  • Les bons pilotes
  • Les mauvais pilotes

Quelle est la différence entre le bon pilote et le mauvais pilote me direz-vous ? Et bien c’est un peu comme le bon et le mauvais chasseur …

  • Les bons pilotes sont les pilotes qui n’ont besoin que du fichier .inf pour s’installer. Ce sont typiquement ces pilotes qui peuvent être intégrés dans un master à l’aide de l’outil dism.exe (fourni dans le WAIK). Cette catégorie regroupe la majorité des pilotes je vous rassure
  • Les mauvais pilotes. Ces pilotes nécessitent d’être installés comme une application. Pire encore certains d’entre-eux nécessitent qu’une session utilisateur soit ouverte pour s’installer ! Ces pilotes sont intégrés à une application et ne peuvent être déployés que durant l’installation de celle-ci. Cette famille de pilotes portent également le nom de “hardwares based application”. Vous les retrouverez certainement lorsque vous aurez à installer un lecteur d’empreintes digitales ou une carte 3G. Dans ce cas, vous l’aurez compris, vous devrez installer ce pilote en déployant l’application.

Par conséquent, lorsque vous allez concevoir votre solution de déploiement/migration Windows 7, vous aurez à déterminer ces deux catégories, car ne comptez pas trop sur les constructeurs pour éclairer votre lanterne. Nous verrons dans  le second article de la série comment s’en sortir assez simplement.

La mise à disposition des pilotes dans les outils Microsoft

Il faut savoir que selon la solution de déploiement utilisée, vous aurez plus ou moins de difficultés à déployer ces pilotes. La catégorie des bons pilotes ne posera globalement jamais de problème. Par contre la catégorie des mauvais pilotes pourrait vous imposer certaines contraintes et ne sera pas possible selon l’outil de déploiement utilisé.

En gros, tout réside dans la possibilité de pouvoir installer automatiquement des applications une fois votre master déployé. Le tableau suivant répertorie cette fonctionnalité selon l’outil de déploiement utilisé :

Intégration manuelle via DISM.exe Windows deployment Services Microsoft Deployment Toolkit SCCM
Application de pilotes .inf oui oui oui oui
Application de pilotes par l’installation d’une application non non oui oui
Application de pilotes par l’installation d’une application dans l’environnement utilisateur non non oui oui

Nous pouvons d’ores et déjà remarquer que l’installation des “hardware based application” par l’outil WDS et par l’outil dism.exe n’est pas possible. Par contre les produits MDT et SCCM peuvent réaliser les opérations mais d’une manière différente.

Windows Deployment Services sous Windows Server 2008 R2

La principale évolution des services de déploiement Windows (WDS)  sous Windows Server 2008 R2 réside dans le fait qu’il est maintenant possible de “provisionner” les pilotes hors-ligne. Préalablement, il fallait absolument utiliser un outil supplémentaire tel que Microsoft Deployment Toolkit (MDT), pour gérer les pilotes hors ligne.

Concrètement vous allez importer vos pilotes dans les services WDS à l’aide de l’interface graphique, ou bien par le biais de la commande WDSUTIL. Vous déciderez ensuite si vous laissez le poste de travail détecter automatiquement les pilotes nécessaires ou vous pourrez regrouper ces pilotes selon certaines catégories (modèle, master, etc..) et filtrer leur installation selon le poste qui en fait la demande ou le master que l’on déploie.

Dans tous les cas seule la catégorie des « bons pilotes » peut être prise en compte par WDS. Ceci est dû au fait que WDS ne gère que l’installation d’un système d’exploitation.

Je détaillerai dans le troisième article de la série la gestion des pilotes via WDS.

Microsoft Deployment Toolkit

Microsoft Deployment Toolkit (MDT) est un outil qui vient en complément de WDS. Il étend largement les fonctionnalités de ce dernier car il permet entre autres, d’installer des language Packs pendant le déploiement d’un poste, mais aussi d’effectuer des tâches de configuration et d’installer des applications … et c’est cette dernière option qui nous intéresse !

Comment fait-il ? Pour déployer/migrer un poste de travail, nous allons créer une séquence de tâches, c’est-à-dire une suite d’étapes qui composent l’installation d’un poste de travail. Par exemple, dans le cas d’une migration de poste de travail la séquence de tâches réalisera les étapes suivantes :

  1. elle validera l’ordinateur pour une installation de Windows 7
  2. Sauvegardera l’environnement utilisateur avant le retrait d’un pc du parc, à l’aide de USMT,
  3. Installera un nouveau poste de travail selon nos souhaits ( partitionnement, language Pack, pilotes, scripts, applications),
  4. restaurera l’environnement utilisateur sauvegardé précédemment

Dans le cas de l’installation des pilotes, nous allons pouvoir importer des pilotes dans l’interface de MDT, comme dans WDS. De cette manière, nous aurons géré la catégorie des bons pilotes.

Reste ensuite à gérer la catégorie des mauvais pilotes. Etant donné que nous pouvons installer des applications dans le cadre de notre séquence de tâches, il ne nous reste plus qu’à importer l’application dans MDT et de spécifier la commande d’installation silencieuse (souvent présente dans le readme.txt ou la release Note de l’application). Nous terminerons l’intégration par l’ajout dans la séquence de tâches d’une étape qui installe cette application.

Cela reste très simple à gérer même si, je vous le conçois, ça aurait été parfait si tout se faisait comme des “bons pilotes” Clignement d'œil

Le détail de la gestion des pilotes dans MDT sera présenté dans le 4ème article de la série.

System Center Configuration Manager

Lorsque nous utilisons la fonction OSD (Operating System Deployment) de SCCM, nous devons également gérer la problématique des pilotes. Microsoft a ici bien fait les choses car nous allons déployer les pilotes exactement de la même manière que sous MDT. Pourquoi ? Parce que le déploiement de systèmes d’exploitation sous MDT et SCCM est basé sur le même moteur de séquences de tâches !

Il y a cependant un petit modulo qui complique les choses. Lorsque vous déployez un système d’exploitation à l’aide de SCCM, toutes les actions sont réalisées avant la première ouverture de session d’un utilisateur, c’est-à-dire dans le contexte SYSTEM. Dans MDT une section entière de la séquence de tâche s’exécute dans la session du compte administrateur local.

Par conséquent les pilotes qui requièrent une session utilisateur ouverte ne peuvent pas être intégrés dans une séquence de tâches. Il faudra donc publier cette application en dehors de la séquence de tâches et attendre que le poste de travail est correctement joint son site SCCM pour récupérer l’application …. OUF !

En résumé …

  • Vista a rendu les masters (Vista et +) indépendants de la couche matérielle Rire
  • Il est désormais possible de concevoir un GOLD Master et de les gérer hors-ligneRire
  • Toutes les solutions Microsoft permettent de déployer les bons pilotes facilement Rire
  • Les mauvais pilotes devront être déployés comme des applications Gêné
  • Cette série d’article vous présentera comment réaliser ces opérations RireRireRire

Laisser un commentaire