OSD / MDT / WDS¶

Pourquoi le déploiement OS est une affaire de GPO¶

La chaîne réelle d'un poste neuf¶

Un déploiement OS n'est pas un bloc unique.

C'est une chaîne de décisions successives.

Chaque brique répond à une question différente.

WDS répond à la question "quel environnement de démarrage fournir ?".

MDT répond à la question "quelles étapes exécuter dans quel ordre ?".

Sysprep répond à la question "dans quel état l'image doit-elle être généralisée ?".

Active Directory et gpsvc répondent à la question "quelle configuration standard appliquer à cette machine devenue membre du domaine ?".

Le piège classique consiste à croire que l'image "porte déjà tout".

En pratique, l'image ne doit porter que le strict socle.

Le durcissement durable, les paramètres d'entreprise et une partie des dépendances applicatives arrivent ensuite via GPO.

La séquence WDS → MDT → GPO → Sysprep/Audit Mode¶

L'ordre logique à retenir est simple.

WDS fournit l'amorce.

MDT pilote la séquence.

Sysprep nettoie ou prépare l'image de référence.

GPO stabilise la machine une fois qu'elle existe vraiment dans le domaine.

Le point d'attention important : Sysprep/Audit Mode intervient avant la vie de la machine en production.

Les GPO de production, elles, interviennent après la création de l'objet machine, la jonction, puis un démarrage où gpsvc peut enfin travailler normalement.

Autrement dit :

• WinPE ne traite pas les GPO de domaine
• Une machine non jointe ne traite pas les GPO de domaine
• Une machine jointe mais qui n'a pas encore redémarré dans la bonne phase peut ne pas avoir appliqué la GPO attendue
• Une task sequence ne doit jamais dépendre d'un paramètre GPO qui n'existe qu'après le redémarrage post-join

Diagramme du flux OSD complet¶

flowchart LR
    A[Power on / PXE] --> B[DHCP + IP Helper]
    B --> C[WDS]
    C --> D[WinPE x64]
    D --> E[Bootstrap MDT]
    E --> F[Deployment Share MDT]
    F --> G[Task Sequence]
    G --> H[Apply OS + Drivers + Apps]
    H --> I[Sysprep / Capture ou OOBE]
    I --> J[First full OS boot]
    J --> K{Join mode}
    K -->|Domain Join| L[Objet machine AD]
    K -->|Offline Domain Join| M[Blob ODJ injecté]
    L --> N[Redémarrage]
    M --> N
    N --> O[gpsvc]
    O --> P[Computer GPO]
    P --> Q[Logon utilisateur]
    Q --> R[User GPO]

Sysprep et Audit Mode : où les GPO s'insèrent réellement¶

Audit Mode sert à préparer l'image de référence.

Il n'est pas là pour "simuler la prod".

Si vous capturez une image pendant Audit Mode avec des paramètres locaux bricolés pour compenser des GPO qui arriveront plus tard, vous fabriquez une image ambiguë.

Le bon modèle :

1. Image de référence la plus neutre possible
2. Drivers, agents et apps communes via task sequence
3. Paramètres d'entreprise via GPO après la vraie jonction

Ce que la GPO apporte que l'image ne doit pas porter¶

Une image figée vieillit mal.

Une GPO vieillit mieux parce qu'elle reste modifiable sans recapturer de WIM.

WDS : serveur de déploiement réseau¶

Ce que WDS fait réellement sur Windows Server 2022¶

WDS n'est pas un moteur d'industrialisation complet.

C'est un serveur de boot et de distribution d'images au sens réseau.

Il sert surtout à :

• répondre au client PXE
• exposer un environnement WinPE x64
• héberger des images de démarrage et, si vous le souhaitez, des images d'installation
• servir de point d'entrée à MDT

Sur Windows Server 2022, le duo classique reste :

• WDS pour l'amorçage réseau
• MDT 8456 pour l'orchestration détaillée

WDS seul suffit pour des scénarios simples.

Dès que vous avez des variables de nommage, du join conditionnel, des apps, du BitLocker, des drivers par modèle ou plusieurs branches de déploiement, MDT devient le vrai chef d'orchestre.

Installation du rôle WDS, des outils RSAT et vérifications DISM¶

Sur le serveur WDS lui-même :

Install-WindowsFeature -Name WDS -IncludeManagementTools

wdsutil /Initialize-Server /RemInst:"D:\RemoteInstall"

Get-WindowsFeature -Name WDS*

