Applications Win32 Intune : comprendre affectations, dépendances et supersedence

L’essentiel

Une dépendance doit être installée avant l’application parente. Elle peut être installée automatiquement sans ciblage explicite, mais toutes les dépendances doivent être des applications Win32 et le graphe complet est limité.

La supersedence demande un ciblage de l’application qui remplace. Elle peut conserver l’ancienne version ou envoyer sa commande de désinstallation. Une chaîne de supersedence comporte au maximum dix nœuds selon la documentation actuelle.

Supersedence et dépendances peuvent partager un sous-graphe, mais les relations contradictoires produisent des conflits. Je représente le graphe sur papier, contrôle chaque règle de détection et teste les retours de redémarrage avant le déploiement.

Une dépendance doit être installée avant l’application parente. Elle peut être installée automatiquement sans ciblage explicite, mais toutes les dépendances doivent être des applications Win32 et le graphe complet est limité.

Pourquoi cette technologie existe

Le ciblage Required ou Available s’applique à l’application racine. Une dépendance marquée installation automatique peut être installée parce qu’elle est requise par le parent, même sans affectation autonome.

Le graphe de dépendances compte l’application parente et toutes les dépendances transitives. Une dépendance partagée entre plusieurs graphes participe au calcul global documenté et peut rendre la conception trop complexe.

Chaque dépendance suit ses propres exigences, règle de détection, commande et codes de retour. Un redémarrage pending ou une détection fausse arrête la progression du parent et doit être lu dans les journaux IME.

Dépendances et supersedence Win32 s’appuie sur la chaîne Assignment → Graph → IME → State. 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 packages Win32 versionnés, règles de détection fiables, codes retour et reboot documentés, graphe dessiné et sans boucle. 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 Parent non installé, Conflict et Ancienne version reste. 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. Assignment ouvre la séquence: Déclenche l’intention Required ou Available. Graph prend ensuite le relais: Résout dépendances et supersedence. Le traitement se poursuit avec IME, où Évalue exigences, détection et commandes. Enfin, State ferme la boucle: Remonte succès, conflit, attente ou erreur. 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. « Parent non installé » conduit d’abord à vérifier IME et état dependency, car la cause possible est Dépendance failed. Pour « Conflict », la preuve utile devient Graphe complet. Les cas « Ancienne version reste » et « Nouvelle app ignorée » 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 Dépendances et supersedence Win32 expose ses états, ses délais et ses erreurs.

Dans un environnement réel, les conditions packages Win32 versionnés, règles de détection fiables, codes retour et reboot documentés, graphe dessiné et sans boucle doivent être réunies en même temps. La validation porte ensuite sur Exporter affectations et relations, Vérifier chaque détection isolément, Construire le graphe sans conflit et Tester install, upgrade et absent. 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

Le ciblage Required ou Available s’applique à l’application racine. Une dépendance marquée installation automatique peut être installée parce qu’elle est requise par le parent, même sans affectation autonome.

Le graphe de dépendances compte l’application parente et toutes les dépendances transitives. Une dépendance partagée entre plusieurs graphes participe au calcul global documenté et peut rendre la conception trop complexe.

Chaque dépendance suit ses propres exigences, règle de détection, commande et codes de retour. Un redémarrage pending ou une détection fausse arrête la progression du parent et doit être lu dans les journaux IME.

Prérequis, compatibilité et limites de support

Le fonctionnement décrit suppose packages Win32 versionnés, règles de détection fiables, codes retour et reboot documentés, graphe dessiné et sans boucle, permission Mobile apps Relate. Ces conditions permettent de distinguer une limite de Dépendances et supersedence Win32 d’un scénario simplement non éligible.

• packages Win32 versionnés
• règles de détection fiables
• codes retour et reboot documentés
• graphe dessiné et sans boucle
• permission Mobile apps Relate
• pilote avec ancien et nouveau états
• package de rollback disponible

Cycle de fonctionnement, étape par étape

Le cycle de Dépendances et supersedence Win32 traverse Assignment → Graph → IME → State. La procédure détaille ce que produit chaque composant et la preuve attendue avant de passer à l’étape suivante.

Dans Dépendances et supersedence Win32, 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 Dépendances et supersedence Win32

Le ciblage Required ou Available s’applique à l’application racine. Une dépendance marquée installation automatique peut être installée parce qu’elle est requise par le parent, même sans affectation autonome.

Le graphe de dépendances compte l’application parente et toutes les dépendances transitives. Une dépendance partagée entre plusieurs graphes participe au calcul global documenté et peut rendre la conception trop complexe.

Chaque dépendance suit ses propres exigences, règle de détection, commande et codes de retour. Un redémarrage pending ou une détection fausse arrête la progression du parent et doit être lu dans les journaux IME.

• packages Win32 versionnés
• règles de détection fiables
• codes retour et reboot documentés
• graphe dessiné et sans boucle

Traitement, exploitation et cas limites de Dépendances et supersedence Win32

