Yohan Rousseau

ÉTUDIANT EN ALTERNANCE EN RÉSEAUX & SYSTÈMES

Déploiement PXE via WDS

Objectif : Mettre en place une solution de déploiement et créer différentes images personnalisées pour chaque besoin

WDS (Windows Deployment Services) est une technologie de Microsoft permettant le déploiement d’images .WIM par le réseau. Il succède à RIS et est inclus en fonctionnalité optionnelle depuis la version 2008 de Windows Server. WDS utilise le PXE afin d’amorcer une image minimaliste de Windows appelé
«Windows PE». De là, on peut effectuer deux opérations, l’installation ou la capture. L’installation peut être lancée en unicast ou broadcast vers les postes tandis que la capture fonctionne en sens inverse en transmettant une image .WIM d’un poste au serveur (après un SYSPREP).
 
Il est possible d’utiliser une image que vous possédez déjà et de la déployer directement depuis le serveur WDS. Si c’est votre cas, l’étape suivante est inutile…

MDT se trouve en téléchargement sur le site web de Microsoft ICI tout comme le Windows ADK qui se trouve ICI.

Tout commence dans la «Deployment Workbench» où se trouve les partages de déploiement. Il faut en créer un.

On va vous demander où le placer, choisissez de préférence un emplacement sur une autre partition ou mieux sur un autre disque. De nouvelles rubriques apparaissent alors.

PS : ne pas oublier de définir les bonnes autorisations pour s’assurer de l’accessibilité de ce dossier lors d’un déploiement, c’est crucial!

Import et modification d’une image

  • Onglet « Operating Systems » : Import d’une image en ISO ou WIM. Cela peut même être un ISO contenant plusieurs versions de Windows, toutes les sources s’ajouteront alors et vous pourrez associer des modifications à chacune d’entre eux.
  • Onglet « Applications » : Permet l’ajout de programme ou d’ensemble de programmes qui viendront s’installer sur votre image lors de son déploiement (exe ou msi). Une commande est demandée pour effectuer une installation silencieuse et elles sont toutes propres à chaque programme. Ces « switches » sont référencés sur plusieurs sites, notamment GET-ITSOLUTIONS.
  • Onglet « Out-of-Box Drivers » : Permet d’ajouter les drivers nécessaires au fonctionnement du poste sur lequel vous comptez déployer l’image. Vous pouvez créer une hiérarchie de répertoire afin de classer vos drivers en fonction de plusieurs modèles de postes. Cette fonctionnalité n’accepte sur des drivers au format compressé CAB ou directement en ajout manuel INF.
  • Onglet « Packages » : Destiné aux patchs correctifs, mises à jours, packs de langages et services packs à intégrer à l’image.
  • Onglet « Advanced Configuration » : Destiné à ceux qui veulent pousser davantage la personnalisation de leur image. Par exemple, lorsque l’on ajoute des packs de drivers pour plusieurs modèles de machines différentes, il faut créer des sélections de profils pour chaque modèle de postes.
  • Onglet « Task Sequences » : Permet d’initier les différences séquences de tâches qui s’appliqueront lors de la phase de déploiement (d’où l’importance de l’accès au partage associé).

Il existe plusieurs séquences types qui sont déjà prédéfinies dans MDT. Toutefois, il faudra les paramétrer, où alors si vous le souhaitez, vous pouvez définir de A à Z vos propres tâches à effectuer, ce qui requiert quand même quelques connaissances avancées. Dans notre cas, nous choisirons le modèle Standard qui correspond aux tâches essentielles d’un déploiement basique tout en l’adaptant.

J’ai défini individuellement, une tâche par installation (alors qu’il est possible de toutes les réaliser en une seule fois) pour éviter les conflits entre plusieurs instances d’installateur.

Application d’une stratégie locale dans une séquence de tâches (facultatif)
 
