[Tuto] Utiliser des fichiers de réponses sur WDS intégré à Active Directory

J’ai reçu de nombreux messages me demandant comment utiliser un fichier de réponses sur une image d’installation dans un WDS intégré à un AD pour faire en sorte que la nouvelle machine déployée rejoigne le domaine et dispose d’un nom généré via l’onglet ADDS de la console WDS. Effectivement, il y a une très légère différence avec un WDS en mode autonome mais rien de bien méchant, nous allons voir cela

Utiliser un fichier de réponses sur une image d’installation de Windows 10/11 avec WDS intégré à l’AD pour rejoindre le domaine

Un précédent article traitait de l’utilisation de fichiers de réponses XML pour automatiser le déploiement de machines Windows 10 via le service WDS. L’article utilisait un serveur WDS en mode autonome, c’est-à-dire sans Active Directory dans l’infrastructure.

Info + : Lien de l’article traitant du même sujet mais en WDS autonome : Automatiser le déploiement d’un OS Windows avec des fichiers de réponses sur WDS

Si on l’utilise en mode intégré à son AD, en effet il peut être intéressant de faire en sorte que la machine dispose d’un nom « préconfiguré » pourquoi pas, mais surtout rejoigne automatiquement le domaine pendant le déploiement !

Pour cela, il faut compléter un tout petit peu plus le fichier de réponses que l’on va appliquer sur l’image d’installation. Plus précisément, il faut ajouter des paramètres dans la passe 4 « specialize » qui seront exécutés juste après l’installation de Windows sur le disque de la nouvelle machine et juste avant le début du mode OOBE.

Comme ce sujet a déjà été évoqué dans le précédent article, je n’avais pas envie de refaire 100% la même chose, j’ai donc décidé ici de m’amuser un peu histoire au passage de voir 1 ou 2 trucs en plus.

Je vous propose donc ici de déployer automatiquement une nouvelle machine Windows 11 64 bits en UEFI avec jonction au domaine pendant le déploiement et activation du compte administrateur local, sans création d’un utilisateur local tiers.

Info ++ : Vous le savez peut-être déjà mais officiellement le boot de Windows 11 n’est plus compatible avec WDS qui est partiellement déprécié. Si vous tentez d’installer Windows 11 depuis WDS seul (sans MDT par exemple), vous aurez une fenêtre au lancement du déploiement qui va vous bloquer. Consultez ce lien pour en savoir plus (ligne 4 du tableau) : Fonctionnalités supprimées ou plus développées à compter de Windows Server 2022

En fait pour le contourner, je vais simplement utiliser le boot de Windows 10… Tout ce qui est décrit dans cet article est valable également pour Windows 10 exactement de la même façon. Par contre n’oubliez pas d’adapter à vos besoins, ne copiez pas bêtement…

⇒ Accès rapide aux différentes parties de cet article :

1. Présentation de l’infrastructure en place

Dans le cadre de cet article, j’ai déjà une infra complètement prête avec un serveur nommé « VM-AD-WDS » sur lequel sont installés les services AD DS et DNS qui gèrent le domaine « neptunet.lan », le service DHCP qui a été configuré avec les options de base (étendue, passerelle, dns, nom du domaine) et le service WDS a été installé mais pas encore configuré.

Dans mon AD, j’ai créé un utilisateur « user-wds » (non administrateur) qui sera utilisé pour les déploiements via WDS et une Unité d’Organiation (OU) appelée « Deploiement » destinée à accueillir les nouveaux PC dans le domaine.

Info ++ : Vous n’êtes pas obligé de faire une OU dédiée. Par défaut les postes ajoutés au domaine iront dans l’OU Computers. De la même façon, vous n’êtes pas obligés de créer un utilisateur dédié mais sachez que pour l’automatisation via un fichier de réponses, le mot de passe sera en clair, c’est donc préférable de ne pas utiliser un compte administrateur…

Je restreins également l’accès au partage de WDS nommé « reminst » à ce seul utilisateur par mesure de sécurité (hors système et administrateurs bien sûr). Si un autre utilisateur que lui tente d’aller sur le partage créé par WDS, l’accès sera refusé. S’il tente d’initier un déploiement, il verra cette erreur :

