I. Présentation

Habituellement, on utile le couple MDT/WDS qui est complémentaire, notamment parce que le WDS permet d’initier le boot PXE (sur le réseau) à partir d’un poste client, pour ensuite charger l’image LiteTouch générée à partir de MDT. Dans ce tutoriel, nous allons voir comment déporter cette image LiteTouch sur une clé USB plutôt que de la charger par le réseau, autrement dit on remplacera le boot PXE par le boot USB.

Cette méthode peut-être utile pour les modèles sans cartes Ethernet natives, comme les Lenovo Yoga ou encore les ultrabooks Dell XPS.

Une clé USB sera bien entendu nécessaire pour réaliser l’opération et une image LiteTouch présente sur votre serveur de déploiement, que nous allons exploiter.

II. Préparation de la clé USB

Pour préparer la clé USB et plus particulièrement créer une partition à l’aide de DiskPart, voici le jeu de commandes à saisir une fois dans l’utilitaire Diskpart, accessible depuis une invite de commandes à partir de la commande du même nom.

DISKPART> List disk
DISKPART> Select disk 1
DISKPART> Clean
DISKPART> Create partition primary
DISKPART> Select partition 1
DISKPART> Format fs=ntfs quick
DISKPART> Active
DISKPART> Exit

On commence par effacer la table de partition de la clé USB et recréer une partition NTFS propre que l’on va formater et définir comme active. Vous devez faire attention lors de l’opération « Select disk 1 » car on va effectuer nos opérations à venir sur le disque sélectionné, à partir du numéro repéré dans la sortie de la commande « List disk ».

Par exemple, sur la copie d’écran ci-dessous, ma clé USB correspond au « Disque 1 » donc je sélectionne le disk 1.

Dès que vous êtes sur de votre coup concernant la sélection du disque, vous pouvez saisir les autres commandes sans rien changer.

III. Copie des fichiers sur la clé USB

Désormais, il va falloir récupérer des fichiers sur votre serveur de déploiement MDT pour les copier sur la clé. Tout d’abord, récupérez les données de boot, dans le répertoire suivant :

\\<votre-serveur>\deploymentshare\Boot

Puis, prenez le contenu du dossier x86 ou x64 selon vos besoins, par exemple pour x64 on obtient le contenu suivant :

Il suffit de copier-coller l’ensemble du contenu à la racine de la clé USB fraîchement préparée.

Il ne reste plus qu’à créer un dossier nommé « Sources » à la racine de votre clé USB, et à copier à l’intérieur l’image WIM correspondant au LiteTouch de votre MDT (et selon votre architecture x64 ou x86) :

Renommez le fichier « LiteTouchPE_x64.wim » ou « LiteTouchPE_x86.wim » en « boot.wim«  et le tour est joué ! La clé USB est prête, vous pouvez démarrer le LiteTouch directement depuis ce support.

I. Présentation

L'idée de cet article est de vous présenter 2 éléments méconnus de configuration d'un poste Windows.

1 - Les stratégies locales multiples (MLGPO) apparues depuis Vista

2 - L'application de GPO en avant-phase ou "sortie-de-boite" (Typiquement via MDT)

II. Introduction aux stratégies locales multiples (MLGPO)

Vous connaissez probablement la fameuse stratégie d'ordinateur local, à laquelle on accède via la console "gpedit.msc". Il est vrai qu'en présence d'un domaine Active Directory, son intérêt est moindre, voire inutile.

Cela étant dit, si votre poste est en Workgroup, cela constitue une technique de configuration plus élégante, et surtout une meilleure traçabilité des réglages que des modifications directes du registre.

Cette technique peut également être retenue pour brider les utilisateurs de serveurs mutualisés (TSE, RDS, Citrix…) sans recourir au traitement par boucle de rappel avec refus d'application pour les administrateurs. (Concepts avancés de gestion des GPO dans AD)

Bien, maintenant, pour faire court, un objet de stratégie de groupe, alias GPO, est toujours composé de 2 configurations. L'une destinée à l'ordinateur (soit HKLM) et l'autre à l'utilisateur (soit HKCU). Toutefois, dans le cadre, d'un GPO d'ordinateur local, il n'y a pas de distinction d'utilisateur à ce niveau. Donc tout paramètre défini dans la partie "Utilisateur" affecte tous les utilisateurs de ce poste, y compris l'administrateur 🙂 .

A.  Mise en œuvre d'un "GPO d'utilisateur local "

Pour accéder à cette fonctionnalité, en tant qu'administrateur, vous devez exécuter "MMC.exe" puis utiliser le menu "Fichier … Ajouter/Supprimer un composant logiciel enfichable" ou  [Ctrl]+[M]"

Sélectionnez le composant "Editeur d'objets de stratégie de groupe" puis cliquez sur le bouton "Ajouter >".

Dès lors que la fenêtre suivante s'affiche, cliquez sur le bouton "Parcourir".

Ne cliquez surtout pas sur "Terminer" à ce stade, car vous obtiendriez l'équivalent de la console "gpedit.msc" appelée directement.

Sous l'onglet "Utilisateurs", vous devriez voir les différents comptes locaux existants sur le poste en question.

Dans cette fenêtre, apparait également 2 "groupes" locaux :

