Главная Windows, Новое Обзор нововведений Windows PowerShell 2.0
  • Обзор нововведений Windows PowerShell 2.0

    powershell С одной стороны, синтаксис языка практически не претерпел изменений, переучиваться не придётся – сценарии написанные для PowerShell 1.0 будут прекрасно работать и в PowerShell 2.0. С другой стороны, приятных нововведений так много, что я сразу предупреждаю – рассказать обо всех них, в одной статье просто нереально. Так что я сделаю лишь краткий обзор нового функционала, и в конце расскажу об источниках более подробной информации.

    Компонент системы

    PowerShell 2.0 сначала появится в составе операционных систем Windows 7 и Windows Server 2008 R2. Это значительный шаг для молодого языка сценариев, ведь теперь он является неотъемлемым компонентом системы. Да что там говорить, в Windows Server 2008 R2, значок PowerShell вынесен на панель задач сразу после Server Manager’а! И это не просто из за того что Microsoft хочет “продвинуть” новую технологию – немало функционала в новых системах основано на PowerShell. Взамен же PowerShell предоставляет богатые возможности по управлению различными компонентами этих систем. Кроме того, теперь вы сможете легко использовать PowerShell в групповых политиках, будучи уверены в том что он установлен на системе, и сценарий будет выполнен.
    Отдельная ситуация с Server Core. Несмотря на то что PowerShell теперь официально поддерживается в этом режиме установки системы, по умолчанию он не установлен, и это связано с самой идеологией Server Core – минимум всего. Но несмотря на это, установить PowerShell в Server Core несложно, за пару минут, одной командой:
    start /w ocsetup MicrosoftWindowsPowerShell

    Удалённое выполнение команд (Remoting)

    Одна из самых ожидаемых возможностей Windows PowerShell 2.0 это конечно Remoting. Стоит однако заметить, что в это понятие авторы PowerShell вкладывают гораздо больший смысл нежели “запустить команду на другом компьютере”. PowerShell Remoting позволит вам не просто выполнять команды на одном или нескольких удалённых компьютерах, но и отслеживать их выполнение, и получать результаты их работы. Причем как это обычно для PowerShell, и необычно для остальных – результаты работы по сети будут передаваться не в виде простого текста, а в виде объектов. Разумеется многие объекты потеряют некоторые качества в отрыве от систем на которых они были созданы – все их методы будут удалены. Но свойства останутся (и даже будут добавлены новые, такие как PSComputerName, указывающий с какого компьютера был получен объект), и  с ними можно будет работать как с остальными объектами PowerShell.
    Гибкость Remoting тоже не разочарует. Можно как выполнять отдельные команды, так и установить постоянную сессию даже или сессии, на несколько компьютеров, и выполнять в них серии команд. Это позволит во-первых сэкономить ресурсы за счет того что не будет создаваться и уничтожаться отдельное окружение PowerShell для каждой команды, а во-вторых команды из последовательности будут иметь доступ к переменным и другим объектам созданным в этой сессии предыдущими командами.
    Если вы захотите использовать интерактивные сессии, как в Telnet, SSH или PSExec, то возможно и это, с помощью командлета Enter-PSSession.

    remoting2

    Разумеется Remoting отключён на системах по умолчанию.  Хоть это и прекрасное средство управления, безопасность остаётся превыше всего. Впрочем включить его не сложно, достаточно выполнить командлет Enable-PSRemoting который спросит подтверждение (от которого можно избавиться с помощью ключа -Force), и затем выполнит все необходимые действия для предоставления удалённого доступа для учетных записей являющихся администраторами компьютера.
    Этот метод хорош когда вам надо включить Remoting на одном или нескольких компьютерах, но что делать если их десятки, сотни, тысячи? Всего лишь несколько дополнительных манипуляций. Все действия что производит командлет Enable-PSRemoting можно сделать с помощью групповой политики.
    Во-первых надо включить настройку Computer Configuration/Administrative Templates/Windows Components/Windows Remote Management (WinRM)/WinRM Service/Allow automatic configuration of listeners. В ней же можно задать диапазоны адресов с которых разрешены подключения. Во-вторых нужно создать необходимые исключения в брандмауэре Windows. Ну и наконец, установить для службы Windows Remote Management (WS-Management) автоматический режим запуска.

    Так как PowerShell Remoting использует технологию WinRM (реализацию стандарта WS-Management) он наследует множество её преимуществ. Например возможность подключаться к системам даже через прокси-серверы. Или выдающаяся безопасность – все соединения Remoting шифруются в обязательном порядке, с использованием SSL. Разумеется шифруются и передаваемые учетные данные. Кстати поддерживается несколько механизмов аутентификации – Kerberos, NTLM, Digest и Basic. Разумеется самым безопасным является Kerberos, и по умолчанию, при возможности, используется именно он.

    По умолчанию подключение можно установить лишь используя учетную запись обладающую правами администратора на удаленном компьютере. Но вы вполне можете изменить эти разрешения или даже создать отдельные конфигурации подключений для разных групп пользователей. У разных конфигураций – разные ограничения. Лимитирование объема передаваемых данных или времени выполнения команд позволит в некоторой степени защититься от пожирания ресурсов сервера одним черезчур активным пользователем. Но главное это конечно возможность ограничить список разрешенных команд, их параметров и конструкций языка. То есть вы можете разрешить определенной группе пользователей выполнять на сервере лишь командлеты Get-* для получения информации, но внести в систему изменения они не смогут. Другой группе можно дать право исполнения командлета Get-Process с параметром -Id, а все остальные параметры и команды будут недоступны.

    За другими подробностями можно обратится во встроенную справку, выполнив команду

    help about_remoting

    Фоновые работы (Jobs)

    Не менее важно и другое нововведение – фоновые работы. Те кто работал с unix-подобными системами наверняка знает что это такое, для остальных же поясню. Это команды которые выполняются в отдельной сессии, параллельно основной. То есть вы можете запустить команду требующую много времени в качестве фоновой работы, и продолжать заниматься другими делами. Можно просматривать статус выполнения работ, и при необходимости получать их результаты. В PowerShell 2.0 это реализуется с помощью командлетов с существительным Job. Команда Start-Job позволяет запустить новую работу, Get-Job – получить список работ текущей сессии и посмотреть их статус. Получить результаты выполнения команды поможет Receive-Job. Стоит обратить внимание, что после того как Receive-Job передаст вам данные, она тут же уберёт их из стека вывода работы, и вызвав командлет второй раз, вы получите лишь новые данные. Чтобы этого не происходило, используйте ключ -Keep.
    Впрочем я не буду рассказывать о действии каждого командлета *-Job, уверен вы прекрасно справитесь сами с помощью встроенной справки. Лучше упомяну о другом методе запуска фоновых работ, параметре -AsJob. Он присутствует у многих разных команд. Например Invoke-Command -AsJob позволит вам запустить продолжительную команду на нескольких компьютерах в виде работ, а затем отслеживать процесс их выполнения и результаты с помощью командлетов *-Job. Get-WmiObject -AsJob, делает примерно то же самое, но для WMI запросов. Например эта команда запрашивает значение Win32_ComputerSystem для всех компьютеров из списка Computers.txt, но не более чем на двух одновременно.

    PS C:\> $Comps = Get-Content Computers.txt
    PS C:\> $Job = Get-WmiObject Win32_ComputerSystem `
    -Computer $Comps -AsJob -ThrottleLimit 2
    PS C:\> $job.ChildJobs
    Id Name State     HasMoreData Location  Command
    — —- —–     ———– ——–  ——-
    2  Job2 Completed True        comp1
    3  Job3 Failed    False       comp2
    4  Job4 Running   False       comp3
    5  Job5 Running   False       comp4

    Результаты разумеется можно получить командлетом Receive-Job.
    Раздел справки посвященный фоновым работам – About_Jobs.

    ISE

    Хоть появление графической оболочки и среды разработки для PowerShell и не является прорывом (уже давно существует немало решений от сторонних производителей), тем не менее ISE всё таки принесет немало полезных нововведений.
    Во первых, это полноценный интерпретатор PowerShell, подобный самому PowerShell.exe, но в отличии от него не использующий консольную подсистему Windows которая не изменялась уже много лет. Это даёт прекрасную возможность начать всё сначала, и не повторять ошибок прошлого. PowerShell ISE не испытывает вообще никаких проблем с отображением Unicode и любых локальных символов. Текст можно удобно выделять, копировать и вставлять, как в любом другом приложении Windows. Разумеется нет никаких сложностей с изменением размеров окна, это делается лишь перетаскиванием края окна, без необходимости залезать в какие либо настройки. Так же легко можно поменять размер шрифта.
    Кажущаяся обычной подсветка синтаксиса, всё же отличается от аналогичной в других продуктах, тем что для разбора текста сценариев и команд используется оригинальный механизм PowerShell, а не сложные правила пытающиеся повторить его функционал. Теперь вы можете быть уверены – если редактор не подсвечивает какой то участок, или подсвечивает его не так как вы хотите, значит где то вкралась ошибка.
    Разумеется работает и автоматическое дополнение команд, параметров, переменных и свойств объектов, так же как и в обычном PowerShell.exe. Причем для этого также используется обычная функция TabExpansion, а следовательно стандартный функционал можно расширить.
    Вполне естественной для такого редактора выглядит и наличие прекрасного отладчика, с возможностью установки точек останова, просмотра содержимого переменных в процессе выполнения, и всего остального что может пригодиться для поиска ошибок при выполнении сценария.
    Кроме обычных для многих текстовых редакторов закладок в которых можно открыть разные текстовые файлы, в PowerShell ISE можно еще открывать отдельные сессии PowerShell, не соприкасающиеся друг с другом. А благодаря технологии Remoting, некоторые из этих сессий могут выполняться даже на других компьютерах!
    Но главный момент для графической среды разработки, это конечно удобство. В PowerShell ISE вы можете выбрать расположение панелей редактора, командной строки и области вывода результатов. Можно даже скрыть всё кроме редактора, и полностью погрузиться в процесс разработки своего сценария.
    ise

    Если бы этим редактор ограничивался – он бы не смог стать хорошей альтернативой конкурентам. Но к счастью ISE обладает прекрасными возможностями для расширения своего функционала… с помощью сценариев PowerShell! С помощью специальной переменной $PsIse можно получить доступ к управлению интерфейсом PowerShell ISE, добавить свои пункты меню, обрабатывать текст из панелей редактора и командной строки, и так далее. Я уверен что вскоре после релиза появится множество пользовательских сценариев преумножающих функционал ISE.
    Соответствующий раздел справки называется about_Windows_PowerShell_ISE.

    Advanced Functions

    Те кто серьезно занимался написанием своих сценариев или создавал командлеты в Windows PowerShell 1.0, наверняка обратили внимание на то, что у последних есть некоторые достаточно большие преимущества. Так например в сценарии .ps1 вы не сможете использовать несколько различных наборов параметров, создавать для параметров псевдонимы, и указывать другие атрибуты, такие как ValueFromPipeline и ValidateSet. Даже использование специальных параметров -WhatIf и -Confirm было не возможным в обычных файлах сценариев, лишь в командлетах написанных на C# или VB.Net. Чтож, теперь все будут находиться в равных условиях 🙂 Командлеты написанные непосредственно на PowerShell называются “Advanced Functions”, их синтаксис лишь немного отличается от обычных функций, но зато даёт гораздо большие возможности для создания качественных сценариев для долговременного использования.
    Подробности в about_functions_advanced.

    Встроенный отладчик

    По мне, и в PowerShell 1.0 была прекрасная возможность отладки сценариев из командной строки, которой могли позавидовать многие языки сценариев. Достаточно было добавить в текст сценария строку $Host.EnterNestedPrompt() и при её достижении сценарий приостанавливался, предоставляя вложенную консоль, из которой можно было посмотреть и даже изменить состояние переменных, попробовать выполнить команду вручную, и т.п. Для выхода достаточно было набрать Exit.
    Но в 2.0 консольный отладчик вышел на совершенно новый уровень. Теперь  можно создавать точки останова которые будут срабатывать не только на некоторых строках, но и по достижении определенного столбца, команды или файла сценариев или переменной. Причем для последних можно задать при каких действиях над переменной нужно срабатывать: чтение значение из переменной, изменение значения или и то и другое.
    Есть возможность создать точки останова которые вместо прерывания выполнения, будут выполнять указанное вами действие.
    При срабатывании точки останова, консоль переходит в специальный режим отладки, который можно отличить по префиксу [DBG]: в приглашении командной строки. Тут доступны специфичные для данного режима команды: stepInto, stepOver, stepOut, continue, list, и некоторые другие, которые вы можете посмотреть введя в командную строку вопросительный знак и нажав Enter.
    Управляют точками останова с помощью командлетов *-PSBreakpoint. Для переключения различных опций относящихся к режиму отладки служит командлет Set-PSDebug. Кроме того, выполнив этот командлет с ключом -Strict вы включите Strict Mode, специальный режим, аналогичный Option Explicit в Visual Basic.
    Еще много интересного об отладке вы сможете прочитать в разделе встроенной справки about_Debuggers.

    Новые командлеты

    Конечно в PowerShell 2.0 добавилось множество новых командлетов. Я очень кратко расскажу тут о наиболее интересных.

    Командлет Add-Type пригодится для использования в сценарии кода других .Net языков. Это бывает очень полезно если какая то операция в сценарии должна выполнятся максимально быстро, или если вдруг вам понадобится какая то из возможностей этих языков, которая недоступна в PowerShell. Например Win32 API. Это низкоуровневые функции для управления различными аспектами системы, зачастую с их помощью можно сделать вещи недоступные иными методами. Вот простой пример вызова функции Win32API ShowWindowAsync:

    $type = Add-Type @”
    [DllImport(“user32.dll”)]
    public static extern bool ShowWindowAsync(IntPtr hWnd, int nCmdShow);
    “@ -name “Win32ShowWindowAsync” -namespace Win32Functions -passthru

    #Скрывает окно PowerShell
    $type::ShowWindowAsync((get-process -id $pid).MainWindowHandle,2)

    #Снова показывает окно
    $type::ShowWindowAsync((get-process -id $pid).MainWindowHandle,10)

    Определения других функций Win32 API вы можете посмотреть на сайте http://www.pinvoke.net
    Команда разработчиков PowerShell видимо решила прибрать к рукам большую часть функционала утилиты net.exe, создав соответствующие командлеты, и это здорово! Просто посмотрите на названия командлетов, уверен что мне не придётся объяснять их назначение:

    Add-Computer
    Remove-Computer
    Reset-ComputerMachinePassword
    Test-ComputerSecureChannel

    Еще больше команд появилось для работы с журналами событий Windows:

    Clear-EventLog
    Limit-EventLog
    New-EventLog
    Remove-EventLog
    Show-EventLog
    Write-EventLog

    С их помощью легко производить любые операции с журналами, например создать для своего сценария журнал событий, установить его параметры и писать отладочную информацию туда. Согласитесь, ведь текстовые журналы мы использовали лишь из за того что это было проще. Теперь, так же просто использовать системный функционал предназначенный специально для этого. Журналы событий можно легко фильтровать, передавать на другой компьютер с помощью подписок, или отслеживать используя решения подобные SC Operations Manager.
    Отдельно стоит упомянуть командлет Get-WinEvent. Он работает только на системах Windows Vista, Windows Server 2008 и выше, из за того что использует новые возможности механизма журналов событий. Кроме обычного извлечения событий соответствующих вашим критериям из журнала, он может например показать список зарегистрированных в системе поставщиков событий, и события которые они могут писать:

    $Provider = Get-WinEvent -ListProvider *update*
    $Provider.Events | Format-Table Id, description –AutoSize

    Чтобы увидеть другие примеры применения этого командлета, рекомендую вызвать команду Get-Help Get-WinEvent -Examples. Их там весьма немало.

    Командлеты для работы с журналами событий легко спутать с другим набором команд. Эти предназначены для привязки своих действий к событиям вызываемым другими объектами, .Net или WMI:

    Register-EngineEvent
    Register-ObjectEvent
    Register-WmiEvent
    Get-Event
    New-Event
    Remove-Event
    Unregister-Event
    Wait-Event
    Get-EventSubscriber

    С их помощью можно например сделать чтобы в созданной вами форме, при нажатии на кнопку, выполнялась ваша команда. Или назначить выполнение своего сценария на событие создания определенного файла в определенноё папке, тогда вам не придется постоянно проверять список файлов – система сама оповестит сценарий при изменениях. Или вызывать код при завершении/старте процесса Windows.
    Get-Counter даст возможность легко и непринуждённо получать данные различных счетчиков производительности Windows. Ну и как можно догадаться Export-Counter и Import-Counter позволяют экспортировать показания этих счетчиков, и импортировать их в другую сессию для анализа.
    Пусть в PowerShell 1.0 и так было несложно получить произвольное число, или выбрать уникальное значение из группы, в 2.0 это стало еще проще и удобнее благодаря командлетам Get-Random и Get-Unique.
    Воспользоваться всеми благами новой технологии веб-служб позволит командлет New-WebServiceProxy, который может подключаться к соответствующим сервисам, и управлять ими или получать данные.
    Out-GridView – командлет который выводит возможности PowerShell за пределы командной строки. Он может показать данные полученные по конвейеру в виде красивой и удобной таблицы в которой работает мгновенный поиск, и можно даже фильтровать показанные результаты с помощью графического интерфейса для создания правил отбора.

    out-gridview

    Функционал командлетов Send-MailMessage и Test-Connection врядли кого то удивит. Первый позволяет отправлять почтовые сообщения по протоколу SMTP, а второй является аналогом Ping для PowerShell, с массой новых возможностей, таких как многопоточность или выполнение пинга с другого компьютера.
    Подробно обо всех этих командах можно прочитать во встроенной справке, вызвав её следующей командой:
    Help ИмяКомандлета
    Чтобы увидеть примеры использования, добавьте ключ -Examples, а для просмотра максимально полной версии справки, с описанием всех параметров и примерами ключ -Full.

    Новые параметры у старых команд

    В процессе добавления новых команд, не были забыты и старые друзья. Хотя основной функционал старых командлетов почти не изменялся для сохранения совместимости, ко многим командлетам были добавлены новые параметры расширяющие их возможности.
    Import-Csv и Export-Csv получили крайне необходимые в российских условиях параметры –Delimiter и -UseCulture позволяющие задать используемый разделитель символов.
    Командлет Get-Help, если не находит команды или раздела справки соответствующего переданному аргументу, выполняет поиск упоминаний этого аргумента по всем разделам. Попробуйте выполнить например команду Get-Help “regular expression” и вы увидите все разделы справки где упоминаются регулярные выражения.
    Новый параметр командлета Select-String -Context позволяет получить не только ту строку в которой было найдено вхождение искомого текста, но и несколько предыдущих и/или последующих строк. Например следующая команда, выведет все строки в которых встречается слово Error, 1 предыдущую строку, и 2 последующих:
    Get-Content Log.txt | select-string “Error” -Context 1,2

    Другие улучшения языка

    Как я уже сказал в статье не хватит места рассказать обо всех нововведениях, и разумеется я не упомянул о многих новых команадах, и улучшениях, но некоторые вещи заслуживают хотя бы пары слов.
    Так теперь вы можете использовать в своих сценариях Windows Presentation Foundation, технологию возможности которой для простого создания красивых графических интерфейсов уже оценили многие Windows программисты.
    В PowerShell 2.0 вы сможете легко создавать обёртки для команд, добавляя/изменяя/удаляя параметры, при этом сохраняя оригинальный функционал команды. Пример можно посмотреть в блоге разработчиков, тут – http://blogs.msdn.com/powershell/archive/2009/03/13/dir-a-d.aspx
    Благодаря новому подъязыку, – data language, будет легко создавать сценарии говорящие на разных языках или отделить в сценарии данные от исполняемого кода.
    Модули позволят хранить, распостранять и подключать ваши наборы функций с гораздо большим удобством. О них можно прочитать в разделе справки About_Modules
    Другой раздел, About_Transactions поведает вам о технологии которая впервые появилась в языках сценариев, и даст нам совершенно новые возможности.
    Оператор -Split легко разделит строку на компоненты, а -Join соберёт её заново, и всё это используя указанные вами разделители.
    Конструкция Try Catch Finally сделает обработку ошибок крайне приятным делом. Если вы не знакомы с ней по другим языкам, то сможете научиться её использовать прочитав раздел справки about_Try_Catch_Finally.
    Используя добавившиеся во второй версии многострочные комментарии вы сможете легко создавать полноценную справку для своих сценариев и функций. Затем, конечный пользователь сможет увидеть эту справочную информацию даже не заглядывая в исходный код сценария, с помощью командлета Get-Help.
    Кстати о справке, не поленитесь, и вызовите Get-Help about_* В PowerShell 2.0 было добавлено много новых разделов, которые позволят узнать еще больше о функционале этого языка, и дадут вам еще больше возможностей.

    Что дальше?

    Рекомендую вам не останавливаться после прочтения этой статьи. Загрузите PowerShell 2.0, и попробуйте нововведения самостоятельно. Ссылки на загрузку находятся тут – http://microsoft.com/powershell/download. Впрочем если вы используете Windows 7 или Windows Server 2008 R2, то вам не стоит себя утруждать никакими загрузками – PowerShell 2.0 и WinRM 2.0 уже интегрированы в эти системы.
    Ну и конечно не забывайте посещать мой блог (http://xaegr.wordpress.com) и блог команды разработчиков PowerShell (http://blogs.msdn.com/powershell/) где вы найдете множество информации о PowerShell 2.0 и примеров кода. Так же существует русскоязычная версия блога команды PowerShell  – http://blogs.technet.com/powershell_ru/ . Еще обязательно загляните на TechDays.Ru, там уже накопилось немало видео-докладов посвященных PowerShell – http://www.techdays.ru/Category.aspx?Tag=PowerShell

    Василий Гусев

    MVP PowerShell

    • Рубрика: Windows,Новое
    • Автор: Василий Гусев
    • Дата: Thursday 01 Oct 2009

Комментарии

  1. Очень познавательно 🙂
    Спасибо, Вань!

  2. Спасиб … очень понравилась не только сама статья, но и легкость изложения! 😉
    Давно хотел поучить какой-нить язык программмирования досканально … Теперь осталось найти одну детальку “Может ли пауэршел удалять софт с удаленного компа?” И основательно начинать изучать.

  3. PowerShell не умеет удалять софт. Более того, он и не должен этого уметь. Для этого есть стандартные средства, например msiexec /u