Introduction : l'erreur 0x800705b4 lors de l'enrollment Autopilot
L'erreur 0x800705b4 est l'une des erreurs les plus frustrantes lors d'un déploiement Windows Autopilot : l'appareil se fige à l'étape Preparing your device for mobile management sans fournir d'explication claire. Dans le cas analysé ici, les premières phases de l'enrollment se sont déroulées sans incident — sécurisation du matériel, jonction à l'organisation, enregistrement pour la gestion mobile — avant que le processus ne s'interrompe précisément à cette étape critique.
La cause racine n'est pas un problème réseau, ni un bug Autopilot au sens strict. C'est App Control for Business (anciennement WDAC) qui a bloqué une dépendance DLL introduite dans les versions récentes de l'Intune Management Extension (IME).
Contexte
L'Intune Management Extension est un composant indispensable au bon déroulement de l'Autopilot Enrollment Status Page (ESP). Sans une installation et une initialisation réussies de l'IME, l'ESP reste bloquée indéfiniment jusqu'à expiration du timeout, signalé par le code 0x800705b4.
Analyse des journaux : Code Integrity Event ID 3033
Absence de journaux IME
La première réaction naturelle est d'aller consulter les journaux de l'Intune Management Extension. Cependant, l'IME n'ayant pas pu s'installer, ces journaux sont tout simplement absents. Il faut donc chercher ailleurs.
Le journal Code Integrity révèle la cause
L'examen du journal d'événements Code Integrity met immédiatement en évidence l'Event ID 3033.
Cet événement indique que Code Integrity a bloqué le chargement d'une DLL car elle ne satisfaisait pas les exigences de niveau de signature Enterprise. Deux fichiers sont concernés :
- Une DLL chargée directement par le processus de l'Intune Management Extension
- Une DLL chargée depuis un chemin temporaire Windows Installer lors d'une custom action MSI :
C:\Windows\Installer\MSI*.tmp
Le fichier incriminé est : WixToolset.Dtf.WindowsInstaller.dll
La chaîne causale est donc la suivante :
- L'ESP Autopilot attend que l'IME termine son installation
- L'installation MSI de l'IME extrait ses fichiers de support dans un répertoire temporaire
- App Control for Business bloque le chargement de
WixToolset.Dtf.WindowsInstaller.dll - La custom action MSI ne peut pas s'exécuter
- L'installation de l'IME échoue silencieusement
- L'ESP expire et remonte l'erreur 0x800705b4
La politique App Control for Business en cause
Configuration de la politique
La politique App Control for Business déployée via Intune sur l'appareil était configurée comme suit :
- Enable App Control for Business policy to trust Windows components and Store apps = Enforce
- Trust apps with good reputation : activé
- Trust apps from managed installers : activé
En apparence, cette configuration devrait être compatible avec l'installation de l'IME : Microsoft signe ses propres composants, et l'IME est un logiciel Microsoft. Pourtant, App Control ne fonctionne pas sur ce principe de confiance implicite par héritage.
Pourquoi WDAC bloque malgré tout
App Control for Business évalue chaque fichier individuellement au moment de son chargement. Le fait que le processus parent soit signé par Microsoft ne confère aucune confiance automatique aux DLL qu'il charge.
Dans ce cas précis, WixToolset.Dtf.WindowsInstaller.dll est bien signé — mais uniquement avec la chaîne de signature WiX Toolset / .NET Foundation. Cette signature ne satisfait pas le niveau Enterprise requis par la politique.
Attention
Ne confondez pas la présence d'une signature Authenticode et la conformité au niveau Enterprise signing level de WDAC. Un fichier peut être signé tout en étant bloqué par App Control for Business si sa chaîne de certification ne correspond pas au niveau de confiance attendu par la politique active.
Évolution des dépendances dans l'IME MSI
Changement de dépendance DTF entre versions
En comparant les versions du package MSI de l'IME, on constate un changement de dépendance significatif :
| Version IME | DLL de custom action | Signature Microsoft catalog |
|---|---|---|
| 1.99.101.0 et antérieures | Microsoft.Deployment.WindowsInstaller.dll | Oui (IntuneWindowsAgent.cat) |
| 1.101.103.0 et ultérieures | WixToolset.Dtf.WindowsInstaller.dll | Non (signature WiX uniquement) |
La nouvelle dépendance WixToolset.Dtf.WindowsInstaller.dll est présente dans les versions 1.101.103.0, 1.101.105.0, 1.101.109.0 et 1.101.111.0. La version 1.101.103.0 est la première à embarquer cette nouvelle DLL.
Une migration de toolchain, pas une nouvelle fonctionnalité
L'analyse comparative de SideCarSetupCustomActions.dll entre les versions 1.99.101.0 et 1.101.103.0 révèle que les points d'entrée des custom actions sont identiques. Seule la référence à la DLL DTF a changé :
- Ancienne version : référence à
Microsoft.Deployment.WindowsInstaller - Nouvelle version : référence à
WixToolset.Dtf.WindowsInstaller
Les deux versions ciblent .NET Framework 4.7.2. Il s'agit donc d'une migration de chaîne de build WiX (de WiX v3 vers le WiX Toolset moderne), et non de l'introduction d'une nouvelle fonctionnalité.
Pourquoi l'ancienne DLL ne posait pas de problème
L'ancienne Microsoft.Deployment.WindowsInstaller.dll présentait également une signature embarquée WiX Toolset / .NET Foundation. Ce qui la différenciait est un détail crucial : elle était également couverte par une signature de catalogue Microsoft via IntuneWindowsAgent.cat.
Cette signature catalog permettait à Code Integrity de valider le fichier dans le contexte de la confiance Microsoft Enterprise, satisfaisant ainsi les exigences de la politique WDAC.
La nouvelle WixToolset.Dtf.WindowsInstaller.dll ne bénéficiait pas de cette couverture catalog :
Le changement cassant n'est donc pas simplement le renommage de la DLL — c'est la disparition de la signature de catalogue Microsoft sur la nouvelle dépendance.
Point critique
Le hash Authenticode de WixToolset.Dtf.WindowsInstaller.dll était absent du fichier IntuneWindowsAgent.cat dans les versions IME 1.101.x. Code Integrity ne pouvait donc pas construire de chemin de confiance Microsoft pour cette DLL, même si elle était signée par WiX Toolset.
Contournement temporaire de l'erreur 0x800705b4
En attendant un correctif officiel, la solution de contournement consiste à ajouter une règle de chemin App Control autorisant le répertoire temporaire Windows Installer :
1%WINDIR%\Installer\*Cette règle permet à la custom action MSI d'extraire et charger ses fichiers de support, y compris WixToolset.Dtf.WindowsInstaller.dll, ce qui débloque l'installation de l'IME et permet à l'Autopilot ESP de poursuivre.
Attention
Cette règle de chemin est une solution temporaire, non une bonne pratique. Une règle basée sur un chemin accorde la confiance à un emplacement, pas à un signataire spécifique. Cela affaiblit la posture de sécurité WDAC. À utiliser uniquement le temps de déployer la version IME corrigée.
Correctif définitif : IME 1.103.101.0
Ce que Microsoft a corrigé
Microsoft a résolu le problème dans la version Intune Management Extension 1.103.101.0. La correction est élégante dans sa simplicité : Microsoft n'a pas modifié ni re-signé WixToolset.Dtf.WindowsInstaller.dll. La DLL est byte-pour-byte identique à celle présente dans la version 1.101.111.0.
La correction consiste à avoir ajouté le hash Authenticode de WixToolset.Dtf.WindowsInstaller.dll dans le catalogue signé IntuneWindowsAgent.cat.
Avant et après le correctif
| Version IME | Hash WixToolset.Dtf dans IntuneWindowsAgent.cat | Résultat WDAC |
|---|---|---|
| 1.101.111.0 | Absent | Event ID 3033 — DLL bloquée |
| 1.103.101.0 | Présent | Chemin de confiance Microsoft validé |
Avec ce hash présent dans le catalog, lorsque Code Integrity évalue WixToolset.Dtf.WindowsInstaller.dll extrait sous C:\Windows\Installer\MSI*.tmp, il peut désormais valider la signature de catalogue Microsoft au lieu de se limiter à la signature embarquée WiX Toolset.
Recommandation
Avant de supprimer la règle de contournement %WINDIR%\Installer\*, validez le comportement de l'enrollment Autopilot sur un appareil de test équipé d'IME 1.103.101.0 et de la politique App Control en mode Enforce. Confirmez l'absence d'Event ID 3033 dans le journal Code Integrity avant de déployer la suppression de la règle à grande échelle.
Procédure de diagnostic de l'erreur 0x800705b4
Vérifier le journal Code Integrity
Ouvrez l'Observateur d'événements et naviguez vers Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational. Filtrez sur l'Event ID 3033 pour identifier les fichiers bloqués pendant l'enrollment.
Identifier la DLL bloquée
Dans les événements 3033, notez le chemin complet de la DLL bloquée. Vérifiez si le chemin contient C:\Windows\Installer\MSI*.tmp, ce qui indique un blocage lors d'une custom action MSI.
Vérifier la version de l'IME
Dans le portail Intune, vérifiez la version de l'Intune Management Extension déployée sur les appareils concernés. Si la version est antérieure à 1.103.101.0, le correctif catalog n'est pas appliqué.
Appliquer le contournement temporaire si nécessaire
Si vous ne pouvez pas mettre à jour l'IME immédiatement, ajoutez une règle de chemin App Control pour %WINDIR%\Installer\* afin de débloquer l'enrollment. Documentez cette exception et planifiez sa suppression après mise à jour de l'IME.
Déployer IME 1.103.101.0 ou supérieure
Mettez à jour l'Intune Management Extension vers la version 1.103.101.0 minimum. Vérifiez que le hash de WixToolset.Dtf.WindowsInstaller.dll est présent dans IntuneWindowsAgent.cat en inspectant les propriétés de signature du catalog sur un appareil de test.
Valider et retirer le contournement
Sur un appareil de test, effectuez un enrollment Autopilot complet avec la politique App Control en mode Enforce et la nouvelle version IME. Confirmez l'absence d'Event ID 3033 et la réussite de l'ESP avant de retirer la règle de chemin temporaire de vos politiques.
Synthèse
L'erreur Autopilot 0x800705b4 analysée ici est le résultat d'une chaîne de dépendances fragile entre trois composants :
- App Control for Business en mode Enforce avec niveau de confiance Enterprise
- L'Intune Management Extension et son processus d'installation MSI
- WixToolset.Dtf.WindowsInstaller.dll, une dépendance de custom action dont le hash Authenticode était absent du catalog signé Microsoft
La migration de la chaîne de build WiX du côté Microsoft a introduit une nouvelle DLL techniquement signée, mais non couverte par le catalog IntuneWindowsAgent.cat. Code Integrity a correctement bloqué cette DLL selon les règles de la politique, provoquant l'échec silencieux de l'installation IME et le timeout ESP.
Le correctif apporté dans la version 1.103.101.0 de l'IME — l'ajout du hash manquant dans le catalog Microsoft — illustre l'importance de maintenir une cohérence entre les dépendances d'un package MSI et le catalog de signature qui les couvre, particulièrement dans des environnements où App Control for Business est activement enforced.
