MDT - Guide de résolution des problèmes courants de configuration lors du déploiement d'un système d'exploitation Microsoft
Introduction
Les ressources necessaires pour réaliser vos tests
| Système d'exploitation | vCPU | vMEM | vDisk | Bios |
|---|---|---|---|---|
| Windows Server 2022 Standard edition | 2vcpu | 4GO Ram | 50GO (OS) 100GO (DATA) |
Par défaut |
| Windows 10 x64 22H2 Enterprise edition | 2vcpu | 4GO Ram | 48 GO | UEFI TPM actif |
| Windows 10 x64 22H2 Enterprise edition | 2vcpu | 4GO Ram | 48 GO | BIOS LEGACY |
| Windows 11 x64 22H2 Enterprise edition | 2vcpu | 4GO Ram | 48 GO | UEFI TPM actif |
Il est préférable d'avoir un ordinateur avec 16go minimum avec un processeur avec plusieurs cœurs (Ryzen ou Core i5 ou i7). Si vous avez un ordinateurs portables, vérifier que votre ordinateur est en processeurs qui fini par H.
Liens :
Le lien permanent pour trouver la dernière version pour télécharger et installer le dernier Windows ADK : https://aka.ms/ADK
Téléchargez l’ADK Windows pour Windows 11, version 22H2.
Téléchargez le module complémentaire PE Windows pour le kit ADK Windows pour Windows 11, version 22H2.
Téléchargez le Microsoft Deployment Toolkit, version 8456
Si votre machine serveur peut se connecter à internet, et que vous avez winget, voici les commandes :
& winget install -e --id Microsoft.WindowsAD -i
& winget install -e --id Microsoft.ADKPEAddon -i
& winget install -e --id Microsoft.DeploymentToolkit
ADK pour Windows 11 ne prend pas en charge x86
 |
