Андрей Бешков опубликовал вопросы с прошедшего вебкаста “Управление Windows Vista с помощью PowerShell”. Запись самого каста можно посмотреть или скачать вот тут.

Вебкаст продолжался 2 часа вместо часа как обычно. При этом никаких затягиваний я не заметил Контента было много, как и демонстраций. Рекомендую

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

Традиционно напоминаю о вебкасте который начнётся сегодня в 12:00 MSK. Мы с Андреем Бешковым расскажем про администрирование Vista с помощью PowerShell, и постараемся ответить на ваши вопросы.

Регистрироваться можно тут, - на онлайн мероприятия у MS места не ограничены пока Для участия понадобится клиент Live Meeting 2007.

Кстати сегодня вечером, в 21:00 MSK состоится еще одна интересная онлайн встреча - “Разговоры об ИТ” у Паши Нагаева. Там меня (и не только меня ) можно будет помучать вопросами более основательно Вопросы можно будет задавать с помощью голоса (если есть микрофон) или в Q/A.

UPD: Запись вебкаста доступна тут.

Буквально “несколько часов назад” стал доступен публике второй CTP PowerShell V2. И еще раз напоминаю - CTP (Community Technology Preview) - это не бета, это сырее беты! CTP выпускается для того чтобы продемонстрировать сообществу новые возможности продукта, и чтобы сообщество могло на эти возможности повлиять.

Но вернемся ко второму CTP. В нем разработчики демонстрируют нам кучу новых фич (которыми давно не терпелось поделиться ):

Интерактивное удаленное подключение (типа telnet, но с помощью winrm). Делается с помощью команд Push/Pull-Runspace:

PS C:\Root> Push-Runspace remotepc
[remotepc]: PS C:\Windows\System32> hostname.exe
remotepc
[remotepc]: PS C:\Windows\System32> Pop-Runspace
PS C:\Root>

Появилась возможность создавать “модули” содержащие внутренние переменные и функции. Очень удобная фича для организации функционала.

Появилась поддержка транзакций в движке и API PowerShell’а. А так же обновлён провайдер Registry как раз для возможности их использования.

Появилась поддержка событий (Eventing). Теперь их можно слушать, перенаправлять и выполнять действия при возникновении событий.

В ScriptCmdlets можно использовать несколько наборов параметров.

Разработчики могут хостить PowerShell в IIS и запускать несколько сессий PoSh в одном процессе.

Ну и множество мелких обновлений типа новых командлетов и параметров

Скачивать тут.

7го мая, в среду, в 12:00 MSK, мы с Андреем Бешковым проведем интересный (очень надеюсь ) вебкаст “Управление Vista с помощью PowerShell”. На самом деле многие вещи о которых там расскажем относятся не только к Vista, но и к остальным ОС. Ну и кроме того немаленькая часть будет посвящена идеологии и устройству PowerShell.

Регистрироваться тут.

PS: Готовьте свои вопросы. Если не смогу ответить на вебкасте - постараюсь потом в блоге.

UPD: Запись вебкаста доступна тут.

Продолжая тему Active Directory и PowerShell, приведу несколько команд (точнее методов .Net), которые бывают полезны в скриптах.

Серьезный, “продакшн” скрипт, не должен требовать указывать ему имя домена, а использовать по умолчанию домен того компьютера на котором он запущен. А как его определить? Вызвать статический метод GetCurrentDomain() класса System.DirectoryServices.ActiveDirectory.Domain:

