VMware Workstation 17.x est devenu un classique pour monter un lab ou faire tourner des machines virtuelles sur un poste Windows. Mais depuis les dernières versions, beaucoup tombent sur une erreur lors de l’application des paramètres de sécurité pendant l’installation : « An error occurred while applying security settings. Users/Authenticated Users is not a valid user or group ». Sur les éditions non anglaises de Windows, ou dans un environnement domaine un peu particulier, cette VMware error bloque tout le setup et laisse le poste dans un état bancal. Entre les groupes locaux traduits, les droits NTFS cassés et les messages « Accès refusé » au lancement, ce qui devait être une simple configuration de poste finit en séance de dépannage improvisée.
Au fil des incidents, un schéma se dessine : le problème ne vient pas de la virtualisation en elle-même, mais de l’application des paramètres de sécurité par le programme d’installation. Quand le groupe « Users » n’existe pas sous ce nom car le système est en français, ou quand les ACL du répertoire d’installation sont déjà abîmées, l’installateur tente de pousser ses droits et se casse les dents. Pour un admin ou un développeur qui a juste besoin de faire tourner une VM pour un chiffrage, cette résolution de problème ne devrait pas exiger de sortir l’artillerie lourde. Pourtant, le réflexe « je relance l’install en admin » ne suffit plus ; il faut comprendre ce qui coince dans les paramètres de sécurité, remettre les permissions à plat et parfois passer par les SIDs plutôt que par les noms traduits.
En bref
- Le message « An error occurred while applying security settings » apparaît surtout sur Windows non anglais ou en environnement domaine, quand l’installateur VMware ne retrouve pas les groupes locaux attendus.
- Les symptômes typiques : boucle d’erreur pendant l’installation, mention « Users is not a valid user or group », ou « Accès refusé » au lancement à cause de droits NTFS mal posés.
- La résolution de problème passe par la vérification des groupes locaux, éventuellement via les SIDs, puis par la réinitialisation des permissions sur le dossier d’installation VMware.
- Les commandes takeown et icacls permettent de reprendre la main sur le répertoire et de corriger l’application des paramètres de sécurité.
- Pour stabiliser l’environnement, il vaut mieux documenter une procédure claire de dépannage VMware et vérifier les autres éléments de sécurité Windows (GPO, antivirus, contrôle de compte utilisateur).
Comprendre l’erreur « An error occurred while applying security settings » sur VMware
Avant de sortir les lignes de commande, poser le diagnostic aide à ne pas aggraver la situation. Le message complet ressemble souvent à ceci : « An error occurred while applying security settings. Users (ou Authenticated Users) is not a valid user or group. This could be a problem with the package, or a problem connecting to a domain controller on the network ». En clair, l’installateur tente d’ajuster des droits sur des fichiers ou des clés de registre, mais le groupe qu’il vise ne correspond à rien sur le système.
Sur un Windows en français, les groupes intégrés portent des noms traduits, par exemple « Utilisateurs » à la place de « Users ». Or, certains installeurs écrits un peu vite continuent de viser les libellés anglais. Résultat : pendant l’application des paramètres de sécurité, le système ne parvient pas à résoudre le nom du groupe, considère que la cible n’existe pas, et retourne une erreur de type problème sécurité qui bloque l’installation.
Autre cas fréquent, observé chez plusieurs PME : une machine d’entreprise rattachée à un domaine, avec des GPO qui restreignent ou renommer certains groupes locaux. L’installateur VMware croit viser un groupe local classique, mais tombe en réalité sur un environnement où la résolution des identités se fait via le contrôleur de domaine. Dès que la connexion au DC décroche ou que les objets ont été déplacés, l’installation se met à boucler sur la fameuse VMware error.
On peut résumer les grandes familles de causes dans le tableau suivant.
| Cause probable | Symptôme visible | Contexte typique |
|---|---|---|
| Noms de groupes traduits (Users / Authenticated Users inexistants) | Message « not a valid user or group » pendant l’installation | Windows 10/11 en français, espagnol ou autre langue |
| ACL NTFS déjà cassées sur « C:Program Files (x86)VMware » | Installation qui va au bout mais « Accès refusé » au lancement | Poste déjà utilisé avec une ancienne version de VMware ou des bidouilles de droits |
| Poste rattaché à un domaine, DC inaccessible | Boucle d’erreur, mention du contrôleur de domaine dans le message | Ordinateur portable d’entreprise, VPN ou réseau instable |
| Antivirus ou solution EDR qui intercepte la modification des permissions | Installation interrompue, logs sécurité bruyants | Parc fortement sécurisé, surveillance renforcée des changements d’ACL |
| Installateur lancé sans droits administrateur | Échec systématique dès les premières étapes, parfois silencieux | Compte utilisateur standard, UAC configuré de manière stricte |
Dans la pratique, beaucoup pensent d’abord à un problème de clé de licence ou de fichier de setup corrompu. Sauf que la clé VMware n’entre en jeu qu’après, et que l’erreur survient au moment où l’installeur tente de configurer les ACL sur les fichiers et services de la virtualisation. Tant que Windows ne reconnaît pas les groupes ciblés, aucune clé ne changera l’issue.
Pour les équipes qui montent régulièrement des environnements de test, la bonne habitude consiste à repérer rapidement les mots-clés « not a valid user or group » et « security settings ». Dès qu’ils apparaissent, le problème vient rarement du binaire VMware lui-même, mais presque toujours de la couche sécurité Windows. Comprendre cette logique évite de réinstaller cinq fois le même exécutable pour rien.
- Repérer le texte exact de l’erreur, en particulier la partie sur le groupe non valide.
- Identifier la langue de Windows et vérifier le nom réel des groupes locaux.
- Contrôler si la machine est liée à un domaine et si le DC est joignable.
- Vérifier d’éventuels outils de sécurité qui surveillent les modifications d’ACL.
Une fois ce terrain balisé, on peut attaquer la remise à plat des droits sans marcher à l’aveugle.
Procédure pas à pas pour corriger les permissions VMware sous Windows
Quand l’installation a déjà échoué une ou deux fois et que le dossier « C:Program Files (x86)VMwareVMware Workstation » existe, la méthode la plus directe consiste à reprendre possession du répertoire puis à réappliquer des droits sains. Cette approche règle de nombreux cas de problème sécurité et supprime les « Accès refusé » au lancement.
La séquence suivante fonctionne sur Windows 10 et 11, éditions Home et Pro, qu’il s’agisse d’un poste perso en homelab ou d’une machine d’entreprise. Elle se base sur les commandes takeown et icacls, qui manipulent le propriétaire et les ACL des fichiers.
Ouvrir l’invite de commandes en administrateur
Pour ajuster les paramètres de sécurité sur les dossiers système, un simple clic sur l’icône VMware ne suffit pas. Il faut démarrer une console avec des privilèges élevés.
- Rechercher « cmd » dans le menu Démarrer.
- Cliquer droit sur « Invite de commandes ».
- Choisir « Exécuter en tant qu’administrateur » et valider l’UAC.
Cette étape peut paraître évidente, mais elle reste la principale raison des tentatives ratées chez les profils moins à l’aise avec Windows. Une invite sans droits admin ne peut pas réparer les ACL dans « Program Files ».
Prendre possession du dossier VMware Workstation
Une fois la console ouverte, l’objectif est de redevenir propriétaire du dossier où VMware s’installe. La commande pivot ressemble à ceci (à adapter à votre chemin réel) :
takeown /F « C:Program Files (x86)VMwareVMware Workstation » /R /D Y
Quelques remarques concrètes pour éviter les erreurs :
- Le paramètre /R applique l’opération de manière récursive sur tout le contenu, sous-dossiers compris.
- Le /D Y force la réponse « Yes » aux éventuelles questions de confirmation en cas de fichiers protégés.
- Si VMware est installé dans « C:Program FilesVMware » sans le « (x86) », il faut évidemment ajuster le chemin.
Cette commande réaffecte le propriétaire à l’utilisateur courant (l’admin qui exécute la console). Elle règle bon nombre de situations où des ACL tordues bloquaient même le panneau de sécurité dans l’explorateur.
Réattribuer les permissions avec icacls
Une fois le dossier « repris », il faut donner de vrais droits d’accès à l’utilisateur qui va lancer VMware. La commande typique ressemble à cela :
icacls « C:Program Files (x86)VMwareVMware Workstation » /grant tonuser:(F) /T
Les points à adapter et à comprendre :
- Remplacer tonuser par le nom du compte qui utilisera VMware (par exemple « martin » ou « martin.durand »).
- Le flag (F) accorde le contrôle total sur les fichiers, ce qui supprime les messages « Accès refusé » à l’exécution.
- L’option /T applique les droits à tous les éléments du dossier, jusqu’aux binaires et DLL.
On peut ensuite contrôler le résultat avec :
icacls « C:Program Files (x86)VMwareVMware Workstation »
Cette commande liste les ACL effectives et confirme si le compte choisi dispose bien des droits attendus. Dans les environnements plus sensibles, où l’on souhaite limiter les permissions, on peut affiner en ciblant uniquement les groupes « Utilisateurs » ou « Utilisateurs authentifiés », mais pour une phase de test, ce réglage large a le mérite d’être clair.
| Commande | Rôle | Quand l’utiliser |
|---|---|---|
| takeown /F « chemin » /R /D Y | Changer le propriétaire du dossier et de son contenu | Quand les fichiers VMware refusent toute modification ou suppression |
| icacls « chemin » /grant user:(F) /T | Accorder le contrôle total à un utilisateur | Pour lever les messages « Accès refusé » au lancement de VMware |
| icacls « chemin » | Afficher les ACL effectives | Vérifier rapidement quels comptes ont accès au dossier VMware |
Dans certains cas, malgré des commandes propres, l’install ou le lancement reste instable. Une fermeture de session ou un redémarrage aide alors Windows à recharger les jetons de sécurité. Ce n’est pas magique, simplement une manière de forcer la prise en compte des changements sur le profil utilisateur.
Pour ceux qui cherchent des méthodes de surveillance plus fines des fichiers, des outils comme tailf ou inotify côté Linux ont leurs équivalents sous Windows. Sur des environnements mixtes, l’article disponible sur la surveillance de fichiers avec tailf sous Linux donne une bonne base pour comprendre comment tracer ce qui se passe autour d’un binaire sensible.
Groupes locaux, SIDs et éditions non anglaises : le vrai nœud du problème
Jusqu’ici, la réparation des droits s’attaque au symptôme. Pour éviter de revivre la même scène à chaque mise à jour, il faut regarder de plus près la manière dont Windows gère les identités et ce que fait l’installateur VMware pendant la configuration.
Sur toutes les éditions récentes de Windows, chaque groupe intégré possède un SID fixe, qui ne dépend pas de la langue. Par exemple, le groupe « Utilisateurs » en français correspond au même SID que « Users » sur une version anglaise. Là où les ennuis commencent, c’est quand un installeur s’appuie sur les libellés textuels plutôt que sur ces identifiants stables.
L’exemple typique reste la différence entre :
- Windows en anglais, où le groupe s’appelle « Users ».
- Windows en français, où le même groupe s’appelle « Utilisateurs ».
Un installeur qui écrit dans son script MSI « ajouter les droits pour Users » va réussir sur le premier cas, mais échouer sur le second avec la fameuse erreur « Users is not a valid user or group ». Certains contournent le souci en créant un groupe local « Users » vide, mais ce bricolage brouille les pistes et peut même compliquer la sécurité à long terme.
Pour vérifier proprement les groupes présents sur une machine, l’outil « lusrmgr.msc » reste pratique, mais dans un contexte automatisé la ligne de commande fait mieux le travail. On peut, par exemple, lister les groupes avec :
net localgroup
Ou utiliser PowerShell pour récupérer les SIDs associés. Cette approche est plus robuste pour écrire des scripts de dépannage et d’audit qui fonctionnent sur des parcs hétérogènes.
| Élément | Version anglaise | Version française | Impact sur VMware |
|---|---|---|---|
| Nom du groupe local utilisateurs | Users | Utilisateurs | Installeurs qui ciblent « Users » échouent sur les éditions FR |
| Groupe « Authenticated Users » | Authenticated Users | Utilisateurs authentifiés | Mêmes risques si l’installateur ne gère pas la traduction |
| Identifiant SID | Identique | Identique | Cible sûre pour l’application des ACL dans les scripts avancés |
Sur plusieurs retours d’expérience, notamment avec VMware Workstation 17.6, le contournement le plus propre consiste à créer ou ajuster les groupes via leur SID dans un script exécuté avant l’installation. Certains administrateurs poussent ce script par GPO sur les machines de développement qui doivent recevoir VMware, ce qui standardise la base de sécurité.
À l’inverse, bricoler l’Active Directory pour faire coller les noms avec ce que l’installateur attend ne tient pas la route. Sur un domaine existant, toucher aux groupes intégrés ou les renommer pour un simple problème de virtualisation locale crée plus de risques qu’il n’en résout. Entre les ACL historiques, les scripts de logon et les vieilles applications métier, le coût de ce genre de « correction » dépasse largement le gain.
- Préférer des scripts qui s’appuient sur les SIDs aux scripts qui utilisent les libellés textuels.
- Éviter de créer des doublons de groupes comme « Users » sur une machine française.
- Documenter clairement les groupes que l’installateur VMware est censé utiliser.
- Tester l’installation sur un poste pilote non critique avant de généraliser.
Cette vision plus structurée des groupes et SIDs évite de traiter chaque VMware error de la même façon, et prépare mieux les futures évolutions de l’outil de virtualisation sur le parc.
Cas concrets de dépannage VMware Workstation dans un environnement hybride
Pour donner un peu de relief à ces notions, autant les replacer dans des scénarios pratiques. Prenons une petite société de conseil, dont l’équipe technique a besoin de VMware Workstation pour tester des setups clients : Active Directory, bases de données, front web. Les postes sont sous Windows 11 Pro en français, rattachés à un domaine, et gérés avec un antivirus d’entreprise assez intrusif.
Le jour où VMware 17.6 est déployé, plusieurs consultants remontent la même erreur lors de l’application des paramètres de sécurité. L’installateur tourne, affiche « Authenticated Users is not a valid user or group », propose de réessayer, puis reboucle. Pendant ce temps, l’antivirus logue des tentatives de modification d’ACL sur des répertoires sensibles.
La résolution, une fois la cause comprise, s’appuie sur trois axes :
- Vérifier les groupes locaux réels, repérer le nom « Utilisateurs authentifiés » et confirmer son SID.
- Préparer un script PowerShell qui, avant le setup VMware, s’assure que les ACL nécessaires existent bien, ciblant les SIDs corrects.
- Mettre en place une exception temporaire sur l’antivirus pour le programme d’installation VMware et pour le dossier d’installation.
Sur un autre terrain, celui du homelab, le contexte est différent mais les ennuis se ressemblent. Un particulier passionné de virtualisation teste VMware Workstation sur une machine Windows 11 Home, passée par plusieurs upgrades depuis Windows 7, avec un historique de logiciels de sécurité et de nettoyeurs divers. Quand il tente d’installer VMware 17.x, le setup échoue en cours de route, mais laisse un dossier « VMware Workstation » incomplet. Au lancement, Windows balance « Accès refusé » malgré les droits admin.
Dans ce cas, la procédure par takeown et icacls sert avant tout à assainir l’existant pour permettre une réinstallation propre. Une fois le dossier repris, les droits réappliqués et le système redémarré, l’installation se déroule enfin sans accroc. C’est souvent à ce moment que l’utilisateur découvre l’intérêt de garder une trace de ces opérations, par exemple dans un petit fichier texte versionné avec les autres scripts d’admin de son homelab.
| Scénario | Symptôme principal | Action corrective clé |
|---|---|---|
| Poste d’entreprise en domaine | Boucle sur « Authenticated Users is not a valid user or group » | Aligner les ACL via SIDs et desserrer temporairement l’antivirus |
| Homelab Windows 11 Home | Installation incomplète, « Accès refusé » au lancement | Reprendre le dossier avec takeown puis icacls, puis réinstaller |
| Machine bilingue ou changée de langue | Groupes en anglais et français mélangés, ACL incohérentes | Rationaliser les groupes locaux, supprimer les doublons bricolés |
Dans ces contextes variés, un point commun ressort : la virtualisation n’est pas l’ennemie. C’est la couche sécurité mal comprise qui transforme une simple installation en casse-tête. Un bon réflexe consiste à documenter les opérations de dépannage réalisées, quitte à en faire un mini guide interne, au même titre qu’une procédure de sauvegarde.
Pour les équipes qui manipulent souvent des systèmes Linux en parallèle, l’habitude de suivre les logs et les fichiers en temps réel (comme avec les commandes inspirées de tailf sur Linux) peut aussi se décliner sur Windows pour observer ce que fait VMware pendant l’installation. Ce regard transversal rend la résolution des incidents plus rapide et plus structurée.
Bonnes pratiques de sécurité et maintenance autour de VMware Workstation
Résoudre l’erreur « An error occurred while applying security settings » est une chose. Garder un environnement VMware propre et sécurisé en est une autre. Une fois les ACL remises d’équerre et la résolution de problème bouclée, il reste à consolider la base pour éviter les récidives ou d’autres surprises liées aux paramètres de sécurité.
Première position claire : installer VMware sur un compte administratif qui n’est pas celui utilisé au quotidien pour naviguer sur le web ou lire ses mails. Même sur un poste individuel, séparer les profils limite les dégâts en cas de malware qui tenterait d’exploiter les droits étendus du binaire de virtualisation.
Deuxième point, trop souvent négligé : surveiller le répertoire d’installation dans le temps. Un outil de supervision basique, ou même un script PowerShell périodique, peut alerter en cas de modification inattendue des ACL ou de remplacement de binaire. Cette logique rejoint des techniques vues en environnement Linux, où l’on suit en continu l’activité des fichiers comme décrit dans les contenus dédiés à la surveillance de logs avec tailf, par exemple sur ce guide orienté Linux.
- Limiter le nombre de comptes ayant des droits de modification sur « Program Files (x86)VMware ».
- Mettre à jour VMware Workstation de manière contrôlée, en testant d’abord sur une machine de préproduction.
- Documenter les exceptions faites dans l’antivirus ou les EDR pour le binaire VMware.
- Conserver les scripts de réparation des ACL dans un dépôt versionné.
Côté sécurité réseau, il ne faut pas oublier que chaque machine virtuelle ajoute une surface d’attaque potentielle. Même si le cœur du sujet reste ici l’installation et l’application des paramètres sur l’hôte, la configuration des VMs elles-mêmes doit respecter les bonnes pratiques habituelles : mises à jour, comptes limités, segmentation réseau.
| Domaine | Bonne pratique | Bénéfice pour la sécurité VMware |
|---|---|---|
| Comptes utilisateurs | Utiliser un compte admin distinct pour l’installation et la maintenance | Réduit le risque d’exploitation des droits élevés |
| Permissions NTFS | Limiter les droits d’écriture aux seuls comptes techniques nécessaires | Évite la corruption accidentelle ou malveillante des binaires VMware |
| Antivirus / EDR | Déclarer des exceptions ciblées et documentées pour VMware | Réduit les faux positifs tout en gardant un niveau de contrôle élevé |
| Supervision | Surveiller les changements d’ACL sur le dossier d’installation | Permet de détecter tôt des comportements anormaux |
Enfin, sur le plan opérationnel, garder une trace claire des versions de VMware déployées, des machines concernées et des scripts de correction utilisés simplifie nettement la gestion. Quand la prochaine mise à jour majeure arrivera, il suffira de rejouer une procédure connue, plutôt que d’improviser à nouveau sous pression.
Pour ceux qui travaillent déjà avec des outils d’automatisation, rien n’empêche d’intégrer ces vérifications de configuration à un pipeline existant, au même titre qu’un check de conformité Windows. La virtualisation s’intègre alors proprement à l’écosystème global, au lieu de rester ce module un peu à part que l’on installe à la main sur chaque machine.
Pourquoi VMware affiche « Users is not a valid user or group » pendant l’installation ?
Le programme d’installation cible des groupes locaux sous leur nom anglais, comme Users ou Authenticated Users. Sur un Windows non anglais, ces groupes portent un autre libellé (par exemple Utilisateurs), ce qui provoque l’erreur de type « not a valid user or group » lors de l’application des paramètres de sécurité.
Comment corriger un message « Accès refusé » au lancement de VMware Workstation ?
Ce symptôme vient en général de permissions NTFS mal configurées sur le dossier d’installation VMware. Il faut reprendre la main avec takeown pour devenir propriétaire du répertoire, puis accorder les droits nécessaires avec icacls à l’utilisateur qui lance VMware, en appliquant les changements de manière récursive.
Faut-il modifier les groupes dans Active Directory pour résoudre cette VMware error ?
Non, il est déconseillé de toucher aux groupes intégrés ou à leur nom dans l’Active Directory juste pour corriger une installation VMware. La bonne approche consiste à travailler sur les groupes locaux et leurs SIDs, ou à ajuster les permissions directement sur le poste concerné, sans impacter tout le domaine.
Un antivirus peut-il provoquer l’erreur lors de l’application des paramètres de sécurité ?
Oui, certaines solutions antivirus ou EDR bloquent ou surveillent de près les modifications d’ACL sur les dossiers système. Elles peuvent interrompre l’installation VMware et déclencher des erreurs de sécurité. Prévoir des exceptions temporaires pour l’installateur et le dossier d’installation règle souvent ce type de blocage.
Les commandes takeown et icacls sont-elles risquées à utiliser ?
Ces commandes sont puissantes, car elles modifient le propriétaire et les permissions des fichiers. Utilisées de manière ciblée sur le seul dossier VMware, elles restent contrôlées. Il faut toutefois éviter de les lancer à la racine du disque ou sur des répertoires système critiques, sous peine de casser d’autres applications ou des mécanismes de sécurité.
