Troubleshooting Company Portal sous Windows : installation, inscription, synchronisation et applications

Résumé opérationnel

Company Portal est une application Microsoft Store par utilisateur qui présente les ressources et actions autorisées par Intune. Son installation, son authentification et l’installation des apps affichées utilisent des composants différents.

Les journaux propres au portail sont stockés dans le LocalState du package Microsoft.CompanyPortal_8wekyb3d8bbwe et suivent le motif Log_n.log. Ils complètent AppX, AAD, DeviceManagement et IME.

Je diagnostique dans l’ordre: présence et enregistrement du package, identité WAM et PRT, enrôlement MDM, synchronisation, affectation de l’application puis exécution par Store ou IME. Chaque étape possède un résultat attendu.

Company Portal est une application Microsoft Store par utilisateur qui présente les ressources et actions autorisées par Intune. Son installation, son authentification et l’installation des apps affichées utilisent des composants différents.

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

Je relève le symptôme exact: application absente, écran blanc, boucle de connexion, appareil non visible, synchronisation en erreur, catalogue vide ou installation bloquée. Ces symptômes ne sont pas interchangeables.

Get-AppxPackage pour l’utilisateur et Get-AppxProvisionedPackage pour l’image indiquent si Company Portal est installé, staged ou provisionné. Un package provisionné n’est pas nécessairement enregistré pour le compte courant.

Le déploiement recommandé sur les postes Autopilot utilise Microsoft Store app new en contexte System et une affectation Required au groupe d’appareils prévu. Le contexte et la connectivité Store sont contrôlés pendant OOBE.

• Company Portal, Intune, Microsoft Store, AppX
• Endpoint Lab — Package, Identity, MDM, Delivery
• compte utilisateur reproduisant le défaut, heure exacte et capture du message, accès LocalState et Event Viewer

Questions à résoudre et méthode de diagnostic

Pour Troubleshooting Company Portal Windows, l’enquête suit le parcours Package → Identity → MDM → Delivery. 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 Qualifier le symptôme et le contexte, Contrôler package provisionné et enregistré et Lire dsregcmd, WAM et enrôlement MDM. 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 « Portail absent, Boucle de connexion 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.

• Qualifier le symptôme et le contexte.
• Contrôler package provisionné et enregistré.
• Lire dsregcmd, WAM et enrôlement MDM.

Cartographie du flux à diagnostiquer

Je relève le symptôme exact: application absente, écran blanc, boucle de connexion, appareil non visible, synchronisation en erreur, catalogue vide ou installation bloquée. Ces symptômes ne sont pas interchangeables.

Get-AppxPackage pour l’utilisateur et Get-AppxProvisionedPackage pour l’image indiquent si Company Portal est installé, staged ou provisionné. Un package provisionné n’est pas nécessairement enregistré pour le compte courant.

Le déploiement recommandé sur les postes Autopilot utilise Microsoft Store app new en contexte System et une affectation Required au groupe d’appareils prévu. Le contexte et la connectivité Store sont contrôlés pendant OOBE.

État initial et prérequis de collecte

L’état initial de Troubleshooting Company Portal Windows doit couvrir compte utilisateur reproduisant le défaut, heure exacte et capture du message, accès LocalState et Event Viewer, inventaire des affectations. Cette photographie est prise avant de relancer un traitement ou de modifier une affectation.

Les couches Package, Identity, MDM, Delivery 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.

• compte utilisateur reproduisant le défaut
• heure exacte et capture du message
• accès LocalState et Event Viewer
• inventaire des affectations
• connectivité Store et Intune
• logs IME si Win32
• poste témoin sain

Collecte des preuves : journaux, registre et états

La chronologie de Troubleshooting Company Portal Windows relie Package, Identity, MDM, Delivery. Les heures et identifiants communs permettent de savoir si les états appartiennent à la même tentative.

La collecte commence par Qualifier le symptôme et le contexte. Contrôler package provisionné et enregistré. Lire dsregcmd, WAM et enrôlement MDM. Exporter LocalState et événements. Ces contrôles conservent l’état qui explique le symptôme avant une nouvelle évaluation.

Les résultats sont lus avec les causes « Package non déployé », « PRT ou WAM », « Aucune app Available applicable » en tête, sans déduire une correction d’un code ou d’un statut isolé.

• Qualifier le symptôme et le contexte.
• Contrôler package provisionné et enregistré.
• Lire dsregcmd, WAM et enrôlement MDM.
• Exporter LocalState et événements.
• Vérifier ciblage et primary user
• Suivre Store ou IME
• Tester la correction puis resynchroniser

Investigation pas à pas

L’investigation suit l’ordre Package → Identity → MDM → Delivery. La première divergence confirmée détermine la branche suivante et évite de multiplier les symptômes secondaires.

Pour Troubleshooting Company Portal Windows, les contrôles « Reproduire et horodater le symptôme », « Contrôler la première couche », « Corréler les preuves » précisent à la fois l’emplacement, le résultat attendu et la vérification à effectuer.

Fonctionnement détaillé de Troubleshooting Company Portal Windows

Je relève le symptôme exact: application absente, écran blanc, boucle de connexion, appareil non visible, synchronisation en erreur, catalogue vide ou installation bloquée. Ces symptômes ne sont pas interchangeables.

Get-AppxPackage pour l’utilisateur et Get-AppxProvisionedPackage pour l’image indiquent si Company Portal est installé, staged ou provisionné. Un package provisionné n’est pas nécessairement enregistré pour le compte courant.

Le déploiement recommandé sur les postes Autopilot utilise Microsoft Store app new en contexte System et une affectation Required au groupe d’appareils prévu. Le contexte et la connectivité Store sont contrôlés pendant OOBE.

