BitLocker ne s’active pas silencieusement avec Intune : diagnostic complet

Résumé opérationnel

Le silent encryption exige un appareil et une policy compatibles. Je contrôle version Windows, jointure Entra, TPM, UEFI, Secure Boot, WinRE, droits utilisateur et absence de demande d’authentification incompatible.

Je n’applique BitLocker que par une autorité de configuration pour une population. Endpoint Security, Settings Catalog, baseline, GPO et MECM peuvent viser les mêmes CSP ou paramètres FVE et créer un conflit difficile à lire.

Le succès comprend trois preuves: volume chiffré avec protecteurs attendus, clé de récupération sauvegardée dans Entra ID et état Intune cohérent. La rotation ou la consultation de clé relève ensuite d’un processus audité.

Le silent encryption exige un appareil et une policy compatibles. Je contrôle version Windows, jointure Entra, TPM, UEFI, Secure Boot, WinRE, droits utilisateur et absence de demande d’authentification incompatible.

Symptôme, contexte et périmètre de l’incident

BitLocker peut être déjà actif par l’OEM, démarrer automatiquement ou être piloté par Intune. L’état observé dépend donc de l’historique du poste autant que du nouveau profil.

Une erreur 65000 ou un profil en erreur ne possède pas une cause universelle. Je corrèle le setting exact, la build Windows et les événements avant de reprendre un contournement terrain.

• volumes OS Windows 10/11 supportés
• BitLocker Endpoint Security/Intune
• Entra joined et hybrid joined selon prérequis

Questions à résoudre et méthode de diagnostic

Pour BitLocker silencieux avec Intune, l’enquête suit le parcours Policy → Windows → Volume → Entra. L’étape utile n’est pas celle qui affiche le dernier message: c’est la première dont le résultat ne correspond plus au fonctionnement attendu.

Les premiers contrôles portent sur manage-bde -status, Get-BitLockerVolume et Get-Tpm et Secure Boot. Ils permettent de dater le problème et de séparer un défaut de ciblage, de transport ou d’exécution avant d’envisager une correction.

Les symptômes « Chiffrement ne démarre pas, Policy conflict et Chiffré mais non compliant » peuvent se ressembler à l’écran tout en provenant de causes différentes. Chaque branche de diagnostic associe donc un signal, une preuve et une action de correction précise.

• qualifier les prérequis silent
• détecter les conflits de policy
• prouver chiffrement et escrow

Cartographie du flux à diagnostiquer

Le profil Intune est traduit en paramètres CSP puis appliqué par le client MDM. Les valeurs peuvent être projetées dans les stratégies FVE, mais le registre seul ne prouve pas la réussite du chiffrement.

Windows évalue matériel, firmware et configuration de récupération. Sur un appareil non compatible avec le scénario silencieux, l’utilisateur peut recevoir une interaction ou le chiffrement peut rester inactif.

La clé de récupération doit être sauvegardée dans Entra. Je vérifie l’identifiant du protecteur local et l’objet device correspondant avant de déclarer l’escrow réussi.

État initial et prérequis de collecte

L’état initial de BitLocker silencieux avec Intune doit couvrir Windows supporté, Entra join ou hybrid join supporté, TPM opérationnel, UEFI natif et Secure Boot. Cette photographie est prise avant de relancer un traitement ou de modifier une affectation.

Les couches Policy, Windows, Volume, Entra sont contrôlées séparément. Un prérequis absent devient alors une cause identifiable, au lieu d’être noyé dans les effets des essais suivants.

• Windows supporté
• Entra join ou hybrid join supporté
• TPM opérationnel
• UEFI natif et Secure Boot
• WinRE disponible
• une seule autorité BitLocker
• droits de lecture recovery key contrôlés

Collecte des preuves : journaux, registre et états

Le journal DeviceManagement-Enterprise-Diagnostics-Provider/Admin relie la policy MDM et le CSP. Microsoft-Windows-BitLocker/BitLocker Management et BitLocker-API/Management détaillent le moteur de chiffrement. System apporte les erreurs TPM.

Je capture les événements dans la fenêtre de synchronisation et de démarrage du chiffrement. Une erreur historique sur un ancien profil ne doit pas être confondue avec la policy active.

• manage-bde -status
• Get-BitLockerVolume
• Get-Tpm et Secure Boot
• reagentc /info
• DM-EDP/Admin
• BitLocker Management et BitLocker-API/Management
• clé présente dans Entra

Investigation pas à pas

L’investigation suit l’ordre Policy → Windows → Volume → Entra. La première divergence confirmée détermine la branche suivante et évite de multiplier les symptômes secondaires.