Cela ne peut se faire qu’après la configuration du serveur WDS pour que le partage Reminst s’initie. Il faudra aller dans les propriétés du dossier de WDS, onglet « Partage », bouton « Partage avancé », bouton « Autorisations », supprimez le groupe « Utilisateurs authentifiés » et ajouter « user-wds » (ou votre utilisateur à vous bien sûr) et lui donner les droits à minima de Lecture (et le droit de modifier également si vous capturez des masters avec ce compte).

Si ce n’est pas fait, ça n’empêchera pas vos déploiements de fonctionner donc pas de panique, ils sont juste open-bar

L’utilisateur « user-wds » a reçu une délégation de contrôle sur l’OU « Deploiement » pour créer des objets ordinateurs dans cette OU spécifiquement.

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

Le kit ADK pour Windows 11 (vous pouvez prendre le kit ADK pour Windows 10, c’est pareil) avec juste les outils de déploiement a aussi été installé sur mon serveur pour pouvoir créer les fichiers de réponses dont je vais avoir besoin et le catalogue a été généré en prenant le fichier « install.wim » dispo dans l’ISO de Windows 11 Entreprise Evaluation (ou celui d’un Windows 10, une fois encore ça ne change rien, j’utilise les mêmes fichiers de réponses pour 10 et 11).

Si vous ne savez pas où trouver ADK, comment l’installer sur le serveur, ou comment générer le fichier catalogue dont il a besoin, consultez le chapitre 2 de cet article : [Tuto] Automatiser le déploiement d’un OS Windows avec des fichiers de réponses sur WDS

2. Configuration de WDS

Nous allons maintenant passer à la configuration de WDS. Ouvrez la console de gestion des services de déploiement Windows. Il faut commencer par configurer le serveur. Pour cela faites un clic droit sur son nom en haut à gauche et cliquez sur « Configurer le serveur ».

Cliquez sur suivant dans la fenêtre « Avant de commencer ».

Cochez l’option « Intégré à Active Directory » et cliquez sur Suivant.

Sélectionnez l’emplacement du dossier d’installation de WDS, pour ma part il sera sur mon lecteur E dans un dossier nommé « WDS » (évitez de le mettre à la racine de l’OS, prévoyez plutôt un second disque de stockage).

Ne rien modifier dans la fenêtre « Serveur DHCP proxy » et cliquer sur Suivant.

Cochez « Répondre à tous les ordinateurs clients (connus et inconnus) », sans exiger l’approbation de l’administrateur.

La configuration du service est maintenant terminée, ce n’est pas grave si le service ne démarre pas de suite car il y a d’autres configurations à effectuer. Cliquez simplement sur Terminer, nous le démarrerons plus tard.

Faites de nouveau un clic droit sur le nom du serveur en haut à gauche de la console et allez dans les propriétés.

Dans l’onglet « Démarrer », cochez les deux options « Continuer le démarrage PXE sauf si l’utilisateur appuie sur Echap », cela évite de devoir appuyer plusieurs fois sur F12 pour booter en réseau sur les postes clients après la communication avec WDS.

Ensuite, allez dans l’onglet « TFTP ». Dans la partie « Taille maximale de bloc », mettez au moins 2048 ou 4096 et décochez la case « Activer l’extension de fenêtre variable ».

Info ++ : Cette étape n’est pas nécessaire mais pourra le devenir en cas d’apparition de l’erreur 0x000000c1 lorsqu’un client va booter sur le réseau et tenter de communiquer avec le serveur.

Allez dans l’onglet « AD DS », c’est celui qui ici nous intéresse le plus. Le champ « Format » de la partie « Stratégie de noms de clients » sert à définir les noms qui seront générés pour les futurs machines jointes au domaine et déployées via WDS.

Par défaut, une machine déployée via WDS portera le login de l’utilisateur qui va initier le déploiement et un numéro donc par exemple « administrateur1 », ensuite « administrateur2 », etc… les numéros vont s’incrémenter automatiquement s’ils existent déjà dans l’AD.

Vous pouvez définir ici une stratégie de noms pour vos futurs postes clients mais attention il faut respecter certaines règles :

Longueur maximale du nom de 15 caractères
Utiliser uniquement les caractères suivants :
- Lettres de A à Z en minuscules ou en majuscules
- Chiffres de 0 à 9
- Le tiret
Ne mettez pas d’espace ou de « _ » dans le nom de vos PC
Possibilité d’utiliser quelques variables et de les tronquer si besoin

Info + : Pour plus d’informations sur la stratégie de noms d’ordinateurs et surtout les variables qu’il est possible d’utilisateur, je vous renvoie vers ce lien : Onglet AD DS

Si vous ne respectez pas ces règles, vos PC ne rejoindrons pas le domaine et vous pourrez même avoir des erreurs lors du déploiement donc soyez attentif.

Personnellement ici je vais utilisez la stratégie suivante : pc-%8Username-%03#

Elle signifie que toutes les machines déployées auront pour préfixe « PC- », ensuite les 8 premiers caractères du login de l’utilisateur qui va lancer le déploiement (chez moi c’est la mission de l’utilisateur « user-wds » qui ça tombe bien n’a que 8 caractères et qui utilise un tiret :-D), ensuite encore un tiret qui sera suivi d’une numérotation sur 3 chiffres allant de 001 à 999. La première machine déployée qui va intégrer l’AD devra donc logiquement s’appeler : pc-user-wds-001.

La partie inférieure de l’onglet AD DS est nommée « Emplacement du compte d’ordinateur ».

Cet espace permet de définir dans quelle OU seront placés les nouvelles machines quand jointes au domaine. Par défaut, elles iront dans l’OU « Computers ».

J’ai choisi de les mettre dans une OU dédiée que j’ai nommé « Deploiement », je vais donc cliquez sur le bouton « Parcourir » pour sélectionner cette OU dans mon arborescence AD.

Au final, mon onglet AD DS ressemble à ceci :

Appuyez sur OK pour prendre en compte les modifications effectuées et fermez la fenêtre des propriétés. Nous pouvons maintenant démarrer WDS, faites un nouveau clic droit sur son nom, puis « Toutes les tâches » et enfin « Démarrer ».

Cliquez sur OK pour valider le démarrage des services de déploiement.

Vous pouvez maintenant ajouter des images de démarrage et d’installation dans la console WDS.

Pour ajouter une image, faites un clic droit sur la catégorie que vous voulez et « Ajouter une image de … », il suffit ensuite d’aller chercher les images selon l’endroit où elles sont stockées sur le serveur (ou directement dans les fichiers ISO).

Je vous rappelle que je me sert ici du fichier « boot.wim » présent dans le dossier « Sources » l’ISO de Windows 10 Entreprise en tant qu’image de démarrage ! Souvenez-vous que j’ai précisé en début d’article que le boot de Windows 11 était désormais bloqué.

Pour une image d’installation, il faut créer un groupe d’images avant de pouvoir en importer une dedans mais ce n’est pas bien compliqué donc on passe les détails pour cette partie.

Pour l’image d’installation, j’ai pris le fichier « install.wim » située dans le dossier « Sources » l’ISO de Windows 11 car je n’ai pas d’image de master, après avoir créé un groupe d’images d’installation que j’ai nommé « Windows11 ».

Info + : Si vous disposez d’une image master à déployer, utilisez la comme image d’installation directement.

Mettez à vos images les noms et les descriptions que vous souhaitez.

Une fois que vous en êtes à la même étape que moi, nous pouvons nous attaquer aux fichiers de réponses, à commencer par le fichier qui va concerner l’image de démarrage.

3. Création du fichier de réponses pour l’image de démarrage

Pour rappel, une image de démarrage est l’image qui va initier l’installation de Windows sur le disque d’une machine. Nous allons automatiser ce processus avec un premier fichier de réponses.

A ce stade vous devez avoir déjà installé ADK et généré le catalogue des composants de Windows 11 (ou Windows 10). Sinon allez voir le lien qui suit comme déjà dit plus haut, le chapitre 2 explique les manipulations : [Tuto] Automatiser le déploiement d’un OS Windows avec des fichiers de réponses sur WDS

Ouvrez la console « Assistant Gestion d’Installation ». Au centre de cette console vous trouverez la partie « Fichier de réponses » et en bas à gauche la partie « Image Windows » qui contient les composants (« components ») et les paramètres que nous allons mettre dans notre fichier de réponses et personnaliser.