La supersedence vise une application Win32 plus ancienne ou différente. L’option Uninstall previous version décide si Intune appelle la commande d’uninstall avant d’installer la nouvelle application; un installeur capable d’upgrade in-place peut nécessiter No.

L’application superseding doit être ciblée. Si elle atteint un poste où l’ancienne application est détectée, la relation peut s’appliquer même si l’ancienne application n’est plus ciblée. Je documente donc les intentions des deux côtés.

Dans une chaîne A vers B vers C, la version la plus récente peut supersede l’ensemble. Les chaînes profondes compliquent rollback, Company Portal et reporting; je limite volontairement la profondeur bien avant le maximum technique.

• Tester redémarrages
• Tester Company Portal et reporting
• Valider désinstallation/rollback

Lire les états propres à Dépendances et supersedence Win32

Quand dépendance et supersedence se contredisent, Intune privilégie la logique de supersedence mais peut remonter Conflict. Un exemple classique est une application A qui dépend de B alors qu’une application C supersede B.

Les mises à jour in-place guidées et la création d’une nouvelle application avec supersedence n’ont pas les mêmes capacités. Affectations, scope tags et autres métadonnées ne sont pas automatiquement recopiés dans tous les workflows.

La preuve se construit dans IntuneManagementExtension.log, AppWorkload.log, AppActionProcessor.log, AppIntentEval.log et les fichiers de reporting. Je corrèle applicationId, relation, contexte et détection avant de relancer.

• Parent non installé — IME et état dependency
• Conflict — Graphe complet
• Ancienne version reste — Commande et règle
• Nouvelle app ignorée — Affectation effective

Pilote et suivi opérationnel de Dépendances et supersedence Win32

Le pilote couvre le périmètre Intune, Win32 apps, Dependencies, Supersedence et contrôle Exporter affectations et relations. Vérifier chaque détection isolément. Construire le graphe sans conflit. Les résultats sont segmentés selon les populations réellement concernées par Dépendances et supersedence Win32.

Les cas d’échec « Parent non installé », « Conflict », « Ancienne version reste » 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 dix nœuds maximum pour supersedence, cent dépendances selon graphe documenté, ciblage explicite du superseding, ne pas effacer GRS sans preuve. 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 Exporter affectations et relations. Vérifier chaque détection isolément. Construire le graphe sans conflit. Tester install, upgrade et absent. Leur intérêt est d’identifier le producteur de chaque donnée et le moment où elle est mise à jour.

Pour Dépendances et supersedence Win32, 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 {
  $root = Join-Path $env:ProgramData 'Microsoft\IntuneManagementExtension\Logs'
  $patterns = 'dependency','supersedence','conflict','reboot'
  Get-ChildItem -LiteralPath $root -Filter '*.log' |
    Select-String -Pattern $patterns -SimpleMatch |
    Select-Object Path,LineNumber,Line
} catch { Write-Error "Lecture IME impossible : $($_.Exception.Message)"; exit 1 }

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

La chronologie de Dépendances et supersedence Win32 relie Assignment, Graph, IME, State. Les heures et identifiants communs permettent de savoir si les états appartiennent à la même tentative.

La collecte commence par Exporter affectations et relations. Vérifier chaque détection isolément. Construire le graphe sans conflit. Tester install, upgrade et absent. Ces contrôles conservent l’état qui explique le symptôme avant une nouvelle évaluation.

Les résultats sont lus avec les causes « Dépendance failed », « Relation contradictoire », « Uninstall No ou détection » en tête, sans déduire une correction d’un code ou d’un statut isolé.

• Exporter affectations et relations.
• Vérifier chaque détection isolément.
• Construire le graphe sans conflit.
• Tester install, upgrade et absent.
• Tester redémarrages
• Tester Company Portal et reporting
• Valider désinstallation/rollback

Validation du modèle et cas d’usage

Le modèle est cohérent lorsque Exporter affectations et relations, Vérifier chaque détection isolément, Construire le graphe sans conflit et Tester install, upgrade et absent. Ces contrôles relient la configuration du service au résultat réellement observé.

• Exporter affectations et relations.
• Vérifier chaque détection isolément.
• Construire le graphe sans conflit.
• Tester install, upgrade et absent.
• Tester redémarrages
• Tester Company Portal et reporting
• Valider désinstallation/rollback

Limites, modes de panne et lecture des erreurs

Les écarts connus de Dépendances et supersedence Win32 incluent Parent non installé, Conflict, Ancienne version reste, Nouvelle app ignorée. Le tableau les replace dans leur phase et précise la donnée à contrôler.

Adoption progressive, réversibilité et vigilance

L’adoption de Dépendances et supersedence Win32 commence sur le périmètre Intune, Win32 apps, Dependencies, Supersedence, Under the Hood — Assignment, Graph, IME, State, packages Win32 versionnés, règles de détection fiables, codes retour et reboot documentés. Les limites et actions de réversibilité ci-dessous cadrent la progression.