Sur une station d'administration Windows 11 avec RSAT :

Add-WindowsCapability -Online -Name Rsat.ServerManager.Tools~~~~0.0.1.0
Add-WindowsCapability -Online -Name Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0
Add-WindowsCapability -Online -Name Rsat.GroupPolicy.Management.Tools~~~~0.0.1.0

Pour contrôler les WIM avant import :

dism /Get-WimInfo /WimFile:"E:\sources\boot.wim"
dism /Get-WimInfo /WimFile:"E:\sources\install.wim"

Trois vérifications DISM évitent beaucoup de faux départs :

• l'architecture est bien amd64
• l'index choisi correspond au bon SKU
• l'image de boot contient bien les composants WinPE attendus

Images de démarrage WinPE x64 et images d'installation¶

Retenez la différence suivante :

• l'image de démarrage démarre la machine
• l'image d'installation installe Windows

En pratique, avec MDT, WDS sert surtout un boot image WinPE x64 généré par MDT.

L'installation finale, elle, est davantage pilotée par la task sequence MDT que par une simple sélection manuelle d'index WIM.

En 2026, la règle opérationnelle reste simple :

WinPE x64 uniquement, sauf héritage matériel très particulier.

Le maintien d'images x86 crée plus de dette que de valeur dans la plupart des parcs.

Import typique dans WDS¶

# 1. Importer le boot image généré par MDT
# 2. Valider son démarrage sur un poste UEFI x64
# 3. Ne publier l'install image WDS que si vous utilisez aussi des scénarios sans MDT

Si MDT est votre moteur principal :

• publiez le boot image MDT dans WDS
• laissez MDT piloter la task sequence
• n'ajoutez des install images WDS que pour des scénarios de secours ou de lab

GPO utiles autour de WDS¶

Les GPO ne remplacent pas les paramètres PXE.

Elles encadrent le contexte autour de WDS.

Exemples utiles :

• empêcher les postes de production de rester dans un cycle de redémarrage réseau
• contrôler les droits locaux et la surface d'attaque pendant OSD
• préparer les prérequis post-déploiement comme BitLocker, LAPS, Defender ou l'inscription automatique de certificats

Sur le sujet F12 PXE, soyez précis :

le vrai prompt PXE dépend du firmware, de WDS et parfois du programme de boot utilisé.

La GPO ne "désactive" pas magiquement un prompt F12 UEFI.

Elle est utile pour le cadre d'exploitation, pas pour le microcode de la carte réseau.

Les méthodes réellement utilisées en production sont :

• ordre de boot BIOS/UEFI géré par outil constructeur
• scoping DHCP/VLAN réservé aux zones d'imaging
• approbation des clients dans WDS
• boot program sans interaction seulement sur les segments de staging

Table des options DHCP souvent citées avec WDS¶

Exemples de boot files rencontrés :

GPO de cadrage utiles avant même le premier déploiement¶

Même si elles n'agissent pas dans WinPE, certaines GPO doivent exister avant le projet OSD.

MDT 8456 : task sequences et GPO¶

LiteTouch vs ZeroTouch : où commencent les attentes irréalistes¶

MDT 8456 sait faire beaucoup.

Mais il ne fait pas tout seul du Zero Touch au sens large.

Dans le vocabulaire opérationnel :

• LiteTouch = MDT + intervention minimale opérateur
• ZeroTouch = MDT intégré à une solution d'orchestration plus large, historiquement MECM/SCCM

Si vous utilisez MDT + WDS sans MECM, vous êtes en pratique sur du LiteTouch, même très bien automatisé.

Ce n'est pas un problème.

Le problème commence quand l'équipe promet un "zero touch" tout en conservant des choix manuels de task sequence, d'OU ou de nom de poste.

Variables MDT critiques à connaître¶

Trois variables reviennent dans presque tous les projets :

Variables souvent liées :

Le point à retenir :

la bonne GPO n'arrive que si la bonne OU reçoit la machine.

Une task sequence parfaitement exécutée qui joint la machine dans le conteneur CN=Computers au lieu de OU=Workstations,OU=Paris produit souvent un poste "techniquement déployé" mais fonctionnellement non standard.

Extrait type de règles MDT¶

[Settings]
Priority=DefaultGateway, TaskSequenceID, Default
Properties=MyOU

[10.10.20.1]
MachineObjectOU=OU=Workstations,OU=Paris,DC=quid,DC=local

[WIN11-STD]
OSDComputerName=PC-%SerialNumber%
JoinDomain=quid.local
DomainAdmin=svc_mdtjoin
DomainAdminDomain=quid
SkipDomainMembership=YES

[Default]
KeyboardLocale=fr-FR
UILanguage=fr-FR
UserLocale=fr-FR
TimeZoneName=Romance Standard Time

Le moment exact où la GPO intervient dans la task sequence¶

C'est la question la plus mal comprise du sujet.

Pendant WinPE, il n'y a pas de traitement normal des GPO de domaine.

Pendant l'application de l'image, non plus.

Pendant le State Restore, MDT peut exécuter des scripts, installer des applications, faire la jonction et préparer le premier usage.

Mais la vraie application stable des GPO machine intervient seulement quand :

1. l'OS déployé a démarré
2. la machine est effectivement jointe
3. elle peut contacter un DC
4. gpsvc traite le cycle ordinateur au démarrage suivant

En pratique, la jonction a lieu dans la séquence Restore State via les scripts MDT de domain join.

Le premier traitement GPO pertinent suit donc la jonction et le redémarrage associé.

Conséquence directe :

si une application installée plus tôt dans la task sequence a besoin d'une clé de registre, d'un certificat ou d'un paramètre de sécurité fourni uniquement par GPO, la task sequence arrive trop tôt.

Il faut alors :

• soit pousser ce réglage dans MDT lui-même
• soit retarder l'installation après le redémarrage post-join
• soit repenser la dépendance

Vue séquencée simplifiée¶

Exemple PowerShell : créer un deployment share MDT¶

Import-Module "C:\Program Files\Microsoft Deployment Toolkit\bin\MicrosoftDeploymentToolkit.psd1"

New-PSDrive -Name DS001 -PSProvider MDTProvider -Root "D:\DeploymentShare" `
    -Description "Deployment Share MDT principal" `
    -NetworkPath "\\MDT01\DeploymentShare$"

New-Item -Path "DS001:\Operating Systems" -Enable "True" -Name "Windows 11 24H2 x64" `
    -ItemType "folder"

New-Item -Path "DS001:\Task Sequences" -Enable "True" -Name "Postes standards" `
    -ItemType "folder"

Update-MDTDeploymentShare -Path "DS001:" -Force

À l'usage, ce script n'est que le début.

Il faut encore :

• importer les OS
• organiser les Out-of-Box Drivers par modèle
• créer les task sequences
• signer la gouvernance de nommage, d'OU et de comptes de join

Ce que MDT fait mieux qu'une image "manuelle"¶

Offline Domain Join (djoin.exe)¶

Quand choisir ODJ¶

L'Offline Domain Join répond à un besoin précis.

La machine doit devenir membre du domaine sans dialogue direct initial avec un contrôleur de domaine.

Cas classiques :

• filiale avec lien AD coupé ou intermittent
• zone de staging en DMZ
• chaîne industrielle isolée
• masterisation hors réseau de production

ODJ n'est pas un join "meilleur".

C'est un join différé.

L'identité AD est préparée à l'avance côté domaine, puis injectée côté client via un blob.

Provisionner le blob côté domaine¶

djoin /provision `
      /domain quid.local `
      /machine PC-LYON-042 `
      /savefile C:\Temp\PC-LYON-042.odj `
      /reuse

Ce blob contient ce qu'il faut pour que la machine se déclare comme membre du domaine lors de la reprise locale.

Il doit être protégé comme un secret de déploiement.

Le stocker en clair dans un partage ouvert est une faute de conception.

Injecter le blob sur la machine déployée¶

