Создание собственного средства инвентаризации программного обеспечения

В этом выпуске статьи, посвященной Windows Power-Shell, я собираюсь продемонстрировать ее крайне практичное применение: будет создано средство, выполняющее инвентаризацию номеров сборки операционных систем (один из лучших способов определения версии операционной системы) и номеров версий пакетов обновлений для некоторого списка компьютеров. Но я не просто собираюсь предоставить готовое решение. Я планирую провести вас по всем этапам процедуры, используемой мною для разработки такого рода сценариев.

При том, что это очевидно полезное средство, я считаю, что процедура, с помощью которой я разрабатыаю это средство, имеет еще более важное значение. После того как вы поймете эту процедуру разработки и сможете применить ее для решения своих собственных задач, вы будете уверенно себя чувствовать при решении практически любых задач по управлению с помощью Windows PowerShell. (Согласно старой пословице, если вы научите человка делать инструмент…) Итак, начинаем.

Поиск информации

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

Слова «извлечь» и «информация» незамедлительно подсказывают мне возможный ответ: Инструментарий WMI. Еще одно ключевое слово, заставляющее меня подумать об WMI, это «удаленный», поскольку в первой версии Windows PowerShell инструментарий WMI является практически единственной возможностью выполнения любой инвентаризации информации или операций управления.

К сожалению, в большинстве систем Windows существуют десятки тысяч классов WMI, и это затрудняет поиск того, в котором содержится необходимая вам информация. Обычно я запускаю механизм веб-поиска и ввожу фразу типа «wmi пакет обновлений версия номер». Отмечу, что для генерации более определенных результатов потребуется довольно длинная фраза поиска типа приведенной.

Возможно, вам даже придется попробовать несколько разных выражений поиска, но не следует соблазняться сокращениями («wmi sp версия» не даст слишком хороших результатов). Рассмотрите альтернативные выражения. Например, то, что вы можете назвать словом «заплатки», одни называют словом «исправления», а другие – «быстрая разработка исправлений» или «заплатки qfe». Чтобы найти правильные результаты, может потребоваться использование всех этих выражений.

Если вы ищете нечто, связанное с аппаратным обеспечением компьютера, или ядром ОС Windows, может помочь добавление «Win32» к фразе поиска, поскольку большая часть соответствующих классов WMI начинается с префикса «Win32_». Добавление «Win32» к моему текущему поиску определенно приведет к наилучшим результатам. Я вижу несколько результатов с «Win32_OperatingSystem» в заголовках — это имя класса WMI.

Теперь важно удержаться и не выбрать ни один из результатов поиска. (Это ведет к безумию.) Сначала я намерен найти страницы действующей документации по этим классам, поэтому я запускаю новый поиск, используя только обнаруженное имя класса. Обычно это приводит к ссылке на веб-узел msdn.microsoft.com в первой паре результатов и должно привести напрямую к чему-нибудь на странице документации по данному классу.

На рис. 1 показана часть этой страницы. На этой странице я переместился к особенно важной таблице, в которой перечислены версии ОС, с которыми будет работать данный класс. Не могу сказать, сколько раз я трудился над чем-нибудь, пытаясь заставить его работать, с тем, чтобы только обнаружить, что то, что я пытался сделать, в действительности не существует в той версии Windows, которую я использовал. Поэтому теперь у меня есть привычка предварительно просматривать эту таблицу.

Рис 1. Поиск сведений о классе WMI

Переместившись немного по странице, я вижу, что существуют два свойства, которые меня интересуют: BuildNumber and ServicePackMajorVersion. Фактически, ServicePackMinorVersion также могло бы быть полезным, хотя я никогда не видел пакет обновления от корпорации Майкрософт с номером 2.1. Тем не менее, оно, возможно, заслуживает проверки, если только стремиться к тщательности.
 

Командлет месяца: Export-CliXML и Import-CliXML

В Windows PowerShell имеется возможность хранить статический снимок данных в специальном формате XML, что позволяет информацию из этих объектов сохранить в файле и загружать в память для последующего изучения. Для сохранения этих объектов в файле достаточно передать объекты по конвейеру в Export-CliXML.

Get-Process | Export-CliXML c:\processes.xml

При последующем импорте этих объектов в оболочку их можно исследовать точно так же, как любой другой объект. Они не являются «реальными» объектами, но позволяют создать большее число вариантов отчетов. Предположим, что вы запланировали сценарий, выполняющий экспорт всех процессов на заданный сервер в 3:00, когда выполняется некоторая задача обслуживания. По приходе на работу можно загрузить эти процессы и изучить их, возможно, сортируя по объему потребляемой виртуальной памяти. Это можно сделать следующим образом.

Import-CliXML c:\processes.xml | Sort VM -descending

Создание прототипов

Я не предполагаю двигаться дальше, не убедившись в том, что эти свойства ведут себя так, как я рассчитываю. Windows PowerShell™ значительно облегчает это. Начинаю с проверки этой информации на своем локальном компьютере.

Get-WmiObject Win32_OperatingSystem | Select
BuildNumber,ServicePackMajorVersion,ServicePack­MinorVersion

Все в порядке, для дополнительной версии счетчик нулевой, на что я и рассчитывал, поэтому я собираюсь об этом забыть. Остальная информация также именно та, которую я ожидал: на моем компьютере номер сборки Windows Server 2008 — 6001, и пакет обновления версии 1.

Теперь я выполню подобную проверку на удаленном компьютере — на том, где у меня есть права администратора.

Get-WmiObject Win32_OperatingSystem –computer Server2 | 
Select BuildNumber,ServicePackMajorVersion

Если это не получается, мне необходимо остановиться и понять, в чем причина, прежде чем двигаться дальше. Любые неполадки вероятнее всего связаны с подключением, брандмауеэрами или правами. Все это находится вне сферы влияния Windows PowerShell. После того как все заработает надлежащим образом, можно переходить к следующему этапу в разрешении проблемы: как получить совокупность имен компьютеров из файла.

Чтение имен компьютеров

В предположении, что список имен компьютеров находится в текстовом файле, в каждой строке которого содержится одно имя компьютера, проще всего прочитать их с помощью командлета Get-Content. (Не волнуйтесь, если имена компьютеров не находятся в текстовом файле или перечислены не по одному в строке — в следующей статье будут обсуждаться методики работы в разных обстоятельствах.)

Каждое имя возвращается в виде независимого строкового объекта. У командлета Get-WmiObject есть удобная особенность, заключающаяся в том, что ее параметр –computerName принимает коллекцию имен компьютеров, поэтому в решении задачи должно помочь следующее.

$names = Get-Content c:\computernames.txt
Get-WmiObject Win32_OperatingSystem –comp $names | Select
BuildNumber,ServicePackMajorVersion

Теперь проблема заключается в том, что выходные данные представляют собой список чисел без какого-либо указания на соответствие номеров и компьютеров. К счастью, оказывается, что у класса Win32_OperatingSystem имеется еще одно свойство, CSName, содержащее имя компьютера. Поэтому можно добавить это свойство к выходным данным и получить удобный список.

$names = Get-Content c:\computernames.txt
Get-WmiObject Win32_OperatingSystem –comp $names | Select
CSName,BuildNumber,ServicePackMajorVersion

Создание модулей

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

Function Get-SPInventory ([string]$filename) {
  $names = Get-Content $filename
  Get-WmiObject Win32_OperatingSystem –comp  $names | Select   CSName,BuildNumber,ServicePackMajorVersion
}

Видно, что я просто оформил рабочий код в виде функции с именем Get-SPInventory. Я определил для нее входной параметр с именем $filename, поэтому ее можно вызывать следующим образом.

Get-SPInventory c:\computernames.txt

Результаты можно по-прежнему направлять в файл CSV, преобразовывать в HTML или форматировать другим способом с помощью обычных команд Windows PowerShell следующим образом.

Get-SPInventory c:\computernames.txt | 
Export-CSV SPInventory.csv

Однако это все еще не идеальный вариант. Что если мне требуется провести также инвентаризацию некоторой информации, не включенной в класс Win32_OperatingSystem, например серийных номеров BIOS всех компьютеров? Это было бы полезно, поскольку многие базы данных управления конфигурацией (CMDBs) используют серийный номер BIOS в качестве уникального идентификатора компьютера.

Может также потребоваться более гибкий вывод результатов работы функции, возможно, допускающий более удобную сортировку или фильтрацию результатов. Еще, например, можно было бы включать в окончательные выходные данные только компьютеры со старой версией обновлений Windows Server 2003, чтобы создать список компьютеров, требующих обновления.

Конвейерные функции

 

Теперь я намереваюсь переписать мою функцию, чтобы она оптимально использовала конвейер Windows PowerShell. А именно, мне требуется, чтобы функция принимала имена компьютеров непосредственно из конвейера — таким образом. при каждом использовании функции можно будет принимать решение о том, откуда требуется получать имена компьютеров. Имена компьютеров могут находиться в файле или в Active Directory, и мне требуется, чтобы фукнция работала надлежащим образом в обоих случаях. Итак, далее идет функция, переписанная для работы с конвейером.

Function Get-SPInventory {
  PROCESS {
    $wmi = Get-WmiObject Win32_OperatingSystem       –comp $_ | Select     CSName,BuildNumber,ServicePackMajorVersion
    Write-Output $wmi
  }
}

В этом специальном типе функции используется блок сценариев PROCESS, который будет выполняться для каждого объекта конвейера, передаваемого функции. (Отдельные читатели вспомнят, что блок сценариев PROCESS обсуждался мной в статье июльского выпуска 2008 г., доступной на веб-странице по адресу technet.microsoft.com/magazine/cc644947.aspx.) Специальная переменная $_ автоматически заполняется входными данными из конвейера — до тех пор, пока имена компьютеров передаются по конвейеру, функция прекрасно работает. Новая функция используется следующим образом.

Get-Content c:\computernames.txt | Get-SPInventory

Видно, что здесь предлагается более гибкий способ получения имен компьютеров из разных источников. Я всего лишь заменяю участок команды с Get-Content какой угодно командой, требуемой для получения имен компьютеров. Отмечу, что она настроена так, чтобы можно было создавать более надежные выходные данные посредством запроса разных классов WMI (или любых других источников данных) до формирования их вывода.

Но это еше не конец обсуждения. В следующем месяце я расширю функцию, чтобы в выходные данные включался серийный номер BIOS.