La tâche « Apply Local GPO Package » appplique une stratégie locale si elle existe. Or, de base, elle n’existe pas et c’est à nous d’en créer une. Pour cela, l’utilitaire LGPO.exe nous sera d’une grande aide. Il est contenu dans le Microsoft Security Compliance Toolkit disponible au téléchargement ICI.
Seul le LGPO.zip nous intéresse ici. Sur un poste où une GPO locale est appliquée et correctement paramétrée, décompressez le ZIP, récupérer l’utilitaire exécutable et placez-le dans un dossier sur le bureau. A l’aide du CMD, placez-vous dans ce dossier contenant cet exécutable et effectuer une backup via la commande :
 
LGPO.exe /b c:\lgpo 

Un nouveau dossier portant le GUID de ce poste est apparu dans le répertoire. Il est conseillé de le renommer pour simplifier les commandes qui vont suivre. Une fois ceci fait, retour sur le serveur possédant MDT, créez un dossier « GPOPacks » dans votre Deployment Share et copier cette backup ici. Puis, ajouter l’utilitaire LGPO.exe dans le dossier Tools (x86 et x64). 

Cette tâche va copier la GPO présente sur le serveur vers les postes en déploiement.  

xcopy E:\DeploymentShare$\GPOPacks %WinDir%\temp\LocalGPO /E /I 

A adapter au besoin (LocalGPO étant le nom que j’ai donné à mon répertoire). Pour finir, on applique la GPO via l’utilitaire, désormais intégré à MDT.

Monitoring et mise à jour du partage de déploiement 

La fonction « Monitoring » présente dans MDT, permet de suivre les déploiements lorsque ceci sont effectués depuis MDT même. C’est pour cela qu’elle ne nous sera pas utile ici. 

A chaque modification majeure effectuée dans MDT, il est nécessaire de mettre à jour le partage de déploiement. 

C’est simple, il suffit d’effectuer un clic droit sur le DeploymentShare et « Update ». Deux choix s’offrent à vous :

L’optimisation de l’image de boot pour des modifications classiques et sa compression si l’image a une taille importante ou la régénération si les modifications sont de grandes ampleurs.

Les fichiers BOOTSTRAP et CUSTOMSETTINGS 

Ces deux fichiers de configuration vont permettre d’automatiser certaines tâches lors du déploiement. 

Customsettings.ini : fichier de configuration principal pour les règles de traitement utilisées dans tous les scénarios. Ce fichier est stocké dans le DeploymentShare et lu depuis celui-ci. 

Bootstrap.ini : fichier de configuration utilisé lorsque l’ordinateur cible n’est pas en mesure de contacter le partage de déploiement. Il est contenu dans l’image de boot. 

/!\ Toutefois, toutes les propriétés disponibles au paramétrage dans le fichier CustomSettings ne le sont pas dans Bootstrap. De plus, la modification du fichier Bootstrap doit toujours s’accompagner d’une mise à jour du partage de déploiement. 

Des centaines de variables peuvent être définies. Pour en savoir plus : LES2T, SYSTEMSCENTER.RU et TECHNET sont de bonnes sources.

Avant d’aborder le sujet concrètement, il faut bien savoir comment se déroule l’opération SYSPREP et comment il est possible de la personnaliser avec ce que l’on appelle un fichier de réponses. 

L’opération SYSPREP 

SYSPREP est un outil de préparation du système en vue d’un déploiement. Il propose 2 outils de nettoyage du système 

  • Mode OOBE (Out-Of-Box Experience) qui permet de faire démarrer l’ordinateur comme s’il subissait son premier allumage. 
  • Mode d’Audit Système qui permet de démarrer l’ordinateur dans un mode particulier afin d’y ajouter des drivers, des applications, des packages, en vue de sa généralisation. Une fois ce mode activé, il sera impossible de le désactiver même en redémarrant l’ordinateur. La généralisation est l’étape prochaine.

La généralisation permet de supprimer toutes les informations propres au système (GUID, nom, logs, points de restauration…) afin de faire revenir l’ordinateur à un mode usine en quelque sorte. C’est un passage obligé avant un déploiement. 

Les différentes phases traversées

SYSPREP traverse plusieurs phases avant d’arriver en OOBE (expérience utilisateur). L’audit n’est pas nécessaire, mais toutefois recommandé pour tester différents paramétrages dans son fichier de réponses et pour ajouter des éléments que l’on aurait oubliés avant cela. 

GENERALIZE : Comme évoqué précédemment, c’est la suppression des informations propres au système. 

SPECIALIZE : Utilisée pour créer et configurer des informations dans une image de Windows. C’est ici que l’on peut configurer les fuseaux horaires, les paramètres réseaux, les informations de jonction au domaine. 

En phase d’audit, les paramètres appliqués dans cette phase sont pris en compte. 

AUDIT : Phase destinée aux tests et à l’ajout additionnel de drivers et d’applications. 

OOBE : Applications des paramètres définis aux phases précédentes et configuration des comptes utilisateurs, de l’envoi des données de diagnostics… Expérience utilisateur (Windows Welcome) 

Les autres phases ne nous concernent pas ici. Toutefois, pour plus d’informations, rendez-vous sur la DOC MICROSOFT.

L’usage d’un fichier de réponses (answer file)

Un fichier de réponses va permettre d’automatiser un grand nombre de paramétrages durant l’installation en précisant pour chaque phase, quel(s) paramètre(s) doit être défini(s) 

Microsoft fournit d’ailleurs un outil d’aide à la création de fichier de réponse dans son ADK, nommé Windows SIM (System Image Manager). Nous y reviendrons plus tard. 

PERSONNALISATION – Activation du compte administrateur

Lors de l’installation de Windows sur le poste de préparation, il vous sera demandé de créer un compte. Ce compte servira de modèle avant copie dans le profil par défaut. Toutefois, il sera également nécessaire d’accéder au compte « Administrateur » local. Il n’est pas activé par défaut, il faut ouvrir une invite de commande aux privilèges élevées et taper : 

net user Administrateur /active:yes

Création du profil

Depuis le compte créé à l’installation, vous pouvez installer des logiciels, paramétrer des stratégies locales, supprimer des applications natives, placer vos icônes. 

En ce qui concerne la disposition du Menu Démarrer et des applications par défaut, il faudra procéder autrement car ni la copie du profil, ni l’opération SYSPREP ne conserve ces paramétrages. 

Copie dans le profil par défaut (avec ProfileTool)

Le profil par défaut est appliqué à tous les prochains utilisateurs qui se connecteront qu’ils soient sur un compte local ou joint à un domaine. 

Or, le profil créé ici n’est pas le profil par défaut. Pour cela, nous allons utiliser le soft « ProfileTool » qui permet de copier la disposition et certains paramètres d’un compte présent sur la machine directement dans le profil « Default ». 

PS : Ce profil est masqué par défaut, il faut cocher les options de visibilité des dossiers cachés dans « Affichage > Options » une fois sur l’Explorateur. 

Une fois téléchargé ICI, décompressez ce fichier dans un dossier à la racine du C:\ que nous appellerons « Logiciels »Après avoir fait toutes vos modifications, déconnectez-vous de ce compte et passer sur l’Administrateur local. 

Une fois ceci fait, ouvrez une invite de commandes aux privilèges élevées et taper : 

cd C:\Logiciels\ProfileTool 

profiletool.exe SETDEFAULT nomducomptepréparé 

Cette commande va copier les paramétrages issus du compte préparé, directement dans le profil par défaut. 

ALTERNATIVE : Il existe une seconde possibilité permettant d’effectuer cette copie sans passer par cet utilitaire et c’est la plus recommandée.

Copie dans le profil par défaut (avec CopyProfile)

CopyProfile est un paramètre booléen qui peut être renseigné dans le fichier de réponse. S’il en est fait usage, toutes les configurations doivent être effectuées sur le compte Administrateur intégré. Aucun autre compte ne doit être présent sur la machine. Lors du SYSPREP, tous ces paramétrages seront retranscrits dans le profil par défaut. 

