Au cœur de l'installation - Résolution des problèmes inhérents au déploiement Windows dans le monde réel

Date de publication : 15 septembre 2010

Il est incontestablement merveilleux de voir tant d'entreprises migrer vers Windows 7 et Windows Server 2008 R2, mais il est également exceptionnel de constater qu'elles tirent parti des nouveaux outils de déploiement qui ont fait leur apparition au cours de la même période. Cela dit, comparé à celui de Windows XP et de Windows Server 2003, le déploiement de la nouvelle plateforme Windows est tout à fait différent. Dans cet article, je vous propose quelques trucs et astuces permettant de résoudre rapidement les problèmes les plus courants inhérents aux déploiements Windows, par le biais d'outils d'installation fondamentaux et de solutions de déploiement tels que Microsoft Deployment Toolkit (MDT) et Microsoft System Center Configuration Manager (ConfigMgr).

Retour au début

Le moteur d'installation Windows

Peu importe l'outil que vous utilisez pour déployer Windows 7 ou Windows Server 2008 R2, à un moment donné il exécutera le nouveau moteur d'installation Windows. Cela peut se produire dans le cadre de l'installation complète que vous effectuez lorsque vous exécutez setup.exe ou dans le cadre de la mini-installation équivalente après avoir appliqué une image Windows Sysprep à l'aide d'outils tels que ImageX provenant du Kit d'installation automatisée (Windows AIK). À chaque fois que l'installation s'exécute, elle nécessite des informations de configuration ; elle peut vous demander de les fournir, mais dans la plupart des cas, elle interroge un fichier de réponses (unattend.xml) pour les obtenir. Le moteur d'installation consigne l'ensemble de ses actions dans un fichier journal (le fichier setupact.log) et c'est ce fichier que nous devons examiner lorsque l'installation de Windows rencontre une erreur.

Problème 1 : L'installation de Windows émet une invite de code d'erreur étrange

Dans le scénario illustré ci-dessous, nous déployons Windows 7 avec un fichier unattend.xml mais le déploiement échoue au milieu de l'installation en émettant un code d'erreur étrange :

Solution :

Ne cliquez pas sur OK. À la place, appuyez sur Maj-F10 pour localiser le fichier setupact.log (ce fichier se trouve à différents emplacements en fonction du moment auquel l'installation échoue). Dans ce cas, la véritable erreur réside dans le fait que nous avons tapé un nom d'ordinateur incorrect dans notre fichier unattend.xml, comme le montre setupact.log. Ce sont les lignes de setupact.log. J'avais délibérément attribué un nom d'ordinateur comportant plus de 16 caractères à mon fichier unattend.xml (comme j'ai pu voir certains clients le faire), et c'est ce qui a provoqué l'obstruction de l'installation.

Conseil ! - Pour obtenir la liste des emplacements possibles du fichier setupact.log, consultez cet article. 

Retour au début

Utilisation de MDT 2010 Lite Touch pour déployer Windows

Lors de l'utilisation de MDT 2010 Lite Touch pour déployer Windows, les problèmes sont bien plus complexes à résoudre. Cela est dû au fait que MDT ajoute une autre couche d'outils et de scripts par-dessus le moteur d'installation fondamental et les outils Windows AIK. Heureusement, MDT fournit également la gestion des erreurs supplémentaire et des fichiers journaux qui nous permettent de déterminer ce qui se passe ; ainsi, au bout du compte, nous sommes mieux armés pour le dépannage. Pour mieux comprendre le dépannage, vous devez garder à l'esprit la façon dont le processus se déroule lors du déploiement de Windows.

Lorsque nous avons recours à MDT pour déployer Windows, nous utilisons ce que l'on appelle une séquence de tâches. La séquence de tâches est notre liste d'étapes ou d'actions devant être effectuées au cours du déploiement. Certaines étapes couramment utilisées portent sur le formatage du lecteur, l'injection de pilotes, l'exécution de l'installation de Windows avec un fichier de réponses, l'installation d'applications et l'installation de mises à jour.

Le processus de déploiement sans système d'exploitation MDT 2010 Lite Touch ressemble à ceci :

1. L'image de démarrage démarre à partir de CD/USB ou PXE et, une fois démarrée, se reconnecte au serveur de déploiement.
2. L'Assistant de déploiement démarre et lit les paramètres de déploiement (règles) à partir du serveur et démarre automatiquement le déploiement ou vous invite à effectuer la saisie (en fonction des paramètres du serveur). Les paramètres sont stockés dans la mémoire.
3. La séquence de tâches sélectionnée est initiée et commence à exécuter les actions ou les étapes qu'elle contient. Par exemple, pour s'assurer de paramétrer correctement l'installation, les actions suivantes sont mises en œuvre :
   
   a. Recueillir : lit les paramètres de déploiement
   b. Configurer : met à jour le fichier unattend.xml en y insérant les paramètres appropriés
   c. Appliquer le système d'exploitation : exécute le fichier setup.exe avec le fichier unattend.xml mis à jour
   
   
4. Une fois l'image du système d'exploitation appliquée, la séquence de tâches redémarre la machine et reprend là où elle s'était arrêtée après le redémarrage.

Lors du dépannage de MDT 2010 Lite Touch, nous utilisons également des fichiers journaux ; néanmoins, ils sont stockés à des emplacements différents de celui du fichier setupact.log. Chaque script MDT génère son propre fichier journal mais le fichier journal BDD.log contient une vue résumée de tous les autres fichiers journaux MDT. Les journaux sont stockés dans X:\MININT\SMSOSD\OSDLOGS, C:\MININT\SMSOSD\OSDLOGS ou C:\Windows\Temp\DeploymentLogs en fonction du moment auquel le déploiement échoue. BDD.log est le fichier journal maître, mais le fichier SMSTS.log peut également produire des indices supplémentaires permettant d'indiquer pourquoi un déploiement Lite Touch se rompt. (Au fait, les fichiers journaux sont formatés pour pouvoir être lus par l'utilitaire trace32.)

Retour au début

Problème 2 : MDT 2010 Lite Touch ne parvient pas à se connecter au serveur

Il s'agit d'une erreur relativement courante, mais comment pouvons-nous y remédier ? Dans ce cas, je sais que l'utilisateur et le mot de passe spécifiés sont corrects.

L'étape suivante consiste à appuyer sur F8 pour obtenir une invite de commande. Puisque cette erreur se produit très tôt au sein du processus, aucun volume C: n'est créé à des fins de stockage des fichiers journaux ; par conséquent, MDT les stocke dans la RAM. Ainsi, après avoir ouvert le fichier journal BDD.LOG à l'aide de l'utilitaire trace32 (ou du Bloc-notes) dans X:\MININT\SMSOSD\OSDLOGS (le lecteur RAM), les éléments suivants s'affichent :

La véritable erreur réside dans le fait que nous avons tapé une erreur dans nos règles. Le partage de déploiement est partagé en tant que MDTProduction$ mais nous avons tapé MDTProducton$ (sans le « i ») dans les règles.

Retour au début

Utilisation de ConfigMgr 2007 pour déployer Windows

À l'instar de l'utilisation de MDT 2010 Lite Touch pour déployer Windows, l'ajout de ConfigMgr 2007 à l'image rend la résolution des problèmes de déploiement plus complexe en comparaison avec la simple utilisation du DVD de Windows 7. Les composants MDT 2010 Zero Touch permettront de réduire les difficultés en ajoutant plus de 100 fonctionnalités fréquemment recherchées, y compris la gestion des erreurs supplémentaire, à ConfigMgr 2007. Contrairement à la croyance commune, MDT réduit en fait la complexité en cas de recours à ConfigMgr OSD, et non l'inverse.

Lors du déploiement de Windows à l'aide de ConfigMgr 2007, ConfigMgr stocke ses fichiers journaux supplémentaires dans X:\Windows\Temp, C:\_SmsTaskSequence\SMSOSD\OSDLOGS et C:\Windows\System32\CCM\Logs ou C:\Windows\SysWOW64\CCM\Logs en fonction de la plateforme. Avec ConfigMgr, le fichier journal maître est SMSTS.log mais les fichiers journaux MDT peuvent également contenir des informations utiles. Pour accéder aux fichiers journaux sur le client, cochez la case Activer la prise en charge des commandes (test uniquement) dans les propriétés de l'image de démarrage pour activer F8 lorsque Windows PE s'exécute.

Retour au début

Autres journaux utiles lors du déploiement de Windows

• Cbs.log : utilisé à des fins de dépannage des commandes DISM pour injecter des pilotes, des packs linguistiques, des mises à jour, etc.
• Setupapi.dev.log : utilisé à des fins de dépannage des pilotes
• Netsetup.log : utilisé à des fins de résolution des problèmes inhérents à la jonction de domaine
• WindowsUpdate.log : utilisé à des fins de dépannage des installations de Windows Update

Bon dépannage !

Retour au début