Pourquoi cela arrive- t- il?

• Custom URI Misconfigurations: L'URI (Uniform Resource Identifier) du point d'extrémité ou de la connexion transmis à la commande présente une erreur de syntaxe ou un schéma non pris en charge.
• Corrupted WinRM Configurations: La configuration de l'écoutant WinRM local ou distant est corrompue ou mal alignée.
• WS-Management Protocol Mismatches: Le client tente d'utiliser un type de shell distant ou une configuration de plug-in personnalisée qui n'est pas enregistrée ou activée sur le serveur cible.
• Corrupted System Files: Les fichiers ou dépendances sous-jacents de Windows sont endommagés.

Réparations étape par étape

Testez votre connexion après chaque étape pour voir si le problème est résolu.

Étape 1: Exécuter la configuration rapide WinRM

Cet utilitaire réinitialise les paramètres WinRM par défaut, active l'écoute et crée les exceptions de pare-feu requises.

1. Cliquez sur le Start menu, type cmd, cliquez avec le bouton droit. Command Prompt, et sélectionnez Run as administrator.
2. Tapez la commande suivante et appuyez Enter:

   winrm quickconfig

3. Si vous êtes invité à apporter des modifications et à activer le service, tapez y et appuyez. Enter.
4. Tapez la commande suivante pour vérifier que l'écoute fonctionne correctement:

   winrm e winrm/config/listener

Étape 2: Vérifier et réinitialiser l'URI de connexion

Si vous exécutez un script ou une commande PowerShell spécifique (comme Enter-PSSession ou... New-PSSession ), le paramètre URI personnalisé peut être incorrect.

1. Assurez-vous que vous ne passez pas manuellement un invalide. -ConnectionURI Un URI WinRM standard ressemble à ceci:

   http://<ComputerName>:5985/wsman

2. Si vous utilisez un shell personnalisé, vérifiez que la chaîne URI respecte strictement le schéma requis par votre application cible.
3. Essayez de vous connecter en utilisant le standard. -ComputerName paramètre au lieu du paramètre URI personnalisé pour voir si le shell par défaut fonctionne:

   Enter-PSSession -ComputerName Target_Computer_Name

Étape 3: Ajouter l'hôte cible à la liste des hôtes de confiance

L'ordinateur client rejettera les connexions vers des terminaux non fiables à moins qu'ils ne soient explicitement ajoutés à la configuration locale.

1. Ouvrez. PowerShell en tant qu'administrateur.
2. Exécutez cette commande pour afficher vos hôtes de confiance actuels:

   Get-Item WSMan:\localhost\Client\TrustedHosts

3. Pour faire confiance à un ordinateur spécifique, exécutez:

   Set-Item WSMan:\localhost\Client\TrustedHosts -Value "Target_Computer_Name" -Force

   (Remarque: vous pouvez utiliser ` ` comme valeur de confiance pour tous les ordinateurs, bien que cela ne soit recommandé que pour des environnements de test isolés).*

4. Redémarrez le service WinRM pour appliquer les modifications:

   Restart-Service WinRM

Étape 4: Réparation des plugins et des shells WinRM corrompus

Si un enregistrement de shell distant personnalisé est corrompu, la réinitialisation de l'infrastructure de shell peut résoudre le problème.

1. Ouvrez. Command Prompt en tant qu'administrateur.
2. Exécutez cette commande pour restaurer les configurations WinRM par défaut:

   winrm reset

3. Ensuite, vérifiez les coquilles enregistrées sur votre système en exécutant:

   winrm e winrm/config/Shell

4. Assurez-vous que l'URI de shell par défaut ( http://microsoft.com ) est actif et n'a pas été écrasé par un plugin personnalisé cassé.

Étape 5: Exécuter le vérificateur de fichiers système (SFC)

Si les composants internes de Windows responsables du traitement des demandes WS-Management sont corrompus, l'outil SFC les réparera.

1. Ouvrez. Command Prompt en tant qu'administrateur.
2. Tapez la commande suivante et appuyez Enter:

   sfc /scannow

3. Attendez que l'analyse soit terminée à 100%.
4. Redémarrez votre ordinateur et réessayez la connexion WinRM.