Powershell windows что это такое

Set-Location -LiteralPath C:\ -PassThru

sEt-loCATion -PATH c:\ -passthru

Set-Location `
-LiteralPath C:\ `
-PassThru

Get-Alias -Definition Get-ChildItem

# Оба варианта равноправны
Get-Alias -Name clear
Get-Alias clear

# Эта команда не будет работать
Set-Location C:\Program Files

Get-Help Get-Childitem

Get-Process powershell

Get-Process powershell | Get-Member

Get-Process powershell | Get-Member | Where-Object {$_.MemberType -eq 'Property'}

Get-Process powershell | Get-Member | Format-Table -AutoSize -Wrap -GroupBy MemberType -Property Name, Definition

Get-Process powershell | Get-Member | Sort-Object -Property Name

Get-ChildItem -Path C:\ -Name powershell.exe -Recurse -ErrorAction SilentlyContinue

Start-Job {Get-ChildItem -Path C:\ -Name powershell.exe -Recurse -ErrorAction SilentlyContinue}

Get-Job Job1

if ($var1 -eq $var2) {
    # Код внутри условия
} else {
    # Код внутри условия
    # Ещё код внутри условия
}

Get-ChildItem | Where-Object { $_.Length -gt 10mb }

Set-ExecutionPolicy RemoteSigned

$Number = 123

if ($Number -gt 0) {
Write-Host 'Число больше нуля'
} elseif ($Number -lt 0) {
Write-Host 'Число меньше нуля'
} else {
Write-Host 'Число равно нулю'
}

>>> Число больше нуля

$Day = 2

switch ($Day) {
    1 {Write-Host 'Понедельник'}
    2 {Write-Host 'Вторник'}
    3 {Write-Host 'Среда'}
    4 {Write-Host 'Четверг'}
    5 {Write-Host 'Пятница'}
    6 {Write-Host 'Суббота'}
    7 {Write-Host 'Воскресенье'}
}

>>> Вторник

Жизнь можно сделать лучше!
Освойте востребованную профессию, зарабатывайте больше и получайте от работы удовольствие. А мы поможем с трудоустройством и важными для работодателей навыками.
Посмотреть курсы

Исторически утилиты командной строки в Unix-системах развиты лучше чем в Windows, однако с появлением нового решения ситуация изменилась.

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

Основные возможности 

Разумеется Windows PowerShell — это в первую очередь командная оболочка с языком сценариев, изначально созданная на основе платформы .NET Framework, а позднее — на .NET Core. В отличие от принимающих и возвращающих текстовые данные оболочек, Windows PowerShell работает с классами .NET, у которых есть свойства и методы. PowerShell позволяет выполнять обычные команды, а также дает доступ к объектам COM, WMI и ADSI. В ней используются различные хранилища, вроде файловой системы или реестра Windows, для доступа к которым созданы т.н. поставщики (providers). Стоит отметить возможность встраивания исполняемых компонентов PowerShell в другие приложения для реализации различных операций, в т.ч. через графический интерфейс. Верно и обратное: многие приложения для Windows предоставляют доступ к своим интерфейсам управления через PowerShell. 

Windows PowerShell позволяет:

• Менять настройки операционной системы;
• Управлять службами и процессами;
• Настраивать роли и компоненты сервера;
• Устанавливать программное обеспечение;
• Управлять установленным ПО через специальные интерфейсы;
• Встраивать исполняемые компоненты в сторонние программы;
• Создавать сценарии для автоматизации задач администрирования;
• Работать с файловой системой, реестром Windows, хранилищем сертификатов и т.д.

Оболочка и среда разработки

Существует Windows PowerShell в двух ипостасях: помимо эмулятора консоли с командной оболочкой есть интегрированная среда сценариев (Integrated Scripting Environment — ISE). Чтобы получить доступ к интерфейсу командной строки достаточно выбрать соответствующий ярлык в меню Windows или запустить powershell.exe из меню «Выполнить». На экране появится синее окошко, заметно отличающееся по возможностям от допотопного cmd.exe. Там есть автодополнение и другие фишки, привычные пользователям командных оболочек для Unix-систем.

Для работы с оболочкой нужно запомнить некоторые сочетания клавиш:

• Стрелки вверх и вниз прокручивают историю для повтора ранее набранных команд;
• Стрелка вправо в конце строки перенабирает предыдущую команду посимвольно;
• Ctrl+Home удаляет набранный текст от позиции курсора до начала строки;
• Ctrl+End удаляет текст от курсора до конца строки.

F7 показывает окно с набранными командами и позволяет выбрать одну из них. В консоли также работает выделение текста мышью, копипаст, позиционирование курсора, удаление, backspace — все как мы любим.

Windows PowerShell ISE является полноценной средой разработки с поддерживающим вкладки и подсветку синтаксиса редактором кода, конструктором команд, встроенным отладчиком и другими программистскими радостями. Если в редакторе среды разработки после имени команды написать знак дефис, вы получите в выпадающем списке все доступные параметры с указанием типа. Запустить PowerShell ISE можно либо через ярлык из системного меню, либо с помощью исполняемого файла powershell_ise.exe.

Командлеты 

В Windows PowerShell появились т.н. командлеты (cmdlets). Это специализированные классы .NET, в которые заложена разнообразная функциональность. Именуются они по принципу «Действие-Объект» (или «Глагол-Существительное, если вам так больше нравится), а разделенная дефисом связка напоминает сказуемое и подлежащее в предложениях естественных языков. Например, Get-Help буквально означает «Получить-Помощь» или в контексте PowerShell: «Показать-Справку». По сути это аналог команды man в Unix-системах и мануалы в PowerShell нужно запрашивать именно так, а не вызывая командлеты с ключом —help или /?.. Не стоит забывать и об онлайн-документации по PowerShell: у Microsoft она достаточно подробная.

Помимо Get в командлетах для обозначения действий используются и другие глаголы (и не только глаголы, строго говоря). В списке ниже мы приведем несколько примеров:

Add — добавить;
Clear — очистить;
Enable — включить;
Disable — выключить;
New — создать;
Remove — удалить;
Set — задать;
Start — запустить;
Stop — остановить;
Export — экспортировать;
Import — импортировать.

Есть системные, пользовательские и опциональные командлеты: в результате выполнения все они возвращают объект или массив объектов. К регистру они не чувствительны, т.е. с точки зрения интерпретатора команд нет разницы между Get-Help и get-help. Для разделения используется символ ‘;’, но ставить его обязательно только если в одной строке выполняется несколько командлетов. 

Командлеты Windows PowerShell группируются в модули (NetTCPIP, Hyper-V и т.д.), а для поиска по объекту и действию существует командлет Get-Command. Показать справку по нему можно так:

Get-Help Get-Command

По умолчанию команда отображает краткую справку, но в командлеты при необходимости передаются параметры (аргументы). С их помощью можно, например, получить детальную (параметр -Detailed) или полную (параметр -Full) справку, а также вывести на экран примеры (параметр -Examples):

Get-Help Get-Command -Examples

