We rise up for the things we believe in over and over again

Перепись всего серверного хозяйства. Эта процедура не давала мне покоя все то время, что я работаю. До текущего момента это был стандартный Excel-файл с кучкой листов. И конечно же, обновлялся он из рук вон плохо. В конце концов, это порядком поднадоело.
Составные части автоматической инвентаризации:
- MS Access в качестве базы данных. База будет довольно мелкой, а потому поднимать что-то большое для этих целей кажется пошлым.
- Powershell как исполняемый процесс.
- WMI как средство сбора данных.
- Группа серверов в AD.
Требования к системе:
1. Наличие провайдеров доступа к базе MS Access 2007. Проще всего выполняется путем установки самого MS Access 2007 на 32-разрядную машину. На 64-разрядной системе получим ошибку "Провайдер незарегистрирован, пожалуйста, переустановите его".
2. Наличие Powershell v.2 и набора Quest AD Management. Если используется Windows 2008 Server R2 - можно обойтись и без него, но в скрипте придется изменить одну строку.
Особо. В работе сценария сбора информации используются функции для работы с базой MS Access 2007, написанные Richard Siddaway - ссылка на его блог - Клац!.
О самом сценарии. Практически целиком он основан на командлете Get-WMIObject. Указав нужный класс и обратившись к определенному объекту внутри этого класса мы можем получить практически всю интересующую нас информацию о системе. В качестве примера можно привести вот такую часть самого скрипта:
get-wmiobject Win32_computerSystem -computername $srv.name | %{
$sysName=$_.Name
$sysManufacturer=$_.manufacturer
$sysModel=$_.model
}
Если попытаться перевести это на русский язык, получим следующее: извлечь данные из класса win32_computersystem (тут хранятся общие параметры компьютера), обратившись к компьютеру с именем, хранящемся в переменной $srv.name, в переменной $sysName сохранить его имя, в $sysManufacturer - фирму-производителя, в $sysModel - модель компьютера.
В дальнейшем эти параметры в числе других будут записаны в специально подготовленную для этого базу данных.
Похожим образом извлекаются и остальные параметры системы, коих довольно много.
Следующее. Поскольку сценарий достаточно велик, я не стал выкладывать его в открытом виде здесь, как поступаю обычно. Вместо этого все необходимые для инвентаризации файлы выложены на Google Docs - ссылка ниже:
Архив на Google Docs
Описание загружаемого файла: zip-архив GetServerInfo.zip, размер 50 910 байт.
Содержимое архива: скрипт db-functions.ps1 (библиотека функций для работы с MS Access 2007), скрипт GetInfo.ps1 (собственно, сам сценарий инвентаризации), база данных ServerDB.accdb - болванка базы данных. Именно в нее будут складываться полученные сведения.
Как использовать?
1. Распаковать содержимое архива в какой-нибудь каталог.
2. В файле GetInfo.ps1 исправить путь к файлу библиотеки (строка 5), и путь к базе данных (строка 8, изменить параметр -path)
3. Все Windows-серверы собрать в какую-нибудь группу в AD и прописать имя этой группы в строке 11, именно для нее нужен пакет Quest AD Management. При использовании родных средств управления Windows 2008 Server R2 нужно заменить командлет Get-QADComputer на Get-ADComputer с соответствующим изменением синтаксиса, а также закомментировать вызов оснастки Quest AD (строка 2).
На этом подготовка закончена.
Возможные проблемы. Да, куда же без них? Заключаются они в весьма странных наборах данных, которые отдаются скрипту через WMI. Например, на почти всех виртуальных серверах, крутящихся под esxi 3.5 (ОС самой виртуальной машины значения не имеет) вся оперативная память виртуальной машины размазывается по 4 банкам памяти, что приводит к следующим результатам:
банк 0 - 512 Мб
банк 1 - 256 Мб
банк 2 - 128 Мб
банк 3 - 112(!) Мб.
Почему так - я пока не разобрался. На железных машинах подобной проблемы не замечено.
Другая неясность - не все машины передают названия своих сетевых соединений, но это скорее проблемы конкретных машин.
Проблема базы данных. Абсолютно все поля базы имеют текстовый тип, что с точки зрения рационализации - не очень хорошо. Оставлять так или нет - решать вам. На просторах сети встречалось упоминание, что при работе через Powershell в MS Access можно записать данные только этого типа. Так это или нет, пока не проверял, но решил перестраховаться.
На этом все. Любые вопросы, дополнения, уточнения - приветствуются. Надеюсь, кому-то эта информация сможет сэкономить довольно много времени и сил.
P.S. Предвосхищая вопрос - а почему не использовать такие средства, как SCCM, MOM и другие? Ответ прост - бюджет компании. Он везде разный.