• Administrateurs (pas la peine d'expliquer 🙂 )
• Non-administrateurs (donc tous les utilisateurs qui ne sont pas membre du groupe des administrateurs locaux)

Sélectionnez cette entrée "Non-administrateurs", puis cliquez sur "OK".

Il est possible de définir un GPO pour chaque utilisateur local, mais cela risque de devenir rapidement fastidieux.

Cliquez sur "Terminer", puis sur "OK" pour fermer l'ajout de composants.

Nous obtenons alors quelque-chose du genre suivant :

Vous pouvez constater que seule une "Configuration utilisateur" est proposée.

Maintenant, pour la démonstration, allez sous la rubrique "Modèles d'administration … Panneau de configuration" puis activez le paramètre : "Empêcher l'accès au Panneau de configuration"

Cliquez sur "OK" pour valider puis fermez la console.

Pour tester cette contrainte, fermez la session administrateur en cours puis  ouvrez une session avec un compte d'utilisateur.

Normalement, vous devriez constater la disparition de l'entrée "Panneau de configuration" habituellement affichée dans le menu "Démarrer". Pour vous assurer que la contrainte est bien effective, exécutez "cmd.exe" puis tapez "control.exe". Le message de restrictions suivant doit alors apparaitre.

Avec un compte, membre du groupe local "Administrateur", vérifiez que cette restriction n'est pas effective.

B. Détails techniques

Le GPO local est stocké dans le dossier "%WINDIR%\System32\GroupPolicy" sous lequel on trouve un fichier "gpt.ini" et 2 sous-dossiers "Machine " et "User".

Le fichier "gpt.ini"(*1) permet de décrire les identifiant GUID des différentes extensions coté client GPO (Client Side Extension - CSE) alors que les 2 fichiers "registry.pol" contiennent les paramètres définis respectivement dans chaque configuration ordinateur et utilisateur.

(*1) Plus d'information sur http://www.jhouseconsulting.com/2008/08/26/scripting-updates-to-the-gptini-for-the-local-group-policy-39

En revanche, les GPO multiples (MLGPO) sont stockées dans le dossier "%WINDIR%\System32\GroupPolicyUsers". Un sous-dossier caché et basé sur l'identifiant de sécurité unique (SID (*2)) est créé afin de distinguer chaque périmètre d'application.

Pour le cas "Non-Administrateurs" que nous venons d'évoquer, c'est le SID du groupe local "Users" qui est utilisé, soit "S-1-5-32-545"

(*2) Plus d'information sur "Well-Known Security Identifiers" : https://technet.microsoft.com/en-us/library/cc978401.aspx

On retrouve sous ce dossier "SID", les fichiers des extensions CSE ainsi qu'un unique sous-dossier "User" et le fichier "registry.pol" contenant les paramètres définis dans la configuration GPO.

Astuce : Pour visualiser le contenu d'un fichier .POL, vous pouvez utiliser l'outil gratuit "polviewer" disponible sur https://sdmsoftware.com/gpoguy/free-tools/library/registry-pol-viewer-utility/

III. Export / Import des GPO Locales

A. L'export de GPO Locales

Pour exporter puis importer ces GPO d'un ordinateur à un autre, Microsoft recommande d'utiliser son outillage de sauvegarde/restauration des stratégies locales. Celui-ci est contenu dans le kit gratuit Security Compliance Manager (SCM) qui peut être téléchargé ici : http://go.microsoft.com/fwlink/?LinkId=182512

Notes :

N'oubliez pas de "débloquer" le  fichier téléchargé (cf flux ADS)

Attention, SCM 4.0 ne contient plus l'outil décrit ci-après - Probablement en lien avec le nouvel outil LGPO.exe mais qui ne supporte plus les MLGPO (https://blogs.technet.microsoft.com/secguide/2016/01/21/lgpo-exe-local-group-policy-object-utility-v1-0/ )

Commencez par extraire le contenu de l'exécutable vers un dossier temporaire via la commande :

"Security_Compliance_Manager_Setup.exe /x"

Ouvrez ensuite le fichier "data.cab" afin d'extraire le fichier "GPOMSI"

Renommez le fichier en "GPOMSI.msi"

Vous n'avez plus qu'à installer "normalement" ce package sur le poste de préparation.

Une fois installé, cet outil ajoute les raccourcis suivants dans le menu Démarrer d'un poste Windows 7.

Exécutez le lien "LocalGPO Command-line" en tant qu'administrateur.

LocalGPO Tool
____________________
Microsoft (R) Windows Script Host Version 5.8
Copyright (C) Microsoft Corporation 1996-2001. Tous droits réservés.

LocalGPO - Configures various aspects of a computer's Local Policy

Usage: LocalGPO.wsf {/Path:path to GPO Backup} [/Export] [/Compare] {[/GPOPack:name]}
 LocalGPO.wsf {/ConfigSCE | /ResetSCE | /Restore}

Options:

/Path:{path} : Applies the contents of a GPO Backup to the local policy of a Windows computer.

/Export : Exports Local Policy to a GPO Backup.

/Compare : Compares Local Policy to a GPO Backup.

/GPOPack:{name} : Creates a GPO backup that contains all components required for it to apply itself to the local security policy of a computer. Specifying a name is optional.

/MLGPO:{name} : Applies user settings from a GPO Backup to the specified MLGPO of a Windows computer. Must specify Administrators, Users(Non-Administrators), or a valid account name.

/Restore : Restores Local Policy to the default configuration.

/ConfigSCE : Configures Security Configuration Editor (SCE) to display MSS settings.

/ResetSCE : Restores SCE to default settings.

Examples:

 cscript LocalGPO.wsf /Path:C:\GPObackups\{GPO Backup GUID}
 - Applies the contents of the GPO Backup stored in the specified path to the Local Policy of a Windows computer.

 cscript LocalGPO.wsf /Path:C:\GPObackups /Export
 - Exports a GPO Backup based on the Local Policy configuration to a folder in the specified path.

 cscript LocalGPO.wsf /Path:C:\GPObackups\{GPO Backup GUID} /Compare
 - Compares Local Policy configuration to the contents of a GPO Backup.

 cscript LocalGPO.wsf /Path:C:\GPObackups /Export /GPOPack
 - Creates a GPOPack and stores it in the specified path. GPOPacks can be copied to other computers, and applied by double-clicking GPOPack.wsf.

 cscript LocalGPO.wsf /Path:C:\GPObackups\{GPO Backup GUID} /MLGPO:Users
 - Applies the contents of the GPO Backup stored in the specified path to the specified Multiple Local Group Policy Obect (MLGPO).

 cscript LocalGPO.wsf /Restore
 - Restores the entire Local Policy to its default configuration.

Comme vous pouvez le constater l'outil propose de nombreuses options.

Commencez par créer un dossier de travail sur le poste de préparation, tel que "C:\LGPO.bck"

Attention, bien que cet outil puisse importer un GPO local d'utilisateur (MLGPO), il ne permet pas d'en effectuer l'export. En conséquence, vous devrez configurer les paramètres d'utilisateur via la console traditionnelle "gpedit.msc".

Une fois ces réglages effectués, procédez à la sauvegarde via l'outil LocalGPO.wsf comme suit :

cscript LocalGPO.wsf /Path:C:\LGPO.bck /Export /GPOPack:MLGPO

Remarque : Je n'ai pas réussi à trouver un outillage ou une méthode officielle pour sauvegarder ou exporter uniquement une stratégie locale d'utilisateur. (Vos propositions sont les bienvenues 🙂 )

Donc, dans l'éventualité où les restrictions appliquées bloqueraient l'administrateur, et particulièrement l'accès à cet outillage 🙁  vous pouvez définir les paramètres dans un "MLGPO  Non-Administrateurs" puis recopier le fichier "GroupPolicyUsers\S-1-5-32-545\User\registry.pol" vers le dossier "User" d'une sauvegarde complète.
Sinon, reportez-vous à la méthode officieuse que je traite ci-après.

Exemple de copie du "LGPO Non-Administrateurs" vers la sauvegarde :

L'option "/GPOPack" permet d'obtenir un package autonome permettant d'injecter un GPO local sur un ordinateur sans installation préalable de l'outil. A défaut de stipuler un nom pour ce package, l'outil affecte un identifiant unique GUID.

Dans le cas d'une exportation en package "GPOPack", le script d'installation se nomme alors "GPOPack.wsf"

Cas particulier des scripts de GPO

L'outil d'import/export que je viens de présenter ne prend pas en charge les  "Scripts".

Au besoin, il faudra les copier manuellement dans les dossiers adéquats (Startup, Shutdown, Logon, Logoff) sans oublier le fichier caché  \Scripts\scripts.ini (chargé de décrire les scripts)

Importance du fichier GPT.ini

Ce fichier décrit principalement les extensions coté client (Client Side Extensions) nécessaires au traitement du GPO. Pour afficher ces extensions CSE et leur identifiant utilisez la commande Powershell suivante :

get-childitem "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions" |
   Get-IemProperty |
       Format-Table @{e={$_.PSChildName};l="GUID"},@{e={$_."(default)"};l="CSE Name"},dllname

Une liste de CSE est disponible ici

Pour le cas qui nous intéresse :

• CSE nécessaires aux scripts de logon/logoff

• CSE nécessaires au traitement des paramètres utilisateur

B. L'import de GPO Locales

Maintenant que nous disposons d'un package conforme, nous allons voir que l'importation est une simple formalité (ou presque).

Donc pour importer le package du "GPO Local Non-Administrateurs", utilisez la commande suivante à partir du dossier de la sauvegarde :

cscript GPOPack.wsf /MLGPO:Utilisateurs

On peut constater que l'importation est réussie et la présence du dossier (caché)  "S-1-5-32-545" sous "%WINDIR%\System32\GroupPolicyUsers".

En revanche, on constate que les éventuels scripts ne sont pas copiés. Dans ce cas, il faut compléter l'opération par une copie manuelle des scripts dans les répertoires correspondants ainsi que le fichier \Scripts\scripts.ini

Attention : Si vous exécutez un script au sein d'un GPO, il est préférable que le champ "Nom du script" contienne l'interpréteur (tel que wscript.exe ou cscript.exe) et le champ "Paramètres de scripts" renseigne le nom du script (et les éventuelles options de l'interpréteur)

C. Ma technique personnelle de gestion d'un MLGPO Non-Administrateurs

Après vous avoir présenté tout ce "bazar", je vais vous exposer une méthode moins académique, et non supporté officiellement, mais qui a fait ses preuves et surtout plus rapide.

• 1 - Sur le poste source, éditez le "LGPO Non-Administrateurs" via la console MMC, comme évoqué précédemment.
  • a - Configurez les paramètres souhaités via les modèles d'administration
  • b - Ajoutez éventuellement un script de logon ou de logoff
• 2 - Copiez intégralement le dossier "%windir%\System32\GroupPolicyUsers\S-1-5-32-545" vers un dossier tel que "LGPO-Users\Sources". (N'oubliez pas les fichiers cachés). Vous devriez obtenir un truc du genre :

Dans mon exemple, le contenu de "gpt.ini"

[General]
gPCFunctionalityVersion=2
gPCUserExtensionNames=[{35378EAC-683F-11D2-A89A-00C04FBBCFA2}{D02B1F73-3407-48AE-BA88-E8213C6761F1}][{42B5FAAE-6536-11D2-AE5A-0000F87571E3}{40B66650-4972-11D1-A7CA-0000F87571E3}{35378EAC-683F-11D2-A89A-00C04FBBCFA2}{D02B1F73-3407-48AE-BA88-E8213C6761F1}]
Version=786432

Et le contenu de "scripts.ini"

[Logon]
0CmdLine=wscript.exe
0Parameters=LogonScript.vbs

• 3 - Sur le poste cible, copiez le dossier "LGPO-Users\Sources" vers le dossier "%windir%\System32\GroupPolicyUsers\S-1-5-32-545"

Exemple de fichier "Install.bat"

@echo off
 mkdir c:\Windows\System32\GroupPolicyUsers\S-1-5-32-545
 xcopy .\Sources\*.* c:\Windows\System32\GroupPolicyUsers\S-1-5-32-545\*.* /e /s /y

IV. Application de stratégies locales via MDT

A. La méthode traditionnelle

Les GPOPacks sont apparus avec le MDT2012 puis, bien que toujours compatibles, les modèles (sous "Templates") ne sont plus proposés dans les versions MDT2013 et suivantes.

https://bcdeployment.wordpress.com/2015/02/01/mdt-astuce-mais-o-sont-passs-les-gpopacks-sous-mdt-2013/

Extrait de la documentation officielle MDT2013 :

GPO Packs do not exist

The Security Compliance Manager (SCM) GPO Packs are not included with MDT 2013. The "Apply Local GPO Package" step (ZTIApplyGPOPack.wsf) will log an entry similar to one of the following:

“The GPO Pack Path – Templates\GPOPacks\ is not valid. The GPO was not applied.”

“Default MDT GPO Pack not present for this operating system.”

WORKAROUND: Create the GPOPacks subfolder under Templates in the deployment share (for example, C:\DeploymentShare\Templates\GPOPacks). Export a GPO backup from SCM or GPMC and then add the following files from SCM:

• wsf
• exe
• sdb

Create a subfolder under GPOPacks and copy this content. Then specify the directory name in the GPOPackPath property in CustomSettings.ini.

Mais l'absence de ces modèles n'est pas critique, surtout que vous savez dorénavant comment créer un "GPOPack" 🙂

1. Séquence de tache

Dans une séquence " Standard Client Task Sequence", sous le groupe de taches "State Restore", doit apparaitre une action conditionnelle "Apply Local GPO Package". Dans le cas contraire, c'est à vous de la recréer :

• Propriétés
  • Type : Run Command Line
  • Name : Apply Local GPO Package
  • Command line : exe "%SCRIPTROOT%\ZTIApplyGPOPack.wsf"
• Options (conditions)
  • Task sequence variable ApplyGPOPack not equal NO

2. Copie des packages

Créez un sous-dossier "GPOPacks" dans le dossier "Templates" situé à la racine de la structure MDT.

Copiez-y ensuite le(s) dossier(s) correspondants aux exports réalisés avec "LocalGPO.wsf …. /export /GPOPack" (ou une sauvegarde de GPO de domaine réalisée avec GPMC.msc)

Vous pouvez renommer chaque package avec un nom convivial (sans espace, ni accents)

3. Ajout des directives

Dans le fichier de configuration "customsettings.ini", ajoutez les directives suivantes :

ApplyGPOPack=YES
GPOPackPath= Win7SP1-MDTGPOPack-DEMO

B. Injection directe du GPO Local "Non-Administrateurs"

Afin de parachever mes propos sur la technique officieuse que je vous ai présentée dans cet article, il ne me reste plus qu'a vous monter comment l'intégrer dans MDT.

Pour cela, il suffit de considérer les fichiers obtenus dans ma présentation comme une application.

Dans la console MDT, sélectionnez la rubrique "Application" puis utilisez le menu "Action … New  Application" ou le menu contextuel.

Choisissez l'option "Application with sources files", puis cliquez sur "Next"

Renseignez un nom dans le champ "Application Name" puis cliquez sur "Next"

Indiquez le chemin du dossier dans lequel vous avez déposé les fichiers, puis cliquez sur "Next"

Indiquez un nom pour le dossier de stockage de ces sources dans le MDT, puis cliquez sur "Next"

Renseignez le champ "Command line" en y indiquant le nom du script de copie "install.bat", puis cliquez 2 fois sur "Next" puis sur "Finish" pour valider.

Ouvrez ensuite la séquence de tache de déploiement, puis sélectionnez l'onglet "Task Sequence".

Sélectionnez la dernière tâche du groupe de taches "State Restore", puis utilisez le menu "Add … General … Install Application"

Dans le champ "Name", entrez un nom distinctif tel que "Apply LGPO Non-Administrators"

Cochez le radio-bouton "Install a single application" puis cliquez sur le bouton "Browse" afin de sélectionner l'application précédemment installée.

Cliquez sur "OK" pour valider et fermer la séquence de tache.

Voilà, c'est terminé.

A vous de jouer !

I. Présentation

Pour faire suite à l'article de Florian "MDT : Créer une clé USB LiteTouch bootable" et répondre à certaines interrogations sur cette technique de déploiement, je vous propose un petit tutoriel sur le thème "Comment réaliser une installation MDT à partir d'un média autonome (typiquement une clé  USB)".

Le MDT (alias Microsoft Deployment Toolkit) est une boite à outils pleine de ressources (ou de surprises pour certains).

Généralement, le MDT est associé à des installations et déploiement au travers du réseau. Parfois, en l'absence d'un serveur PXE, on utilise une clé USB (ou un CD/ISO) pour assurer la séquence d'amorçage du client LTI (LiteTouch) mais les ressources demeurent partagées sur un serveur.

Dans le cas, où le réseau devient une contrainte (bande passante limitée, déploiements autonomes en atelier ou pas), la solution MDT peut encore vous venir en aide, grâce à l'utilisation du mode "MEDIA".

II. Mise en œuvre

Je ne reviendrais pas sur l'installation et la configuration de base d'un MDT. Autrement dit, je considère que la maquette de départ est composée de :

• Un système Windows 7 x64 PRO avec MDT2013 + ADK8.1up1
• Ajout d'un Windows 7 x64 PRO sous "Operating Systems"

Pour cette démonstration, nous avons besoin des 3 fonctionnalités suivantes sélectionnées dans le kit ADK.

Note : Je n'ai pas choisi l'ADK10-1607 en raison d'une erreur "bcdedit" inexpliquée lors de la génération de l'image ISO finale.

https://social.technet.microsoft.com/Forums/en-US/60d86683-68e2-4a93-838b-231d61854804/bcdedit-returned-an-error-when-generating-an-media-iso-in-mdt?forum=mdt

A. Préliminaires

Pour cette démonstration, nous avons besoin d'au moins, un système d'exploitation disponible dans la console MDT :

B. Déclaration d'une séquence de taches

Sélectionnez la rubrique "Task Sequence" puis le menu "Action … New Folder" ou le menu contextuel.

Entrez un nom tel que "Deploy Media" et une description éventuelle pour ce nouveau dossier, puis cliquez sur 2 fois sur "Next" puis sur "Finish".

Sélectionnez ce nouveau dossier puis le menu "Action … New Task Sequence" ou le menu contextuel.

Entrez un identifiant et une description puis cliquez sur "Next"

Choisissez "Standard Client Task Sequence" dans la liste déroulante puis cliquez sur "Next"

Sélectionnez votre système d'exploitation puis cliquez sur "Next".

Renseignez les écrans suivants en fonction de vos besoins, puis cliquez sur "Finish".

Je ne m'attarderais pas sur les nombreux ajustements possibles dans la séquence de tache, tels que l'injection de pilotes par modèle, l'installation d'application… mais vous comprendrez rapidement l'intérêt de créer des sous-dossiers dans le MDT et l'utilité des profils de sélection.

Précision : Pour rappel, les dossiers MDT affichés dans la console MDT sont référencés dans des fichiers XML (situés sous \Control) et ne sont pas visibles dans la structure de fichiers de la ressource partagée MDT. (D'où l'importance de toujours effectuer vos opérations de copie, déplacement, renommage ou autre suppression uniquement au sein de la console). Cette arborescence  MDT  permet essentiellement de définir des profils de sélection, dont vous pourrez cochez que les dossiers contenants les éléments désirés.

C. Définition d'un profil de sélection

Cette étape devient importante dès lors que le MDT contient beaucoup d'éléments tels que différents systèmes, applications, package, pilotes, etc …

Pour visualiser et/ou déclarer un profil de sélection, vous devez développer l'arborescence  de la console jusqu'à "Advanced configuration … Selection Profiles"

Pour la démonstration, nous allons créer un profil spécifique à ce type de déploiement.

Sélectionnez la rubrique "Selection Profiles" puis le menu "Action … New Selection Profile" ou le menu contextuel.

Entrez un nom et une description éventuelle pour ce nouveau profil, puis cliquez sur "Next".

Pour cet exemple, nous n'avons pas d'applications, de packages, ni de pilotes spécifiques mais vous comprendrez que l'usage de sous-dossiers dans les différentes rubriques permet d'ajuster au mieux les éléments à conserver sur le média de destination.

Cochez les dossiers désirés, cliquez 2 fois sur "Next" et puis sur "Finish".

D. Déclaration du média LTI

Pour la déclaration du média, vous devez développer l'arborescence  de la console jusqu'à "Advanced configuration … Media"

Sélectionnez cette rubrique "Media" puis le menu "Action … New Media" ou le menu contextuel.

Entrez un chemin (Media path), une description éventuelle et sélectionnez votre profil précédemment créé, puis cliquez 2 fois sur "Next".

Note : Evitez d'affecter un chemin ou lecteur réseau pour l'emplacement du média, au risque d'avoir un message d'erreur lors de la génération de l'image ISO finale.

Une fois l'opération de copie achevée, cliquez sur "Finish".

Sélectionnez le nouveau "MEDIA001" qui apparait dans la fenêtre de détails puis utilisez le menu "Action … Propriétés".

Sous l'onglet "General", vous avez encore la possibilité de choisir quelques options, telles que décocher "Generate x86 boot image", inutile dans cet exemple.

Nous conservons la dernière option "Generate a Lite Touch bootable ISO image" afin de disposer d'un média utilisable au sein d'une machine virtuelle.

Sous l'onglet "Rules", vous retrouverez le désormais célèbre "CustomSettings.ini" ainsi que le fichier "Bootstrap.ini".

Le contenu est variable selon vos préférences et les ajustements effectués. Pour cette démonstration, je vous propose d'ajouter les directives suivantes sous la section [Default], afin d'automatiser les différents écrans de l'assistant de déploiement.

Ces choix restent bien évidement à votre discrétion. Ajoutez simplement un point-virgule en début de ligne pour l'ignorer.

CustomSettings.ini

[Settings]
Priority=Default
Properties=MyCustomProperty

[Default]
OSInstall=Y
SkipCapture=YES
SkipAdminPassword=YES
SkipProductKey=YES
SkipPackageDisplay=YES
SkipBDDWelcome=YES
SkipAppsOnUpgrade=YES
SkipComputerName=YES
SkipDomainMembership=YES
SkipUserData=YES
SkipComputerBackup=YES
SkipLocaleSelection=YES
SkipTaskSequence=YES
SkipTimeZone=YES
SkipApplications=YES
SkipBitLocker=YES
SkipSummary=YES
SkipFinalSummary=NO

_SMSTSOrgName=Demo Deploy Media
_SMSTSPackageName=Installation en cours....
OSDComputerName=DEMO-#Right("%SerialNumber%",10)#
TimeZone=105
TimeZoneName=Romance Standard Time
UILanguage=fr-FR
; KMS Default key for Windows 7 Pro
ProductKey=FJ82H-XT6CR-J8D7P-XQJJ2-GPDD4
JoinWorkgroup=WORKGROUP
TaskSequenceID=0001

A défaut, vous devrez valider chacun des écrans proposés durant le déploiement.

Remarque : Dans le cadre d'un déploiement par média, le fichier "Bootstrap.ini" n'a généralement pas besoin d'être personnalisé. Toutefois, pour assurer quelques réglages vous pouvez ajouter le contenu suivant :

[Settings]
Priority=Default

[Default]
SkipBDDWelcome=YES
KeyboardLocale=fr-FR
KeyboardLocalePE=040c:0000040c
InputLocale=040c:0000040c
UILanguage=fr-FR

Pour cet exemple, nous ne toucherons pas au dernier onglet "Windows PE". Cliquez sur "Appliquer" et/ou "OK" afin de valider ces changements.

Sélectionnez de nouveau la ligne "MEDIA001" dans la fenêtre de détails puis utilisez le menu "Action … Update Media Content".

Le processus de fabrication, relativement long, va copier les éléments sélectionnés via le profil vers un sous-dossier "[MediaPath]\Content", puis générer le noyau WinPE LiteTouch et enfin générer l'image .ISO (que nous avons demandé).

Si vous avez suivi l'exemple à lettre, l'installation devrait débuter sans aucune intervention de votre part.

Pour tester à partir d'un média USB, il suffit de préparer la clé comme suit :

• A partir d'une invite de commande en tant qu'administrateur

DISKPART

List Disk

Select Disk n (où n correspond au média USB)

Clean

Create Partition Primary

Format fs=ntfs quick label=MDT-Media

Assign Letter=k:

Exit

• A partir de l'explorateur Windows ou d'une invite de commande

Copiez l'intégralité du dossier "Content" vers la clé USB (ici "k:\" )

III. Cas UEFI et WIM supérieure à 4Go

Vous pouvez constater que ce genre de déploiement n'est pas très compliqué à mettre en œuvre. Toutefois, j'attire votre attention sur le fait qu'une image WIM personnalisée peut rapidement dépasser la taille fatidique de 4 Go. Ceci implique de fait un formatage du média USB en NTFS (comme mentionné précédemment).

Hors, le formatage d'un média d'amorçage en NTFS n'est pas (toujours) compatible avec une installation sur un PC qui supporte l'UEFI. En revanche, si vous formatez votre clé USB en FAT32 pour ce type d'installation, vous ne pourrez pas y loger l'image WIM de plus de 4Go.

Vous ne pouvez pas non plus opter pour un partitionnement double (FAT32 + NTFS) à moins de disposer d'une clé reconnue en tant que "Disque" et non en tant "Amovible". cf http://www.msnloop.com/creer-une-cle-uefi-pour-mdt-2013/

Sur les "supports amovibles", typiquement les clés USB, Windows ne reconnait que la première partition.

Donc pour résoudre cette problématique, et pouvoir installer une poste UEFI à partir d'une clé USB standard et une image WIM supérieure à 4 Go, il ne reste que 2 solutions :

• Découper l'image WIM en fichiers SWM inférieurs à 4Go, (via DISM par exemple), et les déposer sur votre clé USB formatée en FAT32. Sans oublier de vérifier que la séquence de tache MDT (notamment le script ZTIApply.wsf) prend bien en compte cette particularité. (Officiellement prise en compte à partir de MDT2013 update1)

• Utiliser l'outil "Rufus", d'une simplicité déconcertante….

Vous pouvez trouver l'outil Rufus ici dont une version "portable" à conserver précieusement dans votre boite à outils 🙂

• Insérez votre clé USB puis lancez "Rufus"
• Choisissez l'option "Type de partition GPT pour UEFI" dans la liste déroulante
• Conservez le système de fichier proposé (FAT32)
• Cliquez sur le bouton en face de "Créer un disque de démarrage…" puis sélectionnez l'image ISO "LiteTouchMedia.iso"
• Cliquez sur le bouton "Démarrer", et c'est fini 😀

Bon déploiement à tous

Christophe

I. Présentation

Vous avez probablement deviné que derrière ce titre racoleur se cache un petit mensonge 🙂 En fait, le service pack  2 n'existe pas vraiment et pour rattraper les nombreux correctifs sortis depuis le SP1 de Windows 7 (et 2008-R2), Microsoft propose un correctif cumulatif "KB3125574" alias "Convenience Rollup".

Distribué sous la forme d'un package Windows Update, vous disposez de plusieurs techniques pour l'installer.

• Sur les ordinateurs déjà installés
  • Directement en ligne via Windows Update ou un serveur WSUS de votre entreprise.
  • En téléchargeant le package .MSU dans le cadre d'une installation autonome (cf WUSA.exe)

• Dans les images de référence
  • Injection directe dans l'image WIM via DISM
  • Installation via le processus de fabrication MDT (Cas exposé ci-après)

Toutefois, l'installation de ce package implique quelques précautions et prérequis. En effet, outre la présence du service pack  1 (ce qui semble évident), il faut y adjoindre les correctifs préalables suivants, selon l'architecture :

L'installation de ces prérequis implique un redémarrage de l'ordinateur afin qu'il soit éligible à l'installation du "Convenience Rollup". En conséquence, l'utilisation de la fonctionnalité "Packages" du MDT, ne peut pas être réalisée en une seule passe.

Remarque : Cette technique et conseils d'installation peuvent s'appliquer à d'autres cas de figure. Dans les grandes lignes, vous devez cibler l'installation des prérequis dans les processus de fabrication initiaux, au plus proche ou à l'intérieur des images WIM de référence. Les autres packages pouvant être installés en post-installation ou via l'infrastructure selon leur taille ou le besoin.

II. Explications et mise en œuvre dans MDT

A. Appliquer les packages au bon moment

Vous savez probablement que MDT prend nativement en charge l'installation de packages au format .cab ou .msu. En fait, au sein d'une séquence de tache standard, nous pouvons constater que l'installation des packages est effectuée au niveau de l'action "Apply Patches" située dans le groupe de taches "Preinstall". Toutefois, cette action s'appuie sur le profil de sélection "All Packages" par défaut, et par conséquent installe l'intégralité des éléments éligibles déclarés dans le dossier "Packages" et ses éventuels sous dossiers.

En affinant sur les profils de sélection des packages, on peut imaginer une installation en 2 étapes mais il faut gérer un redémarrage intermédiaire, ce qui n'est pas possible à ce moment du processus.

Il faut donc que le correctif global s'installe dans un second temps, après que le système ait redémarré, donc plutôt dans la phase "State Restore".

Cela étant dit, nous devons également distinguer deux techniques de fabrication :

• Une séquence de taches distincte chargée de la capture qui intègre au minimum les prérequis puis la ou les séquences de déploiement chargées d'installer ce fameux correctif cumulatif, en mode autonome ou via WSUS. (Gestion du parc existant, mais pénalise fortement les temps d'installation)

• Une séquence de taches chargée de la capture qui intègre directement l'ensemble de ces correctifs, limitant ainsi l'impact sur les séquences de déploiement.

A mon humble, le plus raisonnable est de se focaliser sur cette seconde approche.

B. Installer les prérequis en tant que packages

Commençons par organiser le dossier "Packages" en créant un sous-dossier dédié aux prérequis. Pour cela, à partir de la console MDT, sélectionnez la rubrique "Packages" puis cliquez sur le menu "New Folder" ou le menu contextuel et entrez un nom distinctif tel que "W7SP2-Prereq". Sélectionnez ensuite ce nouveau dossier puis cliquez sur le menu "Import OS Package" ou le menu contextuel. Sélectionnez les packages .MSU correspondants lorsque vous y êtes invité.

L'opération d'importation n'autorise pas un choix sélectif des package et prend en considération la totalité du dossier stipulé. Veillez donc à organiser ces sources (.MSU) dans des dossiers distincts entre ceux du prérequis, ceux des correctif cumulatif.

Une fois l'importation des packages terminée, cela donne quelque chose du genre :

Pour les plus rigoureux, vous pouvez créer des sous-dossiers distincts par architecture mais le processus MDT gère de lui-même ces différences et n'installe que les packages compatibles.

Notez que les MSU ont été transformés en .CAB lors de cette importation.

Par défaut, l'opération "Apply Pacthes" mentionnée précédemment s'appuie sur le profil de sélection "All packages", le sous-dossier que nous venons de créer sera donc pris en compte. Au besoin, vous pouvez modifier ce profil ou créez une tache spécifique.

C. Déclarer le package cumulatif en tant qu'application

Pour installer le "Convenience Rollup", nous allons déclarer le package cumulatif .MSU selon le principe des applications avec sources MDT.  Pour cela, il suffit de créer une nouvelle entrée en sélectionnant la rubrique  "Applications" puis de cliquer sur le menu "New Application" ou le menu contextuel.

Attention à bien distinguer cette fois, les packages selon l'architecture. Au besoin créez des sous-dossiers distincts pour organiser ce classement.

Dans l'assistant de déclaration de cette nouvelle application, sélectionnez "Application with source files" puis cliquez sur "Next". Entrez un nom distinctif tel que "Install W7x64 Convenience Rollup" dans le champ "Application Name" puis cliquez sur "Next". Utilisez ensuite le bouton "Browse" afin de sélectionner le dossier contenant le package cumulatif .MSU (ici 64 bits) puis cliquez sur "Next". Modifiez éventuellement le nom du dossier de stockage puis cliquez sur "Next". Dans le champ "Command line" entrez la commande "Wusa.exe .\windows6.1-kb3125574-v4-x64.msu /quiet /norestart" puis cliquez 2 fois sur "Next" puis sur "Finish".

D. Modifier la séquence de taches

Maintenant, il ne nous reste plus qu'à modifier la séquence de taches afin d'y ajouter cette nouvelle application. Ici j'ai pris une séquence de déploiement classique, mais le principe est le même si vous avez séparé et automatisé vos processus de capture.

Pour cela, sélectionnez la séquence de taches, (64 bits dans cet exemple) puis accédez à ses propriétés et sélectionnez l'onglet "Task Sequence".

Sélectionnez ensuite une tache située sous le groupe de tache "State Restore", plutôt au-dessus de "Windows Update (Pre Application Installation)" désactivée par défaut puis utilisez le menu "Add … General … Install Application".

Ici, le choix dépend bien sûr du contenu de la séquence de taches existante, qui peut déjà contenir une opération "Install Application" - L'action par défaut affiche toutes les applications disponibles dans l'assistant, à moins que l'écran ne soit masqué par la variable "skipApplications=YES" - Généralement, cette tâche par défaut est pondérée par l'usage de "roles" et de "bundles" pour assurer une installation plus ciblée des applications. Il est également possible de déclarer des applications obligatoires (Mandatory) dans le customSettings.ini mais c'est un autre sujet 🙂

Entrez un nom distinctif dans le champ "Name:" puis sélectionnez le radio-bouton "Install a single application" suivi du bouton "Browse" afin de choisir l'application déclarée précédemment.

Pour la démonstration, je n'ai pas géré le redémarrage final qui reste à votre discrétion, par exemple via la variable "FinishAction=Reboot",  afin que le correctif soit pleinement fonctionnel.

Le principal défaut de cette méthode est le temps considérable durant lequel la tâche d'installation du correctif semble bloquée. Il suffit d'être patient 🙂 Au risque de me répéter, il est donc préférable d'intégrer ce gros correctif dans les processus de capture afin d'associer une image WIM à jour dans vos séquences de déploiement, ou d'utiliser la méthode de "slipstreaming" décrite ci-après.

III. Injection directe manuelle (indépendante de MDT)

Cette approche nécessite une intervention manuelle sur les images de référence, afin d'injecter directement les prérequis dans l'image .WIM. Dans ce cas, il suffirait d'ajouter le "Convenience Rollup" dans la rubrique "Packages" afin que celui-ci soit injecté nativement via l'action "Apply Patches" d'une séquence de tache standard. Cela étant dit, le fait d'intervenir sur l'image WIM pour l'ajout des prérequis, peut aussi être l'occasion d'injecter ce correctif cumulatif dans la foulée. C'est donc ce que je vous propose de détailler ici.

Cette procédure n'est pas spécifique au MDT et reste valable pour la mise à jour d'une distribution sur DVD ou USB. Cette technique s'apparente à la notion de "slipstreaming" utilisée dans les générations précédentes de Windows.

A. Modification de l'image WIM via DISM

• Commençons par créer une petite structure de dossiers dédiée à ces opérations, comme par exemple

mkdir F:\W7SP1\Sources

mkdir F:\W7SP1\Mount

Je considère que les correctifs (prérequis et cumulatifs) ont été préalablement copiés dans F:\W7SP2\Updates

Pour simplifier les explications, j'utilise une distribution (fichier WIM)  de Windows 7 sp1 64 bits ne contenant qu'une seule image. En effet, dans le cas contraire, il faut réitérer ces opérations pour chacune des images contenues dans le fichier .WIM.

Pour vous en assurer, tapez la commande suivante

dism.exe /Get-ImageInfo /ImageFile:"F:\Deploy\Operating Systems\Windows 7 x64\sources\install.wim"

Au besoin, vous pouvez extraire l'image souhaitée, pat exemple la 3ème, vers un nouveau fichier "mono-image" via la commande suivante:

dism.exe /Export-Image /SourceImageFile:"F:\Deploy\Operating Systems\Windows 7 x64\sources\install.wim" /SourceIndex:3 /DestinationImageFile:F:\W7SP1\Sources\W7x64-Pro.wim

Note : Sous Windows 7, la commande DISM ne supporte pas cette option. Vous devez installer et utiliser l'outil d'un kit de déploiement, soit "Imagex /export" pour le WAIK, ou DISM pour un ADK plus récent.

• Copiez l'image .WIM de référence dans un dossier de travail (si vous n'avez pas fait d'export comme cité précédemment)

copy "F:\Deploy\Operating Systems\Windows 7 x64\sources\install.wim" F:\W7SP1\Sources\W7x64-Pro.wim

• Procédez au montage de l'image WIM comme suit :

dism.exe /Mount-Wim /WimFile:F:\W7SP1\Sources\W7x64-Pro.wim /MountDir:F:\W7SP1\Mount /Index:1

• Procédez à l'intégration des correctifs, selon l'architecture, comme suit :

dism.exe /Image:F:\W7SP1\Mount /Add-Package /PackagePath:F:\W7SP1\Updates\Windows6.1-KB3020369-x64.msu

dism.exe /Image:F:\W7SP1\Mount /Add-Package /PackagePath:F:\W7SP1\Updates\Windows6.1-KB3102810-x64.msu

dism.exe /Image:F:\W7SP1\Mount /Add-Package /PackagePath:F:\W7SP1\Updates\windows6.1-kb3125574-v4-x64.msu

Cette dernière opération prend beaucoup de temps mais considérons que c'est pour la bonne cause 🙂

• Procédez au démontage de l'image WIM comme suit :

dism.exe /Unmount-Wim /MountDir:F:\W7SP1\Mount /Commit

N'oubliez surtout pas l'option "commit" afin de valider les changements 😉

• Facultatif : Modifiez le nom de l'image et/ou sa description :

Sauf erreur de ma part, Microsoft à du oublier d'intégrer cette faculté dans DISM sans procéder un export. (Cette opération était très simple avec l'outil précédent ImageX.exe). Donc, si vous ne disposez pas de l'ancien outil, vous pouvez toujours utiliser l'outil gratuit GImageX.exe disponible ici : https://www.autoitscript.com/cgi-bin/getfile.pl?gimagex/gimagex.zip

A minima, pensez à renommer le fichier afin de le distinguer plus facilement.

B. Réintégration de l'image WIM dans MDT

Maintenant que vous disposez d'une image Windows 7 à jour, vous pouvez la réintégrer au sein de vos distributions DVD ou MDT, en lieu et place des images WIM précédentes.

Bien que cela ne soit pas impératif, il est conseillé de régénérer le catalogue (fichier .clg) via l'outillage WISM.

Pour le MDT, allez dans la rubrique "Operating System", créez un éventuel sous-dossier spécifique, puis utilisez le menu "Import Operating System" ou le menu contextuel. Choisissez ensuite "Custom image file" puis sélectionnez cette nouvelle image.

Note : Si vous avez déjà importé une autre image de référence, telle que le DVD original de Microsoft, conservez le choix "Setup and Sysprep files are not needed"

Une fois l'image importée, allez dans les séquences de taches concernées, puis modifiez simplement la tâche "Install operating system" ou créez une nouvelle séquence de déploiement.

En vous remerciant pour votre lecture et fidélité sur notre site.

Bon déploiement à tous.

I. Présentation

Tout d'abord, tous mes vœux pour cette année 2018, que vos projets s'accomplissent ! Pour ce premier tutoriel de l'année 2018, on va commencer en douceur, avec une petite astuce.

Avec les dernières versions de Windows, l'image d'installation de l'OS est au format ESD et non plus au format WIM. Pour intégrer une image d'installation dans WDS il faudra alors effectuer la conversion. Nous allons voir comment procéder.

II. Fichier ESD avec plusieurs images

Dans un même ISO d'installation de Windows, on peut avoir la possibilité d'installer plusieurs versions, par exemple : Windows 10 Standard et Windows 10 Pro sur le même ISO. Pour extraire l'image qui nous intéresse du fichier ESD, nous allons indiquer l'index de l'image.

Commencez par monter l'image ISO sur votre machine. Ensuite, pour afficher la liste des images disponibles dans votre fichier, utilisez la commande ci-dessous avec DISM, en adaptant si besoin le chemin vers le fichier ESD :

dism /Get-WimInfo /WimFile:D:/sources/install.esd

Vous obtiendrez un résultat comme ceci :

Par exemple, je souhaite extraire l'image pour Windows 10 Pro, ce qui correspond à l'index n°8.

III. Exporter l'image au format WIM

Toujours avec DISM, on va exporter l'image au format WIM à partir du fichier ESD source. Le paramètre "SourceImageFile" vous permet d'indiquer le chemin vers le fichier ESD source, alors que le paramètre "SourceIndex" sert à spécifier le numéro de l'image que l'on extraire, index n°8 dans mon cas. Enfin, le paramètre "DestinationImageFile" doit contenir le chemin vers le fichier WIM de destination.

Ce qui nous donnera :

dism /export-image /SourceImageFile:install.esd /SourceIndex:8 /DestinationImageFile:F:\install.wim /Compress:max /CheckIntegrity

L'opération prendra plus ou moins de temps selon votre machine, comptez environ 10 minutes.

Lorsque l'opération est terminée, vous obtiendrez un fichier WIM à l'emplacement de destination indiqué :

Il ne vous reste plus qu'à l'intégrer à votre WDS et à déployer Windows ! 🙂

I. Présentation

Dans ce tutoriel, nous allons apprendre à configurer un serveur DHCP de façon à pouvoir faire du boot PXE à la fois en mode BIOS et en mode UEFI, sur le même réseau. Un serveur WDS sous Windows Server 2022 sera utilisé pour tester le bon fonctionnement.

Lorsque l'on effectue un boot PXE sur une machine en mode BIOS (ou Legacy), il faut configurer les options DHCP 66 et 67. Dans le même temps, quand on utilise le mode UEFI (avec ou sans Secure Boot), il faut configurer les options DHCP 60, 66 et 67, mais avec une valeur différente pour l'option 67 qui est commune aux deux modes.

Si l'on a besoin de déployer les deux types de machines et que l'on utilise le même réseau local pour le déploiement (ce qui est généralement le cas), on se retrouve dans l'obligation d'ajuster la configuration de l'étendue DHCP en fonction de la configuration de la machine à déployer (BIOS ou UEFI). Même si l'UEFI devient le mode par défaut et se généralise, la problématique existe toujours. Pour répondre à cette problématique et gérer les deux modes en même temps, nous allons pouvoir créer des stratégies DHCP. C'est ce que nous allons voir.

En ce qui concerne l'environnement utilisé pour cette démo :

• Un serveur virtuel WDS
  • Nom de machine : SRV-WDS
  • Adresse IP : 192.168.14.11
  • Intégré au domaine Active Directory (facultatif)
• Un serveur virtuel contrôleur de domaine et DHCP
  • Nom de machine : SRV-ADDS-01
  • Adresse IP : 192.168.14.10
  • Nom de domaine : it-connect.local
• Une machine virtuelle vierge pour tester le boot PXE

Si vous avez besoin d'aide pour mettre en place le serveur WDS, suivez la vidéo complète puisqu'elle intègre cette partie.

II. VMware Workstation : basculer du mode BIOS au mode UEFI

Le firmware d'une machine virtuelle VMware Workstation Pro peut être configuré en mode "BIOS ou "UEFI". Avec Windows 10, on peut utiliser l'un de ces deux modes, tandis qu'avec Windows 11, il faut utiliser impérativement le mode UEFI pour respecter le prérequis de la puce TPM (vTPM).

Pour basculer d'un mode à l'autre, voici la marche à suivre. Accédez aux paramètres de la machine virtuelle, cliquez sur l'onglet "Options", choisissez "Advanced" dans la liste et sur la droite ajustez le paramètre "Firmware type".

Si vous souhaitez vous exercer sur une machine virtuelle, comme je le fais dans cette démonstration, conservez le mode "BIOS" pour le moment.

III. WDS : boot PXE en mode BIOS

Avant de gérer les deux modes, voyons comment utiliser le mode BIOS seul. Pour cela, nous allons configurer l'étendue "Deploiement" déjà présente sur le serveur DHCP et qui distribue des adresses IP sur le réseau "192.168.14.0/24".

• Installer et configurer un serveur DHCP sous Windows Server

Commencez par ouvrir la console DHCP, sélectionnez l'étendue DHCP utilisée pour le déploiement et effectuez un clic droit sur "Options d'étendue" pour cliquer sur "Configurer les options".

Dans l'onglet "Général", activez les options 066 et 067 en cochant la case située sur la gauche. Renseignez les deux options de cette façon :

• Option 66 : l'adresse IP du serveur PXE, ici c'est le serveur WDS
• Option 67 : le nom du fichier de démarrage, indiquez la valeur générique "boot\x64\wdsnbp.com".

Validez, vous devez obtenir ceci :

C'est suffisant pour faire du boot PXE en mode BIOS !

Pour tester, rien de plus simple : on démarre une machine virtuelle en "boot réseau" et si elle est bien sur le même segment réseau que les serveurs, elle va obtenir une adresse IP et se connecter au serveur WDS. Sur l'exemple ci-dessous, on voit bien qu'elle a pu obtenir une adresse IP et qu'il faut appuyer sur F12 pour démarrer sur le réseau.

C'est tout bon pour le mode BIOS.

IV. WDS : Boot PXE en mode UEFI (et BIOS)

Pour configurer le DHCP avec les options spécifiques au mode UEFI, le principe est le même avec des options et valeurs différentes.

Maintenant, nous allons voir comment configurer le serveur DHCP pour qu'il gère les deux modes : UEFI et BIOS.

Je vous propose de réaliser cette configuration en PowerShell. Voici les étapes à réaliser :

• Activer la prise en charge de l'option 60 dans le serveur DHCP
• Déclarer des classes de fournisseurs pour différencier les machines BIOS et UEFI
• Créer une stratégie pour gérer les machines en mode BIOS
• Créer une stratégie pour gérer les machines en mode UEFI

A. DHCP : ajouter la prise en charge de l'option 60

Dans la liste des options DHCP, l'option 60 n'est pas disponible dans la liste. À l'aide de PowerShell (ou de netsh), nous allons pouvoir remédier à cela.

Sur le serveur DHCP, en l'occurrence SRV-ADDS-01 dans mon exemple, ouvrez une console PowerShell en tant qu'administrateur et exécutez cette commande :

Add-DhcpServerv4OptionDefinition -ComputerName SRV-ADDS-01 -Name PXEClient -Description "PXE Support" -OptionId 060 -Type String

Après avoir actualisé la console DHCP, on peut voir que cette option est accessible :

Passons à la suite.

B. DHCP : déclarer les classes de fournisseurs

Pour la suite, je vous recommande d'utiliser PowerShell ISE ou Visual Studio Code pour écrire les commandes au fur et à mesure.

Commençons par définir trois variables que l'on va appeler tout au long de la procédure :

# Nom d'hôte du serveur DHCP
$DhcpServerName = "SRV-ADDS-01"
# Adresse IP du serveur WDS (PXE)
$PxeServerIp = "192.168.14.11"
# Adresse réseau de l'étendue DHCP ciblée
$Scope = "192.168.14.0"

Puis, grâce aux commandes ci-dessous, nous allons définir trois classes de fournisseurs DHCP correspondantes à des architectures différentes. Par exemple, la valeur "PXEClient:Arch:00007" correspond à du boot PXE pour l'UEFI en x64.

Exécutez les trois commandes suivantes :

Add-DhcpServerv4Class -ComputerName $DhcpServerName -Name "PXEClient - UEFI x64" -Type Vendor -Data "PXEClient:Arch:00007" -Description "PXEClient:Arch:00007"
Add-DhcpServerv4Class -ComputerName $DhcpServerName -Name "PXEClient - UEFI x86" -Type Vendor -Data "PXEClient:Arch:00006" -Description "PXEClient:Arch:00006"
Add-DhcpServerv4Class -ComputerName $DhcpServerName -Name "PXEClient - BIOS x86 et x64" -Type Vendor -Data "PXEClient:Arch:00000" -Description "PXEClient:Arch:00000"

Les modifications effectuées par ces commandes sont visibles dans :

Passons à la suite.

C. Créer les stratégies DHCP pour le BIOS et l'UEFI

Désormais, il faut créer les stratégies DHCP. Dans l'ordre suivant (même si l'ordre n'a pas d'importance) :

• Une première stratégie pour le mode BIOS x86 et x64.
• Une seconde stratégie pour le mode UEFI x86
• Une troisième stratégie pour le mode UEFI x64.

Ces stratégies vont s'appliquer sur l'étendue ciblée (variable définie précédemment) sur le serveur DHCP.

Pour créer la première stratégie :

$PolicyNameBIOS = "PXEClient - BIOS x86 et x64"
Add-DhcpServerv4Policy -Computername $DhcpServerName -ScopeId $Scope -Name $PolicyNameBIOS -Description "Options DHCP pour boot BIOS x86 et x64" -Condition Or -VendorClass EQ, "PXEClient - BIOS x86 et x64*"
Set-DhcpServerv4OptionValue -ComputerName $DhcpServerName -ScopeId $Scope -OptionId 066 -Value $PxeServerIp -PolicyName $PolicyNameBIOS
Set-DhcpServerv4OptionValue -ComputerName $DhcpServerName -ScopeId $Scope -OptionId 067 -Value boot\x64\wdsnbp.com -PolicyName $PolicyNameBIOS

Pour créer la seconde stratégie :

$PolicyNameUEFIx86 = "PXEClient - UEFI x86"
Add-DhcpServerv4Policy -Computername $DhcpServerName -ScopeId $Scope -Name $PolicyNameUEFIx86 -Description "Options DHCP pour boot UEFI x86" -Condition Or -VendorClass EQ, "PXEClient - UEFI x86*"
Set-DhcpServerv4OptionValue -ComputerName $DhcpServerName -ScopeId $Scope -OptionId 060 -Value PXEClient -PolicyName $PolicyNameUEFIx86
Set-DhcpServerv4OptionValue -ComputerName $DhcpServerName -ScopeId $Scope -OptionId 066 -Value $PxeServerIp -PolicyName $PolicyNameUEFIx86
Set-DhcpServerv4OptionValue -ComputerName $DhcpServerName -ScopeId $Scope -OptionId 067 -Value boot\x86\wdsmgfw.efi -PolicyName $PolicyNameUEFIx86

Pour créer la troisième stratégie :

$PolicyNameUEFIx64 = "PXEClient - UEFI x64"
Add-DhcpServerv4Policy -Computername $DhcpServerName -ScopeId $Scope -Name $PolicyNameUEFIx64 -Description "Options DHCP pour boot UEFI x64" -Condition Or -VendorClass EQ, "PXEClient - UEFI x64*"
Set-DhcpServerv4OptionValue -ComputerName $DhcpServerName -ScopeId $Scope -OptionId 060 -Value PXEClient -PolicyName $PolicyNameUEFIx64
Set-DhcpServerv4OptionValue -ComputerName $DhcpServerName -ScopeId $Scope -OptionId 066 -Value $PxeServerIp -PolicyName $PolicyNameUEFIx64
Set-DhcpServerv4OptionValue -ComputerName $DhcpServerName -ScopeId $Scope -OptionId 067 -Value boot\x64\wdsmgfw.efi -PolicyName $PolicyNameUEFIx64

Une nouvelle fois, cette configuration est visible dans la console DHCP. Ici, il faut accéder à la partie "Stratégies" de l'étendue DHCP ciblée. Voici le résultat :

Si l'on regarde les options de notre étendue DHCP, on peut voir qu'il y a beaucoup de valeurs. Effectivement, nous avons plusieurs fois les mêmes options, mais avec des valeurs différentes, et la bonne valeur sera appliquée en fonction de la machine qui initie la connexion.

