Vadims Podans's blog - PowerShell | PowerShell V2

PowerShell V2 RTM для Windows XP/Vista/2003/2008

Camelot — Tue, 27 Oct 2009 18:34:36 GMT

Слава ~~сиськамПротоколу~~ Сноверу!

>> PowerShell V2 RTM <<

PowerShell Powered - http://www.sysadmins.lv

Get-TextEncoding

Camelot — Sun, 04 Oct 2009 11:07:34 GMT

По мотивам предыдущего поста и срача в ньюсгруппе microsoft.public.windows.powershell перепубликовываю скрипт Роберта Робело для определения кодировки, в которой сохранён файл.

filter Get-TextEncoding {
#requires -Version 2.0
    begin {
        [string]$BOM_Unicode = [Text.Encoding]::Unicode.GetPreamble()
        [string]$BOM_UTF7 = [Text.Encoding]::UTF7.GetPreamble()
        [string]$BOM_UTF8 = [Text.Encoding]::UTF8.GetPreamble()
        [string]$BOM_BigEndian = [Text.Encoding]::BigEndianUnicode.GetPreamble()
        [string]$BOM_UTF32 = [Text.Encoding]::UTF32.GetPreamble()
    }
    process {
        if ($_ -is 'IO.FileInfo') {
            $bytes = Get-Content -Literal $_.pspath -Encoding Byte -Total 4 -ErrorAction SilentlyContinue
            $value = if ($bytes) {
                if ($bytes[0..1] -as 'String' -eq $BOM_Unicode) {'Unicode'}
                elseif ($bytes[0..2] -as 'String' -eq $BOM_UTF7) {'UTF7'}
                elseif ($bytes[0..2]  -as 'String' -eq $BOM_UTF8) {'UTF8'}
                elseif ($bytes[0..1] -as 'String' -eq $BOM_BigEndian) {'BigEndian'}
                elseif ($bytes[0..3] -as 'String' -eq $BOM_UTF32) {'UTF32'}
                # undetermined, no BOM
                else {'Unknown'}
            # undetermined, zero bytes
            } else {'Unknown'}
            $_ | Add-Member NoteProperty Encoding $value -PassThru
        # not an IO.FileInfo
        } else {$_}
    }
}

ну и использование достаточно простое:

dir *.ps1 | Get-TextEncoding | Format-Table Name, Encoding

Уже тут видно мелкий косячок подсветки в PowerGUI. Name должно быть такого же цвета, что и Encoding. А выглядеть это будет примерно так:

[↓] [vPodans] dir desktop\*.ps1 | Get-TextEncoding | ft name, encoding

Name                                                        Encoding
----                                                        --------
Untitled1.ps1                                               BigEndian
untitled2.ps1                                               UTF8


[↓] [vPodans]

Не забудьте, что это будет работать только в V2. Для PowerShell 1.0 придётся чуточку подпилить его.

PowerShell Powered - http://www.sysadmins.lv

PS FCIV 1.0

Camelot — Thu, 01 Oct 2009 19:12:11 GMT

После небольшого перерыва продолжаю допиливать свой вариант FCIV на PowerShell. И радостно могу сообщить, что уже есть версия 1.0, т.е. полностью отвечающая нашим требованиям. Что изменилось в новой версии?

Основная команда переименована с Get-PsFCIV в Start-PsFCIV;
Включена предварительная проверка файлов на блокировку;
В связи с предыдущим пунктом, к параметру Show добавлен аргумент – Locked. В это свойство помещаются заблокированные файлы (а для них нельзя подсчитать хеш);
Включена проверка пути. Если путь к исходной папке не является путём файловой системы, то скрипт будет генерировать ошибку;
Исправлена ошибка невозврата на исходный путь, если в процессе работы произошла фатальная ошибка;
Параметр Show теперь выводит файлы из указанных категорий в красивое графическое окошко с использованием Out-GridView. Однако, следует учесть, что использование Out-GridView требует, чтобы был установлен .NET Framework 3.5 SP1.
Добавлен режим Quiet, который ничего не выводит на экран, а только генерирует коды возврата (LastExitCode). Коды возврата обновлены.
Пофиксены сообщения режимов Verbose и Debug.
Исправлены мелкие неточности в коде и произведена небольшая оптимизация кода.

А теперь и on-line справка по всем параметрам по просьбе трудящихся.

Path <String> — путь к папке, файлы которой следует посчитать или проверить. Допускаются относительные пути. Данный параметр обязателен.
XML <String> — путь к XML файлу, который содержит сведения о файлах. Если указанный файл не существует, то после пересчёта файлов по этому пути будет создан новый файл БД со сведениями о файлах. Параметр обязателен.
Include <String> — опциональный параметр в котором вы можете указать только конкретный файл из папки. В таком случае будет проверена не вся папка, а только указанный файл. В настоящее время параметр не поддерживает подстановочные знаки (wildcard), типа '*.ext' из-за обеспечения поддержки файлов с метасимволами (например, в имени содержатся квадратные скобки).
Action <String> — опциональный параметр, который указывает на действие над файлами, у которых не совпадают хеши или сведения о дате изменения и размере файла. Может принимать значение Rename или Delete. В первом случае к проблемным файлам добавляется расширение .BAD, а во втором файл просто удаляется.
Show <String[]> — опциональный параметр, в котором указываются категории файлов для дальнейшего анализа. В зависимости от результата проверки каждый файл (его имя) помещается в ту или иную категорию. Требует установленного .Net Framework 3.5 SP1. Может принимать один или несколько аргументов из списка:
- Bad — содержит имена всех файлов, у которых обнаружен несовпадающий хеш или не совпадает дата/время изменеия и/или размер файла;
- Locked — в эту категорию помещаются файлы хеш которых проверить не удалось по причине блокировки файла в монопольном режиме каким-то приложением;
- Missed — содержит имена файлов, для которых есть запись в XML файле БД, но самого файла уже не существует (по любым причинам);
- New — в эту категорию попадают только имена новых файлов, для которых соответствующей записи ещё нет в XML файле. Новые файлы добавляются только в режиме Rebuild или когда файл БД создаётся с нуля.
- Ok — сюда попадают файлы с успешным статусом проверки, т.е. хеш, дата/время изменения и размер файла совпадают со значениями в XML файле;
- Total — содержит имена всех обработанных файлов вне зависимости от результата проверки;
- Unknown — содержит имена файлов, для которых нельзя сопоставить хеш. Такая ситуация возможна, если в параметрах функции указан только хеш SHA1, но для файла в БД записан только MD5 хеш и наоборот.
Recurse <Switch> — ключ, который включает проверку файлов не только в указанной папке, но и во всех вложенных папках.
Rebuild <Swtich> — ключ, который задаёт особый режим работы скрипта — «освежение». Если этот ключ указан, то производится сверка файлов из БД с реальными файлами. Если файл более не существует, то соответствующая запись для него удаляется из БД. После чего целевая папка (и подпапки при указанном ключе –Recurse) проверяется на наличие новых файлов. Для каждого нового файла добавляется соответствующая запись в XML файл.
SHA1 <Switch> — задаёт алгоритм хеширования, который будет использоваться для подсчёта новых файлов и/или для проверки уже существующих записей в XML файле.
MD5 <Switch> — задаёт алгоритм хеширования, который будет использоваться для подсчёта новых файлов и/или для проверки уже существующих записей в XML файле.
Quiet <Switch> — включает несопровождаемый режим работы скрипта. Если ключ указан, то итоговая статистическая информация не выводится на экран, а в зависимости от результата проверки генерируется код возврата (LastExitCode). Код возврата может принимать одно из следующих значений:
- 0 — в процессе работы скрипта все файлы были успешно проверены и их хеш, дата/время изменения и размер соответствуют записям в БД. Так же, данный код возврата будет сгенерирован, если создавался новый файл БД и все файлы были успешно в него добавлены;
- 1 — в процессе проверки были обнаружены файлы с несовпадающим хешем и/или датой/временем и размером;
- 2 — в процессе проверки было обнаружено, что для записи в БД нет соответствующего файла;
- 3 — в процессе проверки были обнаружены файлы, для которых не удалось сопоставить алгоритм хеширования с хранимым в БД алгоритмом хеширования для файла. Такая ситуация возможна, если в параметрах функции указан только хеш SHA1, но для файла в БД записан только MD5 хеш и наоборот;
- 4 — в процессе работы скрипта для некоторых файлов не удалось подсчитать хеш по причине блокировки файла в монопольном режиме другим приложением;
- 5 — скрипт выполнялся в режиме Rebuild (освежения файла БД)
Verbose <Switch> — включает отображение дополнительной информации о ходе проверки файлов.
Debug <Switch> — включает отображение отладочной информации о ходе работы скрипта.

Несколько примеров использования:

Start-PsFCIV C:\Files db.xml -SHA1 -Recurse -Show Bad, Missed

будет проверена папка C:\Files и все вложенные папки. Файл db.xml должен быть размещён непосредственно в этой папке. Если файл не существует, то будет создан с нуля. После проверки будет показано графическое окно с именами файлов, которые попали в категорию Bad и Missed. Для каждой категории будет отдельное графическое окно.

Start-PsFCIV C:\Files db.xml -SHA1 -MD5 -Include data.dat

будет проверен только файл data.dat в папке C:\Files с использованием SHA1 алгоритмом хешиования. Если для файла в БД записан только MD5 хеш, то проверка будет произведена с использованием MD5. Если файл БД (db.xml) не существует, то создастся новый файл БД со сведениями о файле data.dat. Файл будет подсчитан с использованием как SHA1, так и MD5.

Start-PsFCIV C:\Files db.xml -SHA1 -MD5 -Rebuild

будет произведено освежение файла БД для папки C:\Files. Все записи, для которых соответствующего файла не обнаружено, будут удалены. Если в папке есть файлы, для которых нет соответствующей записи, то они будут обсчитаны с использованием алгоритмов SHA1 и MD5 и будут добвлены в XML файл. Файл db.xml должен существовать, иначе скрипт вернёт фатальную ошибку.

Start-PsFCIV C:\Files db.xml -SHA1 -Quiet

Папка C:\Files будет проверена в несопровождаемом режиме с использованием алгоритма SHA1. По умолчанию никакой информации на экране не будет. После окончания работы, в зависимости от результатов проверки, скрипт сгенерирует соответствующий код возврата (0-5).

И, собственно, сам скрипт:

1 PS1 file
38,3 KB PSFCIV_1.0.ps1

И как обычно, любые замечания, комментарии постить в каменты.

PowerShell Powered - http://www.sysadmins.lv

PS FCIV (часть 3)

Camelot — Thu, 09 Jul 2009 21:43:12 GMT

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

1PS1 file
25,5 KB PSFCIV_0.85.ps1

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

.\PSFCIV_0.85.ps1 C:\Temp –xml DB.XML –sha1

При этом можно указать алгоритм –md5 или оба сразу (-sha1 –md5). В таком случае для каждого файла будет сгенерировано 2 хеша. Без указания любого из этих параметров будет сгенерирована ошибка и работа будет остановлена.

Опциональные параметры:

-Include file.ext – будет произведена проверка только указанного файла;
-Recurse – будет произведена проверка всех файлов в папке и подпапках;
-Rebuild – особый режим обновления XML файла, из которого будут удалены устаревшие записи и если есть новые файлы в папке или папках, то они будут добавлены в XML файл. Данный ключ требует наличия XML файла. Если файл БД не будет обнаружен, то будет выведена соответствующая ошибка. При этом режиме проверка целостности файлов не проверяется.
-Verbose brief/full – включает один из режимов вывода информации о ходе проверки на консоль. Можно выбрать Brief – упрощённый или Full – максимальный.
-Show Total/New/Ok/Bad/Miss – включает дополнительный режим вывода на экран одной из выбранных категорий. Например, всех проверенных файлов, только новых файлов, которые добавлены в БД, только файлов, которые прошли проверку, только файлы с несоответствующим хешем или только файлы, для которых есть запись в БД, но самого файла уже нету.
-Force Rename/Delete – включает режим действия над проблемными файлами. Можно выбрать – переименования (тогда к файлу будет добавлено расширение .BAD) или удаления файла.

На данном этапе реализована работа в соответствии с логикой (которая описана тут: PS FCIV (часть 1)) и односторонняя совместимость с FCIV. Т.е. этой утилите можно скармливать XML файл, который сгенерирован с помощью этого скрипта. В скрипте начата реализация поддержки альтернативных БД, которые не совместимы с FCIV XML. Плюс планируется обеспечение двусторонней поддержки FCIV – т.е. скрипт сможет корректно воспринимать и обрабатывать XML файлы, которые сгенерированы утилитой FCIV. Ну и оптимизация самого кода. Сам скрипт снабжён достаточно плотными комментариями, поэтому будет совсем нетрудно с ним разобраться. По мере дописывания кода буду выкладывать более актуальные версии файла.

Update 27.07.2009

Скрипт PsFCIV.ps1 переписан в виде Advanced Function под именем Get-PsFCIV. Теперь его достаточно загрузить в консоль используя dot-sourcing.
Добавлена справка для функции. После загрузки функции в консоль достаточно набрать команду: Get-Help Get-PsFCIV
По умолчанию на экран не выводится никакой информации, а только коды возврата. Коды возврата описаны в справке.
Изменён ключ -Verbose. Теперь используется стандартный ключ -Verbose для вывода расширенной информации. Аргументы не принмаются.
Добавлен стандартный ключ -Debug для вывода диагоностической информации.
Добавлена поддержка обработки XML файла сгенерированного утилитой FCIV (т.е. совместимость с FCIV теперь двусторонняя).
Ключ -Force заменён на ключ -Action с сохранением аргументов.
К ключу -Show добавлен ещё один аргумент Unknown для индикации файлов с неопределённым результатом проверки. Такое состояние у файла может быть в случае, если не удалось сопоставить алгоритмы хеширования. Т.е. когда при вызове функции указывается алгоритм –SHA1, но в XML файле есть только MD5 хеш и наоборот.

1 PS1 file
32,4 KB PSFCIV_0.88.ps1

PowerShell Powered - http://www.sysadmins.lv

PS FCIV (часть 2)

Camelot — Fri, 03 Jul 2009 20:26:05 GMT

Продолжаем повествование о процессе разработки функционального аналога FCIV.

Подсчёт хешей и кодирование в Base64 String

