Ça fait un petit moment que cette idée me trotte dans la tête et j’ai enfin trouvé le temps et l’envie d’écrire sur ce sujet : le petit outil gratuit de Microsoft, j’ai nommé « Microsoft Deployment Toolkit » (MDT).
MDT est une très bonne alternative au service WDS seul dont l’avenir est encore flou chez Microsoft (deprecated or not deprecated, that is the question…).
Dans cet article, nous allons voir comment mettre en place les bases de MDT et l’utiliser avec WDS pour faire des déploiements via le réseau de postes clients Windows 11 (fonctionne exactement pareil pour Windows 10 bien sûr).
Utiliser le couple MDT-WDS pour déployer des systèmes d’exploitation en réseau
Info ++ : Une vidéo illustrative sortira prochainement pour mieux visualiser les différentes étapes. (Chez moi “prochainement” c’est comme chez Netflix, ça viendra mais on sait pas quand ^^) |
⇒ Accès rapide aux différentes parties de cet article :
-
-
-
- Introduction
- Préparation du serveur et informations importantes
- Configuration de WDS
- Installation des outils ADK et MDT
- Première configuration de MDT via la console Deployment Workbench
- Ajout de Windows 11 et de sa séquence de tâches
- Génération de l’image de démarrage Lite Touch et ajout à WDS
- Test de déploiement de Windows 11 via le réseau
- Bonus : Effectuer les mises à jour pendant le déploiement via MDT
-
-
1. Introduction
Déployer de nouveaux postes Windows dans son infra peut être une tâche longue et répétitive. Heureusement, Microsoft nous met à disposition des outils et services qui peuvent nous faire gagner du temps.
Parmi ces outils et services, vous connaissez surement WDS, les fameux services de déploiement Windows qui permettent d’installer des systèmes d’exploitation via le réseau (boot PXE).
Si vous avez lu la partie résumée de ce post tout en haut, vous avez peut-être compris que WDS n’avait plus vraiment de beaux jours devant lui depuis la sortie des OS serveurs 2022. En effet, Microsoft ne dit pas encore officiellement qu’il va disparaître mais aujourd’hui, il est « partiellement déprécié » pouvons nous dire… En revanche il est toujours bel et bien fonctionnel donc pas de panique ! Je vous renvoie vers le lien suivant pour les infos officielles (4ème ligne du tableau) : Fonctionnalités supprimées ou plus développées à compter de Windows Server 2022
Microsoft poussent vers d’autres solutions bien plus complètes telles que MECM (Microsoft Endpoint Configuration Manager, le petit frère de SCCM), une plateforme très complète de gestion de son infra et des logiciels mais qui est payante, peut s’avérer plutôt complexe et n’est pas forcément orienté pour toutes les entreprises.
Microsoft propose également d’utiliser l’outil MDT (Microsoft Deployment Toolkit) qui est un petit outil plus puissant que WDS mais bien moins performant que MECM. On peut dire que c’est un « juste milieu ». Son avantage, c’est qu’il est gratuit et plutôt simple quand on met le nez dedans. Par contre il ne permet pas à lui seul de faire du déploiement via le réseau, c’est pourquoi il faut le coupler avec WDS pour cette partie boot PXE et donc c’est l’objet de cet article.
Info + : Même si officiellement Windows 11 n’est pas pris en charge par MDT, cela fonctionne tout de même très bien et Microsoft continue, à titre informatif, à publier les erreurs connues de déploiement de Windows 11 avec MDT… |
Je vous invite à jeter un coup d’œil à la doc officielle qui détaille les possibilités de MDT : Prise en main de MDT
Nous allons donc dans le cadre de cet article utiliser MDT, couplé au service WDS, pour déployer via le réseau une nouvelle machine sous Windows 11.
2. Préparation du serveur et informations importantes
Comme toujours avant de démarrer un tuto, je vous présente l’infra virtuelle mise en place, qui est toute simple car finalement il vous faut juste un hyperviseur au choix (ici Virtualbox en version 7.0.8), un réseau virtuel dédié et une machine virtuelle Windows Server 2019 ou 2022 (ici 2022).
Si on schématise grossièrement le réseau, ça ressemblerait à ceci :
La machine virtuelle serveur 2022 est configurée comme ceci :
- 2 CPU
- 8 Go de RAM (4 Go suffisent si vous être trop juste)
- 1 disque de stockage (C) pour l’OS de 50Go / 1 disque de stockage (E) pour les données de MDT et de WDS de 30Go
- Réseau NAT dédié 192.168.20.0/24 avec IP fixe attribuée au serveur : 192.168.20.20
Sur cette machine, renommée « SRV-DEPLOIEMENT », sont déjà installés les services suivants :
- ADDS avec création domaine « neptunet.lan »
- DNS qui gère la zone « neptunet.lan »
- DHCP avec une étendue déjà configurée et fonctionnelle (délivrant aussi les options de base : routeur, serveur DNS et nom du domaine)
- WDS sans aucune configuration à cette étape, le rôle a juste été installé.
- Services de fichiers, toujours installés par défaut sur les serveurs
Dans mon AD, j’ai créé une unité d’organisation (OU), nommée « deploiement » (oui j’ai beaucoup d’imagination merci). Cette OU sera dédiée aux PC déployés via MDT. Ils y seront automatiquement ajoutés. J’ai également créé un utilisateur, non administrateur, dans cette OU que j’ai nommé « user_mdt » et dont le mot de passe ne doit pas changer à la prochaine connexion. Ce compte sera celui utilisé pour accéder au futur partage dont a besoin MDT pour les déploiements. Cela permet d’éviter d’utilisateur le compte administrateur.
Info ++ : Vous n’êtes pas obligé de créer une OU dédiée, l’OU par défaut où les machines sont ajoutées lors de la jonction au domaine est l’OU « Computers », vous pouvez très bien utiliser celle-ci ou alors une OU selon le service d’un utilisateur etc… A vous de voir. De la même façon, vous pouvez utiliser le compte administrateur du domaine pour s’authentifier lors du déploiement via MDT mais ce n’est pas recommandé… |
Mon utilisateur « user_mdt » a reçu une délégation de contrôle sur l’OU « Deploiement » afin de pouvoir ajouter à cette OU autant d’objets ordinateurs que nécessaire car par défaut les simples utilisateurs dans l’AD sont limités à une dizaine de machines seulement.
Info + : Consultez le tuto d’IT-Connect pour mettre en place la délégation de contrôle nécessaire, il est clair et complet et fait précisément ce dont vous avez besoin : Active Directory : déléguer l’ajout d’ordinateurs au domaine |
Ceci étant dit, nous allons tout de suite passer à la configuration de WDS.
3. Configuration de WDS
Comme mon infrastructure virtuelle dispose d’un domaine, le service WDS ne sera pas en mode autonome, il sera intégré à Active Directory.
Rendez-vous dans la console de gestion des services de déploiement de Windows (via le gestionnaire de serveur ou via le menu « Outils d’administration » disponible dans le menu démarrer).
Comme un message l’indique, le serveur n’est pas encore configuré. Faites un clic droit sur le nom de la machine en haut à gauche et cliquez sur « Configurer le serveur ».
Cliquez sur suivant dans la fenêtre « Avant de commencer » qui détaille les prérequis pour ce service.
Comme dit précédemment, il sera « Intégré à Active Directory » dans le cadre de ce tuto. Si vous n’avez pas d’AD, vous pouvez cocher le mode « Serveur autonome ».
L’emplacement du dossier d’installation de WDS est important. Comme n’importe quel service, il est préférable de ne pas l’installer sur la même partition que le système d’exploitation. De mon côté, j’ai prévu un second disque de stockage monté sur la lettre E, je vais donc indiquer « E:\WDS » comme emplacement.
Je ne touche à rien dans la configuration du DHCP car mon serveur dispose du service DHCP déjà configuré, les options nécessaires seront ajoutées automatiquement, veillez juste à ce que les 2 cases soient bien cochées.
Pour la suite, je vais cocher « Répondre à tous les ordinateurs clients (connus et inconnus) », sans exiger l’approbation de l’administrateur car je n’en ai pas besoin.
La configuration du service est terminée. Comme vous pouvez le voir, le service ne démarre pas forcément de suite, ce n’est pas grave car j’ai d’autres configurations à effectuer avant de le démarrer, cliquez simplement sur Terminer.
Faites de nouveau un clic droit sur le nom du serveur puis allez dans les propriétés.
Dans l’onglet « Démarrer », cochez les deux points disant « Continuer le démarrage PXE sauf si l’utilisateur appuie sur Echap », cela permettra de ne pas avoir à appuyer sur F12 pour lancer le boot PXE sur les postes clients.
Ensuite, allez dans l’onglet « TFTP » pour décocher la case « Activer l’extension de fenêtre variable » et dans la partie « Taille maximale de bloc », vous pouvez mettre 2048 ou 4096 par exemple. Cette configuration permettra d’éviter une erreur bien connue (erreur 0x000000c1) lors du démarrage en réseau.
Appuyez sur OK pour prendre en compte les modifications et fermez les propriétés. Vous pouvez maintenant démarrer le service. Faites un clic droit sur son nom, allez dans « Toutes les tâches » puis « Démarrer ».
Le message suivant vous confirme le bon démarrage du service. Cliquez sur OK et fermez la console WDS, nous n’en avons plus besoin pour le moment et il n’y a pas à cette étape d’images de démarrage ou d’installation à ajouter.
Nous allons maintenant installer sur le serveur MDT et les outils nécessaires car pour fonctionner, MDT a besoin des outils ADK (Windows Assessment and Deployment Kit).
4. Installation des outils ADK et MDT
Pour que notre infra fonctionne correctement, nous aurons besoin d’installer tous les outils nécessaires, à savoir ADK, PE et MDT.
Commençons par ADK !
Pour rappel, ADK (le kit d’installation automatisée Windows, en français dans le texte), est une suite d’outils fournie gratuitement par Microsoft pour aider au déploiement d’OS Windows.
PE (ou WinPE) est une extension de l’outil ADK qui fonctionne de pair avec lui. C’est une sorte de « mini-OS » qui est lancé lors de l’installation de Windows ou lors de la capture d’un master entre autres. Le PE est la partie qui permet d’installation un OS sur un disque dur, c’est également par le PE qu’on peut réparer une image d’installation de Windows par exemple.
Vous pouvez télécharger ces deux outils au lien suivant : Télécharger et installer le Windows ADK
Petite mise en garde cependant ! Je ne télécharge jamais les versions données en haut de page qui sont censées être les dernières car à chaque fois je me retrouve avec des bugs relous qui me font juste perdre du temps (notamment l’onglet PE dans MDT – que vous verrez un peu plus tard – qui plante…). J’ai pris l’habitude d’aller directement dans la partie « Autres téléchargements ADK » (un peu plus bas sur la page dans le lien donné juste au-dessus de ces lignes) et de choisir les 2 derniers dispos qui sont en haut du tableau (sans tenir compte de la insider perview).
Dans mon cas, je vais prendre le kit ADK et le module PE pour Windows 11 car c’est ce que je veux déployer et ça fonctionnera également pour Windows 10. Vous n’avez qu’à cliquer sur les 2 liens en bleus pour télécharger les exécutables sur votre serveur.
Nous allons installer en 1er ADK. Lancez l’exécutable « adksetup » et suivez simplement les instructions.
Vous pouvez cliquer sur le bouton « Suivant » tout le long. Sauf si vous êtes certains de ne pas avoir besoin à un moment d’une fonctionnalité spécifique d’ADK, vous pouvez tout laisser cocher par défaut et cliquer sur le bouton « Installer ». Vous pourrez si besoin les ajouter plus tard bien entendu en relançant le setup.
Laissez faire l’installation tranquillement.
Une fois terminée, vous pouvez fermer la fenêtre et lancer l’exécutable « adkwinpesetup ».
Pour le module PE de ADK, l’installation est similaire, laissez tout par défaut.
Une fois l’installation terminée, vous pouvez fermer la fenêtre du setup de WinPE.
Vous pourrez retrouverez tout ce que contient ADK dans le menu démarrer du serveur, dossier « Windows Kits ».
Maintenant, passons à l’outil MDT !
Vous pouvez le télécharger sur la page suivante : Microsoft Deployment Toolkit (MDT)
Choisissez la version x64 après avoir cliquer sur le bouton rouge « Download ».
Double-cliquez sur le fichier « MicrosoftDeploymentToolkit_x64 » pour lancer l’installation de MDT sur votre serveur.
L’installation est vraiment très simple. Commencez par cliquer sur Next.
Cochez la case « I accept the terms in the License Agreement » et cliquez sur Next.
On va choisir d’installer la solution complète du produit donc on ne touche à rien et on clique sur Next. Si vous souhaitez que le dossier d’installation soit mis autre part que dans C:\Programmes, cliquez sur le bouton « Browse » pour déclarer le chemin que vous voulez. Personnellement, je laisse par défaut, ça me convient.
Choisissez ou non d’envoyer des infos à Microsoft sur votre utilisation du produit et cliquez de nouveau sur Next.
Et enfin, cliquez sur « Install ».
Une fois l’installation terminée (ce qui prend environ 2 secondes), vous pouvez cliquer sur Finish.
Voilà MDT est installé ! Vous pouvez retrouver les outils que MDT embarque dans le menu démarrer du serveur, partie « Microsoft Deployment Toolkit ».
Toutefois, je n’en ai pas encore vraiment fini avec lui… MDT embarque avec lui un bug bien connu qui concerne la gestion du BIOS VS l’UEFI.
Lors d’un déploiement via MDT sur un poste en UEFI, vous pourrez voir, bien trop tardivement en plus, une erreur de ce type :
Ce qui est important dans tout ce charabia, ce sont les 2 premières lignes des détails. Si vous voyez « BCDBootEx » et le code erreur « 0x80004005 », ne cherchez pas plus loin, c’est ça le problème…
Heureusement, Microsoft a mis à disposition un patch pour la corriger et une procédure que vous pourrez retrouver ici (en anglais) : Windows 10 deployments fail with Microsoft Deployment Toolkit on computers with BIOS type firmware
Comme nous sommes en train de faire une installation propre de MDT sur notre serveur, nous n’aurons pas besoin de suivre toute la procédure mais seulement une petite partie car notre MDT n’a pas encore été configuré.
Dans le lien donné précédemment, allez dans la partie « Résolution » et cliquez sur le lien en bleu « Download this update now ».
Depuis votre dossier Téléchargements, double cliquez sur le fichier « MDT_KB4564442 » pour l’exécuter. Une fenêtre va vous demander le chemin d’un dossier où extraire les fichiers. Vous pouvez laisser le dossier téléchargement qui est mis par défaut et cliquer sur OK.
Vous verrez dans votre dossier d’extraction 2 nouveaux dossiers appelés respectivement « x86 » et « x64 ».
Je n’aurais pas de système en architecture x86 dans ce tuto, donc je ne vais parler ici que de x64. Allez dans le dossier « x64 ». Vous y verrez un fichier nommé « microsoft.bdd.utility ».
Il va falloir copier ce fichier dans le dossier d’installation de MDT, que j’ai personnellement laissé par défaut.
Rendez-vous dans « C:\Program Files\Microsoft Deployment Toolkit\ » où dans le dossier où vous avez mis les fichiers de MDT. Vous y verrez un dossier nommé « Templates »
Allez ensuite dans ce dossier Templates puis ensuite dans « Distribution\Tools\x64 ».
Dans ce dossier, recherchez un fichier nommé « Microsoft.BDD.Utility » puis renommez le « Old_Microsoft.BDD.Utility » (pour en garder une copie au cas où).
Copiez ensuite à la place celui qui a été extrait suite au téléchargement du patch. Si vous n’avez pas modifier le chemin d’extraction, il est toujours dans vos téléchargements, dossier « x64 ».
Info + : Si vous avez des archi en x86, faites la même opération pour le dossier x86 et prenant le fichier extrait du patch qui doit être dans vos téléchargements, dossier « x86 ». |
Voilà, vous ne devriez pas voir la fameuse erreur qu’on voit après avoir perdu du temps. Vous avez peut être remarqué que nous sommes allez dans un répertoire nommé « Templates », ce qui veut dire « Modèles ».
Une fois configuré, MDT va utiliser le contenu de ce dossier template en le copiant ailleurs sur le serveur (nous y reviendrons plus tard). Si on met le patch dans le dossier template avant même de configurer MDT, cela évite de devoir mettre le patch partout par la suite. CQFD
Ok bon maintenant, on va enfin pouvoir passer à la configuration de MDT ! Go to the next chapter !
5. Première configuration de MDT via la console Deployment Workbench
L’utilisation de MDT se fait via la console « Deployment Workbench » que vous pouvez trouver dans le menu démarrer du serveur. Cette console ressemble à ceci :
Cette console mmc va centraliser toutes les données dont on aura besoin dans des partages appelés « Deployment Shares » (en haut à gauche de la console).
Dans ces partages, nous trouverons par exemple les fichiers d’images d’installation des OS, les fichiers d’images de démarrage également (le PE, que nous utiliserons sur WDS dans le cadre de ce tuto pour booter en réseau), les fichiers de réponses, les applications, les scripts, les séquences de tâches… tout en fait ! C’est le point névralgique pour vos déploiements à l’aide de MDT.
Notre première mission ici est donc de créer un 1er « deployment share ». Pour cela, faites un clic droit sur la partie « Deployment Shares » en haut à gauche de la console et ensuite sur « New … ».
La première fenêtre vous demande la localisation de ce futur partage sur le serveur. Je vous conseille fortement de ne pas le mettre sur le même disque que l’OS. Personnellement j’ai un disque dédié à WDS et MDT donc mon chemin sera « E:\MDT » (il faut que le dossier « MDT » existe dans le lecteur E sinon vous aurez une erreur, pensez bien de le créer en amont).
Vous pouvez ensuite changer le nom du partage. Je vais laisser ici par défaut.
Vous pouvez ajouter si besoin une petite description.
Ensuite il faudra sélectionner des options qui seront vues ou non pendant le déploiement avec MDT, les options ici sont les suivantes :
- Demande si une sauvegarde doit avoir lieu
- Demande de saisir une clé de licence
- Demande de définir le mot de passe de l’administrateur local de la future machine
- Demande si une image de capture doit être faite de la machine avant déploiement
- Demande si bitlocker doit être activé
Dans cette partie, je coche la case concernant le mot de passe de l’administrateur local en plus des 3 autres déjà cochées par défaut.
Info + : Vous pourrez choisir par la suite de bypasser ces options ou de les définir en amont si besoin. |
Vous avez ensuite un petit récap de l’ensemble, cliquez sur Next pour lancer la création du partage de déploiement.
Une fois terminée, vous pouvez cliquer sur le bouton « Finish ».
Le nouveau partage de déploiement sera disponible dans la console Deployment Workbench.
Si vous allez voir le contenu du partage sur le serveur, vous aurez cette arborescence :
C’est dans ce dossier partagé que seront stockés les fichiers de configurations, les séquences de tâches, les images d’installation et de démarrage, les applications… ouais bon bref tout quoi je l’ai déjà dit !
Vous vous souvenez peut-être qu’au début de cet article j’ai dit avoir créé dans mon AD un utilisateur dédié aux déploiements nommé « user_mdt » (si vous avez loupé l’info, retournez voir le chapitre Préparation du serveur, la prochaine fois vous serez plus attentif ).
C’est donc « user_mdt » qui va devoir accéder au dossier « deploymentshare » lors d’un déploiement mais pour cela, il faut lui donner les droits sur le partage. Pour cela, faites un clic droit sur votre dossier « deploymentshare » (que moi j’ai stocké dans mon lecteur E et qui s’appelle MDT) et allez dans ses propriétés.
Allez ensuite dans l’onglet « Partage », cliquez sur « Partage avancé », cliquez sur « Autorisations » puis sur « Ajouter » pour ajouter votre utilisateur dédié. En l’état il n’a besoin que d’un accès en lecture à ce dossier, je ne lui donne donc rien d’autres au niveau des droits. Cliquez sur OK 2 fois et fermez les propriétés du dossier « deploymentshare ».
Info ++ : Si vous n’avez pas mis votre deployment share à la racine du dossier MDT ou que vous en avez plusieurs, faites attention à l’héritage sur les droits NTFS qui peuvent sauter, il faudra les réactiver via les propriétés du dossier deployment share (le nom que vous aurez vous-même donné à ce dossier), onglet « Sécurité », bouton « Avancé » et bouton « Activer l’héritage », sinon votre utilisateur non administrateur n’accédera pas à votre partage de déploiement. |
Une fois ceci fait, nous pouvons retourner sur la console DeploymentWorkbench.
Faites un clic droit sur le nom de votre Deployment Share et allez dans ses propriétés.
Dans l’onglet Général, partie « Platforms Supported », je vais décocher x86 car je n’aurais pas d’architecture en 32 bits dans le cadre de ce tuto donc ça ne me sert à rien.
Dans l’onglet « Rules », vous pourrez automatiser tout ou parties de vos déploiements. Cela se fait grâce à deux fichiers de configuration essentiels de MDT nommés respectivement :
- Bootstrap.ini, qui sert surtout à l’initialisation du déploiement via MDT pour accéder au deploymentshare
- Customsettings.ini, qui va permettre de pré-remplir ou passer complètement les questions de base telles que le nom du PC, l’ajout à un domaine, le fuseau horaire, le mot de passe administrateur local, la conservation des données…
Certains paramètres sont déjà définis comme par exemple les cases cochées lors de la configuration du 1er deploymentshare pour dire ne pas masquer la définition d’un mot de passe pour l’administrateur local.
Le fichier « bootstrap.ini » a ajouté par défaut le chemin réseau du dossier de déploiement.
Pour éditer le fichier Customsettings.ini, cela se fait directement dans la fenêtre de l’onglet Rules.
En revanche pour modifier le fichier Bootstrap.ini, vous devez cliquer sur le bouton « Edit Bootstrap.ini » situé en bas à droite de la fenêtre ce qui aura pour effet d’ouvrir le bloc-notes.
Ne modifiez rien dans ces 2 parties.
Info + : Nous verrons lors d’un prochain article comment automatiser un déploiement, ça ne sera pas abordé dans le cadre de ce tuto. |
Dans l’onglet « Windows PE », on va pouvoir gérer la création de la partie PE du déploiement, l’équivalent du fichier « boot.wim » dispo sur les ISO de Windows. Avec MDT, les images de démarrage s’appellent des « LiteTouch ». Vous pourrez les personnaliser en y ajouter des fonctionnalités et/ou fichiers via les onglets « Features » et « Drivers and Patches » si nécessaire.
Dans cet onglet, je vais juste aller dans la partie « Platform x64 » et décocher la case « Generate a Lite Touch bootable ISO image » car je ne veux pas un ISO bootable mais seulement un fichier .wim que j’ajouterai en tant qu’image de démarrage sur WDS. Je ne le fais pas pour la « Platform x86 » car j’ai décoché précédemment la case indiquant que cette plateforme était supportée, rien ne sera généré pour une architecture en 32 bits. Cliquez sur OK et fermez les propriétés.
Bon maintenant nous allons enfin ajouter l’OS Windows 11 à déployer. Go to the next chapter
6. Ajout de Windows 11 et de sa séquence de tâches
Dans ce chapitre, on va enfin ajouter une image d’installation de Windows 11 qui sera déployée via MDT. Je n’ai pas de master donc je vais prendre le fichier « install.wim » tout fait dispo dans l’ISO officielle de Windows 11 Entreprise pour ce tuto.
Toujours dans la console DeploymentWorkbench, faites un clic droit sur « Operating Systems » puis cliquez sur « Import … ».
Choisissez la seconde option, à savoir « Custom image file » pour importer un fichier .wim.
Choisissez la source où se trouve votre fichier .wim, moi je le prends directement sur le lecteur CD.
Laissez cochée l’option « Setup files are non needed » et poursuivez.
Définissez le nom du dossier qui sera créé et contiendra l’image de Windows 11.
Un petit récap comme toujours et on lance l’ajout en cliquant sur Next.
On peut voir que le fichier wim est en cours de copie dans mon partage stocké sur E.
Quand l’image a bien été ajoutée, vous pouvez cliquer sur Finish.
Vous retrouverez l’image de l’OS Windows 11 disponible dans la console de déploiement, partie « Operating Systems ».
Nous allons maintenant créer une séquence de tâches. Pour faire simple, c’est une suite de tâches, d’actions, qui seront ou pourront être exécutées au besoin lors du déploiement (et même après) et qui sont personnalisables. Par exemple sur quel disque doit avoir lieu l’installation d’un OS, est-ce que si c’est une capture d’un master on fait un sysprep, est-ce qu’il faut exécuter tel ou tel script etc…
Pour créer cette séquence, faites un clic droit sur « Task Sequences » et cliquez sur « New Task Sequence ».
Définissez un ID (identifiant) pour cette séquence de tâche (vous pouvez mettre 01, 001, 999,truc1, etc…) et un nom également. Le nom sera vu dans MDT, veillez donc à mettre des noms assez parlant pour se repérer dans le cas où vous avez plusieurs séquences de tâches.
Ensuite on laisse par défaut sur « Standard Client Task Sequence » car ce qu’on veut c’est faire une simple installation complète d’un OS et on poursuit.
Vous devez choisir quel OS sera déployé via cette séquence de tâches. Ici je n’en ai qu’un donc c’est simple, je clique sur Windows 11 et je continue.
Laissez l’option « Do not specify a produit key at this time » qui est cochée par défaut et poursuivez.
Définissez le nom complet d’un utilisateur et l’organisation (vous pouvez laisser par défaut et juste mettre le nom de votre entreprise, ça n’a pas vraiment d’importance).
Vous pouvez ici choisir de définir le mot de passe qui sera appliqué à l’administrateur local des postes clients sous Windows 11 que vous allez déployer. Si vous le définissez ici, ce sera le même pour tous les postes et il sera écrit en tant que paramètre (en clair) dans le fichier customsettings.
Personnellement, je vais le définir lors du déploiement via MDT en direct donc je prends l’option « Do not Specify an Administrator password at this time ».
Encore un récap qui va bien qu’on Next pour lancer la création de la séquence de tâches.
Quand c’est OK, on peut fermer en cliquant sur Finish.
On la retrouve bien dans la partie « Task Sequences » de la console. Allons voir ses propriétés en faisant un clic droit sur son nom.
Dans l’onglet « Général » on retrouve les infos de base et on a la possibilité de la désactiver si nécessaire.
Dans l’onglet « Task Sequence » se trouve justement toutes les actions qui peuvent ou qui auront lieu lors de l’utilisation de MDT et l’on peut modifier les propriétés si besoin mais cela nécessite de bonnes connaissances donc on ne va rien toucher ici actuellement.
Et enfin dans l’onglet « OS Info », ce qui est intéressant c’est le bouton « Edit Unattend.xml » car il va nous permettre de voir et d’éditer le fichier de réponses qui est utilisé pour cette séquence de tâches.
La génération du catalogue contenant les composants est nécessaire et peut être un certain temps.
Par la suite, c’est l’assistant WSIM (Windows System Image Manager) qui permet de créer et modifier des fichiers de réponses qui va s’ouvrir car il a été installé grâce à l’outil ADK.
Comme vous pouvez le voir, le fichier est complet et utilise plusieurs passes. Tout n’est pas forcément utile à l’intérieur, cela dépend du scénario, et c’est personnalisable bien sûr.
Fermez la console sans rien modifier et sans enregistrer les modifications. Dans le cadre de ce tuto qui n’est qu’une initiation, on ne touche à rien.
C’est terminé pour cette partie, nous allons maintenant générer notre image « Lite Touch », c’est-à-dire l’image de démarrage que nous ajouterons ensuite à WDS.
7. Génération de l’image de démarrage Lite Touch et ajout à WDS
Pour booter, nous avons besoin d’une image de démarrage appelée ici « Lite Touch PE ». Une fois qu’on a terminé nos configurations de déploiement, on doit générer cette image.
Faites un clic droit sur votre partage de déploiement dans la console Deployment Workbench et cliquez sur « Update Deployment Share ».
Le menu va proposer 2 options, à savoir générer une image de boot complète ou alors mette à jour une existante. Vous pouvez ici laisser l’option « Optimize the boot image updating process » car il s’agit ici de la première génération de l’image de boot donc elle sera forcément complète dans tous les cas.
Info ++ : Certaines modifications dans votre deployment share nécessiteront la mise à jour de ce dernier, il faudra penser à refaire cette manipulation et remettre la future image .wim générée dans WDS sinon ça ne fonctionnera pas comme vous vous y attendez. |
Un énième récap qu’on Next pour lancer la génération.
Selon ce qui se trouve dans notre deploymentshare, cela sera plus ou moins loin donc patientez quelques minutes.
Une fois que la fenêtre vous indique que c’est terminé, vous pouvez cliquer sur Finish.
Le fichier « LiteTouchPE_x64.wim » (ou x86 si vous en avez besoin) généré sera stockée dans le dossier « Boot » de votre DeploymentShare (qui chez moi se trouve dans E:\MDT).
Il ne nous reste plus qu’à mettre ce fichier dans les images de démarrage du service WDS.
Ouvrez la console de gestion des services de déploiement Windows. Fait un clic droit « Images de démarrage » et cliquez sur « Ajouter une image de démarrage ».
Dans le champ concernant l’emplacement du fichier, vous pouvez cliquer sur Parcourir et allez chercher le fichier « LiteTouchPE_x64.wim ».
Vous pouvez changer le nom de l’image de boot et lui ajouter une description.
Cliquez sur Suivant pour lancer l’ajout à la console WDS.
L’ajout est plus ou moins rapide suivant la taille du fichier .wim, chez moi il fait 360 Mo (en compressé) donc c’est très rapide. Une fois fini, cliquez sur Terminer.
L’image de boot qui sera utilisée par MDT est disponible dans WDS. En démarrant sur le réseau, les futurs postes à déployer chargeront et utiliseront cette image de démarrage.
Notre déploiement de base de Windows 11 via MDT et WDS et désormais prêt, on se teste ça ?
8. Test de déploiement de Windows 11 via le réseau
Pour tester mon déploiement, j’ai créé une nouvelle VM vide sur mon hyperviseur, avec les caractéristiques de base de Windows 11 : UEFI, 4Go de RAM, 2 CPU, 80 Go de disque. Je l’ai mise dans le même réseau virtuel que mon serveur (bah oui sinon ça ne va pas communiquer ce n’est pas magique…).
Démarrons cette nouvelle machine et voyons ce qu’il va se passer.
Info ++ : N’oubliez pas que mon tuto est fait dans une infra virtuelle, si vous bossez en physique ou avec un autre hyperviseur, vous n’aurez pas forcément les mêmes écrans que moi donc il faudra s’adapter, l’idée reste de faire un boot PXE, la suite sera similaire. |
Si au démarrage d’une machine virtuelle sous Virtualbox dont les propriétés sont réglées sur EFI (c’est-à-dire en UEFI et non pas en BIOS), vous voyez l’écran suivant, ce n’est pas grave.
Tapez « exit » et appuyez sur Entrée. Avec les flèches de votre clavier, déplacez-vous sur « Boot Manager » et appuyez sur Entrée.
Toujours avec les flèches du clavier, déplacez vous sur « UEFI PXEv4 » et appuyez sur Entrée.
Vous verrez les écrans suivants qui signifient que votre nouvelle machine a réussi à communiquer avec le serveur qui, dans un 1er temps, lui a attribué une adresse IP grâce au DHCP et dans un 2nd temps que le service WDS a bien répondu et lui a envoyé notre image de démarrage. Ne touchez à rien.
Nous arrivons sur la page de Bienvenue de MDT. Dans la partie inférieure, pensez bien à mettre votre clavier sur « French » et cliquez sur « Run the Deployment Wizard … ».
Renseignez l’identifiant d’un compte autorisé à accéder au deployment share, son mot de passe et le nom de votre domaine. C’est là que mon fameux user_mdt intervient.
Info + : Soit vous avez créé dans l’AD un compte dédié comme je l’ai fait, soit vous utilisez le compte administrateur du domaine/serveur. Si vous n’avez pas de domaine, mettez directement le nom ou l’IP du serveur. |
Si vos identifiants sont bien valides (et vos droits sur le deployment share également), vous arriverez à la fenêtre suivante qui vous demande choisir la séquence de tâche à exécuter sur cette machine. Ici nous n’en avons qu’une donc je la sélectionne et je continue.
Vous pourrez ensuite donner un nom à l’ordinateur ou laissez celui par défaut et choisir de l’ajouter à un domaine. Dans mon cas je vais l’appeler « PC01 » et l’ajouter à mon domaine. Je vais même précisément l’ajouter à l’OU « Deploiement » créée spécialement pour cela, en utilisant les identifiants de user_mdt qui a une délégation de contrôle pour ajouter des ordinateurs dans cette OU.
Info + : Le nom d’une OU doit en fait être son « distinguished name », vous pouvez le trouver en activant les fonctionnalités avancées de la console de gestion des utilisateurs et ordinateurs AD disponible dans le menu « Affichage ». Faites ensuite un clic droit sur l’OU souhaitée, allez dans ses propriétés, onglet « Editeur d’attributs » et recherchez l’attribut nommé « distinguishedName ». En cliquant dessous vous verrez la valeur complète. |
MDT me demande ensuite si je veux conserver les données actuelles sur la machine. Ma VM est comme un PC vierge sans système d’exploitation déjà installé donc ça ne m’intéresse pas, je laisse l’option « Do not move user data and settings » et je poursuis.
Dans le même registre, MDT demande si l’on veut restaurer des données sur le système d’exploitation. Si oui vous devez au préalable les avoir stockées dans un dossier réseau. Laissez cocher « Do not restore user data and setting » et poursuivez.
On règle la langue du futur OS sur français, le clavier également et le fuseau horaire.
Vous devez maintenant définir un mot de passe pour le compte administrateur local du futur OS. Si vous n’en mettez pas, le compte administrateur sera activé quand même mais sans mot de passe (ce qui n’est pas cool…). L’activation ou non du compte administrateur peut se modifier via le fichier de réponses.
On vérifie dans le récap qu’on n’a pas fait d’erreur et quand on est prêt, on clique sur Begin.
Le déploiement a démarré.
Patientez plusieurs minutes, la machine va redémarrer plusieurs fois pendant le processus (qui est plus ou moins long).
Une fois que MDT aura terminé, le compte administrateur sera automatiquement connecté une 1ère fois sur la machine fraichement déployée. Vous verrez apparaître une dernière fenêtre de MDT vous informant du bon (ou pas) déroulement du déploiement.
Si vous redémarrez la machine ou déconnectez le compte administrateur local, vous pourrez vous authentifier avec un compte de domaine car l’ordinateur aura bien joint le domaine pendant l’installation, avec le nom donné, et sera placé dans l’OU déclarée.
Nous pouvons donc dire que le test de déploiement d’une machine Windows 11 avec MDT couplé à WDS est concluant.
9. Bonus : Effectuer les mises à jour pendant le déploiement via MDT
Comme dit précédemment, une séquence de tâches est personnalisable. On peut lui faire faire les actions que l’on souhaite et il peut être intéressant lors d’un déploiement de faire faire les mises à jour du système directement pour gagner une étape supplémentaire.
Pour cela c’est plutôt simple, allez dans les propriétés de la tâche d’installation de Windows 11, dans l’onglet « Task Sequence ».
Dans la partie gauche, recherchez le nœud « State Restore » et dépliez le pour trouver « Windows Update (Post-Application Installation) » qui doit être grisée et cliquez dessus.
Dans la partie de droite, allez dans l’onglet « Options » et décochez la case « Disable this step ». Pour valider les modifications, appuyez sur Appliquer.
Info + : Vous voyez qu’il existe deux étapes concernant Windows update, l’une « Pre-Application Installation » et l’autre « Post-Application Installation ». Leur différence se situe surtout au moment où cette étape va intervenir c’est-à-dire avant ou après l’installation d’applications via MDT si vous en avez. L’avantage de la « post » est qu’elle pourra aussi mettre à jour les produits Microsoft comme par exemple le pack Office. |
Lors du déploiement d’une nouvelle machine, après l’installation de l’OS et des applications par exemple, vous verrez l’action « Windows Update » dans la fenêtre de progression de MDT.
Les mises à jour disponibles seront alors téléchargées sur la machine fraîchement déployée.
Si votre entreprise dispose d’un serveur WSUS, vous pourrez le déclarer dans le fichier customsettings en ajoutant cette ligne (en adaptant en https et au niveau du port si besoin) :
WSUSServer=http://MonServeurWSUS:8530
Je m’arrête ici pour cette petite introduction et je vous laisse découvrir par vous-même les nombreuses possibilités de MDT.
A bientôt !