Info + : Si la partie fichier de réponses est vide, cliquez simplement en haut à gauche sur « Fichier » puis sur « Nouveau fichier de réponses ».

Nous allons commencer par déclarer dans le fichier de réponses que le setup (l’installeur de Windows) doit être en français.

Déroulez le menu « Components » en bas à gauche et recherchez « amd64_Microsoft-Windows-International-Core-WinPE… ». Une fois trouvé dans la liste, faites un clic droit dessus et cliquez sur « Ajouter le paramètre à la passe 1 windowsPE ».

Le paramètre sera ajouté à la passe « windowsPE » dans votre fichier de réponses en cours de construction.

Sur la droite vous avez les propriétés du paramètre, sur lequel vous devrez préalablement cliquer, que vous allez pouvoir personnaliser. Pour passer en français, vous devez écrire « fr-Fr » dans les paramètres de droite comme ceci :

Il faut faire la même chose pour le paramètre « SetupUILanguage ».

C’est bon pour la partie langue. Recherchez maintenant dans « Components » le paramètre « amd64_Microsoft-Windows-Setup… », faites un clic droit dessus et ajoutez le lui aussi à la passe 1.

Ça va ajouter pas mal de paramètres au fichier de réponses dont nous n’avons pas besoin ici.

Nous allons garder uniquement « DiskConfiguration » et « WindowsDeploymentServices ». Vous pouvez supprimer tous les sous-paramètres avec un clic droit et le bouton « Supprimer » (ou la touche « Suppr » qui va plus vite). Voilà ce que nous allons conserver précisément :

Dans un premier temps, on va gérer la configuration du disque et le partitionnement de celui-ci. Je vous rappelle que je vais le configurer pour une machine en UEFI, la config va donc varier de celle d’un BIOS.

Faites un clic droit sur « DiskConfiguration » et sur « Insérer un nouvel élément Disk ».

Cliquez sur « Disk » et dans la partie de droite, il faut déclarer son ID, c’est-à-dire son numéro qui sera le zéro car c’est le premier disque de la machine (oui le 1^er c’est le 0) et déclarer le « WillWipeDisk » sur « true » pour préciser qu’il faut effacer tout le contenu déjà présent dessus.

Ensuite faites un clic droit sur « CreatePartitions » puis sur « Insérer un nouvel élément CreatePartition ».

Répétez la même opération une seconde et une troisième fois car nous avons besoin de 3 partitions en UEFI (dont obligatoirement 2 au minimum dont une dédiée EFI et l’autre pour l’OS). Faites également la même manipulation mais cette fois-ci seulement 2 fois sur le paramètre « ModifyPartition » pour qu’une fois les partitions créées nous puissions les modifier pour celles où cela est nécessaire. Cela vous donnera ceci :

Dans le 1^er « CreatePartition », nous allons déclarer l’ordre pour indiquer que c’est la première partition en indiquant bien le numéro « 1 » dans le champ « Order » (oui cette fois on commence à 1 et non pas à 0 ), la taille en Mo doit être de 100 minimum et au niveau du type il faut sélectionner « EFI ». Cela donne ceci :

Info + : Une partition EFI est ce qu’on appelle la partition système, c’est sur cette partition que la machine démarre Pour plus d’informations sur les différentes partitions pour des disques UEFI, je vous renvoie directement vers la doc Microsoft : Partitions de disque dur UEFI/GPT

Pour une meilleure gestion des partitions, il est conseillé d’ajouter également une partition réservée à Microsoft appelée « MSR » d’une taille de 16Mo.

Dans le 2^ème « CreatePartition » disponible, nous allons déclarer « 2 » dans le champ « Order », mettre une taille de 16Mo et sélectionner « MSR » dans le type. Cela donne ceci :

Et enfin dans le dernier « CreatePartition » disponible, nous allons préparer la partition pour accueillir le système d’exploitation. Pour prendre toute la place restante sur le disque, il faut la déclarer comme « Extend : true » et ne pas définir de taille. Au niveau de son ordre, c’est ici la 3^ème. Pour le type, ce sera une partition principale (« Primary »), on y trouvera notre OS installé.

