powershell удаленный запуск приложения

Запуск интерактивного сеанса

Чтобы запустить интерактивный сеанс с одним удаленным компьютером, используйте командлет Enter-PSSession. Например, чтобы запустить интерактивный сеанс с удаленным компьютером Server01, введите:
enter-pssession Server01
В командной строке отобразится имя компьютера, к которому вы подключены. В дальнейшем все команды, введенные в командной строке, будут запускаться на удаленном компьютере, а результаты отобразятся на локальном компьютере.
Чтобы завершить интерактивный сеанс, введите:
exit-pssession

Выполнение удаленной команды

Чтобы выполнить любую команду на одном или нескольких удаленных компьютерах, используйте командлет Invoke-Command. Например, чтобы выполнить команду Get-UICulture на удаленных компьютерах Server01 и Server02, введите:

Invoke-command -computername Server01, Server02 {get-UICulture}
Выходные данные будут возвращены на ваш компьютер.
Чтобы запустить сценарий на одном или нескольких удаленных компьютерах, используйте параметр FilePath командлета Invoke-Command. Сценарий должен быть включен или доступен для локального компьютера. Результаты будут возвращены на локальный компьютер.
Например, следующая команда выполняет сценарий DiskCollect.ps1 на удаленных компьютерах Server01 и Server02.
invoke-command -computername Server01, Server02 -filepath c:\Scripts\DiskCollect.ps1

Установка постоянного подключения
Чтобы выполнить ряд связанных команд с общими данными, создайте сеанс на удаленном компьютере, а затем используйте командлет Invoke-Command для выполнения команд в созданном сеансе. Чтобы создать удаленный сеанс, используйте командлет New-PSSession.
Например, следующая команда создает удаленный сеанс на компьютере Server01 и другой удаленный сеанс на компьютере Server02. Она сохраняет объекты сеанса в переменной $s.
$s = new-pssession -computername Server01, Server02
После установки сеансов в них можно выполнить любую команду. Так как сеансы являются постоянными, вы можете собирать данные в одной команде и использовать их в последующей.
Например, следующая команда выполняет команду Get-Hotfix в сеансах в переменной $s и сохраняет результаты в переменной $h. Переменная $h создается в каждом сеансе в $s, но она не существует в локальном сеансе.
invoke-command -session $s {$h = get-hotfix}
Теперь данные в переменной $h можно использовать в последующих командах, таких как следующая. Результаты отобразятся на локальном компьютере.

Invoke-command -session $s {$h | where {$_.installedby -ne "NTAUTHORITY\SYSTEM"}

Всё взято с https://technet.microsoft.com/ru-ru/library/dd819505.aspx

Здесь минимум теории, в основном практическая часть. Описывается как настроить WinRM, как изменить профиль сетевого адаптера, дается скрипт по добавлению в TrustedHosts с фильтрацией, объясняется зачем нужны доверенные хосты, и рассматриваются поверхностно удаленные подключения так чтобы можно было сесть и сразу админить удаленные машины.

Наиболее простой путь сконфигурировать удаленное управление это выполнить Enable-PSRemoting в оболочке powershell с правами администратора. При этом произойдет следущее:

• запустится служба WinRM (если запущена перезапустится)
• служба WinRM перейдет в состояние - автоматический запуск при старте
• будет создан прослушиватель WinRM для HTTP трафика на порту 5985 для всех локальных IP адресов
• будет создано правило файрвола для прослушивателя WinRM. Внимание, этот пункт завершится с ошибкой если любая из сетевых карточек имеет тип сети «публичная», т.к. открывать порт на такой карточке не хорошо. Если у вас при конфигурировании вышла такая ошибка измените профиль это сетевушки командлетом Set-NetConnectionProfile и после этого запустите Enable-PSRemoting снова. Если вам нужна сетевая карточка с профилем «Публичная сеть» запустите Enable-PSRemoting с параметром -SkipNetworkProfileCheck в этом случае будут созданы правила файрвола только из локальной сети.

После этого нужно разрешить подключаться к удаленной машине с той машины с которой будет происходить управление. Сделано это в целях безопасности для того чтобы уменьшить риск взлома сессии удаленного управления или DNS с подстановкой себя вместо удаленной машины и предотвратить исполнение скриптов на машинах которые вы принудительно не разрешили.

Для проверки куда можно подключаться используем:
get-item wsman:\localhost\Client\TrustedHosts
для разрешения подключаться ко всем
set-item wsman:localhost\client\trustedhosts -value *
Если вы открываете доступ для всех указав * то WinRM будет подключаться ко ВСЕМ машинам без проверки. Помните, что вы открываете самого себя для потенциального взлома из локальной сети. Лучше указывать адреса хостов куда вам нужно подключится, тогда WinRM будет отклонять все остальные адреса или имена. Если машина с которой ведется управление находится в домене она будет доверять всем машинам этого домена. Если она не в домене, или в другом домене, то нужно указать в TrustedHosts адрес или имя машины на которую мы будем подключаться. Добавлять себя на машине к которой мы подключаемся не нужно.

В хелпе указаны команды, я их чуть чуть переделал в скрипт
###################################################################################### # добавляет NewHost в список TrustedHost с фильтрацией если такая строка уже есть # можно дергать из командной строки указывая параметр напрямую например # .\Add-TrustedHost.ps1 192.168.2.1 ###################################################################################### param ($NewHost = "192.168.2.89") Write-Host "adding host: $NewHost" $prev = (get-item WSMan:\localhost\Client\TrustedHosts).value if (($prev.Contains($NewHost)) -eq $false) { if ($prev -eq "") { set-item WSMan:\localhost\Client\TrustedHosts -Value "$NewHost" } else { set-item WSMan:\localhost\Client\TrustedHosts -Value "$prev, $NewHost" } } Write-Host "" Write-Host "Now TrustedHosts contains:" (get-item WSMan:\localhost\Client\TrustedHosts).value
он проверяет на есть ли такая запись, если нет то добавляет в список. Вызывать можно из командной строки указав адрес или имя.

Есть разница указывать имя или адрес. Если в TrustedHosts будет только адрес то открыть сессию по имени не получится, и наоборот - если указать имя то прицепится по адресу не получится. Учитывайте это.

в чем же разница

Enable-PSRemoting делает больше действий чем «winrm quickconfig». Командлет Set-WSManQuickConfig делает точно такие же действия как «winrm quickconfig». Enable-PSRemoting запускает Set-WSManQuickConfig когда ведет настройку системы

Удаленные подключения
1. Сессии 1-to-1
открываются командой
Enter-PSSession -ComputerName Test
Вы получите оболочку на удаленной машине. Подключится можно к самому себе указав localhost. Альтернативные кредиталы указываются с параметром -Credential , выход происходит командлетом Exit-PSSession

Ограничения следующие:

• нельзя сделать второй прыжок - только 1 сессия, внутри сессии подключиться дальше нельзя
• вы не можете использовать команды имеющие графический интерфейс. Если вы это сделаете оболочка повиснет, нажмите Ctrl+C чтобы отвисло
• вы не можете запускать команды имеющие свой собственый шел, например nslookup, netsh
• вы можете запускать скрипты если политика запуска на удаленной машине позволяет их запускать
• нельзя прицепится к интерактивной сессии, вы заходите как «network logon» , как будто прицепились к сетевому диску. Поэтому не запустятся логон скрипты, и вы можете не получить домашнюю папку на удаленной машине (лишний довод чтобы не мапать хом фолдеры логон скриптами)
• вы не сможете взаимодействовать с юзером на удаленной машине даже если он туда залогинен. Не получится показать ему окошко или попечатать чтонибудь ему.

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

Комментарий.
объекты переданные по сети обрезаются и перестают быть живыми. У них удаляются методы, свойства остаются. Вытащить объект на свою машину, поколдовать и засунуть обратно не получится. Если нужно больше пишите, допишу отдельно.

2. Сессии 1-to-many
Invoke-Command
определяем что будем исполнять так:
$sb = { команды для удаленной машины разделенные точкой с запятой }
передаем на удаленные машины Test1 и Test2
Invoke-Command -ComputerName Test1, Test2 -ScriptBlock $sb
за раз можно забросить на 32 машины. Если альтернативные кредиталы то используем параметр -Credential

Чтобы передать целиком скрипт вместо параметра -ScriptBlock пишем -FilePath, удаленной машине НЕ нужно иметь доступ к файлу, он будет разобран на запчасти, передан через HTTP и выполнен с той стороны.

Запомним что на той стороне будет новый скоп, так что ваш скрипт не получит значений из вашей консоли, а переменные скрипта могут оказаться на той стороне пустыми. Поэтому передавайте сразу целиком готовые инструкции и скрипты с параметрами.

для полноценного использования Invoke-Command надо уметь превращать строки в скрипт блоки. Например у вас есть команды которые зависят от какогото списка, вам нужно сгенерировать строку, превратить ее в ScriptBlock и отправить на удаленный комп:
$sb = ::Create($SomeString)

kuda78
В статье пропущен очень важный момент - передача параметров в скрипт на удаленной машине.

$deployRemote = {
param(
$targetEnvName,
$targetUsername)
$Global:ErrorActionPreference = «Stop»
#…
}

Invoke-Command -Session $session -ScriptBlock $deployRemote -ArgumentList ($targetEnvName, $targetUsername)

Да действительно пропущен. Сделал сознательно чтобы не загромождать обзор параметрами и описаниями. Спасибо. Параметр -ArgumentList работает как со скрипт блоками так и со сценариями

3. Сессии
Это когда с той стороны создается копия пошика постоянно висящая в памяти, и в нее отправляются команды. Как результат к ней можно переподключится, ченить долгое запустить на исполнение, цепляться из разных скриптов или разными юзерами. Например у вас есть набор скриптов решающих одну задачу по частям, каждый из них поочереди может подключатся к одной удаленной сессии, видеть результаты работы предыдущих команд, иметь одни загруженные модули, общие переменные, общее окружение, до тех пор пока сессия не будет принудительно закрыта.

Создание сессии происходит командлетом New-PSSession, результат можно поместить в переменную
$DC01 = New-PSSession -ComputerName DC01 $Controllers = New-PSSession DC01, DC02, DC03
использовать можно такие же параметры подключения как в Invoke-Command

Как использовать:
если 1-to-1
Enter-PSSession -Session $DC01
если 1-to-many
Invoke-Command -Sessions $Controllers -ScriptBlock {get-eventlog -logname security -newest 50}
посмотреть какие сессии открыты можно с помощью Get-PSSession, закрыть Remove-PSSession
закрыть вообще все сессии
Get-PSSession | Remove-PSSession
прицепится к сессии можно с помощью Connect-PSSession, отключиться через Disconnect-PSSession

Invoke-Command может создать сразу disconnected сессию, он отправляет команды на исполнение и отключатся, позже можно подключится и сгрузить результаты работы. Делается это параметром -Disconnected. Получение результатов через командлет Recieve-PSSession.

Сессии имеют очень много настроек, возможно даже создание сессий с обрезаным набором команд, модулей и т.п. Называется custom endpoints

Вы можете помочь и перевести немного средств на развитие сайта

• Tutorial

Здесь минимум теории, в основном практическая часть. Описывается как настроить WinRM, как изменить профиль сетевого адаптера, дается скрипт по добавлению в TrustedHosts с фильтрацией, объясняется зачем нужны доверенные хосты, и рассматриваются поверхностно удаленные подключения так чтобы можно было сесть и сразу админить удаленные машины.

Наиболее простой путь сконфигурировать удаленное управление это выполнить Enable-PSRemoting в оболочке powershell с правами администратора. При этом произойдет следущее:

• запустится служба WinRM (если запущена перезапустится)
• служба WinRM перейдет в состояние - автоматический запуск при старте
• будет создан прослушиватель WinRM для HTTP трафика на порту 5985 для всех локальных IP адресов
• будет создано правило файрвола для прослушивателя WinRM. Внимание, этот пункт завершится с ошибкой если любая из сетевых карточек имеет тип сети «публичная», т.к. открывать порт на такой карточке не хорошо. Если у вас при конфигурировании вышла такая ошибка измените профиль это сетевушки командлетом Set-NetConnectionProfile и после этого запустите Enable-PSRemoting снова. Если вам нужна сетевая карточка с профилем «Публичная сеть» запустите Enable-PSRemoting с параметром -SkipNetworkProfileCheck в этом случае будут созданы правила файрвола только из локальной сети.

После этого нужно разрешить подключаться к удаленной машине с той машины с которой будет происходить управление. Сделано это в целях безопасности для того чтобы уменьшить риск взлома сессии удаленного управления или DNS с подстановкой себя вместо удаленной машины и предотвратить исполнение скриптов на машинах которые вы принудительно не разрешили.

Для проверки куда можно подключаться используем:
get-item wsman:\localhost\Client\TrustedHosts
для разрешения подключаться ко всем
set-item wsman:localhost\client\trustedhosts -value *
Если вы открываете доступ для всех указав * то WinRM будет подключаться ко ВСЕМ машинам без проверки. Помните, что вы открываете самого себя для потенциального взлома из локальной сети. Лучше указывать адреса хостов куда вам нужно подключится, тогда WinRM будет отклонять все остальные адреса или имена. Если машина с которой ведется управление находится в домене она будет доверять всем машинам этого домена. Если она не в домене, или в другом домене, то нужно указать в TrustedHosts адрес или имя машины на которую мы будем подключаться. Добавлять себя на машине к которой мы подключаемся не нужно.

В хелпе указаны команды, я их чуть чуть переделал в скрипт
###################################################################################### # добавляет NewHost в список TrustedHost с фильтрацией если такая строка уже есть # можно дергать из командной строки указывая параметр напрямую например # .\Add-TrustedHost.ps1 192.168.2.1 ###################################################################################### param ($NewHost = "192.168.2.89") Write-Host "adding host: $NewHost" $prev = (get-item WSMan:\localhost\Client\TrustedHosts).value if (($prev.Contains($NewHost)) -eq $false) { if ($prev -eq "") { set-item WSMan:\localhost\Client\TrustedHosts -Value "$NewHost" } else { set-item WSMan:\localhost\Client\TrustedHosts -Value "$prev, $NewHost" } } Write-Host "" Write-Host "Now TrustedHosts contains:" (get-item WSMan:\localhost\Client\TrustedHosts).value
он проверяет на есть ли такая запись, если нет то добавляет в список. Вызывать можно из командной строки указав адрес или имя.

Есть разница указывать имя или адрес. Если в TrustedHosts будет только адрес то открыть сессию по имени не получится, и наоборот - если указать имя то прицепится по адресу не получится. Учитывайте это.

в чем же разница

Enable-PSRemoting делает больше действий чем «winrm quickconfig». Командлет Set-WSManQuickConfig делает точно такие же действия как «winrm quickconfig». Enable-PSRemoting запускает Set-WSManQuickConfig когда ведет настройку системы

Удаленные подключения
1. Сессии 1-to-1
открываются командой
Enter-PSSession -ComputerName Test
Вы получите оболочку на удаленной машине. Подключится можно к самому себе указав localhost. Альтернативные кредиталы указываются с параметром -Credential , выход происходит командлетом Exit-PSSession

Ограничения следующие:

• нельзя сделать второй прыжок - только 1 сессия, внутри сессии подключиться дальше нельзя
• вы не можете использовать команды имеющие графический интерфейс. Если вы это сделаете оболочка повиснет, нажмите Ctrl+C чтобы отвисло
• вы не можете запускать команды имеющие свой собственый шел, например nslookup, netsh
• вы можете запускать скрипты если политика запуска на удаленной машине позволяет их запускать
• нельзя прицепится к интерактивной сессии, вы заходите как «network logon» , как будто прицепились к сетевому диску. Поэтому не запустятся логон скрипты, и вы можете не получить домашнюю папку на удаленной машине (лишний довод чтобы не мапать хом фолдеры логон скриптами)
• вы не сможете взаимодействовать с юзером на удаленной машине даже если он туда залогинен. Не получится показать ему окошко или попечатать чтонибудь ему.

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

Комментарий.
объекты переданные по сети обрезаются и перестают быть живыми. У них удаляются методы, свойства остаются. Вытащить объект на свою машину, поколдовать и засунуть обратно не получится. Если нужно больше пишите, допишу отдельно.

2. Сессии 1-to-many
Invoke-Command
определяем что будем исполнять так:
$sb = { команды для удаленной машины разделенные точкой с запятой }
передаем на удаленные машины Test1 и Test2
Invoke-Command -ComputerName Test1, Test2 -ScriptBlock $sb
за раз можно забросить на 32 машины. Если альтернативные кредиталы то используем параметр -Credential

Чтобы передать целиком скрипт вместо параметра -ScriptBlock пишем -FilePath, удаленной машине НЕ нужно иметь доступ к файлу, он будет разобран на запчасти, передан через HTTP и выполнен с той стороны.

Запомним что на той стороне будет новый скоп, так что ваш скрипт не получит значений из вашей консоли, а переменные скрипта могут оказаться на той стороне пустыми. Поэтому передавайте сразу целиком готовые инструкции и скрипты с параметрами.

для полноценного использования Invoke-Command надо уметь превращать строки в скрипт блоки. Например у вас есть команды которые зависят от какогото списка, вам нужно сгенерировать строку, превратить ее в ScriptBlock и отправить на удаленный комп:
$sb = ::Create($SomeString)

kuda78
В статье пропущен очень важный момент - передача параметров в скрипт на удаленной машине.

$deployRemote = {
param(
$targetEnvName,
$targetUsername)
$Global:ErrorActionPreference = «Stop»
#…
}

Invoke-Command -Session $session -ScriptBlock $deployRemote -ArgumentList ($targetEnvName, $targetUsername)

Да действительно пропущен. Сделал сознательно чтобы не загромождать обзор параметрами и описаниями. Спасибо. Параметр -ArgumentList работает как со скрипт блоками так и со сценариями

3. Сессии
Это когда с той стороны создается копия пошика постоянно висящая в памяти, и в нее отправляются команды. Как результат к ней можно переподключится, ченить долгое запустить на исполнение, цепляться из разных скриптов или разными юзерами. Например у вас есть набор скриптов решающих одну задачу по частям, каждый из них поочереди может подключатся к одной удаленной сессии, видеть результаты работы предыдущих команд, иметь одни загруженные модули, общие переменные, общее окружение, до тех пор пока сессия не будет принудительно закрыта.

Создание сессии происходит командлетом New-PSSession, результат можно поместить в переменную
$DC01 = New-PSSession -ComputerName DC01 $Controllers = New-PSSession DC01, DC02, DC03
использовать можно такие же параметры подключения как в Invoke-Command

Как использовать:
если 1-to-1
Enter-PSSession -Session $DC01
если 1-to-many
Invoke-Command -Sessions $Controllers -ScriptBlock {get-eventlog -logname security -newest 50}
посмотреть какие сессии открыты можно с помощью Get-PSSession, закрыть Remove-PSSession
закрыть вообще все сессии
Get-PSSession | Remove-PSSession
прицепится к сессии можно с помощью Connect-PSSession, отключиться через Disconnect-PSSession

Invoke-Command может создать сразу disconnected сессию, он отправляет команды на исполнение и отключатся, позже можно подключится и сгрузить результаты работы. Делается это параметром -Disconnected. Получение результатов через командлет Recieve-PSSession.

Сессии имеют очень много настроек, возможно даже создание сессий с обрезаным набором команд, модулей и т.п. Называется custom endpoints

Powershell настолько крут, что позволяет не только выполнять некоторые команды на удалённых компьютерах, но и полностью подключаться к компьютеру и выполнять команды как-будто на локальном компьютере. По умолчанию такое удовольствие отключено в целях безопасности. Включить и настроить его совсем не сложно, но многие почему-то этого не знают.

Для удалённого управления необходимо два условия: во-первых на обоих компьютерах естественно необходимо чтобы были установлены Powershell, .NET Framework и служба Windows Remote Management (все компоненты начиная с версии 2.0 и выше), а во-вторых, чтобы они были настроены на удалённое управление. Для Windows 7 и выше ничего устанавливать не нужно, всё уже есть, для Windows XP/2003 нужно установить.NET Framework и Powershell (служба Windows Remote Management поставляется в комплекте с Powershell).

После того как всё необходимое установлено нужно настроить, компьютер к которому нужно будет подключаться на разрешение удалённых подключений. Для этого нужно выполнить команду winrm quickconfig или winrm qc . Эта команда выполняет сразу несколько действий:

• Запускает службу WinRM
• Изменяет тип запуска службы WinRM на автоматический
• Создаёт прослушивателя для приема запросов с любого IP-адреса
• Изменяет правила брандмауэра для трафика WS-Management (только HTTP)

На этом можно сказать, что компьютер готов для удалённых подключений, однако на практике бывает нужно ещё выполнить команду Enable-PSRemoting .

Всё! Настройка компьютера завершена, и к нему можно подключаться. Теперь пару слов о том, как подключаться. Самый простой способ это использовать командлет Enter-PSSession , после которого указать имя компьютера к которому нужно подключиться, например:

Enter-PSSession NameOfRemoteComputer

При таком способе подключиться удастся при членстве комьютеров в домене, или если на удалённом компьютере есть пользователь, входящий в группу “Администраторы” с таким же логином и паролем как у текущего пользователя.

Кстати, по умолчанию подключаться к удалённому компьютеру могут только члены группы “Администраторы” (о том как это исправить в другой раз).

А как быть в случае если компьютеры не в домене (или в разных доменах) и логины и пароли администраторов разные?

В этом случае командлет Enter-PSSession нужно использовать с параметром -Credential , который позволяет ввести нужные учётные данные для подключения. Но до того как подключаться к компьютеру его нужно добавить в список доверенных узлов (Trusted Hosts). Это делается командой:

Set-Item WSMan:\ localhost\Client\TrustedHosts -value ComputerName

где ComputerName — имя компьютера, к которому будем подключаться. Можно указать как имя компьютера, так и его IP-адрес, однако следует помнить, что то, что ввести здесь, то и нужно будет в последствии использовать для подключения, т.е. если указать IP-адрес, то нельзя будет подключиться к компьютеру, указывая его имя, нужно будет указывать IP-адрес, и наоборот.

• Tutorial

Здесь минимум теории, в основном практическая часть. Описывается как настроить WinRM, как изменить профиль сетевого адаптера, дается скрипт по добавлению в TrustedHosts с фильтрацией, объясняется зачем нужны доверенные хосты, и рассматриваются поверхностно удаленные подключения так чтобы можно было сесть и сразу админить удаленные машины.

Наиболее простой путь сконфигурировать удаленное управление это выполнить Enable-PSRemoting в оболочке powershell с правами администратора. При этом произойдет следущее:

• запустится служба WinRM (если запущена перезапустится)
• служба WinRM перейдет в состояние - автоматический запуск при старте
• будет создан прослушиватель WinRM для HTTP трафика на порту 5985 для всех локальных IP адресов
• будет создано правило файрвола для прослушивателя WinRM. Внимание, этот пункт завершится с ошибкой если любая из сетевых карточек имеет тип сети «публичная», т.к. открывать порт на такой карточке не хорошо. Если у вас при конфигурировании вышла такая ошибка измените профиль это сетевушки командлетом Set-NetConnectionProfile и после этого запустите Enable-PSRemoting снова. Если вам нужна сетевая карточка с профилем «Публичная сеть» запустите Enable-PSRemoting с параметром -SkipNetworkProfileCheck в этом случае будут созданы правила файрвола только из локальной сети.

После этого нужно разрешить подключаться к удаленной машине с той машины с которой будет происходить управление. Сделано это в целях безопасности для того чтобы уменьшить риск взлома сессии удаленного управления или DNS с подстановкой себя вместо удаленной машины и предотвратить исполнение скриптов на машинах которые вы принудительно не разрешили.

Для проверки куда можно подключаться используем:
get-item wsman:\localhost\Client\TrustedHosts
для разрешения подключаться ко всем
set-item wsman:localhost\client\trustedhosts -value *
Если вы открываете доступ для всех указав * то WinRM будет подключаться ко ВСЕМ машинам без проверки. Помните, что вы открываете самого себя для потенциального взлома из локальной сети. Лучше указывать адреса хостов куда вам нужно подключится, тогда WinRM будет отклонять все остальные адреса или имена. Если машина с которой ведется управление находится в домене она будет доверять всем машинам этого домена. Если она не в домене, или в другом домене, то нужно указать в TrustedHosts адрес или имя машины на которую мы будем подключаться. Добавлять себя на машине к которой мы подключаемся не нужно.

В хелпе указаны команды, я их чуть чуть переделал в скрипт
###################################################################################### # добавляет NewHost в список TrustedHost с фильтрацией если такая строка уже есть # можно дергать из командной строки указывая параметр напрямую например # .\Add-TrustedHost.ps1 192.168.2.1 ###################################################################################### param ($NewHost = "192.168.2.89") Write-Host "adding host: $NewHost" $prev = (get-item WSMan:\localhost\Client\TrustedHosts).value if (($prev.Contains($NewHost)) -eq $false) { if ($prev -eq "") { set-item WSMan:\localhost\Client\TrustedHosts -Value "$NewHost" } else { set-item WSMan:\localhost\Client\TrustedHosts -Value "$prev, $NewHost" } } Write-Host "" Write-Host "Now TrustedHosts contains:" (get-item WSMan:\localhost\Client\TrustedHosts).value
он проверяет на есть ли такая запись, если нет то добавляет в список. Вызывать можно из командной строки указав адрес или имя.

Есть разница указывать имя или адрес. Если в TrustedHosts будет только адрес то открыть сессию по имени не получится, и наоборот - если указать имя то прицепится по адресу не получится. Учитывайте это.

в чем же разница

Enable-PSRemoting делает больше действий чем «winrm quickconfig». Командлет Set-WSManQuickConfig делает точно такие же действия как «winrm quickconfig». Enable-PSRemoting запускает Set-WSManQuickConfig когда ведет настройку системы

Удаленные подключения
1. Сессии 1-to-1
открываются командой
Enter-PSSession -ComputerName Test
Вы получите оболочку на удаленной машине. Подключится можно к самому себе указав localhost. Альтернативные кредиталы указываются с параметром -Credential , выход происходит командлетом Exit-PSSession

Ограничения следующие:

• нельзя сделать второй прыжок - только 1 сессия, внутри сессии подключиться дальше нельзя
• вы не можете использовать команды имеющие графический интерфейс. Если вы это сделаете оболочка повиснет, нажмите Ctrl+C чтобы отвисло
• вы не можете запускать команды имеющие свой собственый шел, например nslookup, netsh
• вы можете запускать скрипты если политика запуска на удаленной машине позволяет их запускать
• нельзя прицепится к интерактивной сессии, вы заходите как «network logon» , как будто прицепились к сетевому диску. Поэтому не запустятся логон скрипты, и вы можете не получить домашнюю папку на удаленной машине (лишний довод чтобы не мапать хом фолдеры логон скриптами)
• вы не сможете взаимодействовать с юзером на удаленной машине даже если он туда залогинен. Не получится показать ему окошко или попечатать чтонибудь ему.

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

Комментарий.
объекты переданные по сети обрезаются и перестают быть живыми. У них удаляются методы, свойства остаются. Вытащить объект на свою машину, поколдовать и засунуть обратно не получится. Если нужно больше пишите, допишу отдельно.

2. Сессии 1-to-many
Invoke-Command
определяем что будем исполнять так:
$sb = { команды для удаленной машины разделенные точкой с запятой }
передаем на удаленные машины Test1 и Test2
Invoke-Command -ComputerName Test1, Test2 -ScriptBlock $sb
за раз можно забросить на 32 машины. Если альтернативные кредиталы то используем параметр -Credential

Чтобы передать целиком скрипт вместо параметра -ScriptBlock пишем -FilePath, удаленной машине НЕ нужно иметь доступ к файлу, он будет разобран на запчасти, передан через HTTP и выполнен с той стороны.

Запомним что на той стороне будет новый скоп, так что ваш скрипт не получит значений из вашей консоли, а переменные скрипта могут оказаться на той стороне пустыми. Поэтому передавайте сразу целиком готовые инструкции и скрипты с параметрами.

для полноценного использования Invoke-Command надо уметь превращать строки в скрипт блоки. Например у вас есть команды которые зависят от какогото списка, вам нужно сгенерировать строку, превратить ее в ScriptBlock и отправить на удаленный комп:
$sb = ::Create($SomeString)

kuda78
В статье пропущен очень важный момент - передача параметров в скрипт на удаленной машине.

$deployRemote = {
param(
$targetEnvName,
$targetUsername)
$Global:ErrorActionPreference = «Stop»
#…
}

Invoke-Command -Session $session -ScriptBlock $deployRemote -ArgumentList ($targetEnvName, $targetUsername)

Да действительно пропущен. Сделал сознательно чтобы не загромождать обзор параметрами и описаниями. Спасибо. Параметр -ArgumentList работает как со скрипт блоками так и со сценариями

3. Сессии
Это когда с той стороны создается копия пошика постоянно висящая в памяти, и в нее отправляются команды. Как результат к ней можно переподключится, ченить долгое запустить на исполнение, цепляться из разных скриптов или разными юзерами. Например у вас есть набор скриптов решающих одну задачу по частям, каждый из них поочереди может подключатся к одной удаленной сессии, видеть результаты работы предыдущих команд, иметь одни загруженные модули, общие переменные, общее окружение, до тех пор пока сессия не будет принудительно закрыта.

Создание сессии происходит командлетом New-PSSession, результат можно поместить в переменную
$DC01 = New-PSSession -ComputerName DC01 $Controllers = New-PSSession DC01, DC02, DC03
использовать можно такие же параметры подключения как в Invoke-Command

Как использовать:
если 1-to-1
Enter-PSSession -Session $DC01
если 1-to-many
Invoke-Command -Sessions $Controllers -ScriptBlock {get-eventlog -logname security -newest 50}
посмотреть какие сессии открыты можно с помощью Get-PSSession, закрыть Remove-PSSession
закрыть вообще все сессии
Get-PSSession | Remove-PSSession
прицепится к сессии можно с помощью Connect-PSSession, отключиться через Disconnect-PSSession

Invoke-Command может создать сразу disconnected сессию, он отправляет команды на исполнение и отключатся, позже можно подключится и сгрузить результаты работы. Делается это параметром -Disconnected. Получение результатов через командлет Recieve-PSSession.

Сессии имеют очень много настроек, возможно даже создание сессий с обрезаным набором команд, модулей и т.п. Называется custom endpoints