Справка в Windows PowerShell обновляется командлетом Update-Help. Если строка команд получается слишком длинной, аргументы командлета можно перенести на следующую, написав служебный символ ‘`’ и нажав Enter — просто закончить писать команду на одной строке и продолжить на другой не получится.

Ниже приведем несколько примеров распространенных командлетов: 

Get-Process — показать запущенные в системе процессы;
Get-Service — показать службы и их статус;
Get-Content — вывести содержимое файла.

Для часто используемых командлетов и внешних утилит в Windows PowerShell есть короткие синонимы — алиасы (от англ. Alias). Например, dir — алиас Get-ChildItem. Есть в списке синонимов и аналоги команд из Unix-систем (ls, ps и т.д.), а командлет Get-Help вызывается командой help. Полный список синонимов можно посмотреть с помощью командлета Get-Alias:

Сценарии, функции, модули и язык PowerShell

Скрипты Windows PowerShell хранятся в виде обычных текстовых файлов с расширением .ps1. Запустить их двойным кликом нельзя: нужно правой кнопкой мыши вызвать контекстное меню и выбрать пункт «Запустить в PowerShell». Из консоли придется либо указать полный путь к скрипту, либо перейти в соответствующий каталог и написать имя файла. Запуск сценариев также ограничен системной политикой, а для проверки текущих настроек можно использовать командлет Get-ExecutionPolicy, который выдаст одно из следующих значений:

Restricted — запуск сценариев запрещен (по умолчанию);
AllSigned — разрешен только запуск подписанных доверенным разработчиком сценариев;
RemoteSigned — разрешен запуск подписанных и собственных сценариев;
Unrestricted — разрешен запуск любых сценариев.

У администратора есть два варианта действий. Наиболее безопасный предполагает подписание скриптов, но это довольно серьезное колдунство — мы будем разбираться с ним в следующих статьях. Сейчас пойдем по пути наименьшего сопротивления и поменяем политику:

Set-ExecutionPolicy RemoteSigned

PowerShell для этого придется запустить от имени администратора, хотя с помощью специального параметра можно изменить политику и для текущего пользователя.

Пишутся скрипты на объектно-ориентированном языке программирования, команды которого именуются по тому же принципу, что и рассмотренные ранее командлеты: «Действие-Объект» («Глагол-Существительное»). Основное его предназначение — автоматизация задач администрирования, но это полноценный интерпретируемый язык, в котором есть все необходимые конструкции: условный переход, циклы, переменные, массивы, объекты, обработка ошибок и т.д. Для написания сценариев годится любой текстовый редактор, но удобнее всего запустить Windows PowerShell ISE.

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

Get-ChildItem Env:\PSModulePath | Format-Table -AutoSize

Конвейеры

В последнем примере мы применили знакомую пользователям оболочек для Unix-систем конструкцию. В Windows PowerShell вертикальная черта также позволяет передать выход одной команды на вход другой, но в реализации конвейера есть и существенная разница: речь здесь идет уже не о наборе символов или каком-то тексте. Встроенные командлеты или пользовательские функции возвращают объекты или массивы объектов, а также могут получать их на входе. Как в Bourne shell и его многочисленных последователях, в PowerShell с помощью конвейера упрощается выполнение сложных задач.

Простейший пример конвейера выглядит так:

Get-Service | Sort-Object -property Status

Сначала выполняется командлет Get-Service, а потом все полученные им службы передаются на сортировку по свойству Status командлету Sort-Object. В какой именно аргумент передается результат работы предыдущего участка конвейера, зависит от его типа — обычно это InputObject. Подробнее этот вопрос будет рассматриваться в посвященной языку программирования PowerShell статье. 

При желании цепочку можно продолжить и передать результат работы Sort-Object еще одному командлету (выполняться они будут слева направо). Кстати, пользователям Windows доступна и привычная всем юниксоидам конструкция для постраничного вывода: 

Get-Service | Sort-Object -property Status | more

Запуск задач в фоновом режиме 

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

Start-Job — запуск фоновой задачи;
Stop-Job — остановка фоновой задачи;
Get-Job — просмотр списка фоновых задач;
Receive-Job — просмотр результата выполнения фоновой задачи;
Remove-Job — удаление фоновой задачи;
Wait-Job — перевод фоновой задачи обратно в консоль.

Для запуска фоновой задачи мы используем командлет Start-Job и в фигурных скобках указываем команду или набор команд:

Start-Job {Get-Service}

Фоновыми задачами в Windows PowerShell можно манипулировать, зная их имена. Для начала научимся их отображать:

Get-Job

Теперь покажем результат работы задания Job1:

Receive-Job Job1 | more

Всё довольно просто.

Удаленное выполнение команд

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

• У многих командлетов есть параметр -ComputerName, но таким способом не получится, например, создать конвейер;
• Командлет Enter-PSSession позволяет создать на удаленной машине интерактивный сеанс; 
• С помощью командлета Invoke-Command можно выполнять команды или сценарии на одном или нескольких удаленных компьютерах.

Версии PowerShell

С момента первого релиза в 2006 году PowerShell серьезно изменился. Инструмент доступен для множества систем, работающих на разных аппаратных платформах (x86, x86-64, Itanium, ARM): Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008/2008 R2, Windows 7, Windows 8, Windows 8.1, Windows RT, Windows RT 8.1, Windows Server 2012/2012 R2, Windows 10, Windows Server 2016, GNU/Linux и OS X. Последний релиз 6.2 выпущен 10 января 2018 года. Написанные для более ранних версий скрипты с высокой вероятностью будут работать в более поздних, а вот с обратным переносом могут возникнуть проблемы, поскольку за годы развития в PowerShell появилось большое количество новых командлетов. Узнать версию установленной на компьютере командной оболочки можно с помощью свойства PSVersion встроенной переменной $PSVersionTable:

$PSVersionTable.PSVersion

Также можно воспользоваться командлетом:

Get-Variable -Name PSVersionTable –ValueOnly

То же самое делается и с помощью командлета Get-Host. На самом деле вариантов множество, но для их применения нужно изучить язык программирования PowerShell, чем мы и займемся в следующей статье. 

Итоги 

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

Часть 2: введение в язык программирования Windows PowerShell
Часть 3: передача параметров в скрипты и функции, создание командлетов
Часть 4: Работа с объектами, собственные классы

Какие темы стоит в первую очередь затронуть в следующих статьях цикла?

Проголосовали 288 пользователей.

Воздержались 55 пользователей.

Рассказываем про Windows PowerShell — технологию для автоматизации рутинных задач, пришедшую на смену bat-файлам.

Работа с консолью Microsoft Windows

Ранее мы рассматривали командные интерпретаторы COMMAND.CMD и CMD.EXE, обеспечивающие автоматизацию задач в семействе операционных систем Microsoft Windows. Фактически данные интерпретаторы не получали обновлений с начала 2000-х годов и существуют в современных операционных системах для обеспечения совместимости.

Подробнее о bat-файлах →

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

Помимо отсутствия обновлений, CMD.EXE имеет ограниченный функционал. Он не позволяет писать сложную логику и полностью отказаться от использования графического интерфейса. Корпорация Microsoft пыталась решить эти проблемы с помощью инструмента под названием Microsoft Script Host, который имел интеграцию со скриптовыми языками JScript и VBScript.

Однако Microsoft Script Host имел ряд собственных проблем:

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

Все это побуждало Microsoft сделать командный интерпретатор с нуля.

Новый командный интерпретатор Windows PowerShell

В 2003 году корпорация Microsoft начала разработку нового инструмента — Microsoft Shell (MSH), или Monad. Спустя три года и три бета-версии Monad была официально выпущена под новым названием Windows PowerShell 1.0 на Windows XP и Windows Vista. По ходу развития командная оболочка меняла свои названия на PowerShell Core и PowerShell.

При создании PowerShell разработчики задались целью создать инструмент, который позволил бы с легкостью использовать множество разнородных интерфейсов, предоставляемых операционной системой. Новый инструмент должен быть консистентным и легким для администратора, несмотря на количество технологий «под капотом». Например, PowerShell предоставляет доступ к API .NET-фреймворка, но не требует от администратора знания .NET.

Как и любой командный интерпретатор, PowerShell умеет запускать исполняемые файлы и имеет встроенные команды. Однако у PowerShell встроенные команды имеют название «командлет», появившееся от английского cmdlet.

Что такое командлет?

В основе взаимодействия с PowerShell лежат объекты, а не текст, как у CMD.EXE и командных интерпретаторов в *nix-системах. Такой подход меняет взгляд на организацию встроенных команд.

Командлет — это встроенная команда в PowerShell, выполняющая одну задачу и реализованная на .NET. Имя командлета соответствует правилу Глагол-Существительное, которое можно читать как Действие-Объект.

Самый важный командлет, о котором необходимо узнать в первую очередь, — Get-Help. Он отображает справочную информацию о PowerShell и командлетах.

# Получить общую справку по PowerShell
Get-Help

# Получить справку по командлету Get-Content
Get-Help Get-Content

# Получить справку по командлету Get-Help
Get-Help Get-Help

Если вам кажется, что использовать большие буквы в названии командлетов — это перебор, для вас есть хорошие новости. Все команды в PowerShell являются регистронезависимыми. Иными словами, перечисленные ниже написания эквивалентны:

Get-Help Get-Help
get-help get-help
GET-HELP GET-HELP
GeT-hElP gEt-HeLp

Хотя Windows PowerShell нечувствительна к регистру в именах и параметрах, внешние программы, которые вызываются через оболочку, могут не обладать такими возможностями.

В первой версии PowerShell все командлеты были реализованы на .NET, но начиная с версии 2.0 появилась возможность писать командлеты с использованием синтаксиса PowerShell.

Основы программы PowerShell

Перейдем к практике. PowerShell является кроссплатформенным инструментом и может быть запущена на Linux и macOS, но в данной статье будет рассматриваться только «родное» окружение — Windows.

Как запустить?

Запуск PowerShell можно произвести из меню поиска около кнопки Пуск, набрав powershell.

Аналогично можно запустить PowerShell через диалоговое окно Выполнить…, которое открывается через сочетание клавиш Windows + R.

Если по каким-то причинам у вас не установлен PowerShell, то необходимо сделать это, следуя инструкции в базе знаний Microsoft.

В случае успеха откроется синее окно. Windows PowerShell готов к вашим командам.

Синтаксис

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

Get-Help Get-Command -Online

Данная команда откроет в браузере вкладку с описанием командлета Get-Command в базе знаний Microsoft. Разберем подробнее:

• Get-Help – команда, в данном случае командлет,
• Get-Command – первый позиционный аргумент, который передается командлету,
• -Online – ключ, то есть именованный аргумент.

Обратите внимание, что в CMD.EXE именованные аргументы, то есть ключи, для встроенных команд начинались с символа слэш (/). У командлетов аргументы начинаются со знака минус. Использование знака / в PowerShell недопустимо и будет интерпретировано как ошибка.

Хотя PowerShell во многом похож на CMD.EXE, он имеет несколько существенных отличий. Во-первых, обращение к переменным производится через символ доллар, а не через знак процента. Во-вторых, PowerShell позволяет определять функции. Например:

function Get-Version {
    $PSVersionTable.PSVersion
}

Данный код объявит функцию Get-Version, которая обращается к системной переменной (объекту) PSVersionTable и возвращает значение поля PSVersion. Проще говоря, выводит версию PowerShell.

Именование командлетов может быть неочевидным для администраторов с опытом работы с другими командными интерпретаторами. Поэтому рассмотрим основные команды Windows PowerShell.

Основные команды языка Windows PowerShell

В следующей таблице перечислены основные команды PowerShell и их аналоги в *nix-подобных системах и CMD.EXE. В версии PowerShell 7 количество командлетов превышает полторы тысячи!

После работы в консоли *nix командлет для популярного действия, смены каталога, выглядит громоздко и непривычно. К счастью, командлеты имеют псевдонимы (алиасы), которые могут не следовать правилу именования командлетов. Список известных псевдонимов можно получить с помощью командлета Get-Alias.

Хотя таблица, представленная выше, значительно облегчит назначение командлетов, не стоит ожидать от командлетов поведения как в *nix-системах. Так, например, в PowerShell командлет Get-Content создан для вывода содержимого одного файла на экран, в то время как на *nix-системах утилита cat изначально использовалась для конкатенации (процесса соединения) нескольких файлов с последующим выводом на экран.

Очевидно, что возможности PowerShell значительно больше, чем CMD.exe. Опытный администратор знает, что некоторые задачи из таблицы можно решить в CMD.exe, несмотря на отсутствие специальных команд. Однако эти команды требуют опыта или смекалки.

Отдельно хочется отметить командлет Test-Connection, который делает то же самое, что утилита ping, но не имеет такого алиса. Разница между утилитой и командлетом в формате вывода: утилита выводит текст, а командлет возвращает объект, который можно использовать в конвейерах.

Конвейер PowerShell: особенности и параметры

По своей задумке конвейеры в PowerShell не отличаются от конвейеров в *nix-системах: они перенаправляют вывод одной команды на ввод другой. Как отмечалось ранее, в PowerShell происходит взаимодействие не с текстом, а с объектами. При выводе на экран объект трансформируется в таблицу, чтобы человеку было удобнее читать, но не всегда таблица выводит все поля объекта.

Особенность конвейеров PowerShell заключается в том, что конвейер передает результат не целиком, а по одному объекту. Командлет Test-Connection выводит четыре объекта: по одному на каждый ICMP-запрос. Если подключить командлет к конвейеру, то можно увидеть подтверждение этому тезису. Воспользуемся командлетом Select-Object, чтобы выбрать колонку со временем запроса.

Test-Connection selectel.ru | Select-Object ‘Time(ms)’

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

Но как же так? Дело в том, что отображение объекта при выводе на экран не всегда соответствует имени поля в объекте. Чтобы получить полный список полей в объекте, необходимо вызвать командлет Get-Member.

PS C:\Users\sun> Test-connection selectel.ru | Get-Member


   TypeName: System.Management.ManagementObject#root\cimv2\Win32_PingStatus

Name                           MemberType     Definition
----                           ----------     ----------
PSComputerName                 AliasProperty  PSComputerName = __SERVER
Address                        Property       string Address {get;set;}
BufferSize                     Property       uint32 BufferSize {get;set;}
NoFragmentation                Property       bool NoFragmentation {get;set;}
PrimaryAddressResolutionStatus Property       uint32 PrimaryAddressResolutionStatus {get;set;}
ProtocolAddress                Property       string ProtocolAddress {get;set;}
ProtocolAddressResolved        Property       string ProtocolAddressResolved {get;set;}
RecordRoute                    Property       uint32 RecordRoute {get;set;}
ReplyInconsistency             Property       bool ReplyInconsistency {get;set;}
ReplySize                      Property       uint32 ReplySize {get;set;}
ResolveAddressNames            Property       bool ResolveAddressNames {get;set;}
ResponseTime                   Property       uint32 ResponseTime {get;set;}
ResponseTimeToLive             Property       uint32 ResponseTimeToLive {get;set;}
RouteRecord                    Property       string[] RouteRecord {get;set;}
RouteRecordResolved            Property       string[] RouteRecordResolved {get;set;}
SourceRoute                    Property       string SourceRoute {get;set;}
SourceRouteType                Property       uint32 SourceRouteType {get;set;}
StatusCode                     Property       uint32 StatusCode {get;set;}
Timeout                        Property       uint32 Timeout {get;set;}
TimeStampRecord                Property       uint32[] TimeStampRecord {get;set;}
TimeStampRecordAddress         Property       string[] TimeStampRecordAddress {get;set;}
TimeStampRecordAddressResolved Property       string[] TimeStampRecordAddressResolved {get;set;}
TimestampRoute                 Property       uint32 TimestampRoute {get;set;}
TimeToLive                     Property       uint32 TimeToLive {get;set;}
TypeofService                  Property       uint32 TypeofService {get;set;}
__CLASS                        Property       string __CLASS {get;set;}
__DERIVATION                   Property       string[] __DERIVATION {get;set;}
__DYNASTY                      Property       string __DYNASTY {get;set;}
__GENUS                        Property       int __GENUS {get;set;}
__NAMESPACE                    Property       string __NAMESPACE {get;set;}
__PATH                         Property       string __PATH {get;set;}
__PROPERTY_COUNT               Property       int __PROPERTY_COUNT {get;set;}
__RELPATH                      Property       string __RELPATH {get;set;}
__SERVER                       Property       string __SERVER {get;set;}
__SUPERCLASS                   Property       string __SUPERCLASS {get;set;}
ConvertFromDateTime            ScriptMethod   System.Object ConvertFromDateTime();
ConvertToDateTime              ScriptMethod   System.Object ConvertToDateTime();
IPV4Address                    ScriptProperty System.Object IPV4Address {get=$iphost = [System.Net.Dns]:...
IPV6Address                    ScriptProperty System.Object IPV6Address {get=$iphost = [System.Net.Dns]:...

Можно визуально оценить список и найти поле ResponseTime. Также в начале указан тип данного объекта, Win32_PingStatus, информацию о котором можно поискать в базе знаний Microsoft. В документации не только перечислены поля, но и их назначение. Таким образом, конечный вид конвейера будет таким:

Test-connection selectel.ru | Select-Object ResponseTime

Хотя PowerShell побуждает к интерактивной работе, его основное предназначение — автоматизировать рутинные задачи. Значит, необходимо писать скрипты.

Соберите сервер в конфигураторе под свои задачи. Или выберите из более 100 готовых.

Интегрированная среда разработки

Если вы запускали PowerShell через поиск, вероятно, вы могли заметить приложение Windows PowerShell ISE.

PowerShell-скрипты — это текстовые файлы с расширением .ps1.

Windows PowerShell ISE — это интегрированная среда сценариев PowerShell, включающая в себя:

• редактор PowerShell-скриптов с автодополнением,
• окно для интерактивного выполнения командлетов в скрипте,
• список доступных командлетов с поиском.

Обратите внимание, что модуль ISE предоставляет графический интерфейс для генерации аргументов командлета. Помимо генерации команд, в функции модуля также входит вызов «справочника» по командлетам, аналогичного Get-Help, только в графическом интерфейсе.

После написания своего первого PowerShell-скрипта вы столкнетесь с некоторыми ограничениями. Во-первых, файл с расширением ps1 нельзя запустить «двойным кликом» по файлу. Необходимо открыть контекстное меню с помощью правой клавиши мыши и выбрать Запустить с помощью PowerShell.

Во-вторых, скрипт не запустится со следующей ошибкой:

Невозможно загрузить файл C:\Users\sun\Documents\HelloWorld.ps1, так как выполнение сценариев отключено в этой системе. Для получения дополнительных сведений см. about_Execution_Policies по адресу https:/go.microsoft.com/fwlink/
?LinkID=135170.
    + CategoryInfo          : Ошибка безопасности: (:) [], ParentContainsErrorRecordException
    + FullyQualifiedErrorId : UnauthorizedAccess

По умолчанию запуск PowerShell-скриптов ограничен соответствующей политикой безопасности. Посмотреть текущее значение политики безопасности можно с помощью командлет Get-ExecutionPolicy:

PS C:\Users\sun> Get-ExecutionPolicy
Restricted

Список возможных значений:

• Restricted — запуск запрещен,
• AllSigned — разрешен только запуск подписанных доверенным разработчиком скриптов,
• RemoteSigned — разрешен запуск подписанных и собственных скриптов,
• Unrestricted — разрешен запуск любых скриптов.

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

Set-ExecutionPolicy RemoteSigned

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

Выполнение задач в фоне

PowerShell позволяет выполнять задачи в фоновом режиме, эту функциональность обеспечивают командлеты с существительным Job:

• Start-Job —  запустить команду или командлет в фоновом режиме,
• Get-Job — показать состояние фоновых команд,
• Wait-Job — дождаться завершения выполнения фоновой команды,
• Receive-Job — получить результат выполнения команды.

Командлет Start-Job возвращает информацию о запущенном фоновом задании. Идентификатор, обозначенный в поле Id, является уникальным для сессии PowerShell.

Настройка удаленного выполнения

PowerShell позволяет реализовать удаленное выполнение командлетов, скриптов, но только на платформе Windows. Для включения возможности удаленного управления необходимо выполнить командлет Enable-PSRemoting с правами администратора.

Командлет Enter-PSSession запустит удаленную интерактивную сессию, а Invoke-Command выполнит команду на одном или нескольких удаленных компьютерах.

PowerShell – актуальные версии программы

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

На момент написания статьи актуальная версия PowerShell — 7.2. Используйте этот текст в качестве краткого справочника по Windows PowerShell, администрирование систем со скриптами в этой программе будет довольно простым. 

Screenshot of a PowerShell 7 session in Windows Terminal
Paradigm	Imperative, pipeline, object-oriented, functional and reflective
Designed by	Jeffrey Snover, Bruce Payette, James Truher (et al.)
Developer	Microsoft
First appeared	November 14, 2006; 16 years ago
Stable release	7.3.7 / September 18, 2023; 18 days ago[1]
Preview release	v7.4.0-preview.6 / September 28, 2023; 8 days ago[2]
Typing discipline	Strong, safe, implicit and dynamic
Implementation language	C#
Platform	PowerShell: .NET Windows PowerShell: .NET Framework
OS	Windows 7 and later Windows Server 2008 R2 and later macOS 10.12 and later Ubuntu 14.04, 16.04, 18.04, 20.04 and 22.04 Debian 8.7+, 9, 10 and 11 CentOS 7 and 8 Red Hat Enterprise Linux 7 and 8 openSUSE 42.2, 42.3, 15.0, 15.1, 15.2 Fedora 28, 29, 30
License	MIT License[3] (but the Windows component remains proprietary)
Filename extensions	.ps1 (Script) .ps1xml (XML Document) .psc1 (Console File) .psd1 (Data File) .psm1 (Script Module) .pssc (Session Configuration File) .psrc (Role Capability File) .cdxml (Cmdlet Definition XML Document)
Website	microsoft.com/powershell
Influenced by
Python, Ksh, Perl, C#, CL, DCL, SQL, Tcl, Tk,[4] Chef, Puppet

PowerShell is a task automation and configuration management program from Microsoft, consisting of a command-line shell and the associated scripting language. Initially a Windows component only, known as Windows PowerShell, it was made open-source and cross-platform on August 18, 2016, with the introduction of PowerShell Core.^[5] The former is built on the .NET Framework, the latter on .NET (previously .NET Core).

Since Windows 10 build 14971, PowerShell replaced Command Prompt and became the default command shell for File Explorer.^[6][7]

In PowerShell, administrative tasks are generally performed via cmdlets (pronounced command-lets), which are specialized .NET classes implementing a particular operation. These work by accessing data in different data stores, like the file system or Windows Registry, which are made available to PowerShell via providers. Third-party developers can add cmdlets and providers to PowerShell.^[8][9] Cmdlets may be used by scripts, which may in turn be packaged into modules. Cmdlets work in tandem with the .NET API.

PowerShell’s support for .NET Remoting, WS-Management, CIM, and SSH enables administrators to perform administrative tasks on both local and remote Windows systems. PowerShell also provides a hosting API with which the PowerShell runtime can be embedded inside other applications. These applications can then use PowerShell functionality to implement certain operations, including those exposed via the graphical interface. This capability has been used by Microsoft Exchange Server 2007 to expose its management functionality as PowerShell cmdlets and providers and implement the graphical management tools as PowerShell hosts which invoke the necessary cmdlets.^[8][10] Other Microsoft applications including Microsoft SQL Server 2008 also expose their management interface via PowerShell cmdlets.^[11]

PowerShell includes its own extensive, console-based help (similar to man pages in Unix shells) accessible via the Get-Help cmdlet. Updated local help contents can be retrieved from the Internet via the Update-Help cmdlet. Alternatively, help from the web can be acquired on a case-by-case basis via the -online switch to Get-Help.

Background[edit]

The command-line interpreter (CLI) has been an inseparable part of most Microsoft operating systems. MS-DOS and Xenix relied almost exclusively on CLI. (MS-DOS 5 came with a complementary graphical DOS Shell.) The Windows 9x family came bundled with COMMAND.COM, the command-line environment of MS-DOS. The Windows NT and Windows CE families, however, came with a new cmd.exe that bore strong similarities to COMMAND.COM. Both environments support a few basic internal commands and a primitive scripting language (batch files), which can be used to automate various tasks. However, they cannot automate all facets of Windows graphical user interface (GUI) because command-line equivalents of operations are limited and the scripting language is elementary.

Microsoft attempted to address some of these shortcomings by introducing the Windows Script Host in 1998 with Windows 98, and its command-line based host, cscript.exe. It integrates with the Active Script engine and allows scripts to be written in compatible languages, such as JScript and VBScript, leveraging the APIs exposed by applications via the component object model (COM). However, it has its own deficiencies: its documentation is not very accessible, and it quickly gained a reputation as a system vulnerability vector after several high-profile computer viruses exploited weaknesses in its security provisions. Different versions of Windows provided various special-purpose command-line interpreters (such as netsh and WMIC) with their own command sets but they were not interoperable. Windows Server 2003 further attempted to improve the command line experience but scripting support was still unsatisfactory.^[12]

Kermit[edit]

By the late 1990s, Intel had come to Microsoft asking for help in making Windows, which ran on Intel CPUs, a more appropriate platform to support the development of future Intel CPUs. At the time, Intel CPU development was accomplished on Sun Microsystems computers which ran Solaris (a Unix variant) on RISC-architecture CPUs. The ability to run Intel’s many KornShell automation scripts on Windows was identified as a key capability. Internally, Microsoft began an effort to create a Windows port of Korn Shell, which was code-named Kermit.^[13] Intel ultimately pivoted to a Linux-based development platform that could run on Intel CPUs, rendering the Kermit project redundant. However, with a fully funded team, Microsoft program manager Jeffrey Snover realized there was an opportunity to create a more general-purpose solution to Microsoft’s problem of administrative automation.

Monad[edit]

By 2002, Microsoft had started to develop a new approach to command-line management, including a CLI called Monad (also known as Microsoft Shell or MSH). The ideas behind it were published in August 2002 in a white paper called the «Monad Manifesto» by its chief architect, Jeffrey Snover.^[14] In a 2017 interview, Snover explains the genesis of PowerShell, saying that he had been trying to make Unix tools available on Windows, which didn’t work due to «core architectural difference[s] between Windows and Linux». Specifically, he noted that Linux considers everything an ASCII text file, whereas Windows considers everything an «API that returns structured data». They were fundamentally incompatible, which led him to take a different approach.^[15]

Monad was to be a new extensible CLI with a fresh design capable of automating a range of core administrative tasks. Microsoft first demonstrated Monad publicly at the Professional Development Conference in Los Angeles in October 2003. A few months later, they opened up private beta, which eventually led to a public beta. Microsoft published the first Monad public beta release on June 17, 2005, and the Beta 2 on September 11, 2005, and Beta 3 on January 10, 2006.

PowerShell[edit]

On April 25, 2006, not long after the initial Monad announcement, Microsoft announced that Monad had been renamed Windows PowerShell, positioning it as a significant part of its management technology offerings.^[16] Release Candidate (RC) 1 of PowerShell was released at the same time. A significant aspect of both the name change and the RC was that this was now a component of Windows, rather than a mere add-on.

Release Candidate 2 of PowerShell version 1 was released on September 26, 2006, with final release to the web on November 14, 2006. PowerShell for earlier versions of Windows was released on January 30, 2007.^[17] PowerShell v2.0 development began before PowerShell v1.0 shipped. During the development, Microsoft shipped three community technology previews (CTP). Microsoft made these releases available to the public. The last CTP release of Windows PowerShell v2.0 was made available in December 2008.

PowerShell v2.0 was completed and released to manufacturing in August 2009, as an integral part of Windows 7 and Windows Server 2008 R2. Versions of PowerShell for Windows XP, Windows Server 2003, Windows Vista and Windows Server 2008 were released in October 2009 and are available for download for both 32-bit and 64-bit platforms.^[18] In an October 2009 issue of TechNet Magazine, Microsoft called proficiency with PowerShell «the single most important skill a Windows administrator will need in the coming years».^[19]

Windows 10 shipped a testing framework for PowerShell.^[20]

On August 18, 2016, Microsoft announced^[21] that they had made PowerShell open-source and cross-platform with support for Windows, macOS, CentOS and Ubuntu.^[5] The source code was published on GitHub.^[22] The move to open source created a second incarnation of PowerShell called «PowerShell Core», which runs on .NET Core. It is distinct from «Windows PowerShell», which runs on the full .NET Framework.^[23] Starting with version 5.1, PowerShell Core is bundled with Windows Server 2016 Nano Server.^[24][25]

Design[edit]

A key design tactic for PowerShell was to leverage the large number of APIs that already existed in Windows, Windows Management Instrumentation, .NET Framework, and other software. PowerShell cmdlets «wrap around» existing functionality. The intent with this tactic is to provide an administrator-friendly, more-consistent interface between administrators and a wide range of underlying functionality. With PowerShell, an administrator doesn’t need to know .NET, WMI, or low-level API coding, and can instead focus on using the cmdlets exposed by PowerShell. In this regard, PowerShell creates little new functionality, instead focusing on making existing functionality more accessible to a particular audience.^[26]

Grammar[edit]

PowerShell’s developers based the core grammar of the tool on that of the POSIX 1003.2 KornShell.^[27]

However, PowerShell’s language was also influenced by PHP, Perl, and many other existing languages.^[28]

Named Commands[edit]

Windows PowerShell can execute four kinds of named commands:^[29]

• cmdlets (.NET Framework programs designed to interact with PowerShell)
• PowerShell scripts (files suffixed by .ps1)
• PowerShell functions
• Standalone executable programs

If a command is a standalone executable program, PowerShell launches it in a separate process; if it is a cmdlet, it executes in the PowerShell process. PowerShell provides an interactive command-line interface, where the commands can be entered and their output displayed. The user interface offers customizable tab completion. PowerShell enables the creation of aliases for cmdlets, which PowerShell textually translates into invocations of the original commands. PowerShell supports both named and positional parameters for commands. In executing a cmdlet, the job of binding the argument value to the parameter is done by PowerShell itself, but for external executables, arguments are parsed by the external executable independently of PowerShell interpretation.^[30]

Extended Type System[edit]

The PowerShell Extended Type System (ETS) is based on the .NET type system, but with extended semantics (for example, propertySets and third-party extensibility). For example, it enables the creation of different views of objects by exposing only a subset of the data fields, properties, and methods, as well as specifying custom formatting and sorting behavior. These views are mapped to the original object using XML-based configuration files.^[31]

Cmdlets[edit]

Cmdlets are specialized commands in the PowerShell environment that implement specific functions. These are the native commands in the PowerShell stack. Cmdlets follow a Verb—Noun naming pattern, such as Get-ChildItem, which makes it self-documenting code.^[32] Cmdlets output their results as objects and can also receive objects as input, making them suitable for use as recipients in a pipeline. If a cmdlet outputs multiple objects, each object in the collection is passed down through the entire pipeline before the next object is processed.^[32]

Cmdlets are specialized .NET classes, which the PowerShell runtime instantiates and invokes at execution time. Cmdlets derive either from Cmdlet or from PSCmdlet, the latter being used when the cmdlet needs to interact with the PowerShell runtime.^[32] These base classes specify certain methods – BeginProcessing(), ProcessRecord() and EndProcessing() – which the cmdlet’s implementation overrides to provide the functionality. Whenever a cmdlet runs, PowerShell invokes these methods in sequence, with ProcessRecord() being called if it receives pipeline input.^[33] If a collection of objects is piped, the method is invoked for each object in the collection. The class implementing the cmdlet must have one .NET attribute – CmdletAttribute – which specifies the verb and the noun that make up the name of the cmdlet. Common verbs are provided as an enum.^[34][35]

If a cmdlet receives either pipeline input or command-line parameter input, there must be a corresponding property in the class, with a mutator implementation. PowerShell invokes the mutator with the parameter value or pipeline input, which is saved by the mutator implementation in class variables. These values are then referred to by the methods which implement the functionality. Properties that map to command-line parameters are marked by ParameterAttribute^[36] and are set before the call to BeginProcessing(). Those which map to pipeline input are also flanked by ParameterAttribute, but with the ValueFromPipeline attribute parameter set.^[37]

The implementation of these cmdlet classes can refer to any .NET API and may be in any .NET language. In addition, PowerShell makes certain APIs available, such as WriteObject(), which is used to access PowerShell-specific functionality, such as writing resultant objects to the pipeline. Cmdlets can use .NET data access APIs directly or use the PowerShell infrastructure of PowerShell Providers, which make data stores addressable using unique paths. Data stores are exposed using drive letters, and hierarchies within them, addressed as directories. Windows PowerShell ships with providers for the file system, registry, the certificate store, as well as the namespaces for command aliases, variables, and functions.^[38] Windows PowerShell also includes various cmdlets for managing various Windows systems, including the file system, or using Windows Management Instrumentation to control Windows components. Other applications can register cmdlets with PowerShell, thus allowing it to manage them, and, if they enclose any datastore (such as a database), they can add specific providers as well.^{[citation needed]}

The number of cmdlets included in the base PowerShell install has generally increased with each version:

Cmdlets can be added into the shell through snap-ins (deprecated in v2) and modules; users are not limited to the cmdlets included in the base PowerShell installation.

Pipeline[edit]

PowerShell implements the concept of a pipeline, which enables piping the output of one cmdlet to another cmdlet as input. For example, the output of the Get-Process cmdlet could be piped to the Where-Object to filter any process that has less than 1 MB of paged memory, and then to the Sort-Object cmdlet (e.g., to sort the objects by handle count), and then finally to the Select-Object cmdlet to select just the first ten processes based on handle count.^{[citation needed]}

As with Unix pipelines, PowerShell pipelines can construct complex commands, using the | operator to connect stages. However, the PowerShell pipeline differs from Unix pipelines in that stages execute within the PowerShell runtime rather than as a set of processes coordinated by the operating system. Additionally, structured .NET objects, rather than byte streams, are passed from one stage to the next. Using objects and executing stages within the PowerShell runtime eliminates the need to serialize data structures, or to extract them by explicitly parsing text output.^[43] An object can also encapsulate certain functions that work on the contained data, which become available to the recipient command for use.^[44][45] For the last cmdlet in a pipeline, PowerShell automatically pipes its output object to the Out-Default cmdlet, which transforms the objects into a stream of format objects and then renders those to the screen.^[46][47]

Because all PowerShell objects are .NET objects, they share a .ToString() method, which retrieves the text representation of the data in an object. In addition, PowerShell allows formatting definitions to be specified, so the text representation of objects can be customized by choosing which data elements to display, and in what manner. However, in order to maintain backward compatibility, if an external executable is used in a pipeline, it receives a text stream representing the object, instead of directly integrating with the PowerShell type system.^[48][49][50]

Scripting[edit]

Windows PowerShell includes a dynamically typed scripting language which can implement complex operations using cmdlets imperatively. The scripting language supports variables, functions, branching (if-then-else), loops (while, do, for, and foreach), structured error/exception handling and closures/lambda expressions,^[51] as well as integration with .NET. Variables in PowerShell scripts are prefixed with $. Variables can be assigned any value, including the output of cmdlets. Strings can be enclosed either in single quotes or in double quotes: when using double quotes, variables will be expanded even if they are inside the quotation marks. Enclosing the path to a file in braces preceded by a dollar sign (as in ${C:\foo.txt}) creates a reference to the contents of the file. If it is used as an L-value, anything assigned to it will be written to the file. When used as an R-value, the contents of the file will be read. If an object is assigned, it is serialized before being stored.^{[citation needed]}

Object members can be accessed using . notation, as in C# syntax. PowerShell provides special variables, such as $args, which is an array of all the command line arguments passed to a function from the command line, and $_, which refers to the current object in the pipeline.^[52] PowerShell also provides arrays and associative arrays. The PowerShell scripting language also evaluates arithmetic expressions entered on the command line immediately, and it parses common abbreviations, such as GB, MB, and KB.^[53][54]

Using the function keyword, PowerShell provides for the creation of functions. A simple function has the following general look:^[55]

function name ([Type]$Param1, [Type]$Param2) {
  # Instructions
}

However, PowerShell allows for advanced functions that support named parameters, positional parameters, switch parameters and dynamic parameters.^[55]

function Verb-Noun {
  param (
    # Definition of static parameters
  )
  dynamicparam {
    # Definition of dynamic parameters
  }
  begin {
    # Set of instruction to run at the start of the pipeline
  }
  process {
    # Main instruction sets, ran for each item in the pipeline
  }
  end {
    # Set of instruction to run at the end of the pipeline
  }
}

The defined function is invoked in either of the following forms:^[55]

name value1 value2
Verb-Noun -Param1 value1 -Param2 value2

PowerShell allows any static .NET methods to be called by providing their namespaces enclosed in brackets ([]), and then using a pair of colons (::) to indicate the static method.^[56] For example:

[Console]::WriteLine("PowerShell")

There are dozens of ways to create objects in PowerShell. Once created, one can access the properties and instance methods of an object using the . notation.^[56]

PowerShell accepts strings, both raw and escaped. A string enclosed between single quotation marks is a raw string while a string enclosed between double quotation marks is an escaped string. PowerShell treats straight and curly quotes as equivalent.^[57]

The following list of special characters is supported by PowerShell:^[58]

For error handling, PowerShell provides a .NET-based exception-handling mechanism. In case of errors, objects containing information about the error (Exception object) are thrown, which are caught using the try ... catch construct (although a trap construct is supported as well). PowerShell can be configured to silently resume execution, without actually throwing the exception; this can be done either on a single command, a single session or perpetually.^[59]

Scripts written using PowerShell can be made to persist across sessions in either a .ps1 file or a .psm1 file (the latter is used to implement a module). Later, either the entire script or individual functions in the script can be used. Scripts and functions operate analogously with cmdlets, in that they can be used as commands in pipelines, and parameters can be bound to them. Pipeline objects can be passed between functions, scripts, and cmdlets seamlessly. To prevent unintentional running of scripts, script execution is disabled by default and must be enabled explicitly.^[60] Enabling of scripts can be performed either at system, user or session level. PowerShell scripts can be signed to verify their integrity, and are subject to Code Access Security.^[61]

The PowerShell scripting language supports binary prefix notation similar to the scientific notation supported by many programming languages in the C-family.^[62]

Hosting[edit]

One can also use PowerShell embedded in a management application, which uses the PowerShell runtime to implement the management functionality. For this, PowerShell provides a managed hosting API. Via the APIs, the application can instantiate a runspace (one instantiation of the PowerShell runtime), which runs in the application’s process and is exposed as a Runspace object.^[8] The state of the runspace is encased in a SessionState object. When the runspace is created, the Windows PowerShell runtime initializes the instantiation, including initializing the providers and enumerating the cmdlets, and updates the SessionState object accordingly. The Runspace then must be opened for either synchronous processing or asynchronous processing. After that it can be used to execute commands.^{[citation needed]}

To execute a command, a pipeline (represented by a Pipeline object) must be created and associated with the runspace. The pipeline object is then populated with the cmdlets that make up the pipeline. For sequential operations (as in a PowerShell script), a Pipeline object is created for each statement and nested inside another Pipeline object.^[8] When a pipeline is created, Windows PowerShell invokes the pipeline processor, which resolves the cmdlets into their respective assemblies (the command processor) and adds a reference to them to the pipeline, and associates them with InputPipe, OutputPipe and ErrorOutputPipe objects, to represent the connection with the pipeline. The types are verified and parameters bound using reflection.^[8] Once the pipeline is set up, the host calls the Invoke() method to run the commands, or its asynchronous equivalent, InvokeAsync(). If the pipeline has the Write-Host cmdlet at the end of the pipeline, it writes the result onto the console screen. If not, the results are handed over to the host, which might either apply further processing or display the output itself.^{[citation needed]}

Microsoft Exchange Server 2007 uses the hosting APIs to provide its management GUI. Each operation exposed in the GUI is mapped to a sequence of PowerShell commands (or pipelines). The host creates the pipeline and executes them. In fact, the interactive PowerShell console itself is a PowerShell host, which interprets the scripts entered at command line and creates the necessary Pipeline objects and invokes them.^{[citation needed]}

Desired State Configuration[edit]

DSC allows for declaratively specifying how a software environment should be configured.^[63]

Upon running a configuration, DSC will ensure that the system gets the state described in the configuration. DSC configurations are idempotent. The Local Configuration Manager (LCM) periodically polls the system using the control flow described by resources (imperative pieces of DSC) to make sure that the state of a configuration is maintained.

Versions[edit]

Initially using the code name «Monad», PowerShell was first shown publicly at the Professional Developers Conference in October 2003 in Los Angeles. All major releases are still supported, and each major release has featured backwards compatibility with preceding versions.

Windows PowerShell 1.0[edit]

PowerShell 1.0 was released in November 2006 for Windows XP SP2, Windows Server 2003 SP1 and Windows Vista.^[64] It is an optional component of Windows Server 2008.

Windows PowerShell 2.0[edit]

PowerShell 2.0 is integrated with Windows 7 and Windows Server 2008 R2^[65] and is released for Windows XP with Service Pack 3, Windows Server 2003 with Service Pack 2, and Windows Vista with Service Pack 1.^[66][67]

PowerShell v2 includes changes to the scripting language and hosting API, in addition to including more than 240 new cmdlets.^[68][69]

New features of PowerShell 2.0 include:^[70][71][72]

• PowerShell remoting: Using WS-Management, PowerShell 2.0 allows scripts and cmdlets to be invoked on a remote machine or a large set of remote machines.
• Background jobs: Also called a PSJob, it allows a command sequence (script) or pipeline to be invoked asynchronously. Jobs can be run on the local machine or on multiple remote machines. An interactive cmdlet in a PSJob blocks the execution of the job until user input is provided.
• Transactions: Enable cmdlet and developers can perform transactional operations. PowerShell 2.0 includes transaction cmdlets for starting, committing, and rolling back a PSTransaction as well as features to manage and direct the transaction to the participating cmdlet and provider operations. The PowerShell Registry provider supports transactions.
• Advanced functions: These are cmdlets written using the PowerShell scripting language. Initially called «script cmdlets», this feature was later renamed «advanced functions».^[73]
• SteppablePipelines: This allows the user to control when the BeginProcessing(), ProcessRecord() and EndProcessing() functions of a cmdlet are called.
• Modules: This allows script developers and administrators to organize and partition PowerShell scripts in self-contained, reusable units. Code from a module executes in its own self-contained context and does not affect the state outside the module. Modules can define a restricted runspace environment by using a script. They have a persistent state as well as public and private members.
• Data language: A domain-specific subset of the PowerShell scripting language that allows data definitions to be decoupled from the scripts and allows localized string resources to be imported into the script at runtime (Script Internationalization).
• Script debugging: It allows breakpoints to be set in a PowerShell script or function. Breakpoints can be set on lines, line & columns, commands and read or write access of variables. It includes a set of cmdlets to control the breakpoints via script.
• Eventing: This feature allows listening, forwarding, and acting on management and system events. Eventing allows PowerShell hosts to be notified about state changes to their managed entities. It also enables PowerShell scripts to subscribe to ObjectEvents, PSEvents, and WmiEvents and process them synchronously and asynchronously.
• Windows PowerShell Integrated Scripting Environment (ISE): PowerShell 2.0 includes a GUI-based PowerShell host that provides integrated debugger, syntax highlighting, tab completion and up to 8 PowerShell Unicode-enabled consoles (Runspaces) in a tabbed UI, as well as the ability to run only the selected parts in a script.
• Network file transfer: Native support for prioritized, throttled, and asynchronous transfer of files between machines using the Background Intelligent Transfer Service (BITS).^[74]
• New cmdlets: Including Out-GridView, which displays tabular data in the WPF GridView object, on systems that allow it, and if ISE is installed and enabled.
• New operators: -Split, -Join, and Splatting (@) operators.
• Exception handling with Try-Catch-Finally: Unlike other .NET languages, this allows multiple exception types for a single catch block.
• Nestable Here-Strings: PowerShell Here-Strings have been improved and can now nest.^[75]
• Block comments: PowerShell 2.0 supports block comments using <# and #> as delimiters.^[76]
• New APIs: The new APIs range from handing more control over the PowerShell parser and runtime to the host, to creating and managing collection of Runspaces (RunspacePools) as well as the ability to create Restricted Runspaces which only allow a configured subset of PowerShell to be invoked. The new APIs also support participation in a transaction managed by PowerShell

Windows PowerShell 3.0[edit]

PowerShell 3.0 is integrated with Windows 8 and with Windows Server 2012. Microsoft has also made PowerShell 3.0 available for Windows 7 with Service Pack 1, for Windows Server 2008 with Service Pack 1, and for Windows Server 2008 R2 with Service Pack 1.^[77][78]

PowerShell 3.0 is part of a larger package, Windows Management Framework 3.0 (WMF3), which also contains the WinRM service to support remoting.^[78] Microsoft made several Community Technology Preview releases of WMF3. An early community technology preview 2 (CTP 2) version of Windows Management Framework 3.0 was released on December 2, 2011.^[79] Windows Management Framework 3.0 was released for general availability in December 2012^[80] and is included with Windows 8 and Windows Server 2012 by default.^[81]

New features in PowerShell 3.0 include:^{[78][82]: 33–34}

• Scheduled jobs: Jobs can be scheduled to run on a preset time and date using the Windows Task Scheduler infrastructure.
• Session connectivity: Sessions can be disconnected and reconnected. Remote sessions have become more tolerant of temporary network failures.
• Improved code writing: Code completion (IntelliSense) and snippets are added. PowerShell ISE allows users to use dialog boxes to fill in parameters for PowerShell cmdlets.
• Delegation support: Administrative tasks can be delegated to users who do not have permissions for that type of task, without granting them perpetual additional permissions.
• Help update: Help documentations can be updated via Update-Help command.
• Automatic module detection: Modules are loaded implicitly whenever a command from that module is invoked. Code completion works for unloaded modules as well.
• New commands: Dozens of new modules were added, including functionality to manage disks get-WmiObject win32_logicaldisk, volumes, firewalls, network connections, and printers, which had previously been performed via WMI.^{[further explanation needed]}

Windows PowerShell 4.0[edit]

PowerShell 4.0 is integrated with Windows 8.1 and with Windows Server 2012 R2. Microsoft has also made PowerShell 4.0 available for Windows 7 SP1, Windows Server 2008 R2 SP1 and Windows Server 2012.^[83]

New features in PowerShell 4.0 include:

• Desired State Configuration:^[84][85][86] Declarative language extensions and tools that enable the deployment and management of configuration data for systems using the DMTF management standards and WS-Management Protocol
• New default execution policy: On Windows Servers, the default execution policy is now RemoteSigned.
• Save-Help: Help can now be saved for modules that are installed on remote computers.
• Enhanced debugging: The debugger now supports debugging workflows, remote script execution and preserving debugging sessions across PowerShell session reconnections.
• -PipelineVariable switch: A new ubiquitous parameter to expose the current pipeline object as a variable for programming purposes
• Network diagnostics to manage physical and Hyper-V’s virtualized network switches
• Where and ForEach method syntax provides an alternate method of filtering and iterating over objects.

Windows PowerShell 5.0[edit]

Windows Management Framework (WMF) 5.0 RTM which includes PowerShell 5.0 was re-released to web on February 24, 2016, following an initial release with a severe bug.^[87]

Key features included:

• The new class keyword that creates classes for object-oriented programming
• The new enum keyword that creates enums
• OneGet cmdlets to support the Chocolatey package manager^[88]
• Extending support for switch management to layer 2 network switches.^[89]
• Debugging for PowerShell background jobs and instances of PowerShell hosted in other processes (each of which is called a «runspace»)
• Desired State Configuration (DSC) Local Configuration Manager (LCM) version 2.0
• DSC partial configurations
• DSC Local Configuration Manager meta-configurations
• Authoring of DSC resources using PowerShell classes

Windows PowerShell 5.1[edit]

It was released along with the Windows 10 Anniversary Update^[90] on August 2, 2016, and in Windows Server 2016.^[91] PackageManagement now supports proxies, PSReadLine now has ViMode support, and two new cmdlets were added: Get-TimeZone and Set-TimeZone. The LocalAccounts module allows for adding/removing local user accounts.^[92] A preview for PowerShell 5.1 was released for Windows 7, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 on July 16, 2016,^[93] and was released on January 19, 2017.^[94]

PowerShell 5.1 is the first version to come in two editions of «Desktop» and «Core». The «Desktop» edition is the continuation of the traditional Windows PowerShell that runs on the .NET Framework stack. The «Core» edition runs on .NET Core and is bundled with Windows Server 2016 Nano Server. In exchange for smaller footprint, the latter lacks some features such as the cmdlets to manage clipboard or join a computer to a domain, WMI version 1 cmdlets, Event Log cmdlets and profiles.^[25] This was the final version of PowerShell made exclusively for Windows.

PowerShell Core 6[edit]

PowerShell Core 6.0 was first announced on August 18, 2016, when Microsoft unveiled PowerShell Core and its decision to make the product cross-platform, independent of Windows, free and open source.^[5] It achieved general availability on January 10, 2018, for Windows, macOS and Linux.^[95] It has its own support lifecycle and adheres to the Microsoft lifecycle policy that is introduced with Windows 10: Only the latest version of PowerShell Core is supported. Microsoft expects to release one minor version for PowerShell Core 6.0 every six months.^[96]

The most significant change in this version of PowerShell is the expansion to the other platforms. For Windows administrators, this version of PowerShell did not include any major new features. In an interview with the community on January 11, 2018, the PowerShell team was asked to list the top 10 most exciting things that would happen for a Windows IT professional who would migrate from Windows PowerShell 5.1 to PowerShell Core 6.0; in response, Angel Calvo of Microsoft could only name two: cross-platform and open-source.^[97]

6.1[edit]

According to Microsoft, one of the new features of PowerShell 6.1 is «Compatibility with 1900+ existing cmdlets in Windows 10 and Windows Server 2019.»^[98] Still, no details of these cmdlets can be found in the full version of the change log.^[99] Microsoft later professes that this number was insufficient as PowerShell Core failed to replace Windows PowerShell 5.1 and gain traction on Windows.^[100] It was, however, popular on Linux.^[100]

6.2[edit]

PowerShell Core 6.2 is focused primarily on performance improvements, bug fixes, and smaller cmdlet and language enhancements that improved developer productivity.^[101]

PowerShell 7[edit]

PowerShell 7 is the replacement for PowerShell Core 6.x products as well as Windows PowerShell 5.1, which is the last supported Windows PowerShell version.^[102][100] The focus in development was to make PowerShell 7 a viable replacement for Windows PowerShell 5.1, i.e. to have near parity with Windows PowerShell in terms of compatibility with modules that ship with Windows.^[103]

New features in PowerShell 7 include:^[104]

• The -Parallel switch for the ForEach-Object cmdlet to help handle parallel processing
• Near parity with Windows PowerShell in terms of compatibility with built-in Windows modules
• A new error view
• The Get-Error cmdlet
• Pipeline chaining operators (&& and ||) that allow conditional execution of the next cmdlet in the pipeline
• The ?: operator for ternary operation
• The ?? operator for null coalescing
• The ??= operator for null coalescing assignment
• Cross-platform Invoke-DscResource (experimental)
• Return of the Out-GridView cmdlet
• Return of the -ShowWindow switch for the Get-Help

PowerShell 7.2[edit]

PowerShell 7.2 is the next long-term support version of PowerShell, after version 7.0. It uses .NET 6.0 and features universal installer packages for Linux. On Windows, updates to PowerShell 7.2 and later come via the Microsoft Update service; this feature has been missing from PowerShell 6.0 through 7.1.^[105]

PowerShell 7.3[edit]

This version includes some general Cmdlet updates and fixes, testing for framework dependent package in release pipeline as well as build and packaging improvements.^[106]

PowerShell 7.4[edit]

This section is empty. You can help by adding to it. (April 2023)

Comparison of cmdlets with similar commands[edit]

The following table contains a selection of the cmdlets that ship with PowerShell, noting similar commands in other well-known command-line interpreters. Many of these similar commands come out-of-the-box defined as aliases within PowerShell, making it easy for people familiar with other common shells to start working.

Notes

Filename extensions[edit]

Application support[edit]

Alternative implementation[edit]

A project named Pash, a pun on the widely known «bash» Unix shell, has been an open-source and cross-platform reimplementation of PowerShell via the Mono framework.^[135] Pash was created by Igor Moochnick, written in C# and was released under the GNU General Public License. Pash development stalled in 2008, was restarted on GitHub in 2012,^[136] and finally ceased in 2016 when PowerShell was officially made open-source and cross-platform.^[137]

See also[edit]

• Common Information Model (computing)
• Comparison of command shells
• Comparison of programming languages
• Web-Based Enterprise Management
• Windows Script Host
• Windows Terminal

References[edit]

Further reading[edit]

• Finke, Douglas (2012). Windows PowerShell for Developers. O’Reilly Media. ISBN 978-1-4493-2270-0.
• Holmes, Lee (2006). Windows PowerShell Quick Reference. O’Reilly Media. ISBN 0-596-52813-2.
• Holmes, Lee (2007). Windows PowerShell Cookbook. O’Reilly Media. ISBN 978-0-596-52849-2.
• Jones, Don; Hicks, Jeffery (2010). Windows PowerShell 2.0: TFM (3rd ed.). Sapien Technologies. ISBN 978-0-9821314-2-8.
• Jones, Don (2020). Shell of an Idea: The Untold History of PowerShell. Self-published. ISBN 978-1-9536450-3-6.
• Kopczynski, Tyson; Handley, Pete; Shaw, Marco (2009). Windows PowerShell Unleashed (2nd ed.). Pearson Education. ISBN 978-0-672-32988-3.
• Kumaravel, Arul; White, Jon; Naixin Li, Michael; Happell, Scott; Xie, Guohui; Vutukuri, Krishna C. (2008). Professional Windows PowerShell Programming: Snapins, Cmdlets, Hosts and Providers. Wrox Press. ISBN 978-0-470-17393-0.
• Oakley, Andy (2005). Monad (AKA PowerShell). O’Reilly Media. ISBN 0-596-10009-4.
• Watt, Andrew (2007). Professional Windows PowerShell. Wrox Press. ISBN 978-0-471-94693-9.
• Wilson, Ed (2013). Windows PowerShell 3.0 Step by Step. Microsoft Press. ISBN 978-0-7356-6339-8.
• Wilson, Ed (2014). Windows PowerShell Best Practices. Microsoft Press. ISBN 978-0-7356-6649-8.

External links[edit]

• Official website
• PowerShell on GitHub
• Windows PowerShell Survival Guide on TechNet Wiki