Установка программ через powershell на удаленном компьютере
Установка программ средствами PowerShell в Windows 10
Несмотря на то, что эта функциональная возможность появилась еще в апреле 2014-го года вместе с выходом Windows Management Framework 5.0 Preview, нативной она смогла стать только с окончательным релизом «десятки». Итак, давайте же посмотрим, какой модуль отвечает за эту функциональную возможность и как можно проинсталлировать программные продукты, не загружая инсталляционные файлы.
Модуль Windows PowerShell OneGet
Еще с выходом Windows Management Framework 5.0 Preview у командной оболочки Windows PowerShell появилось несколько новых возможностей, предназначенных для упрощения управления компьютерами. К таким возможностям относятся две занимательные технологии, а именно: Windows PowerShell Desired State Configuration и Certified for Windows Network Switches.
В случае с технологией Certified for Windows Network Switches – был добавлен ряд командлетов Windows PowerShell, отвечающих за управление сертифицированными для Windows сетевыми коммутаторами. То есть, появилось 19 новых командлетов, которые вы можете найти, выполнив в оболочке PowerShell команду «Get-Command *-NetworkSwitch*». Так как технология достаточно серьезная и заслуживает отдельного внимания, в данной статье я ограничусь лишь небольшим описанием и не буду рассматривать эту технологию более подробно.
А вот на второй технологии следует остановиться подробнее. В случае установки Windows Management Framework 5 или операционной системы Windows 10 вы можете воспользоваться средством, позволяющим существенно упростить на ваших компьютерах поиск и установку программного обеспечения. Таким средством является OneGet. OneGet – это агрегатор управления пакетами, то есть модуль, использующий специальные репозитории, предоставляющий единый интерфейс для обнаружения, установки и инвентаризации программного обеспечения. Иначе говоря, эта технология с одной стороны предоставляет набор командлетов, позволяющих конечному пользователю управлять инсталляционными пакетами (о которых мы с вами будем говорить немного ниже), а с другой стороны она предоставляет интерфейс для написания пакетов поставщиков.
Прежде чем мы с вами начнем разбираться с самим модулем, следует обратить внимание на несколько определений, которые тесно связаны с этой технологией, а именно:
- Пакет. Если говорить в двух словах, то пакет представляет собой программу, которая собирается и устанавливается из определенного источника при помощи любой доступной системой управления пакетами. Как правило, пакет предоставляет собой скомпилированный код, с дополнительной мета информацией, к которой может относиться описание пакета, его версия или «зависимости». Система управления пакетами, например, для выполнения автоматического обновления программного продукта до новой версии, для того чтобы удостовериться в том, что все зависимости пакета будут установлены, должна обработать такую мета информацию и, в случае необходимости, должна автоматически установить все отсутствующие пакеты;
- Репозиторий. Согласно википедии, репозитории представляют собой место, где хранятся и поддерживаются какие-либо данные. Чаще всего данные в репозитории хранятся в виде файлов, доступных для дальнейшего распространения по сети. Изначально репозитории использовались Linux-системами, позволяя устанавливать пакеты, необходимые для работы системы из других расположений. Большинство репозиториев бесплатны, однако некоторые компании предоставляют доступ к собственным репозиториям за платную подписку. О репозиториях OneGet мы с вами поговорим немного ниже;
- Диспетчер пакетов. Представляет собой набор программных инструментов, отвечающий за автоматизацию процесса установки, обновления, настройки и удаления пакетов программного обеспечения. Как правило, пакеты включают в себя базу данных, в которой указываются предварительные требования и зависимости программного обеспечения, а также информацию о версии продукта, предотвращающую использование нерабочих программных продуктов. К диспетчерам пакетов можно отнести линуксовский apt-get или NuGet, который позже появился в Windows-системах. В свою очередь, OnetGet представляет собой логическое продолжение NuGet, работающее в качестве агрегатора для всех доступных диспетчеров пакетов, именуемых поставщиками.
Изначально Microsoft ограничивает использование большинства доступных поставщиков, предоставляя базовый набор, позволяющий обнаружить и установить дополнительные поставщики для управления программным обеспечением. Среди базовых поставщиков можно выделить:
Полный список поставщиков OneGet с их кратким описанием вы можете найти по следующей ссылке.
Далее в этой статье мы будем работать с поставщиком Chocolatey, который позволяет выполнять автоматическую установку большинства программных продуктов.
Сам модуль OneGet включает в себя 10 командлетов Windows PowerShell, большинство которых будут рассмотрены в следующем разделе настоящей статьи. К этим командлетам относятся:
Установка программного обеспечения при помощи OneGet
Вот и настало время самого процесса установки программных продуктов. Далее вы увидите, как можно установить поставщик пакетов, найти требуемое программное обеспечение, установить его, а также как можно удалить ненужное приложение и загрузить себе на компьютер инсталляционный пакет программного продукта. Начнем по порядку.
Установка поставщика пакетов Chocolatey
Теперь мы можем сгенерировать полный список всех доступных в поставщиках пакетов и передать его по конвейеру командлету Export-CliXML для создания XML-представления объектов и их сохранения в XML-файле. Учтите, что экспортируемый вами список будет постоянно меняются и со временем все больше и больше пакетов будут добавляться в используемые вами репозитории. Соответственно, не забывайте время от времени заменять экспортируемый вами файл. Для того чтобы выполнить экспорт списка пакетов и сохранить этот список в папке C:\TestPosh вам нужно выполнить следующую команду: Find-Package | Export-CliXML C:\TestPosh\Test.xml
Учтите, что процедура экспорта обязательно займет у вас какое-то время. После того как команда закончит выполняться и у вас на компьютере будет создан XML файл, импортируйте его и, для удобства просмотра, при помощи конвейера и команды GridView, отвечающей за отображение результатов выполнения команды в окне в виде интерактивной таблицы, можете посмотреть, какие пакеты будут доступны для установки. Естественно, этот список пакетов вы можете открыть при помощи любого приложения, которое способно обрабатывать XML файлы, например, средствами того же Excel. Данная команда, как вы видите на следующей иллюстрации, выглядит следующим образом: Import-CliXML С:\TestPosh\Test.xml | Out-GridView
Рис. 4. Просмотр списка пакетов, доступных для установки.
Так как поставщик уже установлен, можно переходить к следующей части данной процедуры, а именно к
Установке программного обеспечения средствами PowerShell
Прежде чем устанавливать программные продукты нам следует посмотреть, что же уже установлено на компьютере. Для выполнения этой задачи вы можете воспользоваться командлетом Get-Package, который возвращает список всех пакетов программного обеспечения, установленных на локальном компьютере как с помощью OneGet, так и другими средствами инсталляции приложений. При желании вы также можете запускать командлет Get-Package и на удаленных компьютерах, запустив его как часть Invoke-Command, команды Enter-PSSession или скрипта.
В том случае, если вы хотите получить информацию по конкретному программному обеспечению, например, по установленным продуктам Microsoft Office 2013, вы можете наряду с данным командлетом использовать параметр –Name с соответствующим значением, например, Get-Package -Name «office 2013». Выходные данные этого командлета видны ниже:
Рис. 5. Вывод командлета Get-Package.
Перед инсталляцией программного обеспечения попробуем определиться с тем, что же нам нужно установить. Так как на машине установлен только офис 2013 и еще несколько приложений, далее я вам покажу, как можно установить такие программные продукты, как Adobe Creative Cloud, Adobe Reader, Notepad++, а также Process Explorer, Process Monitor и WinRar.
Ввиду того, что до самого процесса инсталляции нам нужно сами пакеты локализовать, следует воспользоваться возможностями командлета Find-Package. Как вы уже заметили немного ранее, данный командлет позволяет выполнять поиск инсталляционных пакетов в доступных на локальном компьютере источниках пакетов. В том случае, если вы не будете использовать с данным командлетом какие-либо параметры, вам будет выведен командой полный список всех приложений, как было заметно ранее.
Например, для начала попробуем найти приложения Adobe, которые доступны для инсталляции из добавленного нами поставщика Chocolatey. Для этого достаточно помимо самого командлета указать параметр –Name и в качестве его значения ввести искомый программный продукт. Так как после слова Adobe у инсталляционных пакетов может быть указано имя продукта, следует ввести имя продукта следующим образом: Adobe*, как показано на следующей иллюстрации. Как вы видите, модуль OneGet обнаружил в репозитории следующий инсталляционный пакет: adobe-creative-cloud версии 1.0. В принципе, это один из искомых продуктов, а это значит, что его следует проинсталлировать. Для этого, как также можно заметить на следующей иллюстрации, нужно воспользоваться возможностями командлета Install-Package. Чтобы установить Creative Cloud выполняется следующая команда Install-Package -Name adobe-creative-cloud –Force, где параметр Force, как принято в PowerShell, переопределяет ограничения, препятствующие выполнению команды до тех пор, пока изменения не начнут нарушать требования безопасности. Выходные данные этих команд можно увидеть на следующей иллюстрации:
Рис. 6. Установка Adobe Creative Studio
Теперь, после того как первый программный продукт был установлен попробуем выполнить поиск определенной версии Adobe Reader. Для этого помимо уже известной команды Find-Package –Name AdobeReader следует добавить параметр –AllVersions, который возвращает все доступные версии пакета, или все версии пакета, которые находятся в диапазоне, указанном в параметрах MinimumVersion и MaximumVersion. Обратите внимание на то, что этот параметр не является обязательным, так как изначально поиск отображает свежайшую версию программного продукта. Теперь из всех доступных версий нам следует выбрать ту, которая должна быть проинсталлирована на компьютере, например, пусть это будет версия 2015.007.20033. для того, чтобы установить именно эту версию ридера, следует для команды Install-Package -Name AdobeReader добавить параметр –RequiredVersion со значением 2015.007.20033, который определяет точную версию пакета, который вы хотите установить. Также вы можете установить максимально доступную версию продукта, добавив параметр MaximumVersion с соответствующим значением. Вывод этих команд виден на следующей иллюстрации:
Рис. 7. Установка программного продукта определенной версии
Если вам нужно установить свежайшую версию программного продукта и в то же время вы не хотите вводить в оболочке PowerShell несколько команд, вы можете обобщить поиск и установку пакета при помощи конвейера. Например, в случае с установкой последней версии текстового редактора Notepad++ вы можете выполнить следующую команду: Find-Package -Name NotepadPlusPlus | Install-Package –Force. Таким образом, вы выполняете поиск пакета в репозитории и в случае нахождения результата сразу инсталлируете его в тихом режиме. Процесс выполнения установки этого программного продукта виден ниже:
Рис. 8. Установка Notepad++
Теперь, так как согласно указанному выше заданию осталось установить еще Process Explorer, Process Monitor и WinRar, попробуем установить сразу несколько программных пакетов. Для этого желательно точно знать, как называются эти пакеты в самом репозитории. Как я уже писал ранее, это можно проверить при помощи командлета Find-Package | Out-GridView. После того как будут известны имена пакетов можно заняться самой установкой. Для этого вы можете выполнить следующую команду: Find-Package -Name procexp, procmon, winrar | Install-Package. В данном примере, как видно на следующей иллюстрации, я специально не указываю параметр Force, чтобы вы могли обратить внимание на весь процесс установки нескольких программных пакетов одновременно.
Рис. 9. Установка нескольких программ одновременно
Сохранение и удаление программ
Последние два командлета, которые будут рассмотрены в этой статье отвечают за сохранение инсталляционного пакета и удаление проинсталлированной программы. Начнем с сохранения.
Для того чтобы сохранить инсталляционный пакет можно воспользоваться очередным командлетом модуля OneGet, а именно модулем Save-Package. Данный командлет позволяет сохранить пакеты на локальном компьютере без их последующей установки. По умолчанию данный командлет сохраняет последнюю версию программного продукта, однако если вы к текущему командлету добавите параметр AllVersions, у вас на компьютере будут сохранены все размещенные в репозитории версии выбранной вами программы. Более того, аналогично параметрам командлетов поиска и установки программ, помимо сохранения всех версий, при помощи параметров -MaximumVersion и –MinimumVersion, вы еще можете выбрать диапазон версий пакета, который желаете сохранить. Чтобы сохранить пакет на своем компьютере, помимо параметра Name и, в случае необходимости, параметра, отвечающего за версию продукта, вы должны указать параметр Path с будущим расположением вашего инсталлятора.
Как видно на следующей иллюстрации, команда Save-Package –Name Procexp –Path C:\TestPosh сохранит последнюю версию Process Explorer в папке C:\TestPosh:
Рис. 10. Сохранение Process Explorer на компьютере
Если вы случайно установили не тот пакет, вы всегда можете при помощи модуля OneGet его удалить. Для этого используется командлет Uninstall-Package. Как и в случае с остальными командлетами данного модуля, для удаления программы вам нужно указать параметр Name с соответствующим именем приложения, а также, для тихого удаления, вы можете использовать параметр Force. Например, чтобы удалить с компьютера установленный ранее WinRAR вам нужно выполнить следующую команду: Uninstall-Package –Name WinRAR –Force, как показано ниже:
Рис. 11. Удаление установленной программы
Заключение
Из этой статьи вы узнали об одной из особенностей новой операционной системы от Microsoft, а именно об инсталляции программных продуктов средствами командной оболочки Windows PowerShell. Я вам рассказал о самом модуле OneGet, об основной терминологии, используемой наряду с этой технологией и о том, какие существуют предустановленные поставщики пакетов. Вы узнали о том, как можно подключить к OneGet сторонний поставщик пакетов и как при его помощи можно находить, устанавливать, сохранять и удалять программные продукты.
Существует довольно много методов для работы с удаленными компьютерами. Есть Windows Management Instrumentation (WMI), широко используемый в VBScript. Есть различные утилиты, которые позволяют осуществлять удаленное управление, типа PSExec от Sysinternals. Даже многие командлеты PowerShell имеют параметр ComputerName для выполнения на удаленных компьютерах.
В отличие от утилит, использующих различные программные интерфейсы, PS Remoting работает следующим образом: команды, вводимые на локальном компьютере, передаются на удаленный компьютер и там выполняются, затем результат передается обратно. Поскольку все команды выполняются локально, нет необходимости заботится о совместимости. Кроме того, для работы PS Remoting нужен всего один открытый порт на брандмауэре.
Есть несколько способов управления с помощью PowerShell Remoting.
Управление «один к одному»
Enter-PSSession -ComputerName SRV4
Restart-Service -Name spooler
Посмотрим состояние сервиса и закроем удаленную сессию:
Get-Service -Name spooler
Exit-PSSession
Интерактивная работа подходит для решения несложных задач удаленного администрирования. Если же надо автоматизировать процесс, то лучше воспользоваться командлетом Invoke-Command . Вот так с его помощью можно сделать то же самое действие:
Invoke-Command -ScriptBlock -ComputerName SRV4
Эта команда откроет удаленную сессию на SRV4, выполнит блок команд, указанный в параметре -ScriptBlock , и закроет сессию. А чтобы задание выполнялось в фоновом режиме, дополнительно можно указать параметр -AsJob .
Cледует помнить о том, что при работе в фоновом режиме PowerShell не возвращает результат. Для его получения придется воспользоваться командлетом Receive-Job .
Для того, чтобы выполнить не пару-тройку команд, а какой либо скрипт, у Invoke-Command есть параметр –FilePath , который можно использовать вместо –ScriptBlock для определения файла сценария. Для примера я создал скрипт, который выводит список остановленных служб и запустил его на удаленной машине SRV4:
Invoke-Command -FilePath .\script.ps1 -ComputerName SRV4
Управление «один ко многим»
Довольно часть возникает необходимость параллельно выполнить одну задачу на нескольких компьютерах. Это довольно легко можно сделать с помощью того же Invoke-Command . Например, имена компьютеров можно просто перечислить через запятую:
Invoke-Command -ScriptBlock -ComputerName SRV4,SRV5
Поместить в переменную:
$servers = @(″SRV1″,″SRV2″,″SRV3″)
Invoke-Command -ScriptBlock -ComputerName $servers
Или взять из файла:
Invoke-Command -ScriptBlock -ComputerName`
(Get-Content .\servers.txt)
Примечание: у Invoke-Command есть параметр ThrottleLimit , ограничивающий максимальное количество компьютеров, которыми можно управлять одновременно. По умолчанию этот параметр равен 32. При необходимости его можно изменить, но учтите, что повышение этого параметра увеличит нагрузку на процессор и память вашего компьютера, поэтому эту операцию нужно выполнять с большой осторожностью.
Сессии
Каждый раз при выполнении Invoke-Command создается новая сессия, на создание которой тратится время и ресурсы. Чтобы этого избежать мы можем открыть одну сессию, в которой и выполнять все команды. Например, откроем сессию с именем SRV4 на компьютер SRV4 и поместим ее в переменную $session, а затем этой сессии выполним нашу задачу (остановим многострадальный spooler):
$session = New-PSSession -ComputerName SRV4 -Name SRV4
Invoke-Command -ScriptBlock `
-Session $session
А теперь несколько интересных возможностей, появившихся в PowerShell 3.0. Если раньше при выходе из сессии или закрытии консоли сессия удалялась, то в PS 3.0 при закрытии сессия переходит в состояние disconnected. Мы можем открыть новый сеанс на этом же (или любом другом) компьютере и выполнить команду прямо в этой отключенной сессии. В качестве примера стартуем на компьютере SRV4 сервис печати, остановленный в прошлый раз:
Invoke-Command -ScriptBlock `
-ComputerName SRV4 -Disconnected
$session = New-PSSession -ComputerName SRV4 -Name LongJob
Invoke-Command -Session $session -ScriptBlock`
> -AsJob
Посмотрим, как выполняется задача и закроем сессию:
Receive-Job -Name Job2
Disconnect-PSSession $session
Идем на другой компьютер и открываем консоль, Подключаемся к сессии LongJob и с помощью командлета Receive-PSSession получаем результат выполнения задания:
Connect-PSSession -Name LongJob -ComputerName SRV4
Receive-PSSession -Name LongJob
Или еще вариант, без явного подключения к сессии с помощью Connect-PSSession :
$session = Get-PSSession -Name LongJob -ComputerName SRV4
$job = Receive-PSSession $session -OutTarget Job
Receive-Job $job
Примечание: для того, чтобы результат остался в системе, Receive-Job надо использовать с параметром -Keep .
Неявное удаленное управление
Для примера берем обычную рабочую станцию, без установленных средств удаленного администрирования. Создаем удаленную сессию с контроллером домена SRV4 и импортируем в эту сессию модуль Active Directory:
$session = New-PSSession -ComputerName SRV4
Invoke-Command -Session $session
Затем экспортируем из удаленной сессии командлеты Active Directory и помещаем их в локальный модуль RemoteAD:
Export-PSSession -Session $session -CommandName *-AD* -OutputModule RemoteAD`
-AllowClobber
Эта команда создаст в папке WindowsPowerShell\Modules\RemoteAD новый модуль PowerShell. Загружены будут только командлеты с именами, соответствующими шаблону *-AD*. При этом сами командлеты не копируются на локальный компьютер. Локальный модуль служит своего рода ярлыком, а сами команды будут выполняться на удаленном контроллере домена.
После создания модуля удаленную сессию можно закрыть, она больше не понадобится.
Импортируем новый модуль в текущий сеанс (в PS 3.0 можно этот шаг пропустить):
New-ADUser -Name BillGates -Company Microsoft
Get-ADUser BillGates
При этом будет восстановлено удаленное подключение к контроллеру домена, после чего команда будет передана на контроллер домена и там выполнена. Результат выполнения будет сериализован в XML и передан по сети на локальный компьютер, где будет выполнена десериализация в объекты, с которыми может работать PowerShell.
Удаленный сеанс будет активным до тех пор, пока вы не закроете консоль или не удалите модуль RemoteAD.
Неявное удаленное управление позволяет работать с командлетами на удаленном компьютере практически так же, как если бы они были установлены на локальной машине. При этом все необходимые командлеты всегда под рукой, что довольно удобно.
В заключение скажу, что на данный момент PowerShell Remoting является основным инструментом для удаленного управления операционными системами Windows. Поэтому знать о его возможностях и уметь ими пользоваться просто необходимо любому Windows-администратору.
Доступ к приложениям, использующим установщик Windows, можно получить в классе Win32_Product WMI, но не все современные приложения используют установщик Windows. Установщик Windows обычно не управляет приложениями, использующими другие процедуры установки. Конкретные техники работы с этими приложениями зависят от программного обеспечения установщика и решений, принятых разработчиком приложения. Например, для управления приложениями, установленными путем копирования файлов в папку на компьютере, обычно не используются описанные здесь методы. Вы можете управлять этими приложениями, как файлами и папками, с помощью способов, приведенных в статье Работа с файлами и папками.
Класс Win32_Product не оптимизирован для запросов. Если выполняются запросы, использующие фильтры с подстановочными знаками, то WMI будет использовать поставщика MSI для перечисления всех установленных продуктов, а затем последовательно проанализирует весь список с применением фильтра. При этом также инициируется проверка согласованности установленных пакетов для проверки и исправления установки. Проверка выполняется медленно и может привести к ошибкам в журнале событий. Подробные сведения см. в статье базы знаний 974524.
Создание списков приложений установщика Windows
Чтобы создать список приложений, установленных с помощью установщика Windows в локальной или удаленной системе, используйте следующий простой запрос WMI:
Чтобы отобразить все свойства объекта Win32_Product, используйте параметр Properties командлетов форматирования, например Format-List со значением * (все).
Чтобы получить список только интересующих вас свойств, используйте параметр Property командлетов форматирования.
Создание списка всех удаленных приложений
Так как большинство стандартных приложений регистрируют программу удаления в Windows, с ними можно работать локально, в реестре Windows. Не существует гарантированного способа найти все приложения в системе. Но можно найти все программы в списках, отображаемых в окне Установка и удаление программ в следующем разделе реестра:
В этом разделе можно найти приложения. Чтобы упростить просмотр раздела Uninstall, можно сопоставить диск PowerShell с таким путем реестра:
Теперь диск с именем "Uninstall" можно использовать для быстрого и удобного поиска установок приложений. Количество установленных приложений можно найти, подсчитав количество разделов реестра в разделе "Удаление": Диск PowerShell:
С помощью разных методов, начиная с Get-ChildItem , можно дальше выполнять поиск в списке приложений. Чтобы получить список приложений и сохранить их в переменную $UninstallableApplications , используйте следующую команду:
Чтобы отобразить значения записей реестра в подразделах реестра раздела "Удаление", используйте метод GetValue. Значение метода является записью реестра.
Например, чтобы найти отображаемые имена приложений в разделе "Удаление", используйте следующую команду:
Нет никакой гарантии, что значения DisplayName уникальны.
Установка приложений
Вы можете использовать класс Win32_Product для удаленной или локальной установки пакетов установщика Windows.
Чтобы установить приложение, запустите PowerShell, используя параметр "Запуск от имени администратора".
Если установка выполняется удаленно, используйте сетевой UNC-путь, чтобы указать путь к пакету MSI, так как подсистема WMI не распознает пути PowerShell. Например, чтобы установить пакет NewPackage.msi, расположенный в сетевой папке \\AppServ\dsp на удаленном компьютере PC01, введите следующую команду в командной строке PowerShell:
Приложения, которые не используют метод установщика Windows, могут включать специальные методы для автоматического развертывания конкретного приложения. Изучите документацию по приложению или обратитесь в службу поддержки поставщика приложения.
Удаление приложений
Удаление пакета установщика Windows с помощью PowerShell работает примерно так же, как и установка пакета. Далее представлен пример, в котором пакет для удаления выбирается на основе имени. В некоторых случаях его может быть проще отфильтровать с помощью IdentifyingNumber:
Удаление других приложений не так просто, даже если оно выполняется локально. Строки удаления командной строки для этих приложений можно найти путем извлечения свойства UninstallString. Этот способ работает для приложений установщика Windows и более старых программ, отображающихся в разделе "Удаление":
Выходные данные при необходимости можно отфильтровать по отображаемому имени:
Возможно, что эти строки нельзя будет напрямую использовать из командной строки PowerShell без внесения некоторых изменений.
Обновление приложений установщика Windows
Чтобы обновить приложение, необходимо знать название приложения и путь к пакету обновлений приложения. Получив эти сведения, вы можете обновить приложение с помощью одной команды PowerShell:
В этой статье мы рассмотрим особенности использования командлета Invoke-Command для удаленного выполнения команд и скриптов. Возможно запускать команды удаленно на одном компьютере, или параллельно на множестве компьютерах в вашей сети. Командлет Invoke-Command использует возможности удаленного управления, заложенные в PowerShell Remoting. PowerShell Remoting позволяет удаленно подключаться к PowerShell сессиям на компьютерах через службу WinRM (Windows Remote Management) через протокол Web Services for Management (WS-Management). Этот сервис дает возможность принимать команды Powershell и устанавливать сеансы.
Настройка WinRM для PowerShell Remoting
На удаленных компьютерах, к которым вы планируете подключаться должен быть запущена служба WinRM. Проверить это можно так:
Если служба не запущена, запустите ее:
Данная команда запустит службу WinRM (установит автоматический запуск), выставит настройки winrm по-умолчанию и добавит исключение в Windows Firewall. Команда Enable-PSRemoting –Force включает WinRM без запроса пользователя.
Теперь к компьютеру можно подключиться удаленно через PowerShell Remoting.
Обратите внимание, что PowerShell Remoting по-умолчанию не работает, если тип вашей сети определен как общедоступная (Public). В этом случае команда вернет ошибку:Также нужно включить правило Window Defender Firewall, которое разрешает доступ к WinRM в общедоступных сетях. Вы можете включить правило брандмауэра с помощью GPO или PowerShell:
Чтобы проверить подключение к удаленному компьютер через PowerShell Remoting используется команда:
Если у вас нет домена, или вы обращаетесь к компьютерам через PowerShell Remoting по IP адресам, в этом случае используется для аутентификации используется протокол NTLM. При использовании NTLM, при выполнении команду Invoke-Command появится ошибка:
Set-Item wsman:\localhost\Client\TrustedHosts -value 192.168.1.201
Либо можно разрешить подключение ко все компьютерам (не рекомендуется, т.к. один из главных недостатков NTLM – он не осуществляет проверку подлинности).
Set-Item wsman:\localhost\Client\TrustedHosts -value *
Аналогичные настройки нужно сделать на удаленных хостах.
Чтобы вывести список доверенных хостов, выполните команду:
Чтобы применить изменения, перезапустите службу WinRM:
Удаленное выполнение PowerShell с помощью Invoke-Command
Командлет Invoke-Command позволяет выполнить команду на одном или нескольких удаленных компьютерах.
Например, для запуска одиночной команды на удаленном компьютере можно использовать такую команду:
Invoke-Command -ComputerName dc01 -ScriptBlock
Эта команда выведет в вашу консоль значение версии PowerShell, установленной на удаленном компьютере, имя которого указано в параметре -ComputerName . В блоке -ScriptBlock указывается команда, которую нужно запусть на удаленном компьютере.
По-умолчанию команда, посланная через Invoke-Command выполняется на удалённом компьютере от текущего пользователя. Если нужно выполнить команду от имени другого пользователя, сначала нужно запросить учетные данные пользователя и сохранить их в переменную:
$cred = Get-Credential
Invoke-Command -ComputerName comp-buh2 -Credential $cred -ScriptBlock
Можно задать несколько команд в блоке ScriptBlock, их нужно разделить точкой с запятой. Например следующая команда выведет текущий часовой пояс и изменит его на другой:
Invoke-Command -Computername dc01 -ScriptBlock
Invoke-Command позволяет выполнять не только отдельные команды, но и запускать скрипты PowerShell. Для этого используется аргумент -FilePath (вместо –ScriptBlock). При этом вы указываете путь к локальному PS1 файлу скрипта на вашем компьютере (вам не нужно копировать файл скрипт на удаленный компьютер):
Invoke-Command -ComputerName Server01 -FilePath c:\PS\Scripts\GetComputerInfo.ps1
Используем Invoke-Command для параллельного запуска команд на нескольких компьютерах
Командлет Invoke-Command можно использовать для параллельного выполнения команд на нескольких удаленных компьютерах.
В самом просто случае имена компьютеров, на которых нужно выполнить команды указываются через запятую:
Invoke-Command server1, server2, server3 -ScriptBlock
Список компьютеров можно поместить в переменную (массив):
$servers = @(″server1″,″server2″,″server3″)
Invoke-Command -ScriptBlock < get-date>-ComputerName $servers
Или получить из текстового файла:
Invoke-Command -ScriptBlock -ComputerName(Get-Content c:\ps\servers.txt)
Также можно получить список компьютеров в ADс помощью командлета Get-ADComputer из модуля AD PowerShell:
Чтобы выполнить команду на всех Windows Server в домене, исопльзуйте такой код:
$computers = (Get-ADComputer -Filter 'operatingsystem -like "*Windows server*" -and enabled -eq "true"').Name
Invoke-Command -ComputerName $computers -ScriptBlock -ErrorAction SilentlyContinue
Если компьютер выключен, или недоступен, благодаря параметру SilentlyContinue скрипт не будет остановлен и продолжит выполнение на других компьютерах.
Чтобы понять с какого компьютера получены результаты, нужно использовать специальную переменную окружения PSComputerName.
$results = Invoke-Command server1, server2, server3 -ScriptBlock
$results | Select-Object PSComputerName, DateTime
При запуске команды через Invoke-Command на нескольких компьютерах она выполняется параллельно. В Invoke-Command есть ограничение на максимальное количество компьютеров, которыми можно управлять одновременно (ограничение на количество одновременных PSSession). Оно определяется параметром ThrottleLimit (по умолчанию 32). Если вам нужно выполнить команду одновременно более чем на 32 компьютерах (например, на 128), используйте параметр –ThrottleLimit 128 (но это вызывает повышенную нагрузку на ваш компьютер).
Для запуска команд на удаленных компьютерах через Invoke-Command в фоновом режиме используется специальный атрибут –AsJob . В этом случае результат выполнения команды не возвращается в консоль. Чтобы получить результаты нужно использовать командлет Receive-Job .
Если вы хотите запускать команды на удаленном компьютере интерактивно, используйте командлет Enter-PSSession.
В Powershell есть несколько методов удаленного подключения. Это через:
Сегодня мы поговорим о PS remoting/WinRM. В его состав входит, в основном, два командлета - это:
Этот командлет устанавливает сессию c удаленным компьютером и мы сможем работать прям на нем. Если сравнивать с Linux, то это почти одно и то же:
И второй командлет, который нужен для удаленного выполнения команд как на одном, так и сотни компьютеров:
Где:
-ComputerName - имена компьютеров (или одного)
-Scriptblock - скрипт или командлет в скобках <>
Если опять же сравнить с Linux ssh, то это почти одно и то же:
Как настроить удаленное управление через Powershell?
Если у вас не работают команды выше нужно проверить запущен ли сервис WinRM на том компьютере, к которому мы хотим подключиться:
Если не запушен:
В этом случае мы ставим запуск сервиса автоматически и настраиваем winrm в дефолтной конфигурации. Этот сервис дает возможность принимать команды Powershell и устанавливать сеансы.
Если вы работаете под профилем сети "Public" (не "Domain" или "Private"), то нужно выполнить еще один командлет, разрешающий работать в таких сетях:
Если мы выполним такую команду:
После этого все будет работать, но команды должны исполняться с переменной, в которой будут лежать учетные данные пользователя. Т.е. так:
Где:
$cred - это переменная, куда мы сохраняем данные с формы Get-Credential
-Credential - сюда мы передаем переменную
Так же отмечу, что все команды, которые мы запускаем для удаленного выполнения через Poweshell, должны происходить от члена группы Администратора того хоста, к которому мы подключаемся.
Теперь мы можем устанавливать множество сессий с помощью командлета:
Получать ID этих сессий:
И подключаться по этим ID:
Или использовать с invoke существующую сессию, а командлет для удаленного компьютера запускать с файла:
А так же, т.к. WinRM настроен, выполнять командлеты где есть ключ -ComputerName, сразу на нескольких компьютерах. Этот командлет пропингует AD сразу с нескольких компьютеров:
Читайте также: