[Tuto] Automatiser le déploiement d’un OS Windows avec des fichiers de réponses sur WDS

On poursuit avec un autre post concernant le service WDS. Dans un précédent article, nous avons vu comment préparer un master de Windows 10 et le capturer directement sur le serveur pour qu’il soit prêt à l’emploi sans étape intermédiaire de récupération du WIM à gauche à droite…

Et bien maintenant, on va aller encore un plus loin en automatisant totalement le déploiement de notre master grâce aux fameux « fichiers de réponses » que l’on va donner, non pas à Sysprep lors de la généralisation du master, mais à WDS qui saura en faire bon usage

Utiliser des fichiers d’installation sans assistance pour un déploiement automatisé avec WDS

Autre avantage des services de déploiement de Windows, c’est la possibilité de personnaliser et surtout d’automatiser les deux phases d’installation d’une image d’install de Windows sans que ceux si ne restent « collés » au fichier .wim.

Info ++ : Si vous n’êtes pas à l’aise avec les notions de master et WDS, je vous conseille vivement de lire en amont cet article “Capturer une image d’installation de Windows personnalisée avec le service WDS” avant de poursuivre avec celui-ci, vous trouverez toutes les informations nécessaires pour bien comprendre ce que vous faites/devez faire. Comme d’habitude lors de la rédaction, j’essaye de rester le plus simple possible et d’expliquer les différentes notions rencontrées afin que tout soit compris par le plus grand nombre, aussi cet article restera sur des manipulations très basiques, les nombreuses captures d’écran sont là pour vous aider également.

Dans un précédent post sur le sujet, nous avons vu installer comment préparer un master, le capturer sur le serveur et le déployer sur une nouvelle machine. Cette solution est parfaitement fonctionnelle mais nécessite encore des interventions humaines pour définir par exemple la langue de l’OS, le partitionnement des disques, l’acception des conditions d’utilisation, la localisation, l’utilisation ou non de Cortana… et j’en passe.

Cet article est donc la suite logique, à savoir l’automatisation complète d’un déploiement d’une image d’installation personnalisée.

Le but à atteindre ? Aucune intervention entre le moment où vous connectez une machine sans OS au réseau et appuyez sur le bouton « On » et celui où il faut vous authentifiez sur la machine déployée.

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

Démonstration en vidéo disponible au lien suivant : Déployer un Windows 10 personnalisé avec un serveur WDS. La vidéo couvre en partie cet article mais également celui-ci : Capturer une image d’installation de Windows personnalisée avec le service WDS

1. Informations importantes

Quelques précisions comme toujours avant de commencer…

L’infrastructure utilisée dans ce tuto est exactement la même que dans l’article précédent (lien donné plus haut) que je vous invite à consulter pour plus de détails.

L’hyperviseur utilisé est VirtualBox mais le tuto est valide également sous VMware si la machine est en mode BIOS et non UEFI (à paramétrer dans les configurations de la VM). Des précisions rapides pour refaire les manipulations avec l’UEFI seront ajoutées ici et là dans le tuto quand nécessaire.

Côté réseau, mes machines sont en « Réseau NAT » avec le DHCP de VirtualBox activé pour l’attribution automatique d’adresses IP aux clients.

Dans mon infra virtuelle, j’ai déjà réalisé une image d’installation de mon master sans ajouter de fichier de réponses à Sysprep lors de la généralisation. L’image d’installation est un Windows 10 Entreprise 21h1 avec quelques logiciels installés pour la démo.

Le serveur WDS est déjà prêt à l’emploi et comprend bien une image de démarrage et d’installation. Seul le rôle WDS est activé sur le serveur, pas d’AD, pas de DNS et pas de DHCP pour se concentrer uniquement sur ce qui nous intéresse. Le serveur dispose d’une configuration IP fixe et accède à Internet.

Maintenant que tout ceci est dit, on attaque !