PS:> [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()

Forest                  : МойДомен.local
DomainControllers       : {dc1.МойДомен.local, dc2.МойДомен.local, …}
Children                : {}
DomainMode              : Windows2003Domain
Parent                  :
PdcRoleOwner            : dc1.МойДомен.local
RidRoleOwner            : dc2.МойДомен.local
InfrastructureRoleOwner : dc3.МойДомен.local
Name                    : МойДомен.local

Звучит сложно, но сделать в PowerShell - просто (особенно если работает автодополнение PowerTab ).

В результатах предыдущей команды видно поле DomainControllers, в котором содержатся все контроллеры данного домена (хотя в одной строчке не много отобразятся). Можно легко получить их список, и даже отобрать лишь нужные свойства, но сначала, для читабельности скрипта, я помещу объект домена, в переменную $domain:

PS:> $domain = [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()
PS:> $domain.DomainControllers | Format-Table Name, OSVersion, IPAddress, SiteName

Name                  OSVersion           IPAddress   SiteName
—-                  ———           ———   ——–
dc1.МойДомен.local    Windows Server 2003 192.168.0.1 Default-First-Site
dc2.МойДомен.local    Windows Server 2003 192.168.0.2 Default-First-Site
dc3.МойДомен.local    Windows Server 2003 192.168.0.3 Default-First-Site

Ну и напоследок - получение DN (Distinguished Name) всех этих объектов. Домена:

PS:> $domain.GetDirectoryEntry().distinguishedName
DC=МойДомен,DC=local

И контроллеров:

PS:> $domain.DomainControllers | foreach {$_.GetDirectoryEntry().distinguishedName}
CN=dc1,CN=Servers,CN=Default-First-Site,CN=Sites,CN=Configuration,DC=МойДомен,DC=local
CN=dc2,CN=Servers,CN=Default-First-Site,CN=Sites,CN=Configuration,DC=МойДомен,DC=local
CN=dc3,CN=Servers,CN=Default-First-Site,CN=Sites,CN=Configuration,DC=МойДомен,DC=local

Вопросы и пожелания приветствуются

Сегодня из общения с Пашей Дугаевым “узнал” что людям “иногда” бывает нужно задать из PowerShell атрибут какого нибудь объекта в Active Directory . Процесс не сложный, но в PowerShell 1.0 не очень “красивый”. Поэтому для удобного использования стоит завернуть его в такую вот функцию:

function Set-ADProperty ($DN, $Property, $Value)
{
	$Obj = [adsi]“LDAP://$DN”
	$Obj.psbase.InvokeSet($Property,$Value)
	$Obj.psbase.CommitChanges()
}

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

Set-ADProperty "CN=Василий Гусев,OU=Юзеры,DC=Домен,DC=Local" "displayName" "Гусев Василий"

PS: AD Cmdlets не требует

Те самые люди которые подарили нам PowerShell

А сейчас они заняты подготовкой следующей версии…

В ближайшее время станет доступен PowerShell 2.0 CTP2. То есть это будет второй Community Technology Preview. На всякий случай еще раз напоминаю: CTP - это даже не бета, это гораздо сырее, до релиза в ней многое изменится - не стоит привыкать. Это лишь версия для демонстрации новых возможностей сообществу, чтобы сообщество могло повлиять на эти возможности и подсказать как их можно поменять. В бете сильных изменений уже не произойдет (ну кроме исправления багов конечно).

Итак, для тех кто полностью осознает что такое CTP, Jeffrey Snower огласил список этих самых “breaking changes” которые произойдут в CTP2.

Синтаксис атрибутов для скриптовых командлетов стал более похожим на таковой в C#. Единообразие - хорошо

Возможности удаленного выполнения команд убраны из командлетов Invoke-Expression и Start-PSJob. Для запуска команд удаленно теперь используется только Invoke-Command. Ну и к нему же добавлен ключ -AsJob.

Теперь ждем “New Features” там должно быть куда больше интересного

Скриптерам и программерам на Visual Basic наверняка знакома эта “ключевая фраза”. Дело в том что по умолчанию, если использовать не объявленную заранее переменную, то ошибки не произойдет ни в Visual Basic ни в PowerShell. Просто вместо несуществующей переменной будет подставлено пустое значение. Обычно это является нормальным поведением, но иногда может привести и к логическим ошибкам. Ведь достаточно ошибится на одну букву в имени переменной, и логика скрипта может сильно изменится. Для таких случаев и был сделан Option Explit. При объявлении в начале скрипта этой директивы, при обращении к несуществующей переменной выдается ошибка. Аналог разумеется есть и в PowerShell - команда Set-PsDebug с ключем -Strict

Вызов несуществующей переменной в обычном режиме (никакой ошибки):

[PS <50> C:\Root] $несуществующаяПеременная

и при включении Set-PSDebug -Strict:

[PS <51> C:\Root] Set-PSDebug -Strict
[PS <52> C:\Root] $несуществующаяПеременная
The variable $несуществующаяПеременная cannot be retrieved because it has not been set yet.
At line:1 char:26
+ $несуществующаяПеременная <<<<

Однако если предварительно назначить переменной значение - всё будет в порядке:

[PS <53> C:\Root] $несуществующаяПеременная = 123
[PS <54> C:\Root] $несуществующаяПеременная
123

Отключить режим можно использовав ключ -Off:

[PS <55> C:\Root] Set-PSDebug -Off

Или задав ключу -Strict значение $False следующим образом:

[PS <56> C:\Root] Set-PSDebug -Strict:$False

PowerShell очень классный язык, но тем не менее очень молодой. И по этой причине в нём зачастую нет того чего хочется. Пока нет.

Но так как он всё же очень классный - то чего нет можно дописать Вот к примеру если кому то не хватает привычной конструкции Try/Catch/Finally то Adam Weigert её написал За что ему большое спасибо (и ajax76 спасибо что напомнил )

Достаточно добавить в свой профиль следующую функцию:

function Try
{
    param
    (
        [ScriptBlock]$Command = $(throw “The parameter -Command is required.”),
        [ScriptBlock]$Catch   = { throw $_ },
        [ScriptBlock]$Finally = {}
    )
    & {
        $local:ErrorActionPreference = “SilentlyContinue”
        trap
        {
            trap
            {
                & {
                    trap { throw $_ }
                    &$Finally
                }
                throw $_
            }
            $_ | & { &$Catch }
        }
        &$Command
    }
    & {
        trap { throw $_ }
        &$Finally
    }
}

И можно использовать:

Try {
    echo " ::Do some work..."
    echo " ::Try divide by zero: $(0/0)"
} -Catch {
    echo "  ::Cannot handle the error (will rethrow): $_"
    #throw $_
} -Finally {
    echo " ::Cleanup resources..."
}

Опишу несколько неочевидных моментов из скрипта:

В качестве параметров для функции принимаются [ScriptBlock], то есть грубо говоря “куски кода”. Передаются они (как в видно в примере) заключенными в фигурные скобки, как и везде в PowerShell: в командлетах - foreach-object {скриптблок}, конструкциях - if () {скриптблок} или ключевых словах - trap {скриптблок}.

Выполнить переменную содержащую скриптблок можно используя оператор Invoke - “&”:

&$Command

Когда выполняется скриптблок указанный для throw, то в пределах этого скриптблока, в переменную $_ помещается объект текущей ошибки.

Ключевое слово Throw используется для вызова ошибки. То есть просто указываем ему в качестве аргумента объект ошибки или какое-нибудь сообщение:

[PS <4> C:\Root] throw “Ошипко”
Ошипко
At line:1 char:6
+ throw <<<<  “Ошипко”

В PowerShell ошибки делятся на 2 категории:

Terminating Errors - критичные для выполнения команды, ошибки синтаксиса, и т.п. При возникновении такой ошибки дальнейшее выполнение команды прерывается (по умолчанию), и если установлен trap, то выполняется определённый в нём скриптблок.

Non terminating Errors - ошибки которые можно и стерпеть Это ошибки несмотря на которые выполнение команды можно продолжить (и даже получить еще ошибок ). О них и поговорим сегодня.

Для примера разберём два типа ошибок у командлета Copy-Item. Первая ошибка - это несуществующий путь в параметре -Destination:

[PS <6> C:\Root] trap {”Ошибка!”}; Copy-Item -Path test.txt -Destination \\сервер\шара
Ошибка!
Copy-Item : Не найдено сетевое имя.
At line:1 char:28
+ trap {”Ошибка!”}; Copy-Item <<<<  -Path test.txt -Destination \\сервер\шара

Путь указанный в -Destination критичен для командлета Copy-Item, без него невозможна дальнейшая работа, ведь именно в это место должны копироваться все указанные файлы. Поэтому в этом случае ошибка является Terminating, и прерывая действие командлета, вызывает блок кода из конструкции trap.

Теперь вызовем другую ошибку:

[PS <9> C:\Root] trap {”Ошибка!”}; Copy-Item -Path файл.txt -Destination \\сервер\шара
Copy-Item : Cannot find path ‘C:\Root\файл.txt’ because it does not exist.
At line:1 char:28
+ trap {”Ошибка!”}; Copy-Item <<<<  -Path файл.txt -Destination \\сервер\шара

На этот раз командлет не смог найти файл для копирования, но тем не менее не вызвал блок trap! Дело в том что отсутствие файла источника не является критической (Terminating) ошибкой. Ведь этих файлов может быть указано много, что с того что один из них не существует? Поэтому прерывания команды и не произошло. Вот пример того, какую пользу это может принести:

[PS <10> C:\Root] trap {”Ошибка!”}; Copy-Item -Path файл.txt,file.txt -Destination \\localhost\c$\temp
Copy-Item : Cannot find path ‘C:\Root\файл.txt’ because it does not exist.
At line:1 char:28
+ trap {”Ошибка!”}; Copy-Item <<<<  -Path файл.txt,file.txt -Destination \\localhost\c$\temp
[PS <11> C:\Root] Test-Path \\localhost\c$\temp\file.txt
True

Тут в качестве источника было указано несколько файлов, и командлет вызвав ошибку, всё же продолжил дальнейшую работу, и скопировал существующий файл file.txt.

Действительно, в большинстве случаев, указывая командлету задачу скопировать несколько файлов, мы хотим чтобы он скопировал все которые сможет, а не прерывался после первой же ошибки. Но может возникнуть и обратная ситуация, когда критичен каждый файл. В таком случае можно сказать командлету о том что все ошибки надо считать Terminating. Делается это указанием параметра -ErrorAction “Stop” (или -EA 1):

[PS <14> C:\Root] del \\localhost\c$\temp\file.txt
[PS <15> C:\Root] trap {”Ошибка!”}; Copy-Item -Path файл.txt,file.txt -Destination \\localhost\c$\temp -ea 1
Ошибка!
Copy-Item : Command execution stopped because the shell variable “ErrorActionPreference” is set to Stop: Cannot find pa
th ‘C:\Root\файл.txt’ because it does not exist.
At line:1 char:28
+ trap {”Ошибка!”}; Copy-Item <<<<  -Path файл.txt,file.txt -Destination \\localhost\c$\temp -ea 1
[PS <16> C:\Root] Test-Path \\localhost\c$\temp\file.txt
False

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

Можно и повторить тот же эффект, но в пределах всего скрипта, установив в его начале значение специальной переменной $ErrorActionPreference:

$ErrorActionPreference = "Stop"

Ну и третий вариант - когда не надо прерывать выполнение команды, но о наличии Non terminating ошибок узнать всё таки хочется. Просто проверяем количество элементов в переменной указанной в параметре -ErrorVariable:

[PS <23> C:\Root] trap {”Ошибка!”}; Copy-Item -Path файл.txt,file.txt -Destination \\localhost\c$\temp -ErrorVariable e
Copy-Item : Cannot find path ‘C:\Root\файл.txt’ because it does not exist.
At line:1 char:28
+ trap {”Ошибка!”}; Copy-Item <<<<  -Path файл.txt,file.txt -Destination \\localhost\c$\temp -ErrorVariable e
[PS <24> C:\Root] if ($e.Count -ge 1) {”При выполнении команды произошли ошибки.”}
При выполнении команды произошли ошибки.

—

PS: Напоминалка Заходим сегодня, в 12:00 по Москве, на вебкаст Андрея, слушать про использование NPS (тот что раньше звался IAS, а по сути RADIUS), в NAP.