Disposition du MENU DÉMARRER

Pour conserver la disposition d’un menu Démarrer que vous avez réalisée, ouvrez une invite Powershell aux privilèges élevées et taper : 

Export-StartLayout -Path C:\Windows\startlayout.xml 

Cette commande va exporter la disposition de votre menu Démarrer dans un fichier XML à l’emplacement défini dans la variable Path. Ensuite, créer une stratégie locale ordinateur de disposition du Menu Démarrer avec le chemin du fichier XML. Ainsi, il s’appliquera à tous. 

Applications par défaut

Windows possède une liste d’applications par défaut qui sont associées aux différents formats de fichiers existants. Lorsqu’on modifie ces applications par d’autres, des messages d’erreurs vont apparaître sur l’image sysprépé indiquant que le format de fichier a été réinitialisé.  

Pour éviter cela, le principe est le même que pour le Menu Démarrer. On édite sa liste d’applications par défaut et on l’exporte en effectuant la commande suivante dans une invite de commandes aux privilèges élevées : 

DISM /Online /Export-DefaultAppAssociations:C:\Windows\defaultapps.xml

Applications WIN10 natives inutilisées

Windows est livré avec une panoplie d’applications superflues. Il est possible d’en désinstaller une bonne partie grâce à PowerShell dont le fameux Windows Store.  

Pour lister les applications installées :

Get-AppxPackage | Select Name, PackageFullName 

Pour procéder à une désinstallation : 

Get-AppxPackage PackageFullName | Remove-AppxPackage

Préparation avant SYSPREP

Avant d’effectuer le SYSPREP, il faut veiller à ce que le fichier de réponses « unattend » soit bien placé, je conseille de le mettre à l’endroit suivant : C:\Windows\System32\Sysprep 

Le fichier de disposition du Menu Démarrer ainsi que celui des applications par défaut doit être accessible : C:\Windows 

A la racine du C:\, placer un dossier NET3 contenant le .cab du .NET Framework (nécessaire à certaines fonctionnalités) ainsi qu’un script d’intégration à l’image en cours qui sera exécuté post-sysprep via le fichier de réponse : 

DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /LimitAccess /Source:C:\NET3 

Enfin, on écrit un script de suppression du fichier « unattend » (qui peut potentiellement contenir des données sensibles) et des dossiers qui ne serviront plus après le déploiement.

Windows SIM

Windows SIM permet d’éditer des fichiers de réponse. Il est disponible dans l’ADK (choisir Outils de déploiement à l’installation). La maintenance des images peut s’organiser avec l’outil DISM (Gestion et Maintenance des Images de Déploiement).  

Montage de l’image dans un dossier local -> Apport des modifications -> Enregistrement -> Démontage de l’image 

Il suffira de remplacer l’image sur le serveur WDS par celle venant d’être modifié et le déploiement pourra reprendre ! 

CAPTURE D’UNE IMAGE SYSPREP

Une fois le SYSPREP effectué et le PC éteint (/shutdown). On se dirige sur le serveur WDS. 

Pour en savoir davantage sur l’installation et la configuration d’un serveur WDS, lisez la partie suivante. 

Dans l’onglet « Images de démarrage », on ajoute le fichier boot.wim d’une image Windows 10 vierge (là encore de la même version et de la même édition que celui de votre master). Ensuite, on choisira de créer une image de capture. Le processus prend un peu de temps et une fois terminé, une deuxième image de boot apparaît. 

Une fois ceci fait, on peut redémarrer le service et lancer le boot PXE sur le poste de préparation.  

Il va vous demander de faire un choix entre vos deux images de démarrage. La première lance le programme d’installation de Windows tandis que la deuxième prépare une capture de l’image que vous avez préparé. On peut choisir de sauvegarder son image en local ou de la transférer directement au serveur dans un groupe d’image (qui doit être déjà défini dans les images d’installation). 

En cas de transfert, des identifiants vous seront demandés.

La procédure de déploiement via WDS va différer en fonction de la localisation du serveur (seul, couplé à MDT, sous-réseau différent). Sur un Windows Server 2008 (ou ultérieur), ajouter le rôle « Services de déploiement Windows » avec les deux dépendances : Déploiement & Transport. 

On retrouve 5 rubriques sur notre serveur : 

  • Images d’installation : ce sont les images de postes sysprépées sur lesquelles une installation est possible directement 
  • Images de boot : ce sont les images sur lesquelles vont booter les postes en premier lieu 
  • Périphériques en attente : requête PXE des postes en attente d’approbation 
  • Transmission par multidiffusion : envoi d’une image en une seule fois afin de déployer plusieurs postes qui en récupéreront le flux, dans un soucis d’économie de bande passante
  • Pilotes : liste des drivers à inclure (inutile si MDT utilisé)

Configuration du serveur

Même conseil que pour MDT, il est conseillé que le dossier du WDS (RemoteInstall) soit sur une autre partition, voir un autre disque. 

Il est possible d’intégrer le serveur à un AD ou de le laisser fonctionner de manière autonome. Ne voyant pas d’intérêt à ce couplage, j’ai sélectionner la seconde option. J’ai également choisi de répondre à tous les postes connus comme inconnus (sans approbation pour mes tests). 

Dans les propriétés du serveur, on peut approfondir les configurations à apporter.

Par exemple, dans l’onglet « Démarrer », j’ai choisi de toujours continuer le démarrage PXE après sa détection par mes clients qu’ils soient connus ou inconnus. 

C’est aussi ici que l’on peut définir le chemin du fichier de boot lorsque l’on possède plusieurs images et ce pour différentes architectures (x86 ou x64). Cette étape reste facultative. Il sera également possible de configurer la plage IP relative à la multidiffusion ou alors de renseigner son contrôleur de domaine si on a décidé de lier ce serveur avec son AD. 

La partie la plus critique est la configuration du DHCP. En effet, selon la configuration du réseau, les réglages peuvent être relativement différent.

Le serveur DHCP et le serveur WDS se trouve sur la même machine : 

Dans ce cas, les deux cases doivent être cochées. Aucune configuration supplémentaire n’est nécessaire, le serveur répondra également aux requêtes PXE lancées par les postes. 

Le serveur DHCP et le serveur WDS sont sur des serveurs distincts dans le même sous-réseau : (notre cas) 

Dans ce cas, la première case uniquement est à cocher. Il sera nécessaire de configurer les options 66 et 67 sur l’étendue DHCP afin d’indiquer l’adresse du serveur PXE et le chemin du fichier de boot, traditionnellement : 

\boot\x64\wdsnbp.com pour du LEGACY 

\boot\x64\wdsmgfw.efi pour du UEFI 

Le serveur DHCP et le serveur WDS sont sur des serveurs distincts dans un sous-réseau différent : 

Effectuer la même opération que pour la situation précédente. 

/!\ Attention, utiliser les options DHCP revient à se limiter à une seule architecture. 

Microsoft recommande de configurer un relais DHCP sur chaque switch avec l’adresse du serveur PXE pour passer outre. Ainsi, les requêtes seront correctement redirigées.

Import des images

Il faut maintenant importer au minimum une image de boot pour que le poste qui reçoivent l’image puisse démarrer.

Pour un déploiement via un partage distant, l’image de boot suffit. Autrement, il est nécessaire d’ajouter également une image d’installation (après SYSPREP) qui comprendra tous les paramétrages et applications nécessaires.  

Il est possible de créer un master local sans MDT et de le déployer ensuite via WDS. Ceci est décrit dans une seconde documentation : «Documentation Création MASTER». 

 

Démarrage en PXE

Sur les postes à déployer, il faut configurer le boot PXE dans le BIOS. D’après les paramètres configurés sur le serveur, le boot n’a pas besoin de confirmation une fois lancé et le déploiement se poursuit automatiquement.