2. Installation de Windows ADK sur le serveur WDS

Afin d’automatiser le déploiement d’un OS Windows préconfiguré, nous allons dans ce tuto nous servir de Windows ADK (Assessment Deployment Kit) qui est une suite logicielle propre à Microsoft incluant de nombreux outils permettant d’analyser les performances d’une machine mais également de personnaliser et d’automatiser des déploiements.

Lors de la généralisation d’une machine master avec Sysprep, vous avez la possibilité d’ajouter un fichier de réponses au format XML. Ce fichier de réponses va simplement contenir… et bien oui des réponses… (c’est quand même logique l’informatique des fois…) à certaines questions que posent Windows lors de son installation. Techniquement, ce sont des configurations « préremplies » sur lesquelles Windows va s’appuyer pour installer et préparer votre système d’exploitation sans vous demandez systématiquement ce qu’il doit faire.

Notre objectif ici est d’utiliser ces fichiers de réponses pour notre image d’installation personnalisée mais via le rôle WDS et non pas via Sysprep lui-même. Nous allons donc télécharger et installer ADK sur le serveur directement.

Info + : L’installation sur le serveur ou le master n’est pas obligatoire, vous pouvez tout à fait l’utiliser sur une tierce machine et déposer sur le serveurs les fichiers XML qui seront créés.

Info ++ : De façon globale, évitez de naviguer sur le net avec un serveur si ce n’est pas nécessaire pour des questions de sécurité. Pour VirtualBox, pour pouvez télécharger ADK sur votre PC et monter un lecteur partagé pour le récupérer, utiliser une clé USB ou faire un copier/coller si vous avez bien installé les additions invités dans la VM serveur.

Comme l’OS à déployer est un Windows 10, il faut télécharger le kit ADK de Windows 10 correspondant à la version que l’on possède. ADK est disponible au lien suivant :Télécharger et installer Windows ADK

Microsoft nous propose directement la dernière version du produit qui n’est pas forcément compatible avec la version de Windows que l’on souhaite. Par exemple en ce moment, il propose la version pour Windows 11 qui est encore un peu trop jeune pour la mettre en prod…

Descendez un peu plus bas sur le site de Microsoft pour trouver les anciennes versions de ADK. Recherchez dans le tableau la version de ADK compatible avec votre version de Windows 10. Par exemple dans mon cas (21h1), il est indiqué qu’il faut que je prenne la version pour 2004. Une fois trouvée, cliquez sur le lien à gauche, pour la télécharger.

Info + : Si vous avez un doute sur votre version précise de Windows 10, il est préférable de vérifier. Exécutez la commande “winver” ou recherchez ce terme via la zone de recherche. La fenêtre suivante va s’ouvrir et vous donnera l’information :

Une fois ADK téléchargé, lancez l’installation du logiciel à l’emplacement de votre choix.

Cochez la case « Non » pour refuser l’envoi de données à Microsoft (enfin ou « Oui » si vous le voulez…) et acceptez les termes du contrat.

Il faut maintenant sélectionner les fonctionnalités dont nous aurons besoin. Dans notre cas, nous installerons uniquement les « outils de déploiement » d’ADK car nous n’avons besoin de rien d’autre. Cochez la case correspondante et cliquez sur « Installer ».

Après quelques minutes, les outils seront installés et disponibles via le Menu Démarrer dans « Windows Kits ».

Ouvrez l’outil « Assistant gestion d’installation » qui ressemble à ceci :

Afin de créer les fichiers d’assistance nécessaires, l’assistant a besoin d’une image d’installation de Windows 10 au format « .wim ». Vous pouvez utiliser le fichier « Install.wim » disponible dans une ISO de Windows 10 (dossier « sources ») ou si vous en avez une sous la main, une image d’installation personnalisée au format wim.

Pour utiliser celle présente dans l’ISO de Windows 10 officiel par exemple, il faut insérer l’ISO (le CD virtuel) dans le serveur puis le parcourir sans l’exécuter. Pour cela, rendez-vous dans l’explorateur de fichiers du serveur, dans « Ce PC », faites un clic droit sur le lecteur CD puis « Ouvrir ».

Allez dans le dossier « Sources » et recherchez le fichier WIM nommé « install ».

Copiez ce fichier « install.wim » sur le serveur. Il est nécessaire de l’avoir en local sur la machine pour que ADK puisse l’utiliser, sans quoi vous aurez un message d’erreur précisant qu’il est en lecture seule (ce qui est logique vu que c’est un fichier sur le CD virtuel qui ne peut être modifié…). Je l’ai personnellement mis sur le bureau mais rien ne vous empêche de le conserver proprement dans un petit dossier.

Une fois que vous avez trouvé un fichier d’installation, retournez dans l’assistant d’ADK, cliquez en haut à droite sur « Fichier » et sur « Sélectionner l’image Windows ».

Recherchez le fichier install.wim que vous venez de copier en local. L’assistant va vous demander pour la 1^ère fois de créer un « fichier catalogue » qui est nécessaire pour la suite, cliquez sur « Oui ».

La génération d’un fichier catalogue va alors démarrer. Cette étape peut prendre plusieurs minutes alors soyez patient .

Info ++ : Si l’erreur suivante survient avant la génération du catalogue…

… cela signifie que le fichier install.wim copié depuis le CD est en lecture seule. Pour corriger cela, faites un clic droit sur le fichier que vous avez récupéré, allez dans ses propriétés et décochez la case « Lecture seule » en bas de la fenêtre.

Dans l’assistant Windows SIM d’ADK, sélectionnez de nouveau le fichier .wim et vous pourrez cette fois-ci générer le catalogue.

Une fois la génération terminée, l’assistant aura rajouté en bas à gauche, des configurations possibles contenues dans l’image de Windows 10. C’est ce qui compose le fameux « catalogue ».

L’ensemble des configurations qui sont donc utilisables dans un fichier de réponses sont disponibles dans le menu « Components ». Dans le cadre de ce tuto, vous verrez que nous allons en utiliser très très peu par rapport aux possibilités. Libre à vous de faire le tour de tout ceci et de choisir ce dont vous avez besoin.

Info + : Il y a énormément de choix et ce n’est pas forcément facile de s’y retrouver dans ce catalogue. Pour savoir à quoi correspondent les différents paramètres et comment ils s’utilisent plus précisément (il y a une certaine typo à respecter), consultez le lien suivant : Microsoft doc paramètres sans assistance.

Bien, maintenant tout est prêt, nous allons enfin pouvoir nous attaquer à la création de notre 1^er fichier d’installation sans assistance.

Dans le cadre de ce tuto, nous en ferrons deux distincts, un pour la partie « PE » et un pour la partie « OOBE » de Windows, vous pourrez ainsi tester les deux indépendamment. Poursuivez votre lecture pour mieux comprendre le sens de ces sigles 😉.

3. Création du fichier XML pour la phase WinPE et ajout dans WDS

Commençons par le fichier de réponses pour la partie « Setup » de Windows.

Avec ce fichier, on va chercher à agir sur la phase WinPE, c’est-à-dire l’environnement dit de « pré-installation Windows ». Pour faire simple, WinPE permet simplement d’initier l’installation d’un système d’exploitation complet. C’est tout ce qu’il se passe juste avant l’installation comme par exemples la saisie potentielle d’une licence, les conditions d’utilisation du produit, mais aussi le choix de la partition sur laquelle installer le système.

Dans l’assistant d’ADK, faites un clic droit dans la partie « Fichier de réponses » puis choisissez de créer un « Nouveau fichier de réponses ».

Vous aurez alors l’affichage suivant reprenant les différents composants de Windows :

Il faut savoir que les paramètres sans assistance peuvent se mettre dans différents composants, appelés « passes », d’un fichier de réponses. Nous n’en utiliserons ici que deux, la passe « 1 windows PE » et la passe « 7 oobe System », pour les autres, je vous laisse demander à Google .

Comme ce premier fichier de réponses va concerner Windows PE, nous allons ajouter des paramètres à la passe 1. Je vous rappelle que dans la partie gauche « Image Windows », vous avez tous les paramètres possibles pour personnaliser un Windows.

Nous allons commencer par un paramètre simple, celui qui va nous permettre de définir la langue utilisée par l’installateur de Windows. Ce paramètre s’appelle « Microsoft-Windows-International-Core-WinPE » comme vu dans la doc Microsoft :

Info ++ : Soyez très attentifs aux noms des paramètres et aux propriétés qui seront définies, la moindre erreur peut entrainer l’échec complet du déploiement. Prenez votre temps et vérifiez à plusieurs reprises ce que vous avez fait. Petite anecdote personnelle : j’en ai bouffé des fichiers de réponses à composer et pourtant j’ai déclenché un typhon au Japon lors de la réalisation de ce tuto car j’avais inversé la syntaxe dans 2 paramètres donc forcément erreur lors du déploiement et je ne m’en suis aperçu que 2 heures après… voilà voilà ! Il n’y a pas 50 solutions pour savoir ce qui va vous être utile ou pas dans votre fichier de réponse, il n’y en a que 2 : connaître par cœur tous les paramètres dispos dans l’assistant avec leur syntaxe exacte ou alors RTFM (Read The Fucking Manuel).

Dépliez la partie « Components » et recherchez le paramètre appelé « amd64_Microsoft-Windows-International-Core-WinPE ».

Appuyez sur le petit + à gauche du paramètre pour voir si ce qu’il contient nous intéresse dans sa globalité ou si nous allons devoir trier.

Dans notre cas, il ne contient qu’un seul paramètre concernant la langue de l’interface utilisateur (UI) du setup donc on va pouvoir tout ajouter d’un coup. Pour cela, faites un clic droit sur « amd64_Microsoft-Windows-International-Core-WinPE » puis cliquez sur « Ajouter le paramètre à la passe 1 windowsPE ».

Cela aura pour action d’ajouter le paramètre (encore vide) dans notre fichier de réponse :

Il ne nous reste qu’à définir les propriétés que l’on souhaite pour ce paramètre. Dans la partie « Fichier de réponses », cliquez sur « amd64_Microsoft-Windows-International-Core-WinPE » pour voir apparaître sur la droite, les champs qu’il est possible de personnaliser.

Une fois encore, une petite recherche dans la doc Microsoft (Composant Microsoft-Windows-International-Core-WinPE) pour voir à quoi servent les paramètres présents dans « Microsoft-Windows-International-Core-WinPE » :

Une fois les paramètres utiles à notre config identifiés, on vérifie leur syntaxe, toujours dans la doc, par exemple ici pour « InputLocale » :

Pour nous, ce sera donc « fr-FR » pour tous les paramètres de « Microsoft-Windows-International-Core-WinPE » ce qui donnera quelque chose comme ça dans l’assistant pour la configuration que je souhaite (les paramètres qui ne me semblent pas utiles seront laisser vides tout simplement) :

Il ne faut oublier de saisir « fr-FR » également pour le paramètre « SetupUILanguage » comme ceci :

J’espère que vous avez compris le principe car à partir de ce point, je détaillerai de moins en moins .

Ensuite on va passer directement à la partie personnalisation du setup. Ce que l’on souhaite c’est que ce soit automatique, donc que le setup ne nous demande pas de nous identifier au serveur WDS, ni de choisir une image d’installation ni de partitionner le disque. Pour ces paramètres, ça se passe dans « amd64_Microsoft-Windows-Setup ».

Je vais ajouter à la passe 1 windowsPE uniquement ce qui m’intéresse, à savoir « DiskConfiguration » et « WindowsDeploymentServices ». Faites un clic droit sur chacun de ces 2 paramètres pour les ajouter à la passe 1.

Dans le fichier de réponses, je vais commencer par configurer le partitionnement du disque. Faites un clic droit sur « DiskConfiguration » puis « Insérer un nouvel élément Disk ».

Faites un clic droit sur « CreatePartitions » et cliquez sur « Insérer un nouvel élément CreatePartition ». Faites exactement la même manipulation sur « ModifyPartitions ».

Cela va débloquer les propriétés sur la droite.

On commence par définir l’ID (identifiant) de notre disque. Cliquez sur « Disk » et sur la droite, saisir l’ID « 0 » (zero,) car c’est le premier disque (si vous voulez en ajouter un second, il aura l’ID numéro 1, etc… me demandez pas pourquoi…). Le paramètre « WillWipeDisk » va définir si ce disque 0 doit ou pas être formaté. Nous allons dire que oui, il faut donc passer le paramètre sur « true ». Si vous ne voulez pas le formater, vous pouvez choisir la réponse « false » dans la liste. Ça donnera ceci :

Ensuite, on passe à la création d’une nouvelle partition. Nous n’en aurons dans ce tuto qu’une seule et unique.

Info + : Je vous conseille en production de créer quand même une autre partition réservée au système (appelée partition de type MSR de seulement quelques MégaOctets), voire même une partition de récupération système si nécessaire.

Info ++ : Attention, la suite ne fonctionnera pas avec l’UEFI seulement avec les BIOS ! Plus de détails sur les différences un peu plus bas dans cet article.

Pour notre unique partition, nous allons dire définir qu’elle est extensible ce qui aura pour effet de prendre toute la place disponible sur le disque, le paramètre « Extend » doit donc est placé sur « true ». Il n’y aura donc pas de taille (Size) à définir. Dans le paramètre « Order », il faut définir en quelle position cette partition sera créée. Comme nous n’en avons qu’une, c’est la première, on tape donc « 1 ». Et pour le type, il s’agit qu’une partition principale classique donc nous pouvons choisir « Primary » dans la liste.

Et pour terminer cette configuration, on va répondre au paramètre « ModifyPartition » histoire de la customiser .

L’ordre de modification sera donc le premier, donc 1 pour « Order ». L’ID de la partition à modifier (si vous avez suivi vous avez déjà compris…) sera donc le 1. On choisit au passage la lettre de lecteur pour notre installation de Windows (classiquement, c’est C…) et on lui donne un petit nom dans « Label ». Et enfin on définit son format qui sera NTFS (format de fichiers utilisé par Windows et plus récent que FAT32).

Info ++ : Pour le partitionnement sur de l’UEFI, il est nécessaire de créer en 1^er une partition de type EFI de 100 Mégaoctets, au format FAT32. Voici des screens des configurations pour ce cas précis :

Le partitionnement est prêt, maintenant, passons aux paramètres concernant l’utilisation de WDS que nous avons ajouté précédemment.

On va commencer par le paramètre « InstallTo » qui sert à préciser sur quel disque et quelle partition installer notre Windows personnalisé. Si vous avez suivi ce tuto, vous n’avez qu’un disque, donc « 0 » pour « DiskID » et qu’une seule partition également donc « 1 » pour « PartitionID ».

Info ++ : Pour l’UEFI, le numéro de partition sur lequel installé l’image Windows sera le 2, n’oubliez pas que la partition ID 1 est celle du boot EFI !

On poursuit avec la définition de l’image d’installation disponible sur WDS qui sera utilisée. Cela se passe dans le paramètre « InstallImage ». Dans mon cas, mon fichier .wim (FileName) s’appelle précisément « win10-neptunet.wim », le nom de l’image (ImageName) est le même pour moi mais sans l’extension .wim et cette image est située dans le groupe « Windows_10_Ent », ce qui me donne ceci :

Et pour terminer, je vais aussi automatiser la demande d’authentification au serveur dans le paramètre « Login » et « Credentials ». Je n’ai pas d’autre compte que l’administrateur sur le serveur donc je vais utiliser celui-ci même s’il est plus que conseillé en production d’en utiliser un autre…

Comme je n’ai pas de domaine, j’utilise simplement le nom de mon serveur à la place. Je saisis le nom de mon utilisateur du serveur et son mot de passe (et oui niveau sécurité de base, je suis vraiment au top…).

Et ça sera tout pour ce 1^er fichier de réponse. Avant de l’enregistrer, on va faire une petite validation pour s’assurer qu’il n’y a pas d’erreur de syntaxe ou autre. Pour cela, cliquez sur le petit icone avec une coche orange dans le bandeau en haut de l’assistant.

Si une erreur survient, elle sera affichée dans la partie inférieure droite de l’outil. Avant de poursuivre, assurez-vous qu’il y a bien indiqué « Aucun avertissement ni erreur ».

Vous pouvez ensuite enregistrer ce fichier de réponse (au format XML). Pour éviter que ce soit le bronx sur le serveur, il est préférable de le placer dans le dossier de WDS « RemoteInstall » puis le dossier « WdsClientUnattend ».

Ce fichier on va désormais l’utiliser dans le rôle WDS. Retournez dans la console de gestion de WDS et rendez-vous dans les propriétés du serveur, onglet « Client ».

Cochez la case « Activer l’installation sans assistance » puis cliquez sur le bouton « Parcourir » correspondant à votre architecture pour aller chercher le fichier XML que vous venez de créer (sauf cas exceptionnel, ce sera plutôt une architecture x64, en UEFI ou non).

Info ++ : J’ai choisi « Architecture x64 » et « Architecture arm » pour le même fichier uniquement parce que VirtualBox n’est pas content une fois sur 2 si ce n’est pas dans arm… je n’ai pas perdu de temps à comprendre pourquoi ce nouveau caprice qui ne se produit pas en BIOS sous VMware mais si ça vous arrive, testez arm… Pour UEFI, il faut bien entendu ajoutez le fichier de réponse dans « Architecture x64 (UEFI) ».

Une fois ceci fait, vous pouvez cliquer sur « Appliquer » et/ou « OK » pour valider l’utilisation de ce fichier de réponses lors de la phase WinPE.

En l’état, toute la partie setup (ou pré-installation de Windows) devrait être automatisée, vous pouvez créer dès maintenant une machine virtuelle vide et le vérifier avant de poursuivre si vous le souhaitez.

4. Création du fichier XML pour la phase OOBE et ajout dans WDS

Passons maintenant à la seconde partie qui va nous permettre d’automatiser la configuration de l’expérience utilisateur, la fameuse « OOBE » !

En bon français, OOBE pourrait se traduire par « Expérience sortie de la boite », comprenez plutôt « prête à l’emploi ». Cette phase permet à l’utilisateur de personnaliser son expérience avec Windows lors de la 1^ère installation : région, disposition clavier, termes du contrat d’utilisation d’un logiciel Microsoft, connexion à un compte Microsoft ou création d’un compte local, localisation, envoi de données, Cortana, publicités ciblées…

Avec notre second fichier de réponses, on va faire en sorte que rien de tout cela ne soit pas demandé.

Attention ! Si vous utilisez WDS dans un environnement AD et que vous souhaitez que lors du déploiement la machine soit liée automatiquement au domaine et utilise votre propre stratégie de nom client, une manipulation supplémentaire au niveau de la passe 4 sera nécessaire sinon ça ne fonctionnera pas. Privilégiez plutôt ce tuto (valable pour Windows 10 et 11) :
[Tuto] Utiliser des fichiers de réponses sur WDS intégré à Active Directory / Partie 4