djoin /requestODJ `
      /loadfile C:\Temp\PC-LYON-042.odj `
      /windowspath C:\Windows `
      /localos

shutdown /r /t 0

Vous pouvez aussi viser une image hors ligne avec /imagepath.

Mais dans les environnements MDT, le scénario le plus lisible reste souvent :

1. appliquer l'OS
2. déposer le blob
3. exécuter djoin /requestODJ
4. redémarrer

GPO et ODJ : quand la politique s'applique¶

ODJ ne change pas la logique GPO.

Il change seulement la manière dont le join est préparé.

La GPO s'applique au premier redémarrage utile après la jonction effective, exactement comme pour un join en ligne.

Ce qu'ODJ ne fait pas :

• il ne donne pas de GPO pendant WinPE
• il ne donne pas de GPO avant le redémarrage post-join
• il ne remplace pas le besoin d'accéder ensuite à un DC pour traiter les stratégies

Ce que vous devez surveiller en ODJ¶

Comparaison : ODJ vs jonction en ligne vs Azure AD Join¶

Où ODJ s'insère le mieux dans un design moderne¶

ODJ reste pertinent quand vous devez garder le monde AD classique tout en traversant une zone sans ligne AD directe.

Il n'est pas le bon réflexe si votre objectif réel est de moderniser l'onboarding cloud.

Dans ce cas, Autopilot et Entra ID répondent souvent mieux au besoin.

Utilisez ODJ quand la contrainte réseau ou de sécurité vous y force.

N'utilisez pas ODJ pour reproduire laborieusement un workflow qui serait plus simple en join en ligne.

Autopilot + GPO : coexistence¶

Le modèle de coexistence à retenir¶

Autopilot n'efface pas automatiquement l'univers GPO.

Dans un scénario Hybrid Azure AD Join, les deux coexistent.

La machine traverse d'abord une phase OOBE et d'enrôlement moderne.

Puis elle entre dans un état où elle peut aussi recevoir les stratégies de groupe héritées du domaine.

Le piège consiste à considérer Autopilot comme un remplaçant immédiat de tout ce que faisaient les GPO.

Ce n'est pas vrai en environnement hybride.

Séquence exacte en scénario hybride¶

Retenez cette séquence sans la mélanger :

1. OOBE démarre sur la machine neuve ou réinitialisée
2. Autopilot identifie le profil matériel et décide du parcours
3. Intune enrollment inscrit la machine et/ou l'utilisateur selon le scénario
4. Hybrid Azure AD Join relie la machine au monde AD classique
5. GPO s'appliquent ensuite parce que la machine devient réellement joignable comme client AD

Si l'équipe attend une GPO avant l'étape 4, l'attente est mal placée.

Tableau de coexistence rapide¶

Ce que GPO sait encore mieux faire¶

Il faut être lucide : Intune a énormément progressé.

Mais il reste des zones où GPO garde un avantage opérationnel ou de profondeur.

Exemples courants :

• paramètres très anciens encore portés par ADMX on-prem
• stratégies liées à l'architecture AD classique
• loopback processing pour RDS ou postes partagés
• scripts de démarrage ordinateur dépendants du LAN
• ciblage précis par OU, héritage, blocage et sécurité AD
• scénarios où l'appareil doit converger même hors Internet mais sur réseau interne

Formulation utile face au métier :

Autopilot accélère l'entrée en service. GPO continue de gouverner une partie du comportement Windows en mode hybride.

Où les conflits apparaissent vraiment¶

Les conflits ne viennent pas du principe "Autopilot + GPO".

Ils viennent des mêmes paramètres poussés à deux endroits.

Checklist de bon sens :

• un seul maître pour Windows Update
• un seul maître pour le navigateur et Office quand les paramètres sont identiques
• un seul maître pour le chiffrement et l'identité locale
• une matrice claire des réglages pilotés par GPO, CSP Intune ou script

Quand choisir OSD classique, Autopilot, ou hybride¶

Règle de décision rapide¶

Si votre poste doit être prêt avant remise au salarié, avec applications lourdes, drivers spécifiques, BIOS géré et plusieurs séquences conditionnelles, l'OSD classique garde un sens.

Si votre poste peut être remis quasiment brut avec un onboarding piloté par l'identité cloud, Autopilot gagne.

Si vous êtes entre les deux, vous êtes en hybride.

Et dans l'hybride, les GPO ne disparaissent pas par décret.

:material-checklist: Checklist déploiement OSD avec GPO¶

Comment lire cette checklist¶

Le but n'est pas de cocher des cases pour la forme.

Le but est d'éviter les incidents qui font perdre une journée de vague de déploiement.

La colonne statut est volontairement simple :

• ✅ obligatoire = sans cela, le projet est fragile
• ⚠️ recommandé = fortement conseillé en production
• ℹ️ optionnel = utile selon le niveau de maturité

Mini routine de validation après chaque poste¶

À faire juste après un poste pilote :

1. vérifier le nom final
2. vérifier l'OU
3. vérifier la jonction
4. vérifier le premier gpresult
5. vérifier BitLocker / LAPS / Defender

Une machine "arrivée au bureau Windows" n'est pas une machine validée.

La validation se fait sur l'état de conformité.

Anti-patterns à éliminer¶