Как я уже упоминал, самая первая и основная функциональная часть – функция подсчёта хешей. Я уже делал скрипт, который считает хеши: Полезная безделушка Hash SHA1 на PowerShell, который и стал основой моего скрипта. Однако, по одной причине саму считалку пришлось обрезать. Если посмотреть справку по FCIV (http://support.microsoft.com/kb/841290), то он не записывает в БД реальный хеш файла, а пропускает его ещё через Base64 кодировку и закодированный хеш уже записывается в XML файл. В .NET уже есть стандартный кодировщик Base64, который на входе принимает массив байтов. Если посмотреть на указанный пост из моего блога, то там я приводил вывод объекта $hasher, который как раз и является байтовым массивом, который мы потом преобразовывали в строку. Здесь же преобразовывать в строку ничего не нужно, а сразу подаём этот массив в конвертер. Вот как выглядит функция подсчёта хеша:

function _hashbytes_ ($type, $file) {
    switch ($type) {
        "sha1" {$hasher = [System.Security.Cryptography.SHA1]::Create()}
        "md5" {$hasher = [System.Security.Cryptography.MD5]::Create()}
    }
    $inputStream = New-Object System.IO.StreamReader ($file)
    $hashBytes = $hasher.ComputeHash($inputStream.BaseStream)
    $inputStream.Close()
    $hashBytes
}

в качестве аргументов мы принимаем тип хеша – MD5 или SHA1 и сам файл:

[↓] [vPodans] _hashbytes_ sha1 wsr.txt
7
11
122
247
126
249
232
24
193
38
194
124
237
202
26
183
178
64
173
45
[↓] [vPodans] [System.Convert]::ToBase64String($(_hashbytes_ sha1 wsr.txt))
Bwt693756BjBJsJ87coat7JArS0=
[↓] [vPodans] [System.Convert]::ToBase64String($(_hashbytes_ md5 wsr.txt))
kshzMfHPdtuXdL6l/vWwPA==
[↓] [vPodans]

я подсчитал SHA1 хеш для текстового файла и на выходе получил такой же по структуре массив байтов, как и в предыдущей статье. И далее я этот массив подал в качестве аргумента для конвертера Base64 строки (статический метод ToBase64String класса System.Convert), а на выходе уже получил правильную Base64 строку. Именно эту строку FCIV записывает в файл. То же самое будем делать и мы. Кстати говоря. обратное преобразование делается через тот же класс System.Convert, но с использованием метода FromBase64String:

[↓] [vPodans] [System.Convert]::FromBase64String("Bwt693756BjBJsJ87coat7JArS0=")
7
11
122
247
126
249
232
24
193
38
194
124
237
202
26
183
178
64
173
45
[↓] [vPodans] -join ([System.Convert]::FromBase64String("Bwt693756BjBJsJ87coat7JArS0=") | %{"{0:X2}" -f $_})
070B7AF77EF9E818C126C27CEDCA1AB7B240AD2D
[↓] [vPodans]

как видите, массив байтов получился точно такой же. Второй строкой я показал, как можно собрать строку самого хеша, которую показывают различные программы подсчёта хешей. Как можно заметить все числа в массиве меньше, чем 256, т.е. не превышают значения 2⁸, что является 1 байтом в двоичной форме. В цикле Foreach-Object я преобразовываю каждый байт в HEX и собираю в единую строку оператором –Join, который доступен только в PowerShell V2. Но можно собрать и через [System.String]::Join() для PowerShell 1.0.

Генерация FCIV-совместимого XML файла

Если посмотреть в статью по FCIV, то увидим, что он использует свою нестандартную XML схему:

    <?xml version="1.0" encoding="utf-8" ?>
- <FCIV>
    - <FILE_ENTRY>
          <name>wsr.txt</name>
          <SHA1>Bwt693756BjBJsJ87coat7JArS0=</SHA1>
      </FILE_ENTRY>
     - <FILE_ENTRY>
          <name>0</name>
          <SHA1>xd/Rh0JyuW/I6sxPzY4sULyjS38=</SHA1>
      </FILE_ENTRY>
</FCIV>

По этой причине мы лишаемся возможности использования Export-CliXML и подобных команд, а нужно собирать вручную.

Внимание: хоть FCIV и непривередлив к дополнительным полям в XML, но он начинает сильно ругаться, если поле Name написано с большой буквы. Его нужно заполнять так, как он есть в экземпляре, т.е. все маленькие буквы.

Объект, который будет хранить все данные о файле будет вот такой:

$object = "" | Select Name, Size, TimeStamp, SHA1, MD5

Т.е. мы в XML будем писать имя файла, его размер в байтах, время и дату последней модификации файла и хеши SHA1 и MD5. Если при создании БД мы будем использовать только один хеш, то второй будет просто пустым. Для сборки XML нам потребуется потребуется функция. Эту схему можно разложить на 3 составные части:

заголовок XML и открывающийся тег <FCIV>. Это присуствует только в начале XML файла и всё. Этот тег и заголовок больше нигде в XML не встречается. Поэтому header и открывающийся тег нужно поместить в скриптоблок Begin функции.
А вот теги <FILE_ENTRY> они повторяются для каждой записи. Следовательно этот тег будем заполнять в конструкции Process функции. Т.е. в каждой итерации Process будет создаваться новый тег <FILE_ENTRY>. Но внутри этого тега есть ещё вложенные теги, которые описывают наш файл. Чтобы решить эту задачу мы должны внутри конструкции Process (которая по сути будет являться циклом) написать ещё один цикл, который будет разбирать входящий объект и данные из его свойств записывать во вложенные теги.
В конце XML файла будет закрывающийся тег </FCIV>, его будем помещать в скриптоблок End нашей функции.

Вот такая функция у меня получилась:

function _toxml_ {
# в Begin создаём заголовок XML и открывающийся тег <FCIV>
    Begin {
        $xmlstring += "<?xml version=`"1.0`" ?>`n <FCIV>`n"
    }
# в Process будут по одному поступать объекты, которые описывают файл.
    Process {
# для каждого файла у нас будет один тег <FILE_ENTRY>
        $xmlstring += " <FILE_ENTRY>`n"
# чтобы вручную не создавать и не заполнять вложенные теги мы простым foreach
# перечисляем теги, какие у нас будут в XML и за счёт переменных автоматом
# создаём их в XML и заполняем их данными. Для этого свойства объектов должны
# называться так же, как и теги.
        foreach ($child in ("name", "Size", "TimeStamp", "SHA1", "MD5")) {
            $xmlstring += " <$child>$($_.$child)</$child>`n"
        }
# когда текущий объект обработан, закрываем тег и ждём следующий объект файла
        $xmlstring += " </FILE_ENTRY>`n"
    }
# когда объекты закончились, закрываем первый тег <FCIV> и подаём полученный XML дальше
    End {
        $xmlstring += "</FCIV>`n"
        $xmlstring
    }
}

в ходе испытаний нарвался на одну засаду. В XML существуют некоторые символы как ‘&’, ‘<’, ‘>’ и другие (полный список перечислен тут: http://www.hdfgroup.org/HDF5/XML/xml_escape_chars.htm), которые нужно эксейпить, поскольку являются метасимволами в XML. Эти символы (в частности одинарная кавычка и амперсанд) могут присутствовать в имени файла. Погуляв по сайту MSDN нашёл выход. Выход заключается в использовании метода Escape класса System.SecurityElement. Поэтому после того как массив объектов (которые описывают каждый файл) будет собран его нужно пропустить через фильтр и только после этого собирать XML вышеприведённой функцией. Вот как выглядит фильтр:

filter _escxml_ {
    $_.name = [Security.SecurityElement]::Escape($_.name)
    $_
}

Напоминаю, что мы должны эскейпить только свойство Name нашего объекта.

Преобразование FCIV-совместимого XML в массив объектов

Вот мы уже научились правильно создавать XML файл, который будет полностью совместим со схемой, которая используется в самом FCIV. Теперь у нас возникает задача чтения этого XML и преобразования в массив объектов. Сначала я долго горевал, плакал и бился головой об стену, что нельзя использовать Import-CliXML, но преобразование типов решило задачу ничуть не сложнее:

function _fromxml_ ($xml) {
    $sum = ([xml]$(gc -LiteralPath $xml)).FCIV.FILE_ENTRY | %{$_ | Select Name, Size, TimeStamp, SHA1, MD5}
    $sum
}

сначала читаем файл и преобразовываем его в типа данных XML, опускаем теги FCIV и FILE_ENTRY и в цикле разбираем вложенные теги и собираем объект. Получилось достаточно просто. На сегодня, я думаю, что хватит, продолжение следует.

PowerShell Powered - http://www.sysadmins.lv

Scripting Games 2009 – Event5 (The 400-meter race)

Camelot — Sun, 14 Jun 2009 10:16:39 GMT

Beginner Division

задача на работу с реестром.

Задача:

Найти текущее значение максимального количества закачек в Internet Explorer
Увеличить это число на другое значение
при чтении этого значения предусмотреть проверку существования этого параметра

Решение:

Ключи и значения реестра для этой задачи можно найти тут: http://support.microsoft.com/kb/282402. В принципе, очень просто тут:

$path = 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings'
if (!(Test-Path $path)) {New-Item -ItemType Registry -Path $path -Force}
if (!(Get-ItemProperty $path).MaxConnectionsPer1_0Server) {
    Write-Warning "MaxConnectionsPer1_0Server property doesn't exist"
    [void](New-ItemProperty -Path $path -Name 'MaxConnectionsPer1_0Server' -Value 10 -PropertyType 'DWord')
} else {"MaxConnectionsPer1_0Server is: " + (Get-ItemProperty $path).MaxConnectionsPer1_0Server}
if (!(Get-ItemProperty $path).MaxConnectionsPerServer) {
    Write-Warning "MaxConnectionsPerServer property doesn't exist"
    [void](New-ItemProperty -Path $path -Name 'MaxConnectionsPerServer' -Value 10 -PropertyType 'DWord')
} else {"MaxConnectionsPerServer is: " + (Get-ItemProperty $path).MaxConnectionsPerServer}

и вот вывод:

[↓] [vPodans] $path = 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings'
[↓] [vPodans] if (!(Test-Path $path)) {New-Item -ItemType Registry -Path $path -Force}
[↓] [vPodans] if (!(Get-ItemProperty $path).MaxConnectionsPer1_0Server) {
>>     Write-Warning "MaxConnectionsPer1_0Server property doesn't exist"
>>     [void](New-ItemProperty -Path $path -Name 'MaxConnectionsPer1_0Server' -Value 10 -PropertyType 'DWord')
>> } else {"MaxConnectionsPer1_0Server is: " + (Get-ItemProperty $path).MaxConnectionsPer1_0Server}
>> if (!(Get-ItemProperty $path).MaxConnectionsPerServer) {
>>     Write-Warning "MaxConnectionsPerServer property doesn't exist"
>>     [void](New-ItemProperty -Path $path -Name 'MaxConnectionsPerServer' -Value 10 -PropertyType 'DWord')
>> } else {"MaxConnectionsPerServer is: " + (Get-ItemProperty $path).MaxConnectionsPerServer}
>>
WARNING: MaxConnectionsPer1_0Server property doesn't exist
WARNING: MaxConnectionsPerServer property doesn't exist
[↓] [vPodans] $path = 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings'
[↓] [vPodans] if (!(Test-Path $path)) {New-Item -ItemType Registry -Path $path -Force}
[↓] [vPodans] if (!(Get-ItemProperty $path).MaxConnectionsPer1_0Server) {
>>     Write-Warning "MaxConnectionsPer1_0Server property doesn't exist"
>>     [void](New-ItemProperty -Path $path -Name 'MaxConnectionsPer1_0Server' -Value 10 -PropertyType 'DWord')
>> } else {"MaxConnectionsPer1_0Server is: " + (Get-ItemProperty $path).MaxConnectionsPer1_0Server}
>> if (!(Get-ItemProperty $path).MaxConnectionsPerServer) {
>>     Write-Warning "MaxConnectionsPerServer property doesn't exist"
>>     [void](New-ItemProperty -Path $path -Name 'MaxConnectionsPerServer' -Value 10 -PropertyType 'DWord')
>> } else {"MaxConnectionsPerServer is: " + (Get-ItemProperty $path).MaxConnectionsPerServer}
>>
MaxConnectionsPer1_0Server is: 10
MaxConnectionsPerServer is: 10
[↓] [vPodans]

как бы ничего сложного.

Advanced Division

работа с тэгами файлов. Потребуются файлы TechEd1.JPG, TechEd2.JPG и TechEd3.JPG из Competitors Pack.

Задача:

прочитать следующие EXIF свойства файлов:
Имя
когда снимок был сделан
свойство Make
и модель камеры, которой был сделан снимок

Решение:

Задача не такая и сложная, на самом деле, как кажется. Для начала нам потребуется класс System.Drawing.Bitmap и его метод GetPropertyItem. Для работы с этим классом нужно подключить библиотеку System.Drawing.dll:

[void][reflection.assembly]::loadfile("C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Drawing.dll")

и создать объект System.Drawing.Bitmap:

$drawing = New-Object system.drawing.bitmap -ArgumentList .\TechEd1.jpg

Этот объект будет содержать всё нам необходимое. Чтобы посмотреть нужные нам свойства, нужно получить где-то список всех ID, которым соответствуют эти свойства. К сожалению я не нашёл такого списка на MSDN, а только отдельными частями в интернете:
http://www.exif.org/specifications.html

там в конце PDF файла есть Appendix с таблицой ID на эту тему. Если посмотреть в таблицу, то увидим, что Model находится под ID = 272. Глянем, что там есть:

[↓] [vPodans] $drawing = New-Object system.drawing.bitmap -ArgumentList .\TechEd1.jpg
[↓] [vPodans] $drawing.GetPropertyItem(271).value
67
97
110
111
110
0
[↓] [vPodans]

Как-то не очень радует такой вывод. Но если внимательно посмотреть на эти цифры, то можно заметить, что они не превышают число 256, что подсказывает, что это массив ASCII байтов. Эти ASCII байты можно сконвертировать в элемент вот так: [char]ASCII_Number. А т.к. это массив, то его нужно собрать либо методом ToString() или оператором –Join, который есть в PowerShell V2:

[↓] [vPodans] $drawing = New-Object system.drawing.bitmap -ArgumentList .\TechEd1.jpg
[↓] [vPodans] $drawing.GetPropertyItem(271).value
67
97
110
111
110
0
[↓] [vPodans] -join ($drawing.GetPropertyItem(271).value | %{[char]$_})
Canon
[↓] [vPodans]

Вот так оно всяко лучше стало. По такой же схеме выбираем и собираем все остальные свойства:

[void][reflection.assembly]::loadfile("C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Drawing.dll")
dir *.jpg | %{
    $drawing = New-Object system.drawing.bitmap -ArgumentList $_
    $photo = "" | Select Name, Author, Make, Model, DateTaken
    $photo.Name = $_.Name
    $photo.Author = -join ($drawing.GetPropertyItem(315).value | %{[char]$_})
    $photo.Make = -join ($drawing.GetPropertyItem(271).value | %{[char]$_})
    $photo.Model = -join ($drawing.GetPropertyItem(272).value | %{[char]$_})
    $photo.DateTaken = -join ($drawing.GetPropertyItem(36867).value | %{[char]$_})
    $photo
} | ft -AutoSize

[↓] [vPodans] [void][reflection.assembly]::loadfile("C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Drawing.dll")
[↓] [vPodans] dir *.jpg | %{
>>     $drawing = New-Object system.drawing.bitmap -ArgumentList $_
>>     $photo = "" | Select Name, Author, Make, Model, DateTaken
>>     $photo.Name = $_.Name
>>     $photo.Author = -join ($drawing.GetPropertyItem(315).value | %{[char]$_})
>>     $photo.Make = -join ($drawing.GetPropertyItem(271).value | %{[char]$_})
>>     $photo.Model = -join ($drawing.GetPropertyItem(272).value | %{[char]$_})
>>     $photo.DateTaken = -join ($drawing.GetPropertyItem(36867).value | %{[char]$_})
>>     $photo
>> } | ft -AutoSize
>>

Name        Author     Make   Model               DateTaken
----        ------     ----   -----               ---------
TechEd1.JPG Ed Wilson  Canon  Canon PowerShot G9  2009:05:12 10:41:03
TechEd2.JPG Ed Wilson  Canon  Canon PowerShot G7  2009:05:12 10:25:59
TechEd3.JPG Ed Wilson  Sony   A-9                 2009:05:12 10:26:48


[↓] [vPodans]

Вобщем, как видите, тут тоже ничего сверхсложного нету.

PowerShell Powered - http://www.sysadmins.lv

Cmdlet wrapping и PsBoundParameters

Camelot — Mon, 08 Jun 2009 21:41:52 GMT

Работая с функциями в PowerShell можно столкнуться с одной особенностью – в качестве передачи аргументов в функции или скрипты вы можете использовать почти всё, кроме ключей (данных типа Switch). Их передавать можно, но тут есть одна особенность. Обычно это ощущается, когда вы работаете с командлетами. Возьмём простой пример:

function Test ([string[]]$Path, [String]$Filter, [switch]$Force) {
Write-Host '$Path is:' $Path
Write-Host '$Filter is:' $Filter
Write-Host '$Force is:' $Force
}

и вызовем эту функцию:

[↓] [vPodans] function Test ([string[]]$Path, [String]$Filter, [switch]$Force) {
>> Write-Host '$Path is:' $Path
>> Write-Host '$Filter is:' $Filter
>> Write-Host '$Force is:' $Force
>> }
>>
[↓] [vPodans] Test C:\ * -force
$Path is: C:\
$Filter is: *
$Force is: True
[↓] [vPodans]

В принципе, всё как и ожидалось. Но если внимательно посмотреть на последний аргумент, то мы увидим лишь True, т.е. увидим факт, что ключ Force был передан. Однако, PowerShell не умеет подставять (биндить) переменную $Force (равно как и другие переменные) как именованный параметр в другую команду. Чтобы в этом убедиться, мы попробуем сымитировать нашу функцию как командлет Get-ChildItem:

[↓] [vPodans] function Test ([string[]]$Path, [String]$Filter, [switch]$Force) {
>> Get-ChildItem $Path $Filter $Force
>> }
>>
[↓] [vPodans] Test C:\ * -Force
Get-ChildItem : A positional parameter cannot be found that accepts argument 'True'.
At line:2 char:14
+ Get-ChildItem <<<<  $Path $Filter $Force
    + CategoryInfo          : InvalidArgument: (:) [Get-ChildItem], ParameterBindingException
    + FullyQualifiedErrorId : PositionalParameterNotFound,Microsoft.PowerShell.Commands.GetChildItemCommand

[↓] [vPodans]

Как видно, командлет Get-ChildItem не смог сопоставить последний аргумент ни с одним из своих параметров. Т.е. по факту выполнилась следующая строка:

Get-ChildItem -Path C:\ -Filter * True

PowerShell не смог сказать командлету, что мы указали ключ Force и хотим именно его передать в командлет. По факту в этом коде Get-ChildItem не знал, какие параметры ему были переданы и подставлял их на основе номера позиции параметра. А т.к. у Get-ChildItem нету параметра с порядковым номером 3 (с номером 1 идёт Path или LiteralPath, а с номером 2 идёт Filter. Остальные параметры именованные), то мы получили ошибку. Но всё же, как выкручиваться из этой ситуации? Вы можете как угодно пытаться подставить аргументы, но ничего не выйдет. Для этих целей в PowerShell V2 появилась специальная переменная - $PSBoundParameters. Эта переменная по сути представляет собой хэш-таблицу:

[↓] [vPodans] function Test ([string]$Path, [String]$Filter, [switch]$Force) {
>> $PSBoundParameters
>> }
>>
[↓] [vPodans] Test C:\ * -Force

Key                                                         Value
---                                                         -----
Force                                                       True
Path                                                        C:\
Filter                                                      *


[↓] [vPodans]

В отличии от первого примера переменная $PSBoundParameters содержит не только значения переменных, но и их имена (в перовм примере я вручную дописывал имена переменных), которые используются в качестве именованных параметров. Т.е. при подстановке аргументов в команду, она сначала выбирает имя переменной в качестве именованного параметра и значение переменной подставляет в качестве аргумента этого параметра. Синтаксис использования этой переменной очень прост:

function Name ($arg1, $arg2, $arg3 ... $argN) {
Command @PSBoundParameters
}

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

Command –arg1 <значение $arg1> –arg2 <значение $arg2> –arg3 <значение $arg3> … –argN <значение $argN>

Т.е. будут подставляться именованные параметры и значения переменных соответствующих аргументов. Давайте проверим, как это подействует на наш пример с Get-ChildItem:

function Test ([string]$Path, [String]$Filter, [switch]$Force) {
Get-ChildItem @PSBoundParameters
}

[↓] [vPodans] function Test ([string]$Path, [String]$Filter, [switch]$Force) {
>> Get-ChildItem @PSBoundParameters
>> }
>>
[↓] [vPodans] Test C:\ * -Force


    Directory: C:\


Mode                LastWriteTime     Length Name
----                -------------     ------ ----
d--hs       10.07.2007.     19:44            $Recycle.Bin
d--hs       09.03.2008.     17:53            Boot
d----       23.11.2008.     19:41            inetpub
d-rh-       26.06.2007.     22:27            MSOCache
d----       09.03.2008.     17:41            PerfLogs
<...>

И вы можете видеть, что у нас всё получилось в наилучшем виде! В сравнении с предыдущим примером фактически выполнилась следующая команда:

Get-ChildItem -Path C:\ -Filter * -Force

Для формирования аргументов для командлетов в функциях (так называемые wrapped cmdlets) это самый красивый и идеальный вариант. Если вы захотите изменить логику стандартных командлетов или добавить в них свой функционал, то $PSBoundParamters сделает за вас очень много лишней работы. Но это не единственное полезное применение для этой переменной. Она так же позволяет сократить возможность ошибки при вызове функции внутри скрипта или другой функции, которая принимает те же аргументы. Давайте посмотрим ещё один пример:

function Test ([string[]]$Path, [String]$Filter, [switch]$Force) {
    Write-Host '$Path in Test is:' $Path
    Write-Host '$Filter in Test is:' $Filter
    Write-Host '$Force in Test is:' $Force
    Write-Host --------------------------------
    function Test2 ([switch]$Force, [string[]]$Path, [String]$Filter) {
        Write-Host '$Path in Test2 is:' $Path
        Write-Host '$Filter in Test2 is:' $Filter
        Write-Host '$Force in Test2 is:' $Force
    }
    Test2 @PSBoundParameters
}

Что мы делаем: мы создали функцию Test, которая принимает набор аргументов. Внутри этой функции есть другая функция Test2, которая принимает те же аргументы. Далее из функции Test вызываем функцию Test2 и с помощью $PSBoundParameters передаём в неё аргументы. Обратите внимание, что в функции Test2 я изменил порядок аргументов. Это сделано для того, чтобы показать, что $PSBoundParamters отсортирует наши аргументы. А теперь внимание на экран:

[↓] [vPodans] function Test ([string[]]$Path, [String]$Filter, [switch]$Force) {
>>     Write-Host '$Path in Test is:' $Path
>>     Write-Host '$Filter in Test is:' $Filter
>>     Write-Host '$Force in Test is:' $Force
>>     Write-Host --------------------------------
>>     function Test2 ([switch]$Force, [string[]]$Path, [String]$Filter) {
>>         Write-Host '$Path in Test2 is:' $Path
>>         Write-Host '$Filter in Test2 is:' $Filter
>>         Write-Host '$Force in Test2 is:' $Force
>>     }
>>     Test2 @PSBoundParameters
>> }
>>
[↓] [vPodans] Test C:\ * -Force
$Path in Test is: C:\
$Filter in Test is: *
$Force in Test is: True
--------------------------------
$Path in Test2 is: C:\
$Filter in Test2 is: *
$Force in Test2 is: True
[↓] [vPodans]

И смотрите, что у нас получилось. А у нас получилось, что функция Test2 получила тот же набор аргументов, причём они были подставлены в правильном соответствии. Фактически строка Test2 @PSBoundParameters была преобразована в:

Test2 -Path $Path -Filter $Filter -Force $true

Т.е. в вариант, который мы вынуждены использовать в PowerShell 1.0. Плюс, мы имеем возможность подставлять позиционно ключи (объекты типа Switch), что есть очень позитивно.

PowerShell Powered - http://www.sysadmins.lv

Копирование файлов с графическим Progress Bar

Camelot — Sat, 23 May 2009 23:23:37 GMT

Навеяно множеством мотивов:

Как мне кажется, с Write-Progress вряд ли получится что-то хорошее, поэтому немного сориентировался и нашёл вот это: PowerShell Script: Copy-FilePlus. Именно этот скрипт взят за основу визуального окна. А за основу логики был взят мой простенький скрипт копирования файлов с сохранением структуры каталогов:Лёгкая разминка. Приведённый по ссылке на Copy-FilePlus вариант Хала Роттенберга является достаточно базовым, поскольку не позволяет копировать за раз множество файлов, плюс требуется вводить имя конечного файла. Я решил его немного расширить и добавить следующий функционал:

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

заранее оговорюсь, что скрипт обладает одним недостатком: не будет единого прогресс-бара для всех файлов, а только для каждого файла свой (издержки .NET). Зато хоть что-то и весьма актуально при копировании больших файлов. Код получился несколько солидным, но я его постарался снабдить комментариями о коде и о логике, на которой он работает. Причём следуя примеру Роттенберга я скрипт тоже оформил в Advanced Function. По advanced functions я в скрипте вложил ссылки, как почитать о них во встроенной справке PowerShell. И, собственно, сам код:

########################################################
# Copy files with GUI.ps1
# Version 1.3
#
# Copies single or couple files with GUI progressbar
# 
# Original idea: Oisín Grehan
# First edition: Hal Rottenberg
# Second edition: Vadims Podans
#
# Vadims Podans (c) 2009
# http://www.sysadmins.lv/
########################################################

# сразу после названия идёт описание к функции. После загрузки функции в консоль
# её справка будет доступна в консоли. Достаточно будет набрать:
# Get-Help Copy-FilesPlus
# вобщем, как в настоящих командлетах
function Copy-FilesPlus {
<#
.Synopsis
    Copies files and folders displaying GUI progress bar.
.Description
    This is a script, that demonstrates how PowerShell can use
    useful .NET types and PowerShell V2 capabilities.
.Parameter Path
    Specifies the filename or FileInfo object representing file to be copied.
    Objects can be passed through a pipeline.
.Parameter Destination
    Specifies the path for resulting copy operation
.Parameter Recurse
    Gets the items in the specified locations and in all child items of the locations.
    Used only when source directory passed through argument list. 
.Parameter Force
    Creates directory structure in destination folder and copies files to
    their source respective folders (Tree copy).
.EXAMPLE
    PS > Copy-FilesPlus -Path C:\tmp -Destination e:\Users
    
    This will copy only files from C:\tmp to E:\Users
.EXAMPLE
    PS > Get-Item C:\tmp\windows7.iso | Copy-FilesPlus -Destination E:\Users
    
    This will copy specified file from C:\tmp folder to e:\Users
.EXAMPLE
    PS > Get-Childitem D:\Shared | Copy-FilesPlus -Destination E:\ 
    
    This will copy all files from Shared folders to E: drive root directory
.EXAMPLE
    PS > Get-Childitem D:\Shared -Recurse | Copy-FilesPlus -Destination E:\ -Force
    
    This will copy all files in Shared folder and subfolders. Shared folder will be a
    tree root point. All directory structure will be copied with files to destination folder.
.EXAMPLE
    PS > Copy-FilesPlus C:\Users\User E:\ -Recurse
    
    This will copy all files from User folder and subfolders to destination directory without
    copying source folders tree
.EXAMPLE
    PS > Copy-FilesPlus C:\Users\User E:\ -Recurse -Force
    
    This will copy all files in User folder and subfolders. User folder will be a
    tree root point. All directory structure will be copied with files to destination folder.
.ReturnValue
    Genrally, script don't return anything, except errors!
.Link
    about_functions
    about_functions_advanced
    about_functions_advanced_methods
    about_functions_advanced_parameters
#Requires -Version 2.0
#>

# ну и теперь фишки от advanced functions в V2. CmdletBinding делает
# подстановку передаваемых аргументов в функцию. Если аргумент не передан
# то PowerShell попросит его ввести, а не вывалится с ошибкой
[CmdletBinding()]
    param (
        # первый аргумент. Он является обязательным и он может принимать значения
        # из конвейера. Причём, внутри блока Process {} для обозначения текущего элемента
        # можно использовать, как переменную $path, так и $_.
        [Parameter(Mandatory = $true,ValueFromPipeline = $true)]
        $Path,
        [Parameter(Mandatory = $true)]
        [string]$Destination,
        [switch]$Recurse,
        [switch]$Force
    )
    begin {
        # пробуем создать папку назначения, куда будут копироваться файлы.
        [void](md $Destination -Force -ea 0)
        # вот тут я сделал переменную для счётчика. Счётчик мне потребуется для того,
        # чтобы при использовании ключа -Force и если файлы передаются по конвейеру
        # можно было брать точку начала дерева структуры, которая будет копироваться.
        $n = 0
        # временная функция, которая выполняет само копирование. Тут нужно учесть то,
        # что путь назначения должен указываться в полном формате с указанием имени
        # конечного файла. Относительные пути тут не поддерживаются. Поэтому дальше
        # в коде я буду сохранять имя оригинального файла. т.е. переименовывание файлов
        # на лету не поддерживается
        function _routinecopy_ ([string]$Destination) {
            process {
                Add-Type -AssemblyName microsoft.visualbasic
                [Microsoft.VisualBasic.FileIO.FileSystem]::CopyFile($_, $Destination, 
                [Microsoft.VisualBasic.FileIO.UIOption]::AllDialogs,
                [Microsoft.VisualBasic.FileIO.UICancelOption]::ThrowException)
            }
        }
    }
    process {
        try {
            # вот здесь я проверяю, откуда пришли файлы - через аргументы или через конвейер
            # если данные пришли из обоих путей, то приоритет за конвейером
            if ($_) {
                # проверяем, что объект существует и что это объект файловой системы
                $File = gi $Path.FullName -ea stop | ?{$_.PsProvider -match "FileSystem$"}
                if ($File) {
                    # если объект в порядке и выполняется только первая итерация конвейера
                    # то мы задаём точку начала дерева. Весь путь от этой точки до имени файла
                    # будет копироваться в папку назначения
                    if ($n -eq 0) {
                        # здесь отрезаем от файла структуру папок, которая будет являться границей дерева
                        $RootPoint = $Path.FullName -replace $([regex]::Escape($Path.Name))
                        # заодно на основе этой структуры делаем регулярное выражение. Этим регулярным
                        # выражением будем у всех последующих файлов отрезать начало и оставлять необходимую
                        # часть дерева
                        $RootRegEx = [regex]::Escape($RootPoint.Substring(0,$RootPoint.Length -1))
                        # важно, что эту операцию нужно проделать единожды, чтобы точка монтирования дерева
                        # больше не менялась в процессе. Поэтому увеличиваем счётчик и тогда в течении текущего
                        # процесса копирования код сюда не вернётся
                        $n++
                    }
                    # проверяем, что нужно ли копировать дерево или нет.
                    if ($Force) {
                        # если копируем дерево, то выбрасываем папки и работаем только с файлами
                        $File = $File | ?{!$_.PsIsContainer}
                        if ($File) {
                            # если есть файлы для копирования, то выбираем весь путь папок до текущего файла
                            # и заранее приготовленным регэкспом отрезаем начало. В переменную $rep мы запишем
                            # дерево папок от точки монтирования дерева до имени файла
                            $rep = $Path.Directory.ToString() -replace $RootRegEx
                            # а теперь к папке назначения пристыковываем дерево папок от точки монтирования до имени файла
                            $DestFolder = Join-Path $Destination $rep
                            # заранее создаём начальный хвостик папок в целевой папке и подавляем вывод на экран
                            [void](md $DestFolder -Force -ea 0)
                            # а теперь к новому конечному пути пристыковываем имя файла
                            $Dest = Join-Path $DestFolder $Path.Name
                            # и теперь подаём текущий файл в функцию копирования. Вот тут мы и увидим прогресс-бар.
                            $Path.FullName | _routinecopy_ $Dest
                        }
                    } else {
                        # если структуру папок копировать не надо, то все файлы, что пришли с конвейера будут копироваться
                        # в папку назначения без создания структуры папок.
                        if (!$_.PsIsContainer) {
                            $Dest = Join-Path $Destination $File.Name
                            $File | _routinecopy_ $Dest
                        }
                    }
                # если объект не существует или это не объект файловой системы (защита от дураков, да-да :)), то ругаемся
                } else {throw "Input object does not represent any applicable FileSystem object"}
            } else {
                # если данные об источнике копирования переданы через аргументы, то проверяем, что заданный путь допустим
                # и объект, который мы получим после Get-Item является объектом файловой системы
                $File = gi $Path -ea stop | ?{$_.PsProvider -match "FileSystem$"}
                if ($File) {
                    # если всё хорошо, то указанный файл или папка становятся точкой монтирования дерева
                    $RootPoint = Resolve-Path $Path
                    # если ключи -Force -Recurse не указаны, то копируется либо указанный файл или все файлы в указанной
                    # папке в папку назначения
                    if (!$Recurse) {
                        dir $RootPoint | ?{!$_.PsIsContainer} | %{$Dest = Join-Path $Destination $_.Name
                            $_.FullName | _routinecopy_ $Dest}
                    # хитрый режим, когда рекурсивно выбираются все файлы в указанной папке и всех подпапках и копируются
                    # в папку назначения без сохранения структуры (т.е. в папке назначения будет большая куча файлов).
                    } elseif ($Recurse -and !$Force) {
                        dir $RootPoint -Recurse | ?{!$_.PsIsContainer} | %{$Dest = Join-Path $Destination $_.Name
                            $_.FullName | _routinecopy_ $Dest}
                    # если указаны оба ключа, то мы повторяем структуру исходных папок относительно точки монтирования дерева
                    # в папке назначения
                    } elseif ($Recurse -and $Force) {
                        dir $RootPoint -Recurse | ?{!$_.PsIsContainer} | %{
                            # тут мы делаем то же самое, что и в случае, когда файлы пришли с конвейера
                            $RootRegEx = [regex]::Escape($RootPoint)
                            $rep = $_.Directory.ToString() -replace $RootRegEx
                            $DestFolder = Join-Path $Destination $rep
                            [void](md $DestFolder -Force -ea 0)
                            $Dest = Join-Path $DestFolder $_.Name
                            $_.FullName | _routinecopy_ $Dest
                        }
                    }
                } else {throw "Input object does not represent any applicable FileSystem object"}
            }
        } catch {$_}
    }
}

Вот такой скриптик у меня получился. Местами даже очень умный, почти как я . Как мне кажется, на этом коде тоже можно чему-то поучиться. Если будут вопросы – то welcome в комментарии.

PowerShell Powered - http://www.sysadmins.lv

ConvertFrom-StringData

Camelot — Tue, 10 Feb 2009 08:43:49 GMT

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

ключ1 = значение1
ключ2 = значение2
ключ3 = значение3
ключ4 = значение4

при этом иногда очень хочется работать с этими строками как с объектами. Т.е. при указании объекта и его ключа, например, $a.key1 получить его значение. Как это делается в хэш-таблицах. Вот пример:

[vPodans] $a = @{"key1"="value1";"key2"="value2"}
[vPodans] $a

Name                           Value
----                           -----
key2                           value2
key1                           value1


[vPodans] $a.key1
value1
[vPodans] $a.key2
value2
[vPodans]

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

[vPodans] $a = "key1 = value1"
[vPodans] $a
key1 = value1
[vPodans] $a.GetType().FullName
System.String
[vPodans] $b = ConvertFrom-StringData -StringData $a
[vPodans] $b

Name                           Value
----                           -----
key1                           value1


[vPodans] $b.GetType().FullName
System.Collections.Hashtable
[vPodans] $b.key1
value1
[vPodans]

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

[vPodans] $a = gc keys.txt
[vPodans] $a
key1 = value1
key2 = value2
key3 = value3
key4 = value4
[vPodans] $a[0]
key1 = value1
[vPodans] ConvertFrom-StringData -StringData $a
ConvertFrom-StringData : Cannot convert 'System.Object[]' to the type 'System.String' required by parameter 'StringData
'. Specified method is not supported.
At line:1 char:35
+ ConvertFrom-StringData -StringData <<<<  $a
    + CategoryInfo          : InvalidArgument: (:) [ConvertFrom-StringData], ParameterBindingException
    + FullyQualifiedErrorId : CannotConvertArgument,Microsoft.PowerShell.Commands.ConvertFromStringDataCommand

[vPodans]

командлет Get-Content (или его алиас GC, не путать с глобальным каталогом) читает файл построчно в виде массива. Следовательно каждая строка является отдельным элементом массива. Как быть в такой ситуации? На первый взгляд может показаться, что можно Get-Content разобрать через Foreach-Object и уже отдельные элементы массива подавать конвертеру в качестве строк. Смотрим:

[vPodans] $a = gc keys.txt | %{ConvertFrom-StringData -StringData $_}
[vPodans] $a

Name                           Value
----                           -----
key1                           value1
key2                           value2
key3                           value3
key4                           value4


[vPodans] $a.key1
[vPodans] $a.GetType().FullName
System.Object[]
[vPodans] $a[0].key1
value1
[vPodans]

Как видите, мы на выходе получили не одну хэш-таблицу, а массив одиночных хэш-таблиц и для доступа к его ключам и значениям нужно ещё указывать номер элемента в массиве. Чтобы решить данную проблему нужно каким-то образом прочитать файл не построчно, а в виде целой строки. Для чтения файла целиком можно воспользоваться методом ReadAllText класса File Class. Как видно из описания метода, он читает текст в единую строку. Давайте посмотрим, что у нас получится:

[vPodans] $a = [io.file]::ReadAllText("keys.txt")
[vPodans] $a
key1 = value1
key2 = value2
key3 = value3
key4 = value4


[vPodans] $a.GetType().FullName
System.String
[vPodans] $b = ConvertFrom-StringData -StringData $a
[vPodans] $b

Name                           Value
----                           -----
key2                           value2
key4                           value4
key1                           value1
key3                           value3


[vPodans] $b.key1
value1
[vPodans] $b.key2
value2
[vPodans] $b.key3
value3
[vPodans] $b.key4
value4
[vPodans]

или просто в одну строчку:

ConvertFrom-StringData -StringData ([io.file]::ReadAllText("keys.txt"))

Вот так просто в стиле The PowerShell Way (в одну строчку) можно текстовые файлы сконвертировать в хэш-таблицы и работать с ними как с объектами, что есть удобно и полезно.

PowerShell Powered - http://www.sysadmins.lv

Обзор новых командлетов PowerShell V2 CTP3 - Active Directory/Workgroup

Camelot — Mon, 05 Jan 2009 13:35:10 GMT

Продолжая цикл постов о новых командлетах в PowerShell V2 CTP3 хочу рассказать про несколько командлетов для управлением компьютера как клиента в домене Active Directory или рабочей группе. Отмечу сразу, что эти командлеты не управляют доменом Active Directory, а только компьютером-клиентом домена (не знаю, как по-русски правильно сформулировать мысль). По сути эти командлеты повторяют аналог утилиты netdom.exe и вот их список:

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

и ещё 2 на закуску:

Restart-Computer
Stop-Computer

Ну и как обычно - рассмотрим каждый из них:

1) Add-Computer - добавляет компьютер к домену Active Directory или перемещает компьютер между рабочими группами (Workgroup). Данный командлет содержит следующие параметры и ключи:

-ComputerName - параметр. Имя компьютера, который нужно включить в домен или рабочую группу. Можно указывать как NetBIOS имена, так и FQDN (Fully Qualified Domain Name) и IP адреса компьютеров. Для локального компьютера можно использовать точку ( . ) или localhost или не указывать этот параметр совсем, поскольку по умолчанию будет использовать именно локальная машина. Так же можно указывать несколько компьютеров перечисляя их через запятую. Имена можно передавать в командлет по конвейеру по свойству ComputerName.
-Credential - параметр. Учётные данные для аутентификации в домене или на удалённых компьютерах рабочей группы. Формат учётных данных такой же, как и в подключениях WMI. Для этого можно использовать командлет Get-Credential. Данный параметр следует использовать только при необходимости использования альтернативных учётных данных. Если не указан, то будут использоваться учётные данные текущего пользователя.
-DomainName - параметр. DNS имя домена, куда будет подключаться компьютер. Этот параметр является обязательным при подключении к домену.
-WorkgroupName - параметр. Название рабочей группы, в которую перемещается компьютер. Обязателен при переводе компьютера из одной рабочей группы в другую.
-OUPath - параметр. Если заранее учётная запись компьютера заранее не создана в AD, то указание этого параметра позволяет добавить компьютер в нужный OU с созданием учётной записи в нём. Если этот параметр не указан, то компьютер будет помещён в контейнер по умолчанию - CN Computers. Так же этот параметр не нужно указывать при перемещении компьютера между рабочими группами.
-Server - параметр. Используется только при подключении к домену. Позволяет выбирать контроллер домена, который будет производить ввод компьютера в домен и установку пароля компьютера в домене. Параметр опциональный и может иметь смысл при добавлении машин в домен в удалённых сайтах. Указывается в формате DomainName\DCName.
-Unsecure - ключ. Операция по вводу компьютера в домен или рабочую группу будет производиться без установки защищённого канала между клиентом и сервером (контроллером домена). В домене с жёсткими политиками безопасности данный ключ может дать сбой.
-Reboot - ключ. Как известно любое изменение местоположения компьютера в сети (ввод в домен, вывод из домена, смена рабочей группы) требуют перезагрузки машины.

Примечание: может показаться, что ключ -Reboot очень полезный, но мне так не кажется. И вот почему. Если командлет сам не перезагружает машину после завершения операции, то это нужно сделать вручную. Но перезагружать машину можно только в случае если всё прошло успешно. Но если по каким-то причинам ожидаемый результат не был достигнут, то компьютер будет перезагружен в пустую. Я на этом не настаиваю, но мне это видится именно так.

Hint: не забывайте, что если указываются позиционные параметры, то их имена указывать не обязательно. Например, ComputerName позиционно является первым параметром и если указывать за командлетом сразу имена компьютеров, то название параметра -ComputerName можно и не указывать.

По умолчанию данный командлет не выводит результат на экран, поэтому для вывода результата исполнения можно использовать ключи -PassThru или -Verbose. Так же командлет имеет такие полезные ключи как -Confirm для ручного подтверждения выполнения операции и -WhatIf для моделирования работы командлета. И несколько примеров использования командлета:

Add-Computer -DomainName contoso.com -Credential (Get-Credential) -OUPath OU=Test,OU="3th floor",DC=Contoso,DC=com -Reboot
Add-Computer -ComputerName (Get-Content Comps.txt) -WorkgroupName MSHome -PassThru

2) Remove-Computer - удаляет компьютер из домена или рабочей группы. Содержит параметры -ComputerName, -Credential (учётные данные пользователя, который имеет право на вывод машины из домена или локального администратора, если компьютер перемещается в рабочих группах), -Reboot, -Confirm, -PassThru и -WhatIf. Правила использования этих параметров и ключей такие же, что и для Add-Computer, но только в контексте удаления, а не ввода машины во что-то. Пример:

Remove-Computer -ComputerName computer1, computer2 -Credential contoso.com\Administrator -PassThru -Reboot - выводит компьютер из домена. Следует учесть, что при выполнении команды будет запрошен пароль учётной записи, указанной в Credential.
Remove-Computer MyComputer - просто удаляет компьютер из рабочей группы (интересно, куда? )

Примечание: ни в коем случае не удаляйте так контроллеры домена. Их сначала нужно понизить до роли рядового сервера командой dcpromo и только потом с помощью UI, netdom или командлета Remove-Computer выводить из домена.

3) Rename-Computer - переименовывает компьютер или компьютеры в рабочей группе или домене Active Directory. Обычно использует следующие параметры:

-ComputerName - имя компьютера, которые нужно переименовать. Можно не указывать, если переименовывается локальный компьютер. Если компьютер находится в домене, то следует указывать его полное FQDN имя. Не поддерживает указание нескольких компьютеров, только одного.
-NewComputerName - новое имя компьютера. Если машина находится в домене, то переименовывается и её учётная запись.
-Credential - учётные данные. Данный параметр является обязательным при переименовании удалённых компьютеров-членов домена (кроме переименовывания локального компьютера).

так же командлет содержит такие ключи как -Confirm, -Reboot и -WhatIf.

Примечание: ни в коем случае не пытайтесь этим командлетом переименовать контроллер домена!

4) Reset-ComputerMachinePassword - сбрасывает пароль учётной записи компьютера в базе Active Directory. Используется только для доменных компьютеров. Данный командлет можно использовать при трудностях аутентификации компьютера в домене или при устаревании пароля. Несколько типичных случаев, когда требуется сброс пароля компьютера - компьютер не аутентифицировался в домене более 30 или 60 дней, в зависимости от настроек домена; компьютер был восстановлен из бэкапа (SystemState), срок которого старше 30 или 60 дней или компьютер был восстановлен из образа без дополнительного восстановления актуального SystemState и другие случаи.. Подробности этой темы выходят за рамки этого поста.

Из актуальных параметров содержит -ComputerName (можно указывать несколько компьютеров. Допускаются FQDN, NetBIOS имена или IP адреса), -Server - имя контроллера домена, который будет производить сброс пароля (не обязательный параметр) и -Credental - имя пользователя, который имеет права сброса паролей указанных компьютеров. Из ключей можно выделить такие как -Confirm и -WhatIf. Общий синтаксис такой:

Reset-ComputerMachinePassword (get-content comp.txt) - переустановит пароль всех компьютеров из списка comp.txt
Reset-ComputerMachinePassword - переустановит пароль текущего компьютера
Reset-ComputerMachinePassword -Server dc1.contoso.com -Credential (Get-Credential) -Confirm - переустановит пароль локального компьютера на контроллере домена с именем DC1 и с вводом альтернативных учётных записей. После запуска потребует подтверждения операции.