Si votre WDS est bien en mode autonome (sans Active Directory donc) Créez un nouveau fichier de réponse dans l’assistant.

Nous allons agir cette fois-ci sur la passe « 7 oobeSystem ». Dans la liste des paramètres disponibles (partie inférieure gauche « Image Windows »), recherchez le paramètre appelé « amd64_Microsoft-Windows-Shell-Setup ».

Nous n’allons pas tout ajouter car nous n’avons besoin ici que de quelques paramètres seulement mais vous pouvez voir qu’il y a de nombreuses possibilités de personnalisation ! Faites un clic droit sur « OOBE » puis choisissez « Ajouter le paramètre à la passe 7 oobeSystem ».

Le paramètre sera alors disponible dans notre fichier de réponses. Nous n’avons pas ici besoin de « VMModeOptimizations » donc je vais le supprimer directement. Pour cela faites un clic droit sur le paramètre en question et « Supprimer ».

Pour les paramètres de l’OOBE, nous allons définir de passer tout ce que nous pouvons. Vous pouvez choisir « true », devant chaque paramètre commençant par « Hide ». Je vous rappelle que pour savoir à quoi ça correspond, c’est RTFM. Concernant l’option « ProtectYourPC », c’est elle qui va s’occuper de tous ce qui est publicité ciblée, saisie manuscrite, localisation etc… Ce paramètre se règle sur 1, 2 et 3 suivant si l’on souhaite accepter ou refuser d’office ce que Microsoft propose par défaut (info ICI) . Dans mon cas, je refuse tout donc je mets « 3 ».

Je vais également définir la « TimeZone » sur « amd64_Microsoft-Windows-Shell-Setup » pour préciser le GMT, ce qui me donne ceci pour le fuseau horaire de Paris :

Ensuite je retourne dans la partie inférieure gauche pour ajouter à la passe 7 le paramètre me permettant de créer un utilisateur local sur la future machine. Ce paramètre est toujours dans « amd64_Microsoft-Windows-Shell-Setup ». Il s’agit de « UserAccounts » puis « LocalAccount ».

Dans le fichier de réponse, faites un clic droit sur « LocalAccounts » puis « Insérer un nouvel élément LocalAccount ».

Sur « LocalAccount », vous pouvez saisir sur la droite la description de l’utilisateur, lui définir un login (champ Name), lui donner un nom qui sera affiché (champ DisplayName) et l’ajouter à un groupe d’utilisateurs local. Dans mon cas, je vais créer un utilisateur ayant pour identifiant « admin », nom d’affichage « admin », et l’ajouter au groupe « Administrateurs », ce qui me donne ceci :

Ensuite, je passe sur le paramètre « Password » pour lui définir un mot de passe (plus fort que le mien bien sur…).

Et pour terminer, un dernier paramètre qui va concernant la langue du système d’exploitation qui peut tout à faire être différente de celle définie dans le setup.

Ajoutez à la passe 7 toujours, le paramètre « amd64_Microsoft-Windows-International-Core ».

Et ajoutez la mention « fr-FR » comme vous l’avez déjà fait précédemment, aux paramètres sur la droite pour tout définir en français.

Notre fichier de réponse pour la phase OOBE est terminé. N’oubliez pas de le faire valider puis de l’enregistrer quelque part (je le conserve avec les autres dans « RemoteInstall/WdsClientUnattend » pour éviter de les chercher partout).

Il ne nous reste plus qu’à le déclarer dans WDS. Comme c’est un fichier de réponse destiné à l’OOBE, il sera plutôt à lier avec l’image d’installation de Windows.

Dans la console de gestion des services déploiement, rendez-vous dans la partie « Images d’installation » et faites un clic droit sur votre image puis allez dans ses propriétés.

Dans l’onglet « Général », cochez tout en bas la case « Autoriser l’image à s’installer en mode sans assistance », puis cliquez sur « Sélectionner un fichier ». Allez cherchez le fichier de réponse que vous venez de créer pour l’ajouter et terminer en cliquant sur « OK ».

