PowerShell

Знакомство с PowerShell.

Итак, на компьютерном языке Shell – это пользовательский интерфейс, который позволяет получить доступ к службам самой ОС-и. Этот shell может иметь и вариант консоли (как мы его знаем), а может иметь и более дружелюбный интерфейс – оформленный в окна с кнопочками, по которым можно тыцкать мышкой (PowerShell ISE). Windows PowerShell работает именно с ОС от Microsoft последних версий, основан на среде .NET framework. Первая версия Windows PSH появилась почти сразу после выпуска Windows XP, в ноябре 2006 г. Его основное призвание – автоматизация ежедневных задач и процессов, запускаемых администратором системы.

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

Get-help

Справка как она есть. Русифицирована. Информацию о командах получаем отсюда.

Get-Command

Основные командлеты PSH. Сама по себе командлет вам не даст ничего, однако для начала можно было бы ознакомиться с её именем и исполнительным модулем. Например, если нужно увидеть командлеты, работающие с IP функциями или просто сетевые командлеты, мы можем попросить у get-command:

Get-Command –Name *IP*

Остановлюсь. Командлетов сотни, а может и тысячи. Понимая это, Microsoft ввела в работу целый сервис, который позволяет в режиме онлайн компоновать атрибуты команд в командлеты и проверять их работоспособность. Знакомьтесь: Windows PowerShell Command Builder.

Успехов.

Прочитано: 1 553

Запуск 32-разрядной версии Windows PowerShellStarting the 32-Bit Version of Windows PowerShell

При установке Windows PowerShell на 64-разрядном компьютере в дополнение к 64-разрядной версии устанавливается Windows PowerShell (x86) — 32-разрядная версия Windows PowerShell.When you install Windows PowerShell on a 64-bit computer, Windows PowerShell (x86), a 32-bit version of Windows PowerShell is installed in addition to the 64-bit version. При открытии Windows PowerShell по умолчанию запускается 64-разрядная версия.When you run Windows PowerShell, the 64-bit version runs by default.

Однако в некоторых случаях нужно запустить Windows PowerShell (x86) , например при использовании модуля, которому требуется 32-разрядная версия, или при удаленном подключении к 32-разрядному компьютеру.However, you might occasionally need to run Windows PowerShell (x86), such as when you are using a module that requires the 32-bit version or when you are connecting remotely to a 32-bit computer.

Для запуска 32-разрядной версии Windows PowerShell воспользуйтесь любой из следующих процедур.To start a 32-bit version of Windows PowerShell, use any of the following procedures.

Windows Server 2012 R2In Windows Server 2012 R2

• На экране Пуск щелкните Windows PowerShell (x86) .On the Start screen, type Windows PowerShell (x86). Щелкните плитку Windows PowerShell x86.Click the Windows PowerShell x86 tile.
• Выберите пункт Windows PowerShell (x86) в меню Сервис диспетчера сервера.In Server Manager, from the Tools menu, select Windows PowerShell (x86).
• На рабочем столе переместите курсор в правый верхний угол, щелкните элемент Поиск, введите PowerShell x86 и выберите Windows PowerShell (x86) .On the desktop, move the cursor to the upper right corner, click Search, type PowerShell x86 and then click Windows PowerShell (x86).
• В командной строке введите следующее: Via command line, enter:

Windows Server 2012In Windows Server 2012

• На экране Пуск введите PowerShell и выберите Windows PowerShell (x86) .On the Start screen, type PowerShell and then click Windows PowerShell (x86).
• Выберите пункт Windows PowerShell (x86) в меню Сервис диспетчера сервера.In Server Manager, from the Tools menu, select Windows PowerShell (x86).
• На рабочем столе переместите курсор в правый верхний угол, щелкните элемент Поиск, введите PowerShell и выберите Windows PowerShell (x86) .On the desktop, move the cursor to the upper right corner, click Search, type PowerShell and then click Windows PowerShell (x86).
• В командной строке введите следующее: Via command line, enter:

Windows 8.1In Windows 8.1

• На экране Пуск щелкните Windows PowerShell (x86) .On the Start screen, type Windows PowerShell (x86). Щелкните плитку Windows PowerShell x86.Click the Windows PowerShell x86 tile.
• Если вы используете средства удаленного администрирования сервера для Windows 8.1, можно также открыть Windows PowerShell x86 из меню Сервис диспетчера сервера.If you are running Remote Server Administration Tools for Windows 8.1, you can also open Windows PowerShell x86 from the Server ManagerTools menu.
  Выберите Windows PowerShell (x86) .Select Windows PowerShell (x86).
• На рабочем столе переместите курсор в правый верхний угол, щелкните элемент Поиск, введите PowerShell x86 и выберите Windows PowerShell (x86) .On the desktop, move the cursor to the upper right corner, click Search, type PowerShell x86 and then click Windows PowerShell (x86).
• В командной строке введите следующее: Via command line, enter:

Windows 8In Windows 8

• На экране Пуск переместите курсор в правый верхний угол, щелкните Параметры, Плитки, а затем переместите ползунок Показать средства администрирования в значение «Да».On the Start screen, move the cursor to the upper right corner, click Settings, click Tiles, and then move the Show Administrative Tools slider to Yes. Введите PowerShell и выберите Windows PowerShell (x86) .Then, type PowerShell and click Windows PowerShell (x86).
• Если вы используете средства удаленного администрирования сервера для Windows 8, можно также открыть Windows PowerShell x86 из меню Сервис диспетчера сервера.If you are running Remote Server Administration Tools for Windows 8, you can also open Windows PowerShell x86 from the Server ManagerTools menu. Выберите Windows PowerShell (x86) .Select Windows PowerShell (x86).
• На экране Пуск или рабочем столе введите PowerShell (x86) и выберите Windows PowerShell (x86) .On the Start screen or the desktop, type PowerShell (x86) and then click Windows PowerShell (x86).
• В командной строке введите следующее: Via command line, enter:

Шаг 7 анализ полезных команд PowerShell

К настоящему времени вы уже знаете достаточно много, чтобы суметь нанести урон компьютеру, так что будьте осторожны. Посмотрим, например, часто запрашиваемые команды PowerShell.

Эти команды работают только в Windows 10 и только при запуске PowerShell от лица администратора. Они предназначены для переустановки предустановленных приложений Windows 10 и могут пригодиться тем, кто сначала удалил эти программы, а затем решил вернуть их. Команды выглядит следующим образом:

Get-AppXPackage | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register “$($_.InstallLocation)\AppXManifest.xml”}

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

Вот как работает данная команда. Get-AppXPackage проверяет все пакеты приложений в профиле пользователя. Даже если вы удалили приложение, оно остается в списке профиля пользователя.

Командлета Get-AppXPackage возвращает объект TypeName Microsoft.Windows.Appx.PackageManager.Commands.AppxPackage, который включает в себя полное имя пакета приложения и местонахождения соответствующего файла манифеста XML. Если запустить командлету get-appxpackage, вы увидите длинный список пакетов приложений. Скриншот показывает описание приложения Xbox.

Командлета Foreach посредством цикла проходит через каждый объект в AppXPackage, отправляя их командлету Add-AppxPackage. Согласно get-help для Add-AppxPackage, тут есть два ключевых переключателя:

• Переключатель -Register используется для регистрации существующих установок пакетов приложений, можно задать параметры DisableDevelopmentMode и Register
• Переключатель -DisableDevelopmentMode говорит Windows заново зарегистрировать существующий пакет приложения, который был отключён, не зарегистрирован или повреждён.

Строка «$($_.InstallLocation)\AppXManifest.xml» описывает, где расположен файл manifest.xml. Если посмотреть на файлы AppXManifest.xml, вы увидите сложный список идентификаторов приложений, исполняемых файлов и большое количество визуальных элементов, связанных с приложением.

После перезагрузки все добавленные пакеты приложений скачиваются и устанавливаются из магазина Windows Store.

1. 5
2. 4
3. 3
4. 2
5. 1

(3 голоса, в среднем: 3.7 из 5)

Шаг 5 изучение имён

Есть причина того, почему показанные до сих пор командлеты выглядят сходным образом: get-childitem, update-help, get-help используют единую схему глагол-существительное. Это соглашение применяют все командлеты PowerShell, в них глагол стоит перед единственным существительным. Это понравится тем, кто в своё время пострадал от непостоянства названий команд в языках VB и VBA.

Взгляните на самые распространенные командлеты:

set-location: устанавливает текущую рабочий локацию на определённую локацию

get-content: получает содержимое файла

get-item: получает файлы и папки

copy-item: копирует объект из одной локации в другую

remove-item: удаляет файлы и папки

get-process: получает процессы, запущенные на локальном или удаленном компьютере

get-service: получает сервисы, запущенные на локальном или удаленном компьютере

invoke-webrequest: получает содержимое с веб-страницы в интернете

Для просмотра работы определённой командлеты используйте get-help как в случае

get-help copy-item -full

На основе описания в помощи можно понять, что необходимо командлете. Например, если вы хотите копировать все файлы и папки из Documents в c:\temp, используйте

copy-item c:\users\ \documents\* c:\temp

Введя эту команду, вы увидите несколько интересных возможностей окружения PowerShell. Например, если набрать copy-i и нажать кнопку Tab, PowerShell заполнит Copy-Item.  Если неправильно набрать командлету и PowerShell не может распознать её, даётся полное описание того, что было сделано не так.

Попробуйте данную командлету:

invoke-webrequest askwoody.com

Вы получите краткий список заголовков, изображений, ссылок и прочего содержимого веб-страницы

Обратите внимание в get-help на список invoke-webrequest, который «возвращает коллекцию форм, ссылок, изображений и прочие важные элементы HTML» — именно то, что должно показываться на экране

Некоторые командлеты помогают управлять самим PowerShell:

get-command: список всех доступных командлет

get-verb: список всех доступных глаголов

clear-host: очистка экрана программы-хоста

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

get-command *-service

Будут показаны все глаголы, доступные с существительным service. Вот их список:

Get-Service

New-Service

Restart-Service

Resume-Service

Set-Service

Start-Service

Stop-Service

Suspend-Service

Можно объединять эти командлеты с другими.

Шаг 6 использование труб

Если вы знакомы с командной строкой Windows или пакетными файлами, то знаете о перенаправлении и трубах. Перенаправление (символ >) и трубы (символ |) берут результат действия и прикрепляют его в другое место. Например, можно перенаправить результат команды dir в текстовый файл или передать результат команды ping в команду find для фильтрования интересных результатов, вроде

dir > temp.txt

ping askwoody.com | find “packets” > temp2.txt

Здесь во второй команде find ищет строку packets, взятую из адреса askwoody.com командой ping и объединяет все совпадающие строки в файл под названием temp2.txt.

Первая из этих команд отлично работает в PowerShell. Для запуска второй команды потребуется нечто вроде

ping askwoody.com | select-string packets | out-file temp2.txt

Использования перенаправления и труб значительно расширяет возможности командной строки Windows: вместо бесконечного прокручивания вниз по экрану в поиске текстовой строки можно отфильтровывать нужные команды Windows.

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

Сложная часть начинается при выстраивании объектов. Поставляемые одним командлетом объекты должны совпадать с типом объектов, принимаемых получающим командлетом. Текст является весьма простым типом объектов, так что если вы работаете с текстом, выравнивание объектов является простой задачей. Остальные объекты не такие элементарные.

Как это понять? Используйте командлету get-member. Если вы хотите знать, какой тип объекта обрабатывает командлета, проведите её через get-member. Например, если вы пытаетесь понять запущенные на компьютере процессы и сузили опции до командлеты get-process, вот как узнать результат командлеты:

get-process | get-member

Запуск этой командлеты выдаёт длинный список свойств и методов для get-process, но в самом начале списка можно увидеть тип объекта, который создает get-process:

TypeName: System.Diagnostics.Process

Нижеприведенный скриншот также показывает свойства get-process под названием get-process Handles, Name, NPM, PM, SI, VM и WS.

Если вы хотите манипулировать результатом get-process для работы с этим командлетом (вместо отображения длинного списка активных процессов на мониторе), нужно найти другую команду, которая в качестве вводных данных принимает System.Diagnostics.Process. Для поиска нужной командлеты снова используйте возможности PowerShell:

get-command -Parametertype System.Diagnostics.Process

Эта командлета выдает список командлет, которые могут обрабатывать System.Diagnostics.Process.

Некоторые командлеты известны тем, что принимают почти любой вид данных. Главной среди них является where-object. Эта командлета пропускает через себя каждый посылаемый по трубе объект, один за одним, и применяет к нему заданной критерии выбора. Существует специальный маркер под названием $_, который позволяет использовать каждый предмет в трубе, один за раз.

Допустим, вы хотите получить список всех запущенных на компьютере процессов с названием «svchost», то есть хотите сопоставить свойство Name процессу svchost. Используйте команду:

get-process | where-object {$_.Name -eq “svchost”}

Командлета where-object смотрит на каждый объект System.Diagnostics.Process, сравнивает .Name этого объекта с «svchost»; если есть совпадения, они выдаются на монитор. Смотрите на скриншот.

Обзор

Команды, исполняемые в Windows PowerShell, могут быть в форме командлетов, которые являются специализированными классами .NET, созданными с целью предоставления функциональности в PowerShell в виде сценариев PowerShell () или являются обычными исполняемыми файлами. Если команда является исполняемым файлом, то PowerShell запускает её в отдельном процессе; если это команда, то он исполняется внутри процесса PowerShell. PowerShell предоставляет интерфейс командной строки, в котором можно вводить команды и отображать выводимые ими данные в текстовом виде. Этот пользовательский интерфейс, базирующийся на стандартном механизме консоли Windows, предоставляет настраиваемый механизм автозавершения команд, но не обладает возможностью подсветки синтаксиса, хотя при желании её можно обеспечить. В PowerShell также можно создавать псевдонимы (англ. alias) для командлетов, которые при вызове преобразуются в оригинальные команды. Кроме того, поддерживаются позиционные и именованные параметры для командлетов. При выполнении командлета работа по привязке значений аргументов к параметрам выполняется самим PowerShell, но при вызове внешних исполняемых файлов аргументы передаются им для самостоятельного разбора.

Другое понятие, используемое в PowerShell, — это конвейер (англ. pipeline). Подобно конвейерам в UNIX, они предназначены для объединения нескольких команд путём передачи выходных данных одной команды во входные данные второй команды, используя оператор . Но, в отличие от аналога в UNIX, конвейер PowerShell является полностью объектным, то есть данные между командлетами передаются в виде полноценных объектов соответствующих типов, а не как поток байтов. Когда данные передаются как объекты, содержащиеся в них элементы сохраняют свою структуру и типы между командлетами, без необходимости использования какой-либо сериализации или посимвольного разбора данных. Объект также может содержать некоторые функции, предназначенные для работы с данными. Они также становятся доступными для получающего их командлета. Вывод последнего командлета в конвейере PowerShell автоматически передаёт на командлет , который создаёт текстовое представление объектов и содержащихся в них данных и выводит его на экран.

Так как все объекты PowerShell являются объектами .NET, они содержат метод , возвращающий текстовое представление данных объекта. PowerShell использует этот метод для преобразования объекта в текст. Кроме того, он позволяет указать правила форматирования, так что текстовое представление объектов может быть настроено. Однако с целью поддержания совместимости, если в конвейере используется внешний исполняемый файл, то он получает текстовый поток, представляющий объект, и не интегрируется с системой типов PowerShell.

Расширенная система типов (англ. Extended Type System, ETS) PowerShell базируется на системе типов .NET, но реализует некоторые дополнения. Например, она позволяет создавать различные представления объектов, отображая лишь некоторые из их свойств и методов, а также применять специальное форматирование и механизмы сортировки. Эти представления привязываются к оригинальным объектам с помощью конфигурационных файлов в формате XML.

Настройка

Однако, если вы сейчас попробуете запустить данный сценарий, то получите сообщение об ошибке. Причиной этому является то, что по умолчанию выполнение сценариев в PowerShell запрещено. Это сделано специально для предотвращения возможных проблем с безопасностью. По умолчанию после установки вам доступно только выполнение команд в интерактивном режиме. Для защиты пользовательских данных и целостности операционной системы в оболочке Windows PowerShell реализованы некоторые средства обеспечения безопасности, в том числе политика выполнения. Политика выполнения определяет, можно ли выполнять сценарии, и если да, должны ли они быть подписаны цифровой подписью. Кроме того, она определяет, можно ли загружать конфигурационные файлы.

Прежде всего посмотрите текущий статус политики выполнения. Сделать это можно с помощью команды:

get-executionpolicy

В случае установки по умолчанию вы должны получить статус Restricted. Для того чтобы сменить этот статус, воспользуйтесь командой:

set-executionpolicy статус_политики

Рассмотрим, какие статусы политики выполнения возможны:

n Restricted – эта политика выполнения по умолчанию. Допускает отдельные команды, но сценарии выполнять нельзя.

n AllSigned – здесь выполнение сценариев разрешено, но необходимо наличие цифровой подписи надежного издателя на всех сценариях и файлах конфигураций, включая сценарии, написанные на локальном компьютере. Также при такой политике запрашивают подтверждение перед выполнением сценариев надежных издателей. Однако при этом существует опасность того, что подписанные, но вредоносные сценарии выполняются.

n RemoteSigned – при таком статусе политики выполнение сценариев также разрешено. Необходимо наличие цифровой подписи надежного издателя на всех сценариях и файлах конфигураций, загруженных из Интернета (включая электронную почту и программы мгновенного обмена сообщениями). Нет необходимости в цифровых подписях на сценариях, запускаемых с локального компьютера. Не запрашивают подтверждения перед выполнением сценариев надежных издателей. Подписанные, но вредоносные сценарии также выполняются.