5) Test-ComputerSecureChannel - проверяет возможность установки безопасного канала между клиентом и сервером. Работает только в домене и возвращает True или False. Имеет один параметр и ключ:

-Server - параметр. Имя компьютера в домене (допускается использовать FQDN, NetBIOS имена или IP адрес). Допускается указание только одного компьютера, с которым хотите проверить работоспособность безопасного канала. Параметр обязательный, поскольку нету смысла проверять защищённый канал с самим собой
-Repair - ключ. Если команда выводит False, то при указании этого ключа команда будет пытаться восстановить его.

И содержит дополнительные ключи как -Confirm и -WhatIf.

Я не придумал к какой категории присвоить эти 2 командлета и решил их описать здесь. Кстати, очень удобные командлеты:

6) Restart-Computer и Stop-Computer. Первый командлет перезагружает локальный или удалённый компьютер (или несколько), а второй выключает их совсем. Это очень полезно, поскольку я видел как минимум 5 различных решений перезагрузки/выключения компьютеров в скриптах PowerShell. Как правило это либо WMI, либо использование штатного shutdown.exe (кстати говоря, я им пользуюсь всегда) либо ещё что-нибудь. Теперь можно будет этот момент стандартизировать. Много говорить про них не буду, а скажу только, что эти командлеты используют метод Win32Shutdown WMI класса Win32_OperatingSystem. Следовательно эти командлеты обладают всеми новыми возможностями, которые описаны в предыдущей статье: Обзор новых командлетов PowerShell V2 CTP3 - WMI. Одно из преимуществ - можно использовать фоновую работу. Скажем, отправить в ребут сотню компьютеров и пока это всё происходит спокойно работать в консоли (шутка ). Поэтому в этих командлетах можно использовать такие параметры и ключи как -AsJob, Impersonate, Authentication, ComputerName и другие. Из уникальных отмечу один параметр:

-ThrottleLimit - указывает количество одновременных удалённых подключений для конкретно этой команды. Если компьютеров будет много в этой команде, то чтобы не загружать сеть можно ограничить, скажем, по 10-20 одновременных подключений. По умолчанию максимум одновременно установлено 32 подключения.

и ключ:

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

На сегодня вроде всё. Вроде ничего не пропустил.

PowerShell Powered - http://www.sysadmins.lv

Обзор новых командлетов PowerShell V2 CTP3 - WMI

Camelot — Sun, 04 Jan 2009 18:37:15 GMT

Windows Management Instrumentarion или просто WMI в PowerShell V2 так же претерпел изменения, а точнее дополнения по сравнению с версией 1.0. Я планирую более подробно описать новые и обновлённые параметры командлета Get-WMIObject:

1) -List - ключ. Позволяет получать список классов для системы или список свойств и методов для конкретного класса:

[vPodans] Get-WmiObject -List


   NameSpace: ROOT\cimv2

Name                                Methods              Properties
----                                -------              ----------
__NotifyStatus                      {}                   {StatusCode}
__ExtendedStatus                    {}                   {Description, Operation, ParameterInfo, ProviderName...}
Win32_PrivilegesStatus              {}                   {Description, Operation, ParameterInfo, PrivilegesNotHeld...}
Win32_JobObjectStatus               {}                   {AdditionalDescription, Description, Operation, ParameterIn...
__SecurityRelatedClass              {}                   {}
__Trustee                           {}                   {Domain, Name, SID, SidLength...}
Win32_Trustee                       {}                   {Domain, Name, SID, SidLength...}
__NTLMUser9X                        {}                   {Authority, Flags, Mask, Name...}
....

По умолчанию, без указания других параметров, параметр -List выводит список классов, которые расположены в контейнере по умолчанию Root\CimV2. Но можно указывать и другие контейнеры при помощи параметра -NameSpace. Например:

Get-WmiObject -Namespace root\default -List

Или для конкретного класса:

[vPodans] Get-WmiObject Win32_share -List | select * | fl


Name             : Win32_Share
__GENUS          : 1
__CLASS          : Win32_Share
__SUPERCLASS     : CIM_LogicalElement
__DYNASTY        : CIM_ManagedSystemElement
__RELPATH        : Win32_Share
__PROPERTY_COUNT : 10
__DERIVATION     : {CIM_LogicalElement, CIM_ManagedSystemElement}
__SERVER         : THOR
__NAMESPACE      : ROOT\cimv2
__PATH           : \\THOR\ROOT\cimv2:Win32_Share
Path             : \\THOR\ROOT\cimv2:Win32_Share
Derivation       : {CIM_LogicalElement, CIM_ManagedSystemElement}
Methods          : {Create, SetShareInfo, GetAccessMask, Delete}
Scope            : System.Management.ManagementScope
Options          : System.Management.ObjectGetOptions
ClassPath        : \\THOR\ROOT\cimv2:Win32_Share
Properties       : {AccessMask, AllowMaximum, Caption, Description...}
SystemProperties : {__GENUS, __CLASS, __SUPERCLASS, __DYNASTY...}
Qualifiers       : {CreateBy, DeleteBy, dynamic, Locale...}
Site             :
Container        :



[vPodans]

здесь мы видим доступные методы (Create, SetShareInfo и другие), а так же свойства объекта класса (AccessMask, AllowMaximum, Caption и другие). Можно и более подробно посмотреть методы или свойства объекта:

Get-WmiObject Win32_share -List | %{$_.methods} - получение подробных сведений о методах объекта класса
Get-WmiObject Win32_share -List | %{$_.properties} - получение подробных сведений о свойствах объекта класаа

Кстати говоря, в PowerShell 1.0 параметр -List не работал для конкретных классов, а только для перечисления самих классов. Т.е. приведённые выше 2 команды в 1.0 не работают. Теперь этот недостаток исправлен.

2) -AsJob - ключ. Позволяет выполнять команду в фоновом режиме. Это новая возможность в PowerShell V2, которая позволяет запускать некоторые команды в фоновом режиме не блокируя при этом саму консоль. Коллега, Вася Гусев, уже делал скринкаст по фоновым работам в PowerShell (и не только о них) на TechDays.ru (потребуется авторизация с помощью LiveID или OpenID). И я так же планирую обсудить в своём блоге этот вопрос в обозримом будущем.

3) -Authentication - параметр. Позволяет задавать уровень аутентификации к удалённой машине. Возможные уровни аутентификации могут быть:

-1 (Unchanged) - я не смог найти описание этому уровню, но он в Windows XP/Windows Server 2003 используется для локальных подключений на себя.
0 (Default) - необходимый уровень будет согласовываться между сервером и клиентом в зависимости от настроек Windows Authentication.
1 (None) - не использует аутентификацию. Все уровни безопасности будут проигнорированы. Не следует использовать этот уровень, поскольку с ним аутентифицироваться не удастся (разве что в случае разрешённых анонимных подключений на сервере).
2 (Connect) - клиент аутентифицируется только при установке подключения. После установки подключения аутентификационные данные не проверяются.
3 (Call) - пересылаемые учётные данные проверяются при каждом запросе клиента. Учётные данные криптографически подписываются, но не шифруются. Пересылаемые данные во время сессии не подписываются и не шифруются. Гарантируется, что во время пересылки аутентификационных данных они не были никоим образом изменены.
4 (Packet) - похож на уровень Call с учётом того, что сервер проверяет что данные пришли от ожидаемого клиента. Так же учётные данные подписываются и не шифруются. Данные не подписываются и не шифруются (используется по умолчанию при сетевых подключениях).
5 (PacketIntegrity) - подписываются как учётные данные, так и сами пересылаемые данные. Данный уровень гарантирует, что с момента отправки от клиента до получения данных сервером любые данные не были изменены. Но данные (в том числе учётные) по прежнему не шифруются.
6 (PacketPrivacy) - все передаваемые данные между клиентом и сервером подписываются и шифруются.

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

$a = Get-WmiObject Win32_share -filter "Name = 'sharename'"
$a.PSBase.Scope.Options.Authentication = 6 или PacketPrivacy

4) -Authority - параметр. Позволяет клиенту выбирать, кто будет его аутентифицировать (например, LSA удалённой машины или сервер Active Directory) при указании параметра -Credentials.

5) -DirectRead - ключ. Если указывается, то производится прямой доступ к классу без привязки к нему более высших или производных классов. Реальной пользы я тут пока что не вижу.

6) -Impersonation - параметр. В этом параметре можно указывать уровень имперсонализации при удалённых подключениях. Может иметь следующие значения:

0 (Default) - так же не смог найти описания для него. Во всяком случае в самом WMI такой уровень нигде не определён и скорее всего это какой-то производный уровень из нескольких внутри самого PowerShell.
1 (Anonymous) - При указании этого уровня учётные данные клиента скрываются. По факту WMI в современных версиях ОС скорее всего не поддерживает этот уровень, а переводит его в уровень Identify и использует его для имперсонализации клиента. В Windows 2000 было так, во всяком случае. Да и особого смысла в нём нету, поскольку с таким уровнем ничего сделать не удастся в общем смысле.
2 (Identify) - позволяет объектам запрашивать учётные данные вызывающего пользователя, но не использовать их. Следовательно удалённый объект не сможет установить вас в контексте безопасности (т.е. подтвердить, что вы именно тот за кого себя выдаёте). С таким уровнем обычно можно только прочитать ACL списки объектов (и то не всегда), но не более.
3 (Impersonate) - позволяет объектам использовать учётные данные вызывающего пользователя. Это в свою очередь позволяет пользователю использовать свои учётные данные для произведения любых операций над объектами в пределах прав пользователя на этот объект (обычно эти права задаются ACL списками). Данный уровень используется в PowerShell по умолчанию. Поэтому для использования уровня Impersonate данный параметр указывать не обязательно.
4 (Delegate) - это уровень транзитивной делегации учётных данных. Это позволяет удалённым объектам передавать ваши учётные данные другим объектам на других машинах. Иными словами, когда пользователь с машины A подключается к машине B, то в этом случае используется уровень Impersonate между A и B. Но если для завершения операции объекту с машины B нужно получить ещё объект с машины C, то Delegate позволит машине B аутентифицироваться на машине C с учётными данными, которые были получены от машины A. Если совсем грубо, то пользователь просто разрешает запрашиваемым объектам использовать его учётные записи для своих нужд. Безусловно, это большой риск, когда объект может распоряжаться полученными учётными данными как хочет, поэтому все пользователи и компьютеры, которые будут участвовать в транзакции (например, пользователь и компьютеры A, B и C) должны быть помечены как Trusted For Delegation в Active Directory.

В версии 1.0 так же можно было изменять уровень имперсонализации с теми же сложностями, которые были и у параметра Authentication. А именно - нельзя было изменять этот уровень при первом подключении к WMI. Делалось это так:

$a = Get-WmiObject Win32_share -filter "Name = 'sharename'"
$a.PSBase.Scope.Options.Impersonation = 4 или Delegate

7) -EnableAllPrivileges - ключ. Данный ключ включает все привилегии безопасности (семейство SeSecurity Privilege), которыми обладает пользователь. Я уже не раз отмечал, что при работе в системе из графической оболочки Explorer, LSA (Local Security Authority) прозрачно для пользователя включает привилегии при необходимости. Однако, в целях безопасности для скриптов LSA по умолчанию не включает их. Привилегии безопасности нужны для многих операций, как смена владельца объектов, редактирования списков ACL множества объектов, выполнение критических для системы операции как удаление журналов событий, восстановления системы из точек восстановления и т.д. И только WMI нам предлагает интерфейс для их использования. Причём теперь это делается простым указанием ключа при использовании командлета Get-WmiObject. В общем смысле в версии 1.0 нельзя было из скриптов включать привилегии, хотя по факту данный функционал был заложен и активно использовался:

$a = Get-WmiObject Win32_share -filter "Name = 'sharename'"
$a.PSBase.Scope.Options.EnablePrivileges = $true

В этом отношении PowerShell является менее безопасным, чем, к примеру, VBS, который позволяет включать только необходимые привилегии безопасности (например для смены владельца объекта только SeRestorePrivilege и SeTakeOwnershipPrivilege). Причём VBS может очень гибко работать с подключаемыми привилегиями, что делает код более безопасным. В PowerShell они включаются все сразу и отдельные привилегии включать нельзя.

Вот, в принципе и рассмотрели основые полезные и интересные нововведения в командлет Get-WmiObject для работы с WMI в PowerShell V2 CTP3. Я допускаю, что эти параметры к релизу вряд ли претерпят существенные изменения и будут справедливы и в финальной версии V2.

PowerShell Powered - http://www.sysadmins.lv

Обзор новых командлетов PowerShell V2 CTP3 - SystemRestore

Camelot — Sat, 03 Jan 2009 11:45:20 GMT

В версии 2.0 появились командлеты, которые позволяют в однострочном режиме управлять параметрами восстановления системы. В них входят:

Get-ComputerRestorePoint
Checkpoint-Computer
Restore-Computer
Enabe-ComputerRestore
Disable-ComputerRestore

Мой вариант костылей для версии 1.0 описан здесь: SystemRestore и PowerShell. По сути в версии 1.0 доступно большинство функционала V2, но только в виде самописных функций, в V2 уже есть всё (или почти всё) в коробке. Для работы этих командлетов так же потребуются клиентские версии ОС Windows XP/Windows Vista. Посмотрим их попорядку:

1) Get-ComputerRestorePoint - получает список доступных точек восстановления.

Get-ComputerRestorePoint 490 - 490 - опциональный параметр, который позволяет получить сведения о конкретной точке восстановления.

[System32] Get-ComputerRestorePoint

CreationTime           Description                    SequenceNumber    EventType         RestorePointType
------------           -----------                    --------------    ---------         ----------------
2008.12.29. 21:14:04   Windows Installer installed... 490               BEGIN_SYSTEM_C... APPLICATION_INSTALL
2008.12.29. 21:56:01   Windows Update                 491               BEGIN_SYSTEM_C... APPLICATION_INSTALL
2008.12.29. 21:58:55   Windows Update                 492               BEGIN_SYSTEM_C... APPLICATION_INSTALL
2008.12.31. 1:38:08    Windows Update                 493               BEGIN_SYSTEM_C... APPLICATION_INSTALL
2009.01.01. 21:53:49   Windows Installer installed... 494               BEGIN_SYSTEM_C... APPLICATION_INSTALL
2009.01.01. 22:03:01   Windows Installer installed... 495               BEGIN_SYSTEM_C... APPLICATION_INSTALL
2009.01.02. 1:38:06    Windows Update                 496               BEGIN_SYSTEM_C... APPLICATION_INSTALL
2009.01.02. 19:45:27   Windows Installer installed... 497               BEGIN_SYSTEM_C... APPLICATION_INSTALL


[System32] Get-ComputerRestorePoint 490 | select *


__GENUS          : 2
__CLASS          : SystemRestore
__SUPERCLASS     :
__DYNASTY        : SystemRestore
__RELPATH        : SystemRestore.SequenceNumber=490
__PROPERTY_COUNT : 5
__DERIVATION     : {}
__SERVER         : THOR
__NAMESPACE      : root\default
__PATH           : \\THOR\root\default:SystemRestore.SequenceNumber=490
CreationTime     : 20081229191404.400068-000
Description      : Windows Installer installed Quest PowerGUI 1.5.3.
EventType        : 100
RestorePointType : 0
SequenceNumber   : 490
Scope            : System.Management.ManagementScope
Path             : \\THOR\root\default:SystemRestore.SequenceNumber=490
Options          : System.Management.ObjectGetOptions
ClassPath        : \\THOR\root\default:SystemRestore
Properties       : {CreationTime, Description, EventType, RestorePointType...}
SystemProperties : {__GENUS, __CLASS, __SUPERCLASS, __DYNASTY...}
Qualifiers       : {dynamic}
Site             :
Container        :



[System32]

Если посмотреть внимательней, то можно легко заметить, что данный командлет (как и все остальные, которые относятся к SystemRestore) реализован через тот же WMI класс SystemRestore. Поэтому на эти командлеты будут накладываться ограничения, которые накладывает этот класс. Это и версия ОС и права доступа. В данном случае для работы с командлетами восстановления системы нужны права администратора и для Windows Vista - проход запроса UAC.

2) Checkpoint-Computer - создаёт новую точку восстановления. Синтаксис командлета может быть такой:

Checkpoint-Computer -RestorePointType Application_Install -Description CustomDescription

-RestorePointType может иметь следующие значения:

APPLICATION_INSTALL
APPLICATION_UNINSTALL
DEVICE_DRIVER_INSTALL
MODIFY_SETTINGS
CANCELLED_OPERATION

-Description может иметь любое значение, поскольку это будет всего лишь описание. Но лучше использовать рекомендованные значения для описаний, которые документированы в статье MSDN: Restore Point Description Text. Стандартизация в наше время - это очень важно. Время создания точки восстановления на моём нотебуке составило чуть больше минуты и на экране консоли будет такой псевдографический прогресс-бар:

я вот тоже хочу как-нибудь научиться делать такие прогресс-бары.

3) Restore-Computer - восстанавливает компьютер до указанной точки восстановления:

Restore-Computer -RestorePoint 490 -Confirm -WhatIf

в параметре -RestorePoint указывается номер точки восстановления, который можно получить командой Get-ComputerRestorePoint. Данный командлет обладает ещё опциональными параметрами -Confirm, который будет требовать подтверждения пользователя и -WhatIf, который будет полезен в отладочных целях.

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

4) Enable-ComputerRestore - включает режим восстановления системы для всех дисков или для определённых.

Enable-ComputerRestore -Drive "C:\" -WhatIf

Параметры -Drive и -WhatIf являются не обязательными. Если не указан -Drive, то восстановление системы будет включено для всех допустимых дисков в системе.

5) Disable-ComputerRestore - отключает режим восстановления системы для всех дисков или определеённых:

Disable-ComputerRestore -Drive "C:\" -WhatIf

Параметры -Drive и -WhatIf являются не обязательными. Если не указан -Drive, то восстановление системы будет отключено для всех дисков в системе.

К сожалению функционал изменения настроек SystemRestore, как резервирование места для точек восстановления, время хранения, периодичность создания точек не реализован в командлетах. А ведь лишним это не будет однозначно. Поэтому в отношении CTP3 эти вещи придётся реализовывать с помощью WMI самостоятельно.

PowerShell Powered - http://www.sysadmins.lv

Обзор новых командлетов PowerShell V2 CTP3 - Eventlog

Camelot — Fri, 02 Jan 2009 20:11:19 GMT

PowerShell V2 CTP3 вышел уже давно (23 декабря прошлого года), но всё никак не доходили руки осветить новые командлеты. Сегодня постараюсь рассказать о новых возможностях работы с журналами событий готовыми командлетами. Функционал этих командлетов я уже реализовывал немного раньше:

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

Get-WinEvent
New-EventLog
Write-EventLog
Clear-Eventlog
Limit-EventLog
Remove-EventLog

начнём попорядку:

1) Get-WinEvent. Данный командлет призван заменить ранее использовавшийся командлет Get-Eventlog. Синтаксис команды может быть следующий:

[System32] Get-WinEvent -ListLog * | ft -a

LogName                                                                   MaximumSizeInBytes RecordCount  LogMode
-------                                                                   ------------------ -----------  -------
Application                                                                         20971520       17003 Circular
DFS Replication                                                                     15532032           6 Circular
HardwareEvents                                                                      20971520           0 Circular
Internet Explorer                                                                    1052672           0 Circular
Key Management Service                                                              20971520           0 Circular
ODiag                                                                               16777216         267 Circular
OSession                                                                            16777216         544 Circular
Security                                                                            33554432       16904 Circular
System                                                                              20971520       43146 Circular
Windows PowerShell                                                                  15728640       16803 Circular
ForwardedEvents                                                                     20971520             Circular
Microsoft-Windows-Backup                                                             1052672           6 Circular
Microsoft-Windows-Bits-Client/Analytic                                               1052672             Circular
Microsoft-Windows-Bits-Client/Operational                                            1052672        2226 Circular
....

Показ всех журналов событий в системе, включая журналы в Application and Services Logs (для Vista/2008). Вместо звёздочки можно указать конкретный журнал событий.

Примечание: некоторые журналы, как Security будут генерировать ошибку, если вы исполняете эту команду под обычным пользователем.

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

[System32] Get-WinEvent -ListProvider *

Name                                                        LogLinks
----                                                        --------
.NET Runtime                                                {Application}
.NET Runtime Optimization Service                           {Application}
Active Server Pages                                         {Application}
Application                                                 {Application}
Application Error                                           {Application}
Application Hang                                            {Application}
Application Management                                      {Application}
ASP.NET 1.1.4322.0                                          {Application}
ASP.NET 2.0.50727.0                                         {Application}
CardSpace 3.0.0.0                                           {Application}
Chkdsk                                                      {Application}
Crystal Reports                                             {Application}
DataDynamics ActiveBar 1.0                                  {Application}
Desktop Window Manager                                      {Application}
devenv                                                      {Application}
....

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

Get-WinEvent -ProviderName "Application Hang"

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

[System32] Get-WinEvent -ProviderName "Application Hang" -MaxEvents 1 | select *


Message              :
Id                   : 1002
Version              :
Qualifiers           : 0
Level                : 2
Task                 : 101
Opcode               :
Keywords             : 36028797018963968
RecordId             : 16431
ProviderName         : Application Hang
ProviderId           :
LogName              : Application
ProcessId            :
ThreadId             :
MachineName          : Thor
UserId               :
TimeCreated          : 2008.12.21. 17:19:47
ActivityId           :
RelatedActivityId    :
ContainerLog         : application
MatchedQueryIds      : {}
Bookmark             : System.Diagnostics.Eventing.Reader.EventBookmark
LevelDisplayName     :
OpcodeDisplayName    :
TaskDisplayName      :
KeywordsDisplayNames : {}
Properties           : {System.Diagnostics.Eventing.Reader.EventProperty, System.Diagnostics.Eventing.Reader.EventPrope
                       rty, System.Diagnostics.Eventing.Reader.EventProperty, System.Diagnostics.Eventing.Reader.EventP
                       roperty...}



[System32]

вот так выглядят внутренности события. Однако, свойство Message ничего не содержит, хотя предполагается, что там должен быть текст самого эвента. Пустое оно потому что:

[System32] Get-WinEvent -ProviderName "Application Hang" -MaxEvents 1 | gm -MemberType noteproperty


   TypeName: System.Diagnostics.Eventing.Reader.EventLogRecord

Name    MemberType   Definition
----    ----------   ----------
Message NoteProperty  Message=null


[System32]

в членах объекта мы видим, что свойство Message заткнуто заглушкой (Message=null) и оно ничего не возвращает. Но текст события можно извлечь из свойства Properties:

[System32] (Get-WinEvent -ProviderName "Application Hang" -MaxEvents 1).properties

Value
-----
mstsc.exe
6.0.6002.18000
ac0
01c9637bc8453f5e
8
{67, 0, 114, 0...}


[System32]

текст тут невнятный совсем. Для некоторых событий он возвращает такой же текст, что и в графическом журнале событий (и которые корректно отображаются командлетом Get-EventLog). Те события, которые не показывает корректно Get-EventLog в новом командлете уже не показывают ничего. Тут вся надежда на разработчиков, что они наконец-то сделают возможность полностью видеть тексты всех эвентов журнала событий, в противном случае придётся снова забивать костыли с помощью адского WMI. Но тут следует обратить внимание на параметр MaxEvents. Без его указания поиск только нескольких событий (например, первых 10 с использованием Select -First 10) займёт значительное время, поскольку команда будет работать пока весь журнал не будет прочёсан. Этот параметр является аналогом параметра -Newest для Get-EventLog. Поэтому если вы хотите посмотреть только часть событий, то используйте этот параметр. В общем смысле это выглядит так:

старая нотация: Get-EventLog application -Source "Application Hang" -Newest 5
новая нотация: Get-WineVent -ProviderName "Application Hang" -MaxEvents 5

И ещё одно хорошее отличие нового командлета - теперь не обязательно указывать журнал для поиска. Вы можете указать только поставщика событий и количество событий для вывода. Это очень удобно.

Следовательно можно судить, что новый командлет Get-WinEvent является значимо более лучшим, чем прежний Get-EventLog. Хотя его применимость в настоящее время весьма сомнительна, поскольку работу с текстом событий так никто и не сделал.

2) New-EventLog. Нетрудно догадаться, что этот командлет создаёт новый журнал событий:

New-EventLog -LogName "Custom EventLog" -Source "Custom Source"

[System32] New-EventLog -LogName "Custom EventLog" -Source "Custom Source"
[System32] Get-EventLog -List

  Max(K) Retain OverflowAction        Entries Name
  ------ ------ --------------        ------- ----
  20 480      0 OverwriteAsNeeded      17 011 Application
     512      7 OverwriteOlder              0 Custom EventLog
  15 168      0 OverwriteAsNeeded           6 DFS Replication
  20 480      0 OverwriteAsNeeded           0 HardwareEvents
     512      7 OverwriteOlder              0 Internet Explorer
  20 480      0 OverwriteAsNeeded           0 Key Management Service
  16 384      0 OverwriteAsNeeded         267 ODiag
  16 384      0 OverwriteAsNeeded         544 OSession
  32 768      0 OverwriteAsNeeded      16 908 Security
  20 480      0 OverwriteAsNeeded      43 162 System
  15 360      0 OverwriteAsNeeded      16 920 Windows PowerShell


[System32] Get-WinEvent -ListProvider "custom Source"

Name                                                        LogLinks
----                                                        --------
Custom Source                                               {Custom EventLog}


[System32]

Всё очень просто. Внизу я сделал проверку, что наш провайдер событий успешно зарегистрировался и он будет писать только в журнал Custom EventLog. Так же можно и добавлять события (поставщиков) к существующим журналам. Для этого в параметре -LogName нужно указать существующий журнал.

3) Write-Eventlog. Так же по смыслу можно догадаться, что данный командлет добавляет записи в журнал событий. Общий синтаксис его такой:

Write-EventLog -LogName "Custom EventLog" -Source "Custom Source" -EntryType Information -EventID 1 -Message "Привет мир!"

EntryType может иметь следующие значения: Error, Warning, Information, SuccessAudit, FailureAudit. Об этом я уже говорил ранее здесь. Смотрим:

[[System32] Write-EventLog -LogName "Custom EventLog" -Source "Custom Source" -EntryType Information -EventID 1 -Message
"Привет мир!"
[System32] Get-WinEvent -ProviderName "Custom source"

TimeCreated                   ProviderName                                             Id Message
-----------                   ------------                                             -- -------
2009.01.02. 21:05:06          Custom Source                                             1


[System32] Get-WinEvent -ProviderName "Custom source" | select *


Message              :
Id                   : 1
Version              :
Qualifiers           : 0
Level                : 4
Task                 : 1
Opcode               :
Keywords             : 36028797018963968
RecordId             : 1
ProviderName         : Custom Source
ProviderId           :
LogName              : Custom EventLog
ProcessId            :
ThreadId             :
MachineName          : Thor
UserId               :
TimeCreated          : 2009.01.02. 21:05:06
ActivityId           :
RelatedActivityId    :
ContainerLog         : custom eventlog
MatchedQueryIds      : {}
Bookmark             : System.Diagnostics.Eventing.Reader.EventBookmark
LevelDisplayName     :
OpcodeDisplayName    :
TaskDisplayName      :
KeywordsDisplayNames : {}
Properties           : {System.Diagnostics.Eventing.Reader.EventProperty}



[System32] (Get-WinEvent -ProviderName "custom source").Properties

Value
-----
Привет мир!


[System32]

Первой строкой мы создали новое событие в журнале, второй посмотрели общую сводку по провайдеру Custom Source, которого мы создали ранее. В нём уже зарегистрировано одно событие, которое мы посмотрели в расширенном виде. И последней строкой посмотрели текст созданного события.

Спросите вы, какая польза от этого, ведь кроме программистов это мало кому нужно? А польза есть от него. Для примера можно взять резервное копирование. Например, у администратор регулярно выполняются скрипты, которые делают резервное копирование данных. И создав нового провайдера или новый журнал администратор может в скрипт добавить код, который будет лог копирования помещать в журнал событий помимо стандартной процедуры отправки лога к себе на почту. Это может оказаться очень удобным! Так же данный командлет содержит параметр -WhatIf, который следует использовать в отладочных целях.

4) Clear-EventLog. Очистка журнала:

Clear-EventLog -LogName "Custom EventLog"

тут всё проще постого. Указываете имя журнала и очищаем его:

[System32] Clear-EventLog "Custom EventLog"
[System32] Get-EventLog -List

  Max(K) Retain OverflowAction        Entries Name
  ------ ------ --------------        ------- ----
  20 480      0 OverwriteAsNeeded      17 011 Application
     512      7 OverwriteOlder              0 Custom EventLog
  15 168      0 OverwriteAsNeeded           6 DFS Replication
  20 480      0 OverwriteAsNeeded           0 HardwareEvents
     512      7 OverwriteOlder              0 Internet Explorer
  20 480      0 OverwriteAsNeeded           0 Key Management Service
  16 384      0 OverwriteAsNeeded         267 ODiag
  16 384      0 OverwriteAsNeeded         544 OSession
  32 768      0 OverwriteAsNeeded      16 908 Security
  20 480      0 OverwriteAsNeeded      43 165 System
  15 360      0 OverwriteAsNeeded      16 920 Windows PowerShell


[System32]

Во второй строчке мы уже видим, что нами созданный журнал очистился от тестового сообщения. Данный командлет содержит параметр -WhatIf, который следует использовать в отладочных целях.

5) Limit-EventLog. Позволяет изменять размер журнала и политику перезаписи журнала. Общий синтаксис такой:

Limit-EventLog -LogName "Custom EventLog" -MaximumSize 64mb -OverflowAction OverWriteOlder -RetentionDays 10

[System32] Limit-EventLog -LogName "Custom EventLog" -MaximumSize 64mb -OverflowAction OverWriteOlder -RetentionDays 10
[System32] Get-EventLog -List

  Max(K) Retain OverflowAction        Entries Name
  ------ ------ --------------        ------- ----
  20 480      0 OverwriteAsNeeded      17 011 Application
  65 536     10 OverwriteOlder              0 Custom EventLog
  15 168      0 OverwriteAsNeeded           6 DFS Replication
  20 480      0 OverwriteAsNeeded           0 HardwareEvents
     512      7 OverwriteOlder              0 Internet Explorer
  20 480      0 OverwriteAsNeeded           0 Key Management Service
  16 384      0 OverwriteAsNeeded         267 ODiag
  16 384      0 OverwriteAsNeeded         544 OSession
  32 768      0 OverwriteAsNeeded      16 908 Security
  20 480      0 OverwriteAsNeeded      43 165 System
  15 360      0 OverwriteAsNeeded      16 920 Windows PowerShell


[System32]

Здесь мы задали размер журнала в 64 мегабайта и политику перезаписи старых логов старше 10 дней.

6) Remove-EventLog. Удаляет журнал событий или провайдера событий:

Remove-EventLog -Source "Custom Source" - удаляет провайдера событий из системы
Remove-EventLog -LogName "Custom EventLog" - удаляет указанный журнал из системы

И этот командлет содержит параметр -WhatIf.

В принципе, есть ещё командлет Remove-Event, который должен позволять удалять события из журналов событий, но мне пока что не удалось заставить его работать. Но вообще удаление эвентов из журналов событий - плохая и порочная практика, которая ни к чему хорошему не приведёт.

Вот мы и рассмотрели все новые командлеты в PowerShell V2 CTP3, которые относятся к работе с журналами событий (эвентлогами). В самом начале поста я привёл ссылки, на альтернативные решения, которые повторяют функционал этих командлетов для версии 1.0, но и даже умеют немножко больше (например, архивация и ротация архивов эвентлогов). В целом можно оценить позитив от новых командлетов, которые позволяют нам более удобным способом работать с журналами событий. Но всё равно нужно ждать рабочего решения, который смог бы получать тексты сообщений из журналов Windows Vista/Windows Server 2008, поскольку без него все эти нововведения мало кому будут нужны. Вобщем, как-то так.

PowerShell Powered - http://www.sysadmins.lv