Le serveur DHCP est correctement configuré !

D. Tester le boot PXE en UEFI

Pour tester cette configuration, il convient de basculer la machine virtuelle en mode UEFI (avec le Secure Boot actif tant qu'à faire) et de tester un boot sur le réseau. Si le serveur DHCP est correctement configuré, la machine virtuelle doit parvenir à contacter le PXE et il suffira d'appuyer sur Entrée pour initier le boot réseau et charger l'image de démarrage.

V. Conclusion

Nous venons de voir comment configurer un serveur DHCP pour prendre en charge le boot PXE en mode BIOS et en mode UEFI. Dans cet exemple, le serveur PXE est représenté par un serveur WDS mais il pourrait s'agir d'une autre solution.

Si vos serveurs sont dans un réseau différent des machines à déployer (VLANs différents, par exemple), vous devez déclarer l'adresse IP du serveur DHCP et du serveur WDS dans les options de relais DHCP de votre passerelle (routeur/pare-feu).

The post Serveurs WDS et DHCP – Comment faire du boot PXE BIOS et UEFI sur le même réseau ? first appeared on IT-Connect.

I. Présentation

Dans ce tutoriel, nous allons apprendre à installer et configurer MDT sur Windows Server 2022 pour déployer Windows 11 22H2 sur des postes de travail. Cette procédure peut s'appliquer aussi pour déployer Windows 10.

Même s'il y a aujourd'hui des solutions basées sur le Cloud comme Windows Autopilot, le couple "WDS + MDT" reste opérationnel avec la dernière version en date de Windows 11. Il fonctionne aussi avec Windows 10. Au-delà de présenter l'avantage d'être gratuite, cette solution reste performante et personnalisable pour effectuer du déploiement de machines en masse. Un serveur de déploiement avec MDT est capable de gérer des milliers de machines.

Comme point de départ, vous devez disposer d'un serveur WDS et d'un serveur DHCP. Dans le précédent épisode de cette série, nous avions abordé cette première étape.

• Serveurs WDS et DHCP - Comment faire du boot PXE BIOS et UEFI sur le même réseau ?

En ce qui concerne l'environnement utilisé pour cette démo :

• Un serveur virtuel WDS sur lequel MDT sera mis en place
  • Nom de machine : SRV-WDS
  • Adresse IP : 192.168.14.11
  • Intégré au domaine Active Directory (facultatif)
• Un serveur virtuel contrôleur de domaine et DHCP
  • Nom de machine : SRV-ADDS-01
  • Adresse IP : 192.168.14.10
  • Nom de domaine : it-connect.local
• Une machine virtuelle vierge pour déployer Windows 11 22H2

En complément de ce tutoriel, vous pouvez utiliser cette page de la documentation Microsoft qui recense aussi les liens de téléchargements.

• Microsoft Learn - ADK

II. Installer Windows ADK pour Windows 11 22H2

Commencez par l'installation du kit d'outils Windows ADK (Assessment and Deployment Kit).

• Télécharger Windows ADK pour Windows 11 22H2

Après avoir fait le téléchargement, exécutez le fichier "adksetup.exe". Suivez l'assistant. Conservez l'emplacement d'installation par défaut.

Cochez les fonctionnalités suivantes, suffisantes pour faire du MDT et cliquez sur "Installer". On peut voir qu'il faut un peu plus de 800 Mo d'espace disque.

Patientez pendant l'installation et cliquez sur "Fermer" pour fermer l'installeur de Windows ADK.

III. Installer l'add-on Windows PE Windows 11, version 22H2

Passez à l'installation du second composant que vous pouvez télécharger en utilisant le lien ci-dessous.

• Télécharger l'add-on Windows PE pour Windows 11 version 22H2

Suivez l'assistant... On peut voir que l'installation sera effectuée dans le même répertoire que Windows ADK. C'est normal puisque c'est un complément.

Cochez la seule fonctionnalité disponible et cliquez sur "Installer".

Le second composant est installé.

IV. Installer MDT sur Windows Server 2022

Désormais, c'est l'installation de MDT qui doit être effectuée, ainsi que la configuration de base.

A. Installer le composant MDT

Pour effectuer l'installation de MDT (Microsoft Deployment Toolkit), vous devez télécharger l'installeur en version 64 bits sur cette page :

• Télécharger MDT

Là encore, laissez-vous guider par l'assistant. Cliquez sur "Next".

Au moment de sélectionner les fonctionnalités, conservez le choix par défaut et poursuivez. L'installation peut être réalisée sur le disque "C:", ce qui n'empêchera pas le stockage des données sur un autre volume.

Laissez-vous guider jusqu'à la fin de l'installation... Cliquez sur "Finish" quand c'est effectué.

Désormais, sur le serveur, il y a un nouveau dossier "Microsoft Deployment Toolik" dans le menu Démarrer. Au sein de ce dossier, vous pouvez trouver la console "Deployment Workbench" qui permet d'utiliser MDT au quotidien.

B. Créer le Deployment Share

Il est temps de commencer la configuration. Ouvrez la console "Deployment Workbench", et sur la gauche effectuez un clic droit sur "Deployment Shares" afin de choisir "New Deployment Share".

La première étape consiste à indiquer l'emplacement du Deployment Share. Ce dossier sera partagé et il va contenir l'ensemble des données de MDT : images, pilotes, applications, séquences de tâches, etc... Ici, utilisez un volume différent de celui du système, comme "W:\DeploymentShare" dans cet exemple.

Pour le nom du partage, conservez la valeur par défaut. Le partage caché "DeploymentShare$" sera créé.

Pour le nom descriptif, indiquez une valeur...

En ce qui concerne les "Options", cela permet d'activer ou non certaines étapes de l'assistant de déploiement. Les choix effectués ici ne sont pas définitifs, comme nous le verrons par la suite.

Poursuivez. Prenez connaissance du résumé et cliquez sur "Next".

Patientez pendant la création du DeploymentShare.

À la fin de la création, vous pouvez le contenu du Deployment Share dans la console MDT, mais aussi à partir de l'Explorateur de fichiers Windows. On voit très bien le lien entre les deux.

C. Créer un utilisateur local dédié à MDT

Lorsque l'on va démarrer une machine en boot PXE pour démarrer sur le réseau et installer un système d'exploitation, cette machine va charger une image de démarrage qui va établir une connexion au MDT. Plus précisément, la machine va se connecter au Deployment Share.

De ce fait, la machine doit utiliser un compte utilisateur pour s'authentifier sur le partage et accéder aux données (images, pilotes, séquences de tâches, etc.).

Pour gagner du temps, PowerShell sera utilisé pour créer un compte local nommé "Service_MDT" sur le serveur. Le mot de passe est "P@ssword123!" mais vous devez le personnaliser. Ce compte n'est pas administrateur du serveur : on lui attribue uniquement des droits de lecture et exécution sur le partage.

Sur le serveur MDT, exécutez le script PowerShell suivant :

# Spécifier le nom et le mot de passe du compte de service
$ServiceAccountName = "Service_MDT"
$ServiceAccountPassword = ConvertTo-SecureString "P@ssword123!" -AsPlainText -Force

# Créer le compte local
New-LocalUser $ServiceAccountName -Password $ServiceAccountPassword -FullName "MDT" -Description "Compte de service pour MDT"

# Ajouter les droits en lecture sur le partage
Grant-SmbShareAccess -Name "DeploymentShare$" -AccountName "Service_MDT" -AccessRight Read -Force

# Attribuer au compte de service les permissions nécessaires pour accéder aux fichiers de déploiement MDT
$MDTSharePath = "\\$env:COMPUTERNAME\DeploymentShare$"
$Acl = Get-Acl $MDTSharePath
$Rule = New-Object System.Security.AccessControl.FileSystemAccessRule("Service_MDT","ReadAndExecute", "ContainerInherit, ObjectInherit", "None", "Allow")
$Acl.SetAccessRule($Rule)
Set-Acl $MDTSharePath $Acl

Suite à l'exécution de ce script, l'utilisateur "Service_MDT" a bien un accès en lecture seule sur le Deployment Share.

Vous devez vous assurer que les droits soient corrects (droits de partage et droits NTFS), sinon l'assistant de déploiement ne fonctionnera pas correctement.

V. Importer une image Windows 11 dans MDT

Afin de pouvoir déployer Windows 11 22H2 sur vos machines, vous devez importer une image ISO du système d'exploitation dans MDT. Cette image sera hébergée dans le Deployment Share. Effectuez un clic droit sur "Operating Systems" et cliquez sur "Import Operating System". Avant cela, vous pouvez choisir "New Folder" pour créer un dossier afin d'organiser vos images.

Un assistant se lance. Nous allons ajouter les sources à partir d'une image ISO de Windows 11 (qu'il faudra au préalable monter dans la VM), donc choisissez "Full set of source files". La dernière option est intéressante si vous désirez charger une image d'installation déjà disponible sur votre serveur WDS.

Cliquez sur "Browse" et indiquez le lecteur de votre serveur où se situent les sources d'installation de Windows 11. Autrement dit, sélectionnez le lecteur DVD.

Nommez cette image.

Poursuivez... L'image va être importée sur votre serveur dans le Deployment Share.

Une fois que c'est fait, cliquez sur le bouton "Finish".

Dans la liste "Operating Systems", vous retrouvez l'ensemble des versions de Windows 11 disponible sur l'image "install.wim" de votre image ISO. Supprimez les éditions que vous n'envisagez pas d'utiliser. Ici, on peut supprimer tout sauf "Windows 11 Pro" qui est la version utilisée dans cet exemple.

Passez à la suite.

VI. Créer une séquence de tâches pour Windows 11

Pour utiliser l'image d'installation de Windows 11 22H2 de façon à ce qu'elle soit déployée sur une machine, il faut l'ajouter à une séquence de tâches. Effectuez un clic droit sur "Task Sequences" et créez un nouveau dossier nommé "Windows 11" via l'option "New Folder". Cela va permettre de regrouper les tâches pour Windows 11 dans ce dossier.

Quand c'est fait, effectuez un nouveau clic droit pour cliquer sur "New Task Sequence".

Commencez par indiquer un nom qui fera office d'ID (identifiant unique) pour cette séquence de tâches, puis indiquez un nom : "Déployer Windows 11 Pro 22H2" fera l'affaire.

Poursuivez. Sélectionnez le template "Standard Client Task Sequence" de façon à ce que l'on puisse déployer l'OS. Il existe d'autres types de modèles, notamment pour capturer une image système (opération inverse).

Poursuivez. À l'étape "Select OS", il va falloir choisir l'image Windows 11 que vous venez d'importer. D'où l'intérêt d'importer l'image avant de créer la séquence de tâches.

À l'étape "Specify Product Key", une clé de produit peut être spécifiée, notamment une clé de licence en volume. Nous n'allons pas préciser la clé de produit pour le moment. Ce que l'on définit tout au long de cet assistant est modifiable par la suite.

À l'étape "OS Settings", indiquez le nom du compte utilisateur qui sera créé par défaut sur la machine déployée, ainsi que le nom de l'organisation. Ce compte sera administrateur de la machine.

À l'étape suivante, définissez un mot de passe pour le compte Administrateur local de cette machine.

Poursuivez jusqu'à la fin et une fois que la séquence de tâches est créée, cliquez sur "Finish".