Nous avons déclaré la création des partitions, maintenant il faut les modifier, c’est-à-dire les préparer.

Dans le 1^er « ModifyPartition », nous allons gérer celle prévue pour l’UEFI. Il faut mettre le format sur « FAT32 », éventuellement lui donner un nom (appelée ici « label »), déclarer l’ordre dans lequel se sera fait donc ici le 1 et lui donné un ID. Cette ID doit correspondre à celui donné lors de la création des partitions, pour moi c’est le 1 car j’ai créé en 1^er la partition pour l’UEFI.

Dans le 2^ème « ModifyPartition », on va gérer le système d’exploitation directement. Le format sera cette fois en NTFS. Au niveau du label je mets par habitude soit « OS » soit « System » pour l’identifier et il faut lui donner une lettre de lecteur qui est le « C ». Pour l’ordre, ça sera le 2^ème et côté « partitionID » le 3^ème car le 2^ème et déjà pris par ma partition MSR.

La partition MSR n’a pas besoin d’être modifié donc on ne crée pas de paramètre supplémentaire pour elle. C’est bon pour la configuration du disque.

Passons maintenant à la connexion à WDS et au choix de l’image d’installation qui devra être déployée sur les futures machines du parc.

Cliquez sur le paramètre « WindowsDeploymentServices », sur « ImageSelection » puis sur « InstallImage ». Il faut ici déclarer le nom de l’image à installer, le nom du fichier correspondant dans WDS à cette image et le groupe dans lequel elle se trouve. Pour moi ça donne ceci :

Info + : Si vous ne vous souvenez pas de ces informations, allez dans la console WDS, partie images d’installation et dans les propriétés de votre image, vous verrez les 3 champs dont vous avez besoin et serez sûr de ne pas faire d’erreur.

Ensuite dans le paramètre « InstallTo », il ne reste plus qu’à préciser le numéro du disque et le numéro de la partition sur lequel installer l’image, chez moi c’est le disque 0, partition 3 car c’est la 3^ème qui sera pour mon système d’exploitation, les 2 autres étant pour l’EFI et le MSR.

Pour terminer la configuration de la passe 1, il faut déclarer les identifiants qui seront utilisés pour se connecter au partage de WDS et qui vont initier l’installation. Ceci se passe dans le paramètre « Credentials » situé dans « Login ». Je vous rappelle que de mon côté j’ai prévu un utilisateur dans l’AD nommé « user-wds ».

Info ++ : Attention le mot de passe ici va apparaître en clair dans le fichier de réponses, soyez prudent si vous utilisez un compte administrateur ou prévoyez de chiffrer le fichier XML final. Si vous ne mettez pas de mot de passe ou que vous n’utilisez pas le paramètre Login, vous arriverez lors de vos déploiements au choix de la langue dont la configuration dans le fichier de réponses sera ignorée. Vous pourrez alors vous loguer en toute sécurité. Je vous conseille de ne pas automatiser cette partie par sécurité même si je vais la décrire ici parce que j’adore me contredire

Le 1^er fichier de réponses est terminé, cliquez sur la petite icône dans le bandeau de haut avec une coche orange pour vérifier qu’il n’y a pas d’erreur. Toute erreur sera indiquée dans la partie « Message » de la console.

Si tout est OK, enregistrez le fichier où vous voulez avec un nom reconnaissable, personnellement je vais l’appeler « unattend_PE_EFI » et le mettre dans « E:\WDS\WdsClientUnattend ».

Il faut désormais le déclarer dans la console WDS. Allez dans les propriétés du serveur WDS via la console de gestion du service, onglet « Client ».

Cochez la case « Activer l’installation sans assistance » et suivant votre architecture, cliquez sur le bouton Parcourir pour aller chercher votre fichier de réponse fraichement enregistré. De mon côté ça sera UEFI en x64.

Validez la modification et cliquant sur OK.

C’est terminé pour ce 1^er fichier de réponse qui ne va concerner que la partie « Image de démarrage », passons maintenant au plus intéressant qui va concerner l’image d’installation.

4. Création du fichier de réponses pour l’image d’installation

