Windows 11 Feature Updates : ciblage de version, rollout et safeguard holds

L’essentiel

La stratégie Intune Feature updates cible une version Windows supportée et maintient les appareils sur cette cible jusqu’à modification ou retrait. Elle ne rétrograde pas un appareil déjà plus récent.

Les update rings continuent de gérer l’expérience, les délais, les notifications et les redémarrages. Microsoft recommande de ne pas cumuler inutilement les reports de Feature Update dans l’anneau avec une stratégie de version cible.

Un safeguard hold protège les appareils présentant une combinaison matériel, pilote ou logiciel associée à un problème connu. Je privilégie la résolution du problème et la levée du hold; l’opt-out reste une exception de laboratoire à haut risque.

La stratégie Intune Feature updates cible une version Windows supportée et maintient les appareils sur cette cible jusqu’à modification ou retrait. Elle ne rétrograde pas un appareil déjà plus récent.

Pourquoi cette technologie existe

La policy Feature updates inscrit les appareils au service de déploiement et indique une version cible. Les appareils déjà à cette version y restent; ceux en dessous peuvent recevoir la mise à niveau selon les options de rollout.

Une cible plus ancienne ne déclenche pas de downgrade. Cette règle est importante pendant une fusion de parcs: les machines déjà plus récentes doivent être identifiées plutôt que considérées en échec.

L’anneau Windows Update gère le comportement client, notamment deadlines, grace period, active hours et notifications. La version cible appartient à la policy Feature Update afin de réduire les interactions entre reports.

Feature Updates et safeguard holds s’appuie sur la chaîne Intune → Deployment → WU → Client. Comprendre le rôle de chaque étape permet de distinguer la demande envoyée, le traitement réellement effectué et l’état finalement observé.

Les dépendances importantes sont licences et éditions Windows supportées, devices Entra et Intune éligibles, diagnostic data gouvernée, update source Windows Update. Elles font partie du fonctionnement de la technologie: leur absence peut expliquer un résultat sans remettre en cause le composant étudié.

Les cas limites les plus utiles à connaître sont Policy appliquée, aucune offre, Poste plus récent et Offre retardée. Ils montrent où le modèle nominal peut diverger et quelles données permettent de lire cette divergence.

Le parcours devient plus concret en suivant les composants dans leur ordre réel. Intune ouvre la séquence: Déclare version cible et audience. Deployment prend ensuite le relais: Le service inscrit et orchestre le rollout. Le traitement se poursuit avec WU, où Évalue éligibilité, compatibilité et offre. Enfin, Client ferme la boucle: Télécharge, installe et rapporte les états. Cette lecture évite de confondre un ordre envoyé avec son exécution, puis son exécution avec l’état restitué à l’administrateur. Elle indique aussi où chercher l’heure, l’identité et le résultat qui permettront de rapprocher deux observations.

Les limites se comprennent mieux à partir de situations concrètes. « Policy appliquée, aucune offre » conduit d’abord à vérifier Feature report, car la cause possible est Hold ou inscription en attente. Pour « Poste plus récent », la preuve utile devient Build local. Les cas « Offre retardée » et « Rollback setup » montrent enfin que deux symptômes proches peuvent appartenir à des phases différentes. Cette distinction n’est pas un détour de dépannage: elle fait partie du modèle de fonctionnement et explique la manière dont Feature Updates et safeguard holds expose ses états, ses délais et ses erreurs.

Dans un environnement réel, les conditions licences et éditions Windows supportées, devices Entra et Intune éligibles, diagnostic data gouvernée, update source Windows Update doivent être réunies en même temps. La validation porte ensuite sur Choisir une version supportée et la date cible, Créer la policy Feature Update pilote, Attendre OfferReady avant de retirer les reports et Observer holds et compatibilité. Ce croisement est important: un prérequis confirme que le scénario peut fonctionner, alors qu’un contrôle de validation prouve qu’il a effectivement fonctionné. Il reste donc possible d’avoir une plateforme éligible mais mal configurée, ou une première exécution réussie dont l’état n’est pas encore visible dans le service. Le modèle présenté dans cet article sert précisément à lire ces écarts sans attribuer trop vite le résultat au mauvais composant. Il donne aussi au support un vocabulaire commun pour décrire l’étape atteinte et la preuve encore manquante.

