Темпы развития современных технологий таковы, что мы за ними еле-еле поспеваем. Но сегодня мы забежим чуть-чуть вперед, узнаем о новшествах PowerShell v3, причем оглядим их не только глазами, но и пощупаем руками.
Я собрал под Hyper-V две машины на базе Windows Server 2012 RC, создал лес из одного домена под названием
Также, должен упомянуть, что не все термины, которые я использую, уже локализованы и есть на языковом портале Microsoft, поэтому я даю их перевод ровно так, как я эти термины понимаю, а в скобках даю оригинальное название на английском языке.
Сначала давайте их просто перечислим, это:
После его запуска, без параметров, появляется окно, от которого веет грандиозностью и шиком:
Если раньше приходилось искать по TechNet тот или иной командлет, а то и вовсе использовать объекты .NET, то тут вот пожалуйста, все модули, все командлеты, ищи – не хочу.
![](https://habrastorage.org/r/w1560/storage2/65e/ef8/944/65eef8944a926393a5188f0439a8d50c.png)
Вот, извольте, командлеты управления DNS-сервером и службой DNS-клиента, а если выбрать какой-либо модуль, например сетевой, можно узнать командлеты настройки таблицы маршрутизации или, допустим, параметры TCP/IP сетевых интерфейсов.
![](https://habrastorage.org/r/w1560/storage2/7d0/e0a/a67/7d0e0aa67bcc702771faa7e2a6860af3.png)
Также я пробовал поискать слова «share», «user», «acl», «policy», «adapter», и так далее, и тому подобное, попробуйте, это интересно.
Связанное с предыдущим, но напрямую не зависящее. В PowerShell v2 в Windows Server 2008 R2, для того, чтобы производить те или иные операции, необходимо подключать тот или иной модуль, PowerShell v3 же автоматически определяет, какой модуль отвечает за запуск командлета и в фоне этот модуль подгружает, безо всяких вопросов.
Сравним. Я решил получить список групповых политик домена, если я в PowerShell v2 пытаюсь их загрузить:
То мы получаем ошибку, потому что не подгружен модуль GroupPolicy:
Теперь, если повторить, то все проходит нормально:
![](https://habrastorage.org/r/w1560/storage2/2f9/db0/66e/2f9db066ea5a3cf91da06e0e814ce1eb.png)
В PowerShell v3 же все прекрасно изначально:
![](https://habrastorage.org/r/w1560/storage2/c97/41a/962/c9741a962263e30f4b74b51dc43db9b5.png)
Тут, как мне показалось, разработчики решили приблизить язык к SQL, ну по крайней мере прослеживается некая аналогия. Дело в том, что они представили новые синтаксисы для командлетов
вместо
на мой взгляд, сомнительна.
Другое дело
вместо
уже ничего, безо всяких скобочек фигурных с долларами-кавычками.
Также появилась пара новых операторов:
![](https://habrastorage.org/r/w1560/storage2/9c7/50d/115/9c750d115c09dfd9a152282a0d0be48f.png)
Самое замечательное новшество, о котором я хочу рассказать в первой части, это конфигурация сессии в связке с делегированием административных полномочий. Собственно файл с конфигурацией является файлом с расширением .pssc, в котором всего лишь содержится хэш-таблица свойств и значений: авторство, язык, переменные, определения функций, прочее. В самой же конфигурации сессии есть и иные свойства:
Появится картинка, похожая на эту:
![](https://habrastorage.org/r/w1560/storage2/3e1/f95/7fc/3e1f957fc775fb787ccb40afa7e37734.png)
Видите сколько настраиваемых параметров? Можно даже сравнить с картинкой, которая появится при запуске этой команды в PowerShell v2 и ощутить разницу.
Но как это использовать? А сейчас покажу, признаться, я достаточно долго ковырялся, чтобы написать вот эти несколько строчек. Итак, последовательно выполняем:
Заметьте, я ограничил конфигурацию лишь модулем
![](https://habrastorage.org/r/w1560/storage2/1b5/35d/1d3/1b535d1d3c438bcbb6fed1471f9e0f1e.png)
Удобная штука, правда? Ограничив модули и командлеты внутри PowerShell, мы легко и непринужденно можем внутри нашей команды администраторов одних сотрудников сделать ответственными за DNS, других за сеть, а пользователям, например, дать право делать снэпшоты их машин Hyper-V внутри VDI, и при этом никто не будет знать учетные данные пользователя, из-под которого выполняется задача! А готовый конфигурационный файл просто переносится из одного места на все другие сервера со сходными функциями.
В следующей части мы пойдем далее, а вернее вверх по списку, разберем надежные сессии, запланированные задания и, конечно, рабочие процессы. Ну и, быть может, чуть-чуть коснемся новой PowerShell ISE, там тоже есть, на что посмотреть.
Стенд
Я собрал под Hyper-V две машины на базе Windows Server 2012 RC, создал лес из одного домена под названием
litware.inc
. Две машины в домене называются, соответственно, w2012dc1.litware.inc
и w2012cl1.litware.inc
. На w2012dc1
вертятся доменные службы и DNS, а на w2012cl1
не вертится ничего, кроме, собственно, самой операционки. Также в домене есть пользователь user1
, член группы domain users
. Можно, конечно, было установить на вторую машину Windows 8 RC, так сказать, для красоты, но я решил сэкономить немножечко дискового пространства, взяв один родительский виртуальный жесткий диск, а к нему прицепив два дочерних вместо использования двух независимых виртуальных жестких дисков.Также, должен упомянуть, что не все термины, которые я использую, уже локализованы и есть на языковом портале Microsoft, поэтому я даю их перевод ровно так, как я эти термины понимаю, а в скобках даю оригинальное название на английском языке.
Новые возможности
Сначала давайте их просто перечислим, это:
- Рабочие процессы (англ. Workflows) – это некие процессы, запущенные последовательно или же параллельно, выполняющие комплексные задачи управления. Собственно в PowerShell v3 теперь включена поддержка Windows Workflow Foundation, а сами рабочие процессы PowerShell повторяемы, параллелизуемые, прерываемые и восстановимые.
- Надежные сессии (англ. Robust sessions) – это сессии PowerShell, которые автоматически восстанавливаются после сетевых неурядиц и им подобных прерываний. Также эта технология позволяет отключиться от сессии на одной машине и подключиться к той же сессии на другой.
- Запланированные задания (англ. Scheduled jobs) – задания PowerShell, которые могут выполняться с определенным интервалом, или же в ответ на какое-либо событие.
- Специальная конфигурация для сессии (англ. Custom session configurations) – Для каждой PowerShell-сессии можно предопределить определенный набор параметров и сохранить их в специальном конфигурационном файле, чтобы потом войти в сессию на готовеньком.
- Упрощенный языковой синтаксис (англ. Simplified language syntax) – как утверждается, упрощенный синтаксис позволяет скрипту PowerShell выглядеть менее похожим на программу и более похожим на натуральный человеческий язык.
- Поиск командлетов (англ. Cmdlet discovery) – автоматическая подгрузка модуля, в котором находится командлет, если этот модуль, конечно, установлен на машину.
- Show-Command – это просто один из новых командлетов, с которого мы, пожалуй, и начнем.
Show-Command
После его запуска, без параметров, появляется окно, от которого веет грандиозностью и шиком:
Если раньше приходилось искать по TechNet тот или иной командлет, а то и вовсе использовать объекты .NET, то тут вот пожалуйста, все модули, все командлеты, ищи – не хочу.
![](https://habrastorage.org/storage2/65e/ef8/944/65eef8944a926393a5188f0439a8d50c.png)
Вот, извольте, командлеты управления DNS-сервером и службой DNS-клиента, а если выбрать какой-либо модуль, например сетевой, можно узнать командлеты настройки таблицы маршрутизации или, допустим, параметры TCP/IP сетевых интерфейсов.
![](https://habrastorage.org/storage2/7d0/e0a/a67/7d0e0aa67bcc702771faa7e2a6860af3.png)
Также я пробовал поискать слова «share», «user», «acl», «policy», «adapter», и так далее, и тому подобное, попробуйте, это интересно.
Cmdlet discovery
Связанное с предыдущим, но напрямую не зависящее. В PowerShell v2 в Windows Server 2008 R2, для того, чтобы производить те или иные операции, необходимо подключать тот или иной модуль, PowerShell v3 же автоматически определяет, какой модуль отвечает за запуск командлета и в фоне этот модуль подгружает, безо всяких вопросов.
Сравним. Я решил получить список групповых политик домена, если я в PowerShell v2 пытаюсь их загрузить:
Get-GPO -All | ft Id #Пусть нас просто столбец с Id интересует, без изысков
То мы получаем ошибку, потому что не подгружен модуль GroupPolicy:
Import-Module GroupPolicy
Теперь, если повторить, то все проходит нормально:
![](https://habrastorage.org/storage2/2f9/db0/66e/2f9db066ea5a3cf91da06e0e814ce1eb.png)
В PowerShell v3 же все прекрасно изначально:
![](https://habrastorage.org/storage2/c97/41a/962/c9741a962263e30f4b74b51dc43db9b5.png)
Simplified language syntax
Тут, как мне показалось, разработчики решили приблизить язык к SQL, ну по крайней мере прослеживается некая аналогия. Дело в том, что они представили новые синтаксисы для командлетов
Foreach-Object
и Where-Object
. Хотя практическая ценность Foreach
:Get-Service | Foreach Name
вместо
Get-Service | Foreach {$_.Name}
на мой взгляд, сомнительна.
Другое дело
Where
:Get-Service | Where Status -eq Running
вместо
Get-Service | Where {$_.Status -eq "Running"}
уже ничего, безо всяких скобочек фигурных с долларами-кавычками.
Также появилась пара новых операторов:
-In
и -NotIn
, указывающие на диапазон. С ними, я думаю, все более, чем понятно:![](https://habrastorage.org/storage2/9c7/50d/115/9c750d115c09dfd9a152282a0d0be48f.png)
Custom session configurations
Самое замечательное новшество, о котором я хочу рассказать в первой части, это конфигурация сессии в связке с делегированием административных полномочий. Собственно файл с конфигурацией является файлом с расширением .pssc, в котором всего лишь содержится хэш-таблица свойств и значений: авторство, язык, переменные, определения функций, прочее. В самой же конфигурации сессии есть и иные свойства:
Get-PSSessionConfiguration | Get-Member
Появится картинка, похожая на эту:
![](https://habrastorage.org/storage2/3e1/f95/7fc/3e1f957fc775fb787ccb40afa7e37734.png)
Видите сколько настраиваемых параметров? Можно даже сравнить с картинкой, которая появится при запуске этой команды в PowerShell v2 и ощутить разницу.
Но как это использовать? А сейчас покажу, признаться, я достаточно долго ковырялся, чтобы написать вот эти несколько строчек. Итак, последовательно выполняем:
$defSSDL = (Get-Item WSMan:\localhost\Service\RootSDDL).Value #Берем SSDL "по умолчанию"
$SecDescriptor = New-Object -TypeName Security.AccessControl.CommonSecurityDescriptor $false, $false, $defSSDL #Создаем дескриптор безопасности
$user = Get-ADUser "user1" #Находим в Active Directory нужного пользователя, но лучше, конечно, полномочия давать группам
$SecDescriptor.DiscretionaryAcl.AddAccess([System.Security.AccessControl.AccessControlType]::Allow, $user.SID.Value, 268435456, [System.Security.AccessControl.InheritanceFlags]::None, [System.Security.AccessControl.PropagationFlags]::None) #Добавляем SID нашего пользователя
$sddl = $SecDescriptor.GetSddlForm("All") #Забираем то, что получилось
$creds = Get-Credential "administrator@litware.inc" #Вводим учетные сведения администратора
New-PSSessionConfigurationFile -Path .\DnsRead.pssc -SessionType RestrictedRemoteServer -VisibleCmdlets "Show-DnsServer*" -ModulesToImport DnsServer #Создаем конфигурационный файл
Register-PSSessionConfiguration -Name DnsRead -Path .\DnsRead.pssc -AccessMode Remote -SecurityDescriptorSddl $sddl -RunAsCredential $creds #Регистрируем конфигурацию
Заметьте, я ограничил конфигурацию лишь модулем
DnsServer
и лишь командлетами, начинающимися на Show-DnsServer
, это гарантирует, что хотя сама оболочка и будет выполняться с привилегиями пользователя administrator@litware.inc
, но удаленный пользователь user1
с удаленной машины w2012cl1
не сможет сделать ничего, кроме разве что этого:![](https://habrastorage.org/storage2/1b5/35d/1d3/1b535d1d3c438bcbb6fed1471f9e0f1e.png)
Удобная штука, правда? Ограничив модули и командлеты внутри PowerShell, мы легко и непринужденно можем внутри нашей команды администраторов одних сотрудников сделать ответственными за DNS, других за сеть, а пользователям, например, дать право делать снэпшоты их машин Hyper-V внутри VDI, и при этом никто не будет знать учетные данные пользователя, из-под которого выполняется задача! А готовый конфигурационный файл просто переносится из одного места на все другие сервера со сходными функциями.
В следующей части мы пойдем далее, а вернее вверх по списку, разберем надежные сессии, запланированные задания и, конечно, рабочие процессы. Ну и, быть может, чуть-чуть коснемся новой PowerShell ISE, там тоже есть, на что посмотреть.