Portail d’entreprise Intune : déploiement, enregistrement et troubleshooting

Résumé opérationnel

Je distingue trois résultats: package provisionné pour la machine, application enregistrée dans le profil et communication fonctionnelle avec Intune. Tester uniquement Get-AppxPackage sous l’administrateur ne couvre pas ces dimensions.

Pour Autopilot, la méthode Microsoft Store (new), affectée selon le scénario documenté, est privilégiée. Une encapsulation Win32 hors ligne augmente les composants à maintenir et reste une exception.

Un téléchargement bloqué peut refléter un problème IME ou application cible plutôt qu’un défaut du Portail. Je reconstruis la chronologie avant de réinitialiser l’application.

Je distingue trois résultats: package provisionné pour la machine, application enregistrée dans le profil et communication fonctionnelle avec Intune. Tester uniquement Get-AppxPackage sous l’administrateur ne couvre pas ces dimensions.

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

Le Portail est une application Windows, une interface d’identité et une façade sur les applications disponibles. Son installation relève de Store/AppX, son enregistrement est propre au profil et son contenu dépend d’Intune.

Pendant Autopilot, acquisition du package et création du profil utilisateur ne se produisent pas au même moment. La procédure doit préciser ce qui est attendu avant et après la première connexion.

• Portail Windows sur postes Intune
• Microsoft Store (new) et hors ligne sous conditions
• Autopilot et utilisateurs existants

Questions à résoudre et méthode de diagnostic

Pour Portail d’entreprise: déploiement et diagnostic, l’enquête suit le parcours Store/Intune → Provisioning → Registration → Portal. 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 Get-AppxProvisionedPackage, Get-AppxPackage -User et AppXDeploymentServer/Operational. 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 « Absent pour tous, Présent pour admin et Catalogue vide » 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.

• déployer par la méthode privilégiée
• différencier provisioning et registration
• diagnostiquer lancement, identité et téléchargement

Cartographie du flux à diagnostiquer

Get-AppxProvisionedPackage décrit les packages de l’image; Get-AppxPackage -User décrit ceux enregistrés pour un profil. Les listes peuvent diverger légitimement.

L’application utilise ensuite l’identité et les services Intune. Un lancement réussi ne prouve pas que le catalogue est calculé ni que l’IME peut installer une application Win32.

Store (new) réduit la maintenance. Le package hors ligne répond parfois à une contrainte, mais impose dépendances, versions, signatures et mises à jour.

État initial et prérequis de collecte

L’état initial de Portail d’entreprise: déploiement et diagnostic doit couvrir licence et utilisateur autorisé, appareil Entra joint/hybride et enrôlé, endpoints Store, WinGet et Intune accessibles, affectation pilote. Cette photographie est prise avant de relancer un traitement ou de modifier une affectation.

Les couches Store/Intune, Provisioning, Registration, Portal 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.

• licence et utilisateur autorisé
• appareil Entra joint/hybride et enrôlé
• endpoints Store, WinGet et Intune accessibles
• affectation pilote
• profil test sans installation manuelle

Collecte des preuves : journaux, registre et états

Pour le package, j’analyse Microsoft-Windows-AppXDeploymentServer/Operational et Get-AppxLog. Pour l’application demandée, j’ajoute les journaux IME avec son AppId.

Chaque événement est rapproché de l’heure et du PackageFullName exact; une erreur ancienne portant un nom proche ne prouve pas la cause actuelle.

• Get-AppxProvisionedPackage
• Get-AppxPackage -User
• AppXDeploymentServer/Operational
• Get-AppxLog
• journaux IME
• état d’identité Intune

Investigation pas à pas

L’investigation suit l’ordre Store/Intune → Provisioning → Registration → Portal. La première divergence confirmée détermine la branche suivante et évite de multiplier les symptômes secondaires.

Pour Portail d’entreprise: déploiement et diagnostic, les contrôles « Ajouter l’application Store », « Affecter au pilote », « Contrôler les deux états » précisent à la fois l’emplacement, le résultat attendu et la vérification à effectuer.

Provisionné ne veut pas dire enregistré

Un package provisionné est ajouté à l’image afin d’être enregistré pour les profils; il n’est pas forcément déjà enregistré pour chaque utilisateur existant.

Je teste un nouvel utilisateur et un profil existant lorsque les deux populations sont concernées. Le comportement peut différer selon l’historique du profil.

Je ne généralise pas Add-AppxPackage ou Add-AppxProvisionedPackage sans maîtriser dépendances, licence et source. Ces commandes modifient le poste et exigent un rollback.

Quand Downloading ne finit jamais

Le Portail transmet une intention, mais l’IME traite l’application Win32. Je relève l’AppId cible et recherche son cycle dans AppWorkload.log.

Je vérifie identité, synchronisation, notification et réseau. Dépendance ou détection incohérente peut laisser l’interface attendre.

La réinitialisation du Portail arrive tard, seulement lorsque package ou profil est réellement corrompu. Elle efface sinon un état utile.

Commandes et scripts de diagnostic en lecture seule

Les exemples ci-dessous contrôlent Get-AppxProvisionedPackage, Get-AppxPackage -User, AppXDeploymentServer/Operational, Get-AppxLog. Leur sortie doit être rapprochée de l’heure de l’incident et du contexte d’exécution concerné.

Pour Portail d’entreprise: déploiement et diagnostic, 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 {
  $userPackage = Get-AppxPackage -Name '*CompanyPortal*' -ErrorAction SilentlyContinue
  $provisioned = Get-AppxProvisionedPackage -Online | Where-Object DisplayName -Match 'CompanyPortal'
  [pscustomobject]@{ UserRegistered=[bool]$userPackage; UserVersion=$userPackage.Version; Provisioned=[bool]$provisioned; ProvisionedVersion=$provisioned.Version }
}
catch { Write-Error "Inventaire impossible : $($_.Exception.Message)"; exit 1 }

$ErrorActionPreference = 'Stop'
try {
  Get-AppxProvisionedPackage -Online | Where-Object DisplayName -Match 'CompanyPortal' |
    Select-Object DisplayName,PackageName
  Get-AppxPackage -AllUsers | Where-Object Name -Match 'CompanyPortal' |
    Select-Object Name,PackageFullName,PackageUserInformation
  Get-WinEvent -LogName 'Microsoft-Windows-AppXDeploymentServer/Operational' -MaxEvents 80 |
    Select-Object TimeCreated,Id,Message
}
catch {
  Write-Error "Collecte impossible : $($_.Exception.Message)"
  exit 1
}

[07:55:10.015] Store       Package=CompanyPortal Acquisition=Success
[07:55:12.710] Provision   Package=CompanyPortal State=Staged
[08:03:41.119] UserProfile Sid=<SID> FirstSignIn=True
[08:03:44.002] AppX        Package=CompanyPortal Registration=Success
[08:04:02.998] Portal      Identity=Connected Catalog=Loaded

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

La matrice couvre notamment Absent pour tous, Présent pour admin, Catalogue vide, Downloading. 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 package officiel, provisioning visible et registration visible 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 Portail d’entreprise: déploiement et diagnostic 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.

• package officiel
• provisioning visible
• registration visible
• authentification réussie
• catalogue chargé
• installation pilote remontée

Retour arrière, escalade et points de vigilance

Le retour arrière de Portail d’entreprise: déploiement et diagnostic 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 à Get-AppxProvisionedPackage, Get-AppxPackage -User, AppXDeploymentServer/Operational, Get-AppxLog ainsi que les causes déjà écartées.