I. Présentation

Avant d’aborder un sujet aussi vaste que celui du déploiement Windows, je pense qu’il convient de préciser quelques points et par la même occasion combattre quelques idées reçues.

En premier lieu, pour ceux qui débarqueraient d’une autre planète, je vais vous parler des principales technologies de déploiement Microsoft.

A. WDS (Windows Deployment Services)

C’est le service de déploiement Windows. Autrement dit un “rôle” facultatif disponible sur toutes les versions Windows Server depuis 2003R2. (Pour la petite histoire, son ancêtre se dénommait RIS pour “Remote Installation Service“) – En quelques mots, ce service assure 2 fonctions majeures : Le déploiement des images WIM pour les systèmes d’exploitation Windows et la fourniture d’images de démarrage (via PXE) pour l’initialisation des processus d’installation (ou de réparation).

B. MDT (Microsoft Deployment Toolkit)

C’est l’outil d’automatisation de la fabrication (et d’installation) des systèmes Windows. Pour la petite histoire, son ancêtre se dénommait “BDD2007” pour “Business Desktop Deployment“. Puis le produit a évolué au fil des années pour devenir MDT2008, 2010, 2012 puis dernièrement 2013. La version sera très probablement revue lors de la sortie de Windows 10. Ce produit est donc disponible en téléchargement gratuit, mais son usage requiert un kit complémentaire nommé WAIK (Pour Windows Automated Installation Kit) devenu Windows ADK (Pour Assessment and Deployment Kit)

Le MDT est en fait une console graphique (de type MMC) dont l’objectif est de fédérer des sources, réaliser l’assemblage et proposer des séquences de taches pour piloter le tout…

En quelques mots, la solution de déploiement fait référence à 2 grands types d’usage ou d’implémentation :

– Si vous utilisez MDT sans le produit commercial Microsoft SCCM (System Center Configuration Manager), les scénarios proposés par MDT seront de type “LiteTouch” ou “LTI” en abrégé. C’est-à-dire qu’en l’absence de mécanisme tiers, il restera donc toujours une intervention humaine, aussi infime soit-elle pour les déploiements, d’où le nom “LiteTouch”, pour légère intervention.

– Dès lors que la solution MDT est couplée à SCCM, il est possible de fédérer entièrement les processus de déploiement, jusqu’à la planification du déclenchement. Microsoft a donc déposé le nom “ZeroTouch” ou “ZTI” en abrégé pour désigner ce type de scénarios de déploiement, sans intervention humaine, sauf en cas de problème bien sûr

Cette précision reste toutefois purement culturelle, car la composition du MDT et les principes de fonctionnement restent les mêmes. Vous pourrez simplement constater que les raccourcis MDT autres que le “Deployement Workbench” mentionnés ci-après, sont inopérants en l’absence d’infrastructure SCCM.

C. WinPE (Windows Pre-execution Environment)

C’est un incontournable. Très grossièrement, si cette allusion vous parle, c’est le remplaçant de l’ancestrale disquette DOS. Il s’agit en fait d’un noyau système minimaliste est présent pratiquement partout depuis Vista. C’est-à-dire que vous pourrez le trouver, à quelques nuances près, sur un DVD d’installation, dans le MDT sous la forme d’un client LiteTouch, au sein des images de démarrage WDS, sans oublier sa déclinaison “WinRE” pour les procédures de réparation.

II. Combattre quelques idées reçues

A. Que me faut-il pour déployer automatiquement Windows ?

L’installation automatisée d’un système Windows requiert un fichier de réponse. Par exemple un fichier “autounattend.xml” présent sur un support amovible ou le DVD, pourra faire l’affaire. En utilisant WDS vous aurez l’avantage de ne pas être limité par le support (disques du serveur), mais l’inconvénient du transport de fichiers volumineux (bande passante du réseau).

Le premier intérêt de WDS est d’offrir une “dématérialisation” des DVD de distribution afin de les centraliser sur un serveur et fournir par la même occasion un système d’amorçage via le réseau PXE.

Le second avantage de WDS (depuis 2008R2) est d’offrir une capacité de flux multiples dits “multicast”. Le déploiement d’images identiques est alors réduit de façon significative dès lors que le nombre d’ordinateurs ciblés est important. (>5)

Notez cette subtilité très intéressante : Contrairement aux versions antérieures à Windows Server 2012R2, le serveur WDS n’a plus besoin d’appartenir impérativement à un domaine Active Directory. Autrement dit, dorénavant, vous pouvez installer un serveur WDS en mode “autonome”, ce qui me semble un choix parfaitement adapté à des déploiements en mode “atelier”.

Si vous ne souhaitez pas utiliser WDS, alors MDT peut suffire. Il présentera l’énorme avantage de produire automatiquement les fichiers de réponse par défaut. Toutefois, WDS et MDT ne sont pas exclusifs l’un de l’autre. Au contraire, j’affirmerais même qu’ils sont complémentaires.

Comme on dit souvent qu’un schéma vaut mieux qu’un long discours, je vous propose un petit extrait d’une de mes présentations sur les principes MDT et WDS.

Cette illustration montre la complémentarité des différents composants utilisés dans une solution de déploiement Windows.

B. Faut-il dédier un serveur pour MDT ?

Non, en fait, si vous avez compris le schéma précédent, un poste MDT basé sur un système tel que Windows 7 32 ou 64 bits peut suffire. En fait, ce que l’on pourrait désigner par “le poste d’administration MDT”, est un système Windows, poste de travail ou serveur, sur lequel sont installés le MDT et l’ADK.

Note : L’usage d’un système Windows Server peut être toutefois plus approprié afin de disposer d’une infrastructure de base plus efficace, et lui ajouter des rôles tels que WDS ou encore DHCP.

Le partage “DeployementShare$” du MDT, mentionné sur l’illustration ci-dessus, n’est pas nécessairement stocké sur un serveur de fichier Windows (Un NAS sur Linux Samba peut aussi faire l’affaire) et vous pouvez connecter la console “Deployement Workbench” vers un chemin UNC (sous réserve de fournir les bonnes identités “credentials”).

Pour vous faire une première idée de ce à quoi ressemble MDT, voici ci-après un aperçu de la console aussi appelée “Deployement Workbench“, que l’on peut traduire littéralement par “Atelier de déploiement”

Console “Deployement Workbench”

Notez qu’il est très facile, au grès des nouvelles versions de MDT, de mettre à jour un partage de déploiement, mais c’est une opération irréversible ! Donc, si vous installez des versions différentes de MDT, vous devrez vous astreindre à administrer des partages bien distincts.

Je vous conseille également de réaliser toutes vos opérations de copie ou de déplacement de dossier et de fichiers au sein de la console MDT, et d’éviter les modifications directes de la structure MDT.

Enfin, il est souvent conseillé d’avoir plusieurs MDT dédiés aux tests et développements, à la fabrication des images de référence (masters), puis aux déploiements dans l’environnement de production.. En effet, même si le MDT peut paraitre “souple” et convivial, il n’en reste pas moins un enchevêtrement complexe de scripts, souvent délicat à dépanner.

Ultime conseil : Pensez à vider régulièrement le journal “Audit.log” situé à la racine du partage de déploiement. Ce fichier consigne toutes les actions/modifications réalisées sur le MDT et peut s’avérer volumineux (surtout lors de vos phases de test)

C. Peut-on utiliser WinPE comme un “live-cd” ?

Non, bien qu’il soit issu du même noyau, Windows PE n’est pas un système d’exploitation d’utilisateur à proprement parler et à ce titre ne propose qu’une licence d’utilisation limitée. Officiellement, en termes de licence, voici un petit extrait de ce que vous pourrez lire en installant le kit Windows ADK :

[…]
1. INSTALLATION ET DROITS D’UTILISATION. Vous êtes autorisé à installer et utiliser un nombre quelconque de copies du logiciel sur vos dispositifs, uniquement dans le but de déployer, d’entretenir, d’évaluer la qualité du système et d’évaluer vos systèmes et dispositifs sous les systèmes d’exploitation Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows Vista, Windows 7, Windows 8 ou Windows 8.1.
[…]

Autrement dit, tout produit, même gratuit tel que LibreOffice est proscrit. On peut en déduire que seul l’outillage au titre des déploiements ou réparations des systèmes Windows est toléré. Ainsi, je pense qu’on ne vous reprochera pas d’ajouter un explorateur de fichiers tel que “Explorer++”, mais l’ajout d’un navigateur “portable” tel que Firefox devient rapidement “borderline”.

Quoi qu’il en soit, n’oubliez pas que WinPE est minimaliste, et qu’il ne supporte pas WoW (Windows On Windows). Autrement dit, sur un WinPEx64 ne tourneront que les binaires compilés 64 bits (beaucoup plus rares en freeware).

De plus, les services réseau tels qu’un accès à distance seront, comment dire ? problématiques… En effet, WinPE active un pare-feu par défaut, qu’il est possible d’inhiber, via l’outil spécifique “Wpeutil disablefirewall ” ou bien encore via des commandes de type “netsh”, mais Microsoft ne communique pas trop sur les limites d’usage.

En fait, le message subliminal que Microsoft veut faire passer, c’est que “Windows PE” est un système de type “client de déploiement“, et pas un “Serveur” donc pas de connexions entrantes…

En toute franchise, j’aurais donc tendance à me limiter et m’inspirer de l’outillage offert par DaRT (Diagnosis And Repair Toolkit) fournit aux entreprises ayant souscrit un contrat Software Assurance MDOP (Microsoft Desktop Optimisation Pack).

À ce propos, depuis MDT 2012, via la fonction “Monitoring“, Microsoft a prévu la possibilité d’effectuer des contrôles à distance vers les machines en cours de déploiement.

Ci-dessous : Aperçu des boutons de contrôle à distance, “potentiellement disponible” via les propriétés d’un poste en cours de déploiement via MDT :

Si cela vous intéresse, vous pouvez consulter une alternative possible VNC dans WinPE décrite dans le tutoriel dédié aux personnalisations de WinPE…

En conclusion, il est préférable de limiter ces adaptations à quelques outils propices aux opérations de maintenance, avec peut être un gestionnaire d’archives en plus, histoire d’ouvrir certains fichiers .zip, .7z, ou autres .rar… mais guère plus, afin de “rester dans les clous”…

D. Pourquoi ne faut-il pas cloner “directement” Windows ?

Ce sujet se prête souvent à des tergiversations selon les contextes ou les produits utilisés. Il est vrai qu’il sera plus facile de configurer une machine puis de cloner son état pour en faire des duplications, mais cela risque de vous exposer à des problèmes ou instabilités potentiels.

1. Utilisez impérativement “sysprep” avant une capture

Tout système Windows destiné à être dupliqué, typiquement les machines de référence (dit” Master”) doivent impérativement subir une préparation préalable, via l’outillage intégré “SYSPREP”. L’usage de ce programme réalise un certain nombre de “dépersonnalisations” et remet la machine en condition de “réinstallation”.

Parmi les plus importantes actions de sysprep, on peut relever :

• Nettoie les traces d’utilisation
• Supprime les pilotes tiers de périphériques
• Supprime la clé de licence et réarme le processus d’activation
• Régénère l’identifiant unique de sécurité local (SID) de l’ordinateur
• Passe le système en condition de « re-personnalisation » (OOBE – Out Of Box Experience)

Depuis Vista, l’outil “sysprep.exe” est systématiquement présent sous le dossier “%SystemRoot%\system32\sysprep” du système d’exploitation courant. Il peut être utilisé en ligne de commande ou graphiquement si vous n’indiquez aucun paramètre.

Préparer son système avec Sysprep

Les commutateurs sont obtenus par la commande “sysprep /?”

Les commutateurs de SYSPREP

Note : Bien que cela ne soit pas imposé par l’outil lui-même, pour fabriquer un système de référence, il est fortement conseillé que la machine ne soit pas membre d’un domaine.

Autre recommandation : Si vous réalisez une machine de référence, prenez l’habitude de réactiver le compte administrateur intégré et éviter l’usage des autres comptes tels que celui de l’installation.

Il s’agissait ici de vous sensibiliser à cet outil fondamental, mais l’usage du MDT vous affranchira de cette contrainte et se chargera de la satisfaire à votre place.

Conseil : En matière de préparation d’un poste de référence, n’hésitez pas à exploiter des machines virtuelles et leur capacité de retour arrière, couramment appelé “Snapshots”. En effet, comme j’aurais pu le préciser précédemment, l’usage de l’outil “sysprep” supprime toutes les traces d’utilisation et, mais aussi les dépendances matérielles. Grâce à la virtualisation, vous pourrez donc reprendre la fabrication au point souhaité, tester l’efficacité du déploiement puis valider en dernier lieu le résultat sur une machine physique, en évitant de gaspiller un temps précieux lors de vous différents essais.

2. Les images .WIM, c’est quoi exactement ?

Comme vous pourrez le remarquer, les fichiers .WIM sont au cœur des nouvelles technologies de déploiement Windows et la maitrise de ces derniers est une clé essentielle en la matière. Les fichiers .WIM sont des “conteneurs d’images”, non au sens photographique, ni autres dessins d’artistes en herbe, mais une structure de fichiers et de dossiers (un peu comme un fichier archive de type .ZIP). À l’instar de ces archives, ils peuvent également bénéficier d’un mécanisme de compression, mais offrent d’autres d’avantages tels que l’instanciation unique des fichiers redondants, des métadonnées XML …

Note : L’extension des fichiers WIM n’est pas prise en compte dans les interfaces graphiques Windows. Vous pouvez cependant recourir à l’utilitaire gratuit “7-Zip” pour visualiser le contenu de ces fichiers. Dans le cas d’images multiples, chacune d’entre-elle apparait sous forme d’un dossier représentant le numéro d’index alors que le fichier .xml à la racine contient les métadonnées.

Exemple d’ouverture d’un fichier .WIM contenant plusieurs images avec 7-Zip:

Structure d’un fichier WIM

Il faut toujours avoir à l’esprit qu’un fichier .WIM contient toujours une image au minimum. Chaque image étant identifiée par un index, il faut toujours stipuler ce numéro et ne pas oublier que les images sont indépendantes. Autrement dit, une modification apportée sur l’image donnée ne sera pas visible dans les autres images d’un même fichier. Toutefois, cette technique d’images multiples est essentiellement exploitée par les distributions Microsoft et plus rarement par les entreprises elles-mêmes.

La structure des fichiers .WIM :

Officiellement la manipulation des fichiers WIM s’effectue via les outils suivants :

Résumé des principales actions réalisables sur les fichiers WIM

Schéma de synthèse des actions

Pour manipuler le contenu d’un fichier .WIM, il est nécessaire de procéder à un “montage”.

DISM /Mount-Wim /WimFile:.\DVD\Sources\install.wim /index:1 /MountDir:.\MNT

Pour effectuer ce montage, il est nécessaire que le dossier de destination (.\MNT) existe au préalable et il est préconisé qu’il soit vide, bien que cela ne soit pas imposé par l’outil.

Pour enregistrer des modifications apportées dans une image .WIM montée, il faut valider les changements lors du démontage (/commit).

DISM /Unmount-Wim /MountDir:.\MNT /commit

En cas de difficulté de montage des images, vous pouvez recourir aux actions suivantes

Pour terminer sur cette présentation des fichiers .WIM, j’ajouterais qu’il ne faut pas les confondre avec un système d’imagerie de disque par blocs (du genre .VHD, GHO…). Autrement dit, ils ne contiennent aucune notion de partition, ni de formatage, et il faut donc préparer le support de destination et ne pas oublier d’ajouter un mécanisme d’amorçage le cas échéant.

3. Les processus de fabrication et de déploiement

Schématiquement on pourrait résumer le processus de fabrication et de déploiement comme suit :

• Préparation de l’ordinateur de référence et génération de l’image WIM

• Installation – Partitionnement des disques, configuration de l’amorçage et extraction (ou application) de l’image WIM

Je vous invite à continuer la lecture avec ce second article : Débuter avec MDT 2013

I. Présentation

Ce tutoriel s’adresse aux néophytes en matière de déploiement Windows, et a plus précisément pour but de vous de présenter l’installation de base de la solution de déploiement gratuite de Microsoft. J’ai nommé le désormais célèbre “Microsoft Deployment Toolkit” alias “MDT“.

Vous trouverez probablement sur la toile de nombreux tutoriels relatifs à MDT, et celui-ci n’a pas la prétention d’être meilleur que les autres. En fait, il s’agit là de vous présenter quelques fondamentaux que j’enrichirais par des articles complémentaires permettant de progresser à votre rythme et selon vos besoins.

II. Un peu de théorie

Loin de moi l’idée de détailler l’intégralité d’un outil aussi riche et complexe que le MDT, mais je pense quelques points de repères et de vocabulaire sont toujours bons à prendre pour les débutants :

A. Architecture et composants

Sur le plan technique, le MDT repose principalement sur le kit de déploiement Windows ADK, (anciennement WAIK) constituant un prérequis impératif. L’architecture de cet outil est articulée autour de 3 parties fondamentales :

• La console de gestion : Alias “Deployment Workbench” (ou “Atelier de déploiement”) : C’est une console graphique de type MMC, exécutée sur un poste Windows (32 ou 64 bits) sur lequel ont été installés le kit de déploiement Windows ADK, et le package MDT. Notez que Powershell est également un prérequis.

• Le point de distribution : Sauf  dans le cas particulier d’usage d’un “Media”, il s’agit d’un dossier partagé (Nom par défaut “DeploymentShare$“) – Tout serveur de fichier SMB/CIFS, Windows ou Linux peut faire l’affaire…

• Le client LiteTouch : Basé sur un noyau WinPE utilisant principalement un script “LiteTouch.wsf“, ce client chargé de connecter et d’interpréter des scripts (.vbs/.wsf) et directives publiées (.xml) sur le point de distribution. Comme tous les noyaux WinPE, il peut être utilisé sur des supports flash USB, des CD/DVD ou bien via le réseau PXE, typiquement via les services WDS (Windows Deployment Services)

Vue d’ensemble de MDT

Pour rappel : Les services de déploiement Windows (WDS) constituent une composante facultative de l’architecture MDT.

Au besoin, reportez-vous à ma présentation sur “Vue d’ensemble de MDT-WDS et WinPE” qui aborde une synthèse de ces concepts.

B. Mécanismes et éléments clés de configuration

A l’usage, vous constaterez que le MDT draine des notions de “scénarios de déploiement”. En fait, cela désigne la logique que les scripts vont emprunter pour traiter les différents cas de figures possibles.

Cette logique très complexe de scripts, sera pondérée et contrôlée par les réglages que vous pourrez définir dans les “séquences de taches“. Pour traiter les cas courants, le MDT propose des séquences de taches prédéfinies qui vous pourrez adapter à votre guise.

1. Les scénarios possibles

Les scénarios sont donc composés d’un ensemble de taches pouvant débuter par un test de prérequis(*), une sauvegarde des données d’utilisateur ou une capture de référence puis installer un système d’exploitation et d’éventuelles applications, pour s’achever par une restauration des données d’utilisateur. Les scénarios prennent en charge 4 cas de figure :

• Upgrade Computer : Mise à jour sur place d’un même ordinateur (Sous réserve que le système d’exploitation soit supporté)

• Refresh Computer : Réinstallation sur un même ordinateur (récupération préalable des données d’utilisateur)

• Remplace Computer : Installation sur un nouvel ordinateur (récupération des données d’utilisateur à partir de l’ancien ordinateur)

• New Computer : Installation d’un nouvel ordinateur (L’éventuel contenu existant est supprimé) – Ce scénario ne peut être exécuté que lorsque l’ordinateur est démarré à partir d’un noyau WinPE (Client LiteTouch) – En fait, c’est plutôt rationnel puisqu’il n’est tout bonnement pas possible de supprimer les partitions d’un système en cours d’utilisation.

(*) – Pour votre gouverne et bien qu’il s’agisse d’un concept avancé, voire de spécialiste, sachez que durant l’initialisation du client LiteTouch, le script “ZTIGather.wsf” effectue une collecte d’informations sur l’environnement afin de positionner des variables qui influenceront les séquences de taches par la suite.

2. La ressource partagée “DeploymentShare”

Au niveau de la ressource partagée (“DeploymentShare$” par défaut), on distingue particulièrement les dossiers suivants :

• Boot : Contient les fichiers .WIM et éventuellement .ISO correspondants aux images WinPE modifiées “LiteTouch”, nécessaires à l’initialisation de la connexion et l’exécution des tâches définies sur le serveur de fichiers.
• Operating Systems : Contient les fichiers sources des distributions Windows (Copies intégrales des CD ou DVD d’origine ou images .WIM issues de capture)
• Out-of-Box Drivers : Contient les fichiers de pilote tiers au format .INF nécessaires aux images WinPE et aux systèmes d’exploitation à installer
• Packages : Contient les packs de langues, correctifs et mises à jour des systèmes d’exploitation au format .CAB ou .MSU
• Applications : Contient les applications au format .MSI ou .EXE. qui seront exécutées en post-installation.
• Control : Contient les séquences de tâches à exécuter (“ts.xml”) dans des sous-dossiers, ainsi que la plupart des fichiers .xml de configuration du MDT. Au passage, j’attire juste votre attention sur la présence de 2 fichiers .INI particulièrement intéressants et importants que sont “bootstrap.ini ” et “CustomSettings.ini” sur lesquels nous aurons l’occasion de revenir.

En bref, la majeure partie des réglages du MDT est contenue dans des fichiers .XML Il fortement déconseillé de modifier ces fichiers, ou toute autre manipulation directement au sein de cette structure. En effet, la quasi-totalité des actions de configuration MDT, mais aussi les copies, renommages, déplacements, etc doivent impérativement être réalisés via la console “Deployment Workbench“.

Pour finir sur cette présentation théorique, notez que la structure MDT est “transportable”. Vous pouvez à loisir stocker vos travaux sur un disque amovible, un lecteur réseau ou un média de votre choix. Pour l’exploiter, il suffira d’utiliser une machine sur laquelle le MDT est installé, de connecter la ressource puis d’ouvrir cette structure existante à partir de la console.

III. Installation de MDT 2013

A. Téléchargements

A partir d’un ordinateur ayant un accès Internet, vous devez commencer par télécharger les éléments suivants:

Windows ADK : La version 8.1 est disponible sur le site de Microsoft  ici. Vous remarquerez que ce kit est en fait téléchargé en 2 étapes. En premier lieu vous obtenez le fichier ” adksetup.exe” qui une fois exécuté, vous proposera 2 options:

• Soit une installation en ligne via un téléchargement dynamique
• Soit un téléchargement pour une installation ultérieure – typiquement sur votre futur ordinateur MDT qui n’aura pas nécessairement d’accès à l’Internet. – Je vous conseille ce second choix pour cette démonstration.

Téléchargement du kit de déploiement

Notez que ce kit unique contient les binaires nécessaires aux architectures 32 et 64 bits.

Microsoft Deployment Toolkit (MDT) : La version 2013 est disponible sur le site de Microsoft ici. Contrairement au kit ADK, Microsoft propose des packages distincts pour les architectures 32 ou 64 bits.

Choix des fichiers à télécharger

Cochez les éléments désirés afin de les télécharger.

B. Installation

Pour installer une solution de déploiement MDT, il vous faut un poste et/ou un serveur : Pour débuter, je vous propose d’utiliser un serveur Windows 2012R2, mais un poste Windows 7, 32 ou 64 bits peut également faire l’affaire. Je considère que les fichiers précédemment téléchargés ont été déposés sur une ressource locale de cette machine telle que “F:\Download“.

En premier lieu, et après avoir installé et configuré ce serveur avec les valeurs de votre choix, vous devez installer le kit ADK en exécutant le programme “F:\Download\adksetup.exe“. Validez le chemin d’installation proposé par l’assistant, puis cliquez 2 fois sur le bouton “Suivant” puis sur “Accepter” pour le contrat de licence. Vous devrez alors choisir les fonctionnalités à installer :

Installation des outils de déploiement, de WinPE et d’USMT

Il n’est pas nécessaire de conserver toutes les fonctionnalités. Pour les besoins du MDT, vous limiter la sélection aux options suivantes :

• Outils de déploiement
• Env. de pré installation de Windows (Windows PE)
• Outil de migration utilisateur (USMT) – A conserver si vous souhaitez utiliser des scénarios qui préservent les données locales.

Note : Depuis ADK8.1, la migration Windows XP n’est plus supportée

Cochez les cases désirées puis cliquez ensuite sur le bouton “Installer“.

Une fois l’ADK installé, étant sur un serveur Windows 2012R2, donc un système 64 bits, exécutez le package “F:\Download\MicrosoftDeploymentToolkit2013_x64.msi” via un double-clic.

Démarrage de l’assistant  d’installation de MDT

Cliquez sur le bouton “Next“.

Cochez la case “I accept the terms in the License Agreement” puis cliquez sur le bouton “Next”

Conservez les fonctionnalités (features) proposées, vérifiez ou modifiez éventuellement le chemin d’installation (location) puis cliquez sur le bouton “Next“.

Conservez le choix par défaut puis cliquez de nouveau sur “Next“.

Enfin, cliquez sur le bouton “Install” puis sur le bouton “Finish” une fois l’installation achevée.

IV. 1er contact avec la console MDT 2013

A ce stade, le MDT est encore bien loin d’être opérationnel. En effet, nous avons installé les programmes nécessaires mais il reste encore à alimenter la fameuse structure évoquée précédemment.

Suite à l’installation précédente, plusieurs raccourcis de programmes ont été créés, mais seul “Deployment Workbench” vous sera utile pour l’usage des scénarios LiteTouch.

Les raccourcis “MDT”

Pour ouvrir la console MMC de gestion MDT, exécutez “Deployment Workbench“. Il est souhaitable que cet outil soit exécuté “en tant qu’administrateur“.

Console “Deployment Workbench”

Vous pouvez constater que la console d’administration du MDT est principalement organisée autour de 2 rubriques générales :

• “Information center” : Contient les explications de démarrage et les documentations et nouveautés en anglais (“Getting Started”, “Documentations”, “News”), ainsi que les liens de téléchargement relatifs aux technologies de déploiement (“Components”).

• “Deployment Shares” : Contient la ou les structures de référence que nous allons détailler ci-après. C’est à ce niveau que des structures MDT peuvent être crées ou attachées si elles existent déjà.

A. Déclaration d’un point de déploiement

Étant donné qu’il s’agit d’une présentation, nous allons procéder à la création de notre premier point de déploiement. Pour cela, sélectionnez la rubrique “Deployment Shares” puis utilisez le menu “Action … New Deployment Share” ou le menu contextuel pour créer une nouvelle structure.

Création d’un Deployment Shares

Le nom et l’emplacement proposé par défaut peut être modifié. Pour rappel, il peut s’agir d’une ressource locale (NTFS de préférence, mais ce n’est pas une obligation) ou distante sur n’importe quel serveur SMB/CIFS. Dans ce deuxième cas, vous devrez indiquer le chemin UNC et vous assurer que le partage est effectif et offre les autorisations d’accès en écriture.

Pour cet exemple, nous conservons cette proposition. Cliquez sur le bouton “Next”

Choix du nom du partage

Du fait que nous avons conservé un chemin local, l’assistant vous propose d’effectuer le partage du dossier sous le nom “DeploymentShare$“. Vous pouvez modifier ou conserver ce nom par défaut, sachant qu’il est possible d’héberger plusieurs structures MDT sur une même machine. Cliquez ensuite sur le bouton “Next“.

Description du partage

Là encore, vous allons modifier le nom en “MDT Demo” mais vous pouvez conserver le nom proposé par défaut. Celui-ci vous permet de distinguer les différentes structures que vous auriez à administrer, par exemple au sein de différents environnements. Cliquez ensuite sur le bouton “Next“.

Deployment Shares – Configuration du partage

Cette première série d’options peut être déroutante au début. En fait, il s’agit là de définir les principaux réglages qui seront appliqués par défaut aux séquences de taches. Pour votre gouverne, ces réglages peuvent être modifiés par la suite et éditant le fichier “[MDTShare]\ControlCustomSettings.ini“. Vous pouvez décocher toutes les cases si vous le souhaitez, sachant que nous reviendrons ultérieurement sur les différents écrans des séquences de taches.

Pour votre gouverne, les choix proposés ici correspondent respectivement aux valeurs suivantes :

SkipComputerBackup=NO
SkipProductKey=YES
SkipAdminPassword=YES
SkipCapture=NO
SkipBitLocker=NO

Cliquez ensuite sur le bouton “Next“, vérifiez les informations du résumé (summary) puis cliquez de nouveau sur “Next” afin de procéder à la création de cette première structure.

Une fois l’installation achevée, vous pourrez remarquer l’exécution d’un script Powershell dont vous pouvez éditer et/ou conserver le contenu, via le bouton “View script“. Par exemple :

Import-Module "C:\Program Files\Microsoft Deployment Toolkit\bin\Microsoft\DeploymentToolkit.psd1"
new-PSDrive -Name "DS002" -PSProvider "MDTProvider" -Root "C:\DeploymentShare" -Description "MDT Demo" -NetworkPath "WDS-MDT\DeploymentShare$" -Verbose | add-MDTPersistentDrive -Verbose

Cliquez sur le bouton “Finish“.

B. Vérification de la configuration initiale

A ce stade, via l’explorateur ou une invite de commande, assurez-vous de la présence d’une structure de dossiers et de fichiers, et que le partage associé est bien effectif :

dir C:\DeploymentShare /s /p
net share

De retour dans la console, votre structure MDT doit être également visible (certains dossiers sont toutefois masqués)

Le partage “MDT Demo” est créé !

Sélectionnez votre nouveau point de déploiement, ici “MDT Demo” puis utilisez le menu “Action … Propriétés” ou le menu contextuel.

Sous l’onglet “General“, vous pouvez vérifier ou modifier vos préférences initialement définies.

Accès aux propriétés du partage “MDT Demo”

Si vous souhaitez déployer qu’un seul type d’architecture, comme par exemple 64 bits, vous pouvez décocher la case “x86“. Cela permet d’optimiser sensiblement la structure et les temps de fabrication.

Nous allons maintenant nous attarder particulièrement sur l’onglet “Rules“, sous lequel vous retrouvez les 2 fichiers principaux de configuration du MDT

Aperçu des règles liées au partage MDT

Le cadre est en fait un éditeur du contenu du fichier “MDTShare]\Control\CustomSettings.ini” que vous pourriez également modifier via le bloc-notes. En revanche, pour éditer le fichier “[MDTShare]\Control\Bootstrap.ini“, la console ne propose pas d’édition directe mais un bouton “Bootstrap.ini” qui ouvrira le bloc-notes.

Nous reviendrons ultérieurement sur cet élément fondamental de configuration qu’est le fichier “CustomSettings.ini “, mais j’attire votre attention sur le fait que le fichier “Bootstrap.ini” est le premier point d’entrée d’un scénario de déploiement.

Ce fichier sera intégré lors du processus de fabrication de vos clients LiteTouch, qui nous allons évoquer juste après.

Contenu initial du fichier “Bootstrap.ini” :

Aperçu du bootstrap.ini

En l’état, il permet d’effectuer la connexion vers votre point de déploiement lors de l’initialisation du client LiteTouch. Toutefois, vous serez systématiquement invité à saisir les identifiants nécessaires à la connexion.

A ce propos, je vous suggère de créer un compte d’utilisateur (local ou de domaine) qui servira aux phases de déploiement. Il est possible de créer d’autres comptes avec des privilèges plus ou moins élevés, mais celui-ci n’a besoin que des droits de lecture sur le partage. Vous pouvez créer rapidement ce compte via la commande suivante :

net user MDT-Depl "Pa$$w0rd" /add

Pour les droits, il n’y a rien à faire du fait que les utilisateurs ont déjà un droit de lecture par défaut. Toutefois, si vous le souhaitez, vous pouvez revoir ces autorisations via les commandes suivantes:

net share DeploymentShare$ /delete
net share DeploymentShare$=C:DeploymentShare /grant:"MDT-Depl",READ /remark:"MDT Demo"

Ou plus simplement via l’interface graphique

Pour éviter l’authentification systématique, même si certains nous reprocherons une entorse à la sécurité, je vous propose donc de modifier le fichier “Bootstrap.ini” comme suit :

[Settings]
Priority=Default

[Default]
DeployRoot=WDS-MDTDeploymentShare$
SkipBDDWelcome=YES
UserID=MDT-Depl
UserDomain=WDS-MDT
UserPassword=Pa$$w0rd
KeyboardLocalePE=040c:0000040c

Si vous n’utilisez pas de compte de domaine, comme dans cet exemple, indiquez le nom ou l’adresse IP de votre serveur MDT pour la valeur de la variable “UserDomain”. La variable “KeyboardLocalePE” stipule ici un clavier de type “fr-FR”.

Pensez à enregistrer vos modifications puis fermez le bloc-notes.

Sous l’onglet “Windows PE“, vous pouvez stipuler les différentes options de fabrication des clients LiteTouch et noyaux WinPE. Détaillons maintenant cet onglet, particulièrement fourni….

Propriétés du Deployment Share – Onglet “Windows PE”

Premièrement, faites attention à la liste de choix “Platform“, en haut à gauche, qui permet de basculer sur vos préférences relatives au client 32 bits “x86” ou au client 64 bits “x64“.

Dans les 2 cas, vous disposez de 3 sous-onglets, que nous allons détailler :

1. Sous-onglet “General” :

Permet de définir le type d’image WinPE qui sera généré ainsi que certaines personnalisations.

Propriétés du Deployment Share – Sous-onglet “General”

Vous remarquerez que la première case à cocher “Generate a Lite Touch Windows PE WIM File” est obligatoirement cochée et seule le champ “Description” peut être modifié. Pour rappel, le fichier WIM généré nécessitera son insertion dans une structure d’amorçage tel qu’un serveur de déploiement WDS au niveau des images de démarrage.

Pour une utilisation autonome, incluant une structure de démarrage, cochez la seconde case “Generate a Lite Touch bootable ISO image“. Le fichier .ISO ainsi généré pourra être gravé sur un média ou bien être associé à une machine virtuelle.

Sous la partie centrale “Windows PE Customizations“, vous pouvez modifier :

• “Custom background bitmap file” : Permet de stipuler le fond d’écran de WinPE en indiquant le chemin d’un fichier bmp de votre choix. La variable %INSTALLDIR% pointe par défaut vers le dossier où vous avez installé le kit ADK (ie “C:\Program Files\Microsoft Deployment Toolkit”)

• “Extra directory to add” : Permet de stipuler un dossier quelconque (incluant par exemple vos propres outils) qui sera intégré au noyau WinPE.

• “Scratch space size” : Définit l’espace de travail temporaire affecté en complément du disque mémoire “Ramdrive” de WinPE (variable de 32 à 512 Mo) principalement utilisé par les pilotes. Evitez de modifier cette valeur sans motivation particulière.

Enfin, la zone “Generic Boot Image Settings” permet de décliner ces opérations vers un noyau générique. Autrement dit, un client dépourvu du lancement automatique du script LiteTouch. Un démarrage sur ce type d’image s’achève donc sur une simple invite de commande de WinPE.

2. Sous-onglet “Features” :

Vous trouvez ici, l’ensemble des fonctionnalités optionnelles qu’il est possible d’intégrer au noyau WinPE. Le nombre de ces fonctionnalités s’est enrichi au fil des versions et nous ne détaillerons pas ces composants dans cette présentation.

Toutefois, je ne peux m’empêcher de relever que cette mouture MDT2013 offre (enfin) la possibilité d’ajouter le framework .NET, Windows Powershell , et même des modules “cmdlet” complémentaires : Je pense que les aficionados apprécieront 

Propriétés du Deployment Share – Sous-onglet “Features”

Cet écran permet également d’ajouter quelques compléments linguistiques tels que les polices de caractères asiatiques.

Vérifiez simplement que l’option “Microsoft Data Object Components (MDAC/ADO) support” est cochée.

3. Sous-onglet “Drivers and Patches “

Cet écran est particulièrement important du fait qu’il détermine les pilotes qui seront intégrés aux noyaux WinPE. Ces réglages sont donc déterminants du bon déroulement des processus de déploiement et d’installation, et je pense qu’une petite explication s’impose.

Propriétés du Deployment Share – Sous-onglet “Drivers and Packages”

En premier lieu, vous constaterez la présence d’une liste déroulante “Selection profile” permettant de choisir un “magasin” à partir duquel les pilotes et packages seront recherchés. Notez que la console MDT permet de créer préalablement un profil de sélection, qui correspond en fait, à une sélection de dossier(s) dans la structure MDT.

Lorsque le nombre de pilotes est conséquent, il est conseillé de créer un sous-dossier contenant les pilotes propres à WinPE et de le référencer par un profil de sélection dédié. Par défaut, le profil “All Drivers and Packages” pointe vers les dossiers “Out-of-Box Drivers” et “Packages” de la structure MDT.

Note : N’oubliez pas que les pilotes peuvent être différents selon l’architecture 32 ou 64 bits.

Les noyaux WinPE n’ont pas pour vocation d’inclure tous les pilotes, mais uniquement les pilotes nécessaires à une installation. Autrement dit, le MDT distingue 4 types de périphériques particulièrement cruciaux pour les noyaux WinPE :

Pour en revenir à notre MDT, le réglage proposé par défaut, est plutôt adapté aux situations courantes puisqu’il effectue une requête de recherche des pilotes dans les dossiers référencés par le profil de sélection, en fonction de la classe de ces derniers ainsi que de l’architecture 32 ou 64 bits.

Note : Sous la rubrique “Out-of-box Drivers“, la liste des pilotes tiers présentée dans le tableau peut être triée selon les colonnes. Ainsi, en effectuant un tri sur “Platform” et “Class” vous pouvez avoir une idée précise du nombre de pilote potentiellement ajoutés dans les noyaux WinPE

Aparté sur les pilotes :

Le rangement des pilotes dans des sous-dossiers est une bonne pratique. Cela vous permettra par la suite de distribuer ces pilotes de manière ciblée sur les bons ordinateurs. Une des techniques courante de classement consiste à utiliser des noms de dossiers basés sur les variables “Make” et “Model“, soit respectivement le nom du fabriquant et le modèle d’ordinateur, pour y stocker les pilotes associés.

Pour récupérer ces informations, vous pouvez utiliser, soit :

• L’outil “msinfo32.exe“, puis identifiez les champs “Fabriquant” (Make) et “Modèle” (Model)

Exemple d’informations obtenues avec “msinfo32”

• Via Powershell

Get-WmiObject Win32_ComputerSystem | Select Model,Manufacturer

Collectez les valeurs “Manufacturer” (Make) et “Model” (Model)

• Via la console WMI

WMIC CSProduct Get Name, Vendor

Collectez les valeurs “Vendor” (Make) et “Name” (Model)

Note : L’avantage de cette dernière technique est que vous pourrez l’exécuter sur n’importe quel ordinateur à partir d’un simple invite WinPE (ie DVD d’installation via [Maj]+[F10] , Client LiteTouch via [F8] )

Sachez que les éléments stockés dans cette structure MDT peuvent être réorganisés ultérieurement. Nous reviendrons sur cette mise en œuvre des pilotes dans un prochain tutoriel dédié à la configuration avancée du MDT.

C. Génération des clients “LiteTouch”

La génération du client “LiteTouch” constitue une étape fondamentale avant la mise en exploitation du MDT. Pensez à réitérer cette opération dès lors que vous appliquez des modifications telles que l’ajout de pilotes concernant WinPE, des modifications relatives au partage MDT, et de manière plus générale, dès qu’il y a une modification des thèmes précédemment évoqués.

Pour générer (ou actualiser) la fabrication des clients “LiteTouch”, vous devez sélectionner la racine du partage dans l’arborescence de la console MDT, comme par exemple “Deployment Shares … MDT Demo” puis utiliser le menu “Action … Update Deployment Share” ou le menu contextuel.

Vous disposez alors de 2 options de génération des images :

• “Optimize the boot image updating process” – Permet de travailler sur des images existantes et permet de gagner en rapidité de création hormis la première fois. La case à cocher “Compress the boot image …” est censée optimiser la taille du noyau WinPE en supprimant les composants inutilisés.

• “Completely regenerate the boot images” – Ce processus de génération est plus long mais permet d’obtenir des images fiables. Utilisez cette option suite à des modifications importantes du MDT. Préférez cette option si vous constatez un comportement anormal des clients “LiteTouch”

Dans notre exemple, sélectionnez la seconde options puis cliquez 2 fois sur le bouton “Next“. Cette opération nécessite plusieurs minutes d’attente en fonction des performances de votre ordinateur. Cliquez sur le bouton “Finish” une fois l’opération achevée.

Vous trouverez les fichiers résultants de cette génération dans le dossier “Boot” situé à la racine du point de déploiement.

Une fois générées, les images .WIM LiteTouch peuvent ensuite être intégrées aux images de démarrage d’un serveur de déploiement Windows (WDS) afin de bénéficier du démarrage PXE et éventuellement bénéficier du mode “Multicast*” lors du déploiement des images de distribution. (cf Multicast WDS et MDT)

D. Alimentation de la structure

Maintenant que votre structure MDT est déclarée, vous devez encore l’alimenter afin qu’elle soit opérationnelle. En fait cette arborescence est principalement destinée à recueillir l’ensemble de vos sources de distribution : systèmes d’exploitation, pilotes, mises à jour et autres applications. Pensez à provisionner un espace de stockage relativement conséquent, selon l’usage prévu.

Pour votre premier essai avec MDT, il faudra ajouter à minima, un système d’exploitation Windows (NT6.x) de votre choix. Sous MDT, c’est le dossier “Operating System” qui est destiné à recevoir les sources des systèmes d’exploitation provenant des CD/DVD originaux ou d’une distribution .WIM personnalisée (issue d’une capture) – Dans le premier cas, l’ensemble de la structure du média est recopié dans ce répertoire.

Important : Commencez toujours par l’ajout d’une distribution originale de Microsoft, de type DVD ou .ISO. En effet, ce point de détail est souvent perdu dans la masse des informations relatives au MDT mais il faut considérer que l’ajout d’une image .WIM personnalisée doit se faire dans un second temps. Ceci est principalement lié au fait que le MDT n’inclus pas différents fichiers relatifs à l’installation, et réutilise ces derniers pour gérer les autres déclinaisons.

A toutes fins utiles, voici une petite illustration d’une structure de DVD Windows NT6.x

Schéma simplifié d’une structure de DVD Windows NT6.x

Pour procéder à l’ajout de la première distribution, munissez-vous du support DVD original du système d’exploitation ou du fichier .ISO correspondant – Depuis Windows 8/2012, ce format est (enfin) nativement reconnu par Windows, et vous n’avez plus besoin de recourir à des outils tiers. Pour notre exemple, nous allons ajouter l’image d’un système Windows 8.1 x64 en procédant comme suit :

Insérez le DVD dans le lecteur ou montez l’image .ISO via l’explorateur Windows

Note : Je vous passe ce conseil, qui pourra être appliqué plus tard, mais une bonne pratique consisterait à créer un sous-dossier (“New folder“) que l’on pourrait nommer par exemple “DVD Original W8.1 x64” afin d’identifier facilement l’origine de cette distribution, et la distinguer explicitement des images personnalisées que vous ajouterez par la suite.

Au niveau de la console MDT, sélectionnez le dossier “Operating System” puis utilisez le menu “Action … Import Operating System” ou le menu contextuel.

L’assistant vous demande ensuite quel type d’importation vous souhaitez entreprendre. Vous aurez alors 3 choix possibles :

Importer les sources d’un système d’exploitation

• “Full set of source files” : Intègre la copie conforme et intégrale du média de distribution du système d’exploitation. (pas uniquement l’image WIM contenue dans “Sources”)

• “Custom image file” : Intègre une image .WIM d’un système personnalisé – Typiquement une image de référence, dite “Master”, contenant des applications ou composants préinstallés.

• “Windows Deployment Services images” : Ajoute les images d’installation hébergées sur un serveur de déploiement WDS. Notez qu’il s’agit alors d’un référencement et que les fichiers .WIM demeurent sur le serveur WDS sans être recopiés dans la structure MDT. De plus, l’importation ajoute l’ensemble des images présentes, sans possibilité de sélection unitaire.

Sélectionnez la première option puis cliquez sur le bouton “Next”

Au niveau du champ “Source Directory“, utilisez le bouton “Browse” ou indiquez simplement la racine du média ou dossier contenant les sources originales puis cliquez sur le bouton “Next”

L’assistant détecte automatiquement le système d’exploitation à importer et propose un nom par défaut. Conservez ou modifiez le nom proposé puis cliquez sur le bouton “Next“. Cette valeur correspond au nom du sous-dossier qui sera créé dans l’arborescence MDT.

Vérifiez vos sélections au niveau de l’écran de synthèse puis cliquez sur le bouton “Next” afin de déclencher le processus de copie. Cliquez sur le bouton “Finish” une fois l’opération achevée.

Recommencez cette opération pour chaque système d’exploitation concerné.

Conseil : Si vous disposez de plusieurs systèmes d’exploitation, n’hésitez pas à créer et déplacer ces derniers dans des dossiers explicites tels que “x86”, “x64” afin d’épurer l’affichage et faciliter le repérage. Pour déplacer les éléments dans un dossier de la console MDT, sélectionnez-les puis utilisez la touche [MAJ] lors du déplacement. Il est ensuite nécessaire d’appuyer sur la touche [F5] pour réactualiser l’affichage.

Note : Si votre distribution .WIM contient plusieurs images, l’intégralité de ces dernières est ajoutée à la console MDT. Pour alléger l’affichage, particulièrement lorsque certaines images vous sont inutiles, vous pouvez les sélectionner puis utiliser le menu “Action … Supprimer” ou le menu contextuel.

Normalement, il faudrait poursuivre par l’installation des pilotes, des applications, voire des packages et autres mises à jour, mais pour cette présentation, nous disposons des éléments suffisants à la réalisation d’un premier déploiement automatisé via MDT.

E. Création de votre première séquence de tache

A ce stade, l’ultime étape consiste à déclarer votre première séquence de tâche de déploiement. Situé au cœur des principes du MDT, ces séquences de tâches ont en charge le pilotage des différents scénarios possibles dans le cadre d’un déploiement ou d’une fabrication d’un système Windows. Je vais donc concentrer mes explications ce premier cas d’école.

En premier lieu, au niveau de la console MDT, sélectionnez le dossier “Task Sequences” puis utilisez le menu “Action … New Task sequence” ou le menu contextuel.

Entrez un identifiant unique pour ce scénario dans le champ “Task sequence ID“. Ce nom correspond au sous-dossier qui sera créé pour y héberger les fichiers propres à cette séquence. Hormis l’unicité de cette référence, aucune règle de nommage n’est imposée mais contrairement aux autres informations, ce nom restera délicat à modifier par la suite.

Choisissez par exemple “Depl-W8x64pro-01” puis entrez une information explicite dans le champ “Task sequence Name“. Cette indication apparaitra dans le menu de l’installateur coté client au même titre que les éventuels commentaires que vous pouvez ajouter dans le champ “Task sequence Comments“. Ces champs pourront être facilement modifiés par la suite au niveau des propriétés de la séquence de tâche.

Une fois ces champs renseignés, cliquez sur le bouton “Next”

L’écran suivant vous affiche une liste de modèles prédéfinis de scénarios (séquence de taches) que nous allons décrire brièvement :

• “Sysprep and Capture” : Ce scénario est chargé de réaliser une tache de préparation d’un poste de référence via l’outil sysprep correspondant puis réalise une capture de l’image .WIM résultante vers la structure MDT. Cette image de capture peut ensuite être importée en tant qu’image personnalisée “Custom Image” de la rubrique “Operating System“.

Dans certains cas et surtout pour les néophytes, il peut s’avérer plus simple de préparer manuellement le poste de référence, puis de solliciter cette séquence dédiée à la préparation et à la capture de l’image. Contrairement aux séquences d’installation sollicitées via un démarrage à partir du client LiteTouch, ce scénario doit être déclenché à partir d’un poste opérationnel.

Autrement dit, vous pouvez procéder à la préparation et la configuration du poste en toute liberté, y compris dans un environnement virtuel. Une fois les applications, les mises à jour et les réglages achevés, vous n’avez plus qu’à solliciter cette séquence. Connectez un lecteur réseau, tel que “Z:” vers la ressource “ServeurMDT\DeploymentShare$” avec les identifiants d’un compte disposant à minima des droits d’écriture dans le sous-dossier “Z:\Captures” puis exécutez le script suivant via une connexion réseau “Z:\Scripts\LiteTouch.vbs“.

Astuce : Si vous réalisez votre image de référence à partir d’un ordinateur virtuel, exécutez une capture instantanée (snapshot) de celui-ci juste avant d’exécuter la séquence de préparation. Cette opération vous permettra de conserver une configuration type et gagner un temps précieux si vous souhaitez reprendre ou compléter une configuration existante.

• “Standard Client Task Sequence” : Ce scénario proposé par défaut est chargé de réaliser une installation traditionnelle d’un nouveau poste client.

• “Standard Client Replace Task Sequence” : Ce scénario, proche du précédent, sauvegarde préalablement l’intégralité du poste existant et exporte les paramètres et données d’utilisateur vers un chemin réseau avant d’effacer les disques et procéder à l’installation. Nécessite que le composant User State Migration Tool (USMT) soit installé préalablement installé. (cf Installation du kit ADK)

• “Custom Task Sequence” : Ce scénario ne contient aucune tâche par défaut et peut être utilisé pour effectuer des tâches ponctuelles et/ou complémentaires de déploiement.

• “LiteTouch OEM Task Sequence” : Ce scénario principalement est destiné aux intégrateurs de matériel (Original Equipment Manufacturer) et s’appuie sur un mécanisme de déploiement par média (Ne nécessite pas d’infrastructure réseau).

• “Standard Server Task Sequence” : Ce scénario est chargé de réaliser une installation d’un nouveau système d’exploitation serveur et piloter la configuration de certains rôles tels que les services DNS (Domain Name Service), DHCP (Dynamic Host Configuration Protocol), ou encore ADDS (Contrôleur de domaine Active Directory). Les directives d’installation des rôles (ou fonctionnalités) peuvent également être définies dans un fichier de réponse associé.

• “Post OS Installation Task Sequence” : Ce scénario apparu avec le MDT2010 update 1 permet d’effectuer un ensemble de tâches complémentaires à partir d’un système Windows déjà installé (indépendamment du client “LiteTouch”). Pour déclencher cette séquence, vous devrez solliciter directement le script “PartageMDT]\Scripts\LiteTouch.vbs” comme dans l’exemple précédent puis sélectionner la séquence de tache désirée.

• “Deploy to VHD Client Task Sequence” : Ce scénario apparu avec le MDT2012 permet de déployer des disques virtuels. Sous réserve de disposer d’un chargeur approprié (BOOTMGR et BCD) sur une partition physique, les éditions Entreprise et Intégrale de Windows 7 ont la capacité de démarrer nativement à partir d’un disque virtuel.

• “Deploy to VHD Server Task Sequence” : Ce scénario est identique au précédent pour les systèmes “serveur” depuis Windows Server 2008R2.

Note : Les services de déploiement Windows sont en mesure de diffuser ce genre d’image de disque virtuel au même titre que les images .WIM.

Pour revenir à notre exemple, sélectionnez la séquence par défaut, “Standard Client Task Sequence” puis cliquez sur le bouton “Next“.

La liste des systèmes d’exploitation référencés par le MDT est alors affichée.

Sélectionnez le système désiré parmi ceux installés précédemment puis cliquez sur le bouton “Next”

L’écran suivant permet de stipuler la clé de licence du produit afin d’en éviter la saisie par l’installateur.

Pour les distributions Windows 7 et ultérieures, utilisez la seconde option afin d’affecter une licence d’activation multiple (MAK : Multiple Activation Key).

La dernière option est utilisée pour stipuler une clé de licence unitaire (Retail). De fait, cette option n’est utilisable que sur une seule machine.

Aparté sur les clés de licences et le fichier de réponse :

Les clés de licences peuvent être renseignées dans le fichier de réponse “unattend.xml” (associé et propre à chaque séquence de tache). Celui-ci peut être édité via les “Propriétés” d’une séquence de tache de déploiement, sous l’onglet “OS Info“:

En cliquant sur ce bouton, un fichier catalogue (.clg) est nécessaire. En cas d’absence, celui-ci est régénéré et l’ouverture de ce contenu dans “Windows System Image Manager” (WSIM) peut alors prendre un certain temps.

Attention, selon le type d’image x86 versus x64, la génération d’un catalogue peut poser problème sur une plateforme MDT/ADK 64 bits – cf Support Microsoft

Je vous concède, que pour un néophyte, la richesse de l”interface peut paraître déconcertante !…

WSIM – Windows System Image Manager

Dans cet exemple, si vous souhaitez stipuler une clé de licence, vous devez renseigner le champ “ProductKey” situé sous le composant “…Windows-Shell-Setup_neutral“, dans la phase “4 specialise”

Cette technique peut être utilisée pour stipuler les clés de licence en volume d’entreprise KMS (Key Management Service), ou les clés par défaut – Ces dernières n’ont aucune valeur en matière d’activation mais sont imposées par les processus d’installation depuis Windows 8. Vous trouverez ces clés KMS par défaut sur le site de Microsoft : Clé KMS.

Note : Une clé KMS présente l’avantage d’être unique pour toute l’entreprise, mais nécessite un serveur d’activation au sein de cette dernière. Lorsqu’une machine dispose de ce genre de clé, la localisation du serveur est automatique sous réserve qu’un service DNS le résolve via un enregistrement de ressource SRV, de type ” _VLMCS“. Cf Microsoft Technet

Je ne souhaite pas vous égarer, mais sachez que le script “slmgr.vbs“, vous sera d’une grande utilité en matière de gestion de ces fameuses clés de licence.

A défaut d’être renseignée dans un fichier de réponse, la saisie d’une clé de licence sera proposée à l’installeur au début d’un déploiement LiteTouch à condition que la directive “SkipProductKey = NO” soit définie dans le fichier “CustomSettings.ini” ou dans la base de donnée associée à MDT.

Dans cet exemple basique, conservez l’option par défaut “Do not specify a product key at this time” puis cliquez sur le bouton “Next“.

L’écran suivant vous permet de saisir les informations de votre société habituellement relatives au propriétaire de la licence, respectivement dans les champs “Full Name” et “Organization”

Bien que facultatif, vous pouvez également préciser la page d’accueil par défaut du navigateur Internet Explorer puis cliquez ensuite sur le bouton “Next“.

L’écran suivant vous permet de saisir le mot de passe de l’administrateur local intégré. Cette donnée sensible est stockée dans le fichier de réponse correspondant sous forme encodée.

Si vous conservez la première option, “Use the specified local Administrator password“, la saisie d’un mot de passe sera proposée à l’installeur lors du déploiement LiteTouch. Ce choix correspond à la directive “SkipAdminPassword = NO” définie dans le fichier “CustomSettings.ini” ou dans la base de donnée associée à MDT.

Si vous optez pour la seconde option, “Do not specify an Administrator password at this time“, aucune saisie de mot de passe ne proposé. Notez toutefois que, pour les distributions originales, bien que désactivé par défaut, ce compte administrateur n’a aucun mot passe, et restera donc vide !… Pour vos images de référence, c’est le dernier mot de passe renseigné dans la base SAM qui sera conservé.

Pour cette démonstration, entrez un mot de passe de votre choix, puis cliquez 2 fois sur le bouton “Next” et sur le bouton “Finish” une fois l’opération achevée.

A ce stade, le scénario est opérationnel. Vous pouvez le tester à partir d’un poste, ou machine virtuelle en les démarrant à partir d’une image de client LiteTouch. (Disponibles sous le dossier “Boot” du partage de déploiement)

F. Facultatif : Une petite cerise sur le gâteau :

Malgré la relative longueur de cette présentation, vous êtes encore bien d’avoir exploré tout le potentiel de ce fabuleux outil qu’est le MDT. Toutefois, avant de conclure et sans attendre la parution d’articles complémentaires et avancés sur ces concepts, je vous propose une légère personnalisation du “Control\CustomSettings.ini“. Ceci afin d’affecter une valeur telles que le nom de votre société dans la variable “_SMSTSORGNAME” (par défaut = “IT Organization”). Par la suite, vous pourrez également jouer sur cette valeur affichée dans la barre de titre de progression, afin informer l’installateur sur une séquence de tache en cours.

Afin de lever toute ambiguïté, voici le contenu du fichier “CustomSettings.ini” utilisé dans cette démonstration.

[Settings]
Priority=Default
Properties=MyCustomProperty

[Default]
OSInstall=Y
SkipCapture=YES
SkipAdminPassword=NO
SkipProductKey=YES
SkipComputerBackup=YES
SkipBitLocker=YES

_SMSTSORGNAME=cnf1g MDT - IT Demo

V. Tests et commentaires sur le résultat attendu

Admettons que nous démarrions une machine virtuelle (sous Hyper-V afin de s’affranchir d’éventuelles difficultés sur les pilotes de carte réseau), et ce à partir des fichiers .ISO que nous avons récupéré sous le dossier “Boot”, le premier écran que vous obtiendrez après la séquence d’amorçage devrait correspondre à ceci :

Amorçage de WinPE

Page d’accueil de l’assistant “Wizard.hta”

Vous pouvez choisir le clavier approprié, via la liste “Keyboard Layout“, stipuler une adresse IP en l’absence de serveur DHCP.

Cliquez ensuite sur le gros bouton “Run the Deployment Wizard to install a new Operating System”

Vous serez ensuite invité à renseigner les identifiants nécessaires à la connexion réseau vers le serveur MDT.

Identification nécessaire à la connexion MDT

Si votre serveur MDT n’appartient pas à un domaine Active Directory, indiquez le nom ou l’adresse IP dans le champ “Domain” obligatoire.

Ces opérations deviendrons rapidement de l’histoire ancienne, si vous procédez à la modification du fichier “Bootstrap.ini” comme mentionné précédemment dans le paragraphe “Vérification de la configuration initiale“. Si vous effectuer cette modification que maintenant, n’oubliez pas de régénérer les images de vos clients LiteTouch, via le menu “Update Deployment Share”

Astuce : Si cela ne fonctionne pas, ou simplement pour vérifier, vous pouvez utiliser la touche [F8], puis taper la commandes suivantes :

type X:\Deploy\Scripts\Bootstrap.ini

net use

Si aucune connexion au lecteur “Z:” n’apparaît, tapez la commande suivante en utilisant les valeurs des éléments “DeployRoot“, “UserDomain“, “UserID“et “UserPassword” contenus dans le fichier “bootstrap.ini“, comme par exemple :

Net use z: \\WDS-MDT\DeploymentShare$ /user:WDS-MDT\MDT-Depl Pa$$w0rd

En cas d’échec, vérifiez que le dossier est bien partagé sous le nom mentionné et que l’utilisateur dispose bien des autorisations nécessaires sur le partage MDT.

Vérifiez également que cet utilisateur bénéficie à minima des autorisations NTFS en lecture sur la structure, via une simple commande “dir” ou “tree”.

tree z: | more

A. Détails d’une séquence de taches

Ensuite, les séquences de taches disponibles sont proposées. Dans notre exemple, l’unique séquence de déploiement de Windows 8 Pro 64 bits est affichée.

Notez toutefois, que le MDT a évalué que la machine utilisée était compatible avec une architecture 64 bits. Dans le cas contraire, la séquence ne s’afficherait pas. Pour un usage avancé, il est également possible de masquer, désactiver, ou ajouter une condition de client WinPE pour chaque séquence de taches.

Sélectionnez la séquence “Windows 8.1 Pro 64 bits” puis cliquez sur “Next” .

Un nom d’ordinateur, commençant par “MININT-…” est automatiquement renseigné, ainsi que la jonction à un groupe de travail “WORKGROUP“.

Dans un prochain article, dédié à la configuration avancée de MDT, nous verrons que toutes ces variables “OSDComputerName“,”JoinWorkgroup” peuvent être contrôlées et renseignées automatiquement via le fichier “customSetting.ini” ou de préférence dans une base de données associée à MDT.

Pour ce premier contact, conservez les valeurs par défaut puis cliquez sur “Next” .

Les 2 écrans suivants correspondent à la phase de migration des données et paramètres d’utilisateur alias “USMT” (User State Migration Tool) – L’utilisation de cette fonctionnalité ne sera pas détaillée ici

Dans cette démonstration, je n’ai pas choisi d’installer l’outillage USMT lors de la configuration du kit ADK. En conséquence, il aurait été judicieux de masquer systématiquement ces écrans en ajoutant la directive “SkipUserData=YES” dans le fichier de configuration global “ControlCustomSettings.ini”

Note : MDT 2013 propose de conserver les partitions existantes afin de préserver le contenu (Directive “DoNotFormatAndPartition=YES“).

Sur le premier écran concernant la sauvegarde, conservez l’option sélectionnée par défaut “Do not move user data and settings“, puis cliquez sur le bouton “Next“.

Sur le second écran concernant la restauration, conservez l’option sélectionnée par défaut “Do not restore user data and settings“, puis cliquez sur le bouton “Next“.

Si l’étape suivante vous demande la saisie d’une clé de licence, c’est que vous avez conservé la directive “SkipProductKey=NO” dans le fichier “Control\CustomSettings.ini“.

Une étape supplémentaire peut apparaître ici, si vous avez ajouté des packs de langues supplémentaires au niveau de la rubrique “packages”. Dans ce cas l’étape vous proposera d’en sélectionner en fonction de vos besoins mais le pack de langue intégré au sein du système d’exploitation choisi sera automatiquement détecté et présélectionné.

L’étape suivante vous demande de valider les préférences régionales du système d’exploitation installé.

Là encore, les préférences du système sont automatiquement détectées et présélectionnées, à l’exception du fuseau horaire. Pour automatiser systématiquement cette étape, et passer cet écran, vous devrez ajouter les directives suivantes dans le fichier “Control\CustomSettings.ini” (Pour des réglages “France Métropolitaine“)

• Pour stipuler le clavier et la langue du système installé
  

  KeyboardLocale=040C:0000040C
  UserLocale=fr-FR
  UILanguage=fr-FR

• Pour stipuler le fuseau horaire
  

  TimeZone=105
  TimeZoneName=Romance Standard Time

• Pour masquer complètement cet écran, il faut 2 directives
  

  SkipLocaleSelection=YES 
  SkipTimeZone=YES

Pour cet exemple, sélectionnez le fuseau horaire approprié puis cliquez sur le bouton “Next“.

Là encore, une étape supplémentaire peut apparaître ici, si vous avez ajouté des applications au niveau de la rubrique “Applications ” du MDT. Une liste vous sera alors proposée afin de choisir facilement celles que vous souhaitez installer. Je reviendrais sur cet aspect particulièrement important dans un prochain article sur la gestion des applications et consacré à ce sujet.

L’avant dernier écran, permettant de stipuler le mot de passe qui sera affecté au compte d’administrateur local s’affichera ou non, selon le choix retenu précédemment. Autrement dit, il s’affichera dès lors que la directive “SkipAdminPassword = NO” est définie dans le fichier “CustomSettings.ini”

Entrez le mot de passe souhaité puis cliquez sur le bouton “Next“.

Le dernier écran vous informe que la séquence est prête à commencer et affiche un résumé des paramètres, en cliquant sur le bouton “Details“.

Notez que les informations affichées ici correspondent en fait aux variables qui pourraient être stipulées dans le fichier de configuration “CustomSetting.ini” ou dans une base de données associée au MDT.

Cet écran peut être masqué en ajoutant la directive “SkipSummary=YES” dans le fichier “CustomSettings.ini”

Cliquez sur le bouton “Begin” pour démarrer l’installation.

Vous pourrez constater que la modification de la barre de titre est bien prise en compte.

Le processus d’installation est relativement long, mais ne nécessite plus aucune intervention humaine, jusqu’à son achèvement. A la fin de cette séquence, un écran de résumé des éventuelles erreurs rencontrées sera affiché.

• fond blanc : Aucune erreur
• fond jaune : Avertissements non bloquants
• fond rose : Erreur(s) bloquant(s) – La séquence a échouée

Bien que ce réglage puisse être gênant au début, cet écran peut également être masqué via la directive “SkipFinalSummary=YES” dans le fichier “CustomSettings.ini”. Toutefois, j’attire votre attention sur le fait que la session reste ouverte avec le compte administrateur en fin de déploiement, et donc exposé aux indiscrétions et malveillances éventuelles. En ajoutant une directive telle que “FinishAction=LOGOFF“, vous pourrez définir le comportement souhaité (“LOGOFF | SHUTDOWN | RESTART | REBOOT”) à l’issue du déploiement.

Test Facultatif :

La démonstration peut être achevée ici, toutefois, à partir de ce poste fraichement installé, essayez de démarrer la même séquence de tache, en connectant un lecteur réseau sur la ressource “WDS-MDTDeploymentShare$” puis en exécutant le script “ScriptsLiteTouch.wsf“.

Vous serez invité à sauvegarder les paramètres et remarquerez que le scénario de déploiement sera de type “REFRESH” et non plus “NEW COMPUTER“.

B. Les journaux d’activité et d’erreurs

Si vous rencontrez des difficultés, notez que MDT gères de nombreux journaux d’activité et d’erreurs. Les principaux (à mon avis, les plus significatifs) sont “BDD.log” et “smsts.log“. Le premier est plutôt “très fourni” du fait qu’il consigne l’ensemble des différents journaux du MDT. Le second est plutôt utilisé pour identifier des anomalies sur les séquences de taches.
L’emplacement de ces journaux change en fonction de l’avancement du déploiement :

• [Avant] sous WinPE : “X:\MININT\SMSOSD\OSDLOGS”
• [Pendant] sur l’ordinateur “C:\MININT\SMSOSD\OSDLOGS”
• [Après] sur l’ordinateur “%WINDIR%\TEMP\DeploymentLogs”

Pour terminer, sachez que ces journaux peuvent être ouverts et consultés via le bloc-notes mais la lecture risque d’être délicate et fastidieuse. Pour faciliter la lecture de ces journaux, vous pouvez également utiliser “CMTrace” (anciennement Trace32.exe) qui fait partie de l’outillage “Microsoft System Center 2012R2 Toolkit” disponible à l’adresse suivante : SC 2012 R2 Toolkit

Exemple d’affichage du journal “BDD.log” dans “CMTrace”

Complément facultatif : Durant les phases de développement, il est possible de centraliser les journaux sur le serveur MDT, mais cela engendre un trafic supplémentaire sur le réseau. Pour cela, vous devez créer un dossier partagé et accessible en lecture/écriture, comme par exemple “WDS-MDT\Logs“, puis ajouter l’une des directives suivantes dans le fichier “Control\CustomSettings.ini“.

SLShare=192.168.100.201\Logs
SLShareDynamicLogging=192.168.100.201\Logs

Préférez l’adresse IP du serveur afin de s’affranchir de la résolution de nom.

Note : A des fins de traçage et d’inventaire, sachez que les déploiements réalisés via MDT laissent des informations dans le registre “HKEY_LOCAL_MACHINE\Software\MicrosoftDeployment\4” telles que la méthode, le type et la date de déploiement, ainsi que l’identifiant, le nom et la version de la séquence de tache utilisée.

VI .Conclusion et consignes

Cette longue présentation vous a démontré comment débuter avec MDT. Il faut bien reconnaître que c’est un peu long d’alimenter cette structure au début, mais c’est un capital qui va fructifier et évoluer au fil du temps

Vous pouvez récupérer facilement vos travaux en ajoutant une structure MDT existante via le menu “Open Deployment Share“.

Faites toutefois attention aux versions de MDT. En effet, si vous tentez d’ouvrir une structure MDT existante à partir d’une version supérieure à celle utilisé pour sa création, vous serez invité à mettre automatiquement la structure. Toutefois, le retour arrière ne sera plus possible. Si vous utilisez plusieurs versions de MDT, vous devez vous astreindre à utiliser plusieurs structures MDT distinctes.

A l’heure où je rédige ces lignes, la disponibilité Windows 10 est annoncée pour les prochaines semaines. Ceci induit une mise à jour de version avec MDT 2013 Update1 (technical preview) permettant de déployer ce nouveau système d’exploitation. Vous devrez préalablement télécharger et installer le nouveau kit “Windows 10 ADK”, incompatible avec la version actuelle de MDT2013.

Afin de poursuivre cette présentation des solution de déploiement Microsoft, je vous propose de consulter mon tutoriel sur WDS  – A paraître très prochainement.

I. Présentation

Le but de ce tutoriel est de vous présenter comment transposer vos supports DVD (ou images ISO) en images toujours disponibles via le réseau.

Dans cette démonstration, je vais essentiellement vous présenter  une méthode pour ajouter des images de démarrage sur WDS, afin d’assurer l’installation, mais aussi le dépannage de vos systèmes Windows. Ainsi, l’intervenant technique n’a plus besoin de transporter une clé USB ou un support DVD, et dispose d’un outillage à jour.

II. Installation du serveur WDS2012R2

En premier lieu, vous devez installer le rôle WDS (Services de déploiement Windows). Sur un serveur Windows 2012R2, rien de plus simple et en PowerShell (v4) cela donne :

Install-WindowsFeature WDS -IncludeAllSubFeature

Pour information, le rôle “Services de déploiement Windows” est en réalité composé de 2 services de rôle (rarement dissociés sauf pour les environnements de réseaux contraints):

• Serveur de déploiement : Stocke principalement les images de démarrage et d’installation (distributions)

• Serveur de transport : Assure la gestion des flux multiples (Multicast)
  Ensuite, il suffit de lancer la console “Services de déploiement Windows” via les outils d’administration, ou le gestionnaire de serveur ou bien directement via “wdsmgmt.msc“

À la première utilisation, vous serez invité à choisir la configuration initiale :

Configuration initale suite à l’installation de WDS

Sélectionnez le nom du serveur (sur lequel l’icône d’exclamation est apposée) puis utilisez le menu “Action … Configurer le serveur” ou le menu contextuel via le clic droit.

Assistant de configuration WDS – Rappels des pré-requis

Ce premier écran affiche les recommandations d’usage de WDS et demeure très similaire à celui des versions précédentes, à la différence qu’il mentionne une nouvelle notion de “mode autonome” traitée juste après. Cliquez sur “Suivant”

Assistant de configuration WDS – Nouveauté W2012R2

À mon avis, c’est LA nouveauté de WDS 2012 R2. En effet, contrairement aux versions précédentes, le serveur WDS n’est plus obligatoirement membre d’un domaine Active Directory. C’est donc le choix que nous allons privilégier, car je pense qu’il est parfaitement adapté à un déploiement en mode atelier. Sélectionnez l’option “Serveur autonome” puis cliquez sur “Suivant“.

Assistant de configuration WDS – Stockage des images

Prévoyez un disque dur ou une partition dédiée au stockage des images WDS. Dans mon exemple, le stockage sera sur le lecteur “E:”. Notez que le stockage est obligatoirement en NTFS et sera partagé sous le nom “REMINST“. Cliquez sur “Suivant“.

Assistant de configuration WDS – Réponse aux clients PXE

Cet écran permet d’éviter que le serveur réponde à n’importe qui (alors qu’il n’est pas encore prêt).. Notez simplement, qu’un “client connu” est un ordinateur dont l’identifiant unique (Adresse MAC ou UUID) a été renseigné dans la base WDS (ou Active Directory) ou une machine préalablement installée par WDS. Pour cette démonstration, choisissez la 3ème option puis cliquez sur “Suivant“.

Assistant de configuration WDS – Application des réglages et  initialisation des services

Le dernier écran vous propose de poursuivre cette phase de configuration initiale par l’ajout d’images .WIM sur le serveur. En insérant un DVD d’une distribution, l’essentiel serait fait, et cet article perdrait une partie de son intérêt

Assistant de configuration WDS – Fin de la configuration minimale

Décochez cette case puis cliquez sur “Terminer”

III. Ajout des images de démarrage

Les images de démarrage sont pour WDS des noyaux WinPE (~boot.wim) permettant de charger l’outillage nécessaire à l’installation d’un système Windows, d’effectuer une capture d’image de référence ou des opérations de maintenance.

A. Images de démarrage de type “Setup”

C’est l’image la plus facile à intégrer dans WDS puisque ce noyau est directement disponible par défaut sur toutes les distributions Windows NT6.x . Pour l’intégrer sur un serveur WDS, rien de plus simple. Il suffit d’insérer le DVD, dans mon exemple Windows 8.1 64 bits, puis de sélectionner la rubrique “Images de démarrage” dans la console WDS.

Utilisez ensuite le menu “Action … Ajouter une image de démarrage…” ou le menu contextuel. Utilisez ensuite le bouton “Parcourir” afin de sélectionner le fichier “[DVD]:\Sources\Boot.wim”

WDS : Ajout d’une image de démarrage

Cliquez sur “Suivant“. (Les métadonnées du fichier .WIM sont alors affichées)

Modifiez éventuellement le contenu par “Installation Windows 8.1 (x64)” puis cliquez deux fois sur “Suivant“. Cliquez sur “Terminer” une fois que l’image a été ajoutée correctement sur le serveur.

À ce stade, nous avons ajouté une seule image d’amorçage et les clients PXE démarreront sur celle-ci sans afficher aucun menu de démarrage. Nous allons donc ajouter une seconde image de démarrage afin d’afficher un menu au niveau des clients PXE.

B. Image de démarrage de type “Capture”

Là encore, vous n’êtes peut-être pas familiarisé avec les mécanismes de WinPE, mais la console WDS vient à votre secours en proposant la génération automatique d’une “image de capture“. Ce genre d’image est destinée aux préparateurs des postes de référence (master) qui suite à une préparation d’un système avec SYSPREP, doivent réaliser une capture afin de générer une image WIM qui sera généralisée plus tard. Cette opération peut être réalisée via l’outil “WDSCapture” (là encore, présent par défaut sur les DVD des distributions Windows NT6.x .. ).

Pour ajouter ce type d’image sur un serveur WDS, il faut préalablement sélectionner une image “compatible” de démarrage dans le volet de détail (c’est le cas des images de type “Setup” issues des DVD qui contient déjà le package nécessaire). Utilisez ensuite le menu “Action … Créer une image de capture” ou le menu contextuel.

Dans la fenêtre de l’assistant, modifiez éventuellement le nom et la description de l’image par “Capture d’un poste de référence (x64)” et utilisez le bouton “Parcourir” pour définir l’emplacement du fichier temporaire modifié. Sélectionnez un espace de stockage temporaire afin de créer un nouveau dossier, comme par exemple “E:\Temp” puis entrez un nom de fichier résultant “WDSCapture.wim” (Les noms importent peu et les métadonnées pourront être modifiées ultérieurement).

Création d’une image de capture

Cliquez sur “Suivant” et laissez le processus s’exécuter (plusieurs minutes)

Pour votre gouverne, cette opération consiste à extraire l’intégralité du fichier .WIM original, créer un fichier “WINPESHL.ini” (un des points d’entrée d’exécution automatique de WinPE), d’y inclure la directive de lancement de l’outil de capture, puis de re-capturer le tout dans une version modifiée, c’est dire le fichier “WDSCapture.wim“.

Contenu du fichier “WINPESHL.ini”:

[LaunchApps]
%SYSTEMROOT%\system32\wdscapture.exe

Une fois le processus achevé, vous aurez la possibilité de l’incorporer aux images de démarrage.

Cochez la case “Ajouter une image au serveur de déploiement Windows” puis sur le bouton “Terminer“. L’assistant d’ajout d’image doit alors s’ouvrir, et le fichier de l’image modifiée est automatiquement proposé par défaut.

Cliquez sur “Suivant” et modifiez le nom et la description de l’image par “Capture d’un poste de référence (x64)”

Cliquez deux fois sur “Suivant” puis sur “Terminer” une fois que l’image a été correctement ajoutée sur le serveur.

À ce stade, les clients PXE disposeront d’un menu leur offrant les 2 choix de démarrage pendant 30 secondes. Le premier étant sélectionné par défaut.

Note : L’ordre de ce menu est uniquement basé sur l’ordre alphabétique du nom des images.

C. Image de démarrage de type “Réparation “

En “dématérialisant” nos DVD originaux, nous oublions souvent une option intéressante, la capacité de “Réparer l’ordinateur” – Mais si, rappelez-vous, le choix en bas à droite des écrans d’installation

Cet outil, dénommé “WinRE“, pour “Recovery Environment“, permet d’effectuer des opérations de dépannage de l’amorçage, d’utiliser un point de restauration, une sauvegarde ou encore de lancer une invite de commande WinPE.

La récupération de ce noyau est quelque peu abrupte, mais je pense que le jeu peut en valoir la chandelle… Pour la démonstration, nous allons récupérer l’environnement de réparation d’un système Windows 8.1 64 bits (Mais le principe reste le même pour une distribution Windows 7, 32 ou 64 bits).

Pour cela, vous devez insérer le support d’une distribution Windows 8.1×64 sur le serveur WDS.

• Créez ensuite un dossier vide pour le montage de l’image

mkdir E:\Temp\Mount

• Puis procédez au montage de l’image de la distribution “[DVD]:\Sources\install.wim“

dism /mount-Wim /WimFile:F:\Sources\Install.wim /Index:1 /MountDir:E:\Temp\Mount /ReadOnly

• Le montage de l’image prend quelques secondes. Copiez ensuite le noyau winRE vers un dossier temporaire

copy E:\Temp\Mount\Windows\System32\Recovery\winRE.wim E:\Temp

• Puis procédez au démontage de l’image

dism /Unmount-Wim /MountDir:E:\Temp\Mount /discard

Ouvrez (ou retournez dans) la console WDS, sélectionnez la rubrique “Images de démarrage” puis utiliser le menu “Action … Ajouter une image de démarrage” ou le menu contextuel. Utilisez le bouton “Parcourir” pour sélectionner le fichier “C:\Temp\WINRE.wim” précédemment copié.

WDS : Ajout d’une image de “réparation”

Cliquez sur “Suivant“, puis renommez éventuellement l’image “Réparer l’ordinateur W8.1 (x64)”
Cliquez sur deux fois sur “Suivant” puis cliquer sur “Terminer” une fois que l’image a été correctement ajoutée au serveur WDS.

À ce stade, voici ce qu’un poste démarrant via PXE obtiendra:

Exemple de menu affiché du coté du client PXE (F12)

D. Image de démarrage de type “LiteTouch “

Pour rappel, WDS et MDT sont indépendants, mais aussi complémentaires (Voir mon article consacré à une vue d’ensemble de MDT, WDS et WinPE).

En fait, MDT a en charge la “fabrication” des séquences d’installation des systèmes et peut très bien assurer seul, les taches de capture et de déploiement. Toutefois, pour les déploiements en masse, l’usage des multidiffusions via WDS peut s’avérer rapidement séduisant. La mise à disposition des clients LiteTouch au travers un amorçage PXE (donc WDS) est aussi une excellente motivation à l’usage de WDS en complément d’un environnement MDT.

Pour ajouter un client LiteTouch, il suffit de récupérer les fichiers “LiteTouchPE_x64.wim” et/ou “LiteTouchPE_x86.wim” situés dans le dossier “\Boot” du partage MDT (DeploymentShare). Assurez-vous qu’ils soient présents et à jour en effectuant un “update”, surtout si vous avez ajouté des pilotes ou modifié le “bootstrap.ini”.

Note : Pour ceux qui débuteraient avec MDT, il n’y a rien dans ce dossier tant que vous n’en avez pas lancé la fabrication. Pour y remédier, démarrez la console “Deployment Workbench“, sélectionnez le nom de votre MDT situé sous la rubrique “Deployement Shares” puis utilisez le choix “Update Deployment Share” via le menu contextuel.

Dans l’assistant, cochez éventuellement l’option “Completly regenerate the boot images“.

Régénération des images de clients LiteTouch

Cliquez 2 fois sur “Next” puis sur “Finish” (après quelques minutes d’attente…)

Ensuite, pour ajouter une image de démarrage LiteTouch, il suffit de lancer la console WDS puis de sélectionner la rubrique “Images de démarrage“. Utilisez ensuite le menu “Action … Ajouter une image de démarrage…” ou le menu contextuel.

Ajout d’un client LiteTouch dans WDS

Entrez ensuite le chemin UNC de l’un des fichiers générés tel que “\\ServeurMDT\DeploymentShare\Boot\LiteTouchPE_x64.wim” puis cliquez sur “Suivant“.

Modifiez éventuellement les métadonnées du fichier .WIM qui vous sont proposées puis cliquez deux fois sur “Suivant“. Cliquez sur “Terminer” une fois que l’image a été ajoutée correctement sur le serveur.

Au besoin, réitérez cette opération pour ajouter le client LiteTouch 32 bits.

Note : qu’il est souhaitable de disposer de clients WinPE 32 et/ou 64 bits selon les architectures des systèmes déployés. De plus, si vous disposez de plusieurs points de distribution MDT, vous devrez décliner les clients LiteTouch en conséquence.

IV. Ajout des images d’installation

Précédemment, nous avons ajouté des images de démarrage, mais pour parachever cette configuration, il reste encore à ajouter une ou plusieurs distributions (Équivalentes au fichier “INSTALL.wim” d’un DVD original).

Pour votre gouverne, notez que WDS utilise une gestion très particulière de ces images. En effet, habituellement, un fichier .WIM est composé d’une ou plusieurs images disque (Structure de dossiers et de fichiers) et des métadonnées XML décrivant le contenu. Vous pouvez consulter ces métadonnées via des outils spécialisés tels que “DISM ou IMAGEX /INFO…”

En fait, WDS utilise un dossier dédié, appelé “Groupe d’images” dans lequel il stocke un fichier unique de “ressource” nommé “RES.RWM” et un fichier .WIM de métadonnées uniquement, et ce par image. Ainsi, un fichier INSTALL.wim, contenant 5 images (déclinaisons d’installation) engendre un fichier de ressource unique .RWM et 5 fichiers de descriptions portant l’extension .WIM.

Ces répertoires seront utilisés pour ajouter des images de même type (c’est-à-dire proches l’un de l’autre) et éventuellement de définir des autorisations NTFS qui limiteront la visibilité d’un installateur. Vous pouvez également créer un groupe d’image vide, qui sera destiné à recevoir les captures des postes de référence si vous utilisez WDS pour réaliser cette tâche. Généralement, je préconise l’utilisation de MDT pour la fabrication des images de référence, puis de procéder ensuite au transfert vers WDS au même titre que les distributions originales.

Nous allons illustrer cette procédure en ajoutant la distribution actuellement présente dans le lecteur DVD de notre serveur WDS.

Sélectionner la rubrique “Images d’installation” dans la console WDS, puis utiliser le menu “Action … Ajouter un groupe d’images” ou le menu contextuel.

WDS : Groupe d’images d’installation

Entrer un nom significatif des images qui y seront ajoutées, comme par exemple “DVD-W8.1×64“.

Note : N’hésitez pas à créer autant de groupes que nécessaire même s’ils ne contiennent qu’une seule image. En effet, ces “dossiers” ne sont pas visibles au travers des écrans d’installation des postes clients, mais permettent de maitriser les images proposées aux installateurs en agissant sur la sécurité NTFS de ces groupes.

Cliquez sur le bouton “OK” – Sélectionnez le groupe d’image nouvellement créé puis utilisez le menu “Action … Ajouter une image d’installation” ou le menu contextuel. Utilisez le bouton “Parcourir” afin de sélectionner le fichier “DVD]:\Sources\INSTALL.wim”

WDS : Ajout d’une image d’installation

Cliquez sur le bouton “Suivant”

En fonction de la distribution utilisée, vous serez invité à choisir les images contenues dans le fichier .WIM.

Notez simplement qu’elles sont toutes sélectionnées par défaut, et que vous pourrez toujours les supprimer a posteriori. L’assistant récupère les noms et descriptions (Métadonnées), mais vous laisse la possibilité de modifier ces informations lors de l’importation.

Cochez ou décochez les cases souhaitées puis cliquez 2 fois sur “Suivant” et sur “Terminer” une fois que les images ont été correctement ajoutées au serveur.

Recommencez ces opérations pour chacune des images que vous souhaitez importer sur le serveur WDS.

Note : Pour ceux qui l’ignorerait, je précise qu’une image de démarrage de type “setup” réalisé à partir de Windows 8.1 peut parfaitement servir au déploiement de systèmes antérieurs tels que Windows 7 ou même Windows serveur. Le seul critère étant de respecter la préparation des images via sysprep afin garantir un déploiement selon les règles de l’art.

Une fois les distributions “install.wim” ajoutées en tant qu’image d’installation, vous pourrez remettre vos précieux DVD dans leurs jolies boites, puis les placer sur l’étagère de votre bureau en guise de décoration

V. Gestion des pilotes

Depuis Windows 2008R2, la console WDS propose un mécanisme de gestion des pilotes (un vaste sujet en matière de déploiement). Si je me réfère à mon expérience de terrain, la plupart des entreprises optent pour une gestion des pilotes (propres à leur parc informatique) via la solution MDT.

En effet, ce dernier offre une grande souplesse pour une distribution ciblée des pilotes selon les modèles de machines et contrairement à WDS, permet d’installer certains pilotes récalcitrants de type “exécutable” comme des “applications”.

Pour faire court, il faut distinguer les pilotes critiques à l’installation, tel que ceux des cartes réseau (Net), stockage (Mass Storage), puces spécifiques (Chipset), et éventuellement certains pilotes vidéo, des autres pilotes plus considérés comme “accessoires”.

En effet, les premiers doivent être intégrés aux noyaux WinPE afin d’assurer les phases préliminaires d’installation. Le MDT gère nativement l’injection de ces pilotes particuliers lors de la fabrication des clients LiteTouch 32 et 64 bits.

Pour WDS, le procédé est à mon avis moins granulaire, et surtout, il ne sera pas automatique. Donc, même si la console graphique simplifie considérablement l’injection en vous évitant de passer par DISM en ligne de commande, la procédure demeure manuelle avec le risque d’erreur ou d’oubli associé.

En conclusion, hormis pour l’injection ponctuelle de pilotes dans les images de démarrage, je pense que la gestion des pilotes via WDS est inutile dès lors que vous disposez d’un environnement MDT. Il est dommage que Microsoft ne propose pas encore un moyen de relier directement le magasin des pilotes MDT au mécanisme de gestion WDS, mais la gestion des pilotes au sein de la console WDS reste toutefois intéressante pour ceux qui ne seraient pas encore convaincus des nombreux avantages apportés par MDT

Bien à vous
Christophe

I. Présentation

L’idée de cet article consiste à rassembler l’ensemble des informations utiles pour une exploitation maîtrisée et efficace de l’environnement WinPE. Pour les rares lecteurs qui ne le sauraient pas encore, “Windows Pre-execution Environment“, alias “WinPE“, est un système autonome basé sur un noyau Windows minimaliste destiné aux opérations d’installation, de déploiement et de maintenance. La notion de client “LiteTouch” que nous allons régulièrement évoquer est en fait une version adaptée de WinPE pour un usage avec la solution de déploiement gratuite “Microsoft Deployment Toolkit“, plus connue sous le nom de “MDT“.

II. Les grandes lignes

A. Où peut-on trouver WinPE ?

J’aurais tendance à vous dire “pratiquement partout”, dès lors que vous avez procédé à une installation de Windows depuis Vista. Il est gratuit et ouvert à de nombreuses personnalisations sous réserve de ne pas le détourner de son usage de maintenance. Vous pouvez donc trouver WinPE :

• Sur un DVD d’installation de génération Windows NT6 (Y compris les versions d’évaluation)
• Le générer à partir d’un kit WAIK ou ADK
• Le générer à partir de MDT afin d’obtenir un client LiteTouch et/ou WinPE générique

B. Ouvrir l’invite de commande WinPE

Nous reviendrons plus en détail sur cette notion, mais sachez que sous WinPE, il est pratiquement toujours possible d’ouvrir une invite de commande en cas de besoin. Il y a toutefois une petite nuance en fonction de l’image utilisée :

• Démarrage à partir d’un DVD ou d’un noyau générique
  Utilisez [Maj] + [F10]

• Démarrage à partir d’un client LiteTouch
  Utilisez  [F8] (Depuis MDT2012, cette faculté peut être inhibée)

C. Les versions

Les versions de WinPE ne sont pas vraiment évidentes à définir, surtout lorsque certains articles de Microsoft s’emmêlent les pinceaux : C’est pourquoi je préfère m’appuyer sur la version des noyaux système. Voici un tableau de synthèse, certes perfectible, qui résume la situation constatée selon la valeur du registre (depuis WinPE 3) :

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinPE.

Depuis la génération NT6, le “x” correspond au numéro du “service pack” :

Plus d’info sur : What’s New in Windows PE

III. Utiliser WinPE

A. Commandes utiles

Voici une liste non exhaustive des commandes pouvant vous être utiles dans cet environnement minimaliste. Avant toute chose, je vous précise quelques points de détail qui pourraient s’avérer importants pour la suite :

• Sous WinPE, il n’y a aucune notion de session, d’où la nécessité de stipuler des identifiants pour des connexions réseau par exemple.

• Sous WinPE, il n’y a pas de bureau, ni d’explorateur, ni de console d’administration. Vous disposez toutefois de quelques outils graphiques tels que regedit, notepad, intl.cpl…

• Sous WinPE, il n’y a pas de sous-système (“WindowsOnWindows“), ce qui implique que les binaires exécutés doivent correspondre à l’architecture du noyau utilisé 32 ou 64 bits.

• Certaines commandes, telles que WMIC, Setup, PowerShell… nécessitent que les composants (features) correspondants soient activés dans le noyau concerné.

J’espère donc que vous n’êtes pas trop allergique à la ligne de commande…

B. Exemple d’outils complémentaires

Comme indiqué précédemment, l’ajout d’outils au sein de WinPE peut vous être utile, surtout lorsque la ligne de commande vous rebute un peu. Voici donc quelques outils que je trouve personnellement bien pratiques, mais là encore, la liste est loin d’être achevée.

Commande	Utilité	32 bits	64 bits
Explorer++	Explorateur graphique de dossier et fichiers. Il en existe d’autres tels que A43, ou Q-Dir, mais ils ne sont pas tous disponibles pour les 2 architectures	Oui	Oui
7-Zip	Gestionnaire d’archives. Disponible en version 32 et 64 bits.	Oui	Oui
GImageX	Alternative graphique à l’outil en ligne de “imagex”(Note : 7-Zip est en mesure d’explorer les .WIM)	Oui	Oui
Diskpart	Présent par défaut : Je n’ai pas d’équivalent graphique et gratuit à vous proposer… hormis l’outil PowerShell http://www.alexcomputerbubble.com/category/diskpart/ En dépannage vous pouvez utiliser les premiers écrans du programme d’installation “\Sources\Setup.exe”, adaptés au partitionnement et formatage des disques
	Au besoin, recherchez les applications gratuites dites “portables” (sans installation) puis testez-les dans cet environnement. N’oubliez pas de rester dans un cadre de maintenance

IV. WinPE en profondeur

Pour les plus curieux d’entre-vous, je propose de pousser cette étude un peu plus loin afin de découvrir quelques aspects intrinsèques de WinPE.

A. Le processus d’amorçage de WinPE

Sans trop entrer dans les détails, il convient de préciser que le processus d’amorçage de WinPE est sensiblement différent en fonction du média utilisé au démarrage.

Parmi ces médias, on trouve :

• Le réseau PXE (Pour Microsoft, ce service est offert au travers de WDS) – Le processus particulier d’amorçage ou bootstrap, n’est pas détaillé ici.

• Le disque dur ou la clé USB exploitent le secteur d’amorçage principal (MBR) à partir d’une partition principale active, sauf en cas d’UEFI ou le mécanisme est sensiblement différent.

• Le support CD ou DVD contient une amorce spécifique de type “el-torito” – La présence du fichier “\boot\bootfix.bin” engendre un message de confirmation

Le chargement du noyau est initialisé par le programme “Bootmgr” à partir des informations contenues dans le magasin d’amorçage “\boot\BCD”

Note : Comparativement aux versions antérieures de Windows NT, on peut approximativement considérer que “Bootmgr” correspond à “NTLDR” et “BCD” est équivalent à “boot.ini“

Schéma du processus d’amorçage

B. Structure de WinPE

La structure d’un noyau WinPE et plus globalement des éléments qui l’entourent est particulièrement complexe et un néophyte peut rapidement y perdre son latin. Afin de se repérer plus facilement, entre les composants, les pilotes de périphériques, les commandes internes et l’outillage de fabrication, j’ai imaginé le schéma suivant :

Explications :

Au centre de l’illustration, on trouve le noyau à proprement parler, alias “boot.wim“. C’est le système Windows chargé en mémoire et portant toujours la lettre “X:”. Pour visualiser ou modifier un contenu de noyau, il faut effectuer un montage via la commande DISM /Mount-WIM …

A l’intérieur du noyau, on peut principalement distinguer un nombre variable de pilotes (Drivers) et de fonctionnalités (Features), ainsi que des packages linguistiques. Vous pouvez en obtenir la liste via la commande DISM /Get-… La plupart des fonctionnalités sont déjà intégrées au sein des distributions originales Microsoft, mais vous les trouverez aussi dans les kits de déploiement WAIK ou ADK pour un ajout à la demande.

Ensuite, pour qu’un noyau “boot.wim” soit exploitable, il faut le déposer sur un média et lui associer un chargeur “bootmgr” ainsi qu’une configuration d’amorçage définit dans le fichier “\Boot\BCD“. L’outil de gestion par excellence est “BCDEDIT“, mais pour régénérer simplement une amorce de base, je vous conseille l’outil “BCDBOOT“. Ces 2 outils sont présents par défaut sur tous les systèmes Windows NT6.x

L’utilisation d’un média de type CD/DVD nécessite l’ajout d’une amorce particulière dénommée “El-Torito” et définie dans le fichier “ETFSBOOT.com“. Pour associer cette amorce et générer l’image .ISO, il suffit d’utiliser l’outil “OSCDIMG” fournit dans les kits de déploiement WAIK ou ADK.

C. Lancements automatiques “Autorun”

Lors du chargement d’un noyau WinPE, il est particulièrement intéressant de remarquer qu’il existe plusieurs points d’entrée permettant d’exécuter automatiquement des commandes, des scripts ou tout autre type de programme.

En analysant le processus d’amorçage d’un noyau WinPE, (ie “\Sources\boot.wim“) on peut constater que l’enchaînement dépend en fait de la présence des certains fichiers :

D. Organigramme des processus

Le processus de démarrage de WinPE est variable selon le type de noyau analysé. J’ai donc essayé de représenter un schéma décrivant les enchainements des noyaux courants que vous pourriez trouver sur une distribution originale Microsoft, un client LiteTouch et quelques déclinaisons WDS :

L’illustration étant déjà suffisamment riche en l’état, je commencerais donc mes explications après le chargement initial du chargeur “bootmgr”. (Il vous faut donc commencer la lecture ou le déchiffrage de ce “workflow” en haut à gauche )

Schéma de principe d’une initialisation WinPE

Explications :

Le point d’entrée clé de WinPE est le programme d’initialisation “winpeshl.exe” situé dans le dossier “X:\Windows\System32“. Celui-ci est référencé dans la clé de registre “HKEY_LOCAL_MACHINE\SYSTEM\Setup” au sein de la valeur “cmdline= winpeshl.exe”

Une fois ce programme lancé, vous bénéficiez de la séquence de touches [Maj] + [F10] pour ouvrir une invite de commande à tout instant.

Ce programme vérifie ensuite la présence d’un fichier “winpeshl.ini” situé dans le dossier “X:\Windows\System32“. Si celui-ci existe, il exécute séquentiellement les commandes qu’il contient. On peut y trouver les rubriques suivantes

[LaunchApp]
AppPath =

Pour l’exécution d’un programme unique sans paramètre :

[LaunchApps]
Application1.exe, option1, option2
Application2.exe, option1

Pour l’exécution de un ou plusieurs programme(s) avec ou sans paramètre(s)

Voici quelques exemples typiques de fichier “winpeshl.ini”

• Client LTI

[LaunchApps]
%SYSTEMROOT%\System32\bddrun.exe,/bootstrap

• Client LTI sans F8

[LaunchApps]
%SYSTEMROOT%\System32\bddrun.exe,/BootstrapNoSF8

• WinRE

[LaunchApp]
AppPath=X:\sources\recovery\recenv.exe

• Image de Capture

[LaunchApps]
%SYSTEMROOT%\system32\wdscapture.exe

• Image de Découverte

[LaunchApps]
%SYSTEMDRIVE%\sources\setup.exe,"/wds /wdsdiscover /WdsServer:WDS.labo.local"

• DaRT

[LaunchApps]
%windir%\system32\netstart.exe,-prompt
%SYSTEMDRIVE%\sources\recovery\recenv.exe

Par défaut, la fermeture du dernier programme lancé engendre un redémarrage de WinPE. Vous pouvez contrôler ce comportement en ajoutant le lancement d’une invite de commande, puis éventuellement solliciter un redémarrage via la commande “wpeutil reboot“.

Remarque : La particularité d’un client LiteTouch réside dans l’exécution de “bddrun.exe” dont le commutateur “/Bootstrap” déclenche l’exécution du programme “wpeinit.exe” qui va lui-même tester la présence d’un fichier “X:\unattend.xml” et le cas échéant, traiter les informations qu’il contient. L’appel de l’invite de commande s’effectue alors via [F8].

Si le fichier “winpeshl.ini” n’existe pas, le processus teste la présence à la racine (X:\) du fichier “Setup.exe“. C’est typiquement le programme d’accueil d’une distribution d’installation Windows, à ne pas confondre avec “X:\Sources\Setup.exe” qui correspond au programme d’installation. Bien que déconseillé, sachez qu’en remplaçant “X:\Setup.exe” par un exécutable quelconque, tel qu’un navigateur de fichiers comme “Explorer++”, ce dernier sera exécuté.

Par défaut, cet écran d’accueil vous propose l’installation ou la réparation d’un système. Dans le premier cas, l’installation recherche un fichier “Autounattend.xml” sur la racine de tous les médias accessibles, et le cas échéant, traite les informations qu’il contient.

Particularité : Lors d’un démarrage via PXE /WDS, le processus d’accueil “X:\Setup.exe” passe directement à l’exécution du programme d’installation “X:\Sources\Setup.exe“, qui affiche alors cet écran spécifique aux “Services de déploiement Windows”.

Setup et WDS : Ecran d’accueil typiquement affiché

Si le fichier “X:\Setup.exe” n’existe pas, c’est alors le batch “Startnet.cmd” situé dans le dossier “X:\Windows\System32“, qui est exécuté. Par défaut, ce fichier existe dans tous les noyaux WinPE et ne contient que la commande “wpeinit “.

Ce batch est modifiable, pour y inclure toute sorte de commandes dont vous auriez besoin. Il est toutefois important de relever que l’exécution de “wpeinit ” permet d’exploiter le contenu d’un fichier “X:\unattend.xml“, voire de stipuler un fichier de configuration spécifique “wpeinit /unattend:X:\CustomWinPE.xml“.

Astuce : Pour initialiser uniquement les couches réseau, utilisez la commande “wpeutil InitializeNetwork”

La suppression du fichier “Startnet.cmd” engendre une erreur, mais dans tous les cas  l’exécution se termine sur une invite de commande.

Note: Pour le débogage, il est intéressant de savoir que l’exécution des programmes Winpeshl.exe et Wpeutil.exe génèrent leur journal respectif : “Winpeshl.log” et “Wpeutil.log“

La gestion et la création des fichiers de réponse .XML peut être réalisée via l’outil “Windows Image System Manager” (WISM) apporté par les kits WAIK ou ADK, mais l’usage peut s’avérer très vite déconcertant. Aussi, l’utilisation du bloc-notes à partir d’un modèle ou d’un exemple sera plus rapide à mettre en œuvre. J’attire toutefois votre attention sur le fait qu’il faut impérativement respecter l’architecture stipulée (“amd64” ou “x86”), sous peine que le fichier .xml ne soit pas traité.

Exemple de fichier .xml :

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
    <settings pass="windowsPE">
        <component name="Microsoft-Windows-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State">
            <Display>
                <ColorDepth>32</ColorDepth>
                <HorizontalResolution>1024</HorizontalResolution>
                <RefreshRate>60</RefreshRate>
                <VerticalResolution>768</VerticalResolution>
            </Display>
        </component>
    </settings>
</unattend>

V. Conclusion

Véritable pierre angulaire des solutions de déploiement, WinPE constitue un extraordinaire socle d’outils pour la maintenance et le déploiement Windows. Au fil de mes articles, vous découvrirez sa richesse et son extraordinaire potentiel.

Bien à vous

Christophe

A suivre : Personnalisation de WinPE

I. Présentation

Pour faire suite au tutoriel précédent sur vos débuts avec MDT 2013, je vous propose d’entrer un peu plus dans les détails de la configuration associée à cette solution de déploiement très flexible. Le but recherché étant de réduire au maximum les actions lors de l’installation.

Je ne vais pas dresser l’apologie de MDT, mais je suis intimement convaincu que derrière cet air de complexité, se cache un outil aux capacités presque sans limites et vos efforts pour l’appréhender seront certainement récompensés rapidement. Je reconnais que les premiers contacts avec MDT peuvent être déconcertants et on peut être découragé certains d’entre vous, mais je vous conseille de persévérer, car la communauté est toujours plus active, de jour en jour. En ce qui me concerne, depuis de nombreuses années, j’ai relégué le clonage et la multiplication des masters à de vieux souvenirs. Et avec MDT, cette époque est bien révolue, et je suis persuadé que vous n’aurez surtout plus l’envie d’y revenir…

Ce tutoriel a donc pour but de vous expliquer des concepts avancés afin de comprendre et maitriser la configuration des fichiers CustomSetting.ini et bootstrap.ini et introduire une éventuelle extension vers la base de données. Je reconnais que le sujet est plutôt vaste et qu’il existe d’autres angles d’approche, plus synthétiques, comme par exemple cet article ou un article TRÈS pointu comme  celui-ci

Le plus délicat pour moi était donc de choisir la position du curseur de complexité que je souhaitais vous présenter. La marche de progression est peut-être un peu haute et veuillez donc m’excuser par avance pour ces choix arbitraires. J’espère que chaque lecteur y trouvera son compte, et à défaut de réponse, des pistes pour avancer dans ces investigations ou l’apprentissage de MDT.

II. Un peu de théorie

Une fois de plus, avant d’aborder le vif du sujet, il convient d’insister sur quelques points importants des mécanismes MDT. Précédemment, vous avez constaté que le MDT utilise de nombreux scripts vbs, wsh et fichiers .xml afin de gérer les différents cas de figure possibles, mais rassurez-vous, il ne s’agit surtout pas d’aller modifier ces fichiers. Même les spécialistes ne s’y aventurent que rarement, en dernier recours, et je vous assure qu’il y a une grosse marge de manœuvre avant d’en arriver là.

A. Les variables ou propriétés

Ce qu’il faut en premier lieu comprendre, c’est que les différents scénarios MDT réagissent en fonction de “variables“, dont certaines sont positionnées dynamiquement selon l’environnement détecté et d’autres, plutôt destinés, à modifier le comportement par défaut des séquences de taches. On parle aussi de “propriétés” pour désigner ces variables. Ne vous offusquez pas, mais pour ma part, j’ai pris l’habitude de parler de “directive” pour désigner une variable, ou une propriété ET sa valeur.

Nous verrons qu’il est également possible de déclarer des propriétés personnalisées et/ou des valeurs dynamiquement calculées.

Vous trouverez une description sur chacune de ces variables en sollicitant l’aide intégrée à la console MDT via [F1] ou la documentation “Toolkit Reference.docx” associée au téléchargement de MDT. Accrochez-vous, le document frise les 500 pages !…

Si vous n’êtes pas persuadé de cette richesse, je vous invite à utiliser l’outil fournit ici par l’équipe Microsoft “deploymentguys“,  comme ceci :

.\DeclareProperties.ps1 -deploymentshare C:\DeploymentShare -inifile C:\DeploymentShare\Control\CustomSettings.ini -ztigatherfile C:\DeploymentShare\Scripts\ZTIGather.xml -outputFile MDTVariables.txt

On obtient un fichier d’un peu plus de 1000 lignes, soit un potentiel équivalent de variables. Je ne vais donc pas en dresser une liste exhaustive, mais plutôt essayer d’aller à l’essentiel.

Ces variables et leurs valeurs sont positionnées et exploitées durant les différentes phases et tout au long des traitements de scénarios MDT. Elles sont donc présentes en mémoire, mais également stockées dans le fichier “%SYSTEMDRIVE%\MININT\SMSOSD\OSDLOGS\VARIABLES.DAT” afin de survivre aux redémarrages. A des fins de débogage, sachez que contrairement aux apparences, ce fichier est de format “xml”. La lecture est un peu rude, mais reste tout à fait compréhensible sous réserve d’utiliser un éditeur adapté ou Internet Explorer:

<?xml version="1.0"?>
<MediaVarList Version="4.00.5345.0000">
<var name="LOGPATH">
 <![CDATA[D:\MININT\SMSOSD\OSDLOGS]]>
</var><var name="DEBUG">
 <![CDATA[FALSE]]>
</var><var name="SMSTSLOCALDATADRIVE">
 <![CDATA[D:]]>
</var>

B. Valorisation et traitement

Dans les grandes lignes, on peut considérer que les variables MDT sont valorisées successivement :

• durant la phase de collecte (exécution du script “ZTIGather.wsf“) chargée de détecter l’environnement en fonction du contexte.
• durant la lecture du fichier Bootstrap.ini
• durant la lecture du fichier unattend.xml
• durant la lecture du fichier CustomSettings.ini
• durant le traitement de la base de données
• durant l’exécution d’une séquence de tache

A des fins de tests ou d’investigations, il est possible d’évaluer les variables traités par le script de collecte via la commande suivante :

cscript ZTIGather.wsf /debug:TRUE /inifile:Settings.ini

Bien que marginal, ou pour le moins très ponctuel, sachez qu’il est également possible de stipuler des variables lors de l’exécution du script “Litetouch.vbs”.

Par exemple:

\\WDS-MDT\DeploymentShare$\Scripts\Litetouch.vbs /DeploymentType:REFRESH /SkipDeploymentType:YES /OSDComputerName:PC0001

Ou pour accéder directement à une séquence de tache particulière :

\\WDS-MDT\DeploymentShare$\Scripts\Litetouch.vbs /TasksequenceID:IdentifiantDeLaTache

Sachez qu’il est aussi possible d’exploiter plusieurs configurations, ou variantes de CustomSettings.ini

• Via le script d’initialisation, soit “LiteTouch.vbs /RulesFile:”\\CheminDuCS.ini”
• Au sein d’une séquence de taches, au niveau de “Gather local only”

Les possibilités sont tellement vastes, que la tâche la plus compliqué est de choisir la technique qui vous convient le mieux parmi toutes celles que le MDT peut proposer.

En fait, pour les cas le plus courants, la configuration de MDT passe essentiellement par les fichiers “bootstrap.ini” et “CustomSetting.ini” présents par défaut dans le dossier “\Control” de la structure MDT. Nous allons voir que ces fichiers de configuration, (Rules Files) sont composés de sections destinées à gérer des plusieurs déclinaisons de traitement.

Traitement du Bootstrap.ini

Traitement du CustomSetting.ini :

La manipulation de ces fichiers est assez aisée au début, mais cette approche montre rapidement ses limites lorsque le nombre de déclinaison augmente. C’est pour cette raison que MDT propose d’associer une base de données de type SQL Server. Ce complément facultatif, permet d’étendre les possibilités de MDT et affiner les différents scénarios. L’une des premiers intérêts est d’associer des noms de machine en fonction d’un identifiant unique tel que l’adresse MAC. Cette information étant généralement connue des bases d’inventaire de l’entreprise.

Moins évident, mais néanmoins très intéressant, le MDT exploite une notion de “rôles” basé sur des requêtes sur les différentes tables de la base de données. Bien que ce soit un peu délicat à maitriser au début, ce concept permet “grossièrement” de gérer des “configurations typiques”, déployées selon des critères tels que le site (réseau), l’usage de la machine, un ensemble d’application…

Note : Ne confondez la notion de “rôles” associée à la gestion des fonctionnalités d’un serveur “OSRoles“, avec celle mentionnée au sein de la base de données, qui ont une connotation “d’ensembles de configuration” , ou d’une gestion en “paquets”.

Si vous ne disposez pas d’un serveur MS SQL dans votre environnement, vous pouvez vous contenter d’une version SQL Server Express, qui fera parfaitement l’affaire. Je ne suis pas un spécialiste du sujet, mais je pense que vous mettrez un certain temps avant de saturer cette base de données avec MDT.

III. Étude des fichiers de configuration Bootstrap.ini et CustomSetting.ini

Comme mentionné dans le tutoriel précédent, “Débuter avec MDT 2013“, le fichier “CustomSetting.ini” peut être édité directement au sein de la console MDT, via les propriétés de votre partage de dépliement sous l’onglet “Rules“.

A votre convenance, vous pouvez également éditer ce fichier via un autre éditeur de texte tel que le bloc-notes ou Notepad++.

En revanche, pour le fichier Bootstrap.ini la console MDT ne propose pas d’édition intégrée, mais un bouton  qui aura pour effet de l’éditer avec  le bloc-notes.

Note : Certaines variables ou directives peuvent être mentionnées dans le fichier de primo-configuration “BootStrap.ini“. Reportez-vous à la documentation officielle “Toolkit Reference.docx” pour plus de détail. Je vous conseille toutefois de limiter les modifications de ce fichier qui, contrairement au “CustomSetting.ini“, nécessite une régénération des clients LiteTouch.

A. Le CustomSetting.ini par défaut

Commençons déjà par analyser le contenu par défaut. Au début, ce fichier est composé de simplement 2 sections [Settings] et [Default], mais nous allons voir que ce nombre peut rapidement augmenter.

Normalement, les directives ne sont pas sensibles à la casse (majuscules/minuscules) et les valeurs comme “Y”, “YES”, “Yes” sont valides. Toutefois, probablement pour des raisons historiques et par convention, il est souhaitable de respecter les préconisations proposées dans l’aide en ligne, c’est-à-dire “YES” ou “NO”.

Astuce : Vous pouvez ajouter un point-virgule en début d’une ligne pour la commenter et ainsi éviter son traitement ou mentionner une information personnelle.

Si je résume, la section [Default] doit contenir vos préférences générales, s’appliquant au plus grand nombre de vos scénarios de déploiement, et pour lesquels vous souhaitez contrôler les valeurs par défaut.

Ensuite, vous pouvez ajouter des sections supplémentaires pour traiter les cas particuliers sans oublier de mentionner l’ordre au niveau de la directive “Priority =“.

B. Le Bootstrap.ini par défaut

Ce fichier est en quelque sorte le premier point d’entrée dans la configuration de MDT. Il contient donc les informations cruciales de l’initialisation des processus MDT. Pour votre gouverne, son initialisation est déclenchée par la commande “BDDRun.exe /Bootstrap” contenue dans le noyau des clients LiteTouch. Reportez-vous à mon tutoriel sur la “Présentation de WinPE” et les explications sur les processus d’initialisation.

Il partage la même logique que son homologue de type .ini et à l’issue d’une première installation de MDT, son contenu est le suivant:

Nous allons voir par la suite comment l’améliorer.

C. Principes avancés des fichiers .INI

1. Explications

Le traitement des fichiers .INI est bien plus complexe qu’il n’y parait. En effet, il possible de personnaliser à l’extrême son séquencement. On retrouve toujours une section [Settings] chargée de définir les sections et l’ordre de leur traitement, mais parfois également des propriétés personnalisées. Au sein de ces sections, on trouve généralement les directives préconisées dans la plupart des cas, mais également vos propriétés personnalisées, auxquelles peuvent être associées des valeurs simples ou calculées. De plus, il est possible d’ajouter des sous-sections qui seront traitées en fonction d’une autre valeur.

[Settings]
; ordre de lecture des sections
Priority=Section1, Section2, Section3...
; propriétés personnalisées
Properties=CustStaticVar, CustDynamicVar

[Section1]
; valorisation avec un contenu statique
CustStaticVar=PC
; valorisation avec un contenu dynamique
CustDynamicVar=#Day(Date) & "-" & Month(Date) & "-" & Year(Date)#

[Section2]
; déclaration d'une sous-section avec nom fixe
SubSection=Section2-1

[Section2-1]
Result=Value

[Section3]
; déclaration d'une sous-section avec nom calculé
SubSection=Server-%IsServer%

[Server-True]
OSDComputerName=SRV-#Right("%SerialNumber%",7)#

Dans cet exemple “non fonctionnel”, la variable personnalisée “CustDynamicVar” est valorisée selon une donnée calculée dynamiquement, telle que la date actuelle “#Day(Date)& “-” & Month(Date) & “-” & Year(Date)#”. Les caractères dièse “#” servent à borner l’expression.

Note : Les expressions sont exprimées en code vbscript . Vous disposez donc de toute la panoplie des fonctions disponibles dans ce langage.

Pour le second exemple de valeur calculée, “OSDComputerName=” les signes “pourcent” référent une variable “%SerialNumber%“, déjà positionnée lors de la collecte, en l’occurrence le numéro de série de la machine.
La sous-section déclarée dans la “Section3” est calculée sur la variable booléenne “%IsServer%” déjà positionnée lors de la collecte. S’il s’agit d’un système de type “Serveur”, cette variable renvoie “True” ce qui permet de composer le nom de la sous-section à atteindre, soit “Server-True” dans cet exemple.

Pour illustrer ce principe avec un exemple plus concret :

Supposons que vous vouliez différencier des certains paramètres en fonction des chacun de vos sites et définir un nommage particulier selon que les ordinateurs soient de type portable ou de bureau. Pour un tel cahier des charges, le recours à la passerelle IP par défaut, soit la variable MDT “%DefaultGateway%“, peut être un bon moyen pour localiser un emplacement ou un site. Pour ce qui est de la différentiation des types portable ou de bureau, il suffit d’interroger les variables booléennes MDT “%IsLapTop%” et “%IsDeskTop%“.

Pour définir un nom unique d’ordinateur, vous avez plein de possibilités telles que :

• Utiliser tout ou partie du numéro de série, – #Right(“%SerialNumber%”,7)#
• Utiliser tout ou partie de l’adresse MAC – #Replace(Right(MACAddress,11),”:”,””)#
• Utiliser un nombre aléatoire. #Int(Rnd()*1000000)#

N’oubliez pas de respecter les règles de base NetBIOS, telles que la limitation à 15 caractères pour la compatibilité ascendante, et éviter les caractères spéciaux dont le soulignement.

Ce qui pourrait donner un fichier comme suit :

[Settings]
Priority=Init, ByLaptop, ByDesktop, DefaultGateway, Default
Properties=mySite, myPCType, myNumber

[Init]
 myNumber=#Replace(Right("%MACAddress%",11),":","")#

[ByLaptop]
 SubSection=Laptop-%IsLapTop%

[Laptop-True]
 myPCType=LT
 MachineObjectOU=OU=Portables,OU=Postes,DC=Cnf1g,DC=Local

[ByDesktop]
 SubSection=Desktop-%IsDesktop%

[Desktop-True]
 myPCType=DT
 MachineObjectOU=OU=Fixes,OU=Postes,DC=Cnf1g,DC=Local

[DefaultGateway]
 192.168.75.1=Paris
 192.168.44.1=Nantes
 192.168.35.1=Rennes
 192.168.100.1=Londres

[Paris]
 mySite=PAR
 TimeZoneName=Romance Standard Time

[Nantes]
 mySite=NTE
 TimeZoneName=Romance Standard Time

[Rennes]
 mySite=RNE
 TimeZoneName=Romance Standard Time

[Londres]
 mySite=LON
 TimeZoneName=GMT Standard Time

[Default]
 OSInstall=Y
 OSDComputername=%mySite%-%myPCType%-%myNumber%
 SkipCapture=YES
 SkipAdminPassword=YES
 SkipProductKey=YES
 SkipComputerBackup=YES
 SkipBitLocker=YES

2. Tests et débogage

Il ne vous reste plus qu’à tester cet exemple, mais la mise au point peut s’avérer longue et fastidieuse. Aussi, pour ces cas complexes, je vous conseille de tester la configuration sans passer par le scénario complet. Pour cela, téléchargez préalablement l’excellent outil “MDT Debugger” de l’équipe “The Deployment Guys“. C’est un simple exécutable à déposer dans un dossier quelconque, tel que “\\WDS-MDT\DeploymentShare$\Tools”. Ensuite, déposez le fichier de configuration à tester, que nous nommerons “CS-Complex.ini ” dans le dossier “\\WDS-MDT\DeploymentShare$\Control”. Ouvrez ensuite une invite de commande, puis exécutez les commandes suivantes :

cd C:\DeploymentShare\Tools

.\CUSTOM_MDTDebugger.exe cscript ..\scripts\ZTIGather.wsf /inifile:..\Control\CS-Complex.ini

La fenêtre suivante sera alors affichée, et vous permettra de contrôler précisément les traitements effectués ainsi que l’état des différentes variables et propriétés.

Si vous utilisez l’outil plusieurs fois de suite, pensez à supprimer le fichier suivant pour éviter les rémanences.

del C:\MININT\SMSOSD\OSDLOGS\VARIABLES.DAT

D. Les écrans de l’assistant

Pour cette étude, je vous propose d’aborder la configuration du MDT au travers des différents écrans affichés par l’assistant de déploiement “wizard.hta” exploité sur les clients LiteTouch. Pour l’exemple, nous prendrons un scénario courant d’une séquence de tache de déploiement “Standard Client Task Sequence“.

Grossièrement, on peut considérer que les directives destinées à masquer les écrans de cet assistant sont de la forme “skip…=YES“. A titre d’information, voici la liste de ces variables :

SkipAdminAccounts, SkipAdminPassword, SkipApplications, SkipBDDWelcome, SkipBitLocker, SkipBuild, SkipCapture, SkipComputerBackup, SkipComputerName, SkipDomainMembership, SkipFinalSummary, SkipGroupSubFolders, SkipLocaleSelection, SkipPackageDisplay, SkipProductKey, SkipRearm, SkipRoles, SkipSummary, SkipTaskSequence, SkipTimeZone, SkipUserData, SkipWizard

Toutefois, si vous décidez de passer un écran sans l’afficher, n’oubliez pas qu’il sera nécessaire de contrôler les variables associées ou accepter les valeurs par défaut.

Attention : Les écrans affichés sont variables selon les scénarios traités et certains peuvent être automatiquement masqués en l’absence de contenu, tels que des applications, des packages, ou lorsque certaines conditions ne sont pas remplies…

1. Page de bienvenue

Titre de l’écran de l’assistant : Welcome
Fichier de configuration préconisé : BootStrap.ini
Directive de masquage : SkipBDDWelcome=YES

Aperçu de la page de bienvenue

Propriétés concernées :

• KeyboardLocalePE=040c:0000040c Modifier le clavier en Français

Pour affecter une adresse IP statique :

Bien que les environnements DHCP soit plus simples à mettre en œuvre, vous pouvez affecter une adresse IP statique sur les clients LiteTouch. Pour cela, vous pouvez soit laisser la page de bienvenue visible et utiliser l’assistant, soit utiliser des commandes “netsh”, soit utiliser l’une des techniques suivantes :

– Ajout de tout ou partie des propriétés suivantes au sein du fichier de configuration BootStrap.ini

• OSDAdapterCount=1
• OSDAdapter0EnableDHCP=FALSE
• OSDAdapter0IPAddressList=192.168.100.220
• OSDAdapter0SubnetMask=255.255.255.0
• OSDAdapter0Gateways=192.168.100.1
• OSDAdapter0DNSServerList=192.168.1.11,192.168.1.12
• OSDAdapter0DNSSuffix=labo.local

– Modifier le fichier “\unattend.xml” des clients LTI (modification du noyau WinPE) comme suit :

<component name="Microsoft-Windows-TCPIP" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <Interfaces>
 <Interface wcm:action="add">
 <Ipv4Settings>
 <DhcpEnabled>false</DhcpEnabled>
 <Metric>10</Metric>
 <RouterDiscoveryEnabled>false</RouterDiscoveryEnabled>
 </Ipv4Settings>
 <UnicastIpAddresses>
 <IpAddress wcm:action="add" wcm:keyValue="1">192.168.100.220/24</IpAddress>
 </UnicastIpAddresses>
 <Identifier>Ethernet</Identifier>
 </Interface>
 </Interfaces>
 </component>

Cette seconde technique à ma préférence, mais j’admets qu’elle est plus délicate à mettre en œuvre. En effet, il faut être familier de l’éditeur WSIM à moins de copier/coller cet exemple et il faudra injecter cette modification au sein du noyau WinPE, dans le fichier Boot.WIM.

2. Saisie des identifiants de connexion

Titre de l’écran de l’assistant : User Credentials
Fichier de configuration : BootStrap.ini
Directive de masquage : N/A – Automatiquement passé si les propriétés ci-après sont toutes renseignées.

Aperçu de la page – Saisie des identifiants

Propriétés concernées :

• UserID=CompteUtilisateur – Entrez le nom du compte de déploiement local ou de domaine
• UserPassword =MotDePasse – Entrez le mot de passe du compte en clair
• UserDomain=DomaineOuServeurMDT – Entrez le nom du domaine Active Directory ou le nom ou adresse IP du serveur MDT s’il s’agit d’un compte local.

3. Séquence(s) de taches

Titre de l’écran de l’assistant : Task Sequence
Fichier de configuration : Bootstrap.ini / CustomSettings.ini
Directive de masquage : SkipTaskSequence =YES

Aperçu de la page – Task Sequence

Propriétés concernées :

• TaskSequenceID=Aucun – Entrez l’identifiant de la séquence de taches souhaitée. Vous pouvez retrouver cette information au niveau des propriétés d’une séquence de taches.

4. Détails de l’ordinateur

Titre de l’écran de l’assistant : Computer Details
Fichier de configuration : CustomSettings.ini
Directives de masquage : SkipComputerName =YES : SkipDomainMembership=YES

Aperçu de la page – Détails de l’ordinateur

Propriétés concernées :

• OSDComputerName=NomMachine – Par défaut, MDT affecte un nom commençant par “MININT-” suivi d’un identifiant unique aléatoire.
• JoinWorkgroup=NomDuGroupeDeTravail – Par défaut, MDT affecte le nom “WORKGROUP”

Ou pour joindre l’ordinateur à un domaine

• JoinDomain=NomDuDomaine – Entrez le nom du domaine Active Directory à joindre
• DomainAdmin=CompteDeJonction – Entrez le nom d’un compte habilité à joindre un ordinateur au domaine
• DomainAdminDomain=NomDeDomaineDuCompte – Entrez le nom du domaine auquel appartient le compte habilité
• DomainAdminPassword= MotDePasse – Entrez le mot de passe du compte en clair

5. Transfert des données et paramètres d’utilisateur (USMT)

Titre de l’écran de l’assistant : Move Data and Settings / User Data (Restore)
Fichier de configuration : CustomSettings.ini
Directive de masquage : SkipUserData =YES

Aperçu de la page – USMT

Propriétés concernées :

• DoNotFormatAndPartition=YES – Ne formate pas les partitions existantes afin de préserver le contenu (Nouveauté MDT2013).
• UDDir =Nom du dossier dans lequel seront stockées les données USMT ou la sauvegarde
• UDShare = Chemin UNC dans lequel seront stockées les données USMT ou la sauvegarde
• UserDataLocation = UNC | AUTO | NETWORK |NONE – Définit le chemin UNC ou la méthode de stockage des données USMT ou la sauvegarde – Par défaut, la valeur est “AUTO”

6. Saisie de la clé produit

Titre de l’écran de l’assistant : Product Key
Fichier de configuration : CustomSettings.ini
Directive de masquage : SkipProductKey =YES

Aperçu de la page – Spécifier la clé de produit

Propriétés concernées :

• ProductKey = AAAAA-BBBBB-CCCCC-DDDDD-EEEEE-FFFFF – Entrez la clé KMS du produit (5 blocs de 5 caractères alphanumériques).

• OverrideProductKey= AAAAA-BBBBB-CCCCC-DDDDD-EEEEE-FFFFF – Permet d’affecter une clé MAK lorsque le serveur KMS est injoignable

7. Réglages des préférences régionales

Titre de l’écran de l’assistant : Locale and Time
Fichier de configuration : CustomSettings.ini
Directives de masquage : SkipLocaleSelection =YES : SkipTimeZone=YES

Aperçu de la page – Préférences régionales

Propriétés concernées :

• UILanguage=fr-FR – Entrez l’identifiant de la langue d’installation – ici “French (France)”
• UserLocale=fr-FR – Entrez la préférence régionale – ici “French (France)”
• KeyboardLocale= 040C:0000040C – Entrez le code pays selon le clavier désiré – ici “French”
• TimeZoneName = Romance Standard Time – Entrez le nom du fuseau horaire – ici “(UTC+01:00) Brussel, Copenhagen, Madrid, Paris”
• TimeZone=105 – Alternative au précédent – Entrez le code du fuseau horaire – ici “105” pour celui de la France

8. Applications à installer

Titre de l’écran de l’assistant : Applications
Fichier de configuration : CustomSettings.ini
Directives de masquage : SkipApplications=YES : SkipAppsOnUpgrade=YES

Aperçu de la page – Applications à installer

Cet écran permet de sélectionner les applications qui seront installées durant la tache de post-installation d’une séquence de taches.

Propriétés concernées :

• Applications00x ={guid} – Ces directives particulières commencent par “Applications” suivi d’un numéro d’ordre de 001 à 999. La valeur doit correspondre l’identifiant global unique {GUID} des applications. Vous pouvez retrouver cette valeur au niveau des propriétés de chaque application ajoutée dans le MDT.

• MandatoryApplications00x ={guid} – Identique au précédent, mais rend obligatoire l’installation de l’application. En fait, la case ne peut pas être décochée (grisée) lorsque cet écran est affiché.

9. Saisie du mot de passe d’administrateur local

Titre de l’écran de l’assistant : Administrator Password
Fichier de configuration : CustomSettings.ini
Directive de masquage : SkipAdminPassword =YES

Aperçu de la page – Mot de passe Administrateur

Propriétés concernées :

• AdminPassword =MotDePasse – Entrez le mot de passe du compte d’administrateur local en clair. Si cette information n’est pas mentionnée, MDT conservera le mot de passe défini dans la base de compte locale du système installé. Autrement dit, pour une distribution originale Microsoft, le mot de passe est vide, mais pour une image de référence, le mot de passe peut être défini durant la séquence de fabrication préalable à sa capture.

10 . Capture d’une image de référence

Titre de l’écran de l’assistant : Capture Image
Fichier de configuration : CustomSettings.ini
Directive de masquage : SkipCapture =YES

Aperçu de la page – Capture d’une image de référence

Propriétés concernées :

• DoCapture= – Entrez la valeur “YES” pour activer la première option de capture, soit “Capture an image of this reference computer.”, ou entrez la valeur “SYSPREP” pour activer la seconde option, soit “Sysprep this computer.”, ou entrez la valeur “PREPARE” pour activer la troisième option, soit “Prepare to capture this machine.”

Si vous optez pour l’option la plus courante, soit “DoCapture=YES”, vous avez la possibilité de spécifier le chemin et le nom de l’image de destination. Les directives sont les mêmes que pour une sauvegarde.

• ComputerBackupLocation=\\Serveur\Partage – Entrez le chemin UNC de destination de la capture. Par défaut, ce chemin correspond au sous dossier “Captures” situé sur le partage de déploiement, comme par exemple “\\WDS_MDT\DeploymentShare\Captures”. N’oubliez pas d’accorder les autorisations d’écriture sur cette ressource.
• BackupFile=Fichier.WIM – Entrez le nom de l’image .wim résultante. Correspond par défaut à l’identifiant de la séquence de tache, soit “%TaskSequenceID%.wim”

11. Résumé préalable

Titre de l’écran de l’assistant : Ready to begin
Fichier de configuration : CustomSettings.ini
Directive de masquage : SkipSummary =YES

Aperçu de la page – Résumé des opérations

Propriétés concernées : N/A

12. Résumé de fin de déploiement

Titre de l’écran de l’assistant : Operating system deployment completed successfully : Operating system deployment did not complete successfully
Fichier de configuration : CustomSettings.ini
Directive de masquage : SkipFinalSummary =YES

Ecran Blanc = Aucune erreur, Jaune = Avertissement, Rose = Erreur critique

Aperçu de la page – Etat de l’opération

Quand il y a une erreur, ça donne ça :

Propriétés concernées :

• FinishAction= – Permet de définir le comportement souhaité à l’issue du déploiement, par défaut si l’écran n’est pas masqué, le résumé de fin de déploiement reste affiché. Entrez l’une des valeurs, telle que “LOGOFF | SHUTDOWN | RESTART | REBOOT” afin de respectivement, fermer la session, arrêter, redémarrer à chaud ou à froid l’ordinateur.

Afin de ne pas trop alourdir cette présentation déjà conséquente, je vous invite à vous reporter à la documentation officielle pour les autres cas particuliers non abordés ici.

E. Exemple de personnalisation

1. Postulat du cas étudié

Afin d’illustrer tout ceci, nous allons prendre l’exemple d’une capture d’un poste de référence. En effet, si vous n’êtes pas encore familiarisé avec ce concept, on peut considérer que contrairement aux scénarios habituels de déploiement, il s’agit d’un cas particulier que la séquence de tache associée doit prendre en compte.

Pour faire court, cette notion de “capture” est essentiellement liée aux processus de fabrication d’un ordinateur de référence, souvent désigné par l’anglicisme “Master”. Sur le plan pratique, la capture consiste à générer une image .WIM à partir d’un poste remis en condition de déploiement via l’outil “sysprep”. Avec MDT, on peut distinguer 2 techniques de fabrication :

• La capture manuelle : L’installation et la configuration de l’ordinateur de référence est faite manuellement puis on sollicite ensuite via le réseau, le script “LiteTouch.vbs” situé sur le partage MDT, afin de déclencher une séquence de tache de type “Sysprep and Capture“.

• La capture automatisée : L’installation et la configuration de l’ordinateur de référence est réalisée par une séquence de tache de type “Standard Client Task Sequence” à laquelle on associe l’enchainement des actions de préparation et de capture. Bien que plus délicate à mettre au point, cette méthode garantit et normalise le processus de fabrication.

2. Appliquer une configuration à une machine précise

Il existe plusieurs moyen d’identifier un ordinateur, mais pour cet exemple, nous allons distinguer la machine de référence (virtuelle ou non) par son adresse MAC. Pour cela, il suffit d’ajouter la variable “MACAddress” au niveau de la directive “Priority=” et d’ajouter une nouvelle section correspondante à la valeur de l’adresse physique de la machine, au format [00:00:00:AA:BB:CC].

Note : Sous Windows, les commandes “arp” ou “ipconfig” renvoient l’adresse MAC séparée par un tiret avec les lettres en minuscule. Pour MDT, il faudra remplacer les tirets par des double-points et mettre les lettres en majuscule, soit en langage powershell : (“00-15-5d-00-2c-15”).Replace(“-“,”:”).ToUpper()

Besoin d’un script plus élaboré pour valider le format ?, cf ici

3 . Création de la séquence de test

Pour un premier test de cette configuration, je vous propose de créer une nouvelle séquence de tache de type “Sysprep and Capture“. Par exemple, nous lui affectons l’identifiant “CAPT-001” et le nom arbitraire “Sysprep et Capture uniquement“. Au besoin, vous pouvez ajouter cette information dans le fichier au niveau de la section correspondante à l’adresse MAC de notre machine de test.

4. Directives à ajouter dans CustomSettings.ini

Donc dans le cadre de cette démonstration, il nous faut renseigner les directives suivantes :

Remarque importante : Les processus de capture MDT échouent systématiquement dès lors que l’ordinateur est membre d’un domaine. Autrement dit, les séquences de capture ne sont traitées que sur des ordinateurs autonomes au sein d’un simple groupe de travail.

Le fichier de configuration devrait approximativement ressembler à ceci :

[Settings]
Priority = MACAddress,Default
Properties=MyCustomProperty

[00:15:5D:00:2C:15]
SkipTaskSequence=NO 
TaskSequenceID=CAPT-001

SkipCapture=NO
DoCapture=YES
; ComputerBackupLocation=%DeployRoot%\Captures
; ou 
BackupShare=%DeployRoot%
BackupDir=Captures
BackupFile=%TaskSequenceID%.wim

[Default]
SkipCapture=YES
DoCapture=NO

Notez que dans un premier temps, il est préférable de conserver l’affichage des écrans afin de vérifier que les champs soient correctement remplis.

Pour rappel, n’oubliez pas que le dossier de capture doit être accessible en lecture/écriture et que l’exécution du script nécessite généralement des privilèges d’administration.

5. Test du résultat

A partir de la machine de test sur laquelle un système est déjà installé, il ne reste plus qu’à connecter un lecteur réseau pointant sur le serveur MDT et exécuter le script “LiteTouch.vbs” situé sous le dossier “Scripts“.

net use z: \\WDS-MDT\DeploymentShare$ /user:WDS-MDT\Admin *
Entrez le mot de passe pour \\WDS-MDT\DeploymentShare$ :
Z:\Scripts\LiteTouch.vbs

Selon le niveau de sécurité du poste, une confirmation d’exécution peut être affichée.

A l’issue du traitement des fichiers bootstrap.ini et customsetting.ini, et sous réserve que vous ayez correctement saisi l’adresse MAC de la machine de test, l’écran de choix des séquences de taches devrait apparaître avec l’option “Sysprep et Capture uniquement” sélectionnée.

Si c’est bien le cas, pour la prochaine étape, vous pourrez éventuellement changer la directive par SkipTaskSequence=YES. Cliquez sur “Next“.

L’écran de capture devrait alors apparaître. Et là encore, la première option doit être déjà sélectionnée et les champs “Location” et “File name” devraient contenir les bonnes informations.

Si c’est bien le cas, pour le test suivant, vous pourrez changer la directive par SkipCapture=YES
Cliquez sur “Cancel“.

La démonstration peut s’achever ici, du fait qu’il s’agissait de montrer un exemple simple de capture. Cela étant, il faudrait encore ajuster quelques réglages afin de parfaire cette opération, tels que l’ajout d’applications, de packages ou bien ajuster les composants Windows souhaités.

Voici un exemple de configuration finalisé

[Settings]
Priority = MACAddress,Default
Properties=MyCustomProperty

[00:15:5D:00:2C:15]
_SMSTSORGNAME=Creation de l'image de reference - %TaskSequenceID%

SkipTaskSequence=YES 
 TaskSequenceID=CAPT-001

SkipCapture=YES
 DoCapture=YES
 BackupShare=\\WDS-MDT\DeploymentShare$
 BackupDir=Captures
 BackupFile=BUILD-v%TaskSequenceVersion%.wim

; ajoutez ici les applications a integrer dans l'image de reference
SkipApplications=NO
SkipAppsOnUpgrade=YES
 ; Applications001={GUID1}
 ; Applications002={GUID2}
 ; Applications003={GUID3}

SkipUserData=YES
 UserDataLocation=NONE

SkipComputerName=YES
 OSDComputerName=BUILD-001
SkipDomainMembership=YES
 JoinWorkGroup=WORKGROUP

SkipLocaleSelection=YES
SkipTimeZone=YES
 UILanguage=fr-FR
 UserLocale=fr-FR
 KeyboardLocale= 040C:0000040C
 TimeZoneName=Romance Standard Time

DoNotCreateExtraPartition=YES
ApplyGPOPack=NO
SLShare=\\WDS-MDT\logs
; pensez a reactiver les taches Windows Update dans la TS
WSUSServer=http://wsus

SkipAdminPassword=YES
SkipBitLocker=YES
SkipProductKey=YES
SkipRoles=YES

SkipSummary=YES
SkipFinalSummary=NO
 FinishAction=SHUTDOWN

[Default]
_SMSTSORGNAME=Deploiement par defaut - %TaskSequenceID%
OSInstall=Y
SkipCapture = YES

Exemple de résultat :

Maintenant tous ces choix vous incombent et j’espère que cette présentation sera suffisante à votre envol vers de nouvelles aventures avec MDT.

Conseil : Pensez à sauvegarder régulièrement vos fichiers de configuration opérationnels avant d’effectuer des modifications. Pour l’anecdote, je ne compte plus les heures perdues à chercher une “fausse erreur de traitement” liée simplement à un mauvais encodage du fichier en UTF8 au lieu de ANSI.

F. La base de données MDT DB

Après tout ce remue-méninge autour de ce fameux fichier de configuration, un constat viens rapidement à l’esprit. A une plus grande échelle, le nombre de ligne va très rapidement augmenter, et on atteint très rapidement les limites en termes de lisibilité. En effet, les risques de doublons ou d’erreur dans les déclarations de variables n’est pas négligeable et difficile à identifier. Est-ce raisonnable de maintenir un tel fichier pour gérer toutes les déclinaisons de mon entreprise ?

C’est à ce moment que la base de données “MDT DB” devient intéressante.

Installer une base de donnée pour MDT peut paraitre délicat pour un néophyte et pour débuter, un tutoriel arrivera prochainement dans lequel j’aborde l’installation d’une base SQL Server Express ainsi que l’exploitation des nouvelles possibilités telles que la notion de rôles

IV. Aller plus loin avec CS.ini : Quelques Trucs et Astuces

A. Ne pas créer la partition additionnelle d’amorçage

Vous avez sans doute remarqué que le MDT génère une partition supplémentaire dans le but d’y stocker les fichiers d’amorçage et surtout dans l’hypothèse d’activer le chiffrement intégral de disque BitLocker. Hors, cette fonctionnalité n’est disponible pas sur les versions, vous pouvez désactiver la création de cette partition supplémentaire via la directive suivante :

DoNotCreateExtraPartition=YES

B. Affecter des valeurs dynamiques aux variables MDT

1. Personnalisation de la bannière de déploiement

Nous avons vu qu’il était possible d’affecter de nombreuses valeurs aux propriétés MDT , comme par exemple ” _SMSTSOrgName= MonEntreprise” pour personnaliser la bannière de déploiement. Toutefois, ces valeurs sont statiques et il peut être parfois intéressant de composer dynamiquement certains contenus.

Exemples :

Pour afficher l’identifiant de la séquence et le nom de l’ordinateur sur la bannière de déploiement, vous pourriez utiliser la directive suivante :

_SMSTSOrgName = Execution de la séquence %TaskSequenceID% sur %OSDComputername%

2. Personnalisation des noms de machines

Pour composer vos propres noms de machine à partir des 5 derniers chiffres du numéro de série, vous pourriez utiliser la directive suivante :

OSDComputername = PC-#Right("%SerialNumber%",4)#

Les caractères “#” permettent d’encadrer le code à évaluer

3. Ciblage des pilotes en fonction des machines

Pour maîtriser la distribution des pilotes en fonction de la marque et du modèle de machine

DriverSelectionProfile=Nothing
DriverInjectionMode=ALL
DriverGroup001=Windows 7\x64\%Make%\%Model%

Notez que cette astuce ne fonctionne que si vos pilotes sont organisés selon une hiérarchie de dossiers correspondant exactement à la marque et au modèle de machine renvoyé par les requêtes WMI. Vous pouvez obtenir ces renseignements :

– Via la console WMI

WMIC CSProduct Get Name, Vendor

Relevez collectez les valeurs “Vendor” (Make) et “Name” (Model)

– Via Powershell

Get-WmiObject Win32_ComputerSystem | Select Model,Manufacturer

Relevez les valeurs “Manufacturer” (Make) et “Model” (Model)

4. Ajouter la date de création sur le fichier de capture

Cet exemple permet de nommer le fichier résultant d’une capture ajoutant la date de fabrication à l’identifiant la séquence de tache.

DoCapture=YES
BackupShare=%DeployRoot%
BackupDir=Captures
BackupFile=%TaskSequenceID%_#day(date) & "-" & month(date) & "-" & year(date)#.wim

C. Activer les mises à jour Windows Update, mais bloquer des correctifs indésirables

WSUSServer=http://WSUSServer:8530

WUMU_ExcludeKB001=976002 
WUMU_ExcludeKB002=2267621
WUMU_ExcludeKB003=2434419

Par exemple, le programme européen de choix du navigateur par défaut, silverlight, la barre d’outil “Bing”,…

;Microsoft Browser Choice Screen Update for EEA Users of Windows 7 for x64-based Systems (KB976002)
 WUMU_ExcludeKB1=976002
 ;Microsoft Silverlight (KB2636927)
 WUMU_ExcludeKB2=2636927
 ;Windows Internet Explorer 9 for Windows 7 for x64-based Systems (KB982861)
 WUMU_ExcludeKB3=982861
 ;Bing Desktop (KB2694771)
 WUMU_ExcludeKB4=2694771

Attention : Par défaut les taches de mise à jour sont présentes, mais désactivées

D. Masquer les invites de commande

Pour masquer les invites de commande ouvertes durant les taches de déploiement telles que l’installation des applications, vous pouvez utiliser la directive suivante :

HideShell=YES

Utilisez toutefois, ce réglage avec parcimonie, car certaines applications ne supportent pas toujours ce genre de contrainte.

E. Définir le service de surveillance des déploiements MDT (Monitoring)

Depuis MDT2012, vous pouvez activer un service de surveillance de vos déploiements MDT. Pour cela, utilisez la directive suivante :

EventService=http://SERVER:9800

F. Ajouter des administrateurs locaux

Vous avez la possibilité d’ajouter des administrateurs locaux, comptes d’utilisateur ou groupes d’un domaine via la directive suivante :

Administrators001=Domaine\NomDuGroupe

G. Activer la journalisation dynamique des déploiements

MDT permet d’activer , la journalisation dynamique des déploiements via la directive suivante :

SLShareDynamicLogging=\\SERVER\SHARE$\Logs\%OSDComputerName%

N’abusez pas de ce réglage qui peut engendrer un augmentation significative du trafic réseau.

Annexes – Clés d’installation des clients KMS

Ne vous emballez pas, il s’agit là d’une information tout à fait légale, disponibles sur les sites officiels de Microsoft : Technet – Clé KMS

Les clés fournies ci-après n’ont aucune valeur pour l’activation et sont uniquement destinées aux processus d’installation automatisées. Dans la plupart des cas, vous disposez d’une période de grâce de 30 jours pour entrer votre clé de licence effectivement acquise dans le cadre contractuel.

Remarque : Pour installer une clé d’installation de client, ouvrez une invite de commandes d’administration sur le client, tapez slmgr /ipk <clé d’installation> et appuyez sur ENTRÉE.

Windows Server 2012R2 et Windows 8.1

Windows Server 2012 et Windows 8

Windows 7 et Windows Server 2008 R2

Windows Vista et Windows Server 2008

I. Présentation

Le but de ce tutoriel est de vous présenter comment implémenter la multidiffusion basée sur le tandem des solutions de déploiement WDS et MDT de Microsoft.

A. La multidiffusion en quelques mots

La multidiffusion (ou “Multicast”) est un mode de communication TCP/IP particulier. Dans les grandes lignes, contrairement à la diffusion simple ou mono-diffusion (ou “Unicast”) qui détermine une relation de un à un, et à la diffusion générale (ou “Broadcast”) qui génère une communication vers tous les nœuds d’un même réseau IP, la multidiffusion définit une communication spécialisée à destination d’un “groupe d’abonnés”.

En creusant le sujet, vous vous heurterez surement à quelques acronymes de protocoles particuliers tels que les notions de routeurs ou proxy IGMP, mais ce n’est pas le propos de cet article. Pour votre gouverne, les multidiffusions utilisent une plage d’adresses IP située entre 224.0.0.0 et 239.0.0.0, mais là encore, ce n’est pas très important pour cette démonstration.

B. Intérêts de la multidiffusion

Ces éléments doivent cependant être étudiés et confrontés aux contraintes du réseau de l’entreprise avant une mise en production.

L’intérêt de la multidiffusion dans le cadre des déploiements réside dans l’économie substantielle des échanges réseau entre le serveur et les postes installés. En effet, si vous installez 10 postes identiques à partir d’un même serveur, en diffusion simple (mode “unicast” par défaut), ce dernier doit envoyer 10 fois une même image .WIM. Lors que la multidiffusion est activée, le serveur ne génère qu’un seul flux, que chaque client “abonné” récupère à son rythme.

Attention, il n’est pas conseillé d’activer systématiquement ce type de diffusion qui présente aussi quelques contraintes :

• C’est le client le plus lent qui détermine la vitesse du flux général – WDS peut classer automatiquement et décliner plusieurs flux en fonction de ce critère. Il peut également “sortir” un poste du flux de multidiffusion lorsque la vitesse de transfert passe en dessous d’un seuil défini.

• La multidiffusion est un protocole plus verbeux qui effectue de nombreux contrôles. Il est donc moins performant sur de petits volumes de destinataires.

• La multidiffusion est rarement autorisée sur tous les VLAN d’une entreprise et il est généralement plus judicieux de l’activer principalement sur les segments de type “atelier”, là où le volume d’installations récurrentes est significatif.

II. La multidiffusion sur WDS

En premier lieu, notez que la multidiffusion ne peut être assurée que par les serveurs WDS (Windows 2008 R2 ou ultérieurs) disposant du service de rôle “Serveur de transport” et que l’activation s’effectue individuellement sur chaque image d’installation disponible dans vos différents groupes. (*cf : Dématérialisez vos supports avec WDS2012R2 )

Sur le serveur WDS, ouvrez la console de gestion “Services de déploiement Windows“. Sélectionnez le nom du serveur puis utilisez le menu “Action … Propriétés” ou le menu contextuel. Sélectionnez ensuite l’onglet “Multidiffusion” afin d’afficher les différents réglages proposés par défaut:

Ces réglages sont adaptés aux environnements dits courants. Vous pouvez modifier les plans d’adressage selon les contraintes de votre réseau. En fonction des mesures de transfert constatées, vous pourrez revenir sur cet onglet afin d’affiner les paramètres de transfert.

Pour l’instant, du fait il s’agit d’une simple présentation, je vous propose de cliquer sur “Annuler“.

Pour activer la multidiffusion sur une image donnée, il vous faut choisir l’image d’installation désirée au sein d’un de vos groupes disponibles. Sélectionner cette image puis utilisez le menu “Action … Créer une transmission par multidiffusion…” ou le menu contextuel.

Entrez un nom pour décrire ce flux comme par exemple “MCast – Win8.1Pro x64“.

Note : Les caractéristiques de cette transmission ne seront plus modifiables. Au besoin, vous devrez supprimer cette définition et recréer une nouvelle transmission.

Cliquez sur “Suivant“.

Par défaut, Microsoft propose un déclenchement automatique (qu’il dénomme parfois “Autocast“). En fait, c’est le premier client qui demande l’installation de cette image qui va déclencher la transmission par multidiffusion. Il est toutefois possible de définir un déclenchement contrôlé par les critères suivants :

• Déclenchement manuel (si aucune case n’est cochée)
• Déclenchement automatique lorsque le nombre de clients stipulé est atteint (ma préférence
• Définition d’une plage horaire pour un déclenchement différé.

Cliquez sur “Suivant” puis sur “Terminer“.

Cette nouvelle déclaration de multidiffusion doit apparaître sous la rubrique “Transmissions par multidiffusion“. Vous pouvez contrôler ses caractéristiques en utilisant le menu “Propriétés”

Lorsque des clients sont connectés à cette transmission, vous pouvez choisir “d’ignorer la multidiffusion” ou de le “déconnecter” purement et simplement.

Dans le premier cas, le client poursuivra son installation en mode traditionnel (mono-diffusion) alors que dans le second cas, l’installation du client échouera.

III. Mise en œuvre de la multidiffusion avec MDT

Maintenant que vous avez comment activer une multidiffusion avec des images d’installation WDS, je vous propose d’en faire bénéficier votre solution MDT.

Avant de vous lancer, vous devez considérer 2 cas de figure :

• Le service WDS et la structure MDT sont sur le même serveur – Rien de plus simple, il suffit de se contenter de réaliser l’étape “A”, et le tour est joué !…

• Le service WDS et la structure MDT sont sur des serveurs différents – Suivez les étapes suivantes

A . Activer la prise en charge de la multidiffusion par MDT

En premier lieu, il est nécessaire d’activer la prise en charge de la multidiffusion par votre MDT. Pour cela, il suffit de démarrer la console “Deployment Workbench“, de sélectionner le nom de votre MDT situé sous la rubrique “Deployement Shares” et d’utiliser le menu contextuel “Propriétés“.

Activer le multicast sur un Deployment Share

Sous l’onglet “General” ouvert par défaut, cochez la case “Enable multicast for this deployment share …” puis  cliquez sur “Appliquer” et “OK” pour valider ce changement.

Poursuivez les étapes suivantes, uniquement lorsque le service WDS et la structure MDT sont sur des serveurs différents.

B. Référencer les images sur WDS dans MDT

Cette étape consiste à réaliser un petit tour de passe-passe afin que les images (éventuellement fabriquées par le MDT et stockées sur ce dernier) soient hébergées sur le serveur WDS.

En premier lieu, vous devrez importer l’image stockée sur votre MDT vers le serveur WDS, soit par copie préalable du fichier .WIM puis importation locale, soit par une importation directe à partir du réseau. Autrement dit, dans la console WDS, créez un nouveau groupe d’image d’installation, puis ajoutez une nouvelle image en stipulant le nom du fichier .WIM correspondant dans la structure MDT. (sous “Operating System“)

Cliquez deux fois sur “Suivant” puis sur “Terminer” une fois que l’image a été ajoutée correctement sur le serveur.

Démarrez la console MDT “Deployment Workbench“, puis  sélectionnez la rubrique ” Operating System“. Utiliser le menu “Action … Import Operating System” ou le menu contextuel.

Facultatif : Vous pouvez créer un sous-dossier, (“New folder” puis par exemple “WDS-01…”), afin de différentier cette importation particulière des instances stockées localement au sein de la structure MDT.

Sélectionnez l’option “Windows Deployment Services images“.

Puis cliquez sur “Next“. Entrez le nom ou l’adresse IP du serveur WDS (sans autre caractère UNC)

Cliquez deux fois sur “Next” puis sur “Finish“.

Cette procédure présente l’inconvénient de ne pas permettre la sélection des images que l’on souhaite importer.

Note : Des erreurs surviendront si vous avez implémenté le déploiement des disques virtuel .VHD via le serveur WDS.

Vérifiez que les images désirées sont bien présentes dans le volet de détail et au besoin supprimez les images inutiles. Vous ne supprimez alors qu’une référence, l’image reste bien sûr disponible sur le serveur WDS d’origine.

Les noms affichés dans le MDT sont de la forme “nom de l’image importée” in WDS group “Nom du groupe d’image” mais vous pouvez les modifier via le menu “Propriétés“.

C. Modifier / Choisir la source d’installation dans la séquence de tache

Là encore, pour cette opération, on peut considérer 2 déclinaisons types :

• Soit vous venez de “déplacer” une source initialement stockée sur le MDT vers le serveur WDS afin de bénéficier de la multidiffusion.

• Soit vous souhaitez créer une nouvelle séquence de tache.

Pour simplifier cette présentation, nous n’allons considérer que le premier cas. Démarrez la console “Deployment Workbench“, puis développez l’arborescence de la structure MDT jusqu’à la séquence de tache souhaitée située sous la rubrique “Task Sequence”

Sélectionnez la séquence de tache souhaitée, puis utilisez le menu “Action … Propriétés” ou le menu contextuel. Sélectionnez l’onglet “Task Sequence“, puis développez la structure afin de sélectionner la tâche “Install Operating System” située sous le groupe “Install”

Dans l’illustration ci-dessus, on peut constater que l’image du système d’exploitation est stockée localement  – Si le nom ne vous parait pas convaincant, utilisez le bouton “Browse” pour naviguer dans la structure  MDT.

Selon cette même technique, maintenant que les images du serveur WDS sont connues de votre MDT, cliquez sur le bouton “Browse“, puis sélectionnez l’image désirée (hébergée sur le serveur WDS).

Cliquez sur “OK” pour confirmer ce choix.

Cliquez sur le bouton “Appliquer” puis “OK” de la séquence de tache pour que le changement soit effectif.

D. Ajouter l’image de démarrage de type “LiteTouch ” sur WDS

Pour rappel, si vous ne l’avez pas déjà fait, pour ajouter un client LiteTouch sur un serveur WDS, il suffit de récupérer les fichiers LiteTouchPE_x64.wim et/ou LiteTouchPE_x86.wim situés dans le dossier “\Boot” du partage MDT (DeploymentShare). Assurez-vous qu’ils soient présents et à jour en effectuant un “update”, surtout si vous avez ajouté des pilotes ou modifié le “bootstrap.ini”.

Note : Pour ceux qui débuteraient avec MDT, il n’y a rien dans ce dossier tant que vous n’en avez pas lancé la fabrication. Pour y remédier, démarrez la console “Deployment Workbench“, sélectionnez le nom de votre MDT situé sous la rubrique “Deployement Shares” puis utilisez le choix “Update Deployment Share” via le menu contextuel. Dans l’assistant, cochez éventuellement l’option “Completly regenerate the boot images“

Cliquez 2 fois sur “Next” puis “Finish” (après quelques minutes d’attente…)

Ensuite, pour ajouter une image de démarrage LiteTouch, il suffit de lancer la console WDS puis de sélectionner la rubrique “Images de démarrage“. Utilisez ensuite le menu “Action … Ajouter une image de démarrage…” ou le menu contextuel.

Entrez ensuite le chemin UNC de l’un des fichiers générés tels que “\\ServeurMDT\DeploymentShare\Boot\LiteTouchPE_x64.wim ” puis cliquez sur “Suivant“.

Modifiez éventuellement les métadonnées du fichier .WIM qui vous sont proposées puis cliquez deux fois sur “Suivant“. Cliquez sur “Terminer” une fois que l’image a été ajoutée correctement sur le serveur.

Au besoin, réitérez cette opération pour ajouter le client LiteTouch 32 bits.

IV. Test du résultat

Démarrez votre machine de test à partir du réseau PXE, appuyez (une seconde fois) sur [F12] pour confirmer l’amorçage sur le serveur WDS. Selon votre configuration des images de démarrage, sélectionnez et validez le démarrage sur le client LiteTouch approprié:

À l’issue du chargement du noyau WinPE, vous serez invité à saisir vos identifiants (à moins qu’ils soient pré renseigné dans le fichier bootstrap.ini) puis l’assistant MDT (Windows Deployment Wizard) vous affichera la liste des séquences de taches disponibles.

Sélectionnez la séquence de tache (modifiée précédemment) puis cliquez sur “Next“. Renseignez les différents écrans (variables selon la configuration MDT) puis cliquez sur le bouton “Begin” pour démarrer l’installation.

Après la phase de partitionnement des disques, vous devriez voir apparaitre  l’initialisation de la transmission en multidiffusion de l’image.

Remarque : Normalement, une transmission multidiffusion nommée “MDT Share NomdevotreDeploymentShare” est automatiquement créée sur le serveur WDS. Dans le cas contraire, vous pouvez utiliser localement la commande suivante sur le serveur WDS, pour obtenir un résultat équivalent :

wdsutil.exe /new-namespace /FriendlyName:"Microsoft Deployment Server" /NameSpace:DeploymentShare /ContentProvider:WDS /ConfigString:e:\DeploymentShare /NameSpaceType:AutoCast

Rappel : Cette action n’est pas nécessaire SI MDT et WDS SONT SUR LA MÊME MACHINE !….

Exemple de résultat :

Bien à vous

Christophe

I. Présentation

Dans ce tutoriel, je vais vous présenter l’intégration des applications dans MDT ou la gestion des installations automatisée des applications.

Installer automatiquement un système Windows, est une chose que le MDT assure plutôt bien. En revanche, l’installation des applications peut rapidement devenir un véritable casse-tête, selon les choix retenus par les éditeurs de logiciels quant à leurs distributions. L’administrateur et/ou le responsable d’un parc informatique doivent pouvoir garantir un état stable et maitrisé des logiciels installés dans son organisation.

De cette problématique est né un nouveau métier : “L’intégrateur d’application”. Ses défis résident dans l’identification des solutions pour :

• Automatiser l’installation (et la personnalisation) d’une application
• Maitriser les mises à jour du système et/ou de ces mêmes applications
• Contrôler la cohérence des prérequis ou composants dits “partagés”
• Sans compter, une distribution des pilotes de périphériques nécessaires à l’exploitation optimale du système.

L’objectif est donc de vous présenter les bases et différentes techniques d’intégration d’application au sein d’une solution de déploiement telle que MDT. En gros, l’idée est de vous sensibiliser aux approches que vous pouvez envisager pour intégrer des applications dans vos images de référence (master).

• Au sein de l’image qui sera capturée – On peut envisager l’intervention humaine (du technicien) durant la fabrication), Mais toutes les applications ne supportent pas l’opération de nettoyage que le sysprep va réaliser. Typiquement, on y retrouve des agents réseau, les antivirus, les pilotes (eh oui, quand ils ne sont pas livrés au format .inf, il faut les considérer comme des applications) – Ce choix est particulièrement intéressant dès lors que le temps d’installation de l’application est élevé, mais l’intégration au sein de l’image WIM implique que le cycle de vie ou d’évolution de l’application est faible.

• En post-installation – Sans nul doute, la meilleure approche sous réserve de disposer de la commande d’installation silencieuse  – Idéalement, essayez de regrouper les applications au sein de bundles MDT (packs métiers, d’usage, etc…) – En effet, contrairement à la séquence d’installation des applications, il est plus facile de définir l’ordre d’installation et les dépendances applicatives au sein d’un bundle.

Pour intégrer des applications dans un processus de déploiement Windows, plusieurs approches, ou combinaisons peuvent être envisagées.

L’approche dépend essentiellement de la technologie de packaging (voir de licensing) fournie par l’éditeur du logiciel.

II. Les principales technologies

A. Les packages MSI

De plus en plus répandue, cette technologie offre de nombreux avantages dont les capacités d’installation / réparation / désinstallation silencieuse. Connue sous l’anglicisme “unattend mode” ou “mode sans assistance“, c’est-à-dire automatique, sans intervention humaine.

Ces packages sont parfois fournis sous une forme “encapsulée” telle qu’un programme setup / install.exe. Pour identifier un package MSI, il faudra surveiller le processus MSIEXEC au cœur de cette technologie. On distinguera 2 principaux type de packages :

• Autonome : Tous les fichiers sont inclus dans un fichier .MSI unique

• À plat : Un fichier .MSI contient les directives d’installation alors que les sources sont livrées à part, dans un sous dossier, ou dans une archive telle que “data.cab”

Les principaux commutateurs MSIEXEC à connaitre : (tapez msiexec /? pour tous les autres :-))

• /i ou /package : Indique le nom (chemin complet) du package MSI
• /qb ou /qn : Mode silencieux avec ou sans affichage utilisateur.
• /allusers = 2 : Indique, si applicable, dans quel contexte utilisateur (propre à un ou tous les utilisateurs) l’application doit s’installer.
• /addlocal : Permet d’indiquer la granularité des composants à installer, si applicable
• TRANSFORMS= : Indique le fichier de transformation .MST à utiliser
• /p ou PATCH= : Indique le fichier de correctif ou mise à jour.MSP à utiliser

Vous pouvez utiliser un éditeur gratuit, tel que ORCA ou InstEd pour vérifier (voire modifier) certaines informations de base sur un fichier MSI, voir générer/appliquer un fichier de transformation .MST

Personnellement je vous recommande l’éditeur gratuit “InstED”, car ORCA a un fâcheux défaut qui consiste à modifier la date du fichier même si vous annulez les modifications. (Faites une copie préalable à l’ouverture d’un MSI afin de vous mettre à l’abri de ce désagrément)

Les fichiers MST permettent de modifier le comportement d’une installation MSI. Pour rappel, même si cela est techniquement possible, il est fortement déconseillé de modifier directement le contenu d’un MSI. Il existe plusieurs moyens pour créer un fichier de transformation.

• Vous disposez d’un outillage spécialisé tel que Wise Studio, ou AdminStudio/installshield, et dans ce cas je pense que vous n’avez rien à faire ici.

• Votre DAF ne vous a accordé aucun budget, vous pouvez toujours créer un MST de base via l’outil gratuit “Wise Install Tailor”.

• Vous pouvez également utiliser ORCA, ou InstEd, mais c’est à mon avis un peu plus délicat, bien que tout à fait faisable.

• L’éditeur fournit un outillage, comme par exemple Adobe Customization Wizard

Exemple de commande (batch) d’installation silencieuse pour Adobe Reader XI avec correctifs v11.0.2 – Les erreurs proviennent souvent des chemins complets qui doivent être explicitement renseignés, à défaut d’être présents dans le répertoire courant.

set CurDir=%~dp0 
msiexec.exe /package "%CurDir%\AcroRead.msi"PATCH="%CurDir%\AdbeRdrUpd11001.msp;%CurDir%\AdbeRdrSecUpd11002.msp" TRANSFORMS="1036.mst" /passive

B. Les packages installshield

Bien que plus anciens et en voie de disparition, ces packages sont encore utilisés de nos jours. Ils sont généralement identifiables par l’icône assez typique du programme.

Ces programmes d’installation (typiquement Setup.exe ou Update.exe) supportent généralement un mode silencieux via le commutateur /quiet), mais disposent parfois d’un mode automatisé via un fichier de réponse. C’est dire qu’il suffit de démarrer l’installation en indiquant un fichier “.iss” en paramètre /F1.

Plus d’information sur :

– InstallShield Setup Silent Installation Switches

– Setup.exe and Update.exe Command-Line Parameters

Exemple : En premier lieu, selon le packaging de livraison, vous devez extraire l’intégralité du contenu de l’archive auto-extractible via 7-Zip. Puis lancer le programme d’installation comme suit :

C:\Repack\Appli1\Setup.exe /r /f1" C:\Repack\Appli1\inst.iss"

Vérifiez que l’installation s’est correctement déroulée en éditant le fichier journal “setup.log”. Celui-ci doit impérativement contenir une ligne “ResultCode=0”.

Le fichier « inst.iss » obtenu par la commande précédente est à conserver. Générez le fichier de réponse pour une désinstallation silencieuse via la commande :

C:\Repack\Appli1\Setup.exe /r /f1" C:\Repack\Appli1\uninst.iss"

Si la désinstallation s’est correctement déroulée, le fichier “uninst.iss” est à conserver.

Facultatif : Supprimer le dossier créé par une éventuelle installation manuelle A priori, n’existe pas si installation silencieuse :

rd /s /q "C:\Program Files (x86)\InstallShield Installation Information\{AC3D865A-0D8C-43C0-8BA7-7EC2D34BFBFE}"

L’installation silencieuse peut être assurée par la commande suivante (en mode administrateur) :

@start /wait %~dp0\Setup.exe /s /f1"%~dp0\inst.iss"

La désinstallation silencieuse peut être assurée par la commande suivante (en mode administrateur) :

@start /wait %~dp0\Setup.exe /s /f1"%~dp0\uninst.iss"

Remarque : Si le fichier de réponse n’a pas été généré, la commande suivante permet de désinstaller le produit, mais demande une confirmation à l’utilisateur. Je n’ai pas trouvé de palliatif pour ce cas de figure.

%~dp0\Setup.exe /M{AC3D865A-0D8C-43C0-8BA7-7EC2D34BFBFE} /uninst

C. Les packages traditionnels ou hérités (legacy)

Les packages réalisés avec des produits tels que “innosetup” ou “Nullsoft Scriptable Install System” sont facilement détectables dès lors que vous ajoutez le commutateur “/?” derrière l’exécutable – Généralement ces packages proposent généralement quelques commutateurs comme :

• /dir: pour stipuler le dossier de destination
• /norestart pour éviter un redémarrage
• /loadinf: pour ajouter un fichier de configuration / de réponse
• /saveinf: pour générer un fichier de configuration / de réponse
• /silent ou /verysilent pour réaliser une installation silencieuse

Mais il existe beaucoup de variantes (cf “Setup Command Line Parameters” ).

Des produits gratuits tels que PDF Creator, UltraVNC ou bien encore VLC utilisent ce type de packaging.

Ces sites peuvent vous apporter des compléments d’information précieux sur les techniques d’installation silencieuses :

• ITNinja (www.itninja.com )
• InstallSite (www.installsite.org )
• Installshield Support (support.installshield.com)
• Dell KACE (www.dell.com/kace )

D. Les packages propriétaires

Lorsque l’application est livrée dans un format propriétaire, qui plus est, sans aucun support d’un mode automatisé,:-( les solutions d’intégration seront implicitement très limitées, avec un coefficient de risque relativement élevé. Au cas par cas, selon les contraintes, on optera généralement pour :

• L’intégration de l’application au sein de l’image WIM (en réalisant l’installation manuelle avant le processus de capture) – sous réserve que l’application en question “résiste” à l’épreuve du nettoyage “sysprep”.

• Le “repackaging” que nous allons détailler ci-après

III. Le Repackaging

A. Les risques

Le Repackaging (ou technique de la dernière chance) n’est pas sans risque – En effet, cette technique consiste à utiliser un outil qui va prendre un instantané (snapshot) du système avant puis après l’installation du logiciel.

L’inconvénient majeur de cette technique est qu’elle repose sur une configuration stable et maitrisée du système. En effet, il n’est pas certain que le package obtenu puisse s’installer sur un autre système de version différente, voire parfois même en raison d’une simple différence de service pack ou d’une mise à jour qui pourrait faire échouer l’installation.

J’ajouterais que la technique de packaging par capture souffre de 2 handicaps majeurs :

• Elle peut engranger des polluants d’utilisation (informations annexes et sans rapport avec le produit, généré par les processus et services en cours d’exécution)

• Elle ne tient pas compte des éventuels redémarrages qui ont été nécessaires (Certaines applications ont besoin d’un redémarrage pour achever correctement leur configuration)

Quel que soit le produit retenu, il faudra être particulièrement attentif aux composants complémentaires apportés par l’application, tels que les redistribuables C++ ou autres framework.NET… Il est souhaitable de les considérer comme des packages dépendants, mais distincts et ne pas les inclure dans le package de l’application.

En conséquence, pour effectuer un repackaging par capture dans les meilleures conditions possibles, il est souhaitable de :

• Installer une machine virtuelle avec le socle de référence (composants inclus)

• Désactiver tous les agents, services et autres antivirus susceptibles d’interférer avec le processus de capture. (Windows Update, Defender, etc…)

• Faire un snapshot de la VM avant toute modification. N’hésitez pas à réaliser des snapshots intermédiaires en fonction de la complexité de réalisation.

• N’oubliez pas de supprimer les éventuels fichiers de désinstallation (inutiles si vous avez obtenu un package MSI)

B. Virtualisation d’application  ?

Au fil du temps, la technique de repackaging a évolué pour se scinder en 2 approches distinctes :

• Le repackaging “natif” qui consiste à obtenir un package MSI “traditionnel”

• La virtualisation d’application qui consiste à obtenir un package de type ‘bac à sable” (sandbox) afin de l’imiter les impacts sur le système et autoriser des instances concomitantes dans certains cas. Parmi ces solutions, on retrouve les leaders du marché :
  • Microsoft AppV (Initialement Softgrid)
  • VMware Thinapp (Egalement associé à l’offre Landesk)
  • Citrix XenApp
  • Novell ZAV / Xenocode Virtual Application Studio / Spoon.net
  • Et quelques outsiders
  • Symantec SVS (Initialement Altiris et Appstream)
  • Cameyo (Gratuit)

Mais la virtualisation d’application est loin d’être une panacée. En effet, si cette technologie est prometteuse elle draine cependant quelques contraintes de taille :

• Avantages
  • Cohabitation de versions concurrentes d’un même produit (ie Plusieurs JRE dans différentes instances de navigateurs, meilleure isolation avec le système
  • Streaming – L’application peut être publiée sur un portail ou un magasin distant et commencer son démarrage avant d’être totalement présente dans le cache local du poste.

•  Inconvénients
  • Dépendance du système
  • Pas de communication transverse ni entrante vers les instances virtuelles (addins, plugins…)
  • La prise en charge des objets COM/DCOM n’est pas toujours efficiente

IV. Intégration des applications dans MDT

Maintenant que le décor est planté, passons à la partie “industrialisation” via le MDT. Si vous êtes arrivé jusqu’à l’installation silencieuse de vos applications, leur intégration au sein du MDT sera une formalité.

Premier conseil : Pensez à créer préalablement un dossier dédié contenant les sources nécessaires à l’installation de l’application. Cela facilitera grandement la gestion de vos différents packages.

Lancez la console “Deployment Workbench” puis développez l’arborescence jusqu’à “MDT Deployment Share … Applications” puis effectuez un clic droit “New Application“.

Conservez l’option par défaut si les sources doivent être hébergées dans la structure MDT (DeploymentShare). Utilisez la seconde option si vous préférez publier les sources sur un autre serveur de fichier. Cliquez sur “Next”

Entrez le nom de l’application (obligatoire) et ajoutez éventuellement le nom de l’éditeur, la version, la langue. (Ces éléments formeront le nom dossier par défaut des sources de l’application) – Cliquez sur “Next”

Utilisez le bouton “Browse” pour sélectionner le dossier contenant les sources de l’application puis cliquez sur “Next”

Acceptez (ou modifiez) le nom de dossier proposé puis cliquez sur “Next“. L’assistant vous demande alors de saisir la ligne de commande (d’installation silencieuse).

Si vous ne l’avez pas sous la main, entrez une commande quelconque ; cette information sera modifiable a posteriori. Cliquez 2 fois sur “Next” puis sur “Finish” une fois l’importation terminée.

Pour vérifier ou modifier les informations d’une application, sélectionnez-la puis faites un clic droit “Propriétés“. Sous l’onglet “Details“, vous pourrez renseigner cette fameuse ligne de commande magique “Quiet install command”  chargée de réaliser l’installation automatique.

Ne vous inquiétez pas, ça peut rapidement dépasser le cadre affiché

Exemple de commande :

start /l*v "%TEMP%\FoxitReader_InstallLog.txt" MAKEDEFAULT=1 LAUNCHCHECKDEFAULT=0 VIEW_IN_BROWSER=1 STARTMENU_SHORTCUT=1 DESKTOP_SHORTCUT=0

Le principal inconvénient d’une application au sens MDT, est surtout lié au fait qu’il n’y a qu’une seule commande.

C’est une des raisons pour laquelle il est préférable d’utiliser un script (batch ou PowerShell) pour chainer un ensemble de commandes (et homogénéiser vos installations).

Pour l’intégration des applications du marché, et leur intégration dans MDT, je vous conseille d’essayer “setup commander” de Rovabu Software . La version PRO d’évaluation vous sera fournie sur simple demande, et vous permettra de gérer très facilement un catalogue des principales applications courantes, et les intégrer dans des packages d’applications / bundles MDT en quelques clics ….

Voilà pour les bases en matière de packaging et intégration éventuelle dans le MDT.

Je pense vous proposer quelques exemples concrets et retours d’expériences dans un avenir plus ou moins proche. Juste le temps pour moi de réorganiser et réactualiser quelques composants. Je rajouterai le lien ici dès que possible.

To be continued …

Christophe

I. Présentation

Vous savez surement que le MDT est une fabuleuse “usine” capable de vous assister pour la plupart de vos taches de déploiement. Au cours de vos expériences, vous aurez certainement remarqué qu’il était possible de générer des images de démarrage WinPE, pour obtenir vos clients LiteTouch mais également pour des noyaux plus génériques.

En général, ce que l’on connait moins, c’est la façon dont MDT construit ces images et la possibilité d’agir sur cette fabrication.

II. Principe des “templates”

Pour générer les images de démarrage (boot images), MDT s’appuie sur les éléments du kit ADK (anciennement WAIK) ainsi que sur des fichiers au format .XML servant de modèles de construction.

Le fichier utilisé pour la structure de base d’un noyau WinPE pour client LiteTouch est :
“C:\Program Files\Microsoft Deployment Toolkit\Templates\LiteTouchPE.xml”

La composition de ce fichier est assez simple à déchiffrer.
En premier lieu, on peut remarquer une section “<!– Settings –>” , définissant l’espace de travail “ScratchSpace” . Notion sur laquelle je reviendrais ultérieurement.

LiteTouchPE.xml – Section “Settings”

Puis une section “<!– Components –>” chargée d’énumérer les fonctionnalités et composants à intégrer dans le noyau.

LiteTouchPE.xml – Section “Components”

Contrairement aux composants (OC’s : Optional Components  ) qu’il est possible de choisir sous l’onglet “Features“, il s’agit ici des composants impératifs qui seront systématiquement ajoutés aux noyaux.

La section “<!– Driver and packages –>” est vide par défaut, et comme son nom le laisse supposer, elle est destinée à recevoir les pilotes et autre packs linguistiques à ajouter au noyau de base.

LiteTouchPE.xml – Section “Driver and packages”

Là encore, il est inutile de modifier cette section du fait qu’il est possible de contrôler cette intégration par le biais d’un profil de sélection (Cette notion sera évoquée ultérieurement).

Vient ensuite la section “<!– Content –>“, composée de 3 sous-ensembles

Les fichiers de “configuration”, parmi lesquels on retrouve “Bootstrap.ini”, “Unattend.xml” et “winpeshl.ini”.

LiteTouchPE.xml – Section “Configuration”

Notez que le fichier “Unattend.xml” est lui-même repris selon un modèle dépendant de l’architecture en question x86 ou amd64.

On retrouve dans la partie “<!– Scripts –>“, l’ensemble des scripts du MDT utilisés dans le traitement des séquences de taches, ainsi que des fichiers annexes, xml, png, jpg.

LiteTouchPE.xml – Section “Scripts”

Et enfin dans la partie “<!– Tools –>“, on trouve l’ensemble de la boite à outils MDT composée de plusieurs programmes exécutables et autres bibliothèques.

LiteTouchPE.xml – Section “Tools”

La dernière section “<!– Exits –>” référence simplement le script chargé de positionner les variables qui seront utilisées par le processus de mise à jour et de fabrication des images WIM et/ou ISO.

LiteTouchPE.xml – Section “Exits”

Maintenant, si nous jetons un œil sur le modèle de construction d’un noyau générique, “C:\Program Files\Microsoft Deployment Toolkit\Templates\Generic.xml“, on peut constater que son contenu est particulièrement simple.

Generic.xml

Pour rappel, ce genre d’image se contente de charger un noyau minimaliste et nous amène sur une simple invite de commande.

III. Personnalisation de WinPE dans la console MDT

Dans la console MDT, les personnalisations de WinPE sont regroupées au niveau de l’onglet “Windows PE” affiché via les propriétés d’un partage de déploiement.

Propriétés MDT Deployment Share – Onglet “Windows PE”

A chaque ouverture de cette fenêtre, vous devrez prêter attention à l’architecture “Platform” car les réglages sélectionnés sont indépendants pour chacune des 2 images WinPE.

A. Onglet “General”

Sous l’onglet “General“, vous pouvez opter pour la construction d’images spécialisées pour le déploiement, “Lite Touch Boot Image” et/ou des images simples “Generic Boot Image“. Pour chacune d’entre elle, il est possible d’enchainer l’encapsulation de l’image .WIM au sein d’un fichier .ISO prêt à l’emploi (bootable).

Vous pouvez personnaliser quelques réglages simples au niveau du cadre “Windows PE Customizations”

• Custom background bitmap file : Pour modifier l’image de fond d’écran sur WinPE, il suffit de sélectionner une image de votre choix à partir du bouton “Browse“. Par défaut, le fichier proposé est “%INSTALLDIR%\Samples\Background.bmp“. Depuis WinPE 3, il est possible d’utiliser un format de fichier .jpeg, moins gourmand en taille. Restez toutefois raisonnable sur la taille et la résolution de l’image.

• Extra directory to add : Ce choix permet d’ajouter un dossier de votre choix dans le noyau de WinPE, tel qu’un ensemble d’utilitaires techniques. Attention toutefois à la taille qui influence directement la charge du noyau et à l’architecture 32 versus 64 bits des programmes. J’y reviendrais dans un autre article.

• Scratch space size : Cette valeur, positionnée à “32” par défaut, définit l’espace de travail temporaire affecté en complément du disque mémoire “Ramdrive” de WinPE (variable de 32 à 512 Mo). Cet espace est principalement utilisé par le chargement des pilotes. Personnellement, pour des machines récentes, je vous conseille de positionner cette valeur sur “128”, suffisante dans la plupart des cas.

B. Onglet “Features”

Revenons à présent sur la faculté de personnalisation des composants optionnels mentionnée précédemment, et exposés sous l’onglet “Features“.
En fait, les binaires correspondants à ces fonctionnalités sont dans les dossiers “WinPE_OCs” situés dans le kit et peuvent être ajoutés unitairement via la commande “DISM /add-Package“, ou plus simplement par le MDT sous cet onglet “Features“.

Propriétés MDT Deployment Share – Features (Par défaut)

Cette liste est contenue dans le fichier “C:\Program Files\Microsoft Deployment Toolkit\Bin\FeatureNames.xml”. Vous pouvez toutefois la modifier comme suit (en effectuant une copie de secours préalable) afin d’exclure les fonctionnalités dont vous n’avez pas l’utilité comme par exemple:

<?xml version="1.0" encoding="utf-8" ?>
<features>
  
	<feature id="winpe-mdac">Microsoft Data Access Components (MDAC/ADO) support</feature>
	<feature id="winpe-rndis">Remote Network Driver Interface Specification (RNDIS) support</feature>
	<feature id="winpe-dot3svc">IEEE 802.1x network authentication protocol</feature>
	<feature id="winpe-pppoe">Point-to-Point Protocol over Ethernet (PPPoE) support</feature>
	<feature id="winpe-srt">Windows Recovery Environment</feature>

	<feature id="winpe-fontsupport-ja-jp" option="exclude">Japanese (JA-JP) language pack</feature>
	<feature id="winpe-fontsupport-ko-kr" option="exclude">Korean (KO-KR) language pack</feature>
	<feature id="winpe-fontsupport-zh-cn" option="exclude">Chinese (ZH-CN) language pack</feature>
	<feature id="winpe-fontsupport-zh-hk" option="exclude">Chinese (ZH-HK) language pack</feature>
	<feature id="winpe-fontsupport-zh-tw" option="exclude">Chinese (ZH-TW) language pack</feature>
	<feature id="winpe-fonts-legacy" option="exclude">Legacy fonts</feature>

	<feature id="winpe-legacysetup" option="exclude">Windows setup files (all contents from the sources folder)</feature>
	<feature id="winpe-setup" option="exclude">Setup feature package (parent)</feature>
	<feature id="winpe-setup-client" option="exclude">Client Setup feature package (child)</feature>
	<feature id="winpe-setup-server" option="exclude">Server Setup feature package (child)</feature>
	<feature id="winpe-wds-tools" option="exclude">Windows Deployment Services Tools</feature>

	<feature id="winpe-hta" option="exclude">HTML Application support</feature>
	<feature id="winpe-scripting" option="exclude">Windows Script Host (WSH) support</feature>
	<feature id="winpe-wmi" option="exclude">Windows Management Instrumentation (WMI) support</feature>

	<feature id="winpe-netfx">.NET Framework </feature>
	<feature id="winpe-powershell">Windows PowerShell </feature>
	<feature id="winpe-dismcmdlets" parent="winpe-netfx,winpe-powershell">DISM Cmdlets</feature>
	<feature id="winpe-storagewmi" parent="winpe-netfx,winpe-powershell">Storage Management Cmdlets</feature>
	<feature id="winpe-enhancedstorage" parent="winpe-netfx,winpe-powershell">Enhanced Storage</feature>
	<feature id="winpe-securebootcmdlets" parent="winpe-netfx,winpe-powershell">Secure Boot Cmdlets</feature>

	<feature id="winpe-securestartup" option="exclude">Secure Startup</feature>
	<feature id="winpe-fmapi" option="exclude">File Management API</feature>
	<feature id="winpe-winrecfg" option="exclude">Windows RE Configuration</feature>

	<feature id="dart">Microsoft Diagnostics and Recovery Toolkit 7 (DaRT 7)</feature>
	<feature id="dart8">Microsoft Diagnostics and Recovery Toolkit (DaRT)</feature>

</features>

En redémarrant la console MDT, vous pourrez constater que l’affichage est allégé

Propriétés MDT Deployment Share – Features (Allégé)

C. Onglet “Driver and patches”

Attardons-nous maintenant sur la gestion des pilotes et des packages au sein des noyaux WinPE. Dans la console MDT, toujours sous l’onglet “Windows PE” et sous l’onglet “Driver and patches“, vous pouvez constater que l’injection de ces éléments peut être réalisée de diverses manières:

Propriétés MDT Deployment Share – Drivers and Patches

Comme expliqué dans un précédent article, les pilotes sont “intelligemment” injectés en fonction de leur classe (types).

Par défaut les pilotes et packages sont recherchés dans ce que l’on nomme un “profil de sélection” (selection profile). En fait, il s’agit simplement d’une sélection mémorisée et nommée de toute ou partie d’une arborescence de dossiers du MDT.

Note : Il est conseillé de créer des sous-dossiers pour la gestion de vos différentes ressources MDT, telles que les applications, les séquences de taches, les packages et particulièrement pour différencier les pilotes que vous souhaitez distinguer de la masse. Grâce à cette bonne pratique vous pouvez maitriser la granularité des profils de sélection.

Par défaut, il existe plusieurs profils prédéfinis stockés dans le fichier “SelectionProfiles.xml” situé sous le dossier “Control” du partage de déploiement.

Vous pouvez créer vos propres profils de sélection pour couvrir vos différents besoins. La procédure est plutôt simple, puisqu’il suffit de développer l’arborescence de la console MDT jusqu”à la rubrique “Advanced Configuration … Selection Profiles”

Selection Profiles

Puis d’utiliser le menu “Action … New  Selection Profile” ou le menu contextuel.

New Selection Profile – General

Entrez le nom de votre profil de sélection et une description éventuelle puis cliquez sur “Next“.

New Selection Profile – Folders

Cochez simplement le(s) dossier(s) souhaité(s) puis cliquez 2 fois sur “Next” et enfin sur “Finish“.

Une fois le profil créé, vous pourrez l’ajouter facilement à vos fabrications.

Note : Les profils de sélection sont également très pratiques pour la gestion des points de déploiement liés “Linked Deployment Shares” afin de ne pas répliquer inutilement des informations sur vos différents serveurs MDT.

I. Présentation

Comme je le répète souvent, le MDT est un outil fantastique pour qui sait l’exploiter. Vous pouvez trouver d’excellents tutoriels sur son implémentation et le déploiement des images Windows. En revanche, je pense que l’on n’insiste pas assez sur ces capacités de gestion des applications.

Pour pallier cette lacune, je vais soumettre à votre critique quelques réflexions que je considère importantes pour une bonne gestion au sein de votre MDT.

II. Avant-propos

Avant de présenter ce sujet plutôt vaste, je tenais à vous sensibiliser sur le dilemme de l’intégration (ou non) de vos applications dans une image WIM. Quel que soient les cas étudiés, les avis sont pratiquement toujours partagés. Essayons de résumer la situation dans un petit tableau de synthèse :

En résumé, cette réflexion pourrait être schématisée comme suit :

Ce schéma est simplement ce que je qualifierais d’une “vue d’avion” et n’apporte aucune réponse en l’état. L’idée première étant simplement de mettre en exergue la problématique de la distribution et le cycle de vie des images et des applications.

En fait, il s’agit de trouver l’emplacement du curseur qui va déterminer les applications communes à un ensemble significatif de machines que vous intégrerez ou non dans vos images WIM dites « Master ». J’ai volontairement évoqué la possibilité de distribuer des applications en exploitation via des produits et infrastructures adaptées, mais c’est un autre sujet.

Lors de l’étude d’une image de référence vous pouvez envisager d’intégrer les mises à jour Windows Update (ou WSUS). Même si ces mises à jour s’effectuent en tache de fond et n’empêchent pas l’usage de l’ordinateur (hormis les demandes de redémarrage) cette pratique reste intéressante pour optimiser vos déploiements via MDT.
Cet argument joue en faveur de l’étude de construction de l’image initiale via une séquence de tache. En effet, il est possible de construire manuellement l’image de référence puis réaliser une simple tache de « sysprep et capture » mais le cycle de mise à jour de cette image sera moins fiable. Autrement dit, prévoyez au moins 2 séquences d’installation distinctes :

• Construction automatique du master avec applications intégrées, avec une préparation et capture de résultat.
• Séquence de déploiement de l’image de référence et des applications en post-installation

Une bonne pratique peut consister à distinguer dans le nommage et/ou les dossiers MDT, les applications intégrées dans l’image WIM de celles qui sont déployées en post-installation.

Remarque : N’oubliez pas que les applications intégrées peuvent avoir besoin des sources d’installation en cas de réparation. Cette considération est particulièrement importante si vous installez ces applications à partir de sources inaccessibles en exploitation ou sur des chemins réseau différents de l’atelier de fabrication. (Prévoir une copie locale le cas échéant)

Entrons maintenant dans le vif du sujet et les concepts d’application au sens MDT…

III . Les concepts d’applications MDT

A. Applications, Bundles et Dépendances

Si vous avez déjà eu un premier contact avec MDT, vous aurez probablement découvert qu’il était possible d’ajouter des applications, ponctuellement dans une séquence de tache, ou explicitement dans le CustomSettings.ini , via leur identifiant unique GUID (Au besoin reportez-vous à mon tutoriel sur la “Configuration avancée de MDT 2013“). MDT offre également la possibilité de recourir à des ensembles d’applications, nommés “Bundles“, éventuellement associés à des rôles dans la base de données mais nous reviendrons sur ces notions dans la seconde partie …

En premier lieu – N’hésitez pas à créer des sous-dossiers afin d’organiser au mieux vos applications. Prenez l’habitude de les classer et distinguer les applications spécifiques, des applications courantes, du tronc commun et les composants. Dans la mesure du possible, essayez de les regrouper par “lot métier”.

La première chose à savoir, c’est que pour chaque application dans MDT, il est possible de définir des dépendances. Cette faculté est très intéressante

Ensuite ces applications peuvent être organisées, ou regroupées en “bundles“, c’est-à-dire des ensembles de 1 à n applications ou scripts d’installation.

New Application Wizard – Application Type

Dans l’assistant d’ajout d’application :

• Le premier choix permet de copier les sources de l’application au sein de la structure MDT

• Le second choix permet de référencer un partage réseau à partir duquel l’installation de l’application sera exécutée.

• Le troisième choix permet de définir un regroupement de type “Bundle” d’application.

Ces choix peuvent être modifiés à posteriori.

Lorsque vous ajoutez une nouvelle application dans le MDT, vous êtes invité à saisir la ligne de commande pour l’installation silencieuse. Si vous n’êtes pas encore en mesure d’indiquer la commande complète, entrez juste la commande manuelle tel que “setup.exe“, vous pourrez y revenir plus tard…

Pensez à préparer préalablement cette étape, en créant un sous-dossier spécifique ne contenant que les fichiers et dossiers nécessaires à l’installation de l’application car l’assistant copiera (ou déplacera) l’intégralité de la structure du dossier racine qui sera stipulé.

New Application Wizard – Command Details

La commande d’installation silencieuse (Quiet Install Command)  à saisir dans le champ “Command Line“,  peut être très longue et je préfère personnellement privilégier l’écriture d’un script dédié à l’installation de l’application. En effet, un simple batch, un vbs ou plus simplement un script Powershell, vous permettra non seulement d’homogénéiser vos processus d’installation, mais aussi d’enchainer des actions supplémentaires telles que des modifications de registre, l’enregistrement de journaux, etc…

Vous pourrez ensuite ajouter des dépendances (pointant sur des applications MDT ajoutées préalablement) – Il est possible d’agir sur l’ordre d’installation de ces dépendances. – L’installation d’une dépendance est ignorée si l’application est déjà installée.

Au sens MDT, un ensemble “bundle” ne contient pas de commande d’installation. Pour ma part, je les classe généralement dans un sous-dossier différent de celui des applications – En fait, c’est une sorte de coquille vide où seul l’onglet “Dependencies” est pertinent.

1. Les packages et pilotes en tant qu’applications

Avant d’aborder les applications dites “traditionnelles”, j’attire votre attention sur le fait que cette notion d’installation d’application peut être étendue à la gestion de packages et/ou des pilotes dont le packaging ou le format n’autoriserait pas une intégration native au sein des rubriques prévues à cet effet.

a. Précisions sur les packages

La rubrique “Packages” est destinée à recevoir les mises à jour Windows Update en mode hors ligne ainsi que les packs linguistiques. Le but étant de les référencer et les installer via le fichier de réponse XML des images. La gestion des mises à jour est généralement à la charge d’un serveur WSUS mais certains préféreront les intégrer dans l’image WIM durant le processus de capture afin d’accélérer le processus de déploiement et simplifier la gestion. (cf Ajout des mises à jour en tant que packages MDT)

La rubrique “Packages”  n’accepte que des formats .CAB ou .MSU. Toutefois, vous pouvez également les injecter en tant qu’application.

b. Les packages et les pilotes sous MDT

Si vous avez parcouru à minima mes précédents tutoriels sur le sujet, vous savez probablement que le MDT dispose d’une structure de stockage spécifique aux mises à jour Windows, “Packages” ainsi qu’un espace réservé aux pilotes de périphériques tiers “Out-of-Box Drivers” – C’est à dire ceux qui ne sont pas déjà intégrés par défaut dans les sources des systèmes d’exploitation. Hors, cette rubrique ne peut recevoir que des packages de type .INF. Malheureusement, dans certains cas, les fabricants de matériel peuvent distribuer le pilote sous la forme d’un exécutable non compatible avec la structure MDT. Vous devez alors envisager 2 solutions :

• Gérer le package de ce pilote comme une application : Pour cela, il est souhaitable que le programme supporte une installation silencieuse. Notez que certains packages sont conçus à partir de DPINST issus du kit WDK de Microsoft. Dans ce cas, reportez-vous aux commutateurs supportés par cet outil : “DPInst Command-Line Switches“

• Installer le pilote sur un poste type, puis l’extraire via un outil tel que DriverMax, DriverMagician ou encore l’outil gratuit DriverBackup!  – Une fois que les fichiers du pilote auront été extraits (.inf à minima, et autres binaires ou dll) vous n’aurez plus qu’à les injecter dans le MDT à l’emplacement prévu à cet effet. Cette approche n’est pas garantie mais peut parfois vous sortir d’une passe délicate. Notez en passant, qu’il est possible de tester certains pilotes dans WinPE, comme des cartes réseau par exemple, via la commande “DRVLOAD <chemin-package\fichier.INF”

Note : Vous pouvez également injecter ces packages dans une image donnée en mode hors ligne sans rejouer le processus de capture. (cf MDT-tutoriel-methodes-de-mise-jour-dune-image-windows-de-reference)

B. Bonnes pratiques

Revenons maintenant à nos fameuses applications MDT et autres lignes d’installation silencieuses. Si vous n’êtes pas un spécialiste du sujet, voici quelques pistes que je vous conseille de suivre …

1. Résumé des commandes d’installation :

Typiquement, la commande d’installation d’une application MSI peut ressembler à ceci :

Msiexec.exe /i package.msi REBOOT=ReallySuppress UILevel=67 ALLUSERS=2 /l*vx %LogPath%\package.log /qb-

Si l’aide intégrée “msiexec /?” ne vous suffit pas, vous trouverez de nombreux détails sur les commutateurs de cette commande sur MsiExec

Quelques explications sur l’exemple précédent :

• UILevel : Bien que rarement utilisé, ce commutateur permet d’indiquer le niveau d’information affiché durant l’installation. Le tableau ci-après permet d’obtenir les valeurs possibles (Des combinaisons multiples sont possibles en ajoutant les valeurs désirées entre elles) :

• ALLUSERS = 2 : Le réglage de cette propriété permet de préciser que l’installation doit se faire dans le contexte commun à tous les utilisateurs du poste. La valeur 1 est similaire mais depuis Windows 7, Microsoft préconise l’usage de la valeur 2. En fait, cela permet au système de définir le choix le plus approprié pour ALLUSERS, et ce en fonction du contexte de l’installation, des privilèges de l’utilisateur (UAC) et de la version de Windows. (cf MSIINSTALLPERUSER)

Pour éviter d’éventuelles certaines mauvaises surprises, je préconise que les scripts d’installation des applications prennent en charge l’attente du processus. Autrement dit, entrez les commandes suivantes dans un script de type :

– En mode Batch :

Start /Wait Msiexec /i …

– En VBScript :

Set oShell = CreateObject("WScript.Shell")
sErrorCode = oShell.Run "Msiexec /i … " ,0,True

– En PowerShell :

Start-Process –Wait "Msiexec /i … "

Remarque : Nativement, le MDT intègre au sein des taches d’installation d’applications, un traitement d’erreur pour les codes retour “0” et “3010”.

Task Sequence – Success codes

Autrement dit, une application est considérée comme ” bien installée” et la tache correctement traitée dès lors que l’installation s’est déroulée normalement (code retour = “0”) ou que l’application nécessite un redémarrage (code retour = “3010”).

2. Quelques bons principes…

Pour les applications “non MSI” (et MSI aussi d’ailleurs) essayez de respecter les règles suivantes :

• Utilisez des commandes d’installation silencieuse – l’affichage de la progression peut être intéressant pour vérifier visuellement l’activité.

• N’oubliez pas la gestion des erreurs et le cas échéant, les consigner dans des journaux.

• Faites attention aux programmes qui déclenchent plusieurs processus. Certaines tâches d’arrière-plan peuvent passer inaperçues pour le MDT. De fait, le MDT poursuit sa séquence avec la prochaine installation qui peut entrer en conflit avec le processus inachevé. De plus certaines tâches de fond peuvent déclencher un redémarrage intempestif de la machine.

• N’utilisez pas de redémarrage durant ces séquences. La plupart des installations ne requièrent pas de démarrage, sauf dans le cas de modification des pilotes ou composants système en cours d’utilisation. Comme mentionné précédemment, lorsqu’une installation d’application requiert un redémarrage, celle-ci lève le code d’erreur “3010” (ERROR_SUCCESS_REBOOT_REQUIRED). Le MDT interprète ce code particulier et poursuit ses opérations. Il inclura automatiquement un redémarrage à la prochaine occasion.

• Pensez à toujours vérifier/préciser le contexte d’installation à ALLUSERS=1 ou 2 (Pour rappel, c’est le compte administrateur intégré, non soumis aux contraintes du contrôle de compte utilisateur (UAC) qui est utilisé par les séquences de tâches du MDT).

• Pour les packages MSI, n’hésitez pas à “surcharger” les propriétés publiques que vous pouvez facilement consulter via ORCA ou InstED dans la table “Property” comme par exemple un choix sélectif des composants (cf table “components”) au lieu de “ADDLOCAL=ALL”.

• C’est peut être une évidence, mais pensez à utiliser le commutateur ” /?” derrière un exécutable. Dans de nombreux cas, la réponse est dans cette question 

• Evitez d’intégrer des packages auto extractibles (contenant des MSI) – Réalisez l’extraction préalablement, voire une installation administrative “msiexec /a” afin d’obtenir des sources directement exploitables dans un dossier dédié à cet effet.

• Le nommage des applications est relativement libre mais il est souhaitable d’indiquer la version et l’architecture* de l’application. (Surtout sur les packages x64, potentiellement incompatibles avec les plateformes x86).

• Enfin et bien que cela puisse influencer les processus d’auto-réparation, il est de bon ton de ne créer aucun raccourci d’application sur le bureau. Prenez note du ou des raccourcis créés durant une installation traditionnelle puis ajoutez-les dans une préférence de stratégie de groupe.

A ces bonnes pratiques, j’ajouterai qu’il est souhaitable de maintenir au moins 2 structures MDT comme par exemple :

• MDT Build : pour la fabrication des images de référence. Vous y stockerez toutes les applications dont celles qui seront intégrées dans les images WIM par le biais des séquences de capture.

• MDT Deploy : pour le déploiement dans l’environnement de production (ou préprod) dans laquelle les applications intégrées aux images (ainsi que les pilotes inutiles et autres applications de test) n’ont pas lieu d’être.

IV. L’intérêt des rôles dans MDT /DB

A. Présentation

Pour faire suite à cette présentation sur la “Gestion des applications dans MDT“, je vous propose d’aborder l’usage d’une fonctionnalité avancée du MDT, connue sous le nom de “Rôles“. Avant toute chose, je précise que ce terme n’a rien à voir avec la notion utilisée dans les distributions Windows Server.

Dans les grandes lignes, cette approche consiste à gérer des sortes de “profils” ou “modèles de configuration”, servant à définir des installations selon des réglages et applications spécifiques.

Par exemple, un rôle MDT pourrait associer l’installation d’un système d’exploitation avec une combinaison d’applications ou de bundles, tel que “Socle Poste Fixe” + “Pack Bureautique“.

Toutefois, avant de vous lancer dans cette gestion, il est préconiser d’installer et configurer une base de données pour le besoin de MDT.

B. Installation de la base de données

Il existe déjà de nombreux articles sur le sujet, portant sur différentes versions de MDT et de moteur SQL, et je vais donc essayer d’aller à l’essentiel pour la mise en œuvre d’une maquette basique. Au besoin, consultez l’excellent article de Yannick Plavonil sur l’usage d’une base de données avec MDT2010  dont la procédure reste similaire pour les versions plus récentes de MDT.

En 1er lieu, je considère que nous avons déjà installé MDT (2012 ou 2013) ainsi que l’ADK ou WAIK, et qu’ils sont opérationnels. Selon les versions de MDT, vous pouvez choisir entre plusieurs versions de bases SQL Server, et je vais partir sur le postulat MDT2013 + ADK8.1 + SQLExpress2012 – Ces versions dont relativement récentes mais le principe restera le même avec des versions sensiblement différentes.

Note : En raison des modifications importantes qui seront appliquées à la configuration MDT, pensez à faire une copie de secours de votre fichier “CustomSettings.ini” situé dans le dossier “Control” de votre partage de de déploiement.

1. Installation de l’instance SQL

Généralement, je déconseille d’utiliser le produit SQL Express fournit avec les kits WAIK ou ADK, afin de maitriser la version que l’on souhaite exploiter. Pour cette démonstration, nous allons retenir SQLExpress2012 – Je vous conseille activement de télécharger le package SQL Express avec les outils – SQLEXPRWT_x64_FRA.exe – Lancez l’installation sur la machine MDT (La procédure est très proche de celle décrite sous la rubrique “Installation et configuration de SQL Server 2008 R2 Express” de cet article “MDT SQL” . ) – Choisissez l’authentification mixte (Windows et SQL) pour simplifier la mise en œuvre maquette.

Sachez que MDT supporte les 2 types d’identification, à définir au sein du fichier CustomSettings.ini.

2. Création de la base MDT

Une fois votre instance SQL installée, vous devrez lancer la console “Deployment Workbench” puis ouvrir (ou créer) un point de déploiement. Ensuite, vous devrez développer l’arborescence de la console jusqu’à  “MDT Deploymentshare … Advanced Configuration … Database” puis faites un clic droit (menu contextuel) sur ce dernier élément pour choisir “New database“.

MDT – New Database

Sous l’assistant de création “New DB wizard“, entrez le nom ou l’adresse IP du serveur MDT, le nom de l’instance, par défaut “SQLExpress“, puis la méthode d’accès à la base SQL, soit “Named Pipes” par défaut. L’accès via les canaux nommés est plus simple à mettre en œuvre lors d’une maquette de démonstration. Toutefois dès lors que la base de données n’est pas sur le serveur MDT, il est probable que la méthode “TCP/IP Sockets” sera préférable. Rapprochez-vous de votre DBA pour connaitre les modalités d’implémentation dans un environnement de production.

New DB Wizard – SQL Server Details

Cliquez sur “Next”, puis choisissez la première option “Create a new database” et entrez le nom de cette nouvelle base de données, tel que “MDT“.

New DB Wizard – Create a new database

Les autres choix permettent respectivement de recommencer en réutilisant une base de données précédente dont les tables seront réinitialisées ou de réutiliser une base de données ainsi que les tables existantes (ré-association). Cliquez sur “Next“.

New DB Wizard – SQL Share

Vous pouvez laisser le champ “SQL Share” vide ou entrer le nom d’un partage qui sera utilisé pour déposer les journaux d’activité de déploiement. Ce partage doit être accessible en écriture par les comptes utilisés lors des déploiements MDT. Cliquez sur “Next“.

New DB Wizard – Summary

Vérifier les réglages dans la page “Summary“, puis cliquez sur “Next” pour procéder à la création.

New DB Wizard – Confirmation

Une fois l’opération achevée, quelques secondes suffisent, cliquez sur “Finish”

3. Configuration de la base

Une fois votre base crée, l’étape suivante consiste à définir les règles de gestion MDT. Toutefois, là encore, dans un environnement de production, il faudra probablement vous assurer que les comptes de déploiement aient les droits de lecture sur la base de données.

a. Vérifier les autorisations

Grossièrement, il vous faudra ouvrir la console “SQL Server Management Studio” (Disponible si vous avez suivi mon conseil en installant la version SQL avec les outils):

SQL Server Management Studio

Puis vous connecter à l’instance en indiquant le nom du serveur et de l’instance sous la forme “ServeurMDT\SQLExpress“.

Se connecter au serveur SQL

Le choix “Authentification Windows” utilise votre identité de session principale par défaut. Dans le cas où les droits de l’utilisateur en cours seraient inadaptés à cette connexion, effectuez un “[Maj] + [Clic droit] + [Exécutez en tant qu’autre utilisateur]” sur le raccourci de la console “SQL Server Management Studio” afin de stipuler un identifiant idoine.

Créez ensuite une nouvelle “Connexion” sous “Sécurité” pour le compte utilisé lors des déploiements, tels que “Domaine\MDT-Depl” que vous aurez créé préalablement dans le domaine puis ajoutez-lui les autorisations de lecture “db_datareader” sur la base MDT. Si cette action est un peu obscure pour les néophytes SQL comme moi, voici les écrans concernés:

MDT DB – Nouvelle connexion

MDT DB – db_reader

Cliquez sur “OK” pour valider ces réglages, puis fermez la console “SQL Server Management Studio“.

Note : N’oubliez pas de vérifier que le port d’accès SQL (UDP 1434 par défaut) est bien ouvert sur le pare-feu du serveur. Dans le cas contraire, les clients LiteTouch seront dans l’impossibilité de contacter la base durant les phases de déploiement.

b . Définir les règles de gestion

Pour cela, ouvrez la console “Deployment Workbench” puis développez l’arborescence afin de sélectionner  “MDT Deploymentshare … Advanced Configuration … Database” puis faites un clic droit (menu contextuel) sur ce dernier élément pour choisir “Configure Database Rules“.

MDT – Configure Database Rules

L’assistant de configuration des règles va s’afficher afin de vous proposer différentes famille d’options (variables) exploitables par les requêtes MDT durant les phases de déploiement. Cependant, au moins pour les besoins de cette démonstration, il souhaitable de ne pas conserver les choix par défaut, du fait qu’ils soient tous sélectionnés, cela risque de polluer votre configuration de manière significative. Je vous propose donc les choix suivants :

• Page “Computer Options“

Configure DB Wizard – Computer Options

Conservez les 3 premières cases cochées puis cliquez sur “Next”

• Page “Location Options”

Configure DB Wizard – Location Options

Cliquez sur “Deselect All” puis cliquez sur “Next“,

• Page “Make/Model Options“

Configure DB Wizard – Make/Model Options

Cliquez sur “Deselect All” puis cliquez sur “Next“,

• Page “Role Options“

Configure DB Wizard – Role Options

Conservez les 2 premières cases cochées puis cliquez sur “Next”

• Page “Summary“

Configure DB Wizard – Summary

Vérifiez les réglages dans la page “Summary” puis cliquez sur “Next“.

• Page “Confirmation“

Configure DB Wizard – Confirmation

Cliquez sur “Finish” une fois l’opération achevée

Voilà, à ce stade, la base de données MDT est prête. Vous pouvez éventuellement vérifier le contenu de votre fichier de configuration “%DeployRoot%]\Control\CustomSettings.ini” qui devrait contenir approximativement ceci :

[Settings] 
Priority=CSettings, CApps, CRoles, RSettings, RApps, Default

Ainsi que des sections [ ] pour chacune de ces combinaisons.

C. Configuration des rôles

Pour rappel, je considère que vous avez préalablement configuré quelques bundles sous la rubrique “Applications” et que vous disposez également de quelques images de référence sous “Operating System“.

Dans cette démonstration, j’ai par exemple configuré 5 bundles contenant respectivement

Toujours dans cet exemple, nous disposons des images de référence affectées aux séquences de taches suivantes :

Pour configurer les rôles, ouvrez la console “Deployment Workbench” puis développez l’arborescence afin de sélectionner  “MDT Deploymentshare … Advanced Configuration … Database … Roles” puis faites un clic droit (menu contextuel) sur ce dernier élément pour choisir “New“.

MDT DB – New Role

Sous l’onglet “Identity” entrez un nom décrivant ce rôle, comme par exemple “Poste Fixe Standard“.

Propriétés d’un Role – Identity

Sous l’onglet “Details“, dans le tableau de variables, sous la section (bleutée) “Miscellaneous“, renseignez la propriété “TaskSequenceID” avec la valeur correspondante à l’identifiant de la séquence de tache que vous souhaitez affecter à ce rôle, comme par exemple “DEPL-W7X64“. Autrement dit, quelle image de système, et éventuelle personnalisation, vous souhaitez lui associer.

Propriétés d’un Role – Details

Facultatif : Je vous en ai déjà parlé lors de la configuration de MDT et du fait que la granularité d’une base de données l’autorise, je vous conseille de modifier également la propriété “_SMSTSORGNAME” en indiquant une description succincte de la séquence de tache ou du rôle. Ce champ, habituellement prévu pour indiquer un titre personnalisé dans le bandeau du client LiteTouch (Par défaut “IT Organisation”), permettra de repérer facilement une tache de déploiement en cours sur un ordinateur.

Vous pouvez également ajouter les préférences de fuseau horaire en indiquant les propriétés suivantes dans la section “Regional and Locale Settings“:

• TimeZone = 105
• TimeZoneName = Romance Standard Time

Enfin, sous l’onglet “Applications“, cliquez sur le bouton “Add“…”LiteTouch Appplication“, puis sélectionnez le(s) bundle(s) de votre choix,  comme par exemple “Pack Addons” + “Pack Composants” + “Pack Bureautique 2010 Standard”

Propriétés d’un Role – Applications

Cliquez sur “OK” pour créer ce nouveau rôle.

Réitérer cette opération de création de rôle pour les différentes combinaisons que vous souhaitez déployer.

D. Affectation d’un rôle

Une fois les différents rôles créés, il ne vous reste plus qu’à les associer aux différents ordinateurs de votre parc informatique. Ces derniers sont normalement définis dans la rubrique (table) “Computers“, sous réserve d’avoir importé préalablement les informations nécessaires, comme par exemple le nom d’ordinateur “OSDComputerName” ainsi qu’un identifiant tel que “MAC Address“.

Pour la démonstration, créez une machine virtuelle connectée au réseau du serveur MDT, puis notez son adresse MAC.

• Avec Virtualbox, ouvrez la fenêtre “Paramètres” de la VM, puis sélectionnez “Réseau” et développer l’option “Avancé“. Le champ “Adresse MAC” y est indiqué.

• Avec Vmware Workstation, sélectionnez les paramètres “Hardware” de la VM, puis la rubrique “Network Adapter” et cliquez sur le bouton “Avancé”. Pour une nouvelle VM, vous devrez cliquer sur le bouton “Generate“

• Sous Hyper-V v3, cette information n’est pas disponible dans l’interface graphique. Démarrez puis arrêtez immédiatement cette VM afin de générer l’adresse MAC. Ouvrez une invite Powershell, puis entrez la commande suivante :

Get-VM | Get-VMNetworkAdapter | FT VMName, MACAddress

Pensez également à copiez et affecter l’image “LiteTouchPE_x64.iso” dans le lecteur de CD/DVD de cet ordinateur virtuel.

Dans la console “Deployment Workbench”, sélectionnez  “MDT Deploymentshare … Advanced Configuration … Database … Computers” puis faites un clic droit (menu contextuel) sur ce dernier élément pour choisir “New“.

Sous l’onglet “Identity“, entrez l’adresse MAC précédemment mentionnée. Personnellement, j’ai également pris pour habitude de copier la valeur de “OSDComputerName” dans le champ “Description“. Ce n’est pas impératif, mais cela permet d’afficher directement les noms d’ordinateurs dans le volet détail de la console MDT et ainsi éviter une recherche dans l’onglet “Details” de chaque entrée.

Propriétés d’un ordinateur MDT – Identity

Sous l’onglet “Details“, dans le tableau de variables, sous la section (bleutée) “Identification“, renseignez la propriété “OSDComputerName” avec le nom que vous souhaitez affecter à cet ordinateur, comme par exemple “Test-MDT“.

Propriétés d’un ordinateur MDT – Details

Vous pouvez également stipuler d’autres variables, telles que le domaine à joindre, l’unité d’organisation, ou les définir dans un rôle si ces valeurs sont communes à un ensemble d’ordinateurs et pas uniquement à celui-ci.

Enfin, sous l’onglet “Roles“, sélectionnez le(s) rôle(s) désirés puis cliquez sur “OK“, afin de créer cette nouvelle entrée.

Propriétés d’un ordinateur MDT – Ajout d’un Role

A présent, vous pouvez effectuer le test fonctionnel, en démarrant votre machine virtuelle :

Note : Cette démonstration n’évoque pas l’identification automatique (bootstrap.ini) ni le masquage des différents écrans d’installation traités dans le tutoriel de “Configuration avancée du MDT“. Il vous sera donc nécessaire de valider les différents écrans en appuyant uniquement sur le bouton “Next” de l’assistant LiteTouch.

Exemple de résultat :

MDT – Déploiement en cours

Si vous avez besoin de peupler en masse la liste des ordinateurs et adresse MAC à partir d’un inventaire, je vous conseille d’utiliser le module Powershell MDTDB que vous trouverez ici. (Une fois les fichiers extraits de l’archive MDTDB.zip, n’oubliez pas de les débloquer)–

Si vous souhaitez une gestion simplifiée de ces affectations sans passer par un poste disposant de la console MDT, je vous conseille d’essayer l’outil gratuit “MDT Administrator” que vous trouverez ici.

Enfin, j’ajouterais probablement quelques autres techniques et scripts du même genre au sein d’un article dédié sur ce sujet, afin de simplifier la gestion d’une base de données MDT.

Voilà, j’ai terminé ce tutoriel (dont j’avais sous-estimé l’ampleur). Désolé pour les coupes-franches que j’ai dû concéder, sur certains points de détails. J’espère toutefois que vous y trouverez des informations utiles.

V. Annexes

A. Fichiers de configuration

Pour information, voici les fichiers utilisés dans cette maquette :

“bootstrap.ini”

[Settings] 
 Priority=Default

[Default] 
 DeployRoot=\\WDS-MDT\DeploymentShare 
 SkipBDDWelcome=YES 
 UserID=MDT-Depl 
 UserDomain=LABO 
 UserPassword=Pa$$w0rd 
 KeyboardLocalePE=040c:0000040c

“CustomSettings.ini”

[Settings]
Priority=CSettings, CApps, CRoles, RSettings, RApps, Default
Properties=MyCustomProperty

[Default]
OSInstall=Y
SkipCapture=NO
SkipAdminPassword=YES
SkipProductKey=YES
SkipComputerBackup=NO
SkipBitLocker=NO
EventService=http://WDS-MDT:9800

[CSettings]
SQLServer=WDS-MDT
Instance=SQLExpress
Database=MDT
Netlib=DBNMPNTW
Table=ComputerSettings
Parameters=UUID, AssetTag, SerialNumber, MacAddress
ParameterCondition=OR

[CApps]
SQLServer=WDS-MDT
Instance=SQLExpress
Database=MDT
Netlib=DBNMPNTW
Table=ComputerApplications
Parameters=UUID, AssetTag, SerialNumber, MacAddress
ParameterCondition=OR
Order=Sequence

[CRoles]
SQLServer=WDS-MDT
Instance=SQLExpress
Database=MDT
Netlib=DBNMPNTW
Table=ComputerRoles
Parameters=UUID, AssetTag, SerialNumber, MacAddress
ParameterCondition=OR

[RSettings]
SQLServer=WDS-MDT
Instance=SQLExpress
Database=MDT
Netlib=DBNMPNTW
Table=RoleSettings
Parameters=Role

[RApps]
SQLServer=WDS-MDT
Instance=SQLExpress
Database=MDT
Netlib=DBNMPNTW
Table=RoleApplications
Parameters=Role
Order=Sequence

B. Réglages avancés relatifs à SQL

Au sein du fichier de configuration “CustomSettings.ini” vous pouvez remarquer des réglages spécifiques à l’usage d’une base SQL. Ces propriétés sont principalement positionnées par l’assistant de création de la base de données MDT, mais certains d’entre eux doivent être renseignés manuellement.

Cas concret

Nous avons vu qu’il était possible de définir l’ordre des applications au sein des bundles, mais dans certains cas de figure, il peut s’avérer nécessaire de corriger le séquencement des bundles eux-mêmes.

Exemple d’une section [RApps] utilisant dynamiquement les tables SQL afin de corriger le séquencement d’installation des bundles

[RApps]
SQLServer=WDS-MDT.labo.local
Instance= SQLExpress
Database=MDT-PROD
Port=8415
Netlib=DBMSSOCN
Table=dbo.Settings_Applications AS sp INNER JOIN dbo.RoleIdentity AS ri ON sp.ID = ri.ID INNER JOIN dbo.Settings_Roles AS sr ON sr.Role = ri.Role INNER JOIN dbo.computerRoles AS cr ON ri.Role = cr.Role and sr.ID = cr.ID
Parameters=UUID, AssetTag, SerialNumber, MacAddress
ParameterCondition=OR
Order=sr.Sequence, sp.Sequence
DBID=MDTTS
DBPWD=Pa$$w0rd

Autres références :

– Working with the MDT Database

– Implementing Deployment Role Selection in MDT 2012

I. Présentation

Tout comme n’importe quel technicien Windows, vous êtes surement confronté régulièrement au besoin d’une réinstallation complète à partir un système pourtant opérationnel. Avec MDT, c’est plutôt simple et cela passe par les scénarios de déploiement LiteTouch de type “NEW-COMPUTER”. Toutefois, pour passer par ces étapes, il est nécessaire de redémarrer l’ordinateur concerné à partir d’un média contenant le client LiteTouch.

Imaginons donc que la machine concernée est contrôlée à distance et que pour couronner le tout vous ne bénéficiez pas d’un environnement compatible PXE. Je considère que vous n’avez pas non plus de solution telles que Landesk, ni SCCM. Le poste est donc physiquement inaccessible, et il n’y a aucune “petite main” sur les lieux pour insérer une clé USB, ou autre CD/DVD…

La 1ère solution à laquelle on pourrait penser serait de faire pointer un raccourci vers le script “\\MDTServer\DeploymentShare\Scripts\litetouch.vbs” en ajoutant le commutateur “/deploymenttype:NEWCOMPUTER” –> Ça commence bien et puis ça plante au moment où la séquence tente de générer les partitions : eh oui, c’est logique puisque le disque concerné est en cours d’utilisation, c’est ballot …

Dans de cas de figure, il m’a semblé alors pertinent d’envisager une méthode consistant à redémarrer le poste à partir d’une image WinPE LiteTouch, préalablement copiée sur un des disques locaux, puis modifier la séquence d’amorçage locale avec de charger ce noyau.

II. Détail de la solution proposée

La procédure que je vous propose consiste donc à créer un fichier batch chargé de copier l’une des images WinPE LiteTouch normalement située dans le dossier “\Deploymentshare\Boot” de la structure MDT et configurer un double-amorçage sur la machine concernée.

Créez par exemple, sur la racine de la structure MDT, un fichier “SelfRecover.bat” dans lequel nous allons copier le contenu ci-après.

Vous pouvez indifféremment choisir l’image 32 ou 64 bits en modifiant la variable “ArchiPE“. Pensez à vérifier que les fichiers “LiteTouchePE*.wim” et “boot.sdi” soient bien présents sur la ressource partagée MDT. Dans le doute, utilisez préalablement le menu “Update Deployment Share” pour régénérer les images à partir de la console MDT.

@echo off
cd /d %SystemDrive%\
echo ---- Verification du niveau de privileges
whoami /groups | findstr "S-1-16-12288" > nul && set runLevel=admin
if not "%runLevel%"=="admin" goto notAdmin

cls
echo Attention, la reinstallation complete du poste est imminente !...
echo Toutes les donnees non sauvegardees seront perdues.
echo Appuyez sur [Ctrl]+[C] pour stopper ce processus ou
pause
set RecoverPath=LocalRecover
set ShareMDT=\\WDS-MDT\DeploymentShare$
set ArchiPE=x86
rem set ArchiPE=x64
net use %ShareMDT%
if not errorlevel 0 goto notAdmin

echo ---- copie du noyau WinPE %ArchiPE% vers le disque local
mkdir %SystemDrive%\%RecoverPath%
copy %ShareMDT%\Boot\LiteTouchPE_%ArchiPE%.wim %SystemDrive%\%RecoverPath%\Boot.wim
copy %ShareMDT%\Boot\%ArchiPE%\Boot\boot.sdi %SystemDrive%\%RecoverPath%\boot.sdi

echo ---- modification de la sequence d'amorcage locale
bcdedit /create {ramdiskoptions} /d "Reinstallation du systeme"
bcdedit /set {ramdiskoptions} ramdisksdidevice partition=%SystemDrive%
bcdedit /set {ramdiskoptions} ramdisksdipath \%RecoverPath%\boot.sdi

for /f "tokens=2" %%i in ('bcdedit /create /d "Reinstallation du systeme" /application OSLOADER') do set NewGUID=%%i
echo Le nouveau GUID est %NewGUID%
if errorlevel 1 goto erreur

bcdedit /set %NewGUID% device ramdisk=[%SystemDrive%]\%RecoverPath%\boot.wim,{ramdiskoptions}
bcdedit /set %NewGUID% osdevice ramdisk=[%SystemDrive%]\%RecoverPath%\boot.wim,{ramdiskoptions}
bcdedit /set %NewGUID% systemroot \windows
bcdedit /set %NewGUID% winpe yes
bcdedit /set %NewGUID% detecthal yes
bcdedit /displayorder %NewGUID% /addlast
bcdedit /default %NewGUID%
bcdedit /timeout 5
if errorlevel 0 goto suite

:erreur
Echo une erreur est survenue - procedure abandonnee.
pause
goto fin

:notAdmin
echo Privileges insuffisants : Ce script doit etre execute en tant qu'Administrateur et la ressource MDT partagee doit etre accessible.
pause
goto fin

:suite
echo Le système va redemarrer dans 30 secondes
shutdown -r -f -t 30

:fin

Attention, notez que ce script de configuration de l’amorçage requiert les privilèges d’administrateur (test réalisé via la commande “whoami“) et que la ressource partagée MDT doit être accessible.

Au prochain redémarrage, l’utilisateur aura encore la possibilité de démarrer son système, durant 5 secondes : Sauf si vous exécutez cette opération à distance et qu’il n’y a personne devant l’ordinateur en question pour modifier cette action

Réinstallation du système proposée au redémarrage

Après, il faudra bien sûr que la séquence d’installation soit automatisée, et sans intervention requise. Sinon, prévoyez d’ajouter un contrôle à distance dans votre client LiteTouch. Au besoin, vous pouvez consulter mon article sur “Installer UltraVNC dans WinPE” 

I. Présentation

Ce petit tutoriel est destiné à vous expliquer comment installer un outil de prise de main à distance sur le système de déploiement WinPE. L’idée première de cet article est de proposer une alternative à l’outillage DaRT (Diagnosis And Repair Toolkit) fournit aux clients ayant souscrit le contrat Software Assurance MDOP (Microsoft Desktop Optimisation Pack). L’intégration d’une solution de prise de main à distance permet de surveiller le déploiement sur les différents postes de votre entreprise. Notez que l’outil DaRT précité, s’intègre facilement dans le MDT (Microsoft Deployment Toolkit)

Rappel : Le système de déploiement WinPE est minimaliste et ne supporte pas le mode WoW (Windows On Windows, et non World of Warcraft  ) contrairement aux systèmes d’exploitation dont il partage le noyau. Autrement dit, les outils que vous seriez amené à utiliser dans un environnement WinPE doivent impérativement correspondent à l’architecture retenue. Il va sans dire que les outils 32 bits sont plus répandus que leurs homologues 64 bits.

II. L’outil de prise de main à distance

Il existe de nombreux outils dans ce domaine, mais j’ai opté pour UltraVNC en raison de sa gratuité et sa disponibilité dans les 2 architectures 32 et 64 bits. (Vous pouvez télécharger les sources ici

A. Extraire les fichiers UltraVNC

Après avoir téléchargé les sources désirées, procédez à l’extraction du package .msi via la commande suivante :

msiexec /a D:\Downloads\UltraVnc_1205_X64.msi /qb TARGETDIR=D:\CustPE\UltraVNC\UltraVnc_1205_X64

Note : L’option “/a” permet de réaliser une installation dite “administrative”. C’est-à-dire d’extraire le contenu sur une ressource locale ou réseau, sans installer le produit. L’option “/qb” effectue l’opération avec l’interface graphique de base sans intervention de l’utilisateur (“quiet modes”) – Utilisez “msiexec /?” pour obtenir plus d’informations sur les commutateurs de la commande et au besoin sur mon article relatif à la “gestion des applications“

A l’issue de cette commande vous devriez obtenir un ensemble de fichiers dans le dossier cible (que vous devrez créer préalablement à l’exécution de la commande précitée) – Les fichiers utiles pour cette démonstration sont winvnc.exe et vnchooks.dll. L’exécutable vncviewer nous servira pour réaliser la connexion à distance.

Pour faire court, nous allons simplement générer via le bloc-notes un fichier d’initialisation (nouveau) nommé “UltraVNC.ini” avec le contenu suivant:

[Permissions]
[admin]
AuthRequired=0
HTTPConnect=0
[ultravnc]
[poll]
TurboMode=1
PollUnderCursor=0
PollForeground=1
PollFullScreen=0
OnlyPollConsole=0
OnlyPollOnEvent=1
MaxCpu=40
EnableDriver=0
EnableHook=1
EnableVirtual=0
SingleWindow=0
SingleWindowName=

Ce fichier d’exemple décrit une configuration minimaliste mais suffisante pour notre besoin. Notez toutefois, que cette méthode (AuthRequired=0) n’utilisera aucun mot de passe pour la connexion vers le poste sous WinPE. Si vous souhaitez ajouter des mots de passe pour la connexion et/ou la visualisation, il faudra les générer préalablement en exécutant une fois le programme sur un poste. En effet, les mots de passe sont encodés dans le fichier “UltraVNC.ini” et l’outil ne propose pas de méthode native pour les générer préalablement.

Note : La directive “SingleWindowName=” vide est “normale”. Je n’ai pas essayé de la supprimer car de nombreux exemples du site ultravnc, la contienne… et la documentation http://www.uvnc.com/docs/uvnc-server/69-Ultra%20VNCini.html indique ” Current not used”.

B. Personnalisation du noyau WinPE

Pour rappel, les images d’amorçage WinPE sont disponibles sur les sources ISO ou DVD des systèmes d’exploitation depuis Vista, ou sur le kit de déploiement Windows ADK (Assesment and Deployment Kit) – anciennement connu sous le nom WAIK pour Windows Automated Installation Kit. Ces kits sont d’ailleurs des prérequis à l’utilisation de l’atelier de déploiement (Deployment Workbench) du MDT.

Pour simplifier cet article, nous considérons que vous avez installé l’un de ces kit ainsi que le MDT 2010, 2012 ou 2013 sur un poste de travail (ou un serveur d’atelier technique). Les sources de WinPE (alias client LiteTouch) sont disponibles dans le dossier “Boot” du partage MDT, nommé par défaut “DeploymentShare”.

Note : Pour ceux qui débuteraient avec MDT, sans avoir consulter mes tutoriels précédents :-(, sachez qu’ il n’y a rien dans ce dossier tant que vous n’en avez pas lancé la fabrication. Pour y remédier, démarrez la console “Deployment Workbench“, sélectionnez le nom de votre MDT situé sous la rubrique “Deployement Shares” puis utilisez le choix “Update Deployment Share” via le menu contextuel. Dans l’assistant, cochez éventuellement l’option “Completly regenerate the boot images“

Mise à jour et génération des clients LiteTouch

Cliquez 2 fois sur “Next” puis “Finish” (après quelques minutes d’attente…)

C. Modification de l’image WinPE

Là encore, il y a les débutants et les autres… Donc en quelques mots, un noyau WinPE est une image .WIM (plus exactement “\Sources\boot.wim” par défaut) dont le contenu peut être modifié en réalisant préalablement un “montage” vers un dossier vide. Nous allons réaliser cette opération de montage via l’outil DISM présent par défaut depuis Windows 7. Pour les plus allergiques à la ligne de commande, vous pouvez également recourir à l’excellent freeware “GImageX” qui vous pouvez télécharger ici.

Note : N’oubliez pas d’exécuter votre invite de commande ou console Powershell en tant qu’Administrateur.

Nous allons donc préparer une petite structure de travail, puis procéder à la modification du noyau d’un client LiteTouch en procédant comme suit (adaptez les chemins en fonction de votre environnement) :

md D:\CustPE\Mount

md D:\CustPE\Sources

copy \\localhost\DeploymentShare\Boot\LiteTouchPE_x64.wim D:\CustPE\Sources

dism /mount-wim /wimfile:D:\CustPE\Sources\LiteTouchPE_x64.wim /index:1 /mountdir:D:\CustPE\Mount

Résultat affiché :

Outil Gestion et maintenance des images de déploiement
Version : 6.3.9600.17031

Montage de l'image
[==========================100.0%==========================]
L'opération a réussi.

Une fois l’image “montée”, procédez à la copie des 2 binaires “winvnc.exe” et “vnchooks.dll” parmi les sources récupérées ainsi qu’au transfert du fichier “UltraVNC.ini” construit précédemment.

copy D:\CustPE\UltraVNC\UltraVnc_1205_X64\winvnc.exe D:\CustPE\Mount\Windows\System32

copy D:\CustPE\UltraVNC\UltraVnc_1205_X64\vnchooks.dll D:\CustPE\Mount\Windows\System32

copy D:\CustPE\UltraVNC\UltraVnc_1205_X64\ultraVNC.ini D:\CustPE\Mount\Windows\System32

Il existe plusieurs points d’entrée pour déclencher des actions automatiques sous WinPE ou pour un client LiteTouch. Au besoin, reportez-vous à mon article sur le sujet ici (“Présentation-de-WinPE“) . Pour cette démonstration, j’ai retenu la méthode consistant à modifier le fichier “unattend.xml” situé à la racine du noyau, soit “boot.wim“.

Note : Contrairement à un noyau WinPE générique, sur un client LiteTouch le fichier “unattend.xml” existe déjà. Si vous souhaitez exploiter cette fonctionnalité d’accès à distance sur un noyau générique, il faudra vous assurer que le processus d’initialisation interprète le contenu du ce fichier “unattend.xml” en exécutant la commande “wpeinit“.

Les commandes, relativement simples, dont nous avons besoin pourraient être exécutées via l’invite de commande mais l’usage d’un petit script vbs me paressait plus élégant. Je vous propose donc de créer un nouveau fichier de script comme suit :

Notepad D:\CustPE\Mount\LaunchVNC.vbs

Recopiez le contenu suivant :

Set oShell = CreateObject("Wscript.Shell")
oShell.Popup "Demonstration d'usage de VNC sous WinPE",3

' Demarrage de l'agent de service UltraVNC
oShell.Run("X:\windows\system32\winvnc.exe"),0,False

' Desactivation du pare-feu WINPE
oShell.Run("wpeutil disablefirewall"),0,True

' Message facultatif
Set oWMIService = GetObject("winmgmts:\\.")
Set oWMIAdapters = oWMIService.ExecQuery ("Select IPAddress from " &_
  "Win32_NetworkAdapterConfiguration Where IPEnabled = True")
For Each Adapter in oWMIAdapters 
        sIPAddr = Adapter.IPAddress(0)
Next
oShell.Popup "Controle à distance disponible via UltraVNC sur l'adresse " & sIPAddr ,3

Enregistrez les modifications puis quittez le bloc-notes

Note : Ce script affiche des popups de 3 secondes afin de ne pas bloquer le processus en votre absence.

Éditez le fichier d’initialisation “unattend.xml”

Notepad D:\CustPE\Mount\unattend.xml

Et renseignez-le comme suit : (en gras les modifications apportées comparativement à l’original)

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
    <settings pass="windowsPE">
        <component name="Microsoft-Windows-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State">
            <Display>
                <ColorDepth>32</ColorDepth>
                <HorizontalResolution>1024</HorizontalResolution>
                <RefreshRate>60</RefreshRate>
                <VerticalResolution>768</VerticalResolution>
            </Display>
            <RunSynchronous>
                <RunSynchronousCommand wcm:action="add">
                    <Description>Lancement de VNC</Description>
                    <Order>1</Order>
                    <Path>wscript.exe X:\LaunchVNC.vbs</Path>
                </RunSynchronousCommand>
                <RunSynchronousCommand wcm:action="add">
                    <Description>Lite Touch PE</Description>
                    <Order>2</Order>
                    <Path>wscript.exe X:\Deploy\Scripts\LiteTouch.wsf</Path>
                </RunSynchronousCommand>
            </RunSynchronous>
        </component>
    </settings>
</unattend>

Enregistrez les modifications puis quittez le bloc-notes

Note : Si vous créez un nouveau fichier, faites bien attention à l’architecture indiquée “amd64” ou “x86“. En effet, en cas de divergence avec le noyau, l’interprétation des directives est tout bonnement ignorée.

Procédez au “démontage de l’image WIM” via la commande suivante:

dism /unmount-wim /mountdir:D:\CustPE\Mount /commit

Résultat affiché :

Outil Gestion et maintenance des images de déploiement
Version : 6.3.9600.17031

Fichier image : C:\CustPE\Sources\LiteTouchPE_x64.wim
Index de l'image : 1
Enregistrement de l'image
[==========================100.0%==========================]
Démontage de l'image
[==========================100.0%==========================]
L'opération a réussi.

III. Utilisation du noyau WinPE modifié

Pour utiliser ce noyau WinPE modifié vous devez le réintégrer dans une structure d’amorçage WDS, ISO ou un DVD. En vous reportant à mes différents tutoriels, donc celui concernant la “Dématérialisation des vos supports avec WDS“, vous devriez vous en sortir

A. Via Windows Deployment Services

Exemple : Import d’une image de démarrage sous Windows Deployment Services :

Ajout d’une image de démarrage dans WDS

B. Via un support amovible de type USB

Si vous n’avez pas d’infrastructure WDS et qu’une modeste clé USB (mini 512 Mo) sous la main, vous pouvez suivre la procédure suivante :

1. Formatage du support USB

Formatez la clé via “diskmgmt.msc” ou “diskpart” pour les plus aguerris

Diskpart

Diskpart> list Disk
Diskpart> select Disk 2
Diskpart> clean
Diskpart> create part primary
Diskpart> format fs=ntfs quick
Diskpart> active 
Diskpart> assign letter=K:
Diskpart> exit

Faites attention, ne vous trompez pas de cible ! – Lorsque vous taperez la commande “list disk“, vous obtiendrez un résultat du genre :

N° disque Statut Taille Libre Dyn GPT
--------- ------------- ------- ------- --- ---
Disque 0 En ligne 40 G octets 0 octets
Disque 1 En ligne 60 G octets 1024 K octets
Disque 2 En ligne 512 M octets 0 octets

Et il n’y guère d’information autre que la taille, pour vous permettre de localiser votre clé USB. Je vous ai bien dit que “diskpart” n’était pas pour les néophytes, donc si vous avez vraiment des doutes, utilisez la console graphique. Pour les aficionados de la ligne de commande, sachez qu’il y a toujours quelques commandes alambiquées pour identifier vos disques flash USB, comme par exemple sous Powershell :

gwmi -Class win32_logicaldisk | ? { $_.driveType -eq 2 }

ou encore

gwmi win32_diskdrive | ? {$_.interfacetype -eq "USB"}

2. Copie des fichiers d’amorçage

Copiez les fichiers d’amorçage du MDT vers cette clé (selon l’architecture).

xcopy \\localhost\DeploymentShare\Boot\x64\*.* k:\ /e /s

3. Copie du noyau modifié

Créez un dossier “\Sources” puis recopiez le noyau modifié :

md k:\Sources
copy D:\CustPE\Sources\LiteTouchPE_x64.wim k:\Sources\Boot.wim

A ce stade, votre support est prêt à l’emploi.

Note 1 : Pour la réussite de cette démonstration, vous devez disposer d’un environnement DHCP afin que le client obtienne une adresse IP valide.

Note 2 : Attention, vous perdrez ces modifications en cas de régénération des images LiteTouch (cf “Update Deployment Share“.

C. Tests du résultat

Pour faciliter l’identification des postes cibles, je vous conseille d’activer le mode “Monitoring” au sein de MDT (2012 et +). Pour cela, il suffit de démarrer la console “Deployment Workbench“, de sélectionner le nom de votre MDT situé sous la rubrique “Deployement Shares” et d’utiliser le menu contextuel “Propriétés“. Allez ensuite sous l’onglet “Monitoring” puis cochez la case “Enable monitoring for this deployement share” et cliquez sur “Appliquer” et “OK” pour valider ce changement.

Activation de la surveillance des déploiements sous MDT (Monitoring)

Démarrez votre poste de test sur l’image LiteTouch modifiée. Vous devriez voir apparaitre furtivement les messages d’information du script puis l’écran d’accueil de l’assistant LiteTouch puis les séquences de taches (Variable selon votre configuration MDT).

Exemple d’affichage  de l’assistant LiteTouch

A partir de votre machine MDT, lancez la console “Deployment Workbench” puis sélectionnez la rubrique “Monitoring” et appuyez sur [F5] afin d’actualiser l’affichage. Le(s) poste(s) en cours d’installation devrai(ent) apparaitre.

Exemple de surveillance d’un déploiement sous MDT

Maintenant, il vous suffit de démarrer le programme “vncviewer.exe” (téléchargé précédemment) puis d’entrer le nom du poste dans la zone “VNC Server”  et cliquez sur le bouton “Connect”

Connexion à distance via VNC Viewer

Patientez quelques secondes avant que la connexion soit établie.

Etat de la communication VNC

Vous pouvez alors surveiller (ou interagir en ouvrant une invite de commande via [F8] par exemple) sur le poste tant qu’il exécute le noyau WinPE, c’est-à-dire jusqu’à ce qu’il effectue son premier redémarrage. (après il sera trop tard  , à moins que vous n’ayez activé le bureau à distance ou vnc sur le poste )

Connexion à distance établie sur le client LTI via VNC

Il y existe assurément d’autres techniques pour parvenir à ce genre de résultat mais je vous assure que celle-ci est fonctionnelle et accessible à tous :-)…

Facultatif : L’un des petits défauts de cette méthode est la perte des modifications lors de la régénération des clients LiteTouch. Pour pallier cette contrainte, sur votre machine MDT, vous devrez remplacer le(s) fichier(s) de modèle de l’ADK ci-après par le fichier “unattend.xml” modifié (32 / 64 bits).

• “C:\Program Files\Microsoft Deployment Toolkit\Templates\Unattend_PE_x64.xml”
• “C:\Program Files\Microsoft Deployment Toolkit\Templates\Unattend_PE_x86.xml”

Vous trouverez des informations sur ce sujet dans le tutoriel “Maîtrise des images de démarrage LTI / WinPE“

I. Présentation

Comme évoqué dans mes précédents tutoriels, la console MDT permet d’ajouter un dossier au sein des images WinPE personnalisées. Rappelez-vous, sous l’onglet “Windows PE” … “Extra directory to add“. Cette faculté est intéressante et simple à mettre en œuvre, mais risque d’alourdir le noyau (ie “Ramdrive”) dès lors que le volume de votre outillage devient significatif.

En fait, ce choix d’intégrer des outils additionnels au sein même du noyau WinPE est généralement motivé par la simplicité de “référencement” à ces programmes parce que la lettre affectée est toujours “X:”

Avant de vous lancer dans l’ajout d’un outillage complémentaire, gardez à l’esprit que les programmes doivent être autonomes – c’est à dire de simples binaires exécutables , ou ensemble de fichiers qui ne requièrent aucun processus d’installation, ni dépendance avec des composants Windows) – Depuis WinPE 4, il est toutefois possible d’ajouter une version limitée du framework .NET.

II. Comment connaitre la lettre du média WinPE ?

À mon avis, le stockage sur le média WinPE, est plus intéressant, surtout dans le cas d’outils volumineux ou utilisés très ponctuellement. Cependant, la lettre du média est variable et il peut s’avérer nécessaire d’employer un script pour localiser la bonne lettre d’unité.

Exemple de batch GetPEMedia.cmd

@ECHO OFF
FOR %%i IN (C D E F G H I J K L M N O P Q R S T U V W Y Z) DO IF EXIST %%i:\SOURCES\Boot.wim SET MEDIAPE=%%i:
ECHO MediaPE = %MEDIAPE%

Exemple de script GetPEMedia.vbs

Set objFSO = CreateObject("Scripting.FileSystemObject")
Set colDrives = objFSO.Drives
sFile = "\Sources\boot.wim"
bFound = False
For Each objDrive in colDrives
    sFind = objDrive.DriveLetter & ":" & sFile
    If objFSO.FileExists(sFind) Then
       bFound = True
       Wscript.Echo "Le fichier " & sFile & " a été trouvé sur le lecteur " & objDrive.DriveLetter & ":"
    End If
Next

If bFound = False Then Wscript.Echo "Le fichier " & sFile & " n'a été trouvé sur aucun lecteur."

Exemple de script GetPEMedia.ps1

$File = "\Sources\boot.wim" 
$Found = $False
$Drives = Get-WmiObject -Query "SELECT * from win32_logicaldisk"
ForEach ($Drive in $Drives) {
 if (Test-Path ("$($Drive.DeviceID)$Root$File")) { 
 $Found = $True
 Echo "Le fichier [$File] a été trouvé sur le lecteur $($Drive.DeviceID)"
 }
}
if ($Found -eq $False) { Echo "Le fichier [$File] n'a été trouvé sur aucun lecteur." }

Cette technique n’est toutefois valable que lorsque l’image du noyau WinPE est chargée à partir d’un support amovible. En effet, dès lors que l’on utilise un démarrage PXE, le média n’existe plus en tant que tel. Dans ce cas, bien que le réseau ait servi de support d’amorçage, il n’y a aucun lecteur réseau au sens propre.

III. Constitution de notre boite à outils

A. Avant-propos

Avant de m’engager sur un terrain pour le moins délicat, je rappelle que l’usage de programme au sein de Windows PE est régi par le respect d’un cadre technique, mais aussi légal. C’est ce qu’on désigne par le “contrat de licence d’utilisateur final”, propre à chaque produit composant la solution.

Note : Pour respecter le cadre d’utilisation de WinPE qui n’inclut aucune licence au sens “utilisateur” et les contraintes légales d’utilisation des logiciels, je vous conseille de rester “sage” et de rester dans les limites des outils liés diagnostics, de réparation ou de déploiement d’un système.

Pour information, dans le cadre d’une souscription à un contrat “Software Assurance” ou “MSDN“, vous pouvez prétendre au “Microsoft Desktop Optimization Pack“, incluant le “Microsoft Diagnostics and Recovery Toolset“. Ce produit particulier consiste à inclure une véritable boite à outils techniques construite à partir d’un socle WinPE.

Le résultat s’inscrit dans un écran “WinRE” sensiblement modifié, incluant un nouveau lien vers la boite à outils de Microsoft.

Ce qui donnera pour Windows 7 :

Exemple avec MsDaRT 7

Et si on rentre à l’intérieur, on obtient :

Aperçu de la boite à outils “MsDaRT Tools” (W7)

…Et pour Windows 8 :

Exemple avec MsDaRT 8

De la même manière, si l’on regarde ce qui se trouve à l’intérieur :

Aperçu de la boite à outils “MsDaRT Tools” (W8.1)

Je limiterais donc ma démonstration à quelques propositions, mais je ne vous encourage aucunement à en faire l’usage dans un cadre professionnel. Pour la forme, et lever toute ambiguïté,  j’ajouterais donc la formule bateau “je décline toute responsabilité sur les conséquences d’usage et d’application de ces informations, livrées à titre purement indicatif.”

Vous pouvez également consulter cet excellent article d’Alex Dujakovic sur l’implémentation d’un outillage graphique sur un noyau WinPE 5. Pour constituer votre boite à outils, dont le choix et la pertinence vous incombent, vous pouvez consulter des sites spécialisés tels que :

• http://www.portablefreeware.com/
• http://windowsmatters.com/tag/winpe/
• http://www.snapfiles.com/features/ed_usb_software.html
• http://www.pendriveapps.com/

Toutefois, vous remarquerez certainement que les outils libres et gratuits en version 64 bits sont beaucoup moins nombreux que leurs homologues 32 bits. À titre d’exemple, je vous propose un petit tableau d’équivalence approximative susceptible de constituer votre propre boite à outils.

IV. Mise en pratique

Pour réaliser cette personnalisation, il nous faut récupérer un noyau WinPE (~boot.wim) à modifier. Pour cela, nous avons de nombreuses possibilités, telles que :

• Récupérer un noyau existant à partir d’un DVD original de distribution Windows NT6.x (*)
• Générer une image de démarrage MDT, noyau générique ou client LiteTouch
• Générer un nouveau noyau à partir du kit ADK (ou WAIK)

(*) Les noyaux présents sur les DVD contiennent 2 images, la première étant générique ” Microsoft Windows PE (x64|x86)”et la seconde, plus riche, contenant les programmes d’installation ” Microsoft Windows Setup (x64|x86)”

En fonction de vos objectifs, les opérations devront être déclinées sur chacun des noyaux 32 et/ou 64 bits.

À la lecture de mes différents articles sur le sujet, vous aurez certainement compris que je fais manifestement partie des inconditionnels de MDT. Donc plutôt que de tout fabriquer via la ligne de commande d’un ADK , je vous propose donc construire cet atelier à partir des images génériques que nous avons déjà évoquées précédemment.

A. Constituer la boite à outils

Pour la démonstration, je vais donc m’inspirer partiellement de la solution proposée par “Terabyte” expliqué ici  et qui contient un lanceur graphique de programmes “TBLaunch“, ainsi que plusieurs petites fonctions très pratiques, que nous détaillerons plus tard.

– Commençons par télécharger ce kit ici

– Ajoutons l’explorateur de fichier “Explorer++” dont vous trouverez les sources 32 et 64 bits ici

– Ajoutons l’outil “NTPWEdit” pour la réactivation des comptes locaux et réinitialisation des mots de passe dont vous trouverez les sources 32 et 64 bits ici

– Ajoutons l’outil “PE Network” pour la gestion du réseau dont vous trouverez les sources 32 et 64 bits ici : Ces packages sont au format .7z – Au besoin téléchargez également l’excellent outil gratuit “7-Zip”

Note : J’ai remarqué que l’outil “PE Network” à une forte dépendance avec l’initialisation des couches réseaux via wpeinit et ne fonctionne donc pas avec un client Litetouch, qui exploite un processus alternatif “bbdrun /bootstrap“

N’oubliez pas de “débloquer” les fichiers provenant de sources téléchargées à partir d’Internet.

B. Ventilation de l’outillage

Pour ne pas trop surcharger la liste déjà conséquente des explications, voici la structure dans laquelle j’ai ventilé les différents outils. La structure distingue volontairement les outils à intégrer dans le noyau de ceux destinés à rester sur le média. Toutefois, en raison de la taille relativement faible de ces outils, j’ai opté pour l’intégration totale dans le noyau.

Structure de travail :

Les fichiers en rouge dans le schéma sont à créer ou à modifier selon les explications qui vont suivre. Vous constaterez que je n’ai pas copié l’intégralité des sources et que pour certains programmes, j’ai rajouté le suffixe “*64.exe” pour distinguer les binaires 64 bits.

C. Préparation des fichiers nécessaires à la fabrication

1. Création du menu TBLaucher

En premier lieu, j’ai modifié, un peu violemment certes, le fichier “TBLauncher.ini” comme suit:

[Options]
Mode=WinPE
RunWpeinit=0
DisableFirewall=0
BackgroundInit=1
FindBootDrive=0
MaxSearchTime=8
UpdatePrograms=0

[Menu]
ItemCount=10

[Menu_Item_1]
Name=Explorer++
Path=%systemdrive%\Tools\Explorer++.exe
Path64=%systemdrive%\Tools\Explorer++64.exe

[Menu_Item_2]
Name=Show SuperHidden Files
Path=%systemdrive%\Scripts\ShowSuperHidden.vbs

[Menu_Item_3]
Name=Set French Keyboard Layout
Path=%SystemRoot%\System32\wpeutil.exe
Parameters=SetKeyboardLayout 040c:0000040c

[Menu_Item_4]
Name=Command Prompt
Path=%SystemRoot%\System32\cmd.exe

[Menu_Item_5]
Name=Powershell
Path=%SystemRoot%\System32\WindowsPowershell\v1.0\Powershell.exe

[Menu_Item_6]
Name=PE Network
Path=%systemdrive%\Tools\PENetwork.exe
Path64=%systemdrive%\Tools\PENetwork64.exe

[Menu_Item_7]
Name=Unlock Accounts
Path=%systemdrive%\Tools\ntpwedit.exe
Path64=%systemdrive%\Tools\ntpwedit64.exe

[Menu_Item_8]
Name=Regedit
Path=%systemroot%\System32\regedt32.exe

[Menu_Item_9]
Name=Notepad
Path=%SystemRoot%\System32\notepad.exe

[Menu_Item_10]
Name=Task Manager
Path=%SystemRoot%\System32\taskmgr.exe

Durant la fabrication, ce fichier sera stocké sous “[Z:\CustPE]\Kernel\Tools\TBLauncher.ini”

2. Facultatif : Script pour afficher les fichiers protégés

Cette astuce est liée à l’usage d’explorateurs graphiques tel que Explorer++, A43…, qui n’affichent pas les “fichiers et dossiers protégés du système” car ils s’appuient sur des clés de registre (“SuperHidden”) absentes du noyau WinPE.

Pour pallier cette particularité, il est possible de modifier le registre HKLM par défaut de WinPE, sous réserve d’effectuer le montage du noyau. Pour simplifier, j’ai donc ajouté le script suivant “ShowSuperHidden.vbs” qu’il suffira d’exécuter pour afficher les fichiers protégés sous WinPE.

Hidden = "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Hidden"
SHidden = "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\ShowSuperHidden"
Set oShell =  CreateObject("WScript.Shell")
oShell.RegWrite Hidden, 0, "REG_DWORD"
oShell.RegWrite SHidden, 1, "REG_DWORD"
oShell.Popup "L'affichage des fichiers protégés est maintenant activé",3,"Information",vbInformation

Durant la fabrication, ce fichier sera stocké sous “[Z:\CustPE]\Kernel\Scripts\ShowSuperHidden.vbs”

Note : Si vous suivez intégralement cette procédure, ce script n’aura pas d’utilité du fait que j’ai finalement décidé d’ajouter cette modification du registre dans le script de personnalisation du noyau.

3. Script pour la détection du média WinPE

Le batch suivant “Launcher.cmd” est destiné à déclarer les variables de l’architecture et du média WinPE et démarrer le lanceur d’application.

@ECHO OFF
IF "%PROCESSOR_ARCHITECTURE%"=="AMD64" SET CPU=64
FOR %%i IN (C D E F G H I J K L M N O P Q R S T U V W Y Z) DO IF EXIST %%i:\SOURCES\Boot.wim SET MEDIAPE=%%i:
IF "%MEDIAPE%"=="" SET MEDIAPE=PXE
ECHO MediaPE = %MEDIAPE%
%systemdrive%\Tools\TBLauncher%CPU%.exe

Dans cette démonstration, nous n’exploiterons pas le cas du démarrage de WinPE via WDS ou PXE, mais en l’absence de support amovible, la variable “MediaPE” sera positionnée sur “PXE“. (Pour éventuellement déclencher un script ou des actions spécifiques par la suite…)

Durant la fabrication, ce fichier sera stocké sous “[Z:\CustPE]\Kernel\Scripts\Launcher.cmd”

4. Choisir une image de fond (facultatif)

Vous pouvez préparer une image de fond d’écran pour WinPE. Par défaut, le MDT propose l’image située sous “C:\Program Files\Microsoft Deployment Toolkit\Samples\Background.bmp“.

Pour l’exemple, j’ai arbitrairement choisi une autre image “Wallpaper_windows_logo.bmp“, mais pour une meilleure compatibilité des différents noyaux, nous opterons pour le format bitmap moins optimisé.

Durant la fabrication, ce fichier sera stocké sous “[Z:\CustPE]\Wallpaper_windows_logo.bmp”

Note : Il peut être plus simple de remplacer le fichier d’exemple “C:\Program Files\Microsoft Deployment Toolkit\Samples\Background.bmp” par votre image préférée. Ce fichier sera automatiquement intégré dans le noyau WinPE, sous le nom “X:\Windows\System32\WinPE.bmp”.

5. Présélection des composants intégrés aux images génériques

Bien que l’on puisse effectuer ces réglages au niveau de l’interface de la console MDT, j’ai opté pour la modification du fichier “C:\Program Files\Microsoft Deployment Toolkit\Templates\Generic.xml”

<Definition>
  <WindowsPE>
	
	<!-- Settings -->
	<Version />
	<Source />
	<ScratchSpace>128</ScratchSpace>
	<ImageName />
	<ImageDescription />

	<!-- Components -->
	<Components>
      <Component>winpe-hta</Component>
      <Component>winpe-scripting</Component>
      <Component>winpe-wmi</Component>
      <Component>winpe-mdac</Component>
      <Component>winpe-netfx</Component>
      <Component>winpe-powershell</Component>
	</Components>
	
	<!-- Driver and packages -->
	<Drivers />
	<Packages />
	
	<!-- Content -->
	<Content>

	</Content>

	<!-- Exits -->
	<Exits>
	  <Exit>cscript.exe "%INSTALLDIR%\Samples\UpdateExit.vbs"</Exit>
	</Exits>
	
  </WindowsPE>
</Definition>

Remarque : Il est inutile de modifier les fichiers “Generic_*.xml” et “LiteTouch_*.xml” présents dans le dossier “Boot” du partage de déploiement. En fait, ils sont construits à partir des modèles et des réglages effectués dans la console MDT.

6. Préparation du lanceur d’application

Pour exécuter automatiquement le lanceur d’application aussitôt après du chargement du noyau, il nous faut créer un fichier “winpeshl.ini“, comme suit :

[LaunchApps]
%SYSTEMDRIVE%\Scripts\Launcher.cmd

Durant la fabrication, ce fichier sera stocké sous “[Z:\CustPE]\winpeshl.ini”

D. Les phases de fabrication

La préparation est pratiquement terminée et il ne nous reste plus qu’à assembler tout cela. Il existe plusieurs moyens pour y parvenir, dont l’usage du kit ADK (ou WAIK) en ligne de commande, mais je souhaitais profiter de cette occasion pour aborder un aspect méconnu du MDT. Personnellement, je suis régulièrement surpris par les possibilités de cet outil, et la suite peut s’avérer intéressante pour répondre à certains besoins de personnalisation supplémentaires.

1. Explications

En regardant de plus près les modèles de fabrication des images de démarrage MDT, LiteTouchPE.xml et Generic.xml que nous avons déjà évoqués, vous avez pu relever la présence d’une portion dédiée à la finalisation des traitements, qui doit ressembler à ceci :

<!-- Exits --> 
<Exits> 
 <Exit>cscript.exe "%INSTALLDIR%\Samples\UpdateExit.vbs"</Exit> 
</Exits>

En fait, lors de l’exécution du processus “Update Deployment Share“, ce script de sortie “UpdateExit.vbs” est appelé plusieurs fois durant les différentes phases du processus de fabrication, et permet ainsi d’ajouter librement des actions de personnalisation.

Contenu du script d’exemple par défaut :

' // ***************************************************************************
' // 
' // Copyright (c) Microsoft Corporation.  All rights reserved.
' // 
' // Microsoft Deployment Toolkit Solution Accelerator
' //
' // File:      UpdateExit.vbs
' // 
' // Version:   <VERSION>
' // 
' // Purpose:   Sample "Update Deployment Share" exit script
' // 
' // ***************************************************************************


Option Explicit

Dim oShell, oEnv


' Write out each of the passed-in environment variable values

Set oShell = CreateObject("WScript.Shell")
Set oEnv = oShell.Environment("PROCESS")

WScript.Echo "INSTALLDIR = " & oEnv("INSTALLDIR")
WScript.Echo "DEPLOYROOT = " & oEnv("DEPLOYROOT")
WScript.Echo "PLATFORM = " & oEnv("PLATFORM")
WScript.Echo "ARCHITECTURE = " & oEnv("ARCHITECTURE")
WScript.Echo "TEMPLATE = " & oEnv("TEMPLATE")
WScript.Echo "STAGE = " & oEnv("STAGE")
WScript.Echo "CONTENT = " & oEnv("CONTENT")


' Do any desired WIM customizations (right before the WIM changes are committed)

If oEnv("STAGE") = "WIM" then

    ' CONTENT environment variable contains the path to the mounted WIM

End if


' Do any desired ISO customizations (right before a new ISO is captured)

If oEnv("STAGE") = "ISO" then

    ' CONTENT environment variable contains the path to the directory that
    ' will be used to create the ISO.

End if


' Do any steps needed after the ISO has been generated

If oEnv("STAGE") = "POSTISO" then

    ' CONTENT environment variable contains the path to the locally-captured
        ' ISO file (after it has been copied to the network).

End if

Attardons-nous maintenant sur les variables positionnées durant ce processus et sur l’intérêt de ce script particulier.

On peut distinguer 3 phases durant lesquelles la variable “STAGE” prendra les valeurs suivantes :

• “WIM” . Durant cette phase, l’image WIM est montée et personnalisée, mais les modifications ne sont pas encore appliquées (commit). À ce stade, vous pouvez manipuler librement le contenu du noyau comme par exemple, copier des fichiers, créer des dossiers, monter/modifier le registre, et tout ce que vous voulez.

• “ISO” . Cette phase se manifeste juste avant l’opération de création de l’image ISO. Cela permet typiquement d’ajouter des fichiers sur le média et non dans le noyau, mais vous pouvez également en profiter pour copier l’image du noyau modifié, actuellement situé sous “oEnv(“CONTENT”) & “\Sources\Boot.wim” vers un serveur WDS par exemple.

• “POSTISO“. Cette dernière phase survient une fois que le fichier ISO a été créé et avant qu’il ne soit copié vers le partage de déploiement. Vous pouvez par exemple, copier l’ISO automatiquement sur un partage public, le graver sur un CD, etc.

De plus, durant ces phases de fabrication, il est possible d’exploiter les variables suivantes :

Vous voilà donc en mesure de réaliser toute sorte de personnalisation avec précision. Comme par exemple, ajouter des outils supplémentaires sur le média sans avoir à surcharger le noyau.

' Copiez vos outils dans un dossier racine , par exemple "Z:\CustPE\"
' Placez les binaires 64 bits dans un sous-dossier "MediaTools_x64"
' Placez les binaires 32 bits dans un sous-dossier "MediaTools_x86"

Const sCustRoot = "Z:\CustPE\"

If oEnv("STAGE") = "ISO" then
  Set oFSO = CreateObject ("Scripting.FileSystemObject")
  If oFSO.FolderExists(sCustRoot) Then  
    Const OverwriteExisting = TRUE
    sRep = oEnv("CONTENT") & "\Tools_" & oEnv("PLATFORM")
    oFSO.CreateFolder(sRep)
    oFSO.CopyFile "MediaTools_" & oEnv("PLATFORM") & "\*.*" , _
        sRep & "\" , OverwriteExisting
  Else
    WScript.Echo "Erreur: Le dossier " & sCustRoot a " est introuvable."
  End If

WScript.Quit 1
End if

Voici un exemple de script que je vous propose d’essayer. Celui-ci ne se charge pas de copier les outils sur le média comme le précédent, mais effectue une modification du registre du noyau, la copie du fond d’écran ainsi que les différents outils de cette démonstration. En matière de code, ce n’est pas forcément un modèle du genre, mais je souhaitais vous montrer également l’usage de commandes externes, telles que reg, copy, xcopy…

Set oShell = CreateObject("WScript.Shell")
Set oEnv = oShell.Environment("PROCESS")

WScript.Echo "INSTALLDIR = " & oEnv("INSTALLDIR")
WScript.Echo "DEPLOYROOT = " & oEnv("DEPLOYROOT")
WScript.Echo "PLATFORM = " & oEnv("PLATFORM")
WScript.Echo "ARCHITECTURE = " & oEnv("ARCHITECTURE")
WScript.Echo "TEMPLATE = " & oEnv("TEMPLATE")
WScript.Echo "STAGE = " & oEnv("STAGE")
WScript.Echo "CONTENT = " & oEnv("CONTENT")

Const sCustRoot = "Z:\CustPE\"

If oEnv("STAGE") = "WIM" And oEnv("TEMPLATE") = "Generic" then
    sMountHive = oEnv("CONTENT") & "\Windows\System32\config\DEFAULT"
    sTempHive = "HKLM\WinPE"
    ' Load Temp Hive WinPE
    sCmd = "%COMSPEC% /c reg load " & sTempHive & " " & Chr(34) & _ 
      sMountHive & Chr(34)
    WScript.Echo "Execute : " & sCmd
    rc = oShell.Run(sCmd, 0, true)
    WScript.Echo "Load Return code : " & rc
        
    ' Modify Temp Hive WinPE
    Hidden = sTempHive & "\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Hidden"
    SHidden = sTempHive & "\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\ShowSuperHidden"
    oShell.RegWrite Hidden, 0, "REG_DWORD"
    oShell.RegWrite SHidden, 1, "REG_DWORD"
    
    ' Unload Temp Hive WinPE
    sCmd = "%COMSPEC% /c reg unload " & sTempHive
    WScript.Echo "Execute : " & sCmd
    rc = oShell.Run(sCmd, 0, true)
    WScript.Echo "Unload Return code : " & rc

    '  copy autolauncher (winpeshl.ini) 
    sCmd = "%COMSPEC% /c copy " &  sCustRoot & "\winpeshl.ini " & _
       oEnv("CONTENT") & "\Windows\System32\winpeshl.ini"
    WScript.Echo "Execute : " & sCmd
    rc = oShell.Run(sCmd, 0, true)

    '  copy kernel tools x86 and x64 and scripts
    sCmd = "%COMSPEC% /c xcopy " &  sCustRoot & "\Kernel\*.* " & _ 
       oEnv("CONTENT") & " /e /s"
    WScript.Echo "Execute : " & sCmd
    rc = oShell.Run(sCmd, 0, true)
 
    '  copy wallpaper
    sCmd = "%COMSPEC% /c copy " &  sCustRoot & "\*.bmp " & _
       oEnv("CONTENT") & "\Windows\System32\winpe.bmp"
    WScript.Echo "Execute : " & sCmd
    rc = oShell.Run(sCmd, 0, true)

    WScript.Quit 1

End if

Important : J’ignore pourquoi (no bug, it’s a feature !), mais le script de sortie n’est pas pris en compte lorsqu’il ne contient pas la directive “WScript.Quit 1”. Si cette directive est présente, le script sera exécuté et les instructions “wscript.echo” seront affichés dans la fenêtre de résultat de la console MDT.

Exemple d’affichage dans la console:

Après avoir renommé le fichier existant, il suffit d’enregistrer ce script en lieu et place de ce dernier sous “C:\Program Files\Microsoft Deployment Toolkit\Samples\UpdateExit.vbs“.

Il est également possible de modifier le nom et l’emplacement de ce script, en le stipulant dans le fichier du modèle “Generic.xml” comme suit :

<Exits> 
 <Exit>cscript.exe "%INSTALLDIR%\Samples\UpdateExit.vbs"</Exit>
 <Exit>cscript.exe "Z:\Scripts\CustomUpdateExit.vbs"</Exit> 
</Exits>

2. Génération des images

À partir de la console MDT, sélectionnons notre partage de déploiement préféré afin d’afficher les “propriétés” puis rendons-nous sous l’onglet “Windows PE” sans oublier de vérifier l’architecture “Platform” = “x86|x64”

Sous le sous-onglet “General“, il nous faut supprimer le fond d’écran personnalisé “Custom background bitmap file”  ainsi que “Extra directory to add” du fait qu’ils sont traités par le script.

Notez que ces réglages (copie de fichiers), peuvent également être définis dans les fichiers de modèles “C:\Program Files\Microsoft Deployment Toolkit\Templates\Generic.xml” et/ou “LiteTouch.xml” entre au niveau de la balise “<Content>”..

En fait, je pense que le principal inconvénient lié à l’interface graphique MDT est que l’image et le dossier additionnel sont appliqués aux 2 images LTI et générique.

Nous cocherons également les 2 cases “Generate a generic Windows PE WIM file” et “Generate a generic bootable ISO image” en indiquant éventuellement un nom de notre choix pour ces fichiers.

Normalement, il n’y a rien à faire au niveau du sous-onglet “Features” du fait que les composants optionnels ont été configurés dans le fichier “Generic.xml“.

Après avoir validé ces choix par “OK“, il suffit d’utiliser le menu “Update Deployment Share” pour procéder à la génération.

Vous pouvez maintenant aller tranquillement déguster un bon café ou plusieurs, vous l’avez mérité.:-)

Après quelques longues minutes de patience, nous retrouvons les fichiers .WIM et .ISO dans le dossier “\Boot” du partage de déploiement.

V. Tests et Résultats

En démarrant une machine virtuelle à partir de l’image .ISO obtenue par cet atelier, nous pourrons constater ce genre de résultat.

La lettre du média WinPE est affichée dans une invite de commande qu’il faut conserver ouverte afin de ne pas redémarrer le système, et le lanceur d’application “TBLauncher” est automatiquement lancé.

Aperçu du résultat :

Je reconnais volontiers que cette démonstration est plutôt ardue et pour vous faciliter la tâche, je vous propose de télécharger la structure des fichiers utilisés pour cet atelier ici. (CustPE.zip – 3 679 587 octets )

À vous de jouer

I. Présentation

Cet exemple est issu d’un retour d’expérience qui m’a conduit à implémenter une petite adaptation particulière,  plutôt inédite. En effet, bien que probablement marginale, j’ai pensé que ce serait un bon cas d’étude et de réflexion, voire d’inspiration pour vos propres adaptations .

L’idée consiste à banaliser le fichier de configuration “bootstrap.ini” et le modifier “à la volée”. Cette approche n’est peut être pas la meilleure, mais cela répondait au cahier des charges… De plus, je pense que cette étude permet d’appréhender le MDT sous un angle différent, histoire d’explorer de nouveaux sentiers pédagogiques

Pour rappel, la fabrication des clients, “Update Deployment Share“, est pilotée par un script Powershell qui effectue l’assemblage selon les réglages définis dans l’onglet “Windows PE” ainsi qu’aux directives contenues au sein des fichiers “LiteTouchPE_x64|x86.xml“.

En consultant ces derniers, vous constaterez que le fichier “Bootstrap.ini” est copié dans le ramdrive du noyau WinPE soit “X:\Deploy\Scripts\“. C’est principalement ce fichier qui détermine la relation du client LiteTouch avec la ressource partagée MDT.

Traitement du fichier “Bootstrap.ini”

Cette information peut s’avérer bien pratique à connaitre, dès lors que vous utilisez des points de déploiements multiples. En effet, imaginons que vous disposez de plusieurs sites, avec un serveur MDT sur chaque, vous devez admettre que les noms et adresse IP de la ressource partagée seront nécessairement différents. Le MDT propose bien une notion de “points de déploiement liés” (“Linked Deployment Shares“) mais cela implique une action de régénération et de mise à jour des clients LiteTouch sur chaque site.

Bien que cela soit prévu dans la console MDT, on peut aussi considérer un autre mécanisme de réplication et ne pas vouloir utiliser cette relation entre points de déploiement. On peut alors imaginer de réaliser un “client LiteTouch commun” en modifiant le fichier “bootstrap.ini” à la volée.

II. Mise en œuvre

On considère que le dernier octet de l’adresse IP des serveurs MDT est identique d’un site à l’autre, et que le nom de la ressource partagée est identique (ie . “\\w.x.y.201\DeploymentShare$“). Le script aura donc la charge d’identifier le réseau du client, et recomposer le chemin UNC du serveur MDT. (Pour simplifier, la classe d’adressage IP est /24 soit un masque 255.255.255.0)

Je précise qu’il s’agit d’un exemple arbitraire et je vous laisse le soin de l’adapter en fonction de votre plan d’adressage IP, du partage de déploiement et autres identifiants propres à votre environnement de test.

A. Montage du noyau WinPE

Montez l’image d’un noyau LiteTouchPE-x…wim en procédant comme suit :

mkdir c:\Mount
dism /Mount-Wim /WimFile:c:\DeploymentShare\Boot\LiteTouchPE_x86.wim /index:1 /MountDir:C:\Mount

B. Modification du fichier Bootstrap.ini

Modifiez le fichier “[MountWIM]\Deploy\Scripts\Bootstrap.ini” via le bloc-notes, afin de remplacer le chemin UNC de la ressource partagée MDT par une chaîne spécifique “DeployRoot=@DEPLOYSRV@”

Notepad C:\Mount\Deploy\Scripts\bootstrap.ini

Exemple de contenu d’un bootstrap.ini générique

[Settings]
Priority=Default

[Default]
DeployRoot=@UNC@
SkipBDDWelcome=YES
UserID=MDT-Depl
UserDomain=@SRV@
UserPassword=Pa$$w0rd
KeyboardLocalePE=040c:0000040c

Note : Si vous disposez d’un compte de domaine Active Directory, entrez le nom Netbios du domaine au niveau de la variable “UserDomain“.

Renseignez vos propres informations, puis enregistrez le fichier modifié et fermez le bloc-notes.

Mise à jour du fichier bootstrap.ini

C.  Ajouter un script personnalisé

Créez un nouveau script “UpdBootStrap.vbs” dans le dossier “[MountWIM]\Deploy\Scripts”

Notepad C:\Mount\Deploy\Scripts\UpdBootStrap.vbs

Création du nouveau script “updBootstrap.vbs”

Recopiez le contenu ci-après dans ce nouveau fichier

Contenu du UpdBootStrap.vbs

Function UpdateFile (sFile,sBefore,sAfter)

Const ForReading = 1
Const ForWriting = 2

Set oFSO = CreateObject("Scripting.FileSystemObject")
' Get-content
Set oFile = oFSO.OpenTextFile(sFile, ForReading)
sText = oFile.ReadAll
oFile.Close
     
sNewText = Replace(sText, sBefore, sAfter)

' Set-content
Set oFile = oFSO.OpenTextFile(sFile, ForWriting)
oFile.WriteLine sNewText
oFile.Close

End Function

Function CutIP (sIP,iOct)
  iFirstDot = InStr(1,sIP,".")
  iSecondDot = Instr(iFirstDot+1,sIP,".")
  iThirdDot = Instr(iSecondDot+1,sIP,".")

  iFirstOctet = Left(sIP, iFirstDot-1)
  iSecondOctet = Mid(sIP, iFirstDot+1, iSecondDot-iFirstDot-1)
  iThirdOctet = Mid(sIP, iSecondDot+1, iThirdDot-iSecondDot-1)
  iFourthOctet = Mid(sIP,iThirdDot+1, Len(sIP)-iThirdDot)

  Select Case iOct 
    Case 1 : CutIP = iFirstOctet
    Case 2 : CutIP = iSecondOctet
    Case 3 : CutIP = iThirdOctet
    Case 4 : CutIP = iFourthOctet
    Case Else : CutIP = "Indiquez un chiffre entre 1 et 4"
  End Select
End Function

'--------------------------
' Main script
'--------------------------
Const sFileName = "X:\Deploy\Scripts\Bootstrap.ini"
Const sOctSrv =  ".201"         ' dernier octet de l'adresse IP du serveur 
Const sDeployShare="\DeploymentShare$"  ' nom du partage MDT

' identification du réseau IP
Set oWMIService = GetObject("winmgmts:\\.\root\cimv2")
Set IPConfigSet = oWMIService.ExecQuery _
    ("Select * from Win32_NetworkAdapterConfiguration Where IPEnabled=TRUE")
For Each IPConfig in IPConfigSet
    If Not IsNull(IPConfig.IPAddress) Then 
        sCurrentIP = IPConfig.IPAddress(0)         
         ' Recomposition du chemin UNC vers la ressource MDT ...
        sSrvName = CutIP(sCurrentIP,1) & "." & CutIP(sCurrentIP,2) & _
                    "." & CutIP(sCurrentIP,3) & sOctSrv 
        sDeplUNC =  "\\" & sSrvName & sDeployShare
    Else
        sDeplUNC = "\\?.?.?.?" & sDeployShare  
    End If
Next

Confirm = InputBox ("Veuillez confirmer l'emplacement du point de déploiement" & _
 vbCrLf & "ou cliquez sur annuler pour redémarrer.","Confirmation",sDeplUNC) 
If Confirm <> "" Then
  sKeyword = "@UNC@"    ' le chemin UNC (chaine à remplacer)
  UpdateFile sFileName,sKeyword,sDeplUNC
  sKeyword = "@SRV@"    ' le nom du serveur (chaine à remplacer)
  UpdateFile sFileName,sKeyword,sSrvName

  WScript.Echo "Mise à jour " & sFileName & " " & sKeyword & " " & sSrvName
Else
  Set oShell = CreateObject("Wscript.Shell")
  oShell.Run "wpeutil reboot"
End If

Enregistrez ce contenu et fermez le bloc-notes.

Enregistrement du script “updBootstrap.vbs”

D. Modification du fichier winpeshl.ini

Modifiez le fichier “[MountWIM]\Windows\System32\winpeshl.ini”

Notepad C:\Mount\Windows\System32\winpeshl.ini

Contenu du fichier “winpeshl.ini” :

[LaunchApps]
%SYSTEMROOT%\System32\wpeutil.exe,InitializeNetwork
%SYSTEMROOT%\System32\wpeutil.exe,SetKeyboardLayout 040C:0000040C
%SYSTEMROOT%\System32\wscript.exe,X:\Deploy\Scripts\UpdBootStrap.vbs
%SYSTEMROOT%\System32\bddrun.exe,/bootstrap

Enregistrez le contenu modifié et fermez le bloc-notes.

Modification du fichier “winpeshl.ini”

Compléments d’information :

Pour votre gouverne, voici quelques éléments qui m’ont cette modification particulière de ce fichier d’initialisation “winpeshl.ini” .

En fait, ce fichier existe déjà sur un client LiteTouch et a pour charge d’initialiser l’environnement WinPE via le programme spécifique “BDDRun.exe“. L’enchaînement de l’initialisation des couches réseaux est une difficulté majeure de cette démonstration, du fait que nous effectuons une modification du fichier “bootstrap.ini” en même temps. L’idée est donc d’ajouter l’exécution du script “UpdBootStrap.vbs“, avant le lancement de “BDDRun.exe,/Bootstrap“.

Si le script a besoin du réseau, il ne faut pas lancer wpeinit, car il va interpréter le fichier “unattend.xml” dans la foulée et lancer les commandes qu’il contient.

Dans ce cas, je pense que la modification la plus logique est de :

• soit ajouter la commande “wpeutil InitializeNetwork” au début du fichier “\Windows\System32\winpeshl.ini“

• soit supprimer toutes les directives “RunSynchronous” du fichier “\unattend.xml” et les transposer intégralement dans le fichier winpeshl.ini

Je me permets d’ajouter quelques précisions sur l’outil “BDDRun.exe”, dont le fonctionnement, je l’avoue, reste à mon avis encore bien obscur. Issues de mon expérience, je vous demanderait donc de ne pas prendre ces informations comme des affirmations et de les considérer avec précaution  :

• Modifié depuis MDT2010

• Pas ou très peu documenté. BDDRun.exe est un lanceur de commandes, qui ne semble supporter que 2 options
  • /Bootstrap
  • /BootstrapNoSF8

• Exécute implicitement “wpeinit” lorsque l’un de ces commutateurs précité est stipulé.

• Reste chargé en mémoire, typiquement pour l’exploitation des variables MDT et la surveillance de l’appui sur [F8]

• Sollicité par les scripts MDT (pour exécuter des programmes avec un minimum d’affichage visible, sauf .bat et .cmd.), comme par exemple :
  • Bddrun startnet.cmd
  • Bddrun wscript.exe, X:\deploy\scripts\LiteTouch.wsf

• Dans un contexte Windows (hors WinPE), les programmes sont exécutés avec le niveau de privilèges élevés (hors UAC).

• BDDRun garantit également que le dossier de travail est correctement positionné pour les processus lancés. Par exemple, il agit ainsi sur le contexte d’exécution des scripts utilisant des objets WScript.Shell ou les installations de packages .MSI, afin de minimiser les risques d’erreurs.

Pour cette démonstration, j’ai ajouté 2 lignes préliminaires , faisant appel à l’outil spécifique WinPE “wpeutil.exe”  afin de :

• Initialiser la couche réseau sans passer par BBDRUN, ni WPEINIT

• Passer le clavier en AZERTY du fait que le fichier “bootstrap.ini” n’est pas encore traité lors de l’ouverture de la boite de dialogue, sinon le clavier reste en QWERTY par défaut.

E. Démontage du noyau WinPE

Démontez l’image du noyau WinPE modifié en enregistrant les modifications, via la commande suivante :

dism /Unmount-Wim /MountDir:C:\Mount /commit

Voilà, la modification est terminée et il ne vous reste plus qu’a injecter ce noyau  au sein d’un structure amorçable telle qu’une clé USB, un CDROM ou bien encore un serveur WDS.

Voici un exemple de ce que vous pourriez obtenir lors du démarrage de ce client LTI.

Boite de dialogue du script “UpdBootStrap.vbs” permettant de saisir et/ou valider le chemin d’accès au partage MDT.

Boite de dialogue du script “UpdBootStrap.vbs”

Message du script indiquant la modification effectuée :

Message du script indiquant la modification effectuée

La suite du scénario, lancement de l’assistant “wizard.hta” dépend bien sur de la configuration de votre MDT …

Bonne continuation

Christophe M.

I. Présentation

Pour faire suite à mon tutoriel sur la “présentation de WinPE“, je vous propose d’aborder maintenant quelques possibilités de personnalisation de l’environnement WinPE et par la même occasion en dévoiler quelques aspects méconnus.

Bien évidemment, la personnalisation de WinPE dépend directement de l’usage que l’on souhaite en faire et de l’environnement d’exploitation dans lequel on l’utilise. J’espère que vous me pardonnerez ces choix arbitraires, mais les idées sont tellement nombreuses qu’il m’est difficile de définir une préférence.

Je vais donc prendre différents angles d’approche, afin de couvrir plusieurs cas de figure et ajouter des liens vers des articles dédiés pour les personnalisations plus complexes.

II. Personnalisation du démarrage

A. Supprimer le message WinPE à partir d’un CD/DVD

Je ne pense pas que cela soit une bonne pratique, mais il arrive parfois que l’on souhaite supprimer le message de confirmation “Appuyez sur une touche pour démarrer sur le CD/DVD“. Pour cela, il suffit de supprimer ou renommer le fichier “\boot\bootfix.bin“. Toutefois, il vous faudra ensuite recréer l’image .ISO et/ou graver le support. Les kits ADK ou WAIK, proposent l’outil OSCDIMG.exe pour la génération d’une image .ISO. Mais pour ce genre d’action, l’usage d’un outil tel que 7-Zip me parait amplement suffisant.

Ouvrez donc simplement votre fichier .ISO avec 7-Zip, puis renommez ce fameux fichier “\boot\bootfix.bin” en “\boot\bootfix.bak” par exemple, et le tour est joué.

B. Distinguer l’amorçage WinPE 4 par rapport à Windows 8/2012

Lors d’un démarrage sur un média DVD/CD, si le disque dur contient un système, vous disposez de quelques secondes pour confirmer l’amorçage sur le média amovible. Comme mentionné dans le paragraphe précédent, il est possible de modifier ce comportement, mais c’est plutôt déconseillé, car cela risque d’engendrer des “bouclages” lors des processus d’installation qui imposent un redémarrage.

Toutefois, on peut faire un constat récurent , typique des techniciens utilisant des environnements virtuels, c’est de louper ou confondre l’amorçage sur le bon média, par exemple lors d’une préparation pour une capture d’image WIM ou tout simplement pour une réinstallation de machine.

En fait, lors du démarrage d’un client LiteTouch basé sur un noyau WinPE 4, et que la machine concernée est sous Windows 8, vous n’avez pas la possibilité de distinguer ces 2 phases d’amorçage du fait qu’elles sont graphiquement identiques.

Affichage du logo sur l’écran d’amorçage de Windows NT6.2 (et WinPE 4 et +)

La solution la plus élégante serait de personnaliser le logo d’amorçage d’un noyau WinPE, mais ce n’ai pas une chose aisée et c’est surtout non supporté par Microsoft. De plus, sur une machine UEFI, ce logo générique peut être substitué par celui du fabricant.

Personnellement, j’ai opté pour une solution beaucoup plus simple à mettre en œuvre, qui consiste à afficher la barre de  progression traditionnelle (affichée par les noyaux antérieurs).

Pour cela il suffit modifier  les magasins d’amorçage,  fichiers “BCD“, selon l’architecture souhaitée 32 bits (x86) et/ou 64 bits (amd64) situés dans le Kit de déploiement Windows. Soit : “C:\Program Files (x86)\Windows Kits\8.1\Assessment and Deployment Kit\Windows Preinstallation Environment\x86|amd64\Media\Boot\BCD”

Attention, la modification des fichiers “BCD”, situés dans les dossiers “\Boot\x86\Boot” ou “\Boot\x64\Boot” de votre structure MDT, est inutile. En effet, ils sont écrasés par ceux du kit lors d’une mise à jour de vos clients LiteTouch .

Par exemple, pour modifier les images (non EFI), tapez les commandes suivantes (à partir de Windows 8.1 ou 2012/R2) – Pensez à faire une sauvegarde des fichiers “BCD” au préalable :

bcdedit /store "c:\Program Files (x86)\Windows Kits\8.1\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\Media\Boot\BCD" /set {default} bootmenupolicy legacy

L’opération a réussi.

bcdedit /store "c:\Program Files (x86)\Windows Kits\8.1\Assessment and Deployment Kit\Windows Preinstallation Environment\x86\Media\Boot\BCD" /set {default} bootmenupolicy legacy

L’opération a réussi.

Note : Pour revenir à la normale, remplacez simplement la directive “Legacy” par “Standard” qui est la valeur par défaut. Pour vérifier la valeur positionnée, remplacez le commutateur “/set …” de la commande, par “/enum all”

Pour régénérer les images ISO, rendez-vous au niveau de la console MDT, via les propriétés de votre point de déploiement, sous l’onglet “Windows PE” et selon l’architecture désirée, vérifiez que la case “Generate a Lite Touch bootable ISO image” est cochée. Utilisez ensuite le menu, “Update Deployment Share“,  et choisissez l’option “Completely regenerate the boot images” afin de mettre à jour vos clients LiteTouch.

Lors du chargement des images .ISO / ou de vos supports ainsi modifiés, vous verrez apparaitre cette barre de progression indiquant que la machine est bien en cours d’amorçage sur WinPE et non sur le système déjà installé.

Affichage de la barre de chargement traditionnelle sur l’écran d’amorçage

III. Personnalisations avancées de WinPE

Vous trouverez ci-après un résumé des différents articles disponible sur le sujet.

A. Maîtrise des images de démarrage LTI / WinPE

Sous ce titre quelque peu ambitieux se cache une présentation de personnalisation particulière des client LiteTouch afin d’utiliser le MDT pour la fabrication et s’affranchir de quelques opérations fastidieuses en ligne de commande.

Consultez l’article : “Maîtrise des images de démarrage LTI / WinPE”

B. Lonesome LTI, ou l’histoire d’un client LiteTouch qui voulait rester seul !

Dans cet article, j’aborde un petit challenge qui m’a été soumis consistant à exploiter un client LiteTouch unique (identique sur chaque site) dans un environnement multisites, sans recourir aux points de déploiement liés que propose le MDT.

Consultez l’article “Comment utiliser un bootstrap générique ?“

C. Réaliser un dual boot WinPE LTI/Windows

Cet article est à mon avis un bon cas d’école puisqu’il explique comment implémenter une configuration de double amorçage dans le but de procéder à une réinstallation complète d’un système, localement ou à distance.

Consultez l’article “Réaliser un dual boot WinPE LTI/Windows”

D. Installer UltraVNC sur un client LiteTouch

Dans cet article, j’aborde une solution alternative* permettant d’effectuer une prise de main à contrôle à distance vers un client WinPE ou LiteTouch. *Si vous ne disposez pas de la solution DaRT proposée dans le cadre d’un contrat “Sofware Assurance” MDOP (Microsoft Desktop Optimization Pack)

Consultez l’article “Installer UltraVNC sur un client LiteTouch”

E. Comment installer vos propres outils dans WinPE ?

Dans cet article, je vous propose un ensemble de personnalisation de l’environnement WinPE et/ou LiteTouch afin d’y ajouter une véritable boite à outils et ainsi faciliter les opérations de maintenance et de dépannage de vos précieuses machines.

Consultez l’article Comment installer vos propres outils dans WinPE ?

To be continued ?…

I. Présentation

L’idée de ce tutoriel est de vous présenter différentes techniques de mise en œuvre de l’amorçage réseau PXE (Pre-boot eXecution Environment). Pour ne léser personne, j’ai opté pour 2 implémentations distinctes, l’une consistant à installer un PXE sur un NAS de type Busybox (Linux) et l’autre chargé de modifier le mécanisme d’amorçage WDS en y injectant un syslinux.

L’intérêt principal de PXE réside dans le fait qu’il vous affranchit des médias de type CD ou autres clés USB. Toutefois, il peut également engendrer une augmentation significative du trafic réseau et doit donc être implémenté avec parcimonie dans votre environnement. Notez également qu’il n’est pas obligatoire d’implémenter un serveur PXE sur chaque sous-réseau. En effet, pour bénéficier des services PXE dans plusieurs sous-réseaux, il suffit d’agir sur l’option DHCP 66 sur laquelle je reviendrais plus tard.

A. Rappels sur PXE (WDS)

Pour garantir un mécanisme d’amorçage PXE, il est nécessaire d’offrir un adressage IP dynamique aux clients via un serveur BOOTP ou DHCP. Les clients peuvent ensuite télécharger un système d’amorçage via un serveur Trivial FTP (alias TFTP). Le schéma ci-après symbolise les principales étapes de ce processus.

Mécanisme d’amorçage PXE sous WDS

Notez que les serveurs DHCP et PXE (dérivé de BOOTP) sont techniquement très proches et utilisent les mêmes ports de communication réseau.(D’où la nécessiter de désactiver l’option d’écoute lorsque le DHCP est présent sur le serveur WDS lui-même).  En présence d’Active Directory, les serveurs WDS doivent être “autorisés” au même titre que les serveurs DHCP.

Concernant PXE, les 2 options DHCP les plus intéressantes sont :

Option 66 : Nom d’hôte du serveur de démarrage – C’est-à-dire l’adresse IP ou le nom du serveur chargé de fournir un système d’amorçage à la machine cliente.

Option 67 : Nom du fichier de démarrage – permet de stipuler le nom du fichier d’amorçage (précédé du chemin éventuel, relatif à la racine TFTP du serveur). – Ne confondez pas l’option 67 avec le port 67, ça n’a rien à voir 

II. Mise en œuvre de WinPE/PXE sur un NAS Synology

Si comme moi, vous disposez d’un petit serveur NAS, de type Synology et d’une FreeBox (ou autre boitier d’accès Internet) chargée de distribuer les  adresses IP sur votre réseau local, vous pouvez envisager la solution suivante.

A. Activation du service NFS sur le NAS

Commencez par activer le service NFS sur votre NAS, via le panneau de configuration Synology (DSM4.3) en cliquant sur l’icône ci-dessous :

Configuration des partages sur Synology

Sélectionnez l’onglet “Service NFS“, puis cochez la case “Activez NFS” puis par la même occasion cochez la case “Activer la prise en charge de NFS 4“.

Configuration de NFS sur Synology

Laissez les autres valeurs par défaut puis cliquez sur le bouton “Appliquer“. Acceptez le message vous indiquant que les services réseau vont redémarrer, puis fermez cette page.

B. Création d’un partage SMB (Windows) et NFS (Unix)

À partir de l’icône “File Station“, créez un nouveau dossier partagé, comme par exemple “PXEBOOT”

Nouveau dossier partagé

Cliquez sur le bouton “OK“. Cette action doit vous amener sur l’écran de “configuration des privilèges“.

Configuration des privilèges

Pour simplifier les copies et l’administration par la suite, cochez la case “Lecture/écriture” pour le compte “Admin“, puis cliquez sur le bouton “OK“.

De retour dans la fenêtre “Panneau de configuration … Dossier partagé“, votre nouveau partage doit être sélectionné. Cliquez alors sur le bouton “Privilèges … Privilèges NFS“, puis sur le bouton “Créer”

Privilèges NFS

Sous la fenêtre “Créer une règle NFS“, entrez la/les machine(s) qui auront accès au partage NFS dans le champ “Nom d’hôte ou IP*”

Note : Comme indiqué *, plusieurs syntaxes sont autorisées. Ici, nous avons opté pour la notation CIDR (Classless Inter-Domain Routing), soit le réseau 192.168.0.0 avec un masque de classe C par défaut (255.255.255.0) donc /24

Sélectionnez ensuite “Lecture seule” dans la liste du champ “Privilège” et la valeur “Mapper vers guest” dans le champ “Root squash” *

Note : Cette option (de sécurité linux) a pour but d’empêcher un client de devenir root sur le système de fichiers NFS stockés sur le serveur

Cliquez 2 fois sur les boutons “OK” pour valider cette configuration.

C. Installation du PXE sur le NAS Synology

Pour cela, il faut procéder au téléchargement puis à la configuration d’un syslinux  (Modules PXE sous Linux). Vous pouvez trouver différents tutoriels sur la toile, comme par exemple en français ici et les sources de syslinux  ici

En gros, il vous faudra principalement modifier le fichier “PXEBOOT\pxelinux.cfg\default” afin qu’il ressemble à ceci :

DEFAULT menu.c32
MENU TITLE PXE Boot Menu de demo
PROMPT 0
TIMEOUT 100
ONTIMEOUT chainlocal

LABEL chainlocal
	MENU LABEL Demarrage sur le disque local
    MENU DEFAULT
	KERNEL chain.c32
	APPEND hd0

LABEL Demarrage sur WinPE generique
   LINUX memdisk
   INITRD ISO/Generic_x86.iso
   APPEND iso raw
  
LABEL Demarrage de CloneZilla
   LINUX memdisk
   INITRD ISO/clonezilla-live-2.4.2-10-i686-pae.iso
   APPEND iso

Je vous conseille d’effectuer la modification de ce fichier sans extension avec Notepad++ afin d’éviter les effets de bords et de format liés à l’utilisation du Bloc-notes Windows.

Et stocker vos images .iso sous le dossier “PXEBOOT\ISO“, comme par exemple une image de client LiteTouch ou générique de MDT, une image WinPE de votre cru, une image de réparation WinRE et pourquoi pas une image du logiciel libre Clonezilla – Pour peu que cela soit des images amorçables au format .ISO, ou (WinImage) libre à vous de choisir 

Si vous ne voulez vraiment pas vous casser la tête, vous pouvez télécharger mon exemple prêt à l’emploi :

• Pour la version complète, c’est ici (~455Mo)
  • Contient une image WinPE 32 bits avec quelques petits outils (cf CustPE : Comment installer vos propres outils dans WinPE ?)
  • Contient une image LiveIso de CloneZilla v2.4.2-10 pour système 32 bits/PAE (PC Récents)

• Pour la version sans les .ISO, c’est ici (~110Ko)
  • Pour l’image WinPE, utilisez simplement le MDT (cf Debuter avec MDT 2013)

Créer un ISO de WinPE générique avec MDT

Pour CloneZilla, vous trouverez les sources ici, sans oublier de choisir le format “.iso” au niveau de “File Type”

Copiez tous ces fichiers dans le fameux dossier “PXEBOOT” du NAS, créé précédemment.

Dans le panneau de configuration du NAS, cliquez sur l’icône “FTP“, puis sélectionnez l’onglet “TFTP / PXE“.

Configuration de TFTP/PXE et du DHCP

Cochez la case “Activer le service TFTP” puis cliquez sur le premier bouton “Selectionnez” afin de choisir le dossier racine “PXEBOOT“.

Cochez la case “Configurer le service DHCP sur ce serveur pour PXE”

A ce moment, il est possible que l’interface vous demande d’installer DHCP Server s’il n’est pas déjà installé. Laissez vous guider par l’assistant Synology, il va très bien s’en charger pour peu que l’accès Internet soit valide.

Cliquez sur le second bouton “Selectionnez” afin de choisir le fichier du chargeur de démarrage, soit “pxelinux.0”

La particularité de cette configuration réside dans la présence de 2 serveurs DHCP sur un même réseau. En effet, dans mon cas, la Freebox assure la distribution standard des adresses IP alors que le NAS fournira le chargeur de démarrage (option DHCP 67).

Dans le champ “Serveur DNS” et “Passerelle” entrez l’adresse de la box. Pour le reste, entrez une petite plage d’adresse IP (celles-ci ne seront pas retenues par le client DHCP)

Ça marche plutôt très bien, mais malgré mon analyse je n’ai pas encore d’explication claire sur ce comportement et j’aurais préféré stipuler explicitement l’option 66 sur le serveur DHCP (Freebox) afin d’indiquer le serveur PXE (NAS). – N’hésitez pas à commenter cet article si vous avez  des informations pertinentes sur le sujet  

• cf mon complément en annexe

Ensuite cliquez sur le bouton “Appliquer“.

D. Test du résultat

À partir d’une machine virtuelle ou physique, démarrer l’ordinateur sur l’amorçage PXE (généralement via [F12]). Après quelques secondes, vous devriez voir apparaître le menu suivant:

Voilà, c’est fini pour cet exemple, mais cela devrait marcher pour la plupart des NAS de type Busybox et pour les moins fortunés, je vous conseille la lecture d’un excellent article de Julien Darakdjian sur “Déployer Windows avec un Raspberry Pi“. Je vous concède que c’est un peu geek sur les bords, mais j’avoue que pour l’avoir testé, avoir un MDT complet dans le creux de la main pour une petite trentaine d’euros, c’était plutôt plaisant ( kifant pour les plus jeunes )

III. Mise en œuvre de syslinux sur WDS

Pour de nombreuses sociétés, universités ou centres de formation, la solution de déploiement ne se cantonne pas toujours à des machines sous Windows et peut conduire à des choix difficiles. Dans le cadre d’une complémentarité  avec les systèmes d’exploitation tels que Linux, que naturellement Windows Deployment Services ne prend pas en charge, je vous propose une approche alternative,  prétexte à une analyse plus approfondie des mécanismes du chargeur de démarrage WDS (“bootstrap loader”).

A. Rappels et précisions sur WDS

Au besoin, reportez-vous à mon tutoriel sur WDS.

En premier lieu, il convient de présenter la structure des dossiers retenue par Microsoft pour son serveur WDS. La racine, dénommée “TFTP Root“, est située dans le dossier défini lors de l’installation (ie. “E:\RemoteInstall\” ), mais les clients ont un droit de lecture par défaut uniquement sur les sous-dossiers “boot” et “tmp”. Ces réglages sont respectivement stipulés sous la clé de registre  suivante :

“HKLM:\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSTFTP”

• Pour l’emplacement de la racine TFTP via l’entrée [REG_SZ] “RootFolder” =  “E:\RemoteInstall”
• Pour les droits de lecture des clients PXE via l’entrée [REG_MULTI_SZ] “ReadFilter” = “\boot\* \tmp\* boot\* tmp\*”.

Au niveau de la racine TFTP, on distinguera 2 dossiers essentiels :

• “Boot” : Contient la structure composée principalement des fichiers liés à l’amorçage (Bootstrap Loaders) et des images .WIM de démarrage (Autrement dit, les images système WinPE).
• “Images” : Contient les images .WIM d’installation (Autrement dit, les distributions Windows préparées avec “sysprep”)

Dans la structure de dossier “Boot“,  il semblerait que Microsoft ait choisi d’utiliser un sous-répertoire propre à chaque plateforme (x86, x64, IA64,arm …), dans lesquels sont stockés les fichiers  d’amorçage (tels que bootmgr.exe , default.bcd, pxeboot.com, wdsnbp.com …)  et un sous-dossier “Images” dans lequel sont placés les images .WIM de WinPE ainsi qu’un fichier “.WIM.bcd” associé.

Sur le plan pratique, il apparait que les fichiers situés dans les dossiers x86 et x64 sont identiques et le répertoire  x86x64 ne contient que le fichier de configuration d’amorçage. En focalisant les actions uniquement sur le dossier x86, je n’ai pas relevé de soucis notables avec des machines x64. Réciproquement, si vous travaillez sur le dossier x64, et adaptez les réglages en conséquence, les résultats devraient être sensiblement les mêmes.

Le premier chargeur d’amorçage PXE, nommé “wdsnbp.com” commence par valider l’architecture processeur du client puis, initialise l’amorçage correspondant. En fonction des réglages du serveur la machine peut attendre une confirmation (cf  périphériques en attente)  ou initialiser le chargeur par défaut “pxeboot.com“(son équivalent, le fichier “pxeboot.n12” évite la confirmation du chargement via un second appui sur la touche [F12]). En fonction des images de démarrage disponibles, un éventuel menu est ensuite affiché puis le chargement du noyau WinPE est effectué.

Ce processus peut être modifié au niveau des propriétés du serveur sous l’onglet “Démarrer“.

Aperçu de l’onglet “Démarrer” sur WDS2012R2

En résumé, sous WDS, le principe d’amorçage standard PXE pourrait schématiquement être représenté comme suit :

Enchaînement de l’amorçage sous WDS

Note : Sous WDS, les fichiers portant l’extension “.n12” sont équivalents à leurs homologues “.com”  à la différence qu’ils ne demandent pas de confirmation via l’appui de la touche [F12].

B. Mise en œuvre d’un chainage PXE Linux sur WDS

Dans cette démonstration ostensiblement marginale, je souhaitais simplement démontrer qu’il était possible de substituer ce système d’amorçage par un chargeur Linux ayant la possibilité de rendre la main au chargeur WDS initial en cas de besoin.

1. Récupérer un noyau syslinux

Pour modifier le processus d’amorçage précédemment décrit, vous devez préalablement télécharger un noyau “syslinux” tel que la version 4.07 à l’adresse suivante  http://www.kernel.org/pub/linux/utils/boot/syslinux/

Sachant que certains de ces fichiers spéciaux ne portent pas d’extension, pensez à démasquer les extensions de fichiers connus afin d’éviter les confusions, surtout si vous effectuez ces manipulations via l’interface graphique de Windows.

Choisissez l’un des packages proposés,  portant idéalement une extension “.zip” afin de le gérer au sein de l’explorateur Windows. Vous devrez ensuite extraire de cette archive  les 3 fichiers suivants vers le dossier “Boot\x86”  situé sous la racine TFTP du serveur WDS, soit “\RemoteInstall“.

• modules/pxechain.com
• core/pxelinux.0
• com32/menu/menu.c32

2. Facultatif : Récupérer une distribution Linux

Téléchargez ensuite un noyau d’amorçage réseau Linux comme par exemple celui d’une distribution Ubuntu à l’adresse suivante : http://archive.ubuntu.com/ubuntu/dists/devel/main/installer-i386/20101020ubuntu387/images/hd-media/

Enregistrez les 2 fichiers “vmlinuz” et “initrd.gz” dans le même dossier “boot\x86” situé sous la racine TFTP du serveur WDS.

Note : Faites bien attention à respecter les extensions. En effet, lors du téléchargement d’un fichier spécial tel que “vmlinuz” une extension “.txt” peut être ajoutée à votre insu via l’explorateur Windows.

3. Facultatif : Ajouter un outil de test mémoire

Pour compléter cet exemple, je vous propose d’ajouter le célèbre outil de test mémoire “Memtest86” que vous pouvez télécharger à l’adresse suivante : http://www.memtest.org/download/5.01/memtest86+-5.01.bin

Si vous avez récupéré un fichier au format “.gz”, ouvrez cette archive avec “7-Zip” et faites une extraction de l’unique fichier dans ce même dossier “boot/x86” sous la racine TFTP du serveur WDS, puis renommez ce fichier “memtest86” sans extension.

4. Préparer les amorces PXE

À partir de l’explorateur Windows ou en ligne de commande, au niveau du sous-dossier “Boot\x86“, créez une copie du fichier “pxeboot.n12” et renommez-la en “pxeboot.0“. Faites de même pour le fichier “abortpxe.com” que vous renommerez en “abortpxe.0”

Au regard du schéma précédent sur WDS, vous pourriez me reprocher de ne pas prendre en considération le fichier “wdsnbp.com”. Ceci est lié au comportement de ce “pré-chargeur” qui redemande une confirmation via [F12] et tourne en boucle sur le menu.

Créez un sous-dossier nommé “pxelinux.cfg” : Un fichier de configuration nommé “Default.” (sans extension) doit être stocké dans ce dossier. Tapez les commandes suivantes :

mkdir E:\RemoteInstall\Boot\pxelinux.cfg
echo "" > E:\RemoteInstall\Boot\pxelinux.cfg\default.

Ajoutez le contenu suivant dans ce fichier en prenant garde à ne pas ajouter d’extension erronée.

#
# Fichier de configuration PXE
#
default menu.c32
prompt 0

menu title Demarrage PXE / Installation

label WDS (Services d'installation Windows)
	menu default
	kernel pxeboot.0
	
label Test memoire
	kernel memtest86

label Installation Ubuntu
	kernel vmlinuz
	append initrd=initrd.gz vga=788

label Demarrage sur disque local
	localboot 0

label Linux PXE
  menu label Linux PXE server...
 	kernel pxechain.com
	append 192.168.100.201::pxelinux.0
	# Entrez l'adresse IP du serveur PXE Linux
# append 192.168.100.201::\boot\x86\wdsnbp.com
  	# ou d'un autre serveur WDS "standard"

Label Annuler le boot PXE
	kernel abortpxe.0

A ce stade, le dossier “boot/x86” doit contenir les dossiers/fichiers suivants (surlignés)

Nouveau contenu du dossier .\boot\x86

Pour activer la nouvelle amorce sur le noyau PXE linux, entrez les commandes suivantes dans une invite de commande sur le serveur WDS.

wdsutil /set-server /bootprogram:boot\x64\pxelinux.0 /architecture:x64
wdsutil /set-server /N12bootprogram:boot\x64\pxelinux.0 /architecture:x64
wdsutil /set-server /bootprogram:boot\x64\pxelinux.0 /architecture:x86
wdsutil /set-server /N12bootprogram:boot\x64\pxelinux.0 /architecture:x86

5. Stipuler le fichier de démarrage au niveau des options DHCP

Il ne reste plus qu’à modifier l’option DHCP  stipulant le  fichier d’amorçage. Au niveau de la console du serveur DHCP (sous Windows), développez l’arborescence afin de sélectionner “DHCP … NomDuServeur … IPv4 … Etendue [Nom d’étendue] … Options d’étendue”

Si vous n’avez pas déjà configuré cette option, utilisez le menu “Action … Configurer les options” ou le menu contextuel.  Cochez la case “067  Nom du fichier de démarrage“, puis entrez la valeur “Boot\x86\pxelinux.0” dans le champ “Valeur de chaine“. Dans le cas contraire, éditez simplement l’option existante afin d’en modifier la valeur.

Options d’étendue DHCP (N° 66 et 67)

Pour les accrocs de la ligne de commande, vous pouvez configurer ces options d’étendue sur un DHCP  Windows via les commandes suivantes

netsh dhcp server scope 192.168.100.0 set optionvalue 066 STRING 192.168.100.201
netsh dhcp server scope 192.168.100.0 set optionvalue 067 STRING boot\x86\pxelinux.0

Ou via le module DHCP de Powershell depuis Windows Server 2012

Set-DhcpServerv4OptionValue -ScopeId 192.168.100.0 -OptionId 66 -Value "192.168.100.201"
Set-DhcpServerv4OptionValue -ScopeId 192.168.100.0 -OptionId 67 -Value "boot\x86\pxelinux.0"

C. Test du résultat

À partir d’une machine virtuelle ou physique, démarrer l’ordinateur sur l’amorçage PXE (généralement via [F12]).

Le résultat devrait ressembler à ceci :

Exemple de résultat PXE Linux avec lien vers WDS

Le premier choix aura pour conséquence de poursuivre l’initialisation de l’amorce WDS classique, comme par exemple :

Exemple d’enchaînement vers un menu traditionnel de WDS

Voilà, c’est tout pour cette fois. Si vous avez des questions, des remarques ou même des critiques à formuler sur cet article, n’hésitez pas à utiliser les commentaires : cette démarche d’échange est généralement plutôt constructive.

Bien à vous

Christophe

IV. Annexe : Mon complément sur les mécanismes DHCP et PXE

1. Démarrage du poste client

2. Le BIOS de la carte réseau initialise le processus PXE et envoie une diffusion générale (broadcast DHCP-Discover) avec l’option #60 (Client Class IDentifier) définie sur “PXEClient”

Note : Si cette option est aussi définie au niveau du serveur DHCP, cela indique que le serveur assure également un service PXE. L’usage de l’option #43 (Vendor Specific) est similaire, mais déconseillé en raison de sa complexité de mise en œuvre.

3. La carte réseau obtient une ou plusieurs propositions d’adresse IP (DHCP_Offer) et choisit celle qui répond à l’option #60 ou à défaut celle du DHCP le plus rapide.

4a. Si ces trames de retour contiennent les options DHCP #66 et #67, la carte réseau utilise directement le contenu de ces options pour communiquer avec le serveur PXE.

4b. Si les options DHCP #66 et #67 ne sont pas spécifiées, alors la carte réseau envoie une nouvelle diffusion générale afin trouver un serveur PXE. Si le serveur PXE n’est pas sur le sous-réseau local, un agent relai (ou iphelper) peut transmettre la demande vers autre serveur DHCP/PXE. Une fois le serveur PXE est contacté, il renvoie l’information au client afin que le client puisse communiquer directement avec le serveur PXE.

5. Si le serveur PXE a pu être contacté, il délivre le bootstrap (NBP) au client

6. La carte réseau charge l’image d’amorçage via TFTP à partir du serveur PXE.

I. Présentation

Pour l’installation de la base de données MDT, vous pouvez vous reporter à mon tutoriel sur la gestion des applications. Vous y trouverez une procédure de mise en œuvre d’une base de données MDT.

Il se peut que vous rencontriez quelques difficultés lors de la déclaration de l’instance SQL, avec un symptôme du genre “impossible de trouver l’instance SQL”. Ce phénomène peut être lié au fait que le service “SQL Browser” ne soit pas démarré. Pour y remédier, démarrez le programme “SQL Server Configuration Manager” puis développez l’arborescence “Configuration réseau SQL Server … Protocoles pour SQLEXPRESS” (ou le nom de votre instance installée pour les besoins de MDT). Dans le cadre de droite, vérifiez que le protocole “Canaux nommés” (“Named Pipes“)  est bien activé, conformément au choix de votre configuration MDT.

SQL – Activation des protocoles réseau

Dans le cas contraire, modifiez ce réglage via le menu contextuel ou les propriétés du protocole.

Sélectionnez ensuite le nœud “Services SQL Server” puis accédez aux propriétés du service “SQL Server Browser“. Vérifiez  que le service est bien démarré ou cliquez sur le bouton dans le cas contraire.

Sélectionnez l’onglet “Service” puis choisissez “Automatique” dans le champ “Mode de démarrage“.

Cliquez sur “Appliquer” puis “OK“. À ce stade, la déclaration de votre base de données MDT ne devrait plus poser de problème (du moins, en local…)

Pour votre gouverne, sachez que depuis MDT 2012, il est possible de créer une base de données et l’associer à MDT en ligne de commande Powershell, voici un exemple :

# Importer un module PowerShell
Import-Module "C:\Program Files\Microsoft Deployment Toolkit\Bin\MicrosoftDeploymentToolkit.psd1"
# Créer un nouveau lecteur
New-PSDrive -Name DS002 -PSProvider mdtprovider -Root E:\DeploymentShare
# Créer une base de données
New-MDTDatabase -SQLServer 'WDS-MDT' -Database 'MDT02' -Instance 'SQLExpress' -Path 'DS002:'

Pour afficher les commandes disponibles

Get-Command -Module MicrosoftDeploymentToolkit

Note : Avec MDT2010, le module n’existait pas et il fallait charger l’extension spécifique comme suit : “Add-PSSnapIn Microsoft.BDD.PSSnapIn“

Toutefois, à ma connaissance, il n’existe pas de technique pour configurer en ligne de commande, les règles de gestion de la base de données que nous allons évoquer ci-après. N’hésitez pas à commenter cet article si vous avez une piste à ce sujet. Pour les plus intéressés sur la configuration automatisée de MDT, je vous recommande la lecture de cet article de Rens Hollanders.

II. Rappels – Gestion de la base de données MDT

Pour ceux qui n’auraient jamais eu l’occasion d’utiliser une base de données au sein de MDT, voici quelques éléments de présentation.

A. Présentation

Dans la console MDT, sont regroupées sous la rubrique “Database“, 4 tables (ou plus exactement les vues proposées) suivantes :

Rubrique “Database” du MDT

Ces vues permettent d’afficher les champs principaux sous la forme d’un tableau :

Chaque enregistrement (ou entrée) dispose d’un identifiant unique “ID” logique (ou clé primaire) incrémenté pour chaque nouvel ajout dans la base de données.

La principale vue “Computers” permet de gérer les ordinateurs en leur affectant un identifiant “matériel” unique qui peut être :

B. Rattacher une base existante

Si vous désirez rattacher une base existante, vous pouvez utiliser le menu “Advanced Configuration … Database … New Database” de la console MDT.

Assistant de configuration de la base de données MDT – Réseau

Après avoir renseigné le nom du serveur et de l’instance SQL, cliquez sur le bouton “Next“.

Assistant de configuration de la base de données MDT – Database

Au niveau de la dernière option “Use an existing database that already contains the required tables and views“, sélectionnez la base désirée qui doit apparaitre dans la liste déroulante.

Vous n’avez pas besoin de renseigner la ressource partagée si vous avez installé la base SQL sur le serveur MDT.

Cette directive facultative (SQLShare = ) est censée préciser le dossier partagé sur le serveur SQL. Bien que distinct de la directive “SLshare”, qui désigne la ressource partagée destinée à recevoir les journaux (logs), on peut affecter la même valeur à ces 2 propriétés dès lors que l’instance SQL et le MDT sont sur le même serveur.

Cliquez 2 fois sur le bouton “Next” puis sur “Finish“.

Attention, le fait de raccrocher une base existante à votre MDT, ne met pas à jour le fichier de configuration “CustomSettings.ini”. Pour cela, vous devrez utiliser le menu “Advanced Configuration … Database … Configure Database Rules” de la console MDT l’opération suivante, en ayant préalablement sauvegardé votre fichier de configuration.

Pour configurer les différentes règles de gestion des requêtes, vous pouvez vous reporter à mon tutoriel sur la gestion des applications

C. Créer / Afficher un enregistrement

Pour créer un nouvel enregistrement, sélectionnez la vue désirée, comme par exemple “Computers“, puis cliquez sur le menu “Action … New” ou le menu contextuel.

Ajout d’une nouvel ordinateur dans la base de données MDT

L’adresse MAC doit être saisie avec le séparateur d’octet “:” et les lettres en majuscule. Notez que cette interface ne vérifie pas les doublons. Au besoin, reportez-vous au chapitre “Compléments” ci-après.

Astuce : Vous pouvez remarquer que le champ “description” est optionnel. Toutefois, j’ai personnellement pris l’habitude d’y renseigner le nom de l’ordinateur (OSDComputerName) afin de visualiser directement cette information sans recourir à l’onglet de détail.

Le module Powershell MDTDB présenté plus loin, permet de renseigner une description lors de la création d’une nouvelle entrée “New-MDTComputer” mais présente le défaut de ne pas permettre la modification de ce champ par la suite “Set-MDTComputer”. Au besoin, reportez-vous au chapitre “Compléments” ci-après.

Après avoir saisi les informations requises, vous pouvez cliquer sur le bouton “Appliquer” pour créer l’enregistrement.

Lors de l’ouverture d’un enregistrement, vous disposez de plusieurs onglets, variables selon de type de vue choisi. Pour ne pas trop charger cette présentation, je n’évoquerais que l’onglet “Detail” (de la vue “Computers“).

Sous cet onglet, vous pouvez consulter, et renseigner le cas échéant, toutes les propriétés (variables MDT) de votre choix. Celles-ci sont classées par thèmes mis en exergue par des titres sur fond bleu.

Il y a potentiellement plus de 200 variables disponibles !…

(Get-MDTComputer |get-member -MemberType Properties ).count

En fonction de vos outils d’inventaire logiciels et matériel tel que SCCM, MAPT ou ACT, ou d’outils tiers tels que GLPI, OCS Inventory ou encore de tableaux Excel, le peuplement de la base de données du MDT peut s’avérer rapidement délicate ou fastidieuse.

Il devient donc rapidement évident qu’une technique de gestion de masse s’impose 

III. Gérer la base de données MDT via Powershell

En alliant les capacités intrinsèques de Powershell à des extensions spécifiques (appelée module) vous pouvez bénéficier d’un véritable arsenal de gestion de cette base de données MDT, et envisager rapidement des opérations d’extraction, de modification ou d’import en masse au travers de vos propres scripts.

Le snapin ou module “MicrosoftDeploymentToolkit.psd1” fournit par Microsoft et évoqué précédemment, est manifestement insuffisant pour une gestion des éléments contenus dans une base de données MDT. Heureusement, la communauté Powershell et MDT est très active et vous permet de pallier ces lacunes.

A. Télécharger et installer le module MDTDB

En premier lieu, vous devez télécharger le module spécifique à l’adresse suivante :

http://blogs.technet.com/cfs-file.ashx/__key/communityserver-components-postattachments/00-03-24-15-04/MDTDB.zip

Une fois téléchargée, décompressez l’archive vers un dossier temporaire. Normalement, cette archive ne contient qu’un module Powershell “MDTDB.psm1” et un script d’exemple “MDTDB_Test.ps1“.

Ces fichiers provenant d’un téléchargement Internet, pensez à vérifier les propriétés de ceux-ci  via l’explorateur Windows, puis cliquez sur le bouton “Débloquer” le cas échéant.

Débloquer un fichier téléchargé

Pour respecter les préconisations relatives aux modules, et les retrouver plus facilement, vous pouvez copier ou déplacer le fichier .psm1 vers le dossier “%windir%\System32\WindowsPowerShell\v1.0\Modules\MDTDB”.

Pour vérifier la disponibilité des différents modules dans votre environnement, vous pouvez utiliser la commande Powershell suivante :

($env:PSModulePath).Split(';') |dir | ft name

Vous devriez voir apparaître le module MDTDB dans cette liste.

B. Utilisation du module MDTDB

Ouvrez une console Powershell, en tant qu’Administrateur.

Avant de poursuivre, vous devez vérifier que la stratégie d’exécution autorise l’exécution des scripts qui ne sont pas signés numériquement. Entrez la commande suivante pour autoriser l’exécution locale du module non signé.

Set-ExecutionPolicy RemoteSigned

Entrez la commande suivante afin d’obtenir le liste des modules disponibles.

Get-Module -ListAvailable

Le module “MDTDB” devrait apparaitre dans la liste. Cependant, si vous ne l’avez pas placé à l’endroit indiqué précédemment, vous pouvez également le charger à partir de son emplacement initial, en stipulant son chemin complet.

Bien que facultatif depuis Powershell v3 grâce au chargement automatique des modules, vous devez entrer la commande suivante afin de charger les fonctions dans la session courante.

Import-Module MDTDB

Pour afficher la liste des fonctions apportées par ce module, tapez la commande suivante.

Get-Command -Module MDTDB

Vous pouvez constater que la liste est longue (72 commandes, plus exactement des fonctions) et nous allons porter notre attention uniquement sur les principales fonctions :

La première action primordiale consiste à établir une connexion avec la base de données du serveur MDT en procédant comme suit:

Connect-MDTDatabase –sqlServer WDS-MDT –instance SQLEXPRESS -database MDT01

Si la base contient déjà des ordinateurs référencés, vous pouvez en obtenir la liste via la fonction suivante :

Get-MDTComputer

Comme vous l’avez constaté préalablement, un ordinateur MDT est référencé au sein de la base de données par un ou plusieurs identificateurs distinctifs. La commande précédente permet d’affiner la recherche en stipulant des paramètres suivants :

Comme vous pouvez le constater, chaque enregistrement possède un nombre considérable de variables (~225) retournées sous forme de liste, et de fait difficilement exploitable à l’affichage.

Note : La seule variable positionnée par défaut sur une nouvelle entrée d’ordinateur est “OSInstall = YES“

Pour obtenir un tableau simplifié des ordinateurs référencés dans la base de données, utilisez la commande suivante :

Get-MDTComputer | Format-Table Id, AssetTag, MacAddress, SerialNumber, UUID, OSDComputerName -Autosize

Pour une présentation plus sympathique du résultat sous forme graphique vous pouvez également utiliser la commande suivante:

Get-MDTComputer | select-object -property OSDComputerName, Id, AssetTag, MacAddress, SerialNumber, UUID | sort-object -property OSDComputerName | out-gridview

Pour supprimer une entrée dans la base de données, vous devez connaitre son identifiant et utiliser la commande suivante (où “n” est l’identifiant) :

Remove-MDTComputer -id n

Pour supprimer une entrée dans la base de données, dont vous ne connaissez qu’une propriété telle que le nom, vous pouvez utiliser la commande suivante :

Get-MDTComputer | where { $_.OSDComputerName -match 'Test01' } | Remove-MDTComputer

L’opération de création ou de modification d’une entrée est sensiblement plus délicate. En effet, ces paramètres et leurs valeurs respectives doivent être renseignées au sein d’une table associative (hashtable) symbolisée par ” @ { param1 = valeur1 ;  param2 = valeur2 } “.

Par exemple, pour créer un nouvel enregistrement, tapez la commande suivante :

New-MDTComputer -macAddress '00:00:00:11:22:33' -settings @{ OSInstall='YES' ; OSDComputerName='Test002' }

Note : Cette commande de création nécessite de déclarer au moins une propriété (-settings ) .

Pour Modifier un enregistrement existant, tapez la commande suivante :

Set-MDTComputer -id n -settings @{ OSDComputerName = 'Test003' }

Avant de manipuler efficacement cette base de données, vous devez donc identifier le nom des variables que vous souhaitez exploiter. Vous pouvez obtenir une liste exhaustive des noms de ces variables (ou propriétés) en interrogeant les propriétés d’une entrée existante (n), comme suit :

Get-MDTComputer -id n | Get-Member -MemberType Property | Select-Object Name

Un des nombreux atouts de PowerShell est sa capacité à convertir facilement des résultats vers des formats CSV, HTML, ou XML. Pour générer un fichier directement exploitable par votre tableur favori, il suffit de taper la commande suivante:

Get-MDTComputer | Export-Csv -Path C:\Temp\MyMDT.csv -Delimiter ';'

Réciproquement, si vous souhaitez importer un tableau CSV dans cette base de données, vous devez utiliser la commande “Import-CSV“. Pour décomposer la procédure, tapez les commandes suivantes :

$Machines = Import-CSV -Path C:\Temp\MyMDT.csv -Delimiter ';'

À ce stade la variable “$Machines” contient l’intégralité du fichier CSV et vous pouvez afficher le nombre d’enregistrements comme suit

$Machines.count

Petit piège : J’ignore encore d’où vient ce phénomène, mais lorsqu’il n’y a qu’une seule entrée dans cet objet, la commande “$Machines.count” ne renvoie rien et non “1”, comme on pourrait s’y attendre.

Chaque ligne de ce tableau correspond à un élément où chaque champ est une propriété de celui-ci. Autrement dit, en indiquant le numéro d’index (de 0 à “count-1”) d’un élément suivi du nom de la propriété vous en obtenez la valeur, comme par exemple:

$Machines[0].id $Machines[0].OSDComputerName

À présent, vous pouvez envisager de réaliser une importation de masse. Pour des raisons de simplicité, nous utiliserons le fichier CSV suivant réduit à quelques propriétés (voir fichier d’exemple ci-dessous) :

Nous allons également créer quelques rôles factices, censés correspondre aux séquences de déploiement des différentes images de référence.

New-MDTRole -name 'Poste Fixe W7x64Pro' -settings @{ TaskSequenceID="REF-FIXE01" } 
New-MDTRole -name 'Poste Portable W7x64Ent' -settings @{ TaskSequenceID="REF-PORT01" }
New-MDTRole -name 'Poste Virtuel W7x86Pro' -settings @{ TaskSequenceID="REF-VIRT01" }

Du fait qu’il n’y a aucun contrôle sur la validité des réglages, comme ici “TaskSequenceID“, faites attention aux erreurs de saisie, lors de vos traitements de masse.

Fichier d’exemple “MDTImport.CSV”

Name;Mac;OU;Role
PC-001;00:15:5D:64:33:01;Fixes;Poste Fixe W7x64Pro
PC-002;00:15:5D:64:33:02;Fixes;Poste Fixe W7x64Pro
PC-003;00:15:5D:64:33:03;Fixes;Poste Fixe W7x64Pro
PC-004;00:15:5D:64:33:04;Portables;Poste Portable W7x64Ent
PC-005;00:15:5D:64:33:05;Portables;Poste Portable W7x64Ent
PC-006;00:15:5D:64:33:06;Fixes;Poste Fixe W7x64Pro
PC-007;00:15:5D:64:33:07;Fixes;Poste Fixe W7x64Pro
PC-008;00:15:5D:64:33:08;Fixes;Poste Fixe W7x64Pro 
PC-009;00:15:5D:64:33:09;Fixes;Poste Fixe W7x64Pro
PC-010;00:15:5D:64:33:0A;Virtuels;Poste Virtuel W7x86Pro

Cet exemple ne traite pas la création des unités d’organisation “OU” et le nom du domaine. “ou=Postes,dc=labs,dc=local”

Exemple de script “ImportDB.ps1”

# Saisie du nom du fichier CSV d'import
param ( [string]$Path )

Do {
  if ($Path -eq "" -or -not(Test-Path $Path)) { 
  $Path = Read-Host "Entrez un nom de fichier CSV valide ou rien pour quitter "
  }
  if ($Path -eq "") {exit}
} Until (Test-Path $Path)

$Context = "ou=Postes,dc=labs,dc=local"
$sqlServer = "WDS-MDT"
$instance = "SQLEXPRESS"
$mdtdb = "MDT02"

# Import du module spécialisé MDTDB
Import-Module MDTDB

# Connexion à l'instance de la base de données MDT
Connect-MDTDatabase -sqlServer $sqlServer -instance $instance -database $mdtdb

# Chargement du fichier CSV
$machines = Import-Csv $Path -delimiter ';'

#Boucle de traitement des lignes du fichier CSV
For ($i=1; $i -le $machines.count; $i++)
{
   # Création d'une nouvelle entrée dans la base
   New-MDTComputer -macAddress $machines[$i-1].mac `
		   -description "$($machines[$i-1].name) : Demo Import DB" `
		   -settings @{ OSInstall='YES'; `
				OSDComputerName=$machines[$i-1].name; `
				ComputerName=$machines[$i-1].name; `
				MachineObjectOU="ou=$($machines[$i-1].OU),$Context";
		       	      }

   # Récupération de la clé "Id" de la nouvelle entrée
   $Current = get-mdtcomputer -macAddress $machines[$i-1].mac
   write-host "Création de $($machines[$i-1].name) avec Id: $($Current.id)"

   # Ajout du role (applications) s'il existe
   If ($machines[$i-1].role -ne "") { 
     Set-MDTComputerRole $Current.id $machines[$i-1].role 
     }
}

Dans une session Powershell, à partir du dossier dans lequel vous avez enregistré les 2 exemples précédents, exécutez le script comme suit:

.\ImportDB.ps1 .\MDTImport.csv

Pour vérifier le résultat, vous devez actualiser l’affichage dans la console MDT en sélectionnant la vue “Computers“.

Base de données MDT – Vue “Computers”

Ouvrez l’une des entrées, puis sélectionnez l’onglet “Details“. Vous deviez constater la présence des variables définies par le script.

Détails d’une entrée dans la base de données MDT

Et sous l’onglet “Role“, le rôle correspondant devrait également être présent.

Association d’un rôle dans la base de données MDT

Pour conclure sur cette introduction à l’usage de MDTDB avec Powershell voici 2 petits exemples :

Exemple d’affichage des données renseignées

Get-MDTComputer | % { $_.OSDComputerName, $_.MACAddress, $_.MachineObjectOU, $(Get-MDTComputerRole($_.id)).Role }

Exemple de sortie dans un tableau graphique

Get-MDTComputer | Select *ComputerName, MACAddress | Out-Gridview

Vous pouvez bien évidement adapter cet exemple en stipulant les propriétés de votre choix au niveau de la commande “Select …”.

IV. Utiliser Excel avec la base de données MDT

Si les scripts vous rebutent un peu et que vous disposez d’un tableur tel que Excel, vous pouvez l’utiliser comme interface de la base de données MDT, pour par exemple effectuer des exportations ou des tris.

À partir d’Excel 2010 par exemple, sélectionnez l’onglet “Données” puis cliquez sur “Connexion” … “Provenance : SQL Server”

Entrez ensuite le nom du serveur et l’instance SQL, telle que “wds-mdt/SQLExpress”

Cliquez sur “Suivant“. Sélectionnez votre base MDT dans la liste déroulante.

Choisissez une table telle que “ComputerSettings” correspondant à la table des ordinateurs MDT, puis cliquez sur “Suivant”

Ajoutez une éventuelle description puis cliquez sur “Terminer”

Vous êtes ensuite invité à importer les données dans un classeur Excel.

Pour une simple analyse, conservez le choix “Tableau” puis cliquez sur “OK“. Le tableau fera toutefois plus de 200 colonnes !…

Si vous connaissez un peu le maniement d’Excel, je vous conseille de choisir la seconde option “Rapport de tableau croisé dynamique“, afin de choisir la disposition des informations à analyser.

V. Compléments

À l’usage, vous éprouverez peut-être le besoin d’accéder à la base de données du MDT via des outils personnalisés, ou vos propres scripts. Voici donc quelques exemples pour commencer l’aventure…

A. MDT Administrator

Pour une gestion personnalisée de la base de données MDT, je vous conseille de jeter un œil sur l’outil “MDT Administrator” de Chris W. (Téléchargeable au format .exe ou .hta).

MDT Administrator

Si vous avez mis en place les rôles, comme mentionné dans ce tutoriel, l’usage de cet outil vous paraitra très rapidement évident.

B. Le champ “Description”

Lors de l’usage du module MDTDB précité, vous constaterez que le champ “Description” proposé lors de la création d’un nouvel ordinateur (New-MDTComputer) n’est plus disponible dans les commandes de modification (Set-MDTComputer). Cela est lié au fait que ce champ est stocké dans la table principale des ordinateurs (dbo.ComputerIdentity) référencée par la première commande et non celle des variables associées (dbo.ComputerSettings) sur laquelle agit la seconde commande.

Voici un petit exemple de script Powershell destiné à modifier le champ “Description” d’un ordinateur MDT dont vous connaissez l’identifiant.

Note : J’ai ajouté une petite fonction pour la gestion de la base de données afin que ce script soit indépendant du module MDTDB.

Set-MDTDescription.ps1

Function Invoke-SqlCommand {
param (
    [string]$dataSource,  # = SQLServer\. ou SQLServer\Instance
    [string]$database,
    [string]$sqlCommand = $(throw "Merci de spécifier une requete.")
 )

$connectionString = "Provider=sqloledb; " +
                    "Data Source=$dataSource; " +
                    "Initial Catalog=$database; " +
                    "Integrated Security=SSPI;"

$connection = New-Object System.Data.OleDb.OleDbConnection $connectionString
$command = New-Object System.Data.OleDb.OleDbCommand $sqlCommand,$connection
$connection.Open()

$adapter = New-Object System.Data.OleDb.OleDbDataAdapter $command
$dataset = New-Object System.Data.DataSet
[void]$adapter.Fill($dataSet)
$connection.Close()

$dataSet.Tables # | Select-Object -Expand Rows
}

function Read-Default($text, $defaultValue) { 
  $prompt = Read-Host "$($text) [$($defaultValue)]"; return ($defaultValue,$prompt)[[bool]$prompt]; 
  } 

$SQLServer= "WDS-MDT"
$Instance = "SQLExpress"
$Database = "MDT02"

$ID = Read-Host "Entrez l'identifiant de l'ordinateur MDT"   

  
$MDTComputer = Invoke-SqlCommand -sqlCommand "SELECT * FROM ComputerIdentity `
   WHERE ID = '$ID'" -dataSource "$SQLServer\$Instance" -database "$Database" 
if ($MDTComputer -ne $null) {
  echo $MDTComputer
  
  $NewDescription = Read-Default -text "Modifier ? (Entrée sinon)" -defaultValue "$($MDTComputer.Description)"
  if ($NewDescription -ne $($MDTComputer.Description)) {
     Invoke-SqlCommand -sqlCommand "UPDATE ComputerIdentity SET Description = '$NewDescription'`
       WHERE ID = '$ID'" -dataSource "$SQLServer\$Instance" -database "$Database"
      echo "La description [$NewDescription] a été mise à jour sur l'entrée $ID"
      } else {
      echo "La description [$NewDescription] n'a pas été modifiée sur l'entrée $ID"
      }
   } 
   else {
  echo "Entrée N°$ID inexistante dans la base de données $Database"
}

C. Valider le format d’adresse MAC et son unicité

Voici un autre exemple de script Powershell destiné à valider le format d’une adresse MAC et tester son unicité dans la base de données.

CheckMAC.ps1

Function Invoke-SqlCommand {
param (
    [string]$dataSource,  # = SQLServer\. ou SQLServer\Instance
    [string]$database,
    [string]$sqlCommand = $(throw "Merci de spécifier une requete.")
 )

$connectionString = "Provider=sqloledb; " +
                    "Data Source=$dataSource; " +
                    "Initial Catalog=$database; " +
                    "Integrated Security=SSPI;"

$connection = New-Object System.Data.OleDb.OleDbConnection $connectionString
$command = New-Object System.Data.OleDb.OleDbCommand $sqlCommand,$connection
$connection.Open()

$adapter = New-Object System.Data.OleDb.OleDbDataAdapter $command
$dataset = New-Object System.Data.DataSet
[void]$adapter.Fill($dataSet)
$connection.Close()

$dataSet.Tables # | Select-Object -Expand Rows
}

Function CheckMac {
   param (
       [string]$MACAddress = $(throw "Merci de spécifier une adresse MAC.")
   )  
	$patterns = @(
		'^([0-9a-f]{2}:){5}([0-9a-f]{2})$'
		'^([0-9a-f]{2}-){5}([0-9a-f]{2})$'
		'^([0-9a-f]{4}.){2}([0-9a-f]{4})$'
		'^([0-9a-f]{12})$')
 	if ($MACAddress -match ($patterns -join '|')) {$true} else {
   			Echo "ERREUR: Le format d'adresse MAC specifié est invalide : $MACAddress"
   	return
   	}
  	$Delimiter = ':'
  	$rawAddress = $MacAddress -replace '\W'
  	switch ($Delimiter) {
  		{$_ -match ':|-'}	{    
			if ($MacAddress -match ":")   {
   				$result=$MacAddress
   				Echo "L'adresse MAC $MacAddress est déjà au bon format" 
				}
 			else  {
    			for ($i = 2 ; $i -le 14 ; $i += 3) {
    				$result = $rawAddress = $rawAddress.Insert($i, $_)
					}
    			Echo "L'adresse MAC saisie $MacAddress a été convertie en $result" }
   				break
 			}
  		'.' {  for ($i = 2 ; $i -le 14 ; $i += 3) {
  				$result = $rawAddress = $rawAddress.Insert($i, $_) }
  				Echo "L'adresse MAC saisie $MacAddress a été convertie en $result"
  				break
 			}
		} # End switch
  	$MACAddress=$result.toUpper()
  	$global:MAC = $MACAddress
  	
}


CheckMac(read-host "Entrez l'adresse MAC à vérifier ")


# Vérification d'unicité

    $SQLServer= "WDS-MDT"
 	$Instance = "SQLExpress"
	$Database = "MDT02"
  
	$DuplicateMAC = Invoke-SqlCommand -sqlCommand "SELECT * FROM ComputerIdentity WHERE macAddress `
          = '$MAC'" -dataSource "$SQLServer\$Instance" -database "$Database" 
	
    if ($DuplicateMAC -ne $null){
		Echo "Cette adresse MAC $MAC est déjà assignée ! cf ID N° $($DuplicateMAC.ID)"
		} 
	else {
	    Echo "L'adresse MAC $MAC n'est pas encore assignée." 
	 }

Extraits de mes différents projets, j’ai essayé de rendre ces extraits autonomes, sans m’attarder sur la qualité du code, mais l’idée est bien là et je vous laisse le soin de les adapter à vos besoins.

Bien à vous

I . Présentation

En complément de mes tutoriels sur MDT, je vous propose quelques petits exemples de personnalisation d’une séquence de tache, histoire d’apporter encore un peu de matière à un sujet déjà très fourni.

II . Exemple 1 – Configurer des rôles et/ou des fonctionnalités

A. Avant-propos

Pour apporter des personnalisations sur un système, telles que l’ajout/suppression de fonctionnalités sur un système, vous disposez de plusieurs solutions :

• Effectuer ces personnalisations sur une machine de référence puis capturer une image WIM. Cette technique est peu recommandée pour des raisons évidentes de lourdeur et d’usage d’un processus de fabrication manuel mal encadré.

• Effectuer des modifications dans le fichier “unattend.xml” via l’outil WISM. Bien que meilleure que la précédente, cette technique reste complexe à mettre en œuvre pour des néophytes en raison des contraintes de l’outil et de l’interface.

• Réaliser un script chargé d’exécuter la configuration via des commandes du genre “DISM /online /Enable-Feature …” ou “DISM /online /Disable-Feature” et l’ajouter en tant qu’application MDT

• Ajouter une action personnalisée dans la séquence de tache concernée. C’est cette dernière technique que je vous propose d’explorer:

Il est logique de considérer que l’opération prédéfinie “Install Roles and Features” proposée depuis le MDT2012 est une tache plutôt réservée à la configuration des rôles et/ou des fonctionnalités sur un système Windows de type “serveur”.

En fait, Microsoft a initialement regroupé ces opérations dans ce but, c’est à dire installer des rôles tels qu’un contrôleur de domaine (ADDS), un serveur de nom (DNS) ou bien encore un serveur DHCP, et autres fonctionnalités. Toutefois, si vous regardez de plus près, vous constaterez que cette tache propose une classification incluant les systèmes clients.

B. Mise en œuvre

Pour implémenter cette solution, ouvrez les propriétés de la séquence de tache désirée à partir de la console “Deployment Workbench“, puis sélectionnez l’onglet “Task Sequence“.

Pour l’exemple, on prendra une séquence de déploiement d’un système Windows 7.

Développez l’arborescence des taches afin de sélectionner le groupe “Custom Tasks” situé sous le groupe “State Restore”

Cliquez ensuite sur le bouton “Add … Roles“, puis ajoutez le choix “Install Roles and Features“. Recommencez pour ajouter  ou “Uninstall Roles and Features“.

Vous obtenez donc 2 nouvelles taches, sous lesquelles vous pouvez sélectionner le système d’exploitation concerné, en l’occurrence “Windows 7” et cocher les différentes fonctionnalités.

Il ne vous reste plus sélectionner la tache correspondante à l’activation (Install …) ou la  désactivation (Uninstall …) puis cocher les fonctionnalités de votre choix.

Si vous exécutez cette séquence de tache, les pages seront affichées dans l’assistant.

A noter (Est-ce un bug ?) : Lorsque les pages sont affichées dans l’assistant, bien qu’effectives, les sélections effectuées ne seront pas affichées (toutes les cases apparaissent décochées).

Pour masquer ces écrans, ajoutez la directive “SkipRoles = YES” dans le fichier “CustomSettings.ini” ou la base de données.

III. Exemple 2 – Tester vos applications

Pour tester vos applications ou bundles MDT, avant de les intégrer dans les séquences globales de déploiements, vous pouvez utiliser une petite technique simple, en procédant comme suit.

Après avoir déclaré vos applications dans le MDT, au niveau de la console “Deployment Workbench“, créez simplement une nouvelle séquence de tache via le menu “New Task Sequence” puis entrez un identifiant et un nom de votre choix.

Cliquez sur “Next“,

Sélectionnez “Custom Task Sequence” dans la liste déroulante, puis cliquez 2 fois sur “Next” puis sur “Finish“.

Afin d’illustrer cet exemple, sélectionnez cette nouvelle séquence de tache puis utilisez le menu “Propriétés” et sélectionnez l’onglet “Task Sequence“.

Vous pouvez constater qu’une action “Install Application” est déjà présente et que par défaut, cette opération propose “Install multiple applications“. Autrement dit, toutes les applications déclarées dans le MDT seront proposées.

Cliquez sur le bouton “Annuler“.

Sur votre machine de test, si votre compte de session dispose des droits suffisants, tapez la commande suivante :

\\WDS-MDT\DeploymentShare$\Scripts\LiteTouch.vbs /SkipTaskSequence:YES /TaskSequenceID:T001

Vous devez bien sûr adapter cet exemple avec vos propres informations, et au besoin créer un petit script suivant pour éviter de saisir ces commandes à chaque essai.

Notepad TestAMDT.cmd

Net use Z: \\WDS-MDT\DeploymentShare$ /user:LABO\DeplAccount Pa$$w0rd

Z:\Scripts\LiteTouch.vbs /SkipTaskSequence:YES /TaskSequenceID:T001

Ce script facultatif est destiné à relancer le processus de test car la connexion au lecteur réseau est supprimée après chaque exécution de la tâche.

La suite dépend de vos préférences déclarées dans les fichiers de configuration. Reportez-vous à mes tutoriels sur MDT pour plus d’information sur le sujet. En gros, si vous avez positionné la directive “SkipBDDWelcome=YES“, avec les identifiants de connexion dans le “bootstrap.ini” et ajouté les directives “SkipComputerName=YES” et “SkipDomainMembership=YES” dans la section “[Default]” de “customsettings.ini“, vous arriverez directement sur la page suivante :

Vous n’avez plus qu’à cocher les applications dont vous souhaitez tester l’installation.

IV. Exemple 3 – Taches conditionnelles

Afin d’explorer un peu plus le séquenceur MDT, je vous propose un autre exemple, destiné à présenter les notions de conditions et par la même occasion démontrer l’intérêt des “groupes” que l’on peut définir au sein des séquences de taches.

A. Principes d’un groupe de taches :

Chaque tache peut disposer de ces propres conditions mais cela peut rapidement nuire à la lisibilité de l’ensemble. La démonstration que j’expose ici est plutôt une bonne pratique sans toutefois être une obligation systématique.

L’intérêt premier d’un groupe est bien évidement de regrouper plusieurs de taches élémentaires dans une thématique donnée mais également d’ajouter éventuellement des conditions d’exécution sur cet ensemble de taches.

Lorsque vous sélectionnez un groupe, au même titre que pour une tache, le MDT vous propose un onglet “Option” permettant de :Désactiver cette étape (“Disable this step“) – C’est-à-dire, n’exécuter aucune des taches qu’il contient

• Continuer en cas d’erreur (“Continue on error“) – C’est-à-dire, poursuivre l’exécution des tâches suivantes même si une erreur survient.
  
• Ajouter des conditions comme suit :
  • “If statement” – Permet de déterminer un ou plusieurs niveaux d’imbrication des conditions afin de créer des tests complexes.

• • “Task Sequence Variable” – Permet de tester la valeur d’un variable d’environnement MDT

• • “Operating System Version” – Permet de tester la version et l’architecture du système d’exploitation

• • “Query WMI” – Permet de définir une requête WMI en langage WQL (à l’instar de filtre WMI de GPO) – La condition est considérée comme “vraie” (“true”) dès lors que le résultat renvoyé n’est pas vide

• • “Registry Setting” – Permet de tester la présence, l’absence ou la valeur d’une clé de registre.

• • “Installed Software” – Permet de tester si un package d’application fait partie des produits déjà installé.

Vous pouvez utiliser le bouton “Browse” pour sélectionner le package .MSI de l’application et ainsi obtenir ces caractéristiques.

• • “Folder Properties” – Permet de tester la présence d’un dossier et éventuellement contrôler sa date de création.

• • “File Properties” – Permet de tester la présence d’un fichier et éventuellement contrôler sa version et/ou sa date de création.

B. Mise en œuvre des taches conditionnelles

Imaginons maintenant que l’on souhaite déployer Windows 7, à partir d’une seule  séquence de taches sur un ensemble machines physiques et virtuelles, il peut être intéressant de les distinguer. Pour ce cas typique, MDT propose plusieurs variables prédéfinies susceptibles de répondre à vos attentes :

Maintenant, si notre souhait est d’installer les compléments de machine virtuelle selon la plateforme de virtualisation, l’usage de la dernière variable suffira.

1. Ajouter les applications (outils) propres à chaque environnement virtuel

Dans la vraie vie   , il faudrait commencer par récupérer les différents compléments et les ajouter en tant qu’application. Dans les grandes lignes, il vous faut récupérer les fichiers .iso des machines invitées (guest), généralement situés dans les dossiers de l’hôte de virtualisation et trouver la commande d’installation  silencieuse

Plateforme	ISO Guest	Exemple d’installation silencieuse
Hyper-V	Vmguest.iso	“%~dp0x86\setup” /quiet /norestart”%~dp0amd64\setup” /quiet /norestart
VirtualBox	VBoxGuestAdditions.iso	“%~dp0VBoxWindowsAdditions” /S
VMware	Windows.iso	“%~dp0\setup” /s /v/qb
Xen	?	Votre serviteur n’a malheureusement trop peu d’expérience sur ce produit mais le principe reste le même.

Ces opérations étant relativement longues et complexes à décrire, nous utiliserons des applications factices pour cette démonstration.

Nous allons donc utiliser de simple scripts vbs destinés signaler et suspendre la séquence. Pour faire au plus simple, je vous propose de créer, les 4 scripts suivants puis de les enregistrer dans un dossier temporaire spécifique, tel que “C:\Temp\Outils Platform”, ainsi q’un nom distinctif tel que “DisplayPlatform.vbs”.

DisplayVMware.vbs

wscript.echo "Installation des outils de machine virtuelle" & vbCrLf & "Plateforme : VMware"

DisplayHyperV.vbs

wscript.echo "Installation des outils de machine virtuelle" & vbCrLf & "Plateforme : Hyper-V"

DisplayVBox.vbs

wscript.echo "Installation des outils de machine virtuelle" & vbCrLf & "Plateforme : VirtualBox"

DisplayXen.vbs

wscript.echo "Installation des outils de machine virtuelle" & vbCrLf & "Plateforme : Xen Server"

A partir de la console “Deployment Workbench“, sélectionnez la rubrique “Applications” puis cliquez sur “New Folder” et renseignez un nom de dossier tel que ” Virtual Tools” et cliquez sur “OK“.

Note : Bien que dans cet exemple, nous n’ayons besoin que d’une simple application pour chaque environnement, il est conseillé de créer des bundle ou “coquille vide” afin d’y associer le ou les applications dans un second temps. Cette technique est plus lourde à mettre en place mais à l’instar des groupes, permet une meilleure organisation  et gestion sur le long terme.

Sélectionnez ce nouveau dossier puis cliquez sur “New Application“,  puis conservez l’option “Application with source files” et cliquez sur “Next“.

Entrez un nom tel que “VMware Tools” dans le champ “Application Name” puis cliquez sur “Next“. Cliquez sur le bouton “Browse” afin de sélectionner l’un des scripts précédemment créés.

Copie ou deplacement des sources de l’application fictive

Le chemin du dossier de l’application fictive doit ensuite s’afficher au niveau champ “Source Directory“. Cochez éventuellement la case “Move the files to the deployment share instead of copying them” puis cliquez 2 fois sur “Next“.

Dans le champ “Command line” entrez la commande d’installation correspondante, comme par exemple “wscript DisplayVMware.vbs”

Commande d’installation de l’application

Cliquez ensuite 2 fois sur “Next” et enfin sur “Finish“.

Recommencez ces opérations pour chacune des plateformes virtuelles supportées.

Contenu du dossier “Virtual Tools” sous “Applications”

2. Ajouter des groupes à la séquence de tache

Accédez aux propriétés de votre séquence de tache de déploiement de Windows 7, puis créez un nouveau groupe “Virtual Tools” sous le groupe “State Restore“. Utilisez les boutons flèches “Up” / “Down” pour positionner le bon ordre, comme par exemple, juste après “Custom Task“.

Créez ensuite un nouveau “sous-groupe ” pour chacune des plateformes désirées, comme par exemple “Hyper-V”, “VMware”, “XenServer”,”VirtualBox”.

Groupes de plateforme (Séquence de taches)

Facultatif : Si vous ne souhaitez pas modifier votre séquence d’installation existante, vous pouvez créer une nouvelle séquence de taches, (cf Exemple 2) en choisissant “Custom Task Sequence”, afin de tester individuellement ces applications sur chaque plateforme, déjà installée. Si les tests sont concluants, vous pourrez copier/coller cet ensemble dans la séquence d’installation existante.

Séquence de taches dédiée aux tests

3. Ajouter des conditions sur les groupes

Sélectionnez ensuite chacun des groupes de plateforme, et l’onglet “Option” correspondant afin d’ajouter la condition comme suit :

Cliquez sur “Add … Task Sequence Variable” puis indiquez la variable “VMPlatform“, sélectionnez l’opérateur de condition “equals” et enfin la valeur correspondante au sous-groupe concerné, soit “Hyper-V“, “VMware“, “Xen” ou “VirtualBox“.

Cliquez sur “OK” pour valider l’entrée. En cas d’erreur de saisie, vous pouvez revenir sur le réglage en utilisant le bouton “Edit“.

Recommencez l’opération pour chacun des  groupes de plateforme.

4. Ajouter les taches spécifiques à chaque groupe

Sélectionnez un groupe de plateforme, puis cliquez sur le bouton général “Add … General … Install Application”

Sous l’onglet “Properties” de cette nouvelle tâche “Install Application“, sélectionnez l’option “Install a single application” puis cliquez sur le bouton “Browse” afin de sélectionner l’application désirée.

Cliquez sur “OK” pour valider ce choix.

Réitérez cette opération pour chacun des  groupes de plateforme, puis cliquez sur “Appliquer” / “OK” pour valider la séquence de tache.

Si vous avez  créé une séquence dédiée (cf remarque facultative), rendez-vous sur l’une de vos machines virtuelles, puis exécutez le script “LiteTouch.vbs” de votre MDT, et choisissez cette séquence de test.

Séquence de taches pour test unitaire

Cliquez sur les boutons “Next” puis “Begin“. Vous devriez voir l’affichage suivant, correspondant au script de l’application correspondante à la plateforme concernée.

Résultat sur une VM Hyper-V

Cliquez sur le bouton “OK” de la boite de dialogue du script. La séquence devrait s’achever sans erreur et ignorer ainsi les actions relatives aux autres plateformes virtuelles. De la même manière, si vous exécutez cette séquence sur un poste physique, aucune des taches conditionnelles aux  plateformes virtuelles ne sera traitée.

Autre exemple de résultat dans une VM sous VMware

V. Exemple 4 – Gestion des clés produits

A. Rappel sur les groupes d’une séquence par défaut

Pour bien comprendre ce mécanisme des dossiers “conditionnel”, je vous invite à explorer une séquence de tache typique “Standard Client Task Sequence” et les conditions appliquées à chacun d’entre eux. L’analyse du premier niveau suffit amplement :

En sélectionnant successivement chacun des groupes de premier niveau et en observant l’onglet “Option” dans le volet de détail, vous pourrez relever les informations suivantes :

Vous l’aurez compris, à l’exception du premier groupe de taches qui est donc exécuté dans tous les cas, les autres taches s’exécutent en fonction de la phase d’avancement du déploiement.

B. Ajout des différentes clés par défaut

Vous avez probablement constaté qu’en l’absence de clé produit, l’installation d’un système Windows demande une intervention humaine, pour saisir la clé ou simplement l’ignorer et poursuivre le processus.

Là encore, on pourrait considérer plusieurs palliatifs possibles :

• Injecter la clé dans l’image WIM via une commande “DISM /Set-ProductKey”

• Injecter la clé via un script ou une application du genre “cscript /b c:\windows\system32\slmgr.vbs /ipk AAAAA-BBBBB-CCCCC-DDDDD-EEEEE-FFFFF”

• Modifier le fichier “unattend.xml” via WSIM dans le composant [<component name=”Microsoft-Windows-Shell-Setup”]

• Si l’on dispose d’une base de données, il est possible de renseigner la propriété “ProductKey” dans la (pour chaque ordinateur) ou plus simplement au niveau d’un “role” dédié au déploiement d’un système.

• L’ajout de la directive ”ProductKey = ” au sein du fichier “CustomSettings.ini” n’est pas adaptée à des déploiements de systèmes différents.

• La solution la plus simple, est certainement de valoriser la propriété “ProductKey” dans la séquence de tache chargée du déploiement d’un système.

Pour cela, ouvrez la console “Deployment Workbench“, sélectionnez votre séquence de tache chargée du déploiement d’un système au niveau de la rubrique “Task Sequences“. Utilisez ensuite le menu “Propriétés” puis sélectionnez l’onglet “Task Sequence“.

Sélectionnez le groupe “Initialization” puis le menu “Add … General … Set Task Sequence Variable“.

Note : Ne vous inquiétez-pas, la nouvelle tâche est affichée avec une icône rouge tant que vous n’aurez pas validé les changements et rafraîchi l’affichage.

Entrez dans le champ “Name” une description telle que “Set Default KMS Product Key” pour identifier la tâche.

Entrez la valeur “ProductKey” dans le champ “Task Sequence Variable” et la clé produit dans le champ “Value“.

Cliquez sur “Appliquer” puis sélectionnez de nouveau le groupe “Initialization” pour actualiser la tâche qui devrait apparaitre en vert.

Cliquez sur “OK” pour fermer la séquence de taches.

Il ne vous reste plus qu’à ajouter la directive “SkipProductKey=YES” au sein du fichier “CustomSettings.ini“.

Pour plus d’information sur la modification du fichier “CustomSettings.ini” et les clés KMS par défaut reportez-vous au tutoriel  “Configuration avancée de MDT 2013”

Bonne découverte

I. Présentation

Avec Windows 10, Microsoft assène un sérieux coup aux techniques de déploiement et de mise à jour de son système. L’idée de fond, n’est pas moins que le « zero-master » QU’ES ACO ? En gros, le technicien de déploiement devient une espèce en voie d’extinction !… Comment ? Eh bien, le deal est approximativement le suivant : L’utilisateur se procure un appareil quelconque (pré-équipé de Windows 10 bien sûr), et il doit être en mesure d’achever tout seul sa mise à jour et la configuration de son système (comme disent les anglo-saxons : « User Friendly » ).

Par quel moyen ? : Eh bien soit via une simple clé USB, ou un média amovible (Technique FFU – Full Flash Upgrade), soit au travers d’une jonction à un domaine (direct ou Azure AD) afin qu’il reçoive en retour un package de configuration type pour que son appareil intègre son organisation d’entreprise) Waouh – rien que ça !

Avant toute chose, notez que depuis Windows 10, Microsoft supporte pleinement la mise à jour sur place d’un système, contrairement aux versions antérieures où cette pratique était déconseillée en raison des pollutions et des disparités engendrées.

Nous allons aborder dans cet article, le nouveau concept des « packages de mise en service », dont le but est de simplifier les opérations de préparation et de configuration des « appareils » (pour ne pas dire PC/tablettes/téléphones) à l’échelle d’une entreprise, sans que cette installation ne requière de compétence particulière. Cette nouvelle possibilité d’installation est dénommée « Provisioning » .

Schématiquement on peut considérer que dorénavant vous avez le choix entre 3 techniques de déploiement:

-L’installation traditionnelle via une image WIM (Wipe And Load)
-La migration sur place d’un système Windows 7 et ultérieur (In-Place)
-Le provisionnement qui consiste à transformer un appareil en poste d’entreprise (Provisioning)

Scénarios de déploiement Windows 10

II. Analyse des nouveautés liées au déploiement

A. Aperçu rapide des évolutions

1. Nouveau format .ESD

Principalement destiné à délivrer des images Windows 10 à grande échelle via Internet, ce format de fichier .ESD est en fait une déclinaison compressée et chiffrée des célèbres images .WIM.

Vous trouverez d’ailleurs ces fichiers dans le dossier « \Sources » des distributions de Windows 10 obtenues via Internet, en lieu et place des anciens fichiers « Install.wim » . Ce qui pose quelques difficultés pour la suite, si vous avez récupéré une version PRO via Internet (Windows Update ou Media Creation Tool) , donc, si vous souhaitez jouer un peu avec l’outillage de déploiement présenté ci-après, je vous invite à télécharger la version d’évaluation de « Windows 10 Enterprise » pleinement compatible avec des démonstrations. Une inscription est toutefois requise.

Notez qu’il existe un moyen de déchiffrer des fichiers .ESD afin de les convertir au fomat .WIM standard mais je ne suis pas persuadé que Microsoft approuve cette méthode… Vous trouverez l’outil esd-decrypter-v4c.7z ici ou encore un convertisseur de format, disponible ici.

2. WinPE

Je n’ai pas relevé de modification majeure en matière d’outillage pour ce nouveau noyau. La version de ce nouveau WinPE est « 10.0.10240.16384« . Il semble que les versions de WinPE convergent enfin avec celles du système dont il est issu . Vous pouvez vous en assurer en consultant la valeur » Version » du registre située sous la clé « HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinPE »

Note : J’ai relevé une petite curiosité : Sous la clé « HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion » la valeur de donnée « CurrentVersion » est « 6.3 » (soit le niveau technique de W8.1 et pas 6.4 comme on aurait peu s’y attendre) – Etonnant, non ?

3. ADK 10

Le kit ADK 10 est disponible en téléchargement ici : ADK 10

Windows ADK10 inclut désormais un nouvel outil dénommé « Windows ICD » soit « Windows Imaging and Configuration Designer », qui pour la version française a été traduit par « Concepteur de fonctions d’acquisition d’images et de configurations (ICD) » .

Les packages de mise en service pour Windows 10 portent l’extension .PPKG et se comportent un peu comme les fichiers de réponse unattend.xml. A l’instar des images .WIM vous pouvez utiliser l’outil DISM ou 7-zip pour en visualiser le contenu.

Remarque : Le kit de migration, alias USMT a également évolué et son outil « Scanstate » permet dorénavant de sauvegarder l’état des applications installées sur un poste Windows 10 vers un package de mise en service.

Le package de mise en service avec applications ainsi obtenu peut être ensuite importé dans Windows ICD afin de créer un média.

4. MDT2013 Update1

En pratique, hormis les certaines corrections de bugs, c’est la copie conforme de MDT2013, sauf que cette version supporte officiellement Windows 10 et requiert l’ADK10. Mais je reviendrais ultérieurement sur ce sujet dans un article dédié, pour vous présenter quelques nouvelles facultés intéressantes. Dans l’immédiat, dans cet article, c’est plutôt la solution ICD qui sera mise en lumière.

Le MDT 2013 Update1 (Microsoft Deployement Toolkit) est disponible ici – La version précise est 6.3.8298.1000. Si cela vous interresse, je vous propose de consulter mon exemple de migration de Windows 7 vers Windows 10 via MDT.

5. MDT2013 Update2

Au grès de évolutions de ce fameux kit MDT, la logique de version retenue par les équipes Mircosoft est manifestement déroutante, ou pour le moins étonnante. En effet, alors que MDT2013 marquait la fin du support Windows XP/2003, on aurait pu s’attendre à un MDT »2015″ mais c’est une version MDT2013 Update 1 qui apporta le support officiel de Windows 10. La nouvelle version MDT2013 Update 2 est en fait une simple mise à jour qui ne comporte que très peu de nouveautés fonctionnelles. Cette liste non exhaustive vous donnera une petite idée:

• Intégration des derniers binaires du séquenceur « Configuration Manager »
• Amélioration sensible des séquences de taches relatives à la mise à niveau vers Windows 10
• Meilleure gestion des fichiers WIM fractionnés (split)
• Amélioration du niveau de détail dans les journaux, tels que smsts.log
• Meilleure gestion des autorisations NTFS sur le partage de déploiement
• Evolution de la cryptographie avec le support de l’algorithme de hachage SHA256
• Intègre la surveillance des séquences de mises à niveau dans la rubrique « Monitoring »
• Correction de bugs …

Le MDT 2013 Update2 est disponible ici – La version précise est 6.3.8330.1000

Précision / Astuce : Si vous êtes un peu perdu et souhaitez connaitre/vérifier  la version MDT utilisée sur l’un des vos partages de déploiement, (DeploymentShare), sachez qu’il suffit d’ouvrir le fichier « \Control\Version.xml » situé dans le dossier partagé. Pour rappel :
– 5.0.1641.0 = MDT2010
– 5.1.1642.01 = MDT2010 Update1
– 6.0.2223.0 = MDT2012
– 6.1.2373.0 = MDT2012 Update1
– 6.2.5019.0 = MDT2013
– 6.3.8298.1000 = MDT2013 Update1
– 6.3.8330.1000 = MDT2013 Update2

Donc pour le nom et la version de MDT qui supportera la future mouture de Windows 10 Server, les paris restent ouverts

6. Autres outils (Non Microsoft)

Bien que ceci n’est pas de lien direct avec la sortie récente de Windows 10, notez la disponibilité de quelques produits « adaptés » en version graphique ….

• GeneratorWinPE est disponible ici :

• Pour une présentation détaillée de GeneratorWinPE
• L’outil DISM_64bits_Mount-Unmount est disponible sur ce lien : DISM Mount-Unmount

Attention : Ces outils nécessitent la présence du Framework .NET 3.5 (Non inclus par défaut sur W8/2012 et ultérieurs) – cf Mon article

B. Installation de l’ADK

Le principe est très similaire à la version précédente, à la différence que vous disposez de quelques outils supplémentaires :

Parmi les plus flagrantes :

– Concepteur de fonctions d’acquisition d’images et de configurations (ICD)
– Kit d’évaluation de Windows (sous-ensemble de Windows Performance Toolkit)

C. Présentation de Windows ICD

Objectifs de Windows ICD :

– Créez un package de mise en service que vous pouvez utiliser pour personnaliser des PC/tablettes/téléphones sans avoir à recréer des images.

– Générez une image Windows personnalisée pour des régions et des segments de marché spécifiques

L’outil icd.exe est également utilisable en ligne de commande. Pour plus d’information vous pouvez consulter le lien suivant : icd.exe

Exemple de syntaxe :

ICD.exe /Build-ImageFromWIM /MediaPath:<path_to_media_folder> /SourceImage:<path_to_image>
{[ImageIndex:<index>] | [ImageName:<name>]} [/ProvisioningPackage:<path_to_ppkg>]
[/CustomizationXML:<path_to_xml> /DeploymentConfigXML:<path_to_xml>

Lors du premier lancement de l’outil en mode graphique (icd.exe sans paramètre), celui-ci se veut sobre et épuré.

On distingue donc un simple menu « Fichier » pour, ouvrir, enregistrer, fermer ou créer un nouveau « projet« (*) et un menu « Déployer » avec 2 choix « Sur un appareil connecté USB » ou « Sur un lecteur amovible »

(*) Un projet peut être mémorisé au sein d’un fichier qui porte l’extension « .icdprog.xml » et se décline en 2 grandes variantes: Soit au travers d’un « package de mise en service » dont l’objectif est plutôt d’effectuer la mise à jour sur place d’un système, soit la « personnalisation d’une image système Windows », c’est-à-dire la modification d’une image .WIM sur laquelle un « package de mise en service » peut également être appliqué.

Ainsi qu’un onglet « Page de démarrage » donnant l’accès à 3 « gros boutons » pour respectivement :

– Créer un « Nouveau package de mise en service » (=d’approvisionnement)
– Créer une « Nouvelle personnalisation d’image système Windows »
– « Ouvrir » un projet existant

Un bouton « Créer »

Note : Vous constaterez que la version française de l’outil actuel souffre de quelques erreurs ou omissions en matière de traduction.

Dans les grandes lignes, on peut considérer qu’un « package de mise en service » porte l’extension « .ppkg » et peut être appliqué durant la phase de déploiement ou sur un système déjà installé. (via un double-clic sur le fichier). Ces packages sont comparables à une déclinaison plus élaborée des fichiers de réponse utilisés par les processus de préparation et de déploiement des images Windows NT6.

Vue d’ensemble et premier contact avec l’interface ICD

Vous pouvez donc travailler sur une image WIM (offline) ou sur un système Windows 10 déjà installé (Nécessite l’installation du kit)

Il est alors proposé de lui ajouter un package existant de mise en service, mais cette opération reste facultative.

Après le « chargement des paramètres » (propres à l’image choisie) vous aurez accès à plusieurs personnalisations possibles, regroupées selon 3 thématiques :

Par défaut, tous les paramètres sont affichés, et ils sont très nombreux. Vous avez la possibilité d’éclaircir très nettement cet affichage en sélectionnant l’une des options « Paramètres OEM courants » ou « Paramètres IT Pro courants ».

Détail des 3 thématiques:

– Ressources de déploiement (Asset Deployment) – On retrouve ici toutes les ressources applicatives, pack de langues, mises à jour et autres pilotes (un peu comme dans les dossiers Applications, Packages et OutOfBox Drivers du MDT)

– Paramètres d’heure d’image (Image Time Settings) – Ici sont rangés les nombreuses possibilités de personnalisation à l’instar de ce que l’on pouvait trouver au sein des objets de configuration de l’outil WSIM et les fichiers de réponse engendrés.

– Paramètres d’exécution (Runtime Settings)

Comme vous pouvez le constater, les thèmes sont nombreux et certains choix sont particulièrement fournis en réglages.

Je n’ai pas encore achevé mon tour d’horizon de cet outil dont les déclinaisons d’usage sont très variables. Toutefois, je compte vous proposer une série d’exemples concrets dès que j’en aurais l’occasion.

La documentation officielle d’ICD est ici, mais accrochez-vous, c’est plutôt bien chargé

En résumé, Windows 10 et les outils de déploiement s’inscrivent dans la suite logique des systèmes NT6, en y ajoutant une simplicité relative face à des scénarios complexes.

A la prochaine.

Christophe

I. Présentation

Avec Windows 10, l’opération de « mise à jour sur place » doit être réalisée à partir d’un poste Windows 7 ou ultérieur, en version Pro, Intégrale ou Entreprise, 32 ou 64 bits.

Contrairement aux versions antérieures, pour lesquelles le MDT devait utiliser, avec plus ou moins de succès, un scénario de type « Refresh » étayé par l’outil USMT (User State Migration Tool), dorénavant Windows 10 nous simplifie grandement la tâche, en réalisant une mise à jour « sur place » et cette opération est surtout beaucoup plus rapide.

En fait, dorénavant vous pouvez envisager 3 scénarios possibles pour passer à Windows 10

– Traditionnel : C’est ce que l’on obtient par le désormais classique « Refresh » consistant à utiliser une image WIM (ou autre) de Windows 10 et USMT pour la sauvegarde/restauration des données et paramètres d’utilisateurs.

– Provisionning : Cette nouvelle technique consiste à passer par un fichier de configuration ou package de mise en service (cf Windows ICD) qui permet de reconfigurer / transposer un ordinateur déjà installé avec une image constructeur.

– In-Place : Bien que connu par le passé, ce scénario désormais « pleinement supporté » est basé sur la mise à jour du système Windows existant – Un peu comme s’il s’agissait d’un gros service pack. Ce procédé permet de conserver la totalité des données d’utilisateurs ainsi que les applications, tout en préservant l’éventuelle appartenance à un domaine.

Pour déclencher la migration, il vous sera nécessaire, à partir d’un compte d’administrateur, de déclencher directement la séquence de tache correspondante, à partir du fameux script que vous devez à présent connaitre.

\\MDT-WDS\DeploymentShare$\Scripts\LiteTouch.vbs

Concernant les postes activés via des licences KMS, si le serveur en ligne, le poste devrait automatiquement récupérer une nouvelle clé une fois migré vers Windows 10. Pour les autres, il faudra être plus vigilant. En fait, la migration « gratuite » offerte par Microsoft durant un an, doit permettre l’activation de Windows 10 au même titre que le système migré (7 ou 8/8.1) mais la réinstallation ne sera possible que sur le même poste. De ce que j’ai compris, Microsoft conserve les informations de ces migrations sur un matériel donné, sur lequel une version antérieure de Windows était activée, ce qui doit (en théorie) permettre une réinstallation native de Windows 10 sans passer par la case de saisie d’une nouvelle clé.

Je pense que cela s’applique à toutes les licences de type unitaire « Retail », et peut être à celles en volume dénommées « MAK ». Pour les licences fabricants « OEM_SLP », il faudra obtenir une nouvelle clé auprès de ce dernier (opérations promotionnelles). Cette information n’est toutefois pas une affirmation et reste à consolider avec l’expérience….

Dans tous les cas, l’installation ne sera pas bloquée et vous disposerez toujours d’une période de grâce pour l’activation. Rappelez-vous, pour connaitre le statut actuel de la licence, utilisez l’outil « slmgr.vbs »

II. Création de votre séquence de tache de migration

Nous allons donc prendre l’exemple d’une migration d’un système Windows 7 Pro, opérationnel, vers Windows 10 via une séquence de tache MDT. Pour cela, commencez par installez le kit ADK10 (L’outil USMT n’est pas nécessaire pour cette démonstration) et le Microsoft Deployment Toolkit (MDT) 2013 Update 1 (soit la version 6.3.8298.1000).

Je considère que vous avez effectué les opérations habituelles d’ajout de pilotes, applications, et que vous avez ajouté une image WIM de Windows 10 (de Microsoft). N’oubliez pas de faire une copie de sauvegarde de votre structure MDT si vous utilisez un partage de déploiement antérieur. Par précaution, nous utiliserons un nouveau partage de déploiement.

Dans la console MDT, créez une nouvelle séquence de tache, en choisissant le nouveau modèle (Template) : « Standard Client Upgrade Task Sequence »

Une fois la séquence de taches crée, allez dans les « Propriétés » puis sélectionnez l’onglet « Task Sequence » . Sous le groupe de taches « Upgrade the Operating System » , une tache « Upgrade Windows » devrait être présente.

Aucune option particulière n’est positionnée par défaut. Il est toutefois possible de solliciter Windows Update durant l’exécution du programme d’installation, mais la case n’est par cochée par défaut.

Vous pouvez également remarquer la présence d’un sous-groupe de taches « Capture Setup Failures » , conditionné sur la valeur de la clé de registre :

HKLM:\Software\Microsoft\Windows NT\CurrentVersion\Windows\Win10UpgradeStatusCode = FAILURE

Ce sous-groupe contient une tache unique, destinée à annuler l’installation par un retour arrière en cas d’échec de la mise à jour.

Note : On retrouve cette même action au niveau du groupe « Rollback » situé à la fin de la séquence.

Fermez la séquence de taches.

III. Test et démonstration

Prenons maintenant le poste de test sous Windows 7 Pro x64 sp1, 2Go de RAM, membre d’un domaine, quelques applications installées et licence activée.

Au besoin, lancez « slui.exe » et/ou « slmgr -xpr » pour vérifier l’état de licence

En effet, si vous exécutez cette tâche à partir d’un Windows non activé, vous obtiendrez l’erreur suivante (dans le fichier C:\MININT\SMSOSD\OSDLOGS\BDD.log) :

« LTIApply returns non-zero code -2147024809 0x80070057 »

Remarque : Préalablement à la mise à jour, il est souhaitable :

– D’utiliser une image d’origine Microsoft et non une image personnalisée
– De désactiver le chiffrement de disque s’il est actif.
– De désinstaller l’antivirus (ou vérifier sa compatibilité avec Windows 10)

Vous devez donc ouvrir une session avec un compte d’administrateur puis connecter un lecteur réseau vers votre serveur MDT, comme par exemple « net use Z: \\wds-mdt\DeploymentShare /user:wds-mdt\depl Pa$$w0rd » .

Exécutez ensuite le script LTI comme suit « Z:\Scripts\LiteTouch.vbs » . Passez les différents écrans selon votre configuration, jusqu’au choix des séquences de tâches.

Sélectionnez la tache de mise à jour, puis cliquez sur « Next » sur les écrans suivants et enfin « Begin ». Si les prérequis sont respectés, la tâche « Upgrade Windows » devrait s’exécuter.

Et c’est parti (pour de longues minutes) !… On vous propose même de vous caler dans votre fauteuil et de vous détendre, ils sont bien urbains chez Microsoft, non ?

Après plusieurs redémarrages, l’installation s’achève et nous voici en présence d’un joli Windows 10, toujours membre du domaine….

On ouvre la session…. Et après la phase de préparation de l’environnement, on retrouve bien nos applications et nos données.

En revanche, pour cet exemple la clé de licence est perdue et l’ordinateur est passé en mode « notification ».

Comme je vous le disais en amont de cet article, le processus n’est pas bloqué et selon l’origine de la distribution Windows 10, vous disposez de plusieurs « cartouches de réarmement » (via « slmgr -rearm »), ce qui laisse généralement le temps de voir venir.

Toutefois, si vous avez une licence Windows 10 sous la main, vous pouvez la renseigner avec par exemple « slui.exe« :

A. Nettoyage Post-Installation

Si vous décidez de conserver Windows 10, n’oubliez pas de faire le ménage,. C’est-à-dire supprimer le dossier « Windows.old » et les dossiers « Windows.~BT », « Windows.~WS ». Pour éviter des erreurs via l’explorateur Windows, n’hésitez pas à utiliser l’outil de « Nettoyage de disque » , (cleanmgr.exe) en tant qu’administrateur, puis cochez les options « Fichiers journaux de la mise à niveau de Windows » , « Précédente(s) installation(s) de Windows » et « Fichiers d’installation temporaires de Windows »

B. Ou le retour arrière

En revanche, si vous souhaitez revenir à la version antérieure de votre système tapez simplement « Rétrograder Windows… » dans la zone de recherche, ou passez par le panneau « Paramètres … Mise à jour et sécurité » .

Je n’ai pas testé, mais l’option semble limitée dans le temps, soit un mois pour se décider (Là, ils nous mettent la pression chez Microsoft, mais au moins ils nous préviennent !).

Après un petit questionnaire sur les raisons de retour en arrière, et quelques conseils, vous serez invité à poursuivre.

L’opération ne dure que quelques minutes, et on retrouve le système précédent, toujours activé !…

Mais l’aventure Windows 10 ne fait que commencer…suite au prochain épisode

Christophe

I. Présentation

Le sujet peut paraître quelque peu poussiéreux, mais lors de mes interventions en clientèle, principalement au sein des petites structures, je suis régulièrement surpris par les techniques de mise à jour du navigateur Internet Explorer 11 sur les postes Windows 7 en particulier. En effet, selon les distributions officielles de Microsoft, Windows 7 intègre la version 8 ou 9 du navigateur, mais pour les versions suivantes, 10 ou 11, il faut procéder à une installation de packages. L’emploi du pluriel est volontaire puisque certains correctifs (KB) constituent des prérequis d’installation, mais je vais y revenir dans cet article. Pour mettre à jour Internet Explorer, il y a plusieurs méthodes telles que  :

• En ligne, via Windows Update ou WSUS …
• Via un script chargé d’exécuter les différents packages …
• Via le kit IEAK (Déconseillé pour un déploiement)
• Injection au sein de vos images de référence (construites via MDT bien sûr  )

L’inconvénient majeur de ces techniques, porte sur la nécessité d’un ou plusieurs redémarrages selon la technique employée. Je vous propose donc une solution moins évidente, mais bien plus pratique et efficace en matière de déploiement de masse généralisé.

II. Analyse des packages d’installation d’IE11

A. Les prérequis

Pour rappel,  les mises à jour requises pour l’installation d’Internet Explorer 11 sur Windows 7 sp1 x86 ou x64 sont KB2729094, KB2731771, KB2533623, KB2670838, KB2786081 et KB2834140 auxquelles il est possible d’ajouter les mises à jour facultatives suivantes : KB2639308, KB2888049 et KB2882822. (cf http://support.microsoft.com/kb/2847882 ) – Ce qui fait théoriquement 9 mises à jour, mais l’article ne tient pas compte de celles qui ont été remplacées :

• KB2726535 = Annule et remplace les mises à jour KB2533623 et KB2731771
• KB2882822 = Annule et remplace la mise à jour KB2639308.

En fin de compte, il nous reste 7 mises à jour (par architecture x86/x64) à installer avant de procéder à l’installation d’Internet Explorer 11 sur  Windows 7  sp1.

1. Installer des packages .MSU (méthode traditionnelle)

Ces mises à jour sont délivrées au format .MSU et peuvent donc être installées via la  commande suivante

wusa.exe UpdatePackage.MSU /quiet /norestart /log:Journal.log

Nous n’en aurons pas besoin dans cet exemple, mais pour votre gouverne, la commande suivante permet de désinstaller une mise à jour.

wusa.exe /kb:HotfixId /uninstall /quiet /norestart /log:Journal.log

Vous pouvez déposer tous les fichiers dans des sous-dossiers et inclure leur installation conditionnelle dans un script d’installation d’IE11.

Pour votre gouverne, voici un petit exemple de code Powershell permettant de tester les prérequis, mais ce n’est pas la technique retenue dans cet article.

$NeededHotFixes = @('KB2670838','KB2726535','KB2729094','KB2786081','KB2834140')
Write-Host "Vérification de la présence des correctifs requis pour IE11."
$InstalledHotFixes = (Get-HotFix).HotFixId
$NeededHotFixes | foreach {
 if ($InstalledHotFixes -match $_) {
 Write-Host -fore Green "Correctif $_ installé";
 } else {
 Write-Host -fore Red "Correctif $_ manquant";
 # Ici, on peut procéder à l'installation via WUSA, mais il faudra déclarer une correspondance
 # entre les numéros de KB et le nom des packages .MSU
 }
}

B. Le package principal d’installation IE11

Il vous faudra également récupérer le package d’installation autonome, en français disponible ici : http://windows.microsoft.com/en-us/internet-explorer/ie-11-worldwide-languages  et en fonction de votre plateforme :

Extrait de la page de téléchargement d’Internet Explorer 11

La commande d’installation silencieuse est :

IE11-Windows6.1-x86-fr-fr.exe /norestart /quiet /update-no

IE11-Windows6.1-x64-fr-fr.exe /norestart /quiet /update-no

En l’absence des prérequis, l’exécution d’un de ces packages renvoie l’erreur « 40007 – USER_ERROR_MISSING_REQUIRED_PREREQUISITE »

C. Contenu d’un dossier de packaging IE11 autonome

En résumé, voici le contenu exhaustif d’un dossier « Sources » du package IE11 pour Windows 7 nécessaire à une installation autonome.

\Packages\IE11-Win7-sp1\Sources\IE11-Windows6.1-x64-fr-fr.exe
\Packages\IE11-Win7-sp1\Sources\IE11-Windows6.1-x86-fr-fr.exe
\Packages\IE11-Win7-sp1\Sources\Optional\Windows6.1-KB2882822-x64.msu
\Packages\IE11-Win7-sp1\Sources\Optional\Windows6.1-KB2882822-x86.msu
\Packages\IE11-Win7-sp1\Sources\Optional\Windows6.1-KB2888049-x64.msu
\Packages\IE11-Win7-sp1\Sources\Optional\Windows6.1-KB2888049-x86.msu
\Packages\IE11-Win7-sp1\Sources\Optional\Old\Windows6.1-KB2639308-x64.msu
\Packages\IE11-Win7-sp1\Sources\Optional\Old\Windows6.1-KB2639308-x86.msu
\Packages\IE11-Win7-sp1\Sources\Prereq\Windows6.1-KB2670838-x64.msu
\Packages\IE11-Win7-sp1\Sources\Prereq\Windows6.1-KB2670838-x86.msu
\Packages\IE11-Win7-sp1\Sources\Prereq\Windows6.1-KB2726535-x64.msu
\Packages\IE11-Win7-sp1\Sources\Prereq\Windows6.1-KB2726535-x86.msu
\Packages\IE11-Win7-sp1\Sources\Prereq\Windows6.1-KB2729094-v2-x64.msu
\Packages\IE11-Win7-sp1\Sources\Prereq\Windows6.1-KB2729094-v2-x86.msu
\Packages\IE11-Win7-sp1\Sources\Prereq\Windows6.1-KB2786081-x64.msu
\Packages\IE11-Win7-sp1\Sources\Prereq\Windows6.1-KB2786081-x86.msu
\Packages\IE11-Win7-sp1\Sources\Prereq\Windows6.1-KB2834140-v2-x64.msu
\Packages\IE11-Win7-sp1\Sources\Prereq\Windows6.1-KB2834140-v2-x86.msu
\Packages\IE11-Win7-sp1\Sources\Prereq\Old\Windows6.1-KB2533623-x64.msu
\Packages\IE11-Win7-sp1\Sources\Prereq\Old\Windows6.1-KB2533623-x86.msu
\Packages\IE11-Win7-sp1\Sources\Prereq\Old\Windows6.1-KB2731771-x64.msu
\Packages\IE11-Win7-sp1\Sources\Prereq\Old\Windows6.1-KB2731771-x86.msu

Toutefois l’installation des correctifs et/ou de ces packages sous ce format, engendre une erreur « normale » (Code retour « 3010 – REBOOT REQUIRED »)

Finalisation d’installation et activation d’Internet Explorer 11 lors du redémarrage

III. « Repackaging IE11 » pour un déploiement plus efficace !…

A. Réorganisation des sources

Pour ma part, je préfère une autre technique, moins contraignante, qui consiste à extraire les différents packages afin d’en obtenir leurs déclinaisons au format .CAB. puis procéder ensuite à leur injection dans le système via l’outil « DISM »

Pour extraire les MSU, vous pouvez utiliser l’utilitaire 7-Zip ou la commande suivante:

expand -F:* KB.msu <target_dir>

Pour information, seuls les fichiers portant l’extension .CAB nous seront utiles.

Pour extraire le package d’installation d’IE11, il suffit d’ajouter le commutateur « /x » suivi d’un dossier de destination lors du lancement, comme suit :

.\IE11-Windows6.1-<archi>-fr-fr.exe /x:<target_dir>

Pour information, cette première extraction contient des fichiers .MSU (4 par architecture) que nous devons également extraire au format .CAB. Ne conservez que les fichiers .cab correspondants à « IE-Hyphenation-fr-FR » et « IE-Spelling-fr-FR » respectivement identifiés par KB2849697 et KB2849696.

En résumé, on génère la structure de dossiers et fichiers suivante :

│
├───IE11x64_CAB
│ IE-Win7.CAB
│ ielangpack-fr-FR.CAB
│ Windows6.3-KB2849696-x86.cab
│ Windows6.3-KB2849697-x86.cab
│ x86_noKB2849696-KB2849697-amd64.txt
│
├───IE11x86_CAB
│ IE-Win7.CAB
│ ielangpack-fr-FR.CAB
│ Windows6.3-KB2849696-x86.cab
│ Windows6.3-KB2849697-x86.cab
│
├───Optional
│ Windows6.1-KB2882822-x64.cab
│ Windows6.1-KB2882822-x86.cab
│ Windows6.1-KB2888049-x64.cab
│ Windows6.1-KB2888049-x86.cab
│
├───Prereq
│ Windows6.1-KB2670838-x64.cab
│ Windows6.1-KB2670838-x86.cab
│ Windows6.1-KB2726535-x64.cab
│ Windows6.1-KB2726535-x86.cab
│ Windows6.1-KB2729094-v2-x64.cab
│ Windows6.1-KB2729094-v2-x86.cab
│ Windows6.1-KB2786081-x64.cab
│ Windows6.1-KB2786081-x86.cab
│ Windows6.1-KB2834140-v2-x64.cab
│ Windows6.1-KB2834140-v2-x86.cab
│
└───Security
 IE11-Windows6.1-KB3038314-x64.cab
 IE11-Windows6.1-KB3038314-x86.cab
 KB3038314.txt

 Note : Les fichiers .txt (ajoutés par mes soins) sont facultatifs et contiennent simplement des indications sur l’origine et l’objectif de certains correctifs.

B. Exemple de script d’installation ponctuel

Généralement, pour ce genre de besoin, je privilégie un script en Powershell, mais certains préféreront un autre langage et pour déroger à mes habitudes, je vous propose donc le batch suivant :

« Install_IE11_x86-x64.bat »

@ECHO OFF
CLS
ECHO *********************************************
ECHO Script d'installation d'Internet Explorer 11  
ECHO *********************************************
set OSD=
FOR /f "tokens=2 delims==" %%x in ('wmic os where "version='6.1.7601' and producttype=1" get caption /value') do (set OSD=%%x)
ECHO %OSD% | findstr /C:"Windows 7">nul || (goto notW7)
ECHO Le systeme actuel est "Windows 7 SP1" - On continue.
WHOAMI /groups|findstr S-1-16-12288 > nul
IF %errorlevel%==0 (echo Niveau de privileges : OK) ELSE (goto notAdmin)
IF "%PROCESSOR_ARCHITECTURE%"=="x86" (set CPU=x86) ELSE (set CPU=x64)
ECHO L'architecture CPU est : %CPU%
ECHO Le chemin actuel est : %~dp0
ECHO Installation du prerequis IE11: KB2834140
dism /online /add-package /packagepath:%~dp0Prereq\Windows6.1-KB2834140-v2-%CPU%.cab /quiet /norestart
ECHO Installation du prerequis IE11: KB2670838
dism /online /add-package /packagepath:%~dp0Prereq\Windows6.1-KB2670838-%CPU%.cab /quiet /norestart
ECHO Installation du prerequis IE11: KB2726535
dism /online /add-package /packagepath:%~dp0Prereq\Windows6.1-KB2726535-%CPU%.cab /quiet /norestart
ECHO Installation du prerequis IE11: KB2729094
dism /online /add-package /packagepath:%~dp0Prereq\Windows6.1-KB2729094-v2-%CPU%.cab /quiet /norestart
ECHO Installation du prerequis IE11: KB2786081
dism /online /add-package /packagepath:%~dp0Prereq\Windows6.1-KB2786081-%CPU%.cab /quiet /norestart
ECHO -----------------------------------------
ECHO Installation de la mise a jour facultative IE11: KB2888049
dism /online /add-package /packagepath:%~dp0Optional\Windows6.1-KB2888049-%CPU%.cab /quiet /norestart
ECHO Installation de la mise a jour facultative IE11: KB2882822
dism /online /add-package /packagepath:%~dp0Optional\Windows6.1-KB2882822-%CPU%.cab /quiet /norestart
ECHO -----------------------------------------
ECHO Installation du noyau principal IE 11
dism /online /add-package /packagepath:%~dp0IE11%CPU%_CAB\IE-Win7.cab /quiet /norestart
ECHO Installation du correcteur orthographique (spelling)
dism /online /add-package /packagepath:%~dp0IE11%CPU%_CAB\Windows6.3-KB2849696-x86.cab /quiet /norestart
ECHO Installation de la coupure syllabique (Hyphenation)
dism /online /add-package /packagepath:%~dp0IE11%CPU%_CAB\Windows6.3-KB2849697-x86.cab /quiet /norestart
ECHO -----------------------------------------
ECHO Installation du pack de langue France
dism /online /add-package /packagepath:%~dp0IE11%CPU%_CAB\ielangpack-fr-FR.cab /quiet /norestart
ECHO -----------------------------------------
ECHO Installation de la mise a jour de securite cumulative pour IE11 KB3038314 (14/042015)
dism /online /add-package /packagepath:%~dp0Security\IE11-Windows6.1-KB3038314-%CPU%.cab /quiet /norestart
ECHO *****************************************
ECHO %errorlevel%
ECHO Fin d'installation d'Internet Explorer 11. Le produit sera actif au prochain redemarrage de l'ordinateur.
ECHO Fin du script
GOTO Fin
:notAdmin
ECHO Niveau de privileges insuffisant pour l'installation - Fin du script
GOTO Fin
:notW7
ECHO Ce script est uniquement effectif sur Windows 7 SP1
GOTO Fin
:Fin

Déposez ce script à la racine de la structure de dossier présentée précédemment, puis exécutez-le sur les postes cibles (via un compte d’administrateur), en redirigeant la sortie vers un journal (ie « Install_IE11_x86-x64.bat > c:\temp\IE11-inst.log »). A l’issue de ces opérations, Internet Explorer 11 devrait être correctement installé, mais ne sera activé qu’au prochain redémarrage de l’ordinateur.

A propos d’IE11 – Mise à jour KB3038314

C. Généralisation au sein des images .WIM

Maintenant que nous avons présenté cette technique d’installation « unitaire », je vous propose d’évoquer la généralisation au sein de vos images de référence via le MDT.

Note : Pour ceux qui n’utiliseraient pas le MDT, sachez qu’il est également possible d’injecter IE11 dans une image de distribution Windows 7, via une technique très similaire. Pour cela, il suffit de procéder préalablement à un montage  de l’image .WIM, encore via la commande « DISM« , puis d’exécuter ce même batch (sous réserve de remplacer le commutateur « /online » en « /image:CheminDeMontage » afin de pointer vers l’image à modifier)

1. Intégration d’IE11 via le MDT

En raison du « repackaging » proposé précédemment, nous disposons déjà de la matière première pour effectuer cette opération.

Pour cela, au niveau de la console MDT « Deployment Workbench« , après vous être connecté au partage de déploiement désiré, rendez-vous sous la rubrique « Packages« , puis créer un nouveau dossier, comme par exemple « W7-Patches« . Utilisez ensuite le menu contextuel « Import OS Packages »

MDT : Importation des packages

Sélectionnez le dossier dans lequel nous avons précédemment extrait les fichiers .CAB puis cliquez sur « Next »

Note : Il y aura quelques erreurs sur des packages tels que IE_SUPPORT… qui ne sont pas considérés comme des mises à jour. De plus, je vous conseille de créer des sous-dossiers par architecture afin de faciliter la réalisation de profils de sélection adaptés.

Une fois l’importation terminée, vous devriez obtenir quelque chose du genre :

MDT : Vue d’ensemble des packages nécessaires à l’installation d’IE11

Dans une séquence de tache standard, MDT installe automatiquement toutes les mises à jour contenues dans le dossier « Packages« . Cf « Preinstall … Apply Patches »

MDT : Tache d’installation des packages

Facultatif : A des fins d’optimisation, je vous conseille de définir un nouveau profil « Selection Profile » afin de référencer un sous-dossier contenant uniquement les mises à jour en fonction du système d’exploitation installé.

Pour cela, dans la console MDT, sélectionnez le nœud « Advanced configuration … Selection Profiles » puis le menu « Action … New Selection Profile » ou le menu contextuel. Entrez un nom désignant ce profil selon l’organisation choisie, puis sélectionnez le(s) sous -dossier(s) correspondants.

MDT : Création d’un profil de sélection personnalisé (custom) pour affiner l’installation des packages

Cliquez 2 fois sur « Next » puis « Finish » pour créer le profil de sélection.

Une fois le(s) profil(s) de sélection créé(s), vous n’aurez plus qu’à l’associer dans la séquence de tache, en lieu et place de la valeur « All Packages » mentionnée précédemment.

Si vous utilisez MDT2013, c’est terminé. En revanche, si vous utilisez une version antérieure telle que MDT2012up1, et que vous avez intégré IE11 dans vos images de référence, vous devrez procéder à une modification (ou vérification) du fichier de réponse « unattend.xml », de la séquence de tache. Dans le cas contraire, l’erreur « Windows could not parse or process unattend answer file for pass [specialize]. A component or setting specified in the answer file does not exist. » peut apparaitre lors du déploiement.

Pour éviter cela, au niveau de la console MDT « Deployment Workbench« , sélectionnez la (ou les) séquence de tache d’installation « Windows 7 » puis cliquez sur le menu contextuel « Propriétés« . Sélectionnez l’onglet « OS Info » puis  cliquez sur le bouton « Edit Unattend.xml« .

MDT : Modification du fichier de réponse

Si le fichier catalogue n’est pas à jour, celui-ci est régénéré par le MDT et l’opération peut être relativement longue. Ensuite, l’assistant de gestion d’image Windows (WSIM) s’ouvre sur l’image en question avec le fichier de réponse correspondant.

En fonction de l’architecture, sélectionnez le composant « x86… » ou « amd64_Microsoft-Windows-IE-InternetExplorer_neutral »  situé sous le nœud « 4 specialize node« , puis dans la zone de propriétés, effectuez un clic droit sur « IEWelcomeMsg » puis « Annuler la modification« .

WSIM : Modification du composant Internet Explorer défini fichier unattend.xml

Supprimer également la directive « ShowMenuBar » = « true » si elle existe.

Remarque : La rubrique « Packages » du fichier de réponse n’est pas utile dans le cadre su MDT, à moins que ces mises à jour soient situées dans un autre dossier (déconseillé)

Enregistrez le fichier de réponse modifié puis quittez WSIM.

Cette procédure est un peu complexe, et en tant qu’expert , il est également possible de modifier directement le fichier « Unattend.xml » en commentant la balise. Autrement dit, ouvrez le fichier avec un bloc-notes puis remplacer la ligne « <IEWelcomeMsg>false</IEWelcomeMsg> » par « <!– <IEWelcomeMsg>false</IEWelcomeMsg> –> ».

A titre d’information, sur MDT 2013, le modèle de fichier de réponse contient ceci :

Extrait du fichier unattend.xml (MDT2013) – Détails du composant Internet Explorer

L’action est à réitérer pour chacune de vos séquences de tache concernées et par architecture. Une fois encore, cette opération est inutile si vous utilisez déjà MDT2013

Pour aller plus loin, dans la personnalisation d’IE11, téléchargez le kit IEAK11, disponible ici :  https://www.microsoft.com/en-us/download/details.aspx?id=40903

IEAK11 – Internet Explorer Administration Kit

Précision : L’usage d’IEAK engendre un nouveau package MSI ou EXE à partir des sources initiales, mais reste plus adapté à des personnalisations d’Internet Explorer qu’à des déploiements.

Bon déploiement à tous