Как писать и как запускать скрипты PowerShell. Powershell: как работать с программой, создавать, запускать и изменять скрипты Powershell изменение политики выполнения скриптов

Запуск программы из PowerShell

Задача запустить из PowerShell какой либо исполняемый файл (программу или утилиту командной строки) встречается достаточно часто. PowerShell предлагает для этого несколько различных способов, которые мы и рассмотрим далее в этой статье. Начнем с самого простого…

Прямой запуск

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

Set-Location ″C:\Program Files″
.\Hello.exe

Обратите внимание, что даже находясь в нужном каталоге, требуется указывать относительный путь к исполняемому файлу. Исключение составляют файлы из директорий, перечисленных в переменной окружения (path). Например различные встроенные программы и утилиты (notepad, calc, ping и т.п.), находящиеся в директории Windows\System32, можно запускать без указания пути.

Оператор &

Если необходимо указать полный путь к исполняемому файлу, то можно воспользоваться оператором & (оператор вызова). Он позволяет выполнить строку текста, указанную в кавычках, как единую команду. Например:

& ′C:\Program Files\Hello.exe′

Поскольку оператор & не анализирует передаваемую команду, то он не может интерпретировать ее параметры. Поэтому дополнительные параметры\аргументы передаются также в виде текста, в кавычках. Для примера возьмем предыдущую программу и немного изменим ее, так что она принимает нужный текст в виде аргумента:

& ′C:\Program Files\Hello.exe′ ′Hello, world′

При желании можно указать нескольких аргументов через запятую:

& ′C:\Program Files\Hello.exe′ ′Hello,′, ′ world′

Для удобства команду и аргументы можно поместить в переменные:

$exe = ′C:\Program Files\Hello.exe′
$arg1 = ′Hello′
$arg2 = ′world′
& $exe $arg1 $arg2

Ну и если аргументов много, то их можно объединить, воспользовавшись такой конструкцией:

$exe = ′C:\Program Files\Hello.exe′
$allargs = @(′Hello,′,′world′)
& $exe $allargs

Invoke-Expression

Командлет Invoke-Expression работает примерно так-же, как и оператор & — берет текстовую строку и выполняет ее в виде команды. Например:

Invoke-Expression -Command ′C:\Windows\Hello.exe′

Однако у него есть один большой недостаток, а именно — неумение работать с пробелами. К примеру, следующая команда вызовет ошибку:

Invoke-Expression -Command ′C:\Program Files\Hello.exe′

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

Invoke-Expression -Command ″C:\′Program Files′\Hello.exe″

Start-Process

Командлет Start-Process запускает указанный файл в виде процесса, используя метод Start .NET класса Process . Например:

Start-Process -FilePath ′C:\Program Files\Hello.exe′

По умолчанию процесс выполняется в отдельном окне, которое закрывается по окончании процесса. Изменить такое поведение можно с помощью параметров, так следующая команда запустится в текущем окне:

Start-Process -FilePath ′C:\Program Files\Hello.exe′ -NoNewWindow -Wait

Также Start-Process позволяет передать в процесс дополнительные аргументы:

Start-Process -FilePath ′C:\Program Files\Hello.exe′ -ArgumentList ′Hello, world′ -NoNewWindow -Wait

По умолчанию командлет ничего не возвращает, но с помощью параметра -PassThru можно заставить его вернуть объект процесса. Этот объект очень удобно поместить в переменную:

$process = Start-Process -FilePath ′C:\Program Files\Hello.exe′ -Wait -PassThru

из которой можно затем можно узнать многие полезные вещи, такие как статус:

$process.HasExited

$process.ExitTime

или код выполнения:

$process.ExitCode

.NET

В принципе.NET классом Process можно воспользоваться напрямую, без командлета Start-Process. К примеру, запустить процесс можно командой:

::Start(′C:\Program Files\Hello.exe′)

Такой способ достаточно неудобен и громоздок (на мой взгляд), но чуть более гибок в использовании. Для примера запустим нашу программу в текущем окне, передадим в нее аргументы и заберем результат выполнения:

$process = New-Object -TypeName System.Diagnostics.Process
$process.StartInfo.FileName = ″C:\Program Files\Hello.exe″
$process.StartInfo.Arguments = ″Hello,world″
$process.StartInfo.RedirectStandardOutput = $true
$process.StartInfo.UseShellExecute = $false
$process.Start()
$process.WaitForExit()

$process.StandatdOutput.ReadToEnd()

WMI

С помощью WMI можно сделать практически все, в том числе и запустить программу. Для этого вполне подойдет метод Create WMI-класса Win32_Process. Этот метод запускает процесс на локальном или удаленном компьютере через RPC. Например, для выполнения программы на локальном компьютере можно воспользоваться такой командой:

()″Win32_Process″).Create(′C:\Program Files\Hello.exe′)

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

()″\\remotecomputer\root\cimv2:Win32_Process″).Create(′C:\Program Files\Hello.exe′)

Как вариант, можно воспользоваться командлетом Invoke-WmiMethod:

Invoke-WmiMethod -Class Win32_Process -Name Create -ArgumentList ″C:\Program Files\Hello.exe″

Либо командлетом Invoke-CimMethod:

Invoke-CimMethod -ClassName Win32_Process -MethodName Create -Arguments @{CommandLine=″C:\Program Files\Hello.exe″}

WMI запускает процесс в отдельном окне и возвращает объект, содержащий идентификатор процесса (ProcessID) и результат выполнения (ReturnValue). ReturnValue может принимать следующие значения:

0 — Sucsessful Completiom
2 — Access Denied
3 — Insufficient Privilege
8 — Uncnown Failure
9 — Path Not Found
21 — Invalid Parameter

Invoke-Command

Командлет Invoke-Command умеет выполнять команды на локальном или удаленном компьютере, используя WinRM. Например, для запуска нашей программы на локальном компьютере используем команду:

Invoke-Command -ScriptBlock {″C:\′Program Files′\Hello.exe″}

При необходимости в программу можно передать аргументы:

Invoke-Command -ScriptBlock {C:\′Program Files′\Hello.exe ″Hello,world″}

Обратите внимание, что Invoke-Command не очень дружит с пробелами, поэтому во избежании ошибок приходится исхитряться с кавычками. Впрочем, подобных проблем можно избежать, например комбинируя использования командлета с оператором &:

Invoke-Command -ScriptBlock {& ′C:\Program Files\Hello.exe′}

В основном Invoke-Command применяется для удаленного управления, его главное достоинство — это возможность одновременного выполнения на нескольких компьютерах. Например:

Invoke-Command -ScriptBlock {″C:\′Program Files′\Hello.exe″} -ComputerName SRV1,SRV2,SRV3

$scriptblock = {″C:\′Program Files′\Hello.exe″}
$Computers = @(′SRV1′,′SRV2′,′SRV3′)
Invoke-Command -ScriptBlock $scriptblock -ComputerName $Computers

По умолчанию командлет возвращает результат выполнения программы, а если запустить его в фоновом режиме (параметр -AsJob), то возвращает объект Job:

Invoke-Command -ScriptBlock {C:\′Program Files′\Hello.exe} -ComputerName localhost -AsJob -JobName Hello

Invoke-Item

Командлет Invoke-Item предназначен для применения к файлу действия по умолчанию. Так запустить исполняемый файл можно командой:

Invoke-Item -Path ″C:\Program Files\Hello.exe″

Однако наиболее удобно использовать Invoke-Item для открытия определенного типа файлов. Например так мы откроем текстовый файл:

Invoke-Item -Path ″C:\Files\test.txt″

А так все текстовые файлы в папке:

Invoke-Item -Path ″C:\Files\*.txt″

CMD

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

cmd /c ″C:\Program Files\Hello.exe″

Такое вот изобилие способов запустить программу предоставляет PoSh. И каждый из них хорош для определенных ситуаций.

Кстати, статья написана по мотивам PowerShell: Deep Dive and Best Practice . Рекомендую почитать, там еще много интересного.

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


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

Ограниченный (Restricted)
Значение по умолчанию. Блокируется выполнение любых скриптов и разрешается работа интерактивных команд.
Все подписанные (All Signed)
Разрешено выполнение скриптов, имеющих цифровую подпись.
Удаленные подписанные (Remote Signed)
Локальные скрипты работают без подписи. Все скачанные скрипты должны иметь цифровую подпись.
Неограниченный (Unrestricted)
Разрешено выполнение любых скриптов. При запуске не подписанного скрипта, который был загружен из Интернета, программа может потребовать подтверждение.
Обходной (Bypass)
Ничего не блокируется, никакие предупреждения и запросы не появляются.

По умолчанию для PowerShell используется режим «Ограниченный» . В этом режиме, PowerShell работает как интерактивная оболочка. Если вы ранее не настраивали PowerShell, то вместо работы скрипта вы увидите сообщение об ошибке, написанное красным шрифтом как на скриншоте ниже.

Самым безопасным способом решения этой проблемы является – изменение политики выполнения на неограниченную, запуск скрипта, и затем обратный возврат к ограниченной политике.

Для изменения политики выполнения на неограниченную, воспользуемся консолью PowerShell с правами Администратора и выполним следующую команду:

Y (Да )

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

После запуска команды вам будет предложено подтвердить изменение политики выполнения. Ответим Y (Да )

Блокируется выполнение любых скриптов. Значение по умолчанию.

Set-ExecutionPolicy Restricted

Разрешено выполнение скриптов, имеющих цифровую подпись.

Скрипты, подготовленные на локальном компьютере, можно запускать без ограничений, скрипты, загруженные из Интернета - только при наличии цифровой подписи.

Set-ExecutionPolicy RemoteSigned

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

Set-ExecutionPolicy Unrestricted

Ничего не блокируется, никакие предупреждения и запросы не появляются.

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

Set-ExecutionPolicy Bypass -Force

Теперь при выполнении команд не нужно подтверждать производимые изменения.

Запуск PowerShell скрипта

Данная заметка посвящена описанию настройки необходимых параметров для запуска PowerShell скриптов. Чаще при первом запуске .ps1 скриптов вы видите следующие ошибки:

Файл невозможно загрузить. Файл не имеет цифровой подписи. Скрипт не будет выполнен в системе. Чтобы получить дополнительные сведения, введите команду «Get-Help about_signing».
The file cannot be loaded. The file is not digitally signed. The script will not execute on the system. Please see «Get-Help about_Signing» for more details.

Запустить программу от ненадежного издателя? Файл опубликован CN=Этот издатель не помечен как надежный в данной системе. Выполнять следует только скрипты надежных издателей.
[V] Никогда не выполнять [D] Не выполнять [R] Выполнить один раз [A] Всегда выполнять [?] Справка (по умолчанию «D»):
Do you want to run software from this untrusted publisher? The file is published by CN=This publisher is not trusted on your system. Only run scripts from trusted publishers.
[V] Never run [D] Do not run [R] Run once [A] Always run [?] Help (default is «D»):

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

Set-ExecutionPolicy Unrestricted LocalMachine

Конечно, такой подход не применим в корпоративной среде, поэтом разберемся более подробно с данной ситуацией. Посмотреть текущие настройки политики во всех областях применения можно выполнив командлет Get-Executionpolicy с параметром list.

get-executionpolicy -list

Scope ExecutionPolicy
—— —————
MachinePolicy Unrestricted
UserPolicy Undefined
Process RemoteSigned
CurrentUser AllSigned
LocalMachine Restricted

Данная политика может принимать 6 значений:

Restricted (Политика выполняется по умолчанию. Например если во всех областях применения стоит значение Undefined)
— Допускает отдельные команды, но скрипты выполнять нельзя.
— Препятствует выполнению всех файлов скриптов, включая файлы форматирования и конфигурации (PS1XML), файлы скриптов модулей (PSM1) и профили Windows PowerShell (PS1).

AllSigned

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

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

Unrestricted
— Могут выполняться неподписанные скрипты. (Имеется риск выполнения вредоносных скриптов.)
— Предупреждает пользователя перед выполнением скриптов и файлов конфигурации, загруженных из Интернета.

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

Undefined
— В текущей области не задана политика выполнения.
— Если политика выполнения во всех областях имеет значение Undefined, действует политика выполнения Restricted, которая является политикой выполнения по умолчанию.

Существует пять областей применения данной политики и параметров:

MachinePolicy и UserPolicy задаются политиками AD или локальными политиками данного компьютера.
Process — область применения текущая ссесия. В справке говорится, что её значение хранится в переменной $PSExecutionPolicyPreference однако получить/изменить значение данной политики через переменную не удалось. Измения сделанные на эту область применения ни как не повлияют на другие сессии.
CurrentUser — область применения текущей пользователь. Её значение хранится в разделе реестра HKEY_CURRENT_USER («HKEY_CURRENT_USER\Software\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell\ExecutionPolicy»).
LocalMachine — область применения на всех пользователей текущего компьютера. Она хранится в разделе реестра HKEY_LOCAL_MACHINE(«HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\ScriptedDiagnostics\ExecutionPolicy»).

У команды get-executionpolicy есть параметр -Scope. С помощью данного параметра можно выбрать область применения для которого отобразиться значение политики.

Get-ExecutionPolicy -scope Process

Результат выполнения командлета: RemoteSigned

При этом Области применения имеют приоритет высшим обладает MachinePolicy, потом UserPolicy, Process, CurrentUser и самый низкий приоритет у LocalMachine.
Поэтому в примере:

Scope ExecutionPolicy
—— —————
MachinePolicy Unrestricted
UserPolicy Undefined
Process RemoteSigned
CurrentUser AllSigned
LocalMachine Restricted

В текущей ссесии результирующая политика будет иметь значение Unrestricted.

Для того что бы узнать значение политики выполнения скриптов для данной сесии, надо применить командлет Get-ExecutionPolicy без параметров.

Вывод: Unrestricted

Изменение политики выполнения скриптов PowerShell:

Что бы изменять значение политик выполнения скриптов PowerShell, существует коммандлет Set-ExecutionPolicy.
Данный командлет имеет следующие параметры:

-ExecutionPolicy
Указывает значение политики. Может иметь следующие значения: Restricted, AllSigned, RemoteSigned, Unrestricted, Bypass, Undefined. Данный параметр обязательный для указания. Если не указан, во время выполнения комадлет попросит указать значения.

Вывод:
Укажите значения для следующих параметров:
ExecutionPolicy:

-Scope
Определяет область применения данной политики. Может иметь следующие значения: LocalMachine ,Process, CurrentUser. Если параметр области применения не указан, по умолчанию указывается значение LocalMachine.

Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope Process

Set-ExecutionPolicy Unrestricted Process

-Force
С этим параметром командлет не будет требовать подтверждения со стороны пользователя. Например:

Set-ExecutionPolicy Unrestricted Process -Force

Командлет ничего не выведет на экран и применит значение политики.

-Confirm
Если же вам наоборот мало одного подтверждения. Можно указать параметр Confirm и у вас будет ещё один, дополнительный, запрос на подтверждение ваших действий:

Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope Process -confirm

Результат выполнения:

Подтверждение
Вы действительно хотите выполнить это действие?
Выполнение операции «Set-ExecutionPolicy» над целевым объектом «Unrestricted».
[Y] Да — Y [A] Да для всех — A [N] Нет — N [L] Нет для всех — L [S] Приостановить — S [?] Справка (значением по умолчанию является «Y»):

Изменение политики выполнения
Политика выполнения защищает компьютер от ненадежных сценариев. Изменение политики выполнения может поставить под угрозу безопасность системы, как описано в разделе справки, вызываемом командой about_Execution_Policies. Вы хотите изменить политику выполнения?
[Y] Да — Y [N] Нет — N [S] Приостановить — S [?] Справка (значением по умолчанию является «Y»): . exe -executionpolicy Unrestricted

Get-ExecutionPolicy -list

Результат выполнения:

Scope ExecutionPolicy
—— —————
MachinePolicy Unrestricted
UserPolicy Undefined
Process RemoteSigned
CurrentUser AllSigned
LocalMachine Restricted

Изменение параметров политики запуска скриптов, с помощью групповых политик.

В груповой политике, параметр контролирующая запуск скриптов находиться по пути:

для MachinePolicy :

Computer Configuration/Policies/Administrative Templates/Windows Components/Windows PowerShell

