Gestion des applications dans 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.

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é.

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".

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".

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.

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".

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".

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".

Vérifier les réglages dans la page "Summary", puis cliquez sur "Next" pour procéder à la création.

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):

Puis vous connecter à l’instance en indiquant le nom du serveur et de l’instance sous la forme "ServeurMDT\SQLExpress".

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:

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".

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"

Conservez les 3 premières cases cochées puis cliquez sur "Next"

• Page “Location Options”

Cliquez sur "Deselect All" puis cliquez sur "Next",

• Page "Make/Model Options"

Cliquez sur "Deselect All" puis cliquez sur "Next",

• Page "Role Options"

Conservez les 2 premières cases cochées puis cliquez sur "Next"

• Page "Summary"

Vérifiez les réglages dans la page "Summary" puis cliquez sur "Next".

• Page "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".

Sous l’onglet "Identity" entrez un nom décrivant ce rôle, comme par exemple "Poste Fixe Standard".

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.

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"

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.

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".

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.

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 :

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

Christophe Mandin Consultant - Formateur indépendant

Consultant/Formateur indépendant en quête de solutions et de moyens alliant efficacement la théorie et la pratique. Fort d’une expérience de plusieurs dizaines années dans l’informatique, j’ai pu apprécier de nombreuses problématiques, développer des qualités rédactionnelles et un esprit de synthèse, tout en me forgeant de solides fondamentaux théoriques, indispensables à toute analyse et mise en œuvre fonctionnelle. Malgré toutes ces années, je ne me lasse pas du plaisir de transmettre mes connaissances en misant sur 3 critères que sont les fondamentaux, la simplicité et le pragmatisme. Bien à vous. Retrouvez-moi sur LinkedIn : Christophe Mandin

See Full Bio