Для установки ролей и компонентов в Powershell есть 3 основные команды Install-WindowsFeature, Enable-WindowsOptionalFeature и Add-WindowsCapability. Каждая из этих команд имеет свое применение и может отличаться в разных релизах Windows. В этой статье будет рассмотрен процесс установки ролей и компонентов используя обе команды на примерах.
Навигация по посту
- Типы команд устанавливающие роли с Powershell
- Получение списка ролей и их установка с Powershell Install-WindowsFeature
- Установка компонентов с Enable-WindowsOptionalFeature и их получение
- Установка компонентов с Add-WindowsCapability
Типы команд устанавливающие роли с Powershell
В Windows есть множество команд, с помощью которых можно установить роль или компонент. Если учесть все команды, которые можно использовать в Powershell — получится следующий список:
- Add-WindowsCapability;
- Enable-WindowsOptionalFeature;
- Install-WindowsFeature;
- Add-WindowsFeature;
- dism.exe;
- pkgmgr.exe.
Командлеты, которые относятся только к Powershell разделяются на 3 типа:
- WindowsFeature — относится к модулю ServerManager. Имеет возможности относящиеся только Windows Server и установке и удалению ролей и компонентов;
- WindowsOptionalFeature — относится к модулю DISM, который наследует функционал аналогичной cmd утилиты. Основное предназначение — работа с компонентами Windows. Компоненты доступные через эти команды можно увидеть в GUI «Включение или отключение компонентов Windows». Это старый функционал и его компоненты переезжают в интерфейс Windows 10;
- WindowsCapability — так же относятся к DISM. Команда, которая постепенно заменяет ‘WindowsOptionalFeature’. Имеет возможность установки компонентов из Windows Update. Если какие-то компоненты не получается найти через предыдущую команду, используйте эту.
Вывести все командлеты можно посмотреть так:
Get-Command -Noun ‘WindowsFeature’ Get-Command -Noun ‘WindowsOptionalFeature’ Get-Command -Noun ‘WindowsCapability’
Если вы пользуетесь старыми версиями ОС, то какие-то модули могут быть не доступны. 2019 сервер одинаков с 2016:
Буква А обозначает алиас. Add-WindowsFeature, в 2016+ эта та же команда, что и Install-WondowsFeature.
Сама установка ролей не обозначает и ее настройку. После установки, обычно, появляется множество команд для настройки роли.
Получение списка ролей и их установка с Powershell Install-WindowsFeature
Что бы получить список ролей можно использовать Get-WindowsFeature. Эта команда, как и все ‘WindowsFeature’, может работать локально и удаленно. По умолчанию она возвращает роли и компоненты. Несколько примеров выполнения командлета:
# получаем список всех ролей Get-WindowsFeature # получаем список только установленных ролей Get-WindowsFeature | where Installed -eq $True # вывод подробной информации о роли на примере Active Directory Get-WindowsFeature -Name ‘AD-Domain-Services’ | select * # вывод ролей с удаленного компьютера Get-WindowsFeature -ComputerName ‘localhost’ # получение списка компонентов (Features) Get-WindowsFeature | where FeatureType -eq ‘Feature’ # получение только ролей (roles) Get-WindowsFeature | where FeatureType -eq ‘Role’ # получаем роли содержащие AD в названии Get-WindowsFeature -Name ‘*AD*’
Имена для установки роли берутся из колонки ‘Name’. Если вы до сих пор плохо понимаете что именно получает и устанавливает эта команда — откройте ‘Server Manager’ на ‘Windows Server’ и посмотрите меню установки:
Сам пакет WindowsFeature (модуль ServerManager) может быть установлен на Windows 10 с RSAT.
Базовая установка роли, но не совсем верная, на примере Active Directory Domain Services, будет следующей:
Install-WindowsFeature -Name ‘AD-Domain-Services’
Перед использованием командлета обратите внимание на 2 параметра, которые вы можете указать:
- IncludeManagementTools — добавляет к установке модули Powershell и панели администрирования;
- IncludeAllSubFeature — подразумевает, что вы устанавливаете не одну роль, а всю вложенную ветку.
Если вы забудете указать параметры указанные выше, то команду можно будет выполнить повторно с их включением.
Так же доступны следующие параметры:
- LogPath — путь до файла, в который вы хотите сохранить лог установки;
- Restart — перезагрузить компьютер если это понадобится после установки;
- Source — внешний источник для установки роли;
- Vhd — установка на vhd диск;
- ConfigurationFilePath — перед установкой роли в Server Manager он предлагает сохранить конфигурацию. Это конфигурацию можно использовать здесь.
Если бы я устанавливал Active Directory на обычный GUI сервер, удаленно, то это бы выглядело так:
Install-WindowsFeature -Name ‘AD-Domain-Services’ -ComputerName ‘AD1’ -IncludeManagementTools -LogPath ‘C:ad1.log’
Если удаленный сервер работает под другими учетными данными, то передать их можно использовав команду ‘Get-Credential’. В ‘ComputerName’ можно указывать как DNS имя, так и IP адрес.
Пример установки нескольких ролей подряд, удаленно и под другими учетными данными:
$cred = Get-Credential ‘XPS-Viewer’, ‘AD-Domain-Services’ | Install-WindowsFeature -ComputerName ‘AD1’ -IncludeManagementTools -Credential $cred
Удалить роль можно так:
Uninstall-WindowsFeature -Name ‘DNS’ -IncludeManagementTools ‘DNS’, ‘AD-Domain-Services’ | Uninstall-WindowsFeature -IncludeManagementTools
Если добавить параметр ‘Remove’, то роль будет удалена еще и с папки ‘WinSxS’. Остальные параметры аналогичны.
Установка компонентов с Enable-WindowsOptionalFeature
Список компонентов, с которыми можно работать команда группы ‘WindowsOptionalFeature’ аналогичны следующем окну:
Учитывая, что это окно уже является наследием более старых систем (до Windows 10), вы можете не найти все компоненты. Например RSAT, который раньше можно было найти в этом окне, теперь доступен через интерфейс ‘Приложения и возможности’ Windows 10. Команды в этих случаях тоже отличаются.
Для получения всех компонентов нужно выполнить следующую команду:
Get-WindowsOptionalFeature -Online
Параметр ‘-Online’ говорит, что пакеты будут искаться на этом же компьютере. Можно поставить ‘-Path’, с указанием пути до образа Windows, что бы увидеть какие компоненты доступны там.
Несколько вариантов выполнения команды:
# получение списка всех включенных компонентов Get-WindowsOptionalFeature -Online | where state -eq ‘Enabled’ # получаем компоненты в которых встречается ‘hyper’ Get-WindowsOptionalFeature -Online -FeatureName ‘*hyper*’
Учитывая, что команды относятся к модулю ‘DISM’, мы можем работать с образами используя параметры ‘PackagePath’ и ‘Path’. Такая возможность есть во всех командах ‘WindowsOptionalFeature’.
Для того, что бы включить компонент нужно выполнить следующую команду:
Enable-WindowsOptionalFeature -FeatureName «TelnetClient» -Online
В следующей команде указано, что нам нужно собрать все логи (а не только ошибки) и сохранить их по указанному пути:
Enable-WindowsOptionalFeature -FeatureName «TelnetClient» -Online -LogLevel ‘WarningsInfo’ -LogPath ‘C:feature.log’
Отключение приложения выполняется следующим образом:
Disable-WindowsOptionalFeature -FeatureName «TelnetClient» -Online
WindowsOptionalFeature так же используется для подготовки Nano сервера т.к. там нет WindowsFeature и пакеты с ролями сначала импортируются, а затем включаются.
Установка компонентов с Add-WindowsCapability
В предыдущем разделе было упомянуто о переезде многих компонентов в интерфейс Windows 10. Командлеты ‘WindowsCapability’ работают именно с ними. Если мы выполним следующую команду, которая очень похожа на предыдущую, то мы увидим совершенно разные пакеты:
Get-WindowsCapability -Online
Эти компоненты соответствуют следующему окну в Windows 10:
Некоторый варианта выполнения программы:
# получение списка всех установленных компонентов Get-WindowsCapability -Online | where State -eq ‘Installed’ # получаем компоненты в которых встречается ‘RSAT’ Get-WindowsCapability -Online -FeatureName ‘*RSAT*’
В отличие от предыдущей команды — эта программа может устанавливать компоненты из Windows Update. Поэтому в ней можно увидеть значения ‘DownloadSize’ и ‘InstallSize’. В остальном это одинаковые команды.
Add-WindowsCapability -Name ‘Rsat.WSUS.Tools~~~~0.0.1.0’ -Online
Remove-WindowsCapability -Name ‘Rsat.WSUS.Tools~~~~0.0.1.0’ -Online
Источник: fixmypc.ru
PowerShell: используем Invoke-Command для запуска команд/скриптов на удаленных компьютерах
В этой статье мы рассмотрим особенности использования командлета Invoke-Command для удаленного выполнения команд и скриптов. Возможно запускать команды удаленно на одном компьютере, или параллельно на множестве компьютерах в вашей сети. Командлет Invoke-Command использует возможности удаленного управления, заложенные в PowerShell Remoting. PowerShell Remoting позволяет удаленно подключаться к PowerShell сессиям на компьютерах через службу WinRM (Windows Remote Management) через протокол Web Services for Management (WS-Management). Этот сервис дает возможность принимать команды Powershell и устанавливать сеансы.
Настройка WinRM для PowerShell Remoting
Для связи между компьютерами в PowerShell Remoting используется протокол HTTP (порт TCP/5985) или HTTPS (порт TCP/5986). По умолчанию используется протокол HTTP, но даже этот трафик шифруется с помощью ключа AES-256 (впрочем, есть угроза атак man-in-the middle). Возможна аутентификация через Kerberos (в домене) или NTLM.
На удаленных компьютерах, к которым вы планируете подключаться должен быть запущена служба WinRM. Проверить это можно так:
Источник: darksf.ru
Установка и удаление платформы 1С на клиентских компьютерах удалённо через скрипт (с доменом и без)
Для работы скрипта должен быть установлен PowerShell. Данная программа идёт в комплекте со всеми современными windows системами, а вот в WindowsXP придётся установить PowerShell отдельно.
Все параметры работы скрипта можно задать, отредактировав файл, а можно передать как значения соответствующих ключей. Давайте рассмотрим, какие имеются ключи и какие значения им необходимо передавать.
Ключ «dd» (от Distribution Directory), принимает любой путь windows формата, т.е. пути вида «C:Windows» или «Server1CDistr». По указанному пути должны располагаться дистрибутивы платформы 1С, причём каждый из дистрибутивов должен быть в своей папке с номером версии или с номером версии и битность платформы 1С Предприятия, например «8.3.5.1111» или «8.3.9.1818-32» или «8.3.9.1818-64». Суфиксы битности необходимо использовать, если в одной сети существуют компьютеры с операционными системами разной битности и вы хотите поставить на 64-битную систему 64-битную платформу. Указанная папка, и все подпапки с дистрибутивами платформ, должна быть доступна для чтения пользователю, от имени которого будет работать скрипт.
Ключ «dl» (от Directory Logs), аналогично ключу «dd», принимает любой путь windows формата. В данную папку будут записываться логи выполнения скрипта. Имена файлов с логами соответствуют имени компьютера и дописываются при каждом запуске скрипта. Указанная папка должна быть доступна для записи пользователю, от имени которого будет работать скрипт. Если указанный путь недоступен или нет возможности записи, то все действия скрипта будут писаться в файл «1C8InstallAndUninstall.log», находящийся в локальной папку пользователя (примерный путь «C:UsersVasaAppDataLocal»).
Ключ «ip» (от Install Parameters) отвечает за параметры установки при работе скрипта. Ключ может принимать одно из следующих значений:
- “no” — не производить установку
- “last” — установить последнею платформу из найденных в папке с дистрибутивами
- “8.3.5.1111” — номер версии конкретной платформы, которую необходимо установит
Ключ «dp» (от Delet Parameters) отвечает за параметры удаления при работе скрипта. Ключ может принимать одно из следующих значений:
- “no” — не производить удаление
- “ael” (от all except last) — удалить все найденные на компьютере платформы, которые совпадают со всеми платформами, найденными в папке с дистрибутивами, кроме последней платформы. Важно! Данный ключ удалит только те платформы, версии которых имеются в папке с дистрибутивами платформ, если какая-то версия установлена на компьютер, но её нет в папке с дистрибутивами, то она не будет удалена.
- “8.3.5.1111” — номер версии конкретной платформы, которую необходимо удалить
- “all” — удалить все версии платформы 1С на компьютере. Данное значение является подавляющим и экстенсивным. Подавляющим, потому что, для работы скрипта при данном значении необходимо передать путь для записи логов, а можно не передавать даже его, все значения остальных ключей будут игнорироваться. Экстенсивными, потому что, удалены будут все продукты на компьютере хотя бы призрачно напоминающие платформу 1С.
Ключ «iod» (от Installation Options Distribution) отвечает за компоненты платформы 1С, которые будут установлены. Ключу необходимо передать значение вида «DESIGNERALLCLIENTS=1 THINCLIENT=1 THINCLIENTFILE=1», в котором можно менять 1 на 0 или обратно в зависимости какие части платформы вы хотите установить. Если данному ключу передать любое другое значение, не похожее на строку выше, то будет произведена установка всех компонент для работы системы в клиентском режиме.
- “DESIGNERALLCLIENTS” — основной клиент и конфигуратор
- “THINCLIENT” — тонкий клиент для клиент-серверного варианта работы
- “THINCLIENTFILE” — тонкий клиент с возможностью работы с файловыми информационными базами
Как установить, обновить или удалить Платформу 1С, если у вас много компьютеров, бегать к каждому лень, а домена нет?
Плохая новость: придётся побегать, и настроить на каждом компьютере выполнение планировщика заданий
Хорошая новость: это надо сделать только один раз.
Для начала осуществим подготовку:
- Создаём 2 общедоступных папки, одну с правами на чтение для всех, а другую с правами на запись для всех. Обязательно создавайте 2 независимые папке, иначе всё может очень плохо закончиться.
- В папку с правами «только на чтение для всех» кладём папки с дистрибутивами, каждая из папок должна именоваться по номеру версии дистрибутива, который в ней находиться. Сюда же кладём скрипт и bat файл, который запускает скрипт.
Небольшое отступление! Зачем нам нужен bat файл для запуска PowerShell скрипта? Потому что используя bat файл мы убиваем двух зайцев:
- По умолчанию система windows запрещает запуск любого PowerShell скрипта из соображения безопасности, поэтому bat файл будет сначала разрешать запуск скрипта, а после его работы снова запрещать.
- В bat файле можно менять параметры запуска скрипта, не редактируя сам файл скрипта меняя установленные в него значения по умолчанию.
Теперь начнём настраивать локальные компьютеры пользователей. В отсутствии домена предполагается, что все пользователи работают под локальными учётными записями с правами «Пользователи», а для административных действия имеется учётная записи с правами «Администраторы».
- Входим в систему на локальном компьютере под именем пользователя с правами «Администраторы»
- Жмём Win+R и вводим Taskschd.msc, открывается планировщик заданий
- Создаём задание по ссылке справа (обратите внимание на ссылки «Подключиться к другому компьютеру» и «Импортировать задачу» для самых больших ленивцев).
- Даём осмысленное название заданию. Необходимо обязательно установить: «Выполнять для всех пользователей» и «Выполнять с наивысшими правами»
- Переходим на вкладку «Триггеры» и нажимаем «Создать». Тут настраиваются параметры, при каких условиях будет запускаться скрипт. Можно настроить, чтобы скрипт запускался каждый час в рабочее время (если скрипту нечего делать, т.е. уже всё установлено и удалено, то его работа ни как не скажется на производительности). Другой популярный вариант запуска при включении компьютера, обращаю ваше внимание что имеются в понятие «При входе в систему» и «При запуске», в первом случае скрипт может не отработать, т.к. пользователь от имени которого запускается скрипт отличен от пользователя работающего на данном компьютере, проще говоря выбирайте вариант «При запуске»
- Переходим на вкладку «Действия» и нажимает «Создать». Нажимаем «Обзор» и выбираем bat файл. Дальнейшие вкладки можно оставить по умолчанию.
Как установить, обновить или удалить Платформу 1С, если имеется домен?
Всё проще некуда
- Создаём группу, в которую включаем все интересующие нас компьютеры. Очень важно чтобы в группу входили именно компьютеры, а не пользователи которые за ними сидят, т.к. для работы скрипту необходимы повышение права, которых нет у пользователя.
- Создаём 2 папки, к одной даём доступ на чтение ранее созданной группе, а второй на запись. В первую кладём дистрибутивы 1С (смотри выше), а во вторую будут писаться логи работы скрипта.
- Открываем оснастку «Управление групповой политикой»
- Создаём или изменяем существующую политику, направленную на ранее созданную группу компьютеров.
- Идём «Конфигурация компьютера» — «Политики» — «Конфигурация Windows» — «Сценарии (запуск/завершение)» – «Автозагрузка».
- Добавляем новый сценарий. Обратите внимание, что путь до сценария должен быть сетевым, а не локальным. Можно добавить сценарий как bat файл, так и напрямую PowerShell. Всё зависит от вашего парка компьютеров и желания.
- Всё.
Примечание
- Работоспособность скрипта проверена в следующих системах: Windows 7 (x86, x64), Windows 8.1 (x86, x64), Windows 10 (x86, x64) со всеми обязательными и не обязательными обновлениями на 2023-11-10.
- Если вас не устраивает задержка при срабатывание скрипта в домене, то необходимо установить параметр «blackhole321 за данную информацию.
upd:2023-12-07
- Полностью переписан способ обхода каталогов с платформой. К данной части кода было больше всего нареканий, не у всех данная часть отрабатывала, а у некоторых отрабатывала неправильно. Теперь всё работает корректно, т.к. используются только самые простые конструкции для обхода директории с дистрибутивами.
- Полностью переписана часть поиска последнего (старшего) дистрибутива в папки с дистрибутивами. Теперь это нормальный понятный код, а не ужас, который был ранее.
- Поменялись между собой части кода, теперь скрипт пытается в первую очередь поставить платформу, а потом всё остальное.
- Дописано много различных проверок чтобы избежать странного поведения или лишних попыток установить платформу. В лог файле теперь больше информации о работе скрипта.
upd:2023-11-21
- Изменена логика работы скрипта. Теперь проверяется установка платформы и в случае отсутствия устанавливаемой платформы на клиентском компьютере скрипт прекращает работу.
- Добавлена функциональность позволяющая в сети с компьютерами разной битности устанавливать 64-битную платформу на 64-битные системы. Для работы данного функционала папки с платформами должны быть вида «Х.Х.Х.Х-32» и «Х.Х.Х.Х-64».
upd:2023-12-12
- В связи с выходом платформы 8.3.16.*, в которой добавился msi файл для Windows XP, изменён поиск файла msi. Это не говорит о том что в Windows XP данный скрипт будет работать, скорее наоборот, теперь он точно не будет работать в этой операционной системе.
- Теперь перед установкой платформы устанавливается Microsoft Visual C++ Redistributable, если соответствующий файл имеется в папке с устанавливаемой платформой.
Источник: open-budget.ru