Pour BitLocker silencieux avec Intune, les contrôles « Capturer l’état initial », « Valider les prérequis », « Isoler la policy » précisent à la fois l’emplacement, le résultat attendu et la vérification à effectuer.

Les prérequis qui bloquent silencieusement

TPM présent ne signifie pas TPM prêt. Je vérifie son état, les erreurs firmware et les événements. Un Secure Boot désactivé ou un démarrage Legacy modifie aussi le scénario supporté.

WinRE doit être disponible pour certains parcours de récupération. reagentc /info confirme son état; une partition de récupération cassée doit être réparée avant la généralisation.

Les paramètres d’authentification au démarrage peuvent rendre impossible l’absence d’interaction. Je vérifie que la policy choisie correspond au modèle silent attendu et au type d’utilisateur.

Chiffrement, protecteur et escrow

Get-BitLockerVolume et manage-bde montrent le chiffrement réel. Je vérifie pourcentage, méthode, ProtectionStatus et KeyProtector.

La présence d’un protecteur RecoveryPassword local ne prouve pas sa sauvegarde cloud. Je recherche la clé sur le bon objet Entra et je contrôle les droits d’accès.

Une rotation produit une nouvelle valeur; son processus doit être audité. Je ne copie jamais une clé de récupération dans un ticket ou un article.

Commandes et scripts de diagnostic en lecture seule

Les exemples ci-dessous contrôlent manage-bde -status, Get-BitLockerVolume, Get-Tpm et Secure Boot, reagentc /info. Leur sortie doit être rapprochée de l’heure de l’incident et du contexte d’exécution concerné.

Pour BitLocker silencieux avec Intune, les données utiles se lisent dans les états locaux, les journaux et les rapports cités dans chaque exemple. Une valeur isolée ne remplace pas cette corrélation.

# Collecte de diagnostic
$ErrorActionPreference = 'Stop'
try {
  $volume = Get-BitLockerVolume -MountPoint 'C:'
  $tpm = Get-Tpm
  $secureBoot = Confirm-SecureBootUEFI
  [pscustomobject]@{ VolumeStatus=$volume.VolumeStatus; Protection=$volume.ProtectionStatus; Encryption=$volume.EncryptionMethod; TpmReady=$tpm.TpmReady; SecureBoot=$secureBoot }
}
catch { Write-Error "Collecte BitLocker impossible : $($_.Exception.Message)"; exit 1 }

$ErrorActionPreference = 'Stop'
try {
  Get-Tpm | Select-Object TpmPresent,TpmReady,TpmEnabled
  Get-BitLockerVolume | Select-Object MountPoint,VolumeStatus,EncryptionPercentage,ProtectionStatus,EncryptionMethod
  reagentc.exe /info
  Get-WinEvent -LogName 'Microsoft-Windows-BitLocker/BitLocker Management' -MaxEvents 100 |
    Select-Object TimeCreated,Id,LevelDisplayName,Message
}
catch {
  Write-Error "Collecte impossible : $($_.Exception.Message)"
  exit 1
}

[09:00:14.005] MDM          Policy=BitLocker Status=Applied
[09:00:18.220] BitLocker    TPMReady=True WinRE=Enabled
[09:01:03.901] BitLocker    Volume=C: Protection=On Percentage=100
[09:01:09.445] Escrow       ProtectorId=<GUID> Target=Entra State=Success
[09:04:11.018] Intune       EncryptionState=Encrypted KeyPresent=True

Arbre de décision : symptômes, causes et corrections

La matrice couvre notamment Chiffrement ne démarre pas, Policy conflict, Chiffré mais non compliant, Clé absente Entra. Ces symptômes servent de points d’entrée; la preuve indiquée dans la même ligne confirme ou écarte la cause.

Après correction, les contrôles prérequis silent validés, une seule autorité et volume chiffré sont rejoués dans les mêmes conditions pour vérifier que le problème n’a pas simplement changé de phase.

Validation de la correction et critères de clôture

La correction de BitLocker silencieux avec Intune est validée avec les mêmes points de mesure que le diagnostic initial. Le résultat local et l’état remonté dans le service doivent raconter la même chronologie.

• prérequis silent validés
• une seule autorité
• volume chiffré
• protecteurs attendus
• clé sauvegardée
• reporting Intune cohérent

Retour arrière, escalade et points de vigilance

Le retour arrière de BitLocker silencieux avec Intune restaure l’état connu décrit ci-dessous. Sa réussite se vérifie sur le poste et dans le service, pas seulement par la disparition d’une affectation.

Une escalade conserve les preuves correspondant à manage-bde -status, Get-BitLockerVolume, Get-Tpm et Secure Boot, reagentc /info ainsi que les causes déjà écartées.