Встречаем третий PowerShell (часть I)

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

Стенд

Я собрал под 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, то тут вот пожалуйста, все модули, все командлеты, ищи – не хочу.

Вот, извольте, командлеты управления DNS-сервером и службой DNS-клиента, а если выбрать какой-либо модуль, например сетевой, можно узнать командлеты настройки таблицы маршрутизации или, допустим, параметры TCP/IP сетевых интерфейсов.

Также я пробовал поискать слова «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

Теперь, если повторить, то все проходит нормально:

В PowerShell v3 же все прекрасно изначально:

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, указывающие на диапазон. С ними, я думаю, все более, чем понятно:

Custom session configurations

Самое замечательное новшество, о котором я хочу рассказать в первой части, это конфигурация сессии в связке с делегированием административных полномочий. Собственно файл с конфигурацией является файлом с расширением .pssc, в котором всего лишь содержится хэш-таблица свойств и значений: авторство, язык, переменные, определения функций, прочее. В самой же конфигурации сессии есть и иные свойства:

Get-PSSessionConfiguration | Get-Member

Появится картинка, похожая на эту:

Видите сколько настраиваемых параметров? Можно даже сравнить с картинкой, которая появится при запуске этой команды в PowerShell v2 и ощутить разницу.
Но как это использовать? А сейчас покажу, признаться, я достаточно долго ковырялся, чтобы написать вот эти несколько строчек. Итак, последовательно выполняем:

$defSSDL = (Get-Item WSMan:localhostServiceRootSDDL).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 не сможет сделать ничего, кроме разве что этого:

Удобная штука, правда? Ограничив модули и командлеты внутри PowerShell, мы легко и непринужденно можем внутри нашей команды администраторов одних сотрудников сделать ответственными за DNS, других за сеть, а пользователям, например, дать право делать снэпшоты их машин Hyper-V внутри VDI, и при этом никто не будет знать учетные данные пользователя, из-под которого выполняется задача! А готовый конфигурационный файл просто переносится из одного места на все другие сервера со сходными функциями.
В следующей части мы пойдем далее, а вернее вверх по списку, разберем надежные сессии, запланированные задания и, конечно, рабочие процессы. Ну и, быть может, чуть-чуть коснемся новой PowerShell ISE, там тоже есть, на что посмотреть.

Автор: thunderquack