Конфигурация компьютера/Административные шаблоны/Компоненты Windows/Windows PowerShell

для UserPolicy :
User Configuration/Policies/Administrative Templates/Windows Components/Windows PowerShell

Конфигурация пользователя/Административные шаблоны/Компоненты Windows/Windows PowerShell

Параметр Execution Policy может принимать 3 значения.

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

Не удается загрузить файл <путь к вашему файлу>, так как выполнение скриптов запрещено для данной системы. Введите "get-help about_signing" для получения дополнительных сведений.

Смотрим как ее решить.

PowerShell обладает рядом режимов исполнения, которые определяют, какой тип кода разрешается выполнять. Все это управляется ключом реестра, живущим в HKLM. Существует 4 различных режима исполнения:

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

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

Удаленные подписанные (Remote Signed): Локальные скрипты работают без подписи. Все скачанные скрипты должны иметь цифровую подпись.

Неограниченный (Unrestricted): Все скрипты и файлы конфигурации, полученные из коммуникационных приложений, вроде Microsoft Outlook, Internet Explorer, Outlook Express и Windows Messenger работают после подтверждения, что вы понимаете, что файл исходит из Интернета; никакие цифровые подписи не требуются; данный режим подвергает вас риску работу неподписанных, вредоносных скриптов.

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

Разрешить выполнение скриптов powershell

Чтобы запускать созданные собою скрипты, необходимо разрешить выполнение ненадежных скриптов с помощью команды Set-ExecutionPolicy remotesigned и подтверждением (Внимание!!! для выполнения этой команды необходимо запустить PowerShell с правами администратора). После этого можно вновь запустить выполнения скрипта.

На вопрос жмем Y, для разрешения выполнения скриптов. После этих манипуляций вы сможете запустить ваш скрипт.

В админиcтрировании всегда есть место творчеству. Хочешь сделать какую-нибудь автоматизацию рутинной задачи? Пожалуйста! Нужно что-то регулярно проверять на активность? Не вопрос! Хочешь обработать какой-нибудь гигантский отчет и вывести только актуальные данные? Тоже можно. Все эти и многие другие задачи лучше всего решать при помощи скриптов, и язык PowerShell в случае с Windows - оптимальный выбор.

Что такое PowerShell и чем он хорош

Пользователи UNIX и Linux, а с какого-то мoмента и macOS привыкли к тому, что под рукой всегда есть Bash - немного старомодное, но универсальное и мощное средство, при помощи которого всего парой строк можно творить удивительные вещи. Прописываешь новый скрипт в cron - и готово, он уже крутится на твоем компьютере или на сервере и незаметно делает что-нибудь полезное.

Возвращаясь в Windows (а без этого иногда никак), понимаешь, что скрипты.bat хоть и хороши, но спасают не всегда: очень уж ограниченны их возможности. И если ты до сих пор считал, что PowerShell - это неведомая штуковина, ради которой нужно что-то там поднимaть и настраивать, то не спеши с выводами - он, если разобраться, совсем неплох.

Windows PowerShell - это расширяемое средство автоматизации с открытыми исходниками, которое состоит из оболочки (командной строки) и скриптового языка. Впервые он был показан в 2003 году (тогда он назывался Monad). PowerShell 2.0 вышел в составе Windows 7 и Windows Server 2008 R2 и с тех пор присутствует в Windows в качестве стандартного компонента. Его даже включили в Windows XP SP3. PowerShell построен на основе.NET Framework и интегрирован с ним. PowerShell может обращаться к COM, WMI и ADSI, а также, конечно же, исполняет консольные команды.

В общем, «пошик» имеет крепкие связи с продуктами Microsoft, будь то Active Directory или почтовый сервер Exchange. Это позволяет без подключения к оснастке сервера обращаться к ним через консоль и отдaвать команды.

Если раньше ты не интересовался PowerShell, то, скорее всего, у тебя стоит вторая версия. Я рекомендую обновиться как минимум до третьей - она содержит куда больше возможностей и полезных фишек. Если не вдаваться в подробности, то в PowerShell 2.0 входит около десятка модулей и примерно 350 команд, а в PowerShell 3.0 уже около 2300 командлетов из более чем 70 модулей. «Хакер» также писал о том, чем отличается самый новый PowerShell пятой версии из Windows 10.

