Quand le message « An error occurred while applying security settings VMware » surgit en pleine installation ou mise à jour, la scène se répète souvent de la même façon : barre de progression bloquée, fenêtre d’alerte peu bavarde, chronomètre de maintenance qui tourne. Que ce soit sur un poste Windows avec VMware Workstation, un serveur vCenter ou un composant de virtualisation plus exotique, le fond du problème reste similaire : le système refuse les paramètres de sécurité que l’installateur essaie de poser. Entre stratégies de groupe, antivirus trop chatouilleux et comptes sans droits, la pile sécurité sabote parfois l’outil censé la renforcer. L’enjeu n’est pas théorique, surtout dans une PME ou un lab d’admin qui sert à tout : un blocage d’upgrade peut retarder un projet, immobiliser des VM critiques ou, plus simplement, te gâcher une soirée.
Plutôt que de tout casser ou de désactiver au hasard la moitié des protections Windows, il existe une approche plus calme et surtout plus reproductible. L’idée est de traiter cette erreur comme un signal technique, pas comme une fatalité. Analyser les journaux, croiser les événements, vérifier la configuration des groupes locaux ou des GPO, prendre en compte les particularités des Windows non anglais et les bizarreries de certaines versions de VMware, tout ça finit par former une méthode de dépannage fiable. Ce guide se concentre sur des solutions concrètes : comment diagnostiquer rapidement, quoi vérifier en priorité, quelles corrections appliquer selon les cas, et comment préparer le terrain pour que le prochain upgrade ne soit plus une loterie.
- Le message « An error occurred while applying security settings VMware » signale un conflit entre l’installateur et la couche sécurité Windows ou AD.
- Les causes les plus fréquentes tournent autour des GPO, de l’antivirus/EDR, des groupes locaux manquants et des droits insuffisants du compte d’installation.
- Sur Windows non anglais, VMware Workstation 17.6 a été connu pour échouer quand les groupes « Users » ou « Authenticated Users » ne portent pas leur nom anglais.
- La collecte des logs (installateur, Observateur d’événements, outils de sécurité) avant toute manipulation agressive change complètement la qualité du diagnostic.
- Une checklist de préparation (groupes, GPO dédiées, exclusions temporaires antivirus, versions supportées) réduit nettement le risque de blocage à la prochaine installation.
Erreur « An error occurred while applying security settings VMware » pendant l’installation : comprendre ce qui coince réellement
La première chose à avoir en tête, c’est que ce message n’a rien de mystérieux. Lorsque l’installateur VMware affiche « An error occurred while applying security settings », il signifie simplement que Windows a refusé tout ou partie des paramètres de sécurité qu’il essayait d’appliquer. Dans la pratique, l’outil tente de créer des groupes locaux, d’ajouter des comptes, de poser des ACL sur des dossiers, de déclarer des services ou de modifier le registre. Au moindre refus, l’ensemble de l’installation peut partir en rollback.
Sur un serveur vCenter ou un ESXi managé, la situation est encore plus sensible. L’installeur ou l’updater doit s’aligner sur une couche déjà blindée de règles : compte de service restreint, GPO héritées de multiples OU, solutions de durcissement, scripts maison exécutés au démarrage. Chaque brique ajoute une probabilité que les paramètres de sécurité VMware soient perçus comme intrusifs. C’est pour ça que deux admins avec une même version de VMware peuvent vivre des scénarios complètement différents le jour d’une mise à jour.
Un cas récurrent ressemble à ce qui s’est produit chez la société fictive NexaMeca, assez proche de beaucoup d’industries. Durant une fenêtre nocturne, l’équipe lance une migration vCenter. Tout se passe bien jusqu’à l’étape où l’installeur veut modifier les droits d’un répertoire système pour y déposer des logs. Une GPO maison impose des ACL verrouillées sur « Program Files ». Windows refuse le changement, déclenche un échec silencieux, et l’utilisateur ne voit que le message générique d’erreur lors de l’application de la sécurité. Résultat : deux nuits de test perdues avant qu’un audit ciblé ne mette au jour deux clés de registre et un dossier verrouillés par une stratégie bien cachée.
Sur des postes clients avec VMware Workstation, la même logique s’applique, mais avec des variantes. La version 17.6 a ainsi fait parler d’elle dans des environnements Windows localisés. Le message ressemblait souvent à ceci : « Authenticated Users is not a valid user or group » ou « Users is not a valid user or group ». Là, le blocage ne venait pas d’une GPO agressive, mais d’un simple détail de langue : sur un Windows français, le groupe s’appelle « Utilisateurs », pas « Users ». L’installateur, codé pour chercher les labels anglais, floppait au moment de poser les droits, d’où le message sur l’impossibilité d’appliquer les paramètres de sécurité VMware.
Comprendre ce terrain réel change complètement la stratégie de dépannage. Tant que l’on reste sur l’idée vague d’un « bug VMware », on passe à côté des vrais leviers : droits des comptes, nommage des groupes, héritage des GPO, ou encore compatibilité entre la version de VMware et le niveau de durcissement de Windows. Le message n’est pas là pour décorer, il sert de point de départ à une enquête très concrète.
Diagnostic pas à pas de l’erreur de paramètres de sécurité VMware : logs, événements et tests ciblés
Dès qu’un message lié aux paramètres de sécurité apparaît pendant une installation VMware, le réflexe le plus utile consiste à figer la situation. Avant de relancer dix fois l’installeur en espérant un miracle, il vaut mieux noter l’heure précise de l’erreur, sauvegarder les journaux d’installation et ouvrir l’Observateur d’événements Windows. Ce petit investissement de cinq minutes change tout quand il faut comprendre, une heure plus tard, pourquoi l’upgrade a refusé d’aller au bout.
Côté Windows, trois journaux méritent une attention systématique : Application, Système et Sécurité. Dans Application, on trouve souvent des entrées générées par l’installateur ou par le framework .NET si celui-ci fait partie de la chaîne. Dans Système, les messages de services qui échouent à démarrer ou les erreurs de pilotes peuvent pointer une piste. Le log Sécurité, lui, est une mine d’or : refus d’accès, échecs d’ouverture de session, événements liés à AppLocker, tout y passe. En croisant l’heure du message « An error occurred while applying security settings VMware » avec ces événements, les choses s’éclaircissent vite.
Sur les composants de virtualisation côté serveur, les logs VMware ajoutent une troisième dimension. vCenter, par exemple, trace abondamment ce qu’il fait. Repérer, dans ces fichiers, la dernière opération réalisée avant le rollback d’installation donne souvent le type de ressource qui a posé problème : création d’un service, modification d’un certificat, écriture sur un répertoire spécifique. Une fois la ressource ciblée, il devient plus simple de vérifier qui, dans la chaîne de sécurité, lui dit non.
Pour aller plus loin, certains admins s’appuient aussi sur les journaux des outils de sécurité eux-mêmes. Un antivirus moderne ou un EDR commence presque toujours par loguer les actions qu’il bloque. En ouvrant la console de gestion, ou simplement le journal local de l’agent, on tombe souvent sur une entrée à l’heure exacte de l’erreur VMware : « script bloqué », « exécutable inconnu isolé », « modification du registre refusée ». Ce n’est pas très glamour à lire, mais c’est précis.
Un moyen pratique de résumer ce diagnostic consiste à se fabriquer un petit tableau mental ou écrit des corrélations possibles. Voici un exemple exploitable aussi bien pour un poste Workstation qu’un serveur vCenter :
| Symptôme | Cause probable | Vérification rapide | Action de correction |
|---|---|---|---|
| Message « An error occurred while applying security settings VMware » dès le début de l’installation | Groupes locaux « Users » ou « Authenticated Users » introuvables ou renommés | Ouvrir « Gestion de l’ordinateur » puis « Utilisateurs et groupes locaux » et lister les groupes | Créer les groupes manquants avec les noms anglais attendus, relancer l’installation |
| Installation VMware bloquée vers 70–80 %, puis rollback | Antivirus/EDR qui bloque un binaire ou un script | Consulter les journaux de l’agent de sécurité au même horodatage | Ajouter des exclusions temporaires ciblées pour les exécutables VMware, puis re-tester |
| Erreur de sécurité lors de la création de services ou de groupes | GPO interdisant la modification des groupes locaux ou des ACL | Exécuter gpresult /r et analyser les GPO de l’OU concernée | Isoler les serveurs VMware dans une OU dédiée avec GPO adaptées |
| Échec d’upgrade vCenter sans message détaillé dans l’interface | Compte d’installation ou de service sans droits suffisants | Comparer les droits du compte avec la documentation VMware | Ajuster les permissions ou utiliser un compte dédié avec les privilèges requis |
Une fois ce diagnostic posé, on voit vite si l’on s’oriente vers un souci de langue, une règle de sécurité trop serrée ou un simple manque de droits. Cette étape évite de tirer sur la mauvaise cible, par exemple en accusant les GPO alors que le vrai coupable est un EDR un peu trop enthousiaste.
La suite logique consiste à s’attaquer aux causes spécifiques, à commencer par l’un des cas les plus agaçants pour les admins : l’installation de VMware Workstation 17.6 sur un Windows non anglais, quand les groupes système ne portent pas le nom attendu.
Cas spécifique VMware Workstation 17.6 sur Windows non anglais : groupes « Users » et « Authenticated Users » introuvables
Beaucoup d’admins ont découvert l’erreur « An error occurred while applying security settings. Users is not a valid user or group » en tentant d’installer VMware Workstation 17.6 sur un Windows en français, en allemand ou dans une autre langue. Le message complet va souvent plus loin : il suggère un problème de connexion à un contrôleur de domaine, alors que la machine n’est même pas jointée à un domaine. De quoi perdre un peu plus de temps à vérifier le réseau alors que le souci se situe ailleurs.
En réalité, le cœur du bug est assez simple. Lors de l’installation, Workstation 17.6 s’attend à trouver dans la base de comptes locaux deux groupes portant exactement les noms anglais « Users » et « Authenticated Users ». Sur un Windows en français, ces groupes existent fonctionnellement, mais portent les noms localisés « Utilisateurs » et « Utilisateurs authentifiés ». L’installateur ne les reconnaît pas, considère qu’ils n’existent pas, et renvoie donc l’erreur sur un groupe ou un utilisateur non valide.
VMware a corrigé ce comportement dans la version 17.6.1, qui gère correctement les environnements non anglais. En attendant, ou si l’on doit dépanner une machine qui reste sur la 17.6 pour une raison précise, un dépannage manuel reste possible. L’idée est de recréer, en parallèle des groupes localisés, les groupes attendus sous leur nom anglais exact, le temps que l’installateur pose ses ACL et ses paramètres de sécurité.
La procédure, à réaliser avec un compte administrateur local, ressemble à ceci :
- Ouvrir « Gestion de l’ordinateur », puis « Utilisateurs et groupes locaux », puis « Groupes ».
- Vérifier la présence de groupes nommés exactement Users, Administrators et Authenticated Users.
- Pour chaque groupe manquant, créer un nouveau groupe avec le nom anglais correspondant, en respectant les majuscules et espaces.
- Redémarrer la machine, relancer l’installation VMware Workstation, puis valider la fin de l’installation.
- Contrôler le dossier « C:Program Files (x86)VMwareVMware Workstation » en acceptant, si besoin, les demandes d’élévation de droits.
Une fois cette séquence exécutée, Workstation 17.6 se lance en général sans autre plainte sur les paramètres de sécurité VMware. Ce contournement peut paraître étrange, mais il s’appuie sur un constat simple : le système continue de fonctionner avec ses groupes localisés, et ces groupes en plus ne font qu’offrir à l’installateur les identifiants qu’il attend. Sur une machine critique, il reste prudent de documenter ces ajouts afin de ne pas se retrouver, trois ans plus tard, à se demander qui a bien pu créer un mystérieux groupe « Authenticated Users » aux côtés du groupe standard.
Pour les nouvelles installations et surtout pour des parcs entiers de postes, la solution la plus propre reste quand même la montée de version vers VMware Workstation 17.6.1 ou supérieure. La version corrigée n’a plus besoin de ces groupes anglais artificiels et s’aligne sur la configuration de comptes fournie par l’OS. En d’autres termes, le contournement manuel sert surtout de fusible pour quelques cas isolés ; la vraie correction se trouve côté binaire VMware.
Une fois ce cas particulier géré, reste un terrain plus vaste mais tout aussi fréquent : les environnements d’entreprise durcis par des GPO, où chaque changement de sécurité déclenche une réaction en chaîne. C’est là que l’on voit combien une architecture Active Directory mal maîtrisée peut saboter une mise à jour VMware parfaitement légitime.
GPO, antivirus et EDR : préparer la configuration sécurité pour éviter les erreurs VMware à l’installation
Dans un domaine AD un peu ancien, les GPO ont souvent poussé comme des branches dans tous les sens, au fil des audits et des incidents. On se retrouve avec des serveurs sur lesquels trois ou quatre stratégies différentes touchent la sécurité locale, parfois en contradiction. Lorsqu’un installeur VMware arrive avec ses propres paramètres de sécurité à appliquer, il débarque dans une forêt déjà dense. Résultat fréquent : refus de création de groupes locaux, interdiction silencieuse de modifier une clé de registre, ou écrasement immédiat des ACL tout juste posées par l’outil d’installation.
Le premier réflexe sain consiste à isoler les serveurs VMware dans une OU spécifique. Au lieu de les laisser se prendre de plein fouet toutes les GPO prévues pour les contrôleurs de domaine, les serveurs d’applicatifs maison et les vieux serveurs de fichiers, on leur attribue un périmètre clair. Dans cette OU, on clone éventuellement certaines GPO existantes, puis on retire tout ce qui empêche un logiciel de gestion d’infrastructure de fonctionner correctement : blocage absolu de la création de groupes locaux, interdiction de nouveaux services, durcissement extrême des droits sur « Program Files » ou « ProgramData ».
En parallèle, il serait dommage de négliger les outils de sécurité plus modernes comme les antivirus et EDR. Leur rôle reste essentiel, mais leur configuration doit tenir compte du comportement spécifique d’un installeur VMware : création de services, modifications en série dans le registre, écriture de fichiers binaires et scripts dans des zones sensibles. Vue depuis un EDR qui ne connaît pas encore ce logiciel, la frontière entre un déploiement VMware et un malware sophistiqué peut paraître mince.
La meilleure approche se résume en quelques étapes de préparation, à discuter avec l’équipe sécurité avant même la fenêtre de maintenance :
- Recenser les exécutables principaux, services et dossiers utilisés par la version de VMware à installer ou à mettre à jour, via les notes de version et la documentation.
- Prévoir des exclusions temporaires et ciblées dans l’antivirus ou l’EDR, limitées au temps de la correction ou de l’upgrade, en mode « monitor only » si le produit le permet.
- Tester ces exclusions sur un serveur de préproduction qui reflète vraiment la configuration de sécurité de la production, afin d’éviter les surprises au dernier moment.
- Documenter noir sur blanc les règles ajoutées, leur portée et leur durée de validité, pour s’assurer qu’elles ne se transforment pas en trou de sécurité permanent.
Certains équipes hésitent encore à mettre en place une OU dédiée ou des exclusions aussi précises, par peur de fragiliser leur posture sécurité. Pourtant, dans les faits, ce sont les désactivations brutales d’antivirus ou les suppressions temporaires massives de GPO, faites en panique pour « faire passer l’install », qui créent les vrais angles morts. Une logique de compromis documenté reste bien plus sûre que le grand interrupteur on/off.
En préparant correctement cette couche centrale (GPO, antivirus, EDR), les futures installations de VMware se déroulent dans un environnement prévisible. Le message « An error occurred while applying security settings VMware » devient rare, et surtout, lorsqu’il revient, il pointe alors souvent une autre zone de configuration oubliée, comme la compatibilité de version ou les droits d’un compte de service.
Checklist de préparation et bonnes pratiques pour fiabiliser les installations et mises à jour VMware
Une fois que les causes les plus classiques sont bien identifiées, la meilleure façon d’éviter de revoir cette erreur à chaque cycle de mise à jour consiste à formaliser une petite checklist. Rien de bureaucratique, simplement une série de vérifications rapides avant chaque installation VMware importante, pour s’assurer que le terrain n’est pas piégé à l’avance.
Une liste de contrôle simple mais efficace pourrait rassembler les points suivants, à adapter selon le contexte (homelab, PME, grand compte) :
- Version et compatibilité : vérifier que la version de VMware cible fait bien partie de la matrice de compatibilité avec l’OS et les autres composants présents (par exemple, vCenter et ESXi, ou Workstation et version de Windows).
- Compte d’installation : utiliser un compte clairement identifié, avec les droits requis localement et, si besoin, sur le domaine, au lieu de mélanger comptes personnels et comptes de service.
- Groupes locaux : sur Windows non anglais, contrôler la présence des groupes attendus par l’installeur (cas de Workstation 17.6 et des groupes « Users » / « Authenticated Users »).
- GPO et OU : s’assurer que la machine visée est bien dans une OU dont les GPO ont déjà été testées avec VMware, ou au moins revues pour ne pas bloquer la modification des ACL, des groupes et des services.
- Antivirus / EDR : préparer des exclusions ciblées et temporaires, validées avec l’équipe sécurité, plutôt que de désactiver l’agent en urgence quand l’erreur apparaît.
- Logs et sauvegardes : prévoir l’emplacement des journaux, ainsi qu’un instantané ou une sauvegarde en amont pour pouvoir revenir en arrière proprement en cas d’échec.
Cette checklist n’élimine pas toute possibilité de problème, mais elle réduit fortement la fréquence des blocages stupides. Elle place aussi tout le monde sur la même longueur d’onde : opérations, sécurité, infra, chacun sait ce qui va se passer le soir de la maintenance, et pourquoi ces étapes sont cochées.
Autre bonne habitude qui fait gagner du temps sur le long terme : garder une trace des incidents passés et de la manière dont ils ont été résolus. Si une première tentative d’upgrade a buté sur une GPO trop stricte ou un EDR en mode parano, noter la correction appliquée, les règles exactes ajoutées et l’impact constaté. La prochaine fois que quelqu’un verra remonter un « An error occurred while applying security settings VMware » sur ce même périmètre, il aura déjà une piste chaude, au lieu de repartir d’une page blanche.
Enfin, lorsqu’un environnement commence à accumuler des couches techniques (vSphere, solutions de sauvegarde, intégrations SSO, pare-feu applicatifs…), accepter de faire appel au support VMware peut être un vrai accélérateur. À partir du moment où les logs sont déjà collectés, les versions identifiées et la configuration de sécurité décrite, ouvrir un ticket ne ressemble plus à un aveu d’échec, mais à une collaboration technique pour résoudre un cas limite. Dans les situations où la plate-forme supporte des charges critiques, ce choix évite de rester bloqué des heures sur un détail obscur de paramètres sécurité que l’éditeur a déjà vu passer chez d’autres clients.
En combinant ce travail préparatoire, une lecture rigoureuse des logs et quelques réflexes sur les particularités comme les Windows non anglais, cette fameuse erreur d’application des paramètres de sécurité VMware finit par perdre son côté anxiogène. Elle devient un événement gérable, souvent prévisible, et surtout documenté, plutôt qu’un écran rouge qui ruine la confiance dans la virtualisation maison.
Que signifie exactement le message « An error occurred while applying security settings VMware » pendant une installation ?
Ce message signale que l’installateur ou l’outil de configuration VMware a tenté d’appliquer des paramètres de sécurité (création de groupes, modification d’ACL, enregistrement de services, mise à jour du registre) et que Windows a refusé tout ou partie de ces actions. Les causes les plus courantes sont des GPO trop restrictives, des groupes locaux manquants ou mal nommés, un antivirus ou un EDR qui bloque un composant, ou encore un compte d’installation sans les droits requis.
Comment corriger l’erreur « Users is not a valid user or group » avec VMware Workstation 17.6 sur Windows non anglais ?
Sur certaines installations de VMware Workstation 17.6, l’installateur attend l’existence de groupes locaux nommés exactement « Users » et « Authenticated Users », même sur des Windows localisés où ces groupes portent d’autres noms. Deux solutions existent : mettre à jour vers Workstation 17.6.1 ou supérieur, où le bug est corrigé, ou créer manuellement les groupes locaux avec ces noms anglais via Gestion de l’ordinateur, puis relancer l’installation.
Faut-il désactiver complètement l’antivirus ou l’EDR pour réussir une installation VMware bloquée par les paramètres de sécurité ?
Couper totalement l’antivirus ou l’EDR expose inutilement la machine, surtout en production. Il vaut mieux préparer, avec l’équipe sécurité, des exclusions temporaires et ciblées pour les binaires, services et dossiers VMware concernés, ou utiliser un mode de surveillance sans blocage pendant la fenêtre d’installation. Les journaux de l’agent de sécurité permettent en général d’identifier précisément ce qui a été bloqué et d’ajuster les règles au plus juste.
Comment savoir si l’erreur de paramètres de sécurité vient d’une GPO Active Directory ?
En cas de doute, il est utile d’exécuter la commande gpresult /r sur la machine concernée pour lister les GPO effectivement appliquées. En parallèle, on peut vérifier quels paramètres de sécurité locaux sont forcés (droits sur les groupes, restrictions sur les services, ACL sur certains dossiers). Si l’installation VMware échoue toujours au même stade et que les journaux Windows mentionnent des refus d’accès liés aux stratégies, il devient pertinent de placer les serveurs VMware dans une OU dédiée avec des GPO ajustées.
À partir de quand contacter le support VMware pour une erreur de paramètres de sécurité bloquante ?
Le recours au support VMware est recommandé lorsque l’erreur se produit sur un environnement critique, que le diagnostic local (logs d’installation, événements Windows, journaux des outils de sécurité, vérification des groupes et GPO) ne permet pas d’identifier clairement la cause, ou que plusieurs tentatives de correction ont déjà échoué. Fournir dès l’ouverture du ticket les versions de VMware et de l’OS, les journaux collectés et un résumé de la configuration de sécurité accélère nettement la résolution.
