Задать вопрос

Ошибка: Указанный сеанс работы не существует?

На сервере в папке C:\scripts лежит powershell скрипт который:
Берет файлы из папок и редактирует в них данные, а вторым шагом раскидывает их на удаленные компьютеры.

2 шаг, в кратце, выглядит так:

Invoke-Command $remoteComp -Credential $cred -Scriprblock {
New-PsDrive -Name X -Credential $credLocal -PsProvider FileSystem -Root \\10.10.10.10\script\first\

Copy-Item -Path X:\Filename.txt -Destination C:\FileFloder\Filename.txt

Remove-Psdrive -Name X}


Оно работает. Файл хорошо перекидывается. НО, примерно в 2/3 случаев я получаю ошибку «Указанный сеанс работы не существует. Возможно он завершён»
При этом если перезагрузить удаленную машину, либо запустить скрипт ещё раз через 30 минут, он отработает корректно.

На удалённых машинах созданы учетные записи локального администратора, применен комадлет Enable-Psremoting -Force, на сервере учетная запись админа существует, так же и машины с которыми устанавливается соединение внесены в TrustedHosts. Все компьютеры НЕ находятся в домене. Все машины под управлением Windows 10 и используется Powershell 5.1.

В Google говорят, что возможно я ловлю ошибку из за Double-Hop (когда я подключаюсь из удаленной сессии к ещё одной удаленной сессии), но тогда я бы не смог вообще отработать. Но скрипт стабильно работает в 1/3 случаев, а чаще я получаю ошибку « Указанный сеанс работы не существует. Возможно он завершён».
  • Вопрос задан
  • 5389 просмотров
Подписаться 3 Средний Комментировать
Решения вопроса 1
@azarij
В меру опытный никто
у меня кажется получилось добится такой же ошибки.
решилось введением имени юзера через имя_хоста\имя_юзера. имя хоста конечной удаленной машины, на которой нужно выполнить scriptblock. юзер - локальный админ на конечной удаленной машине.

перед этим я, правда, игрался с credssp и везде его повключал (enable-wsmancredssp, в invoke-command добавить ключ -authentication credssp). но после нахождения решения выше, отключил и попробовал еще раз - работает.

кстати, invoke-command, похоже, использует Negotiate как дефолтный метод аутентификации. возможно, непостоянство проблемы вызвано тем, что при "переговорах" от том, как будем аутентифицироваться машины снюхиваются разными методами (почему? понятия не имею, это только теория) или разные машины выбирают разные методы. какие-то с какими-то машинами работают, какие-то нет и вылазит ошибка. возможно, стоит перебрать все значения параметра -authentication в invoke-command, найти тот, который работает каждый раз и его жестко указывать.
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы