Déploiement automatisé de postes Windows 11 par le réseau avec FOG Project

Le contexte

Installer un poste Windows à la main prend entre une heure et demie et deux heures : système, paramètres régionaux, mises à jour, jonction au domaine, logiciels métier. Multiplié par une dizaine de postes lors d'un renouvellement de parc, c'est une semaine de travail — et dix postes qui ne sont jamais tout à fait identiques.

Je voulais construire la chaîne complète qui remplace ce travail : du poste vierge au poste utilisable, joint au domaine, avec ses logiciels, sans intervention manuelle.

L'objectif

Un poste qu'on démarre, qu'on branche au réseau, et sur lequel on ne touche plus rien jusqu'à l'écran de connexion du domaine.

Et un objectif secondaire qui s'est révélé le plus démonstratif : déployer plusieurs postes en même temps sans que la durée augmente.

Les choix techniques

FOG Project plutôt que MDT ou WDS. Solution libre, indépendante de l'infrastructure Microsoft, qui sait déployer aussi bien Windows que Linux. Elle repose sur des briques standards — PXE, TFTP, NFS, partclone — ce qui rend chaque étape observable et donc diagnosticable.

Debian 12 Bookworm et non Debian 13. Décision prise après avoir constaté que l'installeur de FOG 1.5.10 échoue sur Debian 13 : un paquet retiré de la distribution, une version de bibliothèque incompatible et une version de PHP codée en dur dans le script. Revenir d'une version majeure était plus rapide que corriger l'installeur, et surtout plus sain à maintenir.

ProxyDHCP plutôt que de reconfigurer le DHCP de la box. Un serveur ProxyDHCP répond aux demandes de démarrage réseau sans distribuer d'adresses : la box continue son travail, dnsmasq ajoute seulement l'information « voici où trouver le fichier de démarrage ». Aucun risque de couper le réseau domestique, et aucun conflit entre deux serveurs DHCP.

Aucun logiciel dans l'image. Le master ne contient que le système et ses réglages. Les applications sont installées après coup par snapins. Une nouvelle version de navigateur ne demande donc pas de refaire l'image — on remplace un paquet.

Ce que j'ai réalisé

Le serveur

Debian 12 avec deux disques : un disque système et un volume de 200 Go dédié aux images, monté par UUID plutôt que par nom de périphérique — un nom de périphérique peut changer selon l'ordre de détection des disques au démarrage, un UUID non. La réserve d'espace root a été retirée du volume de données : ces 5 % réservés par défaut n'ont aucune utilité sur un volume de stockage pur.

Durcissement classique : SSH sur port non standard, connexion root interdite, UFW en refus par défaut. Enregistrements DNS direct et inverse créés sur le contrôleur de domaine.

Le démarrage réseau

C'est la partie qui a demandé le plus de diagnostic. Trois obstacles, dont aucun ne produit de message d'erreur explicite.

Le pare-feu ne peut pas filtrer le démarrage réseau par adresse source. Une machine qui démarre par le réseau n'a pas encore d'adresse IP : ses demandes partent de 0.0.0.0, qui n'appartient à aucun sous-réseau. Une règle restreinte au réseau local ne les reconnaît donc jamais. Les ports concernés doivent être ouverts sans restriction d'origine — ce qui a conduit à un arbitrage assumé sur ce serveur.

La configuration iPXE se fait en deux passes. La première sert le binaire de démarrage, identifié par la classe fournisseur du client. La seconde détecte que c'est désormais iPXE qui parle et lui sert son fichier de configuration. Sans la seconde, iPXE se relance, retombe sur la box qui n'a aucun fichier de démarrage à proposer, et la séquence échoue silencieusement.

Le démarrage sécurisé et le noyau de déploiement sont incompatibles. Le chargeur signé passe la vérification, iPXE se charge, le menu FOG s'affiche — puis le noyau de déploiement est rejeté, car il n'est signé par aucune clé reconnue. J'ai documenté le point et déployé avec le démarrage sécurisé inactif, en sachant expliquer pourquoi.

Le piège le plus coûteux : le firmware UEFI fige ses entrées de démarrage à la première énumération du matériel. Une machine créée avec une carte réseau virtuelle d'un type, puis modifiée ensuite, ne régénère pas son entrée de démarrage réseau — elle ne proposera jamais le PXE, quelle que soit la configuration. La seule solution est de recréer la machine en une passe, avec la bonne carte dès le départ. J'ai perdu plusieurs heures à chercher une erreur de configuration qui n'existait pas.

Le master

Windows 11 installé en compte local, paramètres régionaux français propagés aux comptes système et aux nouveaux profils, agent FOG installé, puis un nettoyage méthodique avant généralisation : suppression des profils et comptes temporaires, nettoyage du magasin de composants, purge des journaux et des fichiers temporaires.

Le sysprep a échoué plusieurs fois avant d'aboutir. La cause : des paquets applicatifs orphelins, installés pour un utilisateur mais non provisionnés pour la machine — condition que sysprep refuse. Le journal ne nomme pas directement le coupable ; il faut le remonter depuis les identifiants de paquets. Une fois la logique comprise, la correction est immédiate.

Un fichier unattend.xml automatise entièrement la première ouverture de session : création du compte d'administration local, connexion automatique limitée à un seul démarrage, paramètres régionaux et clavier, masquage de tous les écrans de bienvenue, et contournement de l'obligation de connexion réseau par une clé de registre appliquée en phase de spécialisation.

Détail qui coûte cher : un double tiret dans un commentaire XML est interdit par la spécification. Il provoque une erreur au code peu explicite, en pleine phase d'installation.

La post-configuration

Un script PowerShell idempotent exécuté en snapin après le déploiement :

• détection automatique de l'interface réseau active, via la route par défaut plutôt que par un nom d'interface codé en dur ;
• désactivation de DHCPv6 et bascule du DNS vers le contrôleur de domaine ;
• vérification de la présence des enregistrements de service du domaine avant de tenter la jonction — on ne lance pas une opération dont on sait qu'elle échouera ;
• activation du Bureau à distance par référence à la règle système plutôt que par son nom, pour rester indépendant de la langue de l'installation ;
• synchronisation horaire conditionnée à l'appartenance effective au domaine ;
• réglages d'alimentation.

Trois snapins supplémentaires installent les applications en mode silencieux.

L'incident le plus instructif

Après un déploiement techniquement réussi, la machine restait en groupe de travail. Le DNS était bon, les enregistrements de service présents, le compte de jonction valide.

La cause était ailleurs : le client FOG temporise toute action tant qu'une session utilisateur est ouverte — un comportement de protection, pour ne pas renommer ou redémarrer une machine sous les yeux de son utilisateur. Or la connexion automatique du fichier de réponses ouvrait précisément une session.

La correction tient en une commande de déconnexion : le client reprend seul à son cycle suivant, joint le domaine et enchaîne les snapins.

Ce qui rend cet incident intéressant, c'est qu'il n'y avait rien à corriger. Le comportement était normal, documenté, et je cherchais une panne dans les composants les plus complexes de la chaîne.

Le déploiement de flotte

L'étape finale : trois machines déployées simultanément depuis une session multicast unique.

La preuve tient dans une observation : les trois consoles affichaient rigoureusement les mêmes chiffres au même instant — même pourcentage, même débit, même temps restant. C'est la signature du multicast : un seul flux réseau que les trois reçoivent en parallèle. En unicast, chaque machine progresse à son propre rythme et les pourcentages divergent.

Déployer trois postes prend le temps d'en déployer un.

	Unicast	Multicast
Initiative	Le poste, à la demande	Le serveur, planifié
Flux réseau	Un par machine	Un seul, partagé
Usage	Un poste à remplacer	Renouvellement de parc, salle de formation

Le résultat

Une chaîne complète et reproductible : PXE → image → généralisation → jonction au domaine → logiciels → poste utilisable. Le déploiement d'une flotte de trois postes a été mené de bout en bout, jonction au domaine et exécution des snapins vérifiées sur chacun.

Ce que j'en retiens

C'est le projet qui m'a le plus appris sur le diagnostic, parce que presque aucun de ses échecs ne produit d'erreur explicite. Une machine qui ne démarre pas en PXE ne dit pas pourquoi. Un sysprep qui échoue désigne un identifiant de paquet, pas un nom de logiciel. Une jonction qui n'a pas lieu affiche simplement « en attente ».

La méthode qui a fonctionné : remonter la chaîne dans l'ordre, vérifier chaque maillon indépendamment, et se méfier de l'instinct qui pousse à soupçonner d'abord la brique la plus complexe. Deux fois sur trois, la cause était dans une couche que j'avais considérée comme acquise.