Bonjour Frédéric, je m'appelle Henry et je souhaite partager mon éclairage sur vos problématiques. Toutes mes excuses de ne pas pouvoir répondre dans votre langue maternelle, mais j'ai traduit le contenu pour mieux comprendre le contexte.
Voici des recommandations de plan d'action auxquelles vous pouvez vous référer :
Étape 1 : **Redémarrer le serveur (comme prévu) **: Un simple redémarrage résout parfois des blocages temporaires.
Étape 2 : Dans un environnement virtuel, la carte d'affichage utilisée pour les sessions RDS peut entrer en conflit avec le pilote graphique de la machine virtuelle fourni par VMware Tools. Cela affecte souvent les comptes d'administrateur différemment, car ils peuvent essayer de charger des composants de shell plus complexes.
- **Le problème **: Windows Server 2022 tente d'utiliser le pilote graphique « WDDM » (Windows Display Driver Model) par défaut. Le pilote VMware SVGA 3D peut parfois être instable avec RDS, ce qui entraîne le blocage de l'interpréteur de commandes explorer.exe lors de l'ouverture de session.
- **Le correctif **: vous pouvez forcer la session RDS à utiliser l'adaptateur d'affichage de base Microsoft hérité plus stable via une modification de la stratégie de groupe.
- Sur le serveur hôte de session RDS, ouvrez l'éditeur de stratégie de groupe local (gpedit.msc).
- Accédez à : Configuration de l'ordinateur > Modèles d'administration > Composants Windows > les services Bureau à distance > l'hôte de session Bureau à distance > environnement de session à distance.
- Recherchez la stratégie nommée « Utiliser le pilote d'affichage graphique WDDM pour les connexions Bureau à distance ».
- Définissez cette stratégie sur Désactivé.
- Redémarrez le serveur ou exécutez gpupdate /force à partir d'une invite de commande administrative et demandez aux utilisateurs d'essayer de se connecter à nouveau.
- Discussion sur le forum Microsoft Learn : ce fil de discussion aborde le même problème sur Server 2022, où la désactivation du pilote WDDM via GPO est la solution confirmée.
Étape 3 : **En cas d'échec **: testez la méthode de recréation du profil utilisateur sur un compte administrateur concerné pour confirmer s'il s'agit d'un problème de corruption de profil.
Étant donné que cela affecte un *type spécifique * d'utilisateur (administrateurs) mais pas le compte administrateur intégré, il est possible qu'une clé de registre qui affecte le processus de chargement de l'interpréteur de commandes de ces utilisateurs soit corrompue.
- **Le problème **: une clé de registre spécifique qui régit le shell Windows ou le processus d'ouverture de session de l'utilisateur est endommagée. Lorsqu'un administrateur concerné se connecte, explorer.exe lit les mauvaises données et se bloque.
- **Le correctif **: La façon la plus efficace de tester cela est de renommer le profil de l'utilisateur, forçant Windows à en créer un nouveau lors de la prochaine connexion.
Comment résoudre les problèmes :
- Connectez-vous en tant qu'administrateur intégré fonctionnel.
- Accédez à C :\Users\ et renommez le dossier de profil d'un utilisateur administrateur concerné (par exemple, renommez f.stock en f.stock.old).
- **Important **: Ouvrez l'Éditeur du Registre (regedit.exe).
- Accédez à HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList.
- Parcourez les sous-clés (elles sont nommées avec des SID). Trouvez la clé correspondant à l'utilisateur concerné et supprimez-la. (Vous pouvez identifier l'utilisateur en examinant la valeur ProfileImagePath dans chaque clé).
- Demandez à l'utilisateur d'essayer de se connecter à nouveau. Cela créera un tout nouveau profil.
J'espère que l'un d'entre eux fonctionne pour vous.