Maintenant que la tâche est créée, vous pouvez l'éditer en effectuant un clic droit dessus puis "Propriétés".

L'onglet le plus intéressant s'appelle "Task Sequence" : il contient l'ensemble des tâches qui seront exécutées pendant le déploiement de la machine. Cela va du partitionnement du disque de la machine, à la configuration post-installation du système d'exploitation (pour installer des applications par exemple). Chaque tâche peut être activée ou désactivée, et si une tâche est considérée comme critique, on peut dire à l'assistant d'arrêter le déploiement si elle échoue. On peut créer, modifier et supprimer des tâches.

Par exemple, il est possible d'activer la tâche "Windows Update (Post-Application Installation)" pour mettre à jour la machine (Windows et applications Microsoft) après l'installation éventuelle d'applications. Ainsi, une fois que la machine terminera son déploiement, elle sera entièrement à jour. Pour activer cette tâche actuellement désactivée, il faut cliquer dessus et sur la droite cliquer sur "Options" et décocher la case "Disable this step". La case "Continue on error" doit être cochée pour que le déploiement se poursuive même si cette tâche échoue.

Cliquez sur "OK". Cette séquence de tâches très simple est prête.

VII. Configurer MDT pour Windows 11 (et éviter des problèmes)

Pour déployer Windows 11 avec MDT, il y a quelques ajustements à effectuer dans la configuration de MDT, sinon c'est l'échec assuré... Car vous êtes susceptibles de rencontrer plusieurs erreurs bloquantes.

A. Bug de la console MMC avec l'onglet Windows PE

Tout d'abord, lorsque l'on accède aux propriétés du Deployment Share (via un clic droit sur le Deployment Share) et que l'on clique sur l'onglet "Windows PE", on obtient l'erreur "La console MMC a détecté une erreur dans un composant logiciel enfichable et va le décharger". Et là, impossible d'accéder à cette partie de la configuration. Bloquant...!

Pour résoudre cette erreur, et comme le x86 est actif par défaut, il faut créer cette structure de dossiers vide :

mkdir "C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\x86\WinPE_OCs"

En plus, dans les propriétés du Deployment Share, il faut décocher le support du x86 (32 bits) comme sur l'image ci-dessous. Puisque Windows 11 supporte uniquement le 64 bits, ce n'est pas gênant.

Après avoir effectué ces deux modifications, l'onglet "Windows PE" fonctionne correctement.

B. Lancement d'une tâche : Script Error

Autre problématique que vous pouvez rencontrer par la suite, l'erreur Script Error avec le texte "An error has occured in the script on this page" au moment de lancer un déploiement (ou une capture) sur une machine.

Pour corriger cette erreur, Microsoft vous demande de modifier le fichier "Unatted_PE_x64.xml" situé par défaut dans :

C:\Program Files\Microsoft Deployment Toolkit\Templates

Vous pouvez modifier ce fichier avec le Bloc-notes ou un autre éditeur.

L'idée est de supprimer le contenu de ce fichier pour mettre un nouveau contenu à la place. Le contenu à intégrer est indiqué sur le site de Microsoft, à cet endroit. Visiblement, l'objectif est d'ajouter une clé de Registre pour résoudre ce problème.

Voilà, pour les deux points à corriger pour éviter les erreurs courantes.

En complément de cet article, si vous rencontrez des problèmes, consultez la page des problèmes connus sur le site de Microsoft :

• Microsoft Learn - MDT - Problèmes connus

VIII. Personnaliser le bootstrap.ini et le CustomSettings.ini

La configuration globale de MDT et de l'environnement de déploiement s'effectue au travers de deux fichiers de configuration :

• bootstrap.ini
• CustomSettings.ini

Ces deux fichiers vont influencer sur le processus de déploiement, notamment l'assistant qui permet de lancer une séquence de tâches et qui est intégré à l'image Lite Touch. Cette image que nous allons générer par la suite est l'image de démarrage qui sera chargée par les clients via le boot PXE : elle offre l'accès à l'environnement Windows PE (WinPE).

Pour accéder au contenu du fichier "CustomSettings.ini", effectuez un clic droit sur le Deployment Share via la console MDT et cliquez sur "Propriétés". Cliquez sur l'onglet "Rules".

Il y a quelques directives par défaut, mais on peut ajouter des directives supplémentaires. Dans l'exemple ci-dessous, le fait d'avoir "SkipAdminPassword=YES" permet d'indiquer que l'on ne demande pas le mot de passe "Administrateur", ce qui est intéressant d'un sens puisque l'on a défini ce mot de passe dans la séquence de tâches : inutile de le demander une nouvelle fois.

Les lignes que vous voyez par défaut sous "[Default]" sont le reflet des options cochées/décochées lors de la création du Deployment Share.

[Settings]
Priority=Default
Properties=MyCustomProperty

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

_SMSTSORGNAME=IT-Connect

TimeZone=105 
TimeZoneName=Romance Standard Time

La directive "_SMSTSORGNAME" permet de nommer l'organisation au sein de l'environnement WinPE, ce qui n'influence pas directement la machine déployée.

Par contre, les directives "TimeZone" et "TimeZoneName" permettent de préciser le fuseau horaire de la machine, ce qui est intéressant.

En ce qui concerne le fichier "Bootstrap.ini", il faut cliquer sur le bouton "Edit Bootstrap.ini" en bas à droite de la fenêtre. Ceci ouvre un Bloc-notes pour éditer le fichier. Dans ce fichier qui se charge en premier lors du démarrage de l'environnement WinPE, on va retrouver le chemin réseau vers le Deployment Share, ainsi que le nom de l'utilisateur et le mot de passe à utiliser pour se connecter à ce partage. Ici, on utilisera le compte créé précédemment.

DeployRoot=\\SRV-WDS\DeploymentShare$ : Chemin UNC vers le partage Deployment Share
UserID=Service_MDT : nom du compte utilisateur
UserPassword=P@ssword123! : mot de passe du compte utilisateur
UserDomain=SRV-WDS : nom de domaine Active Directory ou nom du serveur s'il s'agit d'un compte local

On ajoutera aussi une option pour disposer du clavier en français. Ce qui donne :

[Settings]
Priority=Default

[Default]
DeployRoot=\\SRV-WDS\DeploymentShare$
UserID=Service_MDT
UserPassword=P@ssword123!
UserDomain=SRV-WDS
SkipBDDWelcome=YES
KeyboardLocalePE=040c:0000040c

En image :

Une fois les modifications effectuées, enregistrez. Le fait d'inscrire l'identifiant et le mot de passe dans ce fichier va nous éviter de devoir saisir ces informations à chaque fois que l'on veut déployer un PC.

Nous n'allons pas effectuer de modifications avancées dans ces fichiers pour le moment. 

Profitons d'être dans les propriétés pour évoquer l'onglet "Windows PE" qui permet de personnaliser l'image Lite Touch correspondante à l'environnement Windows PE. Cet environnement minimaliste va être chargé via le boot PXE pour nous permettre de lancer une séquence de tâches.

Choisissez la "Platform" en "x64", et cliquez sur "Drivers and Patches". Ici, on peut voir que l'image Lite Touch va contenir uniquement les pilotes pour les périphériques de stockage et pour les cartes réseau. Intéressant pour que l'environnement Windows PE soit capable d'utiliser la carte réseau de votre PC pour se connecter au Deployment Share. Ce paramétrage par défaut doit être ajusté par la suite s'il y a beaucoup de pilotes intégrés à votre MDT afin d'éviter que l'image Lite Touch soit trop lourde.

Validez, et laissez de côté cette partie pour l'instant.

IX. Générer l'image Lite Touch et l'importer dans WDS

L'image Lite Touch correspond à l'environnement de démarrage en boot PXE : elle doit être générée avec la console MDT pour intégrer notre configuration, notamment les identifiants de connexion au Deployment Share. Pour initier la génération, effectuez un clic droit sur le Deployment Share et cliquez sur "Update Deployment Share".

Un assistant s'exécute. Conservez le choix par défaut, à savoir "Optimize the boot image updating process". Par la suite, lorsque des modifications légères seront apportées à votre configuration, ce choix pourra être utilisé aussi. Par contre, si vous effectuez de nombreuses modifications, ou si vous voyez qu'elles ne sont pas prises en compte, il est préférable de régénérer une nouvelle image de zéro avec le choix "Completely regenerate the boot images".

Patientez pendant la génération de l'image Lite Touch.

À la fin, vérifiez s'il n'y a pas eu d'erreur. L'assistant a généré une image 64 bits uniquement, car nous avons désactivé la prise en charge du 32 bits dans les paramètres de MDT. Cliquez sur "Finish".

Comme évoqué précédemment, c'est cette image que nous devons charger en boot PXE. Ainsi, sur le serveur WDS, il faut l'ajouter en tant qu'image de démarrage.

À partir de la console WDS, ajoutez une nouvelle image et chargez le fichier suivant :

W:\DeploymentShare\Boot\LiteTouchPE_x64.wim

Patientez pendant l'ajout de l'image... et cliquez sur "Terminer".

L'image Lite Touch est bien ajoutée et elle est en ligne. Ici, l'image "Windows 11 (Boot)" utilisée pour de précédents tests est "Hors connexion" car on souhaite utiliser uniquement l'environnement Windows PE pour solliciter le MDT. Donc, on désactiver les images "inutiles".

Vous êtes prêts à réaliser un premier essai !

X. Déployer Windows 11 22H2 avec MDT

Il va être temps de passer sur le déploiement d'une machine via MDT ! Vous devez démarrer la machine virtuelle vierge de façon à booter sur le réseau (boot PXE). Après avoir établi une connexion à notre serveur WDS (grâce au DHCP), la VM propose de charger l'image "Lite Touch Windows PE (x64)" : une bonne nouvelle !

Une fois l'image chargée, un écran gris s'affiche avec le texte "Microsoft Deployment Toolkit" et quelques secondes plus tard, un assistant se lance ! Si vous restez bloqué sur un écran gris "Microsoft Deployment Toolkit", vérifiez les droits sur le Deployment Share.

L'onglet "Task Sequence" permet de choisir la séquence de tâches à exécuter. Ici, vous devez retrouver celle créée précédemment.

Passez à l'étape suivante. On vous demande un nom pour cette machine (ce sera le nom de Windows), et vous avez la possibilité d'intégrer le domaine Active Directory par la même occasion. Nous verrons plus tard pour automatiser cette partie.

Par défaut, l'assistant intègre plusieurs étapes pour permettre la récupération de données (sauvegarde et restauration) avant de déployer la nouvelle image système. Dans ce cas présent, c'est une machine vierge, donc ce n'est pas intéressant. En modifiant le fichier CustomSettings.ini, on peut désactiver ces étapes pour gagner du temps.

L'étape "Locale and Time" permet de définir la langue, la disposition du clavier et le fuseau horaire. Tout est déjà correct grâce à la configuration effectuée dans les fichiers INI de MDT.

L'étape "Capture Image" doit être utilisée pour créer une image d'installation (image WIM) à partir de la machine actuelle. En l'occurrence ici, ce n'est pas une machine de référence, mais une machine à déployer donc on sélectionne "Do not capture an image of this computer".

Comme son nom l'indique, l'étape "BitLocker" sert à activer le chiffrement du disque de la machine. Nous n'allons pas configurer cette partie pour le moment.

Poursuivez jusqu'au lancement de la tâche.

Une fois que le séquence de tâches est lancée, MDT va enchaîner toutes les étapes configurées dans la séquence de tâches sélectionnée. Cela intègre notamment l'installation de l'image Windows 11 Pro 22H2.

Il ne reste plus qu'à patienter pendant que le déploiement est effectué...

Une fois le système installé, on peut voir que le nom correspond bien à celui indiqué précédemment : PC-W11-01. On peut voir aussi que MDT n'a pas terminé : il installe les mises à jour Windows. En effet, comme il y a des tâches post-installation, MDT continue son travail même après l'installation de l'image système. Très pratique pour exécuter des scripts, installer des applications, etc... Pour avoir une machine prête à l'emploi.

Lorsque c'est terminé, il affiche une fenêtre semblable à celle ci-dessous. L'occasion de savoir s'il y a eu des erreurs ou des avertissements, ou si au contraire, tout s'est bien passé. Il suffit de cliquer sur "Finish".

Félicitations, vous venez de déployer votre première machine Windows 11 grâce à MDT !

XI. Conclusion

Cette initiation à MDT touche à sa fin ! Le serveur MDT est en place, prêt à vous permettre de déployer de nombreuses machines en s'appuyant sur le serveur WDS qui joue un rôle essentiel pour le démarrage réseau des machines. On peut aller beaucoup plus loin dans la personnalisation avec MDT : c'est ce que nous ferons dans les prochains épisodes de cette série.

Pour ceux qui veulent déployer Windows 10 plutôt que Windows 11, la procédure est sensiblement la même. Par contre, tenez compte de ce correctif à installer en supplément.

The post Installer MDT sur Windows Server 2022 pour déployer Windows 11 22H2 first appeared on IT-Connect.

I. Présentation

Dans ce tutoriel, nous allons apprendre à intégrer au domaine Active Directory les machines déployées à l'aide de MDT. Dans cet exemple, il s'agit d'un déploiement d'une machine Windows 11 22H2, mais cela peut s'appliquer aux autres versions de Windows, y compris Windows 10.

Ainsi, lorsqu'une déploie une machine par le réseau grâce à MDT, celle-ci sera intégrée au domaine Active Directory de façon automatique. Autrement dit, on automatise le processus de jonction au domaine dans MDT.

• [Article + vidéo] Installer MDT sur Windows Server 2022 pour déployer Windows 11 22H2

