Le nouveau client Microsoft Teams ne se lance pas à la connexion dans vos hôtes RDS/AVD avec FSLogix ? Cette fiche de dépannage pas‑à‑pas détaille les causes probables (FSLogix 2210 HF4, EDR/antivirus, minifilters, ACLs WindowsApps, INetCache) et fournit des correctifs concrets et vérifiables.
Vue d’ensemble et symptômes observables
Dans des environnements Windows Server 2019/2022 publiés en RDS ou AVD et utilisant FSLogix, le nouveau client Microsoft Teams installé en mode machine‑wide via le bootstrapper peut ne pas se lancer automatiquement à l’ouverture de session. Les manifestations les plus fréquentes :
- Boîte de dialogue
msteams_autostarter.exeaffichant “The parameter is incorrect” (parfois “Invalid function”). - L’ancienne application Classic Teams fonctionne, mais l’option Try the new Teams échoue ou boucle.
- Le démarrage réussit sur des hôtes sans EDR/antivirus, ou bien un login sur deux seulement aboutit.
La cause est rarement unique : on observe souvent un empilement de facteurs (FSLogix, pilotes de filtre tiers, politique de redirection, interférences EDR) qui perturbe l’enregistrement MSIX et le bootstrap du nouveau client.
Causes probables et logique racine
Conflits FSLogix corrigés partiellement
Plusieurs défaillances de lancement du nouveau Teams ont été traitées par FSLogix 2210 HotFix 4 (HF4). Dans la pratique, cette version réduit sensiblement les occurrences de “The parameter is incorrect/Invalid function” lors de l’enregistrement de l’application et de la création des chemins dans le conteneur de profil.
Interférences d’antivirus/EDR
Des produits de sécurité (p. ex. SentinelOne, Cortex, Trend Micro Apex One, Bitdefender, Symantec) peuvent hooker des API, retarder la création de fichiers/handles ou bloquer des chargements dynamiques pendant la toute première phase d’enregistrement MSIX. Résultat : l’autostarter échoue de manière aléatoire alors que le processus se déroule normalement quand la protection est désactivée.
Autres pilotes de filtre (minifilters) en conflit
Des pilotes de filtre non indispensables, particulièrement ceux ajoutés par des systèmes de profils tiers, peuvent perturber FSLogix. Des cas sont signalés lorsque des composants Citrix UPM (pilotes UPMAction et upmjit) résident sur les hôtes VDA alors qu’UPM n’est pas utilisé.
Droits/ownership du dossier C:\Program Files\WindowsApps
Un propriétaire ou des ACLs incorrects sur le répertoire WindowsApps empêchent l’enregistrement/regeneration de l’AppX MSTeams. Un simple décalage d’owner (Administrators au lieu de TrustedInstaller) suffit à bloquer silencieusement l’opération.
Redirection des caches via FSLogix
La redirection de INetCache dans la stratégie Temp Folders peut créer une condition de course lors du premier lancement de Teams en session, générant le symptôme « un démarrage sur deux ».
Plan d’action recommandé
Appliquez la séquence suivante du plus courant au plus efficace. L’objectif est de stabiliser l’enregistrement MSIX, d’éliminer les hooks intempestifs et de rétablir des ACLs saines.
Mise à niveau FSLogix vers 2210 HF4
- Déployez FSLogix 2210 HF4 sur tous les hôtes concernés.
- Redémarrez chaque serveur après mise à jour pour garantir le rechargement du pilote.
- Vérifiez la version installée :
wmic datafile where name="C:\\Program Files\\FSLogix\\Apps\\frxsvc.exe" get Version # ou PowerShell (Get-Item 'C:\Program Files\FSLogix\Apps\frxsvc.exe').VersionInfo.FileVersion
Valider l’hypothèse sécurité/EDR
Test rapide sur un serveur pilote (fenêtre de maintenance) :
- Désactivez temporairement la protection EDR/AV.
- Ouvrez une nouvelle session utilisateur vierge (profil FSLogix neuf).
- Observez si Teams se lance correctement et s’enregistre sans erreur.
Si la corrélation est avérée, implémentez a minima les exclusions suivantes :
\Program Files\WindowsApps\MSTeams_*\ms-teams.exe
\Program Files\WindowsApps\MSTeams_*\ms-teamsupdate.exe
# si possible
\Program Files\WindowsApps\MSTeams_*\msteams_autostarter.exeÉvitez l’exclusion globale de \Program Files\FSLogix\Apps\frxsvc.exe (solution de contournement « brute force »). Pour SentinelOne, privilégiez des hook exclusions ciblées selon les recommandations de l’éditeur.
Tableau d’exclusions minimales
| Composant | Chemin/Processus à exclure | Type d’exclusion suggérée | Remarques |
|---|---|---|---|
| Nouveau Teams | ms-teams.exe, ms-teamsupdate.exe | Exécution, IO fichier, injection/hook | Exclure la famille MSTeams_* dans WindowsApps. |
| Autostarter | msteams_autostarter.exe | Injection/hook, comportement | Si l’EDR le permet, exclusion spécifique au binaire. |
| FSLogix | frxsvc.exe (éviter) | — | À utiliser seulement pour un test ciblé et temporaire. |
Identifier les pilotes de filtre conflictuels
Listez les minifilters chargés et leurs instances :
fltmc filters
fltmc instancesSi Citrix UPM n’est pas utilisé mais que l’installateur profilemgt_x64.msi a été déployé par habitude, désinstallez les composants UPM (UPMAction et upmjit). Un redémarrage s’impose pour libérer les hooks.
Rétablir l’ownership et les ACLs de WindowsApps
Attention : réalisez un snapshot/backup préalable. Le propriétaire attendu du dossier C:\Program Files\WindowsApps est NT SERVICE\TrustedInstaller.
- Vérifiez l’owner :
powershell -NoProfile -Command ^ "(Get-Acl 'C:\Program Files\WindowsApps').Owner" - Réinitialisez les ACLs (CMD admin) :
icacls "C:\Program Files\WindowsApps" /reset /t /c /q - Réaffectez le propriétaire si nécessaire :
icacls "C:\Program Files\WindowsApps" /setowner "NT SERVICE\TrustedInstaller" /t /c
Ne modifiez pas les ACLs des sous‑dossiers au‑delà du strict nécessaire : une permission inadaptée peut rompre l’enregistrement d’autres applications MSIX.
Ajuster la stratégie FSLogix Temp Folders
Plusieurs retours terrain rapportent qu’il est préférable de ne pas rediriger INetCache dans la stratégie Temp Folders. Si vous observez un échec aléatoire (un login sur deux), supprimez la redirection de ce cache et testez à nouveau.
Vérifications complémentaires utiles
- Confirmez l’installation machine‑wide de New Teams (via bootstrapper) et l’absence d’installations par‑utilisateur résiduelles.
- Vérifiez que les services AppX Deployment (AppXSVC) et FSLogix sont opérationnels.
- Examinez les journaux :
- Event Viewer → Microsoft‑Windows‑AppxDeployment‑Server/Operational
- Event Viewer → Microsoft‑Windows‑AppModel‑Runtime/Admin
- FSLogix logs →
C:\ProgramData\FSLogix\Logs\*
Diagnostic express
| Étape | Commande/Action | Résultat attendu | Interprétation |
|---|---|---|---|
| Version FSLogix | (Get-Item '...frxsvc.exe').VersionInfo.FileVersion | 2210 HF4 | Si version plus ancienne, mettre à niveau. |
| Test EDR | Désactivation temporaire + login neuf | Teams se lance | Confirme une interférence AV/EDR. |
| Minifilters | fltmc filters | Pas de pilotes UPM non utilisés | Désinstaller les composants superflus. |
| Ownership WindowsApps | (Get-Acl ...).Owner | NT SERVICE\TrustedInstaller | Si différent, rétablir l’owner/ACLs. |
| Redirection INetCache | Révision de la stratégie FSLogix | INetCache non redirigé | Réduit l’échec aléatoire 1/2. |
Procédure détaillée pas‑à‑pas
Préparation
- Choisissez un hôte de pré‑production avec snapshot.
- Préparez un compte test sans profil existant (nouvel utilisateur ou suppression du conteneur).
- Rassemblez les journaux FSLogix et les canaux Event Viewer cités plus haut.
Application des correctifs
- Mettre à niveau FSLogix : installez 2210 HF4, redémarrez l’hôte, vérifiez
frxsvc.exe. - Exclusions EDR : ajoutez les exclusions pour
ms-teams.exe,ms-teamsupdate.exeet idéalementmsteams_autostarter.exe. Si votre EDR supporte les hook exemptions, préférez-les. - Nettoyage des minifilters : repérez et désinstallez les pilotes profil inutilisés (UPM, etc.). Redémarrez.
- Réparation WindowsApps : réinitialisez ACLs, remettez TrustedInstaller propriétaire, puis relancez une session test.
- Ajustement Temp Folders : supprimez la redirection
INetCachesi présente et revalidez.
Validation
- Ouverture de session utilisateur : absence de popup d’erreur, premier lancement de Teams en <30 s, création du cache local dans le conteneur FSLogix.
- Redémarrage de la session : relance silencieuse et fiable de
msteams_autostarter.exe. - Journalisation : aucune erreur bloquante dans AppxDeployment‑Server et AppModel‑Runtime.
Scripts et commandes utiles
Inspection rapide de l’environnement
:: Versions FSLogix et présence des binaires clés
wmic datafile where name="C:\\Program Files\\FSLogix\\Apps\\frxsvc.exe" get Version
dir "C:\Program Files\WindowsApps\MSTeams_*" /ad
\:: Minifilters et instances
fltmc filters
fltmc instances
\:: Services critiques
sc query appxsvc
sc query frxsvc
\:: Vérifier le propriétaire du dossier WindowsApps (PowerShell)
powershell -NoProfile -Command "(Get-Acl 'C:\Program Files\WindowsApps').Owner" Réparation des ACLs WindowsApps
icacls "C:\Program Files\WindowsApps" /reset /t /c /q
icacls "C:\Program Files\WindowsApps" /setowner "NT SERVICE\TrustedInstaller" /t /c
Vérification de l’enregistrement MSIX de Teams
powershell -NoProfile -Command ^
"Get-AppxPackage -AllUsers *MSTeams* | Select Name, PackageFullName, Status"
Nettoyage ciblé de profils test
À n’exécuter que pour des comptes de test :
:: Déconnexion complète de la session cible
logoff <SessionID>
\:: Purge du conteneur FSLogix de test (à adapter selon votre stockage)
# DÉPLACEZ le VHD(X) au lieu de supprimer, pour pouvoir restaurer si besoinPourquoi l’erreur survient
L’autostarter du nouveau Teams s’exécute très tôt pendant l’initialisation de session, au moment où FSLogix monte le conteneur de profil et où Windows enregistre les applications MSIX per‑user. Dans les environnements RDS/AVD, cette chronologie est sensible :
- Le conteneur doit être prêt et R/W lorsque Teams tente d’écrire ses premières clés/fichiers.
- Les pilotes de filtres doivent laisser passer l’IO sans latence excessive.
- Les ACLs de
WindowsAppsdoivent être exactes pour permettre l’enregistrement de PackageFamilyName. - La redirection de caches (notamment
INetCache) ne doit pas réécrire les chemins au mauvais moment.
La moindre friction à l’une de ces étapes peut provoquer l’erreur générique “The parameter is incorrect”, qui, faute de contexte, oriente vers le mauvais composant. D’où l’importance d’un plan d’action structuré.
Check‑list opératoire prête à l’emploi
- FSLogix : 2210 HF4 installé + redémarrage effectué.
- EDR/AV : exclusions sur
ms-teams.exe,ms-teamsupdate.exe,msteams_autostarter.exesi possible. - Minifilters : aucun pilote UPM/Citrix non utilisé.
- WindowsApps : owner = NT SERVICE\TrustedInstaller, ACLs réinitialisées proprement.
- FSLogix Temp Folders :
INetCachenon redirigé. - Journalisation : canaux AppX et FSLogix propres après login.
FAQ terrain
Pourquoi Classic Teams fonctionne‑t‑il mais pas New Teams ?
Classic Teams est un binaire Win32 traditionnel avec un modèle d’installation et de démarrage différent. New Teams est packagé MSIX et s’appuie sur un enregistrement per‑user sensible à la disponibilité du profil FSLogix, aux ACLs de WindowsApps et aux hooks EDR.
Pourquoi l’erreur apparaît‑elle un login sur deux ?
Symptôme typique d’une condition de course : l’ordre d’initialisation entre FSLogix, l’EDR et l’enregistrement MSIX varie légèrement à chaque session. La suppression de la redirection INetCache et les exclusions EDR stabilisent cette fenêtre.
Puis‑je exclure frxsvc.exe de mon EDR de façon permanente ?
À éviter. Cela masque le problème sans le résoudre et élargit la surface de risque. Préférez des exclusions ciblées sur les processus de Teams et des hook exclusions au besoin.
Dois‑je réinstaller New Teams pour corriger l’erreur ?
En général non. Si l’owner/ACLs de WindowsApps sont réparés, que FSLogix est à jour et que l’EDR ne hooke plus les binaires Teams, un nouveau login suffit pour réenregistrer le package MSIX proprement.
Citrix UPM est présent mais non utilisé, est‑ce grave ?
Oui, potentiellement. Des pilotes comme UPMAction et upmjit peuvent interférer avec la pile d’IO et la virtualisation de profil. Désinstallez‑les si UPM n’est pas votre solution de profil.
Est‑ce un défaut applicatif de New Teams ?
Pas uniquement. Les correctifs FSLogix (HF4) améliorent le comportement, mais la fiabilité globale dépend du triptyque FSLogix + sécurité + santé de WindowsApps. Le traitement en chaîne est indispensable.
Pièges à éviter
- Modifier massivement les ACLs des sous‑dossiers de
WindowsApps: risque de casser d’autres MSIX. - Exclure
frxsvc.exede façon permanente : dernier recours et uniquement en test. - Laisser des pilotes de filtre orphelins (UPM, anciens antivirus) : nettoyez l’hôte.
- Lancer de multiples essais sur le même profil corrompu : repartez d’un conteneur FSLogix neuf pour valider un correctif.
Bonnes pratiques de stabilisation
- Standardisez la version FSLogix sur l’ensemble du pool et synchronisez les redémarrages.
- Centralisez les exclusions EDR dans une politique spécifique aux hôtes RDS/AVD.
- Automatisez une vérification post‑image (ownership
WindowsApps, présence de minifilters non désirés). - Surveillez les événements AppX/FSLogix clés dans une solution de collecte centralisée.
Résumé exécutif
Essayez d’abord HF4. Si l’erreur persiste, traitez la chaîne EDR/AV (exclusions, test sans EDR), éliminez les minifilters tiers (notamment Citrix UPM s’il n’est pas utilisé), remettez en conformité WindowsApps (owner = TrustedInstaller, ACLs réinitialisées) et désactivez la redirection INetCache si vous observez un échec aléatoire « 1 login/2 ». Cette approche résout la majorité des cas et sécurise l’enregistrement MSIX de New Teams au démarrage de session.
Annexe : journalisation et indices utiles
| Source | Chemin/outil | Ce qu’il faut chercher |
|---|---|---|
| AppxDeployment‑Server | Event Viewer → Microsoft‑Windows‑AppxDeployment‑Server/Operational | Échecs d’enregistrement, accès refusé, erreurs de paramètre. |
| AppModel‑Runtime | Event Viewer → Microsoft‑Windows‑AppModel‑Runtime/Admin | Événements lors du premier lancement MSIX. |
| FSLogix | C:\ProgramData\FSLogix\Logs\* | Montage du conteneur, délais, erreurs d’accès. |
| EDR/AV | Console du produit | Blocages, hooks, détections en Behavior ou Exploit pendant le login. |
Annexe : procédure de rollback
- Restaurer l’owner TrustedInstaller si des ACLs ont été expérimentées.
- Rétablir la politique Temp Folders d’origine si la modification n’a pas aidé.
- Réinstaller la version précédente de FSLogix uniquement si indispensable et validé en pré‑production.
- Revenir sur des exclusions EDR trop permissives une fois la cause éradiquée.
Matrice décisionnelle rapide
| Symptôme | Test immédiat | Correctif prioritaire | Plan B |
|---|---|---|---|
| Popup “The parameter is incorrect” | Désactiver EDR le temps d’un login | Exclusions EDR sur MSTeams_* | Réparer WindowsApps ACLs |
| Un login sur deux | Comparaison avec profil neuf | Ne pas rediriger INetCache | Mettre à jour FSLogix → HF4 |
| Erreur AppX “access denied” | Vérifier owner/ACLs | Owner = TrustedInstaller | Auditer minifilters |
Conclusion
Stabiliser le nouveau client Teams dans RDS/AVD avec FSLogix revient à sécuriser l’amont du processus : ordre d’initialisation, santé des ACLs, et neutralisation des hooks EDR au moment critique du premier enregistrement MSIX. En suivant la check‑list ci‑dessus (HF4, exclusions, nettoyage des minifilters, réparation WindowsApps, ajustement INetCache), vous obtenez une autostart fiable et reproduisible, sans recourir à des contournements risqués.