| MMC a détecté une erreur dans un complément et le déchargera lors de l'ouverture de la configuration de Windows PE. |
- Accédez au répertoire d'installation de Windows ADK : "C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment"
- Créez un nouveau dossier, nommez-le : x86
- Créez un nouveau dossier dans le dossier x86, nommez-le : WinPE_OCs
#Requires -RunAsAdministrator
# Requires the script to be run as an administrator
# Try block to handle errors
Try {
# Check if the system architecture is AMD64 (64-bit)
if ($env:PROCESSOR_ARCHITECTURE -eq 'AMD64'){
# Set the path to the Windows Preinstallation Environment (WPE) for 64-bit systems
$WPE = $((Get-ItemProperty -Path "HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows Kits\Installed Roots").KitsRoot10) + "Assessment and Deployment Kit\Windows Preinstallation Environment"
} else {
# Set the path to the Windows Preinstallation Environment (WPE) for 32-bit systems
$WPE = $((Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows Kits\Installed Roots").KitsRoot10) + "Assessment and Deployment Kit\Windows Preinstallation Environment"
}
} Catch {
# If an error occurs, install the necessary components using 'winget' and exit the script
& winget install -e --id Microsoft.WindowsAD -i
& winget install -e --id Microsoft.ADKPEAddon -i
exit
}
# Check if the path to the 32-bit WPE directory exists, if not, create it
if ((test-path $($WPE + "x86")) -eq $false){
New-Item -Path $($WPE + "\x86") -ItemType Directory
}
# Check if the path to the WinPE_OCs directory exists, if not, create it
if ((test-path $($WPE + "x86\WinPE_OCs")) -eq $false){
New-Item -Path $($WPE + "\x86\WinPE_OCs") -ItemType Directory
}
Lors du premier démarrage de l'environnement de pré installation de Windows (WinPE), un message d'erreur apparaît.
 |
| Le message en question |
- Accédez à C:\Program Files\Microsoft Deployment Toolkit\Templates
- Copiez Unattend_PE_x64.xml vers un emplacement de sauvegarde, au cas où
- Modifiez Unattend_PE_x64.xml
- Remplacez le contenu de Unattend_PE_x64.xml par :
<unattend xmlns="urn:schemas-microsoft-com:unattend"> <settings pass="windowsPE"> <component language="neutral" name="Microsoft-Windows-Setup" processorarchitecture="amd64" publickeytoken="31bf3856ad364e35" versionscope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State"> <display> <colordepth>32</colordepth> <horizontalresolution>1024</horizontalresolution> <refreshrate>60</refreshrate> <verticalresolution>768</verticalresolution> </display> <runsynchronous> <runsynchronouscommand wcm:action="add"> <description>Lite Touch PE</description> <order>1</order> <path>reg.exe add "HKLM\Software\Microsoft\Internet Explorer\Main" /t REG_DWORD /v JscriptReplacement /d 0 /f</path> </runsynchronouscommand> <runsynchronouscommand wcm:action="add"> <description>Lite Touch PE</description> <order>2</order> <path>wscript.exe X:\Deploy\Scripts\LiteTouch.wsf</path> </runsynchronouscommand> </runsynchronous> </component> </settings> </unattend>
- Mettez à jour le déploiement partagé et choisissez de régénérer complètement les images de démarrage.
Problème de démarrage PXE sur les périphériques UEFI
Le démarrage PXE sur les appareils UEFI peut s'arrêter à l'étape "Starting PXE over IPV4". C'est un problème connu qui peut être résolu en désactivant NetBIOS sur TCP/IP.
- Ouvrez les paramètres Réseau et Internet sur votre serveur MDT.
- Cliquez sur Modifier les options d'adaptateur.
- Ouvrez les propriétés de votre adaptateur réseau.
- Ouvrez le Protocole Internet version 4 (TCP/IPv4).
- Cliquez sur Avancé et accédez à l'onglet WINS.
- Désactivez NetBIOS sur TCP/IP dans les paramètres de NetBIOS.
- Désactivez NetBIOS sur TCP/IP pour éviter les problèmes de démarrage PXE.
 |
| Désactivez NetBIOS sur TCP/IP pour éviter les problèmes de démarrage PXE |
Activer Bitlocker en attendant l'activation
L'activation de Bitlocker et le stockage de la clé de récupération dans votre annuaire Active Directory sont des étapes par défaut dans la séquence de tâches de MDT. La séquence de tâches s'est terminée avec succès, mais la clé de récupération n'a pas été stockée dans Active Directory.
"L'attente d'activation de Bitlocker" s'affiche lors de la vérification du statut de chiffrement Bitlocker sur le client récemment installé. Cette erreur est survenue en raison d'une défaillance de pré-vérification dans l'étape Enable Bitlocker de la séquence de tâches.
 |
| Bitlocker attend l'activation, ce qui empêche son activation. |
- Ouvrez l'emplacement des données du partage de déploiement sur le serveur MDT.
- Accédez au dossier "Scripts".
- Copiez ZTIBde.wsf vers un emplacement de sauvegarde, au cas où.
- Modifiez ZTIBde.wsf.
- Recherchez la section ci-dessous et supprimez-la complètement.
- Sauvegardez le fichier ZTIBde.wsf et relancez la séquence de tâches ; maintenant Bitlocker chiffrera le disque et stockera la clé dans Active Directory.
Création d'une image de référence : Échec de l'exécution de Sysprep
La création d'une image de référence, comprenant les dernières mises à jour de Windows et des applications personnalisées, se déroulait bien jusqu'à l'étape de Sysprep. Sysprep se termine constamment par un plantage avec l'erreur suivante : FAILURE ( 6192 ): ERROR – Sysprep did not complete successfully.
Sysprep n'a pas pu être terminé avec succès et a affiché une erreur lors du démarrage de l'étape de sysprep.
Après plusieurs jours de recherche, j'ai finalement trouvé la cause de ce plantage, en raison du manque de détails d'erreur appropriés dans les fichiers journaux.
J'utilisais un pilote NIC personnalisé pour mon client VMware (VMXNet3) afin d'améliorer les performances réseau. Le pilote VMXNet3 était injecté au début de la séquence de tâches.
Sysprep a supprimé le pilote injecté et n'a donc pas pu effectuer la sysprep de l'image de référence. Le problème a été résolu après avoir utilisé la carte réseau VMware E1000 par défaut, qui est disponible dans WinPE.
Lors de la création d'une image de référence sur un système UEFI, vous rencontrez une erreur indiquant “can not find script LTIBootstrap.vbs”
Vous rencontrez une erreur spécifique lors de l'exécution de Sysprep sur des machines virtuelles en mode UEFI dans VMware. Cette erreur n'apparaît pas sur les machines virtuelles en mode BIOS hérité
L'erreur "Cannot find script for 'C:\LTIBootstrap.vbs'" se produit à l'étape d'exécution de Sysprep, et la séquence de tâches devrait redémarrer et revenir à WinPE, mais elle redémarre plutôt dans Windows. Ce bogue est causé par un redémarrage Windows en attente. L'étape de sysprep redémarre la machine virtuelle, mais MDT a déjà configuré la machine virtuelle pour redémarrer dans WinPE, donc le redémarrage Windows en attente persiste.
Cette erreur peut être résolue en ajoutant une étape "Redémarrer l'ordinateur" juste avant l'étape de création d'image dans l'étape de restauration de l'état (State Restore).
Durée de chargement du fichier .WIM par PXE
Le chargement du fichier .WIM (Litetouch.WIM) via PXE prenait environ 1 minute, mais du jour au lendemain, il a commencé à prendre jusqu'à 3,5 heures pour se charger.
Ce problème a été résolu en désactivant l'extension de fenêtre variable (Variable Window Extension) et en définissant une taille de bloc maximale dans Windows Deployment Services (WDS). Par défaut, cette valeur était définie sur 0 dans mes paramètres WDS.
Voici les étapes à suivre :
- Ouvrez Windows Deployment Services (WDS).
- Accédez aux propriétés de votre serveur WDS.
- Naviguez vers l'onglet TFTP.
- Définissez la taille de bloc maximale (Maximum Block Size) sur 16384.
- Décochez la case "Enable Variable Window Extension" pour désactiver l'extension de fenêtre variable.
- Ces ajustements permettront d'améliorer les performances de chargement du fichier .WIM via PXE et de réduire considérablement le temps de chargement.
Problème avec le Secure Boot sur Windows Server 2022
L'installation de la mise à jour KB5022842 peut entraîner une erreur de violation de sécurité (Security Violation Error) dans Windows Boot Manager, en raison d'un problème lié au démarrage sécurisé (Secure Boot).
Toutefois, Microsoft a publié une nouvelle mise à jour le 14 mars (KB5023705) qui résout ce problème.
Si vous rencontrez cette erreur et ne pouvez pas installer la mise à jour KB5023705, une solution de contournement consiste à désactiver le démarrage sécurisé (Secure Boot) sur votre machine virtuelle Windows Server 2022.
Veuillez noter que la désactivation du démarrage sécurisé peut réduire la sécurité de votre système, il est donc recommandé de l'activer dès que vous avez installé la mise à jour appropriée (KB5023705) pour résoudre ce problème.
Assurez-vous de suivre les recommandations de Microsoft et de VMware pour garantir un fonctionnement sécurisé de votre environnement.
Échec du déploiement sur les systèmes basés sur le BIOS
La séquence de tâches MDT échoue sur les systèmes basés sur le BIOS car le micrologiciel du BIOS est incorrectement identifié comme UEFI.
Le message d'erreur:
Failure (5616) 15299 Verify BCDBootExLiteTouch deployment failed, Return Code = 2147467259 0x80004005
Failed to run the action: Install Operating system
Unknown error (error: 000015F0, Source: Unknown)
L'erreur "Failure (5616) 15299 Verify BCDBootEx" est causée par une identification incorrecte du firmware BIOS en tant qu'UEFI. Microsoft a corrigé ce problème avec la mise à jour KB4564442.
Pour résoudre ce problème, vous pouvez télécharger le correctif à partir du lien suivant : https://download.microsoft.com/download/3/0/6/306AC1B2-59BE-43B8-8C65-E141EF287A5E/KB4564442/MDT_KB4564442.exe
Assurez-vous de télécharger et d'appliquer le correctif approprié à votre système. Suivez les instructions fournies par Microsoft pour l'installation du correctif afin de résoudre l'erreur "Failure (5616) 15299 Verify BCDBootEx".
N'oubliez pas de redémarrer votre système après l'installation du correctif pour que les changements prennent effet.
L'installation de la mise à jour KB5022842 peut entraîner une erreur de violation de sécurité (Security Violation Error) dans Windows Boot Manager, en raison d'un problème lié au démarrage sécurisé (Secure Boot).
Toutefois, Microsoft a publié une nouvelle mise à jour le 14 mars (KB5023705) qui résout ce problème.
Si vous rencontrez cette erreur et ne pouvez pas installer la mise à jour KB5023705, une solution de contournement consiste à désactiver le démarrage sécurisé (Secure Boot) sur votre machine virtuelle Windows Server 2022.
Veuillez noter que la désactivation du démarrage sécurisé peut réduire la sécurité de votre système, il est donc recommandé de l'activer dès que vous avez installé la mise à jour appropriée (KB5023705) pour résoudre ce problème.
Assurez-vous de suivre les recommandations de Microsoft et de VMware pour garantir un fonctionnement sécurisé de votre environnement.
Échec du déploiement sur les systèmes basés sur le BIOS
La séquence de tâches MDT échoue sur les systèmes basés sur le BIOS car le micrologiciel du BIOS est incorrectement identifié comme UEFI.
Le message d'erreur:
LiteTouch deployment failed, Return Code = 2147467259 0x80004005
Failed to run the action: Install Operating system
Unknown error (error: 000015F0, Source: Unknown)
L'erreur "Failure (5616) 15299 Verify BCDBootEx" est causée par une identification incorrecte du firmware BIOS en tant qu'UEFI. Microsoft a corrigé ce problème avec la mise à jour KB4564442.
Pour résoudre ce problème, vous pouvez télécharger le correctif à partir du lien suivant : https://download.microsoft.com/download/3/0/6/306AC1B2-59BE-43B8-8C65-E141EF287A5E/KB4564442/MDT_KB4564442.exe
Assurez-vous de télécharger et d'appliquer le correctif approprié à votre système. Suivez les instructions fournies par Microsoft pour l'installation du correctif afin de résoudre l'erreur "Failure (5616) 15299 Verify BCDBootEx".
N'oubliez pas de redémarrer votre système après l'installation du correctif pour que les changements prennent effet.
802.1X ne fonctionne pas correctement avec Windows 11 ADK
Avec le dernier module ADK Windows 11, le service Dot3Svc ne démarre pas par défaut. Si vous utilisez le NAC (Network Access Control) pendant le déploiement du système d'exploitation, vous risquez de rencontrer un problème lors de la mise à niveau vers l'ADK Windows 11 (version 10.1.22000.1).
802.1X est un standard lié à la sécurité des réseaux informatiques, mis au point en 2001 par l'IEEE (famille de la norme IEEE 802).
Il permet de contrôler l'accès aux équipements d'infrastructures réseau (et par ce biais, de relayer les informations liées aux dispositifs d'identification).
Problème 1 :
Pour utiliser 802.1X, il est nécessaire d'ajouter le package WinPE-Dot3svc à votre image WinPE. Cependant, même si vous ajoutez ce package, le service Dot3svc ne démarre pas dans Windows PE. Cela est dû au fait que Microsoft a oublié d'inclure un fichier DLL (mobilenetworking.dll) lors de la création du package WinPE-Dot3Svc.
Pour contourner ce problème, vous pouvez copier le fichier mobilenetworking.dll dans le dossier System32 de WinPE (selon la façon dont vous utilisez WinPE, cela peut nécessiter de monter manuellement l'image et de copier le fichier à la main).
Le fichier mobilenetworking.dll peut être trouvé dans une version régulière/complète de Windows 11 Pro/Enterprise. Il vous suffit de récupérer le fichier à partir de là.
Pour contourner ce problème, vous pouvez copier le fichier mobilenetworking.dll dans le dossier System32 de WinPE (selon la façon dont vous utilisez WinPE, cela peut nécessiter de monter manuellement l'image et de copier le fichier à la main).
Problème 2 :
Maintenant, grâce à la solution de contournement du Problème 1, nous pouvons démarrer le service dot3svc ! Cependant, vous pourriez encore rencontrer des problèmes d'authentification 802.1x.
Pour résoudre ce problème spécifique, vous devez ajouter certaines clés de registre à votre image WinPE :
Clé : HKLM\WinPE\ControlSet001\Services\EAPHost
Nom : UseLegacyTlsStack
Type : REG_DWORD
Valeur : 1
Une fois que la ruche correcte est chargée, vous pouvez ajouter la valeur de registre requise de cette manière : reg add HKLM\WinPE\ControlSet001\Services\EAPHost /t REG_DWORD /v UseLegacyTlsStack /d 1
Cela devrait probablement être fait en montant le fichier Wim de WinPE, puis en chargeant la ruche System de votre WinPE en exécutant : reg.exe load HKLM\WinPE Mount Path\Windows\System32\Config\SYSTEM
Une fois que la ruche correcte est chargée, vous pouvez ajouter la valeur de registre requise de cette manière : reg add HKLM\WinPE\ControlSet001\Services\EAPHost /t REG_DWORD /v UseLegacyTlsStack /d 1
Enfin, vous devez décharger la ruche système en exécutant : reg.exe unload HKLM\WinPE Mount Path
Démontez le fichier WIM et validez les modifications. Cela devrait résoudre le problème d'authentification 802.1x.
Win 10 22H2 l'integration Language pack
- Modifier le fichier CustomSettings.ini
- Ajoutez une variable appelée TEMP_UILang à la section [Settings] du fichier CustomSettings.ini.[Settings]
Priority=Init,TaskSequenceID,ByVMType,ByDesktopType,Make,Default Properties=MyCustomProperty,TEMP_UILang [Init] TEMP_UILang=NotSet - Créer le script ForceUILanguage.wsf : Ce script forcera la langue de l'interface utilisateur à "en-us" pendant le processus de déploiement. Placez-le dans le dossier Scripts\Misc\Tools de votre partage de déploiement MDT.
<job id="TEMP_UILanguage"> <script language="VBScript" src="..\..\ZTIUtility.vbs"/> <script language="VBScript"> Option Explicit Dim iRetVal iRetVal = 0 On Error Resume Next iRetVal = ZTIProcess ProcessResults iRetVal On Error Goto 0 Function ZTIProcess() oLogging.CreateEntry oUtility.ScriptName & ": Starting User Language Settings", LogTypeInfo Dim sUILang sUILang = oEnvironment.Item("UILANGUAGE") If Trim(LCase(sUILang)) <> "en-us" then oEnvironment.Item("UILANGUAGE") = "en-us" End If oEnvironment.Item("TEMP_UILang") = sUILang oLogging.CreateEntry oUtility.ScriptName & ": Finished Settings", LogTypeInfo End Function </script> </job>
- Créer une application : Créez une application dans MDT qui contient un script PowerShell appelé Set-UserLang.ps1. Ce script utilise la variable TEMP_UILang pour définir la langue de l'utilisateur à l'aide de commandes PowerShell telles que Install-Language et Set-WinUILanguageOverride.
$tsenv = New-Object -COMObject Microsoft.SMS.TSEnvironment $UILang = $tsenv.Value("TEMP_UILang") Install-Language -language $UILang -CopyToSettings Set-WinUILanguageOverride -language $UILang - Ajouter une étape dans la séquence de tâches "Exécuter une ligne de commande" avant de créer le fichier Unattend.xml "Configure" "cscript.exe "%SCRIPTROOT%\ZTIConfigure.wsf"".
Type : Run Command Line
Name : Force UILang to en-us
Description : Force Windows installation to en-us (unattended)
Command : cscript.exe "%SCRIPTROOT%\Misc\Tools\ForceUILanguage.wsf" - Lancer l'application PowerShell : Dans votre séquence de tâches, après l'étape de préparation du système d'exploitation, ajoutez une étape pour exécuter l'application PowerShell Set-OSUserLang, qui contient le script Set-UserLang.ps1. Cette étape définira la langue de l'utilisateur en fonction de la valeur de TEMP_UILang.
Conclusion
Microsoft ne travaille plus sur le produit MDT, mais avec toutes ces astuces, on peut s'en sortir. Cependant, le dernier clou dans le cercueil va venir avec l'arrêt en natif de la prise en charge du Vbscripts. La configuration prend plus de temps et vous rencontrerez des problèmes inhabituels lors de la mise en œuvre de MDT.
Commentaires
Enregistrer un commentaire