Pour effectuer la jonction au domaine avec MDT, il y a au moins trois méthodes envisageables :

• Par délégation Active Directory : on donne les autorisations sur une unité d'organisation spécifique à un utilisateur (que l'on utilise dans MDT)
  • Mot de passe en clair dans le fichier de configuration MDT, à moins de l'encoder en base64 (voir ici)
• Script PowerShell : on exécute un script PowerShell dans la séquence de tâches de MDT
  • Mot de passe en clair, masqué ou chiffré dans le script
• Utilisation de l'outil SJDomain
  • Pas de mot de passe car on crée l'objet dans l'annuaire Active Directory avant le déploiement (ce n'est pas la méthode la plus simple, mais surement la sécurisée)

Dans ce tutoriel, la méthode basée sur la délégation Active Directory sera démontrée. C'est probablement la méthode la plus fréquente.

On a besoin :

• D'un compte utilisateur dédié à MDT pour la jonction des machines au domaine Active Directory (pas de compte administrateur !)
• D'attribuer des droits à l'utilisateur sur une OU spécifique (on utilise une OU dédiée pour accueillir les nouvelles machines).
• De configurer le CustomSettings.ini de MDT (pour déclarer les informations sur le domaine et les identifiants)

J'insiste sur le fait qu'en aucun cas, le compte utilisé ne doit être Administrateur du domaine !

II. Jonction au domaine AD : créer un utilisateur MDT

Commencez par créer un compte utilisateur dans l'Active Directory, en PowerShell ou à l'aide de votre console préférée. Dans mon exemple, l'utilisateur s'appelle "cds-mdt@it-connect.local".

Ce compte doit avoir les options "Le mot de passe n'expire jamais" et "L'utilisateur ne peut pas changer de mot de passe" cochées pour éviter les expirations non maitrisées du mot de passe (et par extension l'échec de la jonction au domaine).

Une fois que ce compte est créé, il faut lui attribuer des droits sur une unité d'organisation de l'annuaire. Dans cet exemple, c'est l'OU "Provisioning" qui est utilisée. Une fois l'OU créée, effectuez un clic droit dessus et cliquez sur "Propriétés".

Cliquez sur l'onglet "Sécurité" (1) puis sur "Avancé" (2) pour accéder à la gestion avancée des permissions. Une nouvelle fenêtre s'ouvre, cliquez sur "Ajouter" (3).

Cliquez sur "Sélectionnez un principal" de façon à sélectionner l'utilisateur créé précédemment. Commencez par ajouter des permissions qui s'appliquent à "cet objet et tous ceux descendants".

Sélectionnez "Créer des objets Ordinateur" et "Suppr. des objets Ordinateur" et cliquez sur "OK".

Cliquez de nouveau sur "Ajouter" pour ajouter des permissions supplémentaires. Toujours pour le même compte, mais cette fois-ci sur les "Objets Ordinateur descendants" uniquement.

Dans la liste des autorisations, décochez "Lister le contenu" et cochez les permissions suivantes :

• Lire toutes les propriétés
• Écrire toutes les propriétés
• Autorisations de lecture
• Modifier les autorisations
• Écriture validée vers le nom d'hôte DNS
• Écriture validée vers le nom principal du service
• Modifier le mot de passe
• Réinitialiser le mot de passe

Quand c'est fait, cliquez sur "OK".

Les permissions pour l'utilisateur MDT sont en place. Cliquez sur "OK" une nouvelle fois.

Voilà, la configuration de l'Active Directory est terminée. La suite se passe dans MDT.

III. Configurer la jonction au domaine automatique avec MDT

Ouvrez la console Deployment Workbench pour configurer votre MDT. Effectuez un clic droit sur votre Deployment Share sur la gauche et cliquez sur "Propriétés". Cliquez sur l'onglet "Rules".

La zone de texte à l'écran correspond au fichier de configuration CustomSettings.ini. Ici, pour que la machine soit intégrée au domaine de façon automatique, vous devez déclarer et renseigner plusieurs options :

• MachineObjectOU = l'OU ciblée
• JoinDomain = Nom DNS du domaine AD
• DomainAdminDomain = Nom court du domaine AD
• DomainAdmin = Nom de l'utilisateur
• DomainAdminPassword = Mot de passe de l'utilisateur

Ce qui donne :

En ce qui concerne l'OU ciblée par l'option "MachineObjectOU", il faut indiquer le Distinguished Name (DN) de cette OU. Quand c'est fait, cliquez sur "OK".

• Comment récupérer le Distinguished Name (DN) d'un objet AD ?

Pour finir, il faut mettre à jour l'image de démarrage Lite Touch. Effectuez un clic droit sur le Deployment Share (toujours dans la console) et cliquez sur "Update Deployment Share". Conservez l'option par défaut et continuez jusqu'à la fin...

IV. Tester la jonction au domaine AD

Pour tester, rien de plus simple : il faut déployer une nouvelle machine ! Dans mon cas, ce sera une machine virtuelle. Au moment d'arriver à l'étape "Computer Details" où l'on peut indiquer le nom de l'ordinateur, on constate que l'option "Join a domain" est activée et préconfigurée. Ici, on visualise le nom du domaine, l'OU, l'utilisateur, etc...

Laissez les valeurs précisées (elles correspondent à celle du fichier CustomSettings.ini) et démarrez le déploiement...

Une fois le système d'exploitation déployé, vous devriez constater que la machine est intégrée au domaine Active Directory ! C'est visible dans les informations système de Windows 11 :

Par ailleurs, c'est visible aussi dans l'annuaire Active Directory puisque l'unité d'organisation "Provisioning" contient un nouvel objet qui correspond à notre machine fraîchement déployée.

V. Conclusion

Voilà, nous venons de voir comment intégrer au domaine Active Directory une machine déployée avec MDT ! Grâce à l'automatisation de cette étape, ce sont quelques précieuses minutes qui seront gagnées lors du déploiement de chaque machine (au lieu de le faire manuellement). Sur le déploiement de plusieurs dizaines ou centaines de machines, croyez-moi, cela compte ! La méthode basée sur SJDomain pourra être abordée dans un prochain article.

The post Déploiement avec MDT – Intégrer les machines au domaine Active Directory first appeared on IT-Connect.

I. Présentation

Dans ce tutoriel, nous allons apprendre à capturer une image de référence Windows 11 23H2 avec MDT. Cette image, préparée par nos soins, pourra ensuite réutilisée en tant que master afin d'être déployée sur un ensemble de machines de votre parc informatique.

• Cliquez ici pour regarder la vidéo sur YouTube

La méthode que nous allons employer aujourd'hui consiste à :

1 - Prendre une machine Windows 11 qui servira de référence. Sur cette machine, nous pouvons modifier la configuration du système, installer des applications, déposer des fichiers de configuration, etc... Selon les besoins

2 - Capturer cette machine avec MDT afin que l'image Windows dans son intégralité (système + applications) donne lieu à une image WIM

3 - Ajouter cette image WIM à la liste des systèmes d'exploitation de MDT

4 - Déployer cette image de référence, qui est notre master, sur X ordinateurs

Ceci permet d'avoir une image prête à l'emploi, avec tous nos prérequis, ce qui en fait un master sur-mesure. Néanmoins, préférez autant que possible le déploiement d'applications par l'intermédiaire de MDT : ceci est la recommandation, et c'est aussi plus simple pour gérer les versions que vous souhaitez déployer, car l'image WIM capturée est figée (même si nous pouvons toujours agir dessus via les étapes de post-installation).

Dans certaines situations, cette méthode s'avère très utile, voire indispensable, et permettra d'éviter bien des galères aux équipes IT... Surtout, elle permettra de gagner un temps fou. Lors d'une précédente expérience, j'ai eu de nombreuses applications spécifiques à installer sur des machines, du style AutoCAD, Revit, Cadwork, etc... Elles sont à la fois lourdes et difficiles à déployer de façon silencieuse. De ce fait, les applications étaient installées sur une machine Windows 11, puis l'image capturée, ce qui permettait d'avoir une image prête à l'emploi avec ces applications préinstallées.

Voici quelques ressources complémentaires :

• Déployer Windows 11 23H2 avec MDT
• MDT - Intégrer les machines à l'Active Directory

II. Préparer la machine de référence

Pour cette démonstration, une machine sous Windows 11 Pro 23H2, déployée par l'intermédiaire de MDT (via la procédure décrite dans le précédent tutoriel) sert de point de départ.

Pour simuler quelques changements sur le système, je procède à l'installation de deux applications : la suite LibreOffice et VLC Media Player. Vous pourriez également décider de durcir la configuration du système à l'aide d'un outil comme HardeningKitty.

En complément, les VMware Tools sont installées dans la VM. Ainsi, lorsque cette image sera capturée puis de nouvelles VM déployées, elles bénéficieront directement des VMware Tools.

Ceci n'est qu'un exemple afin d'avoir un "master" à capturer. De votre côté, faites ce dont vous avez besoin.

Remarque : vous ne devez pas chiffrer la machine de référence avec BitLocker, sinon la capture échouera.

III. Les permissions sur le DeploymentShare

Si vous avez suivi notre tutoriel sur l'installation de MDT pour déployer Windows 11, vous avez créé le compte "Service_MDT" et vous lui avez attribué des permissions en "Lecture seule" sur le partage DeploymentShare. En fait, il s'agit de l'utilisateur déclaré dans les paramètres de MDT et utilisé par le LiteTouch (WinPE) pour se connecter au DeploymentShare.

Nous devons modifier les permissions car l'utilisateur doit pouvoir écrire dans le répertoire "Captures" afin de venir écrire l'image WIM.

Modifiez les permissions de partage :

1 - Effectuez un clic droit sur le dossier du DeploymentShare puis cliquez sur "Propriétés". Cliquez sur l'onglet "Partage" puis sur "Partage avancé".

2 - Cliquez sur le bouton "Autorisations".

3 - Sélectionnez l'utilisateur dans la liste, ici "Service_MDT".

4 - Attribuez la permission "Modifier" à cet utilisateur.

5 - Validez avec "OK".

Modifiez les permissions sur le système de fichiers NTFS :

1 - Cliquez sur l'onglet "Sécurité".

2 - Cliquez sur "Modifier".

3 - Sélectionnez l'utilisateur "Service_MDT" dans la liste.

4 - Attribuez la permission "Modification" à cet utilisateur.

5 - Cliquez sur "OK".

Voilà, cette étape est terminée.

IV. Créer une tâche Sysprep and Capture pour Windows 11

À partir de la console Deployment Workbench, créez une nouvelle séquence de tâches (via un clic droit sur "Task Sequences"), dans votre DeploymentShare.

Commencez par nommer cette séquence de tâches, par exemple "Capturer Windows 11" et poursuivez.

Lors de la sélection du template, choisissez "Sysprep and Capture".

À l'étape suivante, prenez une image système correspondante à la version que vous allez capturer. Mais, je crois que cela n'a pas de réelle importance puisque nous allons capturer notre image complète par la suite.

Poursuivez jusqu'à la fin... Tout en sachant que ces informations seront écrasées par la future tâche de déploiement de l'image.

Finalisez la création de la séquence de tâche.

Avant d'aller plus loin, accédez aux propriétés de votre DeploymentShare, puis dans l'onglet "Rules", assurez-vous d'avoir la ligne suivante :

SkipCature=NO

Sinon, l'assistant ne vous permettra pas de lancer la capture car l'étape de capture sera masquée.

En complément, si vous avez configuré le CustomSettings pour l'intégration au domaine Active Directory, vous devez commenter les lignes correspondantes, sinon l'étape "Capture Image" de l'assistant LiteTouch ne s'affichera pas (il s'agit probablement d'un bug). Une fois la capture effectuée, vous pouvez "réactiver" ces lignes.

V. Capturer image Windows 11 23H2 avec MDT

A. Démarrer la capture de l'image de référence

Désormais, nous allons initier la capture de l'image Windows 11. Vous ne devez pas démarrer en boot PXE sur le LiteTouch pour cette étape. À partir d'une session, sur la machine Windows 11 à capturer, accédez au DeploymentShare de votre serveur MDT.

À partir du nom ou de l'adresse IP. Puis, dans le répertoire "Scripts", exécutez le fichier "LiteTouch.vbs".

\\SRV-WDS\DeploymentShare$\Scripts
\\192.168.14.11\DeploymentShare$\Scripts

Actuellement, vous êtes toujours sur Windows 11, connecté à la session, et le LiteTouch démarre !

Sélectionnez la séquence de tâche "Capturer Windows 11" créée précédemment puis continuez.

Choisissez "Capture an image of this reference computer". Vous pouvez éventuellement donner un nom personnalisé à l'image WIM. Ici, la capture va générer l'image "CAPTW11-01.wim".

Continuez jusqu'à la dernière étape puis cliquez sur "Begin".

B. Le Sysprep

Le LiteTouch va commencer par initier un Sysprep sur la machine Windows. Cette étape est cruciale car Sysprep efface toutes les informations spécifiques à la machine : le SID, le nom de l'ordinateur, etc... Afin de préparer la machine au clonage ou à la création d'une image de référence (notre cas).

Patientez...

Le Sysprep est l'étape la plus délicate, disons.

Il y a régulièrement des plantages à cette étape, notamment à cause des applications Appx provisionnées dans une session et pas dans une autre. Si vous rencontrez une erreur, consultez ce fichier journal :

C:\Windows\System32\sysprep\Panther\setupact.log

Vous pouvez constater des lignes comme celle-ci :

SYSPRP Package <Nom du package> was installed for a user, but not provisioned for all users.

Dans ce cas, vous devez utiliser PowerShell pour essayer de faire le nettoyage nécessaire. Ceci peut bloquer sur une première application, puis sur une deuxième, donc consultez bien les logs si l'erreur revient après avoir fait le nécessaire.

Remove-AppxPackage -Package <Nom du package>

Pour lister les paquets de Microsoft, vous pouvez utiliser cette commande :

Get-AppxPackage -AllUsers | Where PublisherId -eq 8wekyb3d8bbwe | Format-List -Property PackageFullName,PackageUserInformation

Si vous ne parvenez pas à supprimer le paquet, essayez des commandes en supplément :

Get-AppxPackage -AllUsers <Nom du package> | Remove-AppxPackage -AllUsers
Remove-AppxProvisionedPackage -Online -PackageName <Nom du package>

Vous pouvez consulter cette page de la documentation Microsoft puisqu'elle aborde ce sujet.

Quand le Sysprep sera terminé et effectué avec succès, la machine va redémarrer.

C. Création de l'image WIM

Au redémarrage, la machine va automatiquement poursuivre la capture et procéder à la création de l'image WIM. Ceci signifie que l'image WIM est envoyée dans le répertoire "Captures" de votre DeploymentShare.

Patientez jusqu'à la fin... Ici, la capture s'est déroulée sans problème !

Sur le serveur MDT, il y a bien une nouvelle image WIM. Son poids est d'environ 9,4 Go.

VI. Ajouter l'image de référence à une séquence de tâches

Nous avons fait la capture de notre image de référence, c'est bien, mais comment l'utiliser ? Comment déployer cette image sur des ordinateurs ?

A. Importer l'image WIM dans MDT

Tout d'abord, nous devons importer l'image WIM dans MDT, en tant qu'image de système d'exploitation.

Sur "Operating Systems", effectuez un clic droit et cliquez sur "Import Operating System".

Un assistant s'exécute. Choisissez "Custom image file" comme type d'OS.

Puis, à l'étape "Image", cliquez sur "Browse" pour sélectionner l'image WIM générée par la tâche de capture. Cochez également l'option "Move the files..." pour que l'image WIM soit déplacée dans le répertoire "Operating Systems" de votre DeploymentShare. Sinon, elle sera copiée et elle occupera deux fois plus de place sur votre serveur...

Poursuivez jusqu'à la fin en suivant l'assistant... Il n'est pas nécessaire de changer les autres paramètres, si ce n'est nommer le répertoire de destination.

Voilà, l'image WIM est importée !

B. Associer l'image WIM à une séquence de tâches

Désormais, nous allons associer l'image WIM capturée à une séquence de tâches dans le but de la déployer sur des appareils. Vous pouvez créer une nouvelle séquence de tâches, ou éditer une séquence de tâches existante. Ici, nous allons éditer la tâche "Déployer Windows 11 Pro 23H2".

1 - Rendez-vous dans "Task Sequences".

2 - Double-cliquez sur la séquence de tâches à modifier.

3 - Cliquez sur l'onglet "Task Sequence" pour accéder à la liste des tâches.

4 - Sous "Install", cliquez sur la tâche "Install Operating System".

5 - Sur la droite, cliquez sur "Browse", ceci vous permet de choisir l'image WIM à déployer !

Sélectionnée l'image correspondante à votre capture :

Validez. Vous pouvez cliquer sur "OK" car c'est la seule modification que nous devons apporter à la séquence de tâches.

VII. Déployer l'image de référence avec MDT

Tout est prêt, nous n'avons plus qu'à tester cette nouvelle configuration !

Prenez une machine sur laquelle tester le déploiement... Pour ma part, ce sera une nouvelle machine virtuelle. Puis, démarrez en boot PXE pour charger l'image LiteTouch de votre MDT.

Vous voilà sur l'écran "Task Sequence" où vous pouvez sélectionner la tâche "Déployer Windows 11 Pro 23H2" à laquelle est rattachée l'image WIM de référence.

Suivez les prochaines étapes pour associer un nom à la machine, etc... Puis lancez le déploiement !

Voilà, le déploiement est terminé ! Nous avons une nouvelle machine déployée à l'aide de notre image de référence ! Les applications LibreOffice et VLC Media Player sont bien présentes, tout comme les VMware Tools !

VIII. Conclusion

En suivant ce tutoriel, vous devriez être en mesure de capturer une image de référence personnalisée avec MDT, pour créer votre propre master sur-mesure à déployer sur les machines de votre parc informatique !

The post MDT – Comment capturer et déployer un master Windows 11 23H2 ? first appeared on IT-Connect.

I. Présentation

Dans ce tutoriel, nous allons voir comment déployer des applications sur Windows 11 à l'aide de MDT, en prenant des packages au format MSI ou EXE comme source. Ainsi, lors du déploiement d'un ordinateur, le système d'exploitation Windows et les applications seront installés automatiquement.

La solution MDT peut être utilisée pour déployer l'image de Windows 11 sur un ou plusieurs ordinateurs, que ce soit une image vierge officielle ou une image personnalisée capturée à partir d'une image de référence. MDT intègre aussi une gestion des applications, ce qui va nous permettre d'installer automatiquement des applications sur les machines déployées, grâce à l'ajout d'étapes supplémentaires dans notre séquence de tâches.

En effet, dans le cas présent, les applications ne sont pas intégrées à l'image WIM déployée puisque nous allons installer un système vierge, et suite au déploiement de l'image WIM, les applications seront installées.

• Cliquez ici pour regarder la vidéo sur YouTube

En complément de ce tutoriel, voici des liens utiles :

• Déployer Windows 11 avec MDT
• La gestion des applications dans MDT
• Intégration des applications dans MDT
• Capturer une image de référence Windows 11 avec MDT

II. Télécharger les sources d'installation

La première étape consiste à télécharger les sources d'installation de l'application que vous souhaitez installer. Dans cet exemple, nous allons utiliser 7-Zip. En complément, dans la vidéo, un second logiciel sera utilisé pour la démonstration : Adobe Reader DC (qui est très particulier à déployer).

Lorsque vous téléchargez le paquet d'installation, priorisez le format MSI autant que possible, car il prend en charge les installations silencieuses, et donc automatique, des applications. Pour 7-Zip, nous avons la chance de pouvoir télécharger un package MSI :

• Télécharger 7-Zip depuis le site officiel

Une fois que le téléchargement est effectué, vous devez stocker ce fichier dans un répertoire. Par exemple, vous pouvez nommer ce répertoire "7zip". Il est important de bien organiser vos sources, surtout que l'ajout d'application dans MDT fonctionne par dossier, et non par fichier.

Ensuite, vous pouvez continuer...

III. Créer une application dans MDT

A. Installer 7-Zip avec MDT

Désormais, vous devez intégrer l'application dans MDT afin qu'elle soit référencée et que vous puissiez l'associer à une séquence de tâches (ou un rôle). À partir de la console DeploymentWorkbench, effectuez un clic droit sur "Applications" puis cliquez sur "New Application".

Remarque : si vous envisagez d'intégrer de nombreuses applications, il est important de créer des dossiers pour organiser vos applications, par métier, par exemple.

Un assistant s'exécute et vous propose de choisir le type d'application. Vous devez choisir "Application with source files" car nous allons importer dans MDT les sources d'installation de l'application. La seconde option est utile pour une application disponible sur un partage réseau distant, tandis que la troisième option permet de créer des bundles d'application, c'est-à-dire des groupes de plusieurs applications.

Indiquez les détails de l'application, en précisant, à minima, le nom de l'application. Vous pouvez aussi ajouter d'autres précisions comme la version, l'éditeur et la langue.

Ensuite, l'étape "Source" s'affiche à l'écran. Ici, vous ne pouvez pas sélectionner un fichier, mais uniquement un dossier. Ceci signifie que tout le contenu du dossier sera intégré dans MDT en tant que "source de l'application". De ce fait, il est important d'isoler le package MSI dans un répertoire où c'est le seul fichier. Ceci peut sembler étonnant, mais c'est pourtant utile dans certains cas lorsque le package MSI a besoin de s'appuyer sur un fichier de configuration INI, ou de charger un fichier de mise à jour MSP.

À l'étape "Destination", indiquez le nom du répertoire dans lequel stocker les sources de cette application. Ce répertoire sera créé dans le dossier "Applications" du DeploymentShare. Passez à la suite.

L'étape "Command Details" est cruciale puisque c'est ici que vous devez indiquer la commande à exécuter pour installer l'application. Lorsqu'il s'agit d'un package MSI, msiexec.exe doit être utilisé et l'option "/qn" permettra d'effectuer une installation silencieuse. Dans certains cas, il sera nécessaire de préciser le nom de l'exécutable(".exe") et de trouver le bon commutateur pour effectuer l'installation silencieuse (/S, par exemple), s'il existe.

msiexec.exe /i 7z2301-x64.msi /qn

MDT installera l'application à partir du fichier "7z2301-x64.msi". Il n'est pas utile de mentionner le chemin du fichier, car il est déjà référencé dans "Working directory".

Remarque : dans le cas d'un exécutable, précisez simplement le nom du fichier ".exe" ainsi que le(s) commutateur(s) à ajouter pour effectuer l'installation silencieuse.

Poursuivez jusqu'à la fin... Voilà, l'application 7-Zip a été intégré à MDT !

Désormais, vous devez ajouter l'application à une séquence de tâches pour qu'elle soit déployée.

B. Installer Adobe Acrobat Reader DC avec MDT

Le déploiement d'Adobe Acrobat Reader DC avec MDT (ou par GPO) est un peu particulier, puisqu'il faut commencer par télécharger l'exécutable sur le site officiel d'Adobe, via cette page.

Puis, vous devez ouvrir l'EXE avec 7-Zip pour extraire son contenu, car vous avez besoin des trois fichiers suivants :

Le fichier d'installation MSI nommé "AcroRead.msi" a besoin des données du fichier "Data1.cab" pour installer l'application. Sauf qu'en l'état, une ancienne version datant de 2015 sera déployée sur la machine. De ce fait, il faut impérativement installer le patch représenté par le fichier MSP "AcroRdrDCUpd2400120615.msp" pour mettre à jour l'application. Vous devez ajouter ces trois fichiers dans le répertoire avec vos sources d'installation à importer dans MDT.

Ce qui donne la ligne d'installation suivante à introduire dans MDT à l'étape "Command Details" :

msiexec.exe ALLUSERS=2 /i AcroRead.msi PATCH="\\SRV-WDS\DeploymentShare$\Adobe Reader DC\AcroRdrDCUpd2400120615.msp" /q

Pour plus de détails, référez-vous à la vidéo.

IV. Ajouter l'application à une séquence de tâches

Pour déployer une application avec MDT, vous avez plusieurs possibilités dont l'utilisation d'une étape dans la séquence de tâches ou l'affectation de l'application à un rôle.

Lorsque l'application est affectée à la séquence de tâches, toutes les machines qui seront déployées par cette séquence de tâche bénéficieront de l'application. À l'inverse, le rôle permettra d'associer une application à un rôle fonctionnel, et ce rôle sera associé à une machine. C'est une logique un peu différente.

Ici, nous allons utiliser la méthode la plus simple : la séquence de tâches. Nous allons modifier la séquence de tâches "Déployer Windows 11 Pro 23H2" déjà existante, mais vous pouvez créer une séquence de tâches de toutes pièces.

Dans les propriétés de la séquence de tâches :

1 - Cliquez sur l'onglet "Task Sequence".

2 - Sélectionnez la tâche "Install Applications" sous "State Restore".

3 - Cliquez sur "Install a single application", car l'autre option est utilisée pour la gestion par rôle (ou sélection manuelle lors du déploiement).

4 - Cliquez sur "Browse" pour sélectionner l'application.

5 - Sélectionnez l'application 7-Zip précédemment ajoutée à MDT et validez. Nous pourrions aussi choisir un bundle.

Vous pouvez aussi renommer la tâche pour indiquer "App - 7-Zip" à la place de "Install Applications" pour que ce soit plus évocateur. Sachez également que vous pouvez ajouter plusieurs tâches pour le déploiement d'applications, via le bouton "Add", ou simplement en faisant un copier-coller de celle-ci.

Validez. La séquence de tâches est prête !

Désormais, il ne reste plus qu'à déployer une nouvelle machine basée sur cette séquence de tâches pour vérifier si 7-Zip est bien installé, ou non.

V. Tester sur un PC

Lorsque la séquence de tâches sera terminée, la machine bénéficiera d'un système d'exploitation ainsi que des applications présentes dans la séquence de tâches. En tant qu'administrateur système, vous gagnez un temps précieux dans la préparation d'une nouvelle machine !

VI. Conclusion

Voilà, nous venons de voir comment installer des applications sur Windows 11 à l'aide d'une séquence de tâches MDT ! De quoi gagner du temps lors du déploiement en masse de postes de travail Windows !

Si vous déployez une application à partir d'un fichier EXE et que ce dernier ne propose pas de commutateur pour l'installation silencieuse, sachez que MDT peut tout de même déclencher l'installation. Mais, dans ce cas, c'est vous qui devez intervenir à l'écran pour déclencher l'installation.

Plutôt que de s'appuyer sur des paquets d'installation MSI ou EXE, vous pouvez utiliser MDT pour déployer des applications en utilisant le gestionnaire de paquets Chocolatey, voire même WinGet qui est intégré à Windows 11 et qui peut accéder au catalogue d'applications du Microsoft Store. Ceci pourrait faire l'objet d'un prochain article et d'une prochaine vidéo !

Le déploiement d'application est également possible avec d'autres solutions telles que Microsoft Intune et WAPT, notamment sur des machines déjà déployées :

• Installer des applications (EXE) sur Windows avec Intune
• Installer des applications (MSI) sur Windows avec Intune
• Prise en main de WAPT Enterprise pour déployer un logiciel

The post MDT – Déployer des applications MSI et EXE sur Windows 11 first appeared on IT-Connect.