Удаленное взаимодействие Powershell внезапно перестает работать

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

Довольно простой скрипт (подробности ниже) успешно работал около года. Внезапно он начал давать сбой, потому что удаленный сценарий PowerShell не мог быть выполнен. Я понятия не имею, в чем основная причина этого. Местные ИТ-службы следят за тем, чтобы они ничего не меняли.

(Должен отметить, что я, вероятно, могу заменить сценарий PowerShell чем-то другим, но я не собираюсь отказываться от этого легко. Кроме того, я хотел бы понять, что здесь не так)

Вот общая настройка:

Виртуальная машина Windows Server 2008 R2, не подключенная к домену, называется целевой. Локальный пользователь u_target назначен группе администраторов на цели.

Виртуальная машина Windows Server 2008 R2 в домене (назовем домен D), называемая источником. Пользователь домена D u_source назначен группе администраторов источника.

Powershell имеет версию 2.0 на обеих виртуальных машинах.

Все команды на цели выполняются u_target с правами администратора, все команды в источнике выполняются u_source с правами администратора. Я трижды проверил, что PowerShell запускается от имени администратора во всех случаях.

Около года назад я включил psremoting на обеих виртуальных машинах следующим образом:

На цели u_target выполняется в административной оболочке. enable-psremoting -force и set-item wsman:\local\client\TrustedHosts -value 'source' После этого машина была перезагружена.

Обе команды были выполнены без ошибок. Позже, когда я столкнулся с проблемой, я заменил «источник» на *, чтобы убедиться, что проблема не связана с опечаткой.

По источнику, u_source выполняется в административной оболочке PowerShell enable-psremoting -force. Эта машина тоже была перезагружена.

Позже, когда что-то не удалось, цель была добавлена ​​и в TrustedHosts здесь.

Скрипт, который предполагается выполнить, в принципе выглядит следующим образом:

$server = 'target' #(using the FQHN)
$username = 'u_target'
$password = 'u_targetpwd' #(the correct one, of course)

$pass = ConvertTo-SecureString -AsPlainText $password -Force
$Cred = New-Object System.Management.Automation.PSCredential -Argumentlist $username,$pass

$scbScriptBlock = {
# a valid script. For simplicity assume it's
Get-ChildItem C:\
}

Invoke-Command -ComputerName $server -Credential $Cred -ScriptBlock $scbScriptBlock 

Это приводит к тому, что примерно через неделю появляется следующее сообщение об ошибке:

[target] Connecting to remote server failed with following error messages  :    
The connection to the specified remote host was refused. Verify that the
WS-Management service is running on the remote host and configured to 
listen for requests on the correct port and HTTP URL. For more information,     
see the about_Remote_Troubleshooting Help topic.
+ CategoryInfo      : OpenError: (:) [], PSRemotingTransportException
+ FullyQualifiedErrorID : PSSessionStateBroken

Что я пытался исправить или разобраться в чем дело:

• Прочтите раздел справки about_Remote_TroublShooting. За некоторыми исключениями (см. Ниже) я уверен, что безуспешно следовал инструкциям.
• Прочтите документация
• перенастроил WSMan (см. выше)
• проверил настройки доверенного хоста с помощью Get-Item, создал их с помощью Set-Item (и не забыл перезапустить wsman).
• вошли на оба компьютера с указанными пользователями и подтвердили, что они по-прежнему принадлежат к группе администраторов, и их пароли по-прежнему действительны
• заменил исходный блок сценария на тривиальный, чтобы убедиться, что сломан не блок сценария.
• проверил, что компьютеры знают друг друга (пинг, тестовое соединение от источника к цели)
• проверил, что u_target может выполнять команды в блоке сценариев при входе в систему с помощью PowerShell в сеансе удаленного рабочего стола
• искал в интернете. Одно попадание предполагало, что профиль пользователя u_target на цели мог быть поврежден, чего не было.
• проверенный WSMan работает в диспетчере служб
• заменил u_target на target \ u_target в скрипте и попробовал с нуля
• перезагрузил указанные виртуальные машины несколько раз и повторил все вышеперечисленное
• создал альтернативную исходную и целевую виртуальные машины с аналогичной настройкой (на них установлена ​​версия PowerShell 3.0). Удаленное взаимодействие и здесь не работает. Удаленное взаимодействие, похоже, отлично работает с парой виртуальных машин, привязанных к домену (вчера и сегодня я тоже не мог заставить его работать), чего я не хочу.
• проверил журнал событий цели в разделах Журналы Windows -> Приложения и Журналы Windows -> Безопасность. В то время как сценарий ранее (когда он все еще работал нормально) генерировал, например, события входа в систему, теперь там больше ничего нет. Ошибок тоже нет.
• проверил настройки брандмауэра на источнике и цели. Я думаю, что они в порядке, но, может быть, я просто хочу верить, что инструмент enable-psremoting работал правильно
• (и, конечно же, проверил, что сценарий также не работает с тривиальным блоком сценария, который я использовал в этом вопросе, вместо исходного, который я не должен публиковать здесь).

Итак, вот мои вопросы:

• конечно, этот ;-): вы хоть представляете, что могло вызвать внезапный сбой скрипта ???

• В чем я не уверен, так это в том, что WS-Management прослушивает порт и URL-адрес HTTP. Как мне это проверить? Я выполнил команду «winrm enumerate winrm / config / listener», потому что мне было сказано сделать это в каком-то старом сообщении в событии, и я заметил, что имя хоста кажется неопределенным. Кажется, что для CertificateThumbprint тоже нет значения, но Transport - это HTTP.

• есть ли какие-либо недавние обновления или исправления, которые, как известно, вызывают проблемы с удаленным взаимодействием PS?
• есть ли какие-либо типичные настройки, которые администратор хотел бы применить в масштабах сети, которые могут привести к подобному отказу?
• где еще я мог посмотреть (конкретный журнал событий, идентификаторы событий)?

Еще несколько абсурдных идей, которые мне пришли в голову, может быть, не слишком абсурдные (?):

• виртуальные машины были настроены почти ровно за год до того, как сценарий начал давать сбой - есть ли какие-то настройки, срок действия которых истекает через год, которые я бы не заметил в противном случае, но которые могли бы вызвать такой эффект?
• установка .net Framework 4.5.2 - я почти уверен, что скрипт был в рабочем состоянии после того, как это произошло, хотя
• есть ли сертификат, срок действия которого может истек?