web-dev-qa-db-fra.com

Comportement déroutant de Powershell

Je suis un peu confus avec l'exécution à distance d'une commande Powershell. J'ai un serveur de test (Win 2k8-R2-SP1) appelé ServerA, qui a la communication à distance PowerShell activée correctement. À partir de ma machine de développement (Win 2k8-R2-SP1), je suis capable d’exécuter à distance les commandes powershell correctement. Mais, lorsque j'essaie d'exécuter la même commande à partir d'un autre serveur appelé ServerB (Win 2k8-R2), j'obtiens le message d'erreur suivant.

[ServerA] Connecting to remote server failed with the following error message : The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service: "winrm quickconfig". For more information, see the about_Remote_Troubleshooting Help topic. + CategoryInfo : OpenError: (:) [], PSRemotingTransportException + FullyQualifiedErrorId : PSSessionStateBroken

Les trois machines sont dans le même domaine. Ma confusion est que de ma machine dev, je suis parfaitement capable de me connecter à ServerA et exécuter la commande. 

Le fait que ServerB ne dispose pas du SP1 fera-t-il une différence? S'il vous plaît donnez votre avis. J'utilise le même compte de domaine qui dispose de droits d'administrateur sur les 3 serveurs.

Et la commande que j'essaie est Invoke-Command -ComputerName ServerA -ScriptBlock {Get-UICulture}.

S'il vous plaît aider.

Merci

powershellpowershell-remoting
18
Prasanna K Rao

Exécutez winrm quickconfig ou Enable-PSRemoting -force à partir de ServerB.

Vérifier que le service fonctionne avec get-service winrm

http://technet.Microsoft.com/en-us/magazine/ff700227.aspx

En outre, lancez ceci depuis votre boite de développement locale:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value "*" -Force
27
manojlds

J'ai également eu le même problème sur une machine qui fonctionnait pour Remote PowerShell dans le passé. Dans mon cas, la solution consistait à effacer le journal de sécurité. C'était plein, et je pense que cela empêchait PowerShell d'établir une connexion sécurisée adéquate.

5
Aerankas

J'avais ce même problème et résolu de la manière suivante. Fonctionnement 

winrm quickconfig

a renvoyé l'erreur ci-dessous.

winrm : WSManFault
At line:1 char:1
+ winrm quickconfig
+ ~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (WSManFault:String) [], RemoteException
    + FullyQualifiedErrorId : NativeCommandError

    Message
        ProviderFault
            WSManFault
                Message = WinRM firewall exception will not work since one of the network connection types on this machine is set to Public. Change the network connection type to either Domain or Private and try again. 
Error number:  -2144108183 0x80338169
WinRM firewall exception will not work since one of the network connection types on this machine is set to Public. Change the network connection type to either Domain or Private and try again.

Dans mon cas, il s’agissait d’un NIC virtuel pour un service d’hyperviseur que j’exécutais sur ma machine. Une fois que je l'ai changé en mode privé, winrm quickconfig s'est exécuté sans erreur. J'ai toujours eu des problèmes de connexion à certaines machines et d'obtenir le même échec que celui décrit dans ce fil. Pour résoudre le problème, j'ai vérifié et démarré le service winrm où il a été arrêté.

get-service -ComputerName computer -Name winrm

Status   Name               DisplayName                           
------   ----               -----------                           
Stopped  winrm              Windows Remote Management (WS-Manag...



get-service -ComputerName computer -Name winrm | Start-Service
2
Bradley_Schanche

Pour éviter de devoir activer WinRM sur chaque serveur que vous gérez, vous pouvez exécuter ce script de traitement par lots:

Exigences:

Utilisation: EnablePSRemoting.bat PCs.txt

@echo off
for /f %%f in (%1) do (
  psexec.exe \\%%f -accepteula -h -d -s powershell.exe "enable-psremoting -force"
  echo Enabled on %%f
)
1
Carl Bennett

Ce qui suit a résolu mon problème:

Vous devez soit vider votre liste d'iplisten qui peut être vérifiée à l'aide de la commande CMD suivante:

netsh http show iplist

ou pour ajouter l'adresse de retour en boucle s'il y a d'autres adresses:

netsh http add iplisten 127.0.0.1
1
Shadi Namrouti

Je cherche la réponse depuis des jours et j'ai trouvé le problème;

Il semble que le composant IIS 7 .NET Extensibility n’ait pas été installé et soit à l’origine de ce problème. Nous avons un serveur R2 Exchange 2010 2012;

https://technet.Microsoft.com/en-us/library/dd421841(v=exchg.80).aspx

Je l'ai installé en entrant ceci dans PowerShell;

Voir ici les conditions préalables pour Exchange 2010. 

https://technet.Microsoft.com/en-us/library/bb691354(v=exchg.141)

Notre serveur Exchange n’a que le rôle de boîte aux lettres, l’autre étant toujours le transport CAS et HUB;

Nous avons donc besoin de cette commande;

Add-WindowsFeature NET-Framework-Features, RSAT-Clustering, Web-Mgmt-Console, Modèle de processus WAS, Web-Basic-Auth, Web-Light-Mgmt-Console, Web-métabase, Web-Net-ext -Server, Web-Windows-Auth -Restart

La partie de Web-Net-Ext a installé le composant IIS 7.NET Extensibility Inutile de redémarrer.

Juste mes 2 cents, peut-être que cela aide quelqu'un d'autre :-)

0
Roël Ramjiawan