Обновить powershell на удаленном компьютере
Существует довольно много методов для работы с удаленными компьютерами. Есть 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-администратору.
В PowerShell доступно множество различных способов выполнения команд на удаленных компьютерах. В последней главе вы узнали, как удаленно запрашивать WMI с помощью командлетов CIM. PowerShell также содержит несколько командлетов со встроенным параметром ComputerName.
Как показано в следующем примере, Get-Command можно использовать с параметром ParameterName, чтобы определить, какие команды имеют параметр ComputerName.
Параметр ComputerName есть у команд Get-Process и Get-Hotfix . Следует отметить, что для корпорации Майкрософт это не то долгосрочное направление, которого следует придерживаться для выполнения команд на удаленных компьютерах. Даже если вы нашли команду с параметром ComputerName, скорее всего, вам потребуется указать альтернативные учетные данные и у команды не будет параметра Credential. Если вы решили запустить PowerShell из учетной записи с повышенными привилегиями, брандмауэр между вами и удаленным компьютером может заблокировать запрос.
Чтобы использовать команды удаленного взаимодействия PowerShell, которые демонстрируются в этой главе, необходимо включить удаленное взаимодействие PowerShell на удаленном компьютере. Это можно сделать с помощью командлета Enable-PSRemoting .
Удаленное взаимодействие "один к одному"
Если вы хотите, чтобы удаленный сеанс был интерактивным, то в этом случае подойдет удаленное взаимодействие "один к одному". Этот тип удаленного взаимодействия предоставляется с помощью командлета Enter-PSSession .
В последней главе учетные данные администратора домена были сохранены в переменной с именем $Cred . Если вы еще не сделали этого, сохраните учетные данные администратора домена в переменной $Cred .
После этого вы сможете ввести учетные данные один раз и использовать их для каждой команды в активном текущем сеансе PowerShell.
Создайте сеанс удаленного взаимодействия PowerShell "один к одному" с контроллером домена DC01.
Обратите внимание, что в предыдущем примере перед запросом PowerShell стоит [dc01] . Это означает, что вы находитесь в интерактивном сеансе PowerShell с удаленным компьютером dc01. Все запускаемые команды выполняются на компьютере dc01, а не на локальном компьютере. Кроме того, помните, что у вас есть доступ только к командам PowerShell, которые существуют на удаленном, а не на локальном компьютере. Иными словами, если на компьютере установлены дополнительные модули, они недоступны на удаленном компьютере.
При подключении к удаленному компьютеру в рамках интерактивного сеанса удаленного взаимодействия PowerShell "один к одному" вы фактически находитесь на удаленном компьютере. Все объекты являются обычными объектами, аналогичными тем, с которыми вы уже работали.
Завершив работу на удаленном компьютере, выйдите из сеанса удаленного взаимодействия "один к одному" с помощью командлета Exit-PSSession .
<a name="one-to-many-remoting">Удаленное взаимодействие "один ко многим"
Иногда может потребоваться выполнить задачу в интерактивном режиме на удаленном компьютере. Удаленное взаимодействие гораздо более эффективно при выполнении задачи на нескольких удаленных компьютерах одновременно. С помощью командлета Invoke-Command выполните команду на одном удаленном компьютере или нескольких одновременно.
В предыдущем примере на три сервера были отправлены запросы состояния службы времени Windows. Командлет Get-Service был помещен в блок сценария Invoke-Command . На самом деле сценарий Get-Service выполняется на удаленном компьютере и результаты возвращаются на локальный компьютер в виде десериализованных объектов.
Передача предыдущей команды в Get-Member подтверждает, что результаты действительно десериализованы.
Обратите внимание, что в десериализованных объектах отсутствует большинство методов. Это значит, что они не являются активными объектами, они инертны. Нельзя запускать или останавливать службу с помощью десериализованного объекта, так как он является моментальным снимком состояния этого объекта на момент выполнения команды на удаленном компьютере.
Это не значит, что вы не можете запускать или прекращать работу службы с помощью метода Invoke-Command . Это просто значит, что метод должен быть вызван в удаленном сеансе.
Чтобы доказать это, далее я остановлю службу времени Windows на всех трех удаленных серверах с помощью метода Stop() .
Как отмечалось в предыдущей главе, если для выполнения задачи существует командлет, рекомендуется использовать его, а не метод. В предыдущем сценарии вместо метода остановки советую выполнить командлет Stop-Service . Чтобы доказать свою точку зрения, я решил использовать метод Stop() , так как многие люди ошибочно полагают, что в рамках удаленного взаимодействия PowerShell вызывать методы невозможно. Их нельзя вызывать в возвращаемом объекте, потому что он десериализован, но можно вызывать в самом удаленном сеансе.
Сеансы PowerShell
В последнем примере в предыдущем разделе выполнялись две команды с помощью командлета Invoke-Command . Это означает, что для их запуска прошлось бы настроить два отдельных сеанса.
Подобно сеансам CIM, обсуждаемым в главе 7, сеанс PowerShell на удаленном компьютере можно использовать для запуска нескольких команд на удаленном компьютере без дополнительных затрат на создание нового сеанса для каждой отдельной команды.
Создайте сеанс PowerShell с каждым из трех компьютеров, с которыми мы работали в этой главе, — DC01, SQL02 и WEB01.
С помощью переменной $Session запустите службу времени Windows с использованием метода и проверьте состояние службы.
После создания сеанса с использованием альтернативных учетных данных указывать учетные данные при каждом выполнении команды не требуется.
Завершив работу с сеансами, не забудьте удалить их.
Сводка
В этой главе вы узнали об удаленном взаимодействии PowerShell, научились выполнять команды в интерактивном сеансе с одним удаленным компьютером и поняли, как выполнять команды на нескольких компьютерах с помощью удаленного взаимодействия "один ко многим". Вы также узнали о преимуществах использования сеанса PowerShell при выполнении нескольких команд на одном удаленном компьютере.
Для обновления политик Active Directory, вместо команды CMD gpudate, в Powershell используется Invoke-GPUpdate. В этом статье будут рассмотрены примеры обновления политик как для всего AD, так и для отдельной OU.
Сама команда идет в комплекте с ролью AD или установленным RSAT.
Навигация по посту
Обновление GPO на одном компьютере
Для работы этой команды, а так же большинства других с возможностью удаленного подключения, должен работать PSRemoting.
По умолчанию эта команда не применяет новые политики моментально, а делает это с определенным интервалом. Что бы избежать этого нужно указать параметр:
- RandomDelayInMinutes - где значение 0 обозначает "моментальное обновление". Кроме этого можно указать значение в минутах, которое будет определять время обновления политик после запуска команды.
В документации Microsoft написано, что для значений больших чем 0 так же применяется "случайное смещение", но как оно вычисляется мне выяснить не удалось. Такой подход используется, если вы ожидаете какую-то большую нагрузку на сеть или сервер.
В этом примере политики будут применены моментально:
При этом у пользователей появится следующее окно, которое нельзя никак скрыть:
Как и с gpupdate в CMD мы можем указать источник применения политики в Target:
- User - обновить GPO предназначенные для пользователя;
- Computer - обновить GPO для компьютера.
Сами политики могут не применяться, например, до повторного входа пользователя или перезагрузки. Если такие действия необходимы можно использовать следующие ключи:
- Boot - компьютер будет перезагружен после того, как политика будет скачена;
- LogOff - после применения политики пользователю выйдет из под своей учетной записи для повторного входа.
Пример работы с обоими ключами:
Force исключает ситуацию, где у пользователя будет запрошено подтверждение на какое-то действия (на выход например). Окно с примером, где этого ключа не было:
Возможные проблемы
Некоторые GPO так и не вступили в действие при использовании ключей Boot и LogOff. Просто отображалось окно аналогичное показанному на изображении выше. После закрытия окна перезагрузка или выход пользователя тоже не произошел.
Команда Boot не перезагружает компьютер, а только выбрасывает пользователя для повторного входа. Возможно это связано с самой политикой, так как она не требовала перезагрузку.
Так же читал про проблемы, которые связаны с отсутствием или использованием старой версии RSAT. Об этом говорят следующие ошибки:
Получение списка компьютеров с Get-ADComputer в Powershell
Обновление с использованием AD
Имя каждого компьютера можно найти через следующий запрос:
Обновление политик можно сделать через конвейер следующим образом:
Ключ -ErrorAction SilentlyContinue позволяет исключить вывод ошибок, которые связаны с выключенными компьютерами.
Если компьютеров в AD много и вам важна скорость обновления - лучше использовать циклы с задержкой:
Что дает обновление версии PowerShell ?
Компания Microsoft вкладывает огромные силы для развития и поддержки своего продукта по управлению всем, что только можно в мире Windows. Поэтому, чтобы иметь возможность делать работу по автоматизации быстрее, лучше и профессиональнее, необходимо всегда следить за последними версиями командлетов и их ключами, так как от этого зависит их функционал. Каждый новый релиз PowerShell, это по сути как переход с одной операционной системы на другую, более продвинутую и лучшую. С каждой новой версией появляются десятки, а то и сотни новых командлетов для различных сценариев.
Алгоритм обновления версии PowerShell
Хочу отметить, что алгоритм обновления будет одинаков для всех версий Windows начиная с 7 SP1, если у вас ниже, то установите сервисный пакет Service Pack 1 на семерку и двигайтесь дальше.
В моем примере я буду обновлять PowerShell в Windows 7 SP1. Моя текущая версия 2.0.
Данный пакет подойдет:
- Windows 7 с пакетом обновления 1 (SP1) (x86 и x64) (x86 и x64)
- Юбилейное обновление Windows 10 (x86 и x64)
- Windows Server 2008 R2 с пакетом обновления 1 (SP1) (x64)
- Windows Server 2012 (x64) (x64)
- Windows Server 2016 (x64)
Так же советую вам произвести установку всех доступных обновлений, которые есть у вас в операционной системе, а так же убедиться, что вы получаете и дополнительные обновления. Для этого в перейдите по пути "Панель управления\Все элементы панели управления\Центр обновления Windows\Настройка параметров". Убедитесь, что у вас установлены галки:
В Windows 10, данный пункт можно найти по пути "Параметры Windows - Обновление и безопасность - Центр обновления Windows - Дополнительные параметры"
Далее, когда все обновления у вас установлены, вы можете скачивать автономный пакет PowerShell 5.1, пройдите по ссылке:
Нажимаем кнопку "Download".
У вас появится всплывающее окно, где вас попросят выбрать для какой операционной системы вы хотите скачать пакет, по первому названию цифр понятно, для какой версии пакет, так же обратите внимание на разрядность x86 и x64. В моем случае Windows 7 64-х битная. Для обновления версии PowerShell запускаем соответствующий автономный пакет обновления Windows. У меня это Win7AndW2K8R2-KB3191566-x64.zip, единственное вам нужно его распаковать. Запустив пакет, он проверит нет ли уже данного обновления или более свежего.
Так как пакета в Windows 7 не оказалось, то вам предлагают установить KB3191566, соглашаемся.
Принимаем лицензионное соглашение.
Установка пакета с PowerShell 5.1 занимает пару минут.
После чего потребуется обязательная перезагрузка вашей системы.
После перезагрузки, открыв оболочку PowerShell и выполнив команду Get-Host вы видите, что версия PowerShell 2 превратилась в 5.1.14409.1005
Так же вы наверняка обратили внимание, что совместно с пакетом обновления в архиве лежит скрипт Install-WMF5.1.ps1. В задачи данного скрипта входит проверка вашей текущей версии и поиск зависимостей в виде пакетов .NET Framework. Если их не будет, то вас об этом уведомят. Так, что можете смело щелкать правым кликом по скрипту и так же выполнять его. Если у вас в системе не разрешено выполнение неподписанных цифровой подписью сценариев, то вы увидите ошибку "Выполнение скриптов запрещено", как это обходить посмотрите по ссылке, там я приводил команду Set-ExecutionPolicy remotesigned.
Так же может выскочить уведомление, что запрещено изменять раздел реестра, это из-за того, что оболочка PowerShell запущена не из под админана. Запустите ее в режиме администратора.
После чего скрипт у вас успешно отработает.
Установка Windows Management Framework and PowerShell 5.1.14409.20180811 через репозиторий choco
Есть такой офигенный репозиторий choco, который позволяет одной командой всегда иметь самые последние официальные версии продуктов и утилит, и PowerShell тут не исключение. Как подключать в Windows репозиторий choco я рассказывал, можете посмотреть. Когда он у вас есть вы открываете командную строку cmd , обязательно от имени администратора и вводите команду:
Вот так вот просто. В итоге запуститься удаленный скрипт из репозитория, вам покажут какая версия PowerShell самая последняя и спросят, хотите ли вы ее установить, нажимаете Y и тут начинается магия автоматической установки со всеми зависимостями и пакетами KB обновлений.
Осталось перезагрузить вашу систему и проверить новую, установленную версию PowerShell.
Читайте также: