NEPTUNET.

FR SysAdmin
Everything's under control 👁 Ma base de connaissances à ciel ouvert

Accueil Découvrir Système Réseau Logiciels

Astuces Jokes

Contact

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

1. Informations importantes
2. Installation de Windows ADK sur le serveur
WDS
3. Création du fichier XML pour la phase WinPE
et ajout dans WDS
4. Création du fichier XML pour la phase OOBE
et ajout dans WDS
5. Test de déploiement de l’image personnalisée

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 1er 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 1er

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 1er 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 !

Articles pouvant vous intéresser


 Admin 12 juin 2021
Déploiement, Rôles et services, Système, Windows

#WHOAMI EN SAVOIR PLUS Dernière vidéo

Poséidon A propos
publiée
Fils de Les consignes de la DSI
Cronos et
Informations complémentaires Installer GLPI 10 …
de Rhéa,
frère de Politique de confidentialité
Zeus et
d’Hadès,
Zone de recherche
je suis Poséidon (ou Neptune
comme tu veux…) le puissant
Dieu des mers et des océans
Saisir un mot-clé 
ainsi que des tremblements
de ter… eh mais attendez, on
est où là ?! OK je vois donc
on utilise mon image pour un
truc qui n’a rien à voir ? Nen
mais what’s the hell ?!

Copyright © 2024 NEPTUNET.FR. - Tous droits réservés