Enter-PSSession sur le serveur distant échoue avec "impossible de trouver l'ordinateur"
Mon ordinateur est win7 et j'essaie de me connecter à un serveur 2012.
Les deux hôtes sont sur le même domaine.
Si je fais:
Enter-PSSession -ComputerName *ServerName***
Je reçois le message d'échec suivant de winrm
Enter-PSSession: La connexion au serveur distant xxx a échoué avec le Message d'erreur suivant: WinRM ne peut pas traiter la demande. L'erreur suivante s'est produite lors de l'utilisation de Authentification Kerberos: impossible de trouver l'ordinateur xxx. Vérifiez que le ordinateur existe sur le réseau et que le nom fourni est orthographié correctement. *
Peu importe que j'utilise uniquement le nom du serveur ou que je l'entre pleinement qualifié.
Les deux systèmes affichent $PSVersionTable.PSVersion 4 0 -1 -1
J'ai essayé les divers conseils de dépannage que j'ai trouvés, c'est-à-dire.
lancez Enable-PSRemoting -Force et définissez également TrustedHosts = * des deux côtés.
J'ai également désactivé le service de pare-feu des deux côtés.
Lorsque j'essaie d'entrer-PSSession du serveur sur mon bureau, cela fonctionne comme souhaité.
Mais de mon bureau au serveur, je reçois toujours le message d'erreur que l'ordinateur est introuvable.
Après avoir parlé à notre administrateur de domaine, je pense avoir trouvé la cause du problème.
Le serveur se trouve dans un domaine de ressources qui n’a une confiance que dans un sens envers l’unité organisationnelle principale.
Ceci explique pourquoi je peux faire de la communication à distance PS du serveur aux clients mais pas l’inverse.
J'ai découvert que je pouvais utiliser l'adresse IP avec l'option -Credential dans mon cas, bien que ce ne soit pas Nice mais une solution de contournement acceptable.
Cela est probablement dû au fait que votre nom netbios est différent du nom d'hôte du serveur. Essayez plutôt de vous connecter avec le nom netbios.
- Déterminez le nom correct en exécutant la commande suivante dans powershell:
"$ env: NOMORDINATEUR. $ env: USERDNSDOMAIN"
Dans mon cas, DNS pointait vers la bonne adresse IP, mais il y avait une faute de frappe dans le nom d’hôte, donc le paramètre -Commutername et le nom d’hôte ne correspondaient pas.
lancer winrm quickconfig à partir d'une session PowerShell sur la machine distante
Je sais que c'est très tard, mais je répare les quelques sites qui ont connu le même problème. pour moi, c'était un nom d'ordinateur en double dans le domaine racine. trouvé en exécutant setspn -f -q */nom_serveur. cela a fait apparaître le nom du serveur dans plusieurs domaines. supprimer la machine invalide de la racine AD et de la racine DNS et j’étais opérationnel.
Vérifiez la réplication de domaine et voyez si l'objet ordinateur est là où il est censé être. C’est quelque chose que j’ai dû traiter pour les objets informatiques qui n’ont pas été répliqués d’un contrôleur de domaine à un autre.
Il existe un certificat auto-signé sous ordinateur local/RDP ... assurez-vous qu’il en existe un que le service WinRM peut utiliser.
Voyez si vous pouvez savoir s'il existe un pare-feu susceptible de bloquer les ports WinRM.
J'espère que ça aide.