Architecture, composants et flux de données

La policy Feature updates inscrit les appareils au service de déploiement et indique une version cible. Les appareils déjà à cette version y restent; ceux en dessous peuvent recevoir la mise à niveau selon les options de rollout.

Une cible plus ancienne ne déclenche pas de downgrade. Cette règle est importante pendant une fusion de parcs: les machines déjà plus récentes doivent être identifiées plutôt que considérées en échec.

L’anneau Windows Update gère le comportement client, notamment deadlines, grace period, active hours et notifications. La version cible appartient à la policy Feature Update afin de réduire les interactions entre reports.

Prérequis, compatibilité et limites de support

Le fonctionnement décrit suppose licences et éditions Windows supportées, devices Entra et Intune éligibles, diagnostic data gouvernée, update source Windows Update, anneau d’expérience défini. Ces conditions permettent de distinguer une limite de Feature Updates et safeguard holds d’un scénario simplement non éligible.

• licences et éditions Windows supportées
• devices Entra et Intune éligibles
• diagnostic data gouvernée
• update source Windows Update
• anneau d’expérience défini
• inventaire applicatif et matériel
• cohortes et critères rollback

Cycle de fonctionnement, étape par étape

Le cycle de Feature Updates et safeguard holds traverse Intune → Deployment → WU → Client. La procédure détaille ce que produit chaque composant et la preuve attendue avant de passer à l’étape suivante.

Dans Feature Updates et safeguard holds, les étapes « Identifier les composants », « Observer le traitement », « Relier les états », « Valider le modèle » séparent l’intention, son transport, son traitement et le résultat final.

Fonctionnement détaillé de Feature Updates et safeguard holds

La policy Feature updates inscrit les appareils au service de déploiement et indique une version cible. Les appareils déjà à cette version y restent; ceux en dessous peuvent recevoir la mise à niveau selon les options de rollout.

Une cible plus ancienne ne déclenche pas de downgrade. Cette règle est importante pendant une fusion de parcs: les machines déjà plus récentes doivent être identifiées plutôt que considérées en échec.

L’anneau Windows Update gère le comportement client, notamment deadlines, grace period, active hours et notifications. La version cible appartient à la policy Feature Update afin de réduire les interactions entre reports.

• licences et éditions Windows supportées
• devices Entra et Intune éligibles
• diagnostic data gouvernée
• update source Windows Update

Traitement, exploitation et cas limites de Feature Updates et safeguard holds

Lors d’une transition depuis les reports d’anneau, je crée d’abord la policy de version, puis j’attends l’état OfferReady dans le rapport organisationnel avant de remettre le report Feature Update à zéro. Cela évite une fenêtre d’offre non maîtrisée.

Le service Windows Update évalue l’applicabilité à partir de l’inventaire. Un safeguard hold bloque temporairement la mise à niveau lorsqu’un problème connu risque de provoquer rollback, perte de données, connectivité ou fonction critique.

Le Windows release health dashboard et les rapports de mise à jour aident à identifier le hold et la population. Tous les holds ne donnent pas immédiatement un identifiant exploitable localement; je conserve modèle, drivers et applications pour comparer les appareils.

• Déployer sur Test puis Ring 1
• Valider applications et rollback
• Étendre seulement si seuils GO

Lire les états propres à Feature Updates et safeguard holds

Contourner les safeguard holds retire une protection globale pour la policy concernée. Microsoft déconseille ce choix hors validation IT robuste; je ne l’utilise jamais comme réponse automatique à un calendrier projet.

Le pilote inclut applications critiques, VPN, sécurité, chiffrement, pilotes stockage/graphique et dock. Je mesure OfferReady, offering, download, install, rollback et état final, avec une fenêtre compatible avec l’uninstall period.

La validation finale confirme la version, le dernier quality update, l’état BitLocker, les composants de sécurité, les applications métier et la remontée dans les rapports. Un setup réussi sans validation utilisateur n’est pas un GO.

• Policy appliquée, aucune offre — Feature report
• Poste plus récent — Build local
• Offre retardée — Update ring effectif
• Rollback setup — SetupDiag et Panther

Pilote et suivi opérationnel de Feature Updates et safeguard holds

Le pilote couvre le périmètre Windows 11, Feature Updates, Safeguard holds, Intune et contrôle Choisir une version supportée et la date cible. Créer la policy Feature Update pilote. Attendre OfferReady avant de retirer les reports. Les résultats sont segmentés selon les populations réellement concernées par Feature Updates et safeguard holds.

Les cas d’échec « Policy appliquée, aucune offre », « Poste plus récent », « Offre retardée » sont reproduits lorsque c’est possible. Ils vérifient que l’écart reste visible et que la procédure indique une preuve exploitable.

Le suivi après déploiement conserve ne pas combiner reports sans nécessité, ne pas forcer un safeguard hold en production, une policy ne rétrograde pas, suivre la fin de support de la cible. Une évolution de version, de licence ou de dépendance déclenche une nouvelle lecture de ces points.

Interfaces d’observation, commandes et exemples

Les exemples rendent visibles Choisir une version supportée et la date cible. Créer la policy Feature Update pilote. Attendre OfferReady avant de retirer les reports. Observer holds et compatibilité. Leur intérêt est d’identifier le producteur de chaque donnée et le moment où elle est mise à jour.

Pour Feature Updates et safeguard holds, les interfaces documentées restent la référence de conception. Les fichiers, tâches ou clés observés localement servent à expliquer un état précis et peuvent évoluer avec le composant.

# Collecte de diagnostic
$ErrorActionPreference = 'Stop'
try {
  Get-ComputerInfo | Select-Object WindowsProductName,WindowsVersion,OsBuildNumber,OsArchitecture
  Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' | Select-Object DisplayVersion,CurrentBuild,UBR
  Get-WinEvent -LogName 'Microsoft-Windows-WindowsUpdateClient/Operational' -MaxEvents 120 | Select-Object TimeCreated,Id,Message
} catch { Write-Error "Collecte Feature Update impossible : $($_.Exception.Message)"; exit 1 }

Observabilité : où lire l’état réel

La chronologie de Feature Updates et safeguard holds relie Intune, Deployment, WU, Client. Les heures et identifiants communs permettent de savoir si les états appartiennent à la même tentative.

La collecte commence par Choisir une version supportée et la date cible. Créer la policy Feature Update pilote. Attendre OfferReady avant de retirer les reports. Observer holds et compatibilité. Ces contrôles conservent l’état qui explique le symptôme avant une nouvelle évaluation.

Les résultats sont lus avec les causes « Hold ou inscription en attente », « Aucun downgrade », « Deferral résiduel » en tête, sans déduire une correction d’un code ou d’un statut isolé.

• Choisir une version supportée et la date cible.
• Créer la policy Feature Update pilote.
• Attendre OfferReady avant de retirer les reports.
• Observer holds et compatibilité.
• Déployer sur Test puis Ring 1
• Valider applications et rollback
• Étendre seulement si seuils GO

Validation du modèle et cas d’usage

Le modèle est cohérent lorsque Choisir une version supportée et la date cible, Créer la policy Feature Update pilote, Attendre OfferReady avant de retirer les reports et Observer holds et compatibilité. Ces contrôles relient la configuration du service au résultat réellement observé.

• Choisir une version supportée et la date cible.
• Créer la policy Feature Update pilote.
• Attendre OfferReady avant de retirer les reports.
• Observer holds et compatibilité.
• Déployer sur Test puis Ring 1
• Valider applications et rollback
• Étendre seulement si seuils GO

Limites, modes de panne et lecture des erreurs

Les écarts connus de Feature Updates et safeguard holds incluent Policy appliquée, aucune offre, Poste plus récent, Offre retardée, Rollback setup. Le tableau les replace dans leur phase et précise la donnée à contrôler.

Adoption progressive, réversibilité et vigilance

L’adoption de Feature Updates et safeguard holds commence sur le périmètre Windows 11, Feature Updates, Safeguard holds, Intune, Modern Management — Intune, Deployment, WU, Client, licences et éditions Windows supportées, devices Entra et Intune éligibles, diagnostic data gouvernée. Les limites et actions de réversibilité ci-dessous cadrent la progression.