Алексей Максимов, Автор в Блог IT-KB - Страница 63 из 68

HP System Management Homepage - Установка FQDN Local Server Certificate

07.12.2010 Автор:Алексей Максимов
4 235 Просмотров Комментариев нет
При установке HP System Management Homepage (SMH) по умолчанию использует самоподписанный сертификат, что приводит к паническим предупреждениям веб-браузеров. Встроенный механизм управления локальным сертификатом HP System Management Homepage непосредственно через веб-интерфейс, несмотря на свой почтенный срок существования, до сих пор не умеет формировать запрос на создание цифрового сертификата с атрибутом commonName в формате FQDN. Если для сравнения взять, например веб-интерфейс управления iLO2, то там такая возможность появилась в одном из предпоследних релизов firmware, что само по себе подаёт надежду на то, что технари HP таки одумаются и добавят такую возможность и в функционал HP System Management Homepage… А пока такой возможности нет, мы попробуем использовать альтернативный метод установки сертификата SMH, имеющего в качестве commonName FQDN имя сервера, подписанного нашим локальным доверенным центром сертификации.

Проделаем несколько несложных действий:
- Сгенерируем запрос на сертификат средствами OpenSSL к ЦС Windows;
- Получим от ЦС файла сертификата (.cer) в формате X.509 Base-64;
- Заменим сертификат в встроенном веб-сервере HP System Management Homepage
Для того чтобы создать запрос к ЦС Windows нам понадобиться OpenSSL, а именно 3 файла из его состава – openssl.exe, ssleay32.dll, libeay32.dll. Сложим их в один каталог (например в каталог C:ToolsOpenSSL).

Для подготовки запроса к ЦС создадим конфигурационный файл для OpenSSL - текстовый файл myopenssl.cfg со следующим содержимым:

[ req ]
distinguished_name = req_distinguished_name

[ req_distinguished_name ]
commonName = FQDN of server
commonName_default = SERVER.mydom.com
countryName = Country Name (2 letter code)
countryName_default = RU
0.organizationName = Organization Name (eg, company)
0.organizationName_default = MyCompany
localityName = Locality Name (eg, city)
localityName_default = Syktyvkar
organizationalUnitName = Organizational Unit Name (eg, section)
organizationalUnitName_default = KOMI

Как вы понимаете, в этом файле мы указываем параметры, которые нужны для идентификации запроса сертификата в ЦС, т.е. указываем имя сервера, которому требуется сертификат, имя организации и т.п.
Для формирования запроса с закрытым ключом нам нужно получить собственно сам закрытый ключ используемый сервером в данный момент – файл file.pem (по умолчанию расположен в каталоге C:hpsslshare).
Далее создаем запрос на сертификат с учётом подготовленных ранее параметров и ключевого файла командой:

C:ToolsOpenSSL >openssl req -config myopenssl.cfg -new -key file.pem -out myreq.req

Полученный файл запроса myreq.req загружаем в центр сертификации Windows Server, где выдаем сертификат на загруженный запрос. Выгружаем из ЦС новый сертификат в файл с именем cert.pem в формате X.509 в кодировке Base-64.

Файл cert.pem копируем в каталог, где HP SMH хранит файл самоподписанного сертификата (по умолчанию каталог C:hpsslshare). При этом имеющийся там файл на всякий случай сохраняем и переименовываем в cert.back.

После этого на сервере с HP SMH перезапускаем службу HP System Management Homepage командами:

Net stop SysMgmtHp
Net start SysMgmtHp

В итоге открываем HP System Management Homepage в вэб-браузере (по умолчанию URL типа https://server.mydom.com:2381/) и убеждаемся в том, что HP SMH использует определенный нами сертификат и предупреждения безопасности браузера отсутствуют.
Ошибка обработки GPP: Group Policy object did not apply because its targeting item failed with error code 0x86012004

01.12.2010 Автор:Алексей Максимов
4 371 Просмотров Комментариев нет

Ранее уже описывалась проблема с обработкой Group Policy Preferences (GPP) в части применения нацеливания (Item-level targeting) на OU - Долгая обработка GPP на этапе “Applying Group Policy Drive Maps policy” на клиентах RODC Windows Server 2008 R2

В ходе дальнейшей эксплуатации GPP для изменения членства группы Администраторов на доменных компьютерах описанная проблема проявила себя по аналогичному сценарию (при нацеливании на доменные OU). Чтобы уйти от этого, приняли решение использовать нацеливание на группы безопасности, то есть изменять членство группы Администраторов в зависимости от членства учетной записи компьютера в той или иной доменной группе безопасности. Однако после настройки GPP и применения на клиентских компьютерах с Windows 7 и Windows Server 2008 R2 обнаружилось, что данная настройка GPP не отрабатывает. Сбор трейсов GPP выявил ошибку обработки типа:

Failed filter [FilterGroup]. [ hr = 0x86012004 "Клиентское расширение перехватило необрабатываемое исключение "filter expand" в: "Access violation (0xc0000005) occurred at 0xca12dad1; the memory at 0xca12dad1 could not be ????."%100790275" ]

Как выяснилось, эта проблема известна уже почти год и описана в статье KB976399 - FIX: You cannot apply Group Policy settings on a computer that is running Windows 7 or Windows Server 2008 R2 when security group filters are used in Group Policy preference settings.

К удивлению для себя выяснил, что данное обновление через WSUS не раскатывалось и для его применения MS предлагает воспользоваться отдельно загружаемым файлом исправления

Имеющийся на данный момент перечень исправлений включенных в готовящийся к выпуску SP1 для Windows 7 и Windows Server 2008 R2 - Documentation for Windows 7 and Windows Server 2008 R2 Service Pack 1 Release Candidate (KB976932) говорит нам о том, что этот фикс туда включен. Так что ждём релиза SP1, а пока можем выбрать для себя либо вариант с отдельной установкой фикса на проблемных клиентов, либо опять же нужно выбирать альтернативные методы нацеливания.
Exchange Server 2007 – Просмотр статистики БД почтовых ящиков

29.11.2010 Автор:Алексей Максимов
2 979 Просмотров Комментариев нет

Для получения статистики об использовании почтовых ящиков пользователями организации в Exchange Server 2007 можно воспользоваться Exchange Management Shell и командлетами Get-MailboxDatabase и Get-MailboxStatistics.

Для того чтобы получить сводную информацию о количестве почтовых ящиков в каждой базе данных и общему размеру каждой базы данных на определенном сервере в Exchange Management Shell выполним скрипт:

$MailBoxServer = "MyMailBoxServer"

Get-MailboxDatabase | Where-Object {$_.ServerName -eq $MailBoxServer} | Select @{Label="SG Name";Expression={$_.StorageGroupName}}, @{Label="DB Name";Expression={$_.Name}}, @{Label="Mailboxes";Expression={(Get-Mailbox -Database $_.Identity | Measure-Object).Count}} , @{Label="DB Size";Expression={"{0:N2}" -f ((get-mailboxstatistics -database $_.Identity | Measure-Object -Property TotalItemSize,TotalDeletedItemSize -Sum | Select-Object Sum | Measure-Object -Property Sum -Sum).Sum.ToString() /1024KB)}} | Sort -Property "DB Name" | Format-Table –AutoSize

Для того чтобы получить информацию об использовании пространства почтовых ящиков в определенной базе данных (в мегабайтах) выполним скрипт:

$FullDBIdentity = "MyMailBoxServerMyStorageGroupMyDataBase"

Get-MailboxDatabase -Identity $FullDBIdentity | Get-MailboxStatistics | Sort -Property TotalItemSize | Select DisplayName,@{label="TotalItemSize(MB)";expression={$_.TotalItemSize.Value.ToMB()}},ItemCount,StorageLimitStatus | Format-Table -AutoSize

Если же нас интересует информация только о почтовых ящиках, у которых превышен лимит хранения почты, выполним скрипт:

$FullDBIdentity = "MyMailBoxServerMyStorageGroupMyDataBase"

Get-MailboxDatabase -Identity $FullDBIdentity | Get-MailboxStatistics | Where-Object {$_.StorageLimitStatus -ne "BelowLimit"} | Sort -Property TotalItemSize | Select DisplayName,@{label="TotalItemSize(MB)";expression={$_.TotalItemSize.Value.ToMB()}},ItemCount,StorageLimitStatus | Format-Table –AutoSize

Дополнительные источники информации:

Exchange Server TechCenter - Get-MailboxDatabase: Exchange 2007
Neil Hobson - Getting Mailbox Statistics in Exchange 2007
Exchange Server Share Blog - Exchange 2007: Database Statistics in Powershell
PowerShellCommunity Forums - Exchange Mailbox Database size
System Center DPM 2010 QFE Rollup KB2250444 (3.0.7706.00)

28.11.2010 Автор:Алексей Максимов
2 680 Просмотров Комментариев нет

В первой половине Ноября появился пакет исправлений для DPM 2010 RTM – System Center DPM 2010 QFE Rollup (KB2250444) который изменяет версию DPM до 3.0.7706.00

Описание: Description of the hotfix rollup package for System Center Data Protection Manager 2010: November 10, 2010
URL для скачивания: System Center Data Protection Manager 2010 QFE Rollup

После установки требуется перезагрузка DPM сервера и обновление всех клиентов DPM. Сделать обновление клиентов DPM можно как с консоли DPM так и вручную (обе процедуры описаны в вышеперечисленных ссылках). После обновления клиентов DPM перезагрузка не потребуется.

Наконец то исправлена ошибка, с которой неоднократно приходилось сталкиваться - когда при создании Protection Group мы пытались изменить предлагаемые по умолчанию размеры партиций Replica volume и Recovery point volume – в некоторых случаях из этого ничего не выходило :)
SQL Server 2008 - Перенос файлов БД tempdb на отдельный диск

27.11.2010 Автор:Алексей Максимов
12 578 Просмотров 5 комментариев

При планировании развертывания приложений активно использующих системную временную базу данных SQL Server – tempdb, необходимо учитывать тот факт, что по умолчанию файлы этой БД расположены на системном диске. Соответственно для того чтобы избежать в будущем возможных проблем, связанных с переполнением системного диска из-за увеличения размера файлов tempdb, нам по возможности нужно выделить для файлов этой БД отдельное логическое дисковое пространство.

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

Следует учитывать, что для достижения максимальной производительности в работе tempdb может потребоваться разнесение файла данных и лога транзакций БД tempdb. Также следует отметить то, что для поднятия производительности хорошо нагруженных систем в документе MSDN Library - Optimizing tempdb Performance присутствует рекомендация создавать отдельные группы файлов tempdb на разных дисках для каждого ядра серверного процессора.

По умолчанию БД tempdb настроена на авто-расширение (Autogrow) и при каждой перезагрузке SQL Server пересоздаёт файлы этой БД с минимальным размером инициализации (Initial Size). Опираясь на рекомендации вышеуказанного документа, мы увеличим размер инициализации файлов tempdb таким образом, чтобы свести к минимуму затраты системных ресурсов на операции авто-расширения.

Для того чтобы определить где в текущий момент физически располагаются файлы БД tempdb, откроем SQL Server Management Studio и выполним SQL запрос:

SELECT name, physical_name AS CurrentLocation

FROM sys.master_files

WHERE database_id = DB_ID(N'tempdb');

GO

Получим примерно такой результат:

Затем, определившись с тем, на каких логических дисках будут расположены файлы БД, и какой они будут иметь размер, выполним SQL запрос:

USE master;

GO

ALTER DATABASE tempdb

MODIFY FILE (NAME = tempdev, FILENAME = 'H:TempDB_Datatempdb.mdf' , SIZE = 10240);

GO

ALTER DATABASE tempdb

MODIFY FILE (NAME = templog, FILENAME = 'I:TempDB_Logtemplog.ldf' , SIZE = 3072);

GO

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

После успешного выполнения запроса - перезапустим службу SQL Server и убедимся что наши файлы расположены там где мы хотим, выполнив SQL запрос:

SELECT name, physical_name AS CurrentLocation, size, state_desc

FROM sys.master_files

WHERE database_id = DB_ID(N'tempdb');

Если всё нормально, результат должен быть примерно таким:

После этого необходимо удалить файлы tempdb.mdf и templog.ldf с их старого месторасположения.

Дополнительные источники информации:

MSDN Library- Moving System Databases

MSDN Library - How to: Move a Database Using Detach and Attach (Transact-SQL)

KB224071 - How to move SQL Server databases to a new location by using Detach and Attach functions in SQL Server
SCOM 2007 R2 – Пакетный перевод агентов в Maintenance Mode

24.11.2010 Автор:Алексей Максимов
2 225 Просмотров Комментариев нет

В окружении с большим количеством агентов мониторинга SCOM 2007 R2 массовый перевод этих агентов в режим обслуживания (Maintenance Mode) через UI консоль может стать весьма хлопотным занятием. На помощь в таком случае как всегда приходит Operations Manager Shell.

Например, для того чтобы перевести в Maintenance Mode все сервера в имени которых встречается “SQL”, с текущего момента сроком на 2 часа в Operations Manager Shell можно выполнить следующий нехитрый скрипт:

$Time1 = [DateTime]::Now

$Time2 = $Time1.AddMinutes(120)

$Agents = Get-Agent | Where {$_.Name –match "SQL"}

$Agents | foreach {New-MaintenanceWindow -StartTime $Time1 -EndTime $Time2 -Reason "PlannedOther" -Comment "Maintenance Mode Window" -MonitoringObject $_.HostComputer}

Здесь вместо функции AddMinutes() можно также использовать AddHours() и AddDays()

Или другой пример, когда необходимо указать конкретный диапазон дат:

[DateTime] $Time1 = "11/23/2010"

$Time1 = $Time1.ToUniversalTime()

[DateTime] $Time2 = "11/28/2010"

$Time2 = $Time2.ToUniversalTime()

$Agents = Get-Agent | Where {$_.Name –match "SQL"}

$Agents | foreach {New-MaintenanceWindow -StartTime $Time1 -EndTime $Time2 -Reason "PlannedHardwareMaintenance" -Comment "Hardware Maintenance" -MonitoringObject $_.HostComputer}

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

%SYSTEMROOT%system32WindowsPowerShellv1.0powershell.exe C:MaintenanceModeStartMaintenanceModeWindow.ps1

Так же для того чтобы скрипт успешно отработал при таком вызове из планировщика задач, в начало скрипта следует добавить строки инициализации командлетов Operations Manager Shell и вызов подключения к корневому серверу управления SCOM (RMS):

$RMSServer = 'RMSServerName'

Add-PSSnapin "Microsoft.EnterpriseManagement.OperationsManager.Client";

Set-Location "OperationsManagerMonitoring::";

New-ManagementGroupConnection -ConnectionString:$RMSServer;

Set-Location $RMSServer;

Дополнительные источники информации:

System Center TechCenter - How to Put a Monitored Object into Maintenance Mode in Operations Manager 2007

System Center TechCenter- Operations Manager 2007 R2 Cmdlets - New-MaintenanceWindow

Collection of Maintenance Mode Scripts, Utilities and MPs for Opsmgr and Essentials 2007 (Updated for SCOM 2007 R2)

System Center Operations Manager Forums > Extensibility > Setting all entities to maintenance based on a particular class
SCOM 2007 R2 – Изменение статуса ManuallyInstalled для агентов

21.11.2010 Автор:Алексей Максимов
2 185 Просмотров Комментариев нет

В некоторых случаях может возникнуть ситуация, когда по каким-то причинам произведена ручная установка агентов SCOM на ряд компьютеров. Для таких агентов в UI консоли недоступны опции смены основного сервера управления (Change Primary Management Server), восстановления (Repair) и удаления (Uninstall). Помимо этого после применения новых кумулятивных обновлений (CU) такие агенты не будут переходить в режим принудительного обновления, что опять же потребует их обновления «в рукопашную». Получить список таких агентов можно как в UI консоли, так и в Operations Manager Shell:

Get-Agent | where {$_.ManuallyInstalled -match ‘true’} | ft name,ManuallyInstalled

Для повышения централизованной управляемости нам потребуется изменить статус ручной установки для таких агентов. Через UI консоль это сделать невозможно by design. Через Operations Manager Shell у нас в данном случае также не получится изменить данное свойство, так как оно установлено как ReadOnly. Для решения данной задачи можно воспользоваться советом из блога Кевина Холмана: Kevin Holman's OpsMgr Blog - How to get your agents back to "Remotely Manageable" in OpsMgr 2007 R2

Для того чтобы вывести список агентов установленных вручную, подключимся к базе данных «OperationsManager» и выполним запрос:

SELECT bme.DisplayName FROM MT_HealthService mths

INNER JOIN BaseManagedEntity bme ON bme.BaseManagedEntityId = mths.BaseManagedEntityId

WHERE IsManuallyInstalled = 1

Для того чтобы изменить статус всех вручную установленных агентов, выполним запрос:

UPDATE MT_HealthService

SET IsManuallyInstalled=0

WHERE IsManuallyInstalled=1

Если же мы не хотим менять статус для всех агентов, а лишь для одного какого то конкретного агента, выполним запрос:

UPDATE MT_HealthService

SET IsManuallyInstalled=0

WHERE IsManuallyInstalled=1

AND BaseManagedEntityId IN

(SELECT BaseManagedEntityID FROM BaseManagedEntity

WHERE BaseManagedTypeId = 'AB4C891F-3359-3FB6-0704-075FBFE36710'

AND DisplayName = 'agentname.domain.com')

После этого, в UI консоли, для измененных агентов станут доступными вышеописанные опции управления.

Следует так же понимать, что если агенты устанавливались вручную из-за их ограничений с точки зрения сетевого доступа, то такие манипуляции, с точки зрения управляемости, нам всё равно не принесут никакой пользы.
SCOM 2007 R2 – Включение Agent Proxy на группе агентов

21.11.2010 Автор:Алексей Максимов
2 642 Просмотров Комментариев нет

По мере начала использования новых пакетов управления (MP) в SCOM, может возникнуть необходимость включения механизма «Agent Proxy» на группе агентов, например, когда мы используем MP для мониторинга AD, нам необходимо включить проксирование для всех агентов, имеющих роль контроллеров домена.

При большом количестве агентов, сделать это в UI консоли - не самый лучший вариант, так как у нас есть Operations Manager Shell.

Например, для того чтобы получить информацию о том в каком состоянии находится значение атрибута «ProxyingEnabled» на агентах, содержащих в имени «dc» в консоли Operations Manager Shell выполним:

Get-Agent | where {$_.computerName -match 'dc'} | ft name,proxyingEnabled

Для того чтобы для всего выведенного списка включить проксирование выполним PS скрипт:

$Agents = Get-Agent | where {$_.computerName -match 'dc'}

$Agents | foreach {$_.ProxyingEnabled = $true}

$Agents | foreach {$_.ApplyChanges()}
Настройка ILO 2 Single Sign-On (SSO) для HP Systems Insight Manager

13.11.2010 Автор:Алексей Максимов
8 456 Просмотров 3 комментария
Для того чтобы быстро попасть на интерфейс ILO 2 любого управляемого сервера с HP SIM можно на странице «All Systems» открыть свойства этого сервера и выбрать ссылку «Integrated Lights-Out 2 (ILO 2)» на закладке «System».

При этом мы можем обратить внимание на то, что ILO2 попросит ввести нас учетные данные.

Для повышения эффективности работы с HP SIM можно настроить интерфейсы Integrated Lights-Out 2 управляемых серверов таким образом, чтобы при переходе с узла HP SIM на ILO2 не нужно было бы вводить учетные данные. Механизм Single Sign-On (SSO) в данном случае основан на использовании доверия между узлом HP SIM и ILO2 на основе цифровых сертификатов.

Для того чтобы настроить данный механизм нам потребуется на интерфейсе ILO2 включить цифровой сертификат сервера HP SIM в список доверенных систем управления. Для этого нам нужно получить цифровой сертификат HP SIM в формате X.509.

Есть несколько вариантов получения сертификата HP SIM:
- Сертификат можно получить, открыв специальный URL c веб-узла HP SIM в формате
  http://<hpsim network address>:280/GetCertificate
  то есть в нашем случае это будет http://KOM-AD01-HPSIM:280/GetCertificate
- Экспортировать сертификат с веб-консоли HP SIM через меню “Options” > “Security” > “HP Systems Insight Manager Server Certificate”. Чтобы получить содержимое X.509 - экспортированный файл servcert.cer нужно открыть в любом текстовом редакторе
- Использовать command-line утилиту mxcert на сервере HP SIM. Для выполнения экспорта нужно будет в командной строке с административными привилегиями выполнить команду
  mxcert -l tomcat
Далее в веб-интерфейсе администрирования ILO2 открываем:
закладка "Administration" > "Security" > закладка "HP SIM SSO".

Параметр "Single Sign-On Trust Mode" устанавливаем в значение "Trust by Certificate" и сохраняем изменения кнопкой “Apply”.

Настраиваем необходимые уровни привилегий на ILO относительно ролей User, Operator и Administrator используемых в HP SIM.

Нажимаем кнопку "Add HP SIM Server"

Затем в разделе “Directly import a HP SIM Server Certificate” данные сертификата HP SIM копируем в поле «HP SIM Server X.509 Certificate Data» и нажимаем кнопку «Import Certificate»

Если проверка сертификата в ILO прошла успешно, то в писке «HP SIM Trusted Servers» появится запись об импортированном сертификате HP SIM

После этого механизм Single Sign-On при открытии ссылки на веб-интерфейс ILO 2 c веб-консоли HP SIM должен начать работать.
Настройка HP Version Control

11.11.2010 Автор:Алексей Максимов
17 212 Просмотров 16 комментариев
Программный пакет HP Version Control представляет собой клиент-серверную систему для обновления драйверов и firmware на серверах HP. Он устанавливается по умолчанию вместе с HP SIM и состоит из двух компонент:
- Version Control Repository Manager (VCRM) - веб-приложение обеспечивающее доступ к центральному обновляемому хранилищу драйверов и firmware
- Version Control Agent (VCA) – клиентская компонента, взаимодействующая с VCRM из состава HP Support Pack позволяющая отслеживать соответствие установленных версий драйверов и firmware на управляемых серверах
Настраиваем HP Version Control Repository Manager

Компонент HP Version Control Repository Manager (VCRM) устанавливается по умолчанию вместе с HP SIM и служит для построения репозитория обновлений программного обеспечения HP (драйверов и firmware). Для поддержания репозитория в актуальном состоянии можно настроить его автоматическое обновление с веб-узлов HP по расписанию. После получения свежих обновлений в VCRM сервер HP SIM автоматически опросит все обслуживаемые системы на предмет применимости этих обновлений. Если обновления применимы и более того строго рекомендуемы для каких либо систем (например когда в ПО исправляются какие то проблемы безопасности или совместимости), - HP SIM автоматически изменит статус таких систем на критический.

Служба «HP Version Control Repository Manager» (cpqsrhmo) после установки VCRM по умолчанию запускается от имени Local System. Нам необходимо изменить настройки службы так, чтобы она запускалась и работала от имени доменного пользователя имеющего доступ в Интернет. В нашем примере я использовал туже учетную запись, от имени которой работает служба HP SIM. Сделать это необходимо для того чтобы в дальнейшем не было проблем с автоматическим обновлением репозитория с сайта hp.com. Несмотря на то, что в настройках VCRM есть возможность указать имя пользователя и пароль для прохода через прокси, на практике выяснилось, что в процессе обновления VCRM пытается пробиться в интернет либо от учетной записи anonymous либо от учетной записи, от имени которой работает сама служба «HP Version Control Repository Manager» (cpqsrhmo), что собственно говоря и приводит к неудачному завершению процедуры обновления.

После изменения параметров службы перезапускаем её командами:

Net stop cpqsrhmo
Net start cpqsrhmo

Теперь можно приступить к первоначальной настройке VCRM. Для этого на веб-консоли HP SIM в вьюшке All Systems выберем свойства сервера HP SIM с установленным VCRM, и на закладке «Tools & Links» откроем ссылку «HP Version Control Repository Manager»

Откроется веб-страница управления VCRM. В ней на закладке «home» выберем пункт «change repository & update settings» для того чтобы вызвать пошаговый мастер настройки основных параметров VCRM

Первым делом изменим каталог для хранения файлов репозитория, указав диск на котором достаточно места для хранения большого объёма файлов. В этот каталог будут распаковываться все пакеты драйверов и firmware для обслуживаемых серверных систем.

На следующем шаге отметим те ОС, которые есть на наших обслуживаемых серверных системах, для которых мы планируем загрузку всех обновлений драйверов и firmware.

Далее на шаге “Automatic Update Settings” включаем опцию «Enable Automatic Update» , задаем расписание обновления репозитория из Интернета и укажем имя прокси-сервера. Указывать учетные данные пользователя, как я писал ранее, не нужно, так как это всё равно нам не поможет J.

Далее после нажатия кнопки “Finish” VCRM попытается обратиться в Интернет для проверки соединения с веб-узлом HP и если ему это удастся, сохранит все настройки.

Указанные настройки в любой момент можно будет изменить позже, в том числе и с помощью CLI утилиты vcrmcli.exe. Эта утилита по умолчанию расположена в каталоге C:hphpsmhdatacgi-binvcrepository. Вывод сведений о текущей конфигурации можно выполнить с помощью команды

vcrmcli.exe /show

Более подробно об использовании утилиты vcrmcli.exe можно найти в руководстве «HP Version Control 6.2 Repository Manager User Guide».

После того как настройки сохранены, переходим на закладку «catalog» и вызываем пункт «update from hp.com now» для инициализации процедуры первоначального наполнения репозитория.

Первоначальное заполнение каталога обновлений может занять существенное время в зависимости от выбранных типов ОС и пропускной способности вашего Интернет соединения. Отследить статус обновления репозитория можно на закладке «log». После окончания процесса на закладке «home» должны появиться сводные данные о загруженных пакетах драйверов. На своей инсталляции заметил неприятный момент – несмотря на то, что для загрузки была отмечена ОС Windows Server 2008 R2, support pack был загружен для Windows 7 x64. Плюс в процессе загрузки некоторые файлы не были успешно загружены, и в логе было зафиксирована рекомендация загрузить эти файлы в репозиторий вручную L. Характерно также то, что для указанных ОС было загружено три последних версии Support Pack и поэтому объём скачанного из интернета траффика получился достаточно большим.

Как бы там ни было, у VCRM есть возможность загрузки отдельно скачанных пакетов драйверов и firmware (“home” > “upload a support pack”). Так мы и поступим, - загрузим последние паки «ProLiant Support Pack for Microsoft Windows Server 2008 R2» и «ProLiant Support Pack for Microsoft Windows Server 2008» (на дату создания заметки последняя версия - 8.60 и предыдущая - 8.50), распакуем их в отдельные каталоги и выполним upload из этих каталогов

После окончания загрузки и отсутствия видимых признаков жизнедеятельности, чтобы растормошить VCRM, можно перезапустить его службу, что вызовет форсированную проверку репозитория. Информация на странице «home» должна обновиться и в логе должны появиться события окончания процесса перестройки и проверки

После этого на закладке «catalog» в меню «delete items» отметим и удалим пакеты драйверов старых версий (если мы точно уверены в том, что они нам не понадобятся в дальнейшем). В своём случае я оставил две последние версии - 8.50 и 8.60.