• compte utilisateur reproduisant le défaut
• heure exacte et capture du message
• accès LocalState et Event Viewer
• inventaire des affectations

Traitement, exploitation et cas limites de Troubleshooting Company Portal Windows

dsregcmd status montre AzureAdJoined, DeviceId, TenantId et AzureAdPrt. Un PRT absent oriente vers identité, heure, réseau ou WAM avant toute action sur le cache du portail.

La page Access work or school et le canal DeviceManagement-Enterprise-Diagnostics-Provider montrent l’enrôlement et le check-in. Le bouton Sync ne peut pas corriger une association MDM inexistante.

Les fichiers LocalState Log_n.log tracent les opérations et erreurs de l’application. Je collecte la fenêtre autour du clic utilisateur et masque UPN, tenant, device ID, URL signée et nom d’application interne.

• Vérifier ciblage et primary user
• Suivre Store ou IME
• Tester la correction puis resynchroniser

Lire les états propres à Troubleshooting Company Portal Windows

Pour une application Win32, Company Portal exprime la demande mais l’IME télécharge, détecte et exécute. Je bascule alors vers IntuneManagementExtension.log, AppWorkload.log, AppActionProcessor.log et AgentExecutor.log selon le type.

Le catalogue vide peut être légitime si aucune application Available ne cible l’utilisateur ou l’appareil. Je vérifie groupes, filtres, exigences, primary user et temps de propagation avant de modifier le client.

La remédiation doit sauvegarder les logs, proposer une simulation, viser un utilisateur précis et fournir une méthode de retour arrière. La réinitialisation du package ou la suppression de données locales n’intervient qu’après preuve d’un état local corrompu.

• Portail absent — AppX et assignment
• Boucle de connexion — dsregcmd et AAD logs
• Catalogue vide — Assignments et filtres
• Install reste Pending — IME/Store logs

Pilote et suivi opérationnel de Troubleshooting Company Portal Windows

Le pilote couvre le périmètre Company Portal, Intune, Microsoft Store, AppX et contrôle Qualifier le symptôme et le contexte. Contrôler package provisionné et enregistré. Lire dsregcmd, WAM et enrôlement MDM. Les résultats sont segmentés selon les populations réellement concernées par Troubleshooting Company Portal Windows.

Les cas d’échec « Portail absent », « Boucle de connexion », « Catalogue vide » 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 préserver LocalState avant reset, Company Portal et IME sont deux couches, ne pas supprimer les objets Entra par défaut, tester sous le compte affecté. Une évolution de version, de licence ou de dépendance déclenche une nouvelle lecture de ces points.

Commandes et scripts de diagnostic en lecture seule

Les exemples ci-dessous contrôlent Qualifier le symptôme et le contexte. Contrôler package provisionné et enregistré. Lire dsregcmd, WAM et enrôlement MDM. Exporter LocalState et événements. Leur sortie doit être rapprochée de l’heure de l’incident et du contexte d’exécution concerné.

Pour Troubleshooting Company Portal Windows, 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 {
  Get-AppxPackage -Name Microsoft.CompanyPortal | Select-Object Name,Version,Status,InstallLocation
  Get-AppxProvisionedPackage -Online | Where-Object DisplayName -Match 'CompanyPortal' | Select-Object DisplayName,Version,PackageName
  $logRoot = Join-Path $env:LOCALAPPDATA 'Packages\Microsoft.CompanyPortal_8wekyb3d8bbwe\LocalState'
  Get-ChildItem -LiteralPath $logRoot -Filter 'Log_*.log' -ErrorAction SilentlyContinue | Select-Object Name,Length,LastWriteTime
  dsregcmd.exe /status
} catch { Write-Error "Collecte Company Portal impossible : $($_.Exception.Message)"; exit 1 }

$ErrorActionPreference = 'Stop'
try {
  Get-AppxPackage -AllUsers | Where-Object Name -Match 'CompanyPortal' |
    Select-Object Name,PackageFullName,Status,PackageUserInformation
  $logs = 'C:\ProgramData\Microsoft\IntuneManagementExtension\Logs'
  Get-ChildItem -LiteralPath $logs -Filter '*.log' -ErrorAction SilentlyContinue |
    Select-String -Pattern 'Company Portal','CompanyPortal' -Context 2,4 |
    Select-Object Path,LineNumber,Line
}
catch {
  Write-Error "Collecte impossible : $($_.Exception.Message)"
  exit 1
}

[10:20:01.020] AppX      CompanyPortal Registration=Success User=<SID>
[10:20:03.411] Identity  Account=<USER> Token=Acquired
[10:20:04.211] Service   ManagedDevice=<DEVICE> State=Active
[10:20:05.008] Catalog   AvailableApps=12 RequiredApps=4
[10:20:05.901] UI        View=Applications State=Rendered

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

La matrice couvre notamment Portail absent, Boucle de connexion, Catalogue vide, Install reste Pending. 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 Qualifier le symptôme et le contexte, Contrôler package provisionné et enregistré et Lire dsregcmd, WAM et enrôlement MDM 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 Troubleshooting Company Portal Windows 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.

• Qualifier le symptôme et le contexte.
• Contrôler package provisionné et enregistré.
• Lire dsregcmd, WAM et enrôlement MDM.
• Exporter LocalState et événements.
• Vérifier ciblage et primary user
• Suivre Store ou IME
• Tester la correction puis resynchroniser

Retour arrière, escalade et points de vigilance

Le retour arrière de Troubleshooting Company Portal Windows 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 à Qualifier le symptôme et le contexte. Contrôler package provisionné et enregistré. Lire dsregcmd, WAM et enrôlement MDM. Exporter LocalState et événements. ainsi que les causes déjà écartées.