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

Résumé

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.

Contexte, objectif et périmètre

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.

Je traite « Portail d’entreprise : déploiement et diagnostic » comme une chaîne de preuves et non comme une succession de boutons à cliquer. Une action n’est considérée comme réussie que lorsque le résultat est visible au niveau attendu : configuration du service, état reçu par le poste, traitement local, puis remontée cohérente dans les outils d’administration. Cette séparation évite de confondre une affectation valide avec une exécution terminée.

Je conserve systématiquement les heures en UTC et en heure locale, l’identité de l’appareil, le contexte utilisateur ou système, la version de Windows et la version des composants concernés. Sans ces repères, deux événements semblables peuvent appartenir à des cycles différents. Les exemples de journaux sont anonymisés et les identifiants techniques doivent l’être avant tout partage.

Ma méthode part du symptôme observable, formule plusieurs hypothèses concurrentes, puis cherche la preuve capable d’en éliminer une. Je ne commence pas par vider un cache, supprimer une clé ou réinstaller un agent : ces actions modifient précisément l’état qui permettrait de comprendre l’incident. La collecte initiale reste donc en lecture seule.

Une correction n’est proposée qu’après localisation de la phase en échec. Je distingue toujours le contournement temporaire, la correction causale et la correction structurelle. Le retour arrière est préparé avant la modification, puis le résultat est contrôlé sur un pilote représentatif avant toute généralisation.

• Objectif : déployer par la méthode privilégiée
• Objectif : différencier provisioning et registration
• Objectif : diagnostiquer lancement, identité et téléchargement
• Périmètre : Portail Windows sur postes Intune
• Périmètre : Microsoft Store (new) et hors ligne sous conditions
• Périmètre : Autopilot et utilisateurs existants

Architecture et fonctionnement général

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.

Prérequis techniques et préparation

Avant toute mise en œuvre, je fige le périmètre de test et je capture l’état initial. Cette photographie comprend les versions, les affectations, les autorités de gestion, les dépendances et les exceptions connues. Elle sert autant à interpréter le résultat qu’à construire le retour arrière.

Je vérifie les prérequis sur un appareil réellement représentatif. Une console qui autorise la création d’un profil ne prouve ni l’éligibilité du poste, ni la disponibilité effective de la fonctionnalité dans le tenant. Les prérequis réseau, licence, identité et système doivent tous être confirmés.

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

Procédure de mise en œuvre

La procédure suivante est volontairement découpée en points de contrôle. Je ne poursuis pas lorsqu’un résultat attendu manque : continuer masquerait la première divergence et produirait des symptômes secondaires plus difficiles à interpréter.

Les noms de groupes, profils, applications et fichiers sont des exemples. Je les remplace par les conventions de l’organisation, je documente la population ciblée et je conserve une preuve avant/après pour chaque changement.

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.

Scripts, commandes et exemples de lecture

Les commandes présentées servent à observer ou illustrer le fonctionnement. Les scripts de diagnostic restent de niveau 1, avec arrêt sur erreur et gestion globale de l’exception. Ils ne modifient pas le poste. Une remédiation serait au minimum de niveau 2, avec mode de simulation, journalisation adaptée au test et comportement de rollback explicitement validé.

Je lis toujours la sortie avec le contexte d’exécution. Une commande lancée dans la session de l’utilisateur ne voit pas nécessairement les mêmes certificats, chemins, variables, applications ou ruches de registre qu’un processus exécuté par l’Intune Management Extension sous SYSTEM.

# Exemple pédagogique non testé — niveau 1
$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 }

Validation et critères de contrôle

Je valide d’abord le résultat technique sur le poste, puis sa remontée dans le service. Le portail peut conserver un état ancien pendant un certain temps ; inversement, un état vert dans la console ne dispense pas de contrôler l’artefact local réellement attendu.

Le critère GO exige un résultat reproductible, une absence de régression sur les fonctions voisines, une documentation à jour et un retour arrière démontré. Le critère NO-GO s’applique dès qu’une dépendance n’est pas maîtrisée, qu’une partie du parc réagit différemment ou que l’état final ne peut pas être prouvé.

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

Journaux, diagnostic et constitution des preuves

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

Dépannage : symptômes, preuves et corrections

Je pars de la colonne Symptôme, mais je ne choisis jamais une correction sur ce seul indice. La colonne Preuve indique l’élément qui doit confirmer la cause. Si cette preuve manque, l’hypothèse reste ouverte et l’action proposée ne doit pas être appliquée comme une recette automatique.

Après correction, je reproduis le scénario initial et je compare les mêmes points de mesure. Un changement de symptôme n’est pas toujours une résolution : il peut simplement indiquer que le traitement progresse jusqu’à une nouvelle phase. La chronologie complète reste donc la référence.

Retour arrière et points de vigilance

Le retour arrière ne consiste pas seulement à retirer une affectation. Je restaure l’autorité précédente, la configuration ou la version attendue, puis je vérifie que le poste a effectivement reçu et appliqué ce nouvel état. Les caches et délais de remontée sont documentés au lieu d’être interprétés comme une absence de rollback.

Je conserve les preuves du pilote, le motif de la décision et les écarts rencontrés. Si le service cloud ou une interface évolue, je réévalue les étapes avant une nouvelle vague. Aucun succès obtenu uniquement sur le poste de développement ne constitue une validation de production.

• Rollback : retirer affectation pilote
• Rollback : restaurer méthode/version validée
• Rollback : réenregistrer seulement le package officiel
• Vigilance : ne pas encapsuler automatiquement le Store en Win32
• Vigilance : ne pas confondre provisioning et registration
• Vigilance : ne pas reset avant collecte