Voilà, tout est désormais prêt côté serveur ! Vous pouvez tester votre fichier indépendamment du précédent bien entendu.

N’hésitez pas à ajouter des paramètres, assembler plusieurs passes dans le même fichier de réponses (j’en utilise ici deux uniquement dans un but pédagogique), tester, faire, défaire… et même utiliser un fichier de réponse très complet directement lors du Sysprep du master, vous n’êtes pas obligé d’avoir un serveur WDS sous la main ! En bref, faites-vous votre propre expérience, les machines virtuelles sont là pour ça !

5. Test de déploiement de l’image personnalisée

Maintenant que tout est opérationnel côté serveur, il ne reste plus qu’à tester si notre solution entière est fonctionnelle !

Pour cela, j’ai créé une nouvelle machine virtuelle totalement vide sans toucher aux configurations proposées par VirtualBox. J’ai mis la nouvelle machine vide dans le même réseau que le serveur et j’ai ajouté le « Réseau » dans l’ordre d’amorçage (ordre de boot).

Au démarrage de cette nouvelle machine, elle va automatiquement booter sur le réseau car il n’y a pas d’OS sur son disque de stockage donc sa dernière option est le boot sur le réseau.

On voit que la nouvelle machine récupère bien automatiquement une adresse IP du DHCP du réseau et qu’elle a bien trouvé le serveur WDS.

Info + : Pour l’UEFI, l’affichage ressemblera plutôt à ceci :

Elle trouve bien l’image de démarrage « boot.wim » présente dans le serveur.

Après quelques minutes, le setup va afficher une fenêtre indiquant être « en attente du serveur », ce qui est plutôt bon signe car cela signifie que les paramètres du premier fichier XML ont bien été lus.

Si aucune erreur n’est détectée (souvent possible surtout au niveau du partitionnement du disque), il n’y a alors rien à faire, l’installation du système d’exploitation va directement se lancer. Cela signifie que le fichier d’installation sans assistance déclaré dans les propriétés du serveur est fonctionnel.

A cette étape il ne vous reste qu’à patienter. Une fois l’OS installé sur le disque de la nouvelle machine, elle va redémarrer automatiquement et rentrer dans sa phase OOBE.

Si le fichier XML déclaré dans WDS sur l’image d’installation est fonctionnel, l’ensemble du processus va s’effectuer sans poser une seule question, notamment sans devoir créer un nouvel utilisateur, définir un clavier, choisir d’avoir des pubs ciblés, etc…

L’installation va stagner quelques secondes sur la partie « Réseau », puis repartir directement.

Si vous arrivez à la page de connexion de l’utilisateur que vous avez demandé au fichier XML de créer, c’est gagné !

Vous pouvez vous loguer avec le mot de passe défini dans le fichier XML. Comme c’est la première connexion de cet utilisateur sur la machine, Windows est poli et va vous dire bonjour .

Après quelques secondes, vous retrouverez votre bureau avec les logiciels installés et toutes les personnalisations effectuées.

Et voilà, plus qu’à laisser tourner les machines à déployer et aller se faire un cocktail (ou plusieurs…) en attendant !

Ce qui a été fait ici n’est clairement qu’un grain de sable dans la mer, je vous renvoie directement vers la doc de Microsoft pour aller plus loin dans l’utilisation des fichiers de réponses avec l’assistant WSIM : Windows System Image Manager (Windows SIM)

Il y a énormément de possibilité en matière de déploiement Windows, et d’autres outils, propres à Microsoft, permettent d’affiner beaucoup plus ce que l’ont vient de voir. Si vous êtes curieux, allez faire quelques recherches sur MDT ou encore SCCM (qui fait désormais parti de MECM), mais là on est sur un autre level 😉.

Quant à moi, je vous dis à bientôt !