После удаления будет сформирован и показан отчет об удаленных файлах. Если какие-то из файлов пака входят так же в состав актуальных паков – такие файлы не будут удалены и будет выведено по ним соответствующее предупреждение.

Наряду с пакетами драйверов “Support Pack” VCRM поддерживает загрузку firmware из пакета «Smart Update Firmware DVD», так же доступного для скачивания с сайта hp.com, что может расширить набор обновляемых из репозитория аппаратных компонент.

Настраиваем Version Control Agent (VCA)

Настало время настроить Version Control Agent (VCA) на управляемых серверных системах для взаимодействия с VCRM. Сделать это можно как на самих управляемых серверах через локальный модуль HP System Management Homepage, так и непосредственно с веб-консоли управления HP SIM (более удобный способ). Перед тем как настраивать управляемые сервера, на самом сервере VCRM нужно создать специальную локальную учетную запись пользователя от имени которого агенты VCA будут удалённо подключаться к VCRM. В нашем случае эта учетная запись будет называться s-HP-VCRM-AccessUser. Включим эту учетную запись в локальную группу Администраторов на сервере VCRM.

Приступим к настройке VCA на управляемых серверах. Текущий сводный статус VCA на всех управляемых серверах можно увидеть в веб-консоли HP SIM в All Systems в столбце «SW».

Первоначально статус будет отражать то, что между агентами VCA и VCRM не установлены доверительные отношения, то есть агенты VCM не нацелены на наш репозиторий VCRM. Для настройки откроем свойства любого ненастроенного управляемого сервера (по ссылке в столбце System Name), перейдём на закладку «Tools & Links» и кликнем по ссылке «HP Version Control Agent»

Откроется страница доступа к HP System Management Homepage управляемого сервера.
Обратите внимание на то, что первоначально внизу страницы входа нам будет предложено установить доверительные отношения между управляемым сервером и сервером HP SIM на основе цифрового сертификата для того, чтобы в дальнейшем не вводить учетные данные и прозрачно входить на страницу HP System Management Homepage. Рекомендую включить эту опцию.

В открывшемся окне настройки VCA на закладке «home» выберем пункт меню «change settings» и зададим имя нашего сервера VCRM, а также укажем созданную ранее учетную запись доступа к репозиторию обновлений.

После нажатия кнопки «Next» нам будет предложено выбрать предпочитаемый пакет драйверов (Reference Support Pack). В большинстве случаем можно его не выбирать, так как VCA автоматически способен определить необходимый для данной системы набор драйверов и firmware. После сохранения настроек, VCA сразу попытается выполнить запрос в репозиторий VCRM и отобразит все компоненты необходимые для нашей управляемой системы.

После этого можно произвести пакетную установку всех необходимых обновлений непосредственно через этот веб-интерфейс. При этом необходимо понимать, что если мы обновляем, например драйвер сетевого адаптера или firmware ILO, возможна кратковременная потеря соединения с веб-страницей VCA. В таком случае её просто нужно перезапустить. Окончание процесса установки можно будет определить по появлению в логе записи типа «Completed installation with summary result …»

В текущей версии VCA код возврата «1» означает успешную установку без необходимости перезагрузки, а код возврата «2» означает успешную установку с необходимостью перезагрузки ОС. Все другие коды возврата будут свидетельствовать о каких либо проблемах, возникших на этапе установки.

В дальнейшем сводный статус взаимодействия VCRM и VCM на серверном оборудовании можно будет наблюдать, например, на странице All Systems веб-консоли HP Systems Insight Manager

Факт появления в репозитории обновлений драйверов и firmware для управляемых серверных систем будет фиксироваться в журнале событий HP SIM (с параллельной генерацией SNMP трапов с статусом Critical), который в свою очередь может оповестить об этом администратора и другие системы мониторинга, такие как MS SCOM.

Полную документацию об установке и настройке HP Version Control на английском языке можно найти на странице HP Version Control Installation Guide