Выбираем среду разработки и инструменты

Теперь давай разберемся, где удобнее всего писать код. Можно, конечно, и в «Блокноте», Notepad++ или Sublime. Но это в данном случае не самый грамотный выбор редактора. Лучше всего начинать знакомство с PowerShell, вооружившись идущим в комплекте .


Это даже не редактор, а практически полноценная среда разработки. Здесь есть функция IntelliSense, которая позволяет просматривать перечень командлетов и их параметров, переменных, утилит и прочего. Поддерживаются сниппеты, есть возможность расширения нaбора функций за счет различных аддонов. Очень полезно и окно Commands. В нем можно составлять команды в визуальном режиме: выбираешь модуль, находишь нужный командлет и задаешь ему необходимые параметры. Получившуюся команду можно скопировать в консоль или сразу запустить на выполнение. В общем, этакий конструктор для админа. Ну и конечно, есть подсветка синтаксиса, дебаггер и многое другое.

Тем не менее у PowerShell ISE есть и достойные конкуренты. Один из них - .

PowerGUI - это визуальное дополнение к PowerShell. Оно упрощает сборку собственных сценариев до выбора необходимых командлетов. Берешь то, что нужно для решения задачи, и перетаскиваешь части кода, пока не получишь скрипт. Одна из главных фишек PowerGUI - это Power Packs, готовые скрипты, опубликованные сообществом пользователей и выложенные в свобoдный доступ. Тут есть и простенькие команды вроде добавления пoльзователей, и сложные - к примеру, управление свитчами и виртуальными машинaми. Все их легко дополнять и модифицировать в соответствии с нуждами.


Фирмы Sapien - бoлее продвинутая среда, которая рассчитана на совместную разработку одного проекта большим количеством участников. Если ты когда-нибудь имел дело с Visual Studio, то, думаю, заметишь сходство. Среди полезных фишек PowerShell Studio - панель Ribbon, поддержка удаленной отладки, а также функции компилятора, которые позволяют включить скрипты в исполняемые файлы. Есть поддержка разных версий PowerShell.


Стоит упомянуть и Script Browser для Windows PowerShell ISE. Это не среда разработки, но вeсьма интересный инструмент, разработанный в Microsoft. Script Browser открывает доступ к базе готовых скриптов, которые можно использовать в качестве образцов для написания своего кода. А еще эта штука умеет анализировать код, который ты пишешь, и подсказывает, как его улучшить.


Несколько полезных трюков

Разобравшись с редактором, можно приступать к написанию кода. PowerShell - несложный язык, и, я думаю, ты быстро разберешься, что к чему. Команды здесь называются командлетами, и каждый из них состоит из двух частей. Сначала идeт действие, например Get, Set, Add, Invoke, Remove. Затем указывается то, на что действие направлено: Service, VM, AzureAccount, DHCPServerSetting. Каждая часть отделяется от другой дефисом. Получается, к примеру, get-process. Это, кстати, полезная команда, которая выводит список процессов. Скажем, если написать

get - process BadTh *

увидим что-то такое:

Handles NPM (K ) PM (K ) WS (K ) VM (M ) CPU (s ) Id ProcessName

------------------------

28 4 - 210844 - 201128 - 163 25.67 2792 BadThread

Теперь можно завершить зависший процесс:

Можно проcмотреть рекурсивно, правда уже чуть с более сложной логикой:

Можно также выполнить

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

Get - AdUser - Filter * - Properties OfficePhone | FT OfficePhone , UserPrincipalName

PowerShell в сравнении с bat

Иногда задачу можно решить как старым дедовским методом, так и при помощи PowerShell. Я рекомендую не лениться и использовать PS, хотя бы просто потому, что так ты его быстрее изучишь и сможешь применять в более сложных ситуациях. К тому же ты постепeнно оценишь его синтаксис - более элегантный и консистентный. Вот несколько примеров, как вещи делались раньше и как их можно сделать при помощи PowerShell.

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

Вот так через bat можно перезагрузить службу dnscache (или любую другую):

sc stop dnscache

sc start dnscache