Windows, Sysprep, DriversPacks, Image Universelle et JeDDLaJ

mardi 27 janvier 2009
par  f
popularité : 43%

La version 1.6 IBE+ de JeDDLaJ prend désormais en charge les images de Windows préparées avec l’utilitaire Microsoft Sysprep. Astucieusement Configurée et combinée à l’ajout d’une archive de pilotes, une installation de Windows XP ou 2003 sysprépée va nous permettre de construire une image de base universelle, c’est-à-dire une image de base qui sera opérationnelle pour toute architecture i386. Nous verrons pourquoi la méthode décrite ici ne marche pas sous Windows Vista, mais nous envisagerons une amélioration pour un futur très proche de JeDDLaJ qui rendra la méthode plus légère et compatible avec ce système.

(Tous les scripts de ce document sont inclus dans l’archive de JeDDLaJ 1.6IBE+)

Sysprep : la première brique

Sysprep (SYStem PREParation) est l’outil Microsoft préparant une installation Windows à la duplication en la nettoyant de certaines informations propres à l’ordinateur (SID, numéro de licence, registres...) et réinstanciant ces informations lors du démarrage qui suit l’éxécution de Sysprep : l’image d’une installation sysprépée doit être faite avant ce reboot. La phase de ré-instanciation peut être conduite de façon automatique via un fichier de réponses qui peut également servir à la première phase de Sysprep (en particulier pour indiquer les pilotes contrôleurs de disques).

Confection d’une image sysprépée universelle

Nous allons maintenant dérouler en détails les étapes de la confection d’une installation de Windows XP sysprépée :

- aller sur une machine où est installé Windows XP (avec le dernier Service Pack mais sans logiciel non système) ou faire une installation de celui-ci sur une machine quelconque : il est vivement recommandé d’utiliser l’architecture la plus neutre possible, c’est-à-dire avec le moins de composants, et pour cela une machine virtuelle, créée dans un environnement comme VWMARE par exemple, est des plus approprié ;

- une fois l’installation terminée ouvrir le "Gestionnaire de périphériques" (cette étape est importante pour rendre l’image compatible avec toute architecture) :

  • remplacer le contrôleur de disques :
    • aller dans la rubrique "Contrôleurs ATA/ATAPI IDE" ;
    • cliquer droit sur le contrôleur de disque non générique ;
    • choisir "Mettre à jour le pilote" ;
    • puis "Installer à partir d’une liste" ;
    • et "Ne pas chercher. Je vais chercher le pilote à installer" ;
    • sélectionner alors "Contrôleur IDE standard double canal PCI" dans la liste ;
    • répéter l’opération sur l’autre contrôleur.
  • remplacer le couche type de couche HAL :
    • aller dans la rubrique "Ordinateur" ;
    • reproduire les actions décrites au-dessus pour choisir le pilote ;
    • sélectionner alors "PC à interface de configuration d’énergie avancée (ACPI)" dans la liste .
  • rebooter pour que les changements soient pris en compte

- faire un check du système de fichiers :

  • dans une console lancer chkdsk /f ;
  • répondre O pour l’opération s’exécute au démarrage suivant ;
  • rebooter.

- rendre le mot de passe administrateur vierge si vous voulez pouvoir l’instancier durant le déploiement (pré-requis de sysprep)

- exécuter le Sysprep :

  • télécharger Sysprep sur le site de Microsoft ;
  • décompresser l’archive dans C :\sysprep ;
  • dans une console taper : sysprep -reseal -mini

Intégration de l’image sysprépée dans JeDDLaJ

Voilà, il ne nous reste maintenant plus qu’à faire une image de l’installation sur laquelle a été appliqué Sysprep. Si vous n’êtes pas encore familier avec la confection des images sous JeDDLaJ,
consultez l’article Les images de base : création/insertion. Le but étant de disposer d’une image universelle, il est important de bien instancier le champs "Spécificité" à la valeur "Aucune". Pour les nom et version de la distribution "WindowsXP Sysprep" et "SP3" semblent adaptés.

Nous allons nous pencher sur le fichier de réponses sysprep.inf attendu par Sysprep lors du déploiement de l’image ainsi construite. Afin que ce fichier soit adaptable et adapté à chaque machine, nous allons associer à la distribution un script de post-installation qui va construire le fichier de réponses avec les informations recueillies dans la base de données de JeDDLaJ.

Voici un exemple de script créant le texte à sauver dans le fichier C :\sysprep\sysprep.inf :

Nous voyons que le fichier de réponses est organisé sous forme de sections. Afin que vous puissiez apporter vos propres modifications à ce script, reportez-vous à l’article [Variables et fonctions de JeDDLaJ] pour plus de détails sur les variables utilisées et prenez note de ceci :

- dans la section [Unattended] :

  • UpdateInstalledDrivers=yes permet de mettre à jour un pilote déjà présent dans l’image de base ;
  • DriverSigningPolicy=Ignore et NonDriverSigningPolicy=Ignore permettent d’installer sans confirmation des pilotes non signés ;
  • UpdateUPHAL...Mérite qu’on s’y attarde un peu. Nous avons vu que pour rendre universelle l’image nous avons modifié le type de la couche HAL. Le type choisi étant plus portable mais ne tirant pas le meilleur profit de la machine, on peut lors du déploiement modifier à nouveau la couche HAL. Voici un tableau récapitulatif des valeurs possibles (utiliser UpdateUPHAL pour un monoprocesseur et UpdateHAL pour un multiprocesseur) :
Sysprep NameHAL NamePC TypeDescription
UpdateUPHAL E_ISA_UP Standard Computers Standard PC
UpdateUPHAL ACPIPIC_UP ACPI PIC-based PC Advanced Configuration and Power Interface (ACPI) PC
UpdateUPHAL ACPIAPIC_UP ACPI APIC-based PC (UP) ACPI Uniprocessor PC
UpdateHAL ACPIAPIC_MP ACPI APIC-based PC (MP) ACPI Multiprocessor PC
UpdateUPHAL MPS_UP MPS UP PC MPS Uniprocessor PC
UpdateHAL MPS_MP MPS MP PC MPS Multiprocessor PC
UpdateHAL SYSPRO_MP Compaq SystemPro (MP) HAL Compaq SystemPro Multiprocessor or 100% Compatible

- dans la section [GuiUnattended] le mot passe administrateur via AdminPassword ne sera pris en compte que s’il est vierge dans l’installation sysprépée ;
- dans les section [UserData] et [Display] le nom netbios et les paramètres d’affichage sont positionnés par des variables JeDDLaJ ;
- dans la section [Identification], suivant le type d’affiliation choisi au travers de la variable affiliation_windows, Domaine ou Workgroup, s’inscrira respectivement JoinDomain ou JoinWorkgroup : dans cet exemple, les nom et mot de passe du compte permettant la jonction au domaine sont récupérés dans un fichier annexe _settings.rbc (reportez-vous au paragraphe Workgroups et Domaines sous JeDDLaJ v1.4IBE de ce document ;
- dans la section [Networking] on indique la configuration par défaut du réseau (DHCP,...)

Il existe beaucoup de paramètres configurables via le fichier sysprep.inf que vous pourrez trouver sur le net.

Il suffit ensuite de déposer le fichier de post-installation dans son répertoire et de l’ajouter via l’interface JeDDLaJ pour l’associer à la distribution "WindowsXP Sysprep SP3". Vous déterminerez s’il convient à tous les ordinateurs (choisir groupe "tous les ordinateurs") ou à un groupe spécifique : auquel cas vous écrirez un script de post-installation adapté à chaque groupe de machines sur lesquelles vous déploierez cette distribution.

DriverPacks : la deuxième brique

Durant sa deuxième phase (le reboot qui suit l’éxécution de la commande sysprep donc après le déploiement de l’image), Sysprep va paramétrer le système mais également installer les pilotes nécessaires au bon fonctionnement du matériel détecté : ces pilotes doivent être alors disponibles pour le système. Windows XP embarque un certain nombre de pilotes, mais pas tous les pilotes. Il s’agit maintenant d’intégrer l’archive de pilotes constituée par le site DriverPacks.net de la façon la plus souple et d’en tirer meilleur profit.

Récupération de l’archive de pilote depuis le site DriverPacks.net

Le site maintient et met à disposition une collection de pilotes répartis dans 10 archives au format 7zip téléchargeables sur cette page. On peut également y télécharger un logiciel qui vérifie si les archives dont on dispose sont à jour et qui permet de les slipstreamer : cette méthode est utilisée pour un installation en mode unattended mais pas dans Sysprep.

Nous donnons ici une façon de tenir à sa disposition une collection de pilotes à jour :

  1. créer un partage CIFS sur un système de type Unix de préférence ;
  2. télécharger une première fois les 10 archives ;
  3. croner une fois par semaine l’exécution d’un script qui compare le nom des archives. Voici un exemple de script :

Intégration dans JeDDLaJ des archives de pilotes

Grâce aux nouvelles méthodes de création de packages de la version 1.6 IBE+, nous allons pouvoir faire rapidement un package de l’arborescence des pilotes et la refaire à chaque mise à jour sans refaire l’image sysprépée :

  1. se connecter sur une machine connue de JeDDLAJ et sous Windows XP (n’importe qu’elle version) ;
  2. connecter le lecteur réseau contenant les archives de pilotes à jour ;
  3. dé-7ziper les archives à la racine du système, c’est à dire C :\ (nous allons voir que la longueur des chemins permettant d’accéder aux pilotes est très importantes) ;
  4. Depuis un navigateur, mettre la machine en "état package" ;
  5. rebooter ;
  6. cliquer sur le bouton "Faire un package du logiciel SANS faire de snapshots"
  7. choisir la partition où est installé Windows XP en cas de multi-boot ;
  8. dans la partie droite de l’explorateur de fichiers, sélectionner, le répertoire D ;
  9. dans le menu "Windows" de l’explorateur de fichiers, cliquer sur "Add To package" ;
  10. dans le menu "Windows" de l’explorateur de fichiers, cliquer sur "Create package" ;
  11. répondre "Oui" à la question "Voulez-vous inserer le package dans la base ?" ;
  12. si c’est la première fois que vous faites un package des pilotes, répondre "Oui" à "Est-ce un nouveau package ?". Dans le cas contraire (mise à jour), répondre "Non" ;
  13. remplir les champs d’information (la version ne devrait pas être renseignée de façon à écraser le package à chaque mise à jour. Le logiciel est sans spécificité) ;
  14. terminer la création de package.

L’idée est maintenant d’ajouter les pilotes au déploiement de l’image sysprépée. Pour cela, il faut évidement cocher dans la configuration logicielle l’installation du logiciel DriverPacks que nous venons de packager, mais il faut d’abord réaliser une opération cruciale qui est d’indiquer au système Windows XP que des pilotes additionnels sont à sa disposition.

Il existe un paramètre de Sysprep prévu pour indiquer le chemin vers des pilotes tiers. Cependant il faut indiquer chaque chemin vers chaque fichier d’extension .inf décrivant un pilote. Or la longueur de la chaîne contenant les chemins étant limitée à 1024 caractères, on ne peut pas utiliser ce paramètre. Cette limitation n’existe pas par contre pour la clef de registre qui décrit ces mêmes chemins : HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\DevicePath. Nous allons donc associer un script de post-installation au logiciel DriverPacks qui va parcourir l’arborescence des pilotes dont la racine est le répertoire C :\D et qui va, à chaque rencontre d’un fichier .inf, concaténer le chemin vers ce fichier dans une chaîne de caractères au départ vide. La chaîne est ensuite placée dans le registre sus-nommé.

Il ne reste plus qu’à associer ce script via l’interface JeDDLaJ au logiciel Driverpacks et au groupe "tous les ordinateurs".

Voilà. C’est fini ? Presque, reste le terrible syndrome de BSOD (blue screen of death). Et oui, nous avons mis dans l’image le pilote générique IDE, mais que se passe-t-il si l’on déploie l’image sur une machine munie d’un contrôleur SATA, SAS ou SCSI ? Ben, c’est le reboot infini assuré ! Est-ce qu’on peut faire quelque chose ? Pour le SATA il existe en général un moyen de le rendre compatible à l’IDE via le Bios : sur les ordinateurs Dell, par exemple, on le trouve sous les intitulés "Legacy", "Combination", "Raid Autodetect/ATA"... Ceci n’est pas très satisfaisant, et surtout ne marche pas avec le SCSI et le SAS.

Le problème vient du fait que les pilotes de ce type de contrôleur doivent être enregistrés dans le système avant que celui-ci n’accède au disque. Sysprep prévoit cela en déclarant une section particulière dans le fichier de réponses sysprep.inf où l’on indique in extenso les pilotes à utiliser. Dans ce cas précis, le fichier sysprep.inf est utilisé avant de lancer la commande sysprep, ce qui oblige à refaire l’image s’il faut y inclure un nouveau pilote.

Cette solution n’étant pas très souple, il existe, depuis la version 1.6 IBE+ de JeDDLaJ, une fonction pour enregistrer dans le système un nouveau pilote de contrôleur de disque sans avoir à relancer Sysprep : RegisterCriticalMassStorage(id_composant,driver,path), où id_composant est l’identificateur du contrôleur, driver le nom du pilote à utiliser pour ce contrôleur, et path le chemin vers ce pilote.

Exemple : pour un contrôleur "(ICH7 Family) SATA AHCI" (Dell OptiPlex 330)

L’enregistrement du contrôleur de disque dans le système peut être fait au moment du déploiement de Driverpacks par script de post-installation sous forme d’un branchement switch/case à mettre à jour au fur et à mesure des besoins.

Enfin, pour les ordinateurs munis d’un processeur AMD, il faut retirer un fichier issu du service pack 3 :

JeDDLaJ : le ciment

Examinons maintenant le déroulement du déploiement d’une image de base universelle sysprépée :

  1. l’image de base est téléchargée et installée sur la partition désignée ;
  2. le script de post-installation associé crée le fichier de réponses C :\sysprep\sysprep.inf ;
  3. le package des pilotes est téléchargé et installé ;
  4. le script de post-installation associé met à jour la clef de registre HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\DevicePath pour y indiquer tous les chemins des pilotes contenus dans le package et inscrit éventuellement dans le système le pilote gérant le contrôleur de disque dur s’il est non-IDE ;
  5. d’autres packages et scripts de post-installation associés sont installés et exécutés ;
  6. JeDDLaJ détecte que l’image est sysprépée (en attente d’éxécution de la deuxième phase) et boote sur le système ;
  7. la deuxième phase de Sysprep (appelée mini-setup) se déroule : installation des pilotes et paramétrage du système à partir du fichier de réponses ;
  8. à la fin du sysprep le système reboote ;
  9. JeDDLaJ reprend la main : l’image n’est plus en attente de terminaison de sysprep mais un reboot du système est exécuté si des scripts de post-installation ont inscrit un appel à MSWindowsRunOnce (voir paragraphe MSWindowsRunOnce de Workgroups et Domaines sous JeDDLaJ v1.4IBE de ce document, dans le cas contraire l’installation est terminée.

Remarque : le package des pilotes est installé aux cours du déploiement des logiciels sélectionnés, pas forcément à la suite de l’installation de l’image de base.

Il est important de noter que :
- dans le cas d’une image sysprépée le paramétrage du système n’est pas fait par JeDDLaJ (nom netbios, SID, résolution) : ce qui a pour conséquence, par exemple, que le SID d’une machine sur laquelle on installe une image sysprépée ne remonte pas dans la base JeDDLaJ ;
- vous pouvez associer d’autres scripts de post-installation à la distribution en plus de celui générant le fichier de réponses ;
- les éxécutions du mini-setup et de MSWindowsRunOnce engendrent deux reboot du système distincts.

L’image universelle sysprépée : exploitation et devenir

La combinaison de l’image de base sysprépée à la collection de pilotes apporte une souplesse considérable pour l’installation d’une machine.

Cependant il faut prendre en compte certains aspects de cette solution :

- limitation forte liée à Sysprep : il ne marche que si le système est installé sur C :, c’est à dire sur la première partition reconnue par le système ;
- pire que l’absence d’un pilote dans la collection DriverPacks, la présence d’un mauvais pilote est très pénible à gérer (surtout de façon pérenne) ;
- le temps mis pour exécuter la phase de mini-setup de Sysprep (qui avoisine en général les 5 minutes) peut être handicapant si les réinstallations sont fréquentes ;
- le poids de l’archive des pilotes : aujourd’hui autour des 1,5Go, il compte à la fois dans le temps du déploiement (téléchargement et installation) mais également dans la place occupée sur le disque.
- elle ne fonctionne pas sous Windows Vista ; la raison principale étant que la clef de registre DevicePath n’est plus prise en compte durant le déroulement du Sysprep

Si ces considérations ne sont pas problématiques pour vous, vous pouvez alors ne disposer que d’une seule image de base pour toutes vos machines pour les versions XP, 2003 de Windows ainsi que 2000 en utilisant la version de Sysprep adéquate.

Dans le cas contraire, vous pourrez utiliser cette solution pour décliner les images spécifiques d’une distribution "WindowsXP SP3".

Créer une image de base spécifique à partir de l’image universelle

Voici une méthode systématique et à moindre coût pour décliner une image universelle en n images spécifiques.

Sur chaque machine d’architecture matérielle différente :

  1. déployer la distribution "WindowsXP Sysprep SP3"+"DriverPacks" ;
  2. booter sur le système pour vérifier que tous les composants sont correctement installés ;
  3. détruire le répertoire C :\D des pilotes et ré-instancier la clef de registre HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\DevicePath à sa valeur initiale %SystemRoot%\inf. Vous avez la possibilité de laisser le soin à JeDDLaJ de faire ce travail pour vous, en répondant "OUI" à la question "Voulez-vous supprimer le repertoire et la clef de registre de DriverPacks ?" lors de la création de l’image de base ;
  4. éventuellement vérifier que tous les composants sont bien installés via le "Panneau de configuration" ;
  5. passer en création d’images de base et sauvegarder l’image sous le nom de distribution "WindowsXP SP3" avec comme spécificité la signature matérielle de la machine (reportez-vous à cet article pour plus de détails sur la création d’une image de base) ;

Vous pouvez effectuer l’étape 2 en réalisant une "vraie" désinstallation (voir l’article Désinstallation et script de pré-déinstallation) ; du logiciel "DriverPacks", en lui ayant au préalable asscocié le script de pré-désinstallation suivant :

Le cas Vista

Nous avons évoqué plus haut l’une des différence de comportement de Sysprep dans Vista par rapport à ses versions antérieures. En fait, le déroulement du processus Sysprep dans sa quasi totalité est différent : pour avoir une bonne vision de ce déroulement lisez ce document.
Une image d’un système Vista se déploie plus facilement d’une architecture à une autre, la couche HAL ne posant plus de problème dans cette version de Windows. Par contre, le problème du contrôleur de disque au démarrage, lui, demeure. Il peut être réglé de la même façon que précédemment :

  1. créer un package de pilotes fournis par DriverPacks.net : (éventuellement que l’archive "DriverPack MassStorage") ;
  2. lui associer un script post-installation pour déterminer quel pilote insérer dans le système et quel contrôleur de disque (partie switch/case du script initial) ;
  3. déployer le package en même temps que l’image de base de Vista.

On s’assure ainsi que le Vista déployé bootera bien, quant à la gestion des composants présents sur la machine ils ne seront pris en compte que :

  1. si les pilotes nécessaires aux composants de la machine sont présents sur le disque ;
  2. si l’administrateur valide l’installation des pilotes détectés.

Conclusion, il faut créer une image spécifique pour chaque architecture et une méthode pour le faire assez rapidement est d’appliquer le processus décrit plus haut ("Créer une image de base spécifique à partir de l’image universelle") en vous servant d’une image Vista faite sur n’importe quel ordinateur (sans y avoir appliqué l’utilitaire sysprep).

Remarque : bien que l’application de Sysprep sur un système Vista ne soit pas traitée ici, il faut noter que JeDDLaJ prend en charge le déploiement des images Vista syprepées (avec l’option /oobe).

Vers un nouvelle image universelle (sans défaut ?)

En considérant les points suivants :

  1. l’utilisation de Sysprep nous permet 2 choses :
    1. instancier les paramètres systèmes spécifiques d’une machine (SID, nom netbios, affiliation,...) ;
    2. installer les pilotes spécifiques aux composants d’une machine.
  2. l’installation automatique de pilotes additionnels durant le déroulement de Sysprep sous Vista se fait par l’exécution de l’utilitaire PnpUnattend via la commande shell C:\Windows\System32\pnpUnattend.exe AuditSystem (voir à nouveau ce document au paragraphe "Running PnP to install specific drivers") :
    1. cet utilitaire installe TOUS les pilotes se trouvant dans le repértoire indiqué dans la clef de registre HKLM\Software\Microsoft\Windows NT\CurrentVersion\UnattendSettings\PnPUnattend\DriverPaths\1 ;
    2. cet utilitaire n’existe que sous Vista.

JeDDLaJ, via les fonctions Rembo-C, sait instancier les paramètres du Système. N’existerait-il pas une commande shell pouvant être utilisée sous toutes les versions de Windows via la commande MSWindowsRunOnce qui nous permette d’installer les pilotes liés aux composants d’une machine ? Oui ! Cet utilitaire nommé Devcon est téléchargeable sur le site de Microsoft et permet, entre autres, d’ajouter un pilote de la façon suivante :

devcon install <chemin_vers_le_fichier_inf_du_pilote> <identifiant_windows_du_pilote>

Il nécessite donc que pour chaque composant et chaque version du système Windows, on connaisse le chemin vers le fichier .inf associé.
Dans la version actuelle de JeDDLaJ, la table des composants renseigne seulement le module Linux associé à chaque composant. Il faudrait élargir la connaissance de la base de données grâce à une nouvelle table dans laquelle serait indiqué pour chaque composant les chemins vers les pilotes issus de DriverPacks de chaque système Windows. Le remplissage de cette table se ferait de façon automatique par un parcours de l’arborescence de la collection de pilotes.

Quels seraient les avantages :

  1. on n’utiliserait plus une image sysprépée mais une image d’un système où les seules précautions prises seraient celles du contrôleur de disque et de la couche HAL (et encore, pas dans Vista) : plus de temps perdu au déroulement du sysprep lors du déploiement, plus de contrainte sur la partition de déploiement ;
  2. la collection de pilotes ne serait plus à déployer sur les postes mais seuls les pilotes nécessaires seraient téléchargés depuis le serveur où elle serait stockée : pas de place utilisée inutilement sur disque et temps de téléchargement considérablement réduit ;
  3. l’insertion dans le système des contrôleurs de disques ne serait plus conditionnée par un switch/case, mais déduite automatiquement, comme pour les autres pilotes, des informations stockées dans la base de données ;
  4. même méthode pour toutes les versions de Windows.

Il ne reste plus qu’à coder tout cela pour la nouvelle version de JeDDLaJ...


Brèves

12 février 2009 - JeDDLaJ passe sur SourceSup à partir de la version 1.6IBE+

La communauté JeDDLaJ manquait jusqu’alors cruellement de certains services et moyens de (...)

12 février 2009 - 11/2/2009 : La version 1.6 IBE+ est disponible !!!

Ça y est. Après tant de mois (18 à peu près...) de gestation, d’hésitations, de :wq et autres (...)

12 février 2009 - JeDDLaJ gagne le concours DEVA => nouvelles fonctionnalités pour vous !!!

JOIE !!! BONHEUR !!! FIERTÉ !!!
JeDDLaJ remporte le concours DEVA (DEVeloppements (...)

9 juillet 2007 - Précision importante sur la compatibilité MySQL 5 de JeDDLaJ 1.4IBE

Dans le cas d’un serveur Rembo sous Windows, 2 moyens pour pouvoir utiliser MySQL 5 :
soit (le (...)

9 juillet 2007 - Déjà le SP1 pour JeDDLaJ 1.4IBE : désormais TPMfOSd-ready !!!

Description
Ce service pack n’apporte principalement qu’une amélioration... mais de taille... (...)