Encore un petit rappel : une image d’installation est le système d’exploitation lui-même, ça peut être une image d’un PC que l’on aura préalablement personnalisé par exemple.

Créez un nouveau fichier de réponses dans la console WSIM (Assistant Gestion d’Installation).

Nous allons commencer par ajouter tous les paramètres qui vont concerner la jonction au domaine.

Par défaut, WDS utilise son propre fichier de réponses pour cette partie et l’ajout d’un autre fichiers de réponses à une image d’installation va prendre le pas sur le fichier par défaut.

Vous pouvez voir ce fichier de réponses par défaut qui est situé dans « C:\Windows\System32 » et qui s’appelle « WdsUnattendTemplate.xml ». Vous pouvez ouvrir ce fichier mais il ne faut pas le modifier.

Si vous l’ouvrez dans WSIM, vous verrez qu’il ressemble à cela :

Il comprend seulement 2 paramètres dont l’un est complètement vide mais sa présence est nécessaire pour l’attribution du nom d’un PC qui va joindre le domaine et l’autre contient un paramètre nommé « UnsecureJoin » qui est réglé sur « True ».

Ce paramètre signifie que la jonction au domaine se fera de façon non sécurisée, il faut plutôt comprendre sans authentification préalable. Sauf que pour déployer une machine via WDS, il faut forcément s’identifier avec un compte, souvenez-vous que j’ai créé dans mon AD mon utilisateur « user-wds » spécialement pour cela et que dans mon précédent fichier de réponses, c’est lui qui va s’authentifier pour lancer le déploiement et c’est également lui qui a reçu une délégation de contrôle pour ajouter des PC dans l’OU « Deploiement ». Donc techniquement, on peut se permettre ici d’utiliser le mode Unsecure Join.

Info ++ : Vous pouvez choisir de mettre ce paramètre sur false, dans ce cas vous devrez déclarer en plus un credentials. Consultez le lien de Microsoft suivant (en anglais) pour plus d’info sur les 2 méthodes : Automating the Domain Join

Comme dit un peu plus haut, si vous mettez un fichier de réponses à une image d’installation dans WDS sans rajouter ces paramètres, le fichier de réponses par défaut sera ignoré et la jonction au domaine ne se fera pas. Il faut donc que ces paramètres soient également ajoutés à votre propre fichier de réponses.

Dans votre nouveau fichier de réponses (ne modifiez pas celui par défaut hein !), cherchez le components « amd64_Microsoft-Windows-Shell-Setup… » et ajoutez le à la passe 4 avec un clic droit.

Info + : La passe 4 « specialize » va intervenir tout de suite après l’installation de l’OS sur le disque dur de la machine et juste avant le lancement de l’OOBE.

Cela va ajouter une fois encore grand nombre de paramètre qui ici ne vont pas vraiment servir donc on peut tous les supprimer. Le seul champ ici qui m’intéresse est celui sur le paramètre principal et qui s’appelle « ComputerName ». Je vais seulement mettre un « * » dedans car si le paramètre est vide, il ne sera pas enregistré.

Le symbole « * » sera remplacé lors du déploiement par la stratégie de noms de clients que vous avez déclaré dans l’onglet AD DS de WDS.

Ensuite, ajoutez à la passe 4 toujours, le composant « amd64_Microsoft-Windows-UnattendJoin… ».

Vous pouvez supprimer les paramètres « Credentials » et « Provisioning », nous n’en avons ici pas besoin.

Et dans « Identification », mettez bien « true » au paramètre « UnsecureJoin ».

Voilà, c’est tout pour la partie jonction au domaine avec application de la stratégie de nom que vous avez définie.

Maintenant nous allons voir la gestion des utilisateurs locaux, plus précisément sa « non gestion ». Je ne veux pas créer spécialement un utilisateur local, je préfère ici activer le compte administrateur qui existe déjà dans toutes les machines Windows et lui définir un mot de passe.

Par contre, je ne veux pas pendant l’installation que ça me demande de créer un autre utilisateur, sinon ça ne me sert à rien…

Info + : Pour passer l’étape de création d’un utilisateur local de l’OOBE, il est nécessaire d’avoir au moins un compte utilisateur membre du groupe local « Administrateurs » selon Microsoft (lien en anglais ici : Avoid creating a local user account). Donc soit, vous créez via votre fichier de réponses un utilisateur, soit, vous utilisez le compte admin local intégré qui doit être activé (et avoir un mot de passe, c’est mieux…)

Pour faire cela, il va falloir faire exécuter des commandes pendant la passe 4 « specialize ». L’une va activer le compte administrateur, l’autre va faire en sorte de bypasser la demande de création d’un utilisateur pendant l’OOBE.

Dans votre fichier des réponses en cours de création, cherchez le composant « amd64_Microsoft-Windows-Deployment… » et ajoutez le à la passe 4.

Vous pouvez supprimer le paramètre « ExtendOSPartition » qui ne nous servira pas. Il va vous rester « RunSynchronous » et « RunAsynchronous ».

La différence réside dans ce que vous voulez faire précisément. Si vous avez besoin de faire une action complète avant d’en lancer une autre, vous devez utiliser « RunSynchronous ». Si au contraire 2 actions peuvent être faites en même temps, vous pouvez utiliser « RunAsynchronous ».

Dans notre cas ici, les 2 commandes que nous allons utiliser ne sont pas complémentaires, elles pourront donc être lancer en asynchrone sans problème.

Faites un clic droit sur « RunAsynchronous » puis sur « Insérer un nouvel élément RunAsynchronousCommand ». Vous pouvez supprimer « Credentials », pas nécessaire ici.

Dans la partie de droite, vous pouvez mettre « 1 » dans order et ajouter une description de ce que à quoi sert la commande. Dans le paramètre « Path », c’est ici que vous ajoutez la commande à exécuter. Pour activer le compte administrateur local, il faut saisir ceci :

cmd /c net user Administrateur /active:yes

Mes paramètres ressemblent donc à ceci :

Faites de nouveau un clic droit sur « RunAsynchronous » pour « Insérer un nouvel élément RunAsynchronousCommand » et supprimez « Credentials » une fois encore.

Cette 2^nde commande va bypasser la demande de création d’un utilisateur local pendant la phase OOBE. Pour cela il faut faire une modification dans la base de registre. Ajoutez le « 2 » dans Order et une description simple mais claire puis dans « Path », la commande suivante (qui est sur une seule ligne) :

reg add HKLM\Software\Microsoft\Windows\CurrentVersion\Setup\OOBE /v UnattendCreatedUser /t REG_DWORD /d 1 /f

Ce qui me donne ceci dans mon fichier de réponses :

C’est terminé pour la configuration de la passe 4 « specialize », maintenant on va se concentrer sur la passe 7 « OOBE System ».

Ajoutez à la passe 7 le composant « amd64_ Microsoft-Windows-Shell-Setup… ».

Dans toute la liste ajoutée au fichier de réponses, on ne va garder que « OOBE » et « UserAccounts », vous pouvez supprimer tout le reste.

Dans la partie « UserAccounts », ne conservez que « AdministratorPassword » puis sur la droite dans le champ « Value », ajoutez le mot de passe qui sera défini sur le compte administrateur local des futures machines déployées. Il va apparaître ici en clair mais sera chiffré dans le fichier XML terminé.

Info ++ : Si vous ne définissez pas de mot de passe à l’administrateur via ce paramètre, le compte sera activé mais avec un mot de passe vide…

Cliquez ensuite sur le paramètre au-dessus nommé « OOBE » et au passage vous pouvez supprimer « VMModeOptimizations ».

Dans la partie de droite, mettre « true » à chaque champ commençant par « Hide » et ajoutez un « 3 » dans la partie « ProtectYourPC » pour passer tous les écrans et toutes les questions interminables de l’OOBE en refusant plus ou moins tout.

Cliquez maintenant sur « amd64_ Microsoft-Windows-Shell-Setup » pour ajouter le fuseau horaire « (GMT +01:00) Brussels, Copenhagen, Madrid, Paris » dans le champ tout en bas nommé « TimeZone ».

Et pour terminer, ajoutez à la passe 7 le composant « amd64_ Microsoft-Windows-International-Core… » qui va passer le système et le clavier en français.

Dans tous les champs sauf le Fallback, ajoutez « fr-FR » (fallback c’est la langue qui sera définie en cas d’erreur).

Notre 2^ème fichier de réponses pour l’image d’installation est terminé ! Cliquez sur la petite icone avec la coche orange en haut pour vérifier qu’il n’y a pas d’erreur et enregistrez le fichier XML où vous voulez. Moi je vais l’appeler « Unattend_Install.xml » et le mettre une nouvelle fois dans « E:\WDS\WdsClientUnattend ».

La dernière étape consiste à le déclarer dans WDS.

Allez dans les propriétés de l’image d’installation sur laquelle vous souhaitez que le fichier de réponses s’applique.

Cochez la petite case en bas « Autoriser l’image à s’installer en mode sans assistance », cliquez sur le bouton « Sélectionner un fichier » et allez chercher ce fichier XML.

Validez la modification en cliquant sur OK.

Nos deux fichiers de réponses sont prêts ! On se fait un petit test ?

5. Test de déploiement

Pour mon test et comme je travaille dans un environnement virtuel, j’ai créé une nouvelle VM que j’ai mise dans le même réseau que le serveur et sur laquelle j’ai activé l’EFI (pour l’UEFI).

Quand la machine démarre, je la fais booter en PXE (via le boot manager si non détecté de suite). Après quelques secondes elle va récupérer une adresse IP depuis mon DHCP.

Elle va se connecter au serveur WDS et charger l’image de démarrage (boot.wim).

Elle attend ensuite la réponse du serveur concernant la passe PE.

Et quand le contact est établi et mon 1^er fichier de réponses bien lu, l’installation de Windows 11 (ou 10) sur le disque de la nouvelle machine démarre.

Info + : Le temps d’installation dépend de la puissance de la machine et du réseau, soyez juste patient

La machine va effectuer son 1^er redémarrage.

Si je vais voir dès maintenant dans mon OU « Deploiement », je vais voir une nouvelle machine qui porte bien un nom attribué par ma stratégie définie sur WDS.

Info ++ : Si votre machine n’est pas remontée dans l’AD au moment du 1^er reboot, soit votre fichier de réponses sur l’image d’installation contient une erreur, soit votre stratégie de noms de clients n’est pas valide.

Le PC va redémarrer encore une fois de lui-même, laissez-le faire. Vous verrez un écran vous demandant encore de patienter ce qui signifie que votre 2^nd fichier de réponses est toujours en cours de lecture et qu’il est bien rentré dans la passe 7, la phase OOBE.

Et voilà, vous arrivez quelques minutes plus tard à la page de connexion, l’installation est terminée et rien ne vous a été demandé. On peut d’ailleurs voir que la machine est bien dans mon domaine qui s’appelle « NEPTUNET » et que je peux me loguer directement avec un compte de domaine.

Info + : Pour vous connecter avec un compte utilisateur local de la machine, dans le champ « Nom d’utilisateur », ajoutez « .\ » devant le login de votre utilisateur (plutôt pratique si on ne connait pas le nom du PC). Vous verrez le nom de la machine apparaître à la place du domaine. Si vous mettez le login « administrateur », la connexion se mettra automatiquement sur le nom de la machine et se sera donc le compte administrateur local.

Si on regarde les utilisateurs présents dans la machine, on peut voir qu’il n’y a pas d’autres utilisateurs créés à part ceux par défaut et le compte administrateur, qui au passage est bien activé car il n’y a pas la petite flèche pointant vers le bas qui indique le contraire.

Dernier petit check pour vérifier mes partitions avec l’outil en ligne de commandes Diskpart :

J’ai bien mes 3 partitions avec les tailles déclarées dans mon 1er fichier de réponses.

Je pense qu’on peut dire que tout est bon désormais.

Savoir manipuler les fichiers de réponses peut également être utile pour personnaliser ceux dans MDT par exemple, même s’ils sont bien plus complets et que la gestion se fait surtout via scripts.

MDT que je vous conseille d’ailleurs de tester et éventuellement d’adopter si vous voulez poussez un petit peu plus vos déploiements, mais surtout pour Windows 11 et ses futurs petits frères…

Oh tiens c’est marrant ça, il y a justement une intro à MDT ici : [Tuto] Déployer des postes Windows 11 avec MDT et WDS