Непонятное поведение Powershell - PullRequest
20 голосов
/ 02 сентября 2011

Я немного смущен, когда удаленно выполняю команду powershell.У меня есть тестовый сервер (Win 2k8-R2-SP1) с именем ServerA, на котором правильно включено удаленное взаимодействие PowerShell.С моего компьютера разработчика (Win 2k8-R2-SP1) я могу удаленно выполнять команды powershell правильно.Но, когда я пытаюсь выполнить ту же команду с другого сервера с именем ServerB (Win 2k8-R2), я получаю следующую ошибку

[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

Все три машины находятся в одном и том жедомен.Я путаюсь с тем, что с моей машины разработчика я могу подключиться к ServerA и выполнить команду.

Будет ли иметь значение тот факт, что ServerB не имеет SP1?Пожалуйста, порекомендуйте.Я использую ту же учетную запись домена, которая имеет права администратора на всех 3 серверах.

И команда, которую я пытаюсь сделать, Invoke-Command -ComputerName ServerA -ScriptBlock {Get-UICulture}.

Пожалуйста, помогите.

Спасибо

Ответы [ 6 ]

28 голосов
/ 02 сентября 2011

Выполнить winrm quickconfig или Enable-PSRemoting -force с сервера B.

Убедитесь, что служба работает с get-service winrm

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

Кроме того, запустите ее из своего локальногоокно разработки:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value "*" -Force
5 голосов
/ 13 декабря 2012

У меня тоже была такая же проблема на машине, которая в прошлом работала для удаленного PowerShell.В моем случае решением было очистить журнал безопасности.Он был полон, и я полагаю, что это помешало powershell создать правильное безопасное соединение.

2 голосов
/ 11 октября 2018

У меня была такая же проблема, и я решил ее следующим образом.Запуск

winrm quickconfig

вернул приведенную ниже ошибку.

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. 

В моем случае это был виртуальный сетевой адаптер для службы гипервизора, которую я выполнял на своей машине.Как только я изменил это на Private, winrm quickconfig запустился без ошибок.У меня все еще были проблемы с подключением к некоторым машинам и тем же отказом, как описано в этой теме.Для разрешения я проверил и запустил службу winrm, где она была остановлена.

get-service -ComputerName computer -Name winrm

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



get-service -ComputerName computer -Name winrm | Start-Service
1 голос
/ 07 марта 2017

Чтобы избежать необходимости включать WinRM на каждом сервере, которым вы управляете, вы можете запустить этот пакетный скрипт:

Требования:

Использование: 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 голос
/ 07 декабря 2016

Следующее исправило мою проблему:

Вы должны либо очистить свой список iplisten, который можно проверить с помощью следующей команды CMD:

netsh http show iplist

, либо добавить адрес обратной связи вэто если есть какие-то другие адреса:

netsh http add iplisten 127.0.0.1
0 голосов
/ 19 июля 2017

Я искал ответ в течение нескольких дней и обнаружил проблему;

Похоже, что компонент IIS 7 .NET Extensibility не был установлен, вызывая эту проблему.У нас есть сервер 2012 R2 Exchange 2010;

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

Я установил его, введя его в powershell;

См. Здесь предварительные требования для Exchange 2010.

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

Этот наш сервер Exchange имеет только роль почтового ящика, другой по-прежнему является транспортом CAS и HUB;

Так что нам нужна эта команда;

Функциональные возможности Add-WindowsFeature NET-Framework, RSAT-кластеризация, Web-Mgmt-Console, WAS-Process-Model, Web-Basic-Auth, Web-Lgcy-Mgmt-Console, Web-метабаза, Web-Net-Ext, Web-Server, Web-Windows-Auth -Restart

Часть Web-Net-Ext установила компонент IIS 7.NET Extensibility.Не нужно перезапускать.

Только мои 2 цента, может быть, это поможет кому-то еще: -)

...