n Unrestricted – самая демократичная политика, позволяет запускать неподписанные сценарии. Сценарии и файлы конфигурации, загруженные из Интернета (включая Microsoft Outlook, Outlook Express и Windows Messenger), выполняются после предупреждения, что данный файл был загружен из Интернета. Как и следовало ожидать, при таком статусе также возможно выполнение вредоносных сценариев. Думаю, использование данного статуса политики выполнения возможно только на тестовых машинах, так как в реальных сетях это крайне небезопасно.

В зависимости от специфики выполняемых серверами задач я бы рекомендовал использовать RemoteSigned, в случаях, когда выполняются преимущественно сценарии собственного написания, и AllSigned, когда выполняются сценарии, полученные из внешних источников.

Итак, устанавливаем статус политики RemoteSigned:

set-executionpolicy RemoteSigned

Запускаем PS1-файл. Для этого достаточно просто набрать в командной строке PowerShell имя файла. Результатом выполнения сценария будет информация о времени на локальной машине.

Итак, на примере такого незамысловатого сценария мы настроили систему политики выполнения сценариев PowerShell и убедились в работоспособности интерпретатора. Пришло время рассмотреть более сложные, прикладные сценарии.

Предыстория

Каждая выпущенная версия MS-DOS и Microsoft Windows для персональных компьютеров содержала утилиту, предоставляющую интерфейс командной строки. Это были (в системах, основанных на MS-DOS, включая Windows 9x) и (в системах семейства Windows NT). Это были обычные интерпретаторы командной строки, имевшие лишь несколько базовых команд. Для других задач требовались отдельные консольные приложения, которые вызывались из этих оболочек. Они также имели язык сценариев (пакетные файлы), при помощи которого можно было автоматизировать различные задачи. Однако эти интерпретаторы не годились для полноценной автоматизации — частично потому, что в них отсутствовали эквиваленты многих операций графического интерфейса, а также из-за слабой функциональности языка сценариев, не позволявшего описывать достаточно сложные алгоритмы. В Windows Server 2003 ситуация была улучшена, однако поддержка сценариев всё ещё считалась недостаточной.

Microsoft пыталась решить некоторые из этих недостатков с помощью Windows Script Host, вышедшего в 1998 году в составе Windows 98, и утилиты для работы с ним из командной строки . Он интегрируется с Active Script и позволяет писать сценарии на совместимых языках, таких, как JScript и VBScript, используя API, предоставляемое приложениями через Component Object Model (COM). Однако у этого решения свои недочёты. Windows Script Host не интегрирован с оболочкой, отсутствует встроенная документация. Различные версии Windows также предоставляют командные интерпретаторы специального назначения (такие, как и WMIC) со своими собственными наборами команд. Они не интегрированы с командной оболочкой и не дают возможностей для взаимодействия.

В 2003 Microsoft начала разработку новой оболочки, называемой Monad (также известной как Microsoft Shell или MSH). Monad должен был стать новой расширяемой оболочкой командой строки, со свежим дизайном, который позволял бы автоматизировать весь спектр административных задач. Microsoft опубликовала первую публичную бета-версию Monad 17 июня 2005 года. Вторая и третья бета-версии были выпущены 11 сентября 2005 и 10 января 2006 соответственно. 25 апреля 2006 года было объявлено, что Monad переименован в Windows PowerShell для позиционирования его в качестве значительной части их технологий управления. В это же время была выпущена версия Release Candidate 1 («кандидат на выпуск»). Release Candidate 2 последовал 26 сентября 2006 года. Финальная версия (Release to Web, RTW) была выпущена 14 ноября 2006 года для Windows XP SP2 и Windows 2003. Финальная версия для Windows Vista стала доступна только 30 января 2007 года.

Последний community technology preview выпуск Windows PowerShell версии 2.0 был выпущен в декабре 2008 года. Финальная версия второй версии PowerShell была выпущена в составе систем Windows 7 и Windows Server 2008 R2 одновременно с их выпуском. Для остальных систем (Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008), вторая версия PowerShell стала доступна в составе комплекта Windows Management Framework 27 октября 2009 года. Кроме Windows PowerShell второй версии, в этот комплект также входят WinRM версии 2.0 и BITS 4.0 (последний доступен только для Windows Vista и Windows 2008; в Windows 7 и Windows Server 2008 R2 он встроен).