| Новые программы oszone.net |  |
Диспетчер System Center Operations Manager 2007 (OpsMgr) дал администраторам доступ к Windows PowerShell, новому языку сценариев, позволяющему автоматизировать многие задачи. Официальный выпуск диспетчера состоялся в ноябре 2006 года, и с тех пор его загрузили более двух миллионов раз. В этой статье мы обсудим оболочку Windows PowerShell® и ее связь с диспетчером Operations Manager. Мы поговорим о том, какие задачи Windows PowerShell позволяет автоматизировать (и тем самым упростить их выполнение), а также укажем несколько веб-узлов, на которых можно найти готовые сценарии и пояснения. Мы собрали воедино советы и сообщения в блогах многих специалистов, работающих с Windows PowerShell. Корпорация Майкрософт приступила к выпуску версий CTP Windows PowerShell 2.0, однако они еще не готовы к использованию в реальной производственной среде, они не тестировались на совместимость с OpsMgr. Интерпретатор команд Operations ManagerДоступ к Windows PowerShell из OpsMgr осуществляется через интерпретатор команд, схожий со стандартной средой Windows PowerShell, за исключением того что он загружает файл консоли и сценарий, который выполняет инициализацию среды, вместе с командлетами, функциями и подключением по умолчанию OpsMgr. Запустить интерпретатор команд можно при помощи значка в папке OpsMgr в меню «Пуск» или щелкнув правой кнопкой мыши имя компьютера в пользовательском интерфейсе консоли OpsMgr (см. рис. 1). После запуска сразу открывается каталог по пути наблюдения OpsMgr (его мы рассмотрим ниже).
Рис. 1 Запуск интерпретатора команд из пользовательского интерфейса OpsMgr Windows PowerShell стыкуется с диспетчером Ops Mgr через пакет SDK для OpsMgr. К радости администраторов, для большинства основных операций, которые удобно автоматизировать и выполнять из командной строки, уже имеются готовые командлеты. Если для какой-то задачи командлет не создан, можно использовать Windows Power Shell совместно с пакетом SDK. Команды, с которыми можно работать в командной оболочке Operations Manager, содержатся в отдельной оснастке — в библиотеке DLL, которая загружается оболочкой Windows PowerShell и включает в себя командлеты для администрирования через OpsMgr. В эту же оснастку входит поставщик Windows PowerShell OperationsManager Monitoring. Это средство — его еще называют поставщиком наблюдения — позволяет просматривать подключения, группы и объекты наблюдения примерно так же, как составляющие файловой системы. Список всех командлетов OpsMgr можно получить при помощи командлета Get-OperationsManager Command (см. рис. 2). (В первой версии это была функция, не поддерживавшая автозавершение при помощи клавиши табуляции; в пакете обновления 1 (SP1) вместо нее был реализован командлет.) В исходную версию диспетчера Operations Manager входили 74 командлета; в OpsMgr с пакетом обновления 1 (SP1) их 87.
Рис. 2 Получение списка командлетов OpsMgr Поставщик наблюдения OpsMgrПри помощи командлета Set-Location или его псевдонима cd можно переходить по группам и компьютерам. Базовая схема для диска Monitoring по умолчанию выглядит примерно так: Monitoring:\->RMS->Groups (as defined in OpsMgr) ->Computers(as defined in OpsMgr) Отсюда уже можно переходить к конкретным объектам. Здесь мы работаем с простейшей средой, в которой есть лишь один сервер управления. Первый сервер управления в группе управления называется корневым. При запуске интерпретатор команд создает диск с именем Monitoring, сопоставляет его корневому каталогу поставщика OperationsManager Monitoring и устанавливает текущее положение или путь к корневому каталогу диска Monitoring (путь к нему). Затем интерпретатор команд пытается найти в реестре имя корневого сервера управления, используемого по умолчанию. Если удается установить подключение к нему, то текущему положению (пути) назначается имя этого подключения (корневого сервера управления), как показано на рис. 3.
Рис. 3 В качестве местоположения интерпретатора команд устанавливается имя корневого сервера управления Автоматизация основных задачРассмотрим, как Windows PowerShell помогает выполнять основные задачи администрирования. Режим контрольного обслуживания Вне зависимости от того, какую задачу вы выполняете, вы обычно указываете дату и время проведения операций. Командлет Get-Date значительно упрощает это действие. На рис. 4 показано несколько примеров.
Рис. 4 Использование командлета Get-Date Можно видеть, что мы создали переменную $date, в которой содержится объект, представляющий текущее время. Затем мы использовали ряд документированных методов, поддерживаемых этим объектом, для демонстрации того, как просто можно получить дату и время, отступающее от текущего на пять минут или на пять часов. Чтобы получить значения, относящиеся к прошлому, нужно использовать не (5), а (-5). Если требуется блокировать все предупреждения, приходящие с компьютера, можно включить режим обслуживания. Диспетчер OpsMgr 2007 позволяет перевести в режим обслуживания отдельную службу Windows®, даже отдельную базу данных, а не только весь компьютер или целую группу. Существует три командлета, непосредственно связанных с режимом обслуживания: Get-MaintenanceWindow, New-MaintenanceWindow и Set-MaintenanceWindow. Чтобы перевести компьютер в режим обслуживания из интерпретатора команд, найдите нужный компьютер или объект наблюдения через поставщик наблюдения и вызовите командлет New-MaintenanceWindow, как показано на рис. 5. В нашем примере компьютер Denver.contoso.com переводится в режим обслуживания. Мы определили окно обслуживания таким образом, чтобы работы начинались в текущий момент времени, а заканчивались через час. Обратите внимание на то, что при таком переводе компьютера в режим обслуживания предупреждения не блокируются, поскольку экземпляры HealthService и HealthService Watcher для данного объекта по-прежнему работают.
Рис. 5 Использование командлета New-MaintenanceWindow Борис Янушпольский, руководитель программы в группе разработчиков Microsoft Ops Mgr, предоставил несколько весьма полезных фрагментов кода на языке Windows PowerShell, которые можно использовать для перевода всех объектов, соответствующих компьютерам, в режим обслуживания. Кроме того, он объясняет, как их использовать после создания сценария. Дополнительную информацию можно найти в его блоге по адресу blogs.msdn.com/boris_yanushpolsky/archive/2007/07/25/putting-a-computer-into-maintenance-mode.aspx. Бывают ситуации, когда нужно определить, нет переведены ли в режим обслуживания лишние объекты. Перебор же всех объектов может оказаться задачей трудоемкой. К счастью, и тут Борис Янушпольский приходит на помощь: он разработал сценарий Windows PowerShell, задействующий пакет SDK для OpsMgr. Можно загрузить код непосредственно из его блога (blogs.msdn.com/boris_yanushpolsky/archive/2007/08/06/so-what-is-in-maintenance-mode.aspx) и вставить его в окно интерпретатора команд. На выходе вы получите список всех объектов, переведенных в режим обслуживания. Иногда требуется завершить режим обслуживания объекта до наструпления ранее указанного срока окончания обслуживания. Человек, знакомый с Windows PowerShell, будет искать какой-нибудь командлет с глаголом stop или remove в названии, но на самом деле используется командлет Set-MaintenanceWindow (см. рис. 6).
Рис. 6 Использование командлета Set-MaintenanceWindow для изменения времени окончания обслуживания Управление агентами Администраторам нередко приходится иметь дело с агентами. В текущей версии диспетчера есть одна функция и шесть командлетов, помогающих выполнять задачи, связанные с агентами. Их список можно получить при помощи следующей команды: Get-Command *-agent* В пакете обновления 1 (SP1) Install-AgentBy Name представляет собой не функцию, а командлет. Рекомендуется использовать командлет Install-AgentByName, поскольку в таком случае улучшается поддержка и повышается согласованность операций. Во встроенной справке интерпретатора команд есть несколько неплохих примеров использования командлетов Install-Agent и Uninstall-Agent. Роджер Спрэг (Roger Sprague), старший инженер-разработчик в группе Microsoft Ops Mgr, в своем блоге рассказал об альтернативном методе: он приведен на рис. 7 (исходное сообщение расположено на странице blogs.msdn.com/scshell/archive/2006/09/28/getting-started.aspx). Этот сценарий отлично работает в версии RTM диспетчера OpsMgr (запускать его нужно из корневого каталога поставщика наблюдения, в наших примерах это каталог monitoring:\oxford.contoso.com), а вот в OpsMgr с пакетом обновлени $managementServer = Get-RootManagementServer Рис. 7. Установка агента # Get the Root Management Server. $managementServer = Get-ManagementServer -Root: $true # Create the discovery configuration for computer2 and computer3. $discoConfig = New-WindowsDiscoveryConfiguration -ComputerName: computer2, computer3 # Discover the computers. $discoResult = Start-Discovery -ManagementServer: $managementServer -WindowsDiscoveryConfiguration: $discoConfig # Install an agent on each computer. Install-Agent -ManagementServer: $managementServer -AgentManagedComputer: $discoResult.CustomMonitoringObjects Итак, агент установлен в удаленной системе, за которой мы будем наблюдать. Осталось одно: сервер управления должен принять новый агент, прежде чем за ним можно будет наблюдать. Если никаких действий не предпринимать, сервер управления автоматически примет новый агент. Однако процесс принятия можно отслеживать при помощи командлета Get-AgentPendingAction. Вот однострочник, который позволит проверить ход принятия агента: Get-AgentPendingAction | Where Object {$_.AgentName –like
'computer*'} | Approve-AgentPendingAction
Если его выходные данные направить в командлет Reject-AgentPending Action, а не в командлет Approve-AgentPending Action, можно блокировать принятие данного агента сервером OpsMgr. Так можно поступить, если агент еще не принят. В противном случае нужно использовать командлет Uninstall-Agent. Как уже упоминалось выше, при помощи командлета Install- AgentByName можно напрямую из командной строки указать, на каком компьютере должен быть установлен агент. Работа с пакетами управления существуют четыре командлета, помогающие выполнять различные задачи при работе с пакетами управления. Их список можно получить следующим образом: Get-Command –noun ManagementPack При помощи вот такой несложной команды составляется список установленных пакетов управления с указанием версий: Get-ManagementPack | Format-Table –autosize Рассмотрим процедуру установки двух распространенных пакетов управления через интерпретатор команд. Использовать будем два установщика:
Поскольку цель наша в том, чтобы показать, как интерпретатор команд способен упростить выполнение рутинных задач, мы будем использовать такую процедуру установки, в которой меньше всего команд (см. рис. 8). Можно было бы изменить процедуру установки, передав установщику (файлу MSI) параметр quiet, но мы предпочли указать место распаковки файлов вручную.
Рис. 8 Установка пакетов управления Теперь необходимо установить общие библиотеки. Сделать это можно следующим образом: Get-ChildItem –Path C:\MPs –filter *Library.mp |
ForEach-Object
{Install-ManagementPack –filePath $_.FullName}
Теперь установим остальные необходимые пакеты управления: Get-ChildItem –Path C:\MPs –filter *200?.mp |
ForEach-Object
{Install-ManagementPack –filePath $_.FullName}
Как видно из рис. 9, во встроенной справке интерпретатора команд имеется прекрасный пример использования командлета Export-ManagementPack для экспорта незапечатанных пакетов управления. Если нужно экспортировать все пакеты, измените следующую строку: $mps=Get-ManagementPack | Where-Object {$_.Sealed –eq $false}
$mps=Get-ManagementPack
Рис. 9 Экспорт пакета управления Работа с ролями пользователей Командлет Get-UserRole выполняет ряд функций, связанных с администрированием пользователей, однако, как ни странно, не имеет парного командлета Set, поэтому обычно он не используется для изменения и обновления ролей (согласно документации к пакету Windows PowerShell SDK). На рис. 10 показано, как мы получаем список имеющихся ролей пользователей. Затем мы добавляем пользователя в группу операторов только для чтения (см. рис. 11).
Рис. 10 Получение списка ролей пользователей
Рис. 11 Добавление пользователя Включение служб ACSСлужбы ACS — это дополнительная функция, появившаяся в Operations Manager 2007. Это средство централизованной обработки данных аудита безопасности. По умолчанию службы ACS отключены. Обычно их можно настроить на более позднем этапе развертывания диспетчера OpsMgr. Бывают ситуации, когда требуется включить большое количество агентов для служб ACS, и тут на помощь приходит Windows PowerShell, позволяющий автоматизировать установку. На этапе бета-тестирования диспетчера OpsMgr специалисты корпорации Майкрософт добавили сценарий для включения служб ACS для всех агентов. Нил Браун (Neale Browne), ведущий блог на узле SystemCenterForum.org, расширил его, добавив поддержку дополнительных параметров. На веб-узле SystemCenterForum.org (это узел сообщества, в котором обсуждаются решения Microsoft® System Center) имеются два разных сценария Windows PowerShell для автоматизации установки служб ACS. Для настройки всех агентов в отдельно взятой группе используйте файл systemcenterforum.org/wp-content/uploads/ACSBulkEnableGroupDisplayName.zip. Для настройки всех наблюдаемых агентов нужен файл systemcenterforum.org/wp-content/uploads/ACSBulkEnableAllAgents.zip. Включение прокси для агентов В среде OpsMgr могут существовать отслеживаемые устройства без агентов. Таким устройствам нужно обязательно назначить сервер управления или устройство, управляемое агентом, которое будет обеспечивать удаленное наблюдение. Подробные указания по использованию сценариев Windows PowerShell для одновременной настройки большого числа агентов приведены на веб-узле systemcenterforum.org/enable-agent-act-as-a-proxy-in-bulk-via-powershell. Обновленная версия сценария доступна по ссылке systemcenterforum.org/wp-content/uploads/Set AgentProxyBulk_FQDN.zip. Существуют и другие ситуации, в которых для того или иного пакета управления требуется, чтобы агент выступал в роли прокси. Подробные сведения приведены в документации к пакету управления. Практические примерыНиже приведено несколько примеров, демонстрирующих возможности Windows PowerShell в сфере автоматизации. Обработка предупреждений Вам доводилось сталкиваться с необходимостью устранить сразу несколько предупреждений на отдельно взятом компьютере? Возможно, произошел какой-то сбой в приложении, и предупреждения не были обработаны вовремя. Следующий однострочник позволяет обработать все предупреждения с нулевым состоянием разрешения: Get-Alert –criteria 'ResolutionState = ''0''' | Resolve-Alert | Out-Null Следующий код выполняет то же самое, но в масштабных средах с большим количеством необработанных предупреждений он работает гораздо быстрее: Get-Alert | Where-Object {$_.ResolutionState -eq 0} |
Resolve-Alert | Out-Null
Причина такой разницы в производительности заключается в том, что при использовании параметра критерия передаваемое значение предоставляется непосредственно базе данных SQL Server®, и возвращаются только нужные данные. Тем самым сокращается количество объектов, которые нужно передать в консоль Windows PowerShell. Итак, у нас есть простой способ устранить все необработанные предупреждения на отдельно взятом компьютере. Если необходимо, можно запланировать автоматический запуск этого кода. Следующая несложная команда позволяет просмотреть все предупреждения за определенный день: Get-Alert -criteria 'TimeRaised >= ''4/25/2008''' Дата в ней меняется без труда. Выходные данные этой команды можно передать в командлет Resolve-Alert. Тестовые предупреждения Бывают ситуации, в которых требуется способ наблюдения за определенными событиями в средстве просмотра событий Windows и проверки на них. Следующие две строки кода создают запись в журнале событий: $api=New-Object -comObject MOM.ScriptAPI $api.logscriptevent("API test",100,0, "Test using PowerShell")
По умолчанию, правда, запись выполняется в журнал событий Operations Manager, который далеко не всегда используется для поиска каких-то определенных событий. К счастью, Стефан Стрэнджер (Stefan Stranger), один из главных специалистов по эксплуатации в корпорации Майкрософт, написал сценарий, позволяющий создавать события в средстве просмотра событий Windows. Этот сценарий дает большую свободу действий, нежели тот код, который выполняет запись только в конкретный журнал. Сценарий можно найти на странице go.microsoft.com/fwlink/?LinkId=120308. (Стефан упаковал его в файл CAB. Вам нужно будет загрузить файл и щелкнуть его правой кнопкой мыши, чтобы извлечь сценарий.) Единственное, что нужно пояснить: значение, которое указывается для источника событий, определяет, в какой журнал будут вноситься записи. Наверное, самый простой способ гарантировать правильный выбор журнала — открыть средство просмотра событий Windows и найти источник последней записи. Установка владельца Иногда бывает удобно установить владельца предупреждения автоматически. Вот простой способ сделать это из интерпретатора команд: $alert = Get-Alert
-id f3f73d62-37ab-45ce-a7ff-2bdda0dfaeb4
$alert.set_owner("Administrator")
$alert.update("Updated owner")
В первой строке этого кода мы получаем идентификатор конкретного объекта оповещения и передаем его в переменную $alert. Во второй строке эта переменная используется для установки владельца. После всего этого обновление применяется к базе данных OpsMgr. Если при помощи следующей команды проверить владельца, мы увидим, что он изменился: Get-Alert -id f3f73d62-37ab-45ce-a7ff-2bdda0dfaeb4 | Select-Object Owner Чтобы настроить владельца для нескольких предупреждений одновременно, нужно использовать следующий код: Get-Alert | ForEach-Object {$_.Set_
Owner("Administrator");
$_.Update("Owner set")}
Восстановление состояния наблюдения Наверное, вам приходилось сталкиваться с агентами в «ненаблюдаемом» состоянии. В таком случае нужно быстро восстановить режим наблюдения для всех агентов, а потом уж выяснять, что произошло. Сеценарий, приведенный на рис. 12, при запуске непосредственно из командной строки восстанавливает режим наблюдения для всех агентов, затронутых неполадкой. Рис. 12. Восстановление хранилища службы работоспособности
$all="Microsoft.SystemCenter.AllComputersGroup"
$agents = Get-ChildItem Microsoft.SystemCenter.AllComputersGroup | `
Where-Object {$_.HealthState -eq 'Uninitialized'}
foreach ($agent in $agents)
{
$agent.DisplayName
Push-Location $all\$agent\Microsoft.SystemCenter.HealthService
Get-Task | Where-Object {$_.Name -eq "Microsoft.SystemCenter.ResetHealthServiceStore"} | `
Start-Task -Asynchronous
Pop-Location
}
Взгляните на код, показанный на рис. 12. После объявления переменной мы получаем список всех агентов для данного корневого сервера управления, а потом отбираем те, которые работают некорректно. После этого мы асинхронно вызываем задачу, восстанавливающую хранилище службы работоспособности для всех отобранных агентов. Привязка предупреждений к пакетам управления На рис. 13 показано, как получить список всех новых предупреждений с указанием связанных с ними пакетов управления. В этом коде использовано несколько нестандартных приемов для проверки возможности разрешения всех имен пакетов управления. Набор используемых командлетов будет различаться в зависимости от источника предупреждения (правило или монитор). (Обратите внимание на то, что в коде на рис. 13 использовано небольшое обходное решение для командлета Get-Monitor. В диспетчере OpsMgr с пакетом обновления 1 (SP1) этот командлет поддерживает новый параметр идентификатора, что несколько упрощает код.) Рис. 13. Поиск пакета управления
Get-Alert | Where-Object {($_.PrincipalName -ne $null) -and ($_.ResolutionState = '0')}| `
Format-Table –autosize PrincipalName,Severity, `
@{Label="MP"
Expression={If(!($_.IsMonitorAlert)){
ForEach-Object {
((Get-Rule $_.MonitoringRuleId).GetManagementPack()).DisplayName}
}
Else{
ForEach-Object {
$id=$_.ProblemId
((Get-Monitor -criteria "Id='$id'").GetManagementPack()).DisplayName}
}
}
Упрощение отчетов При обновлении среды бывает полезным контролировать версии установленных агентов. Элементарный сценарий, приведенный ниже, выводит на печать соответствующий отчет.
Get-Agent| `
Format-Table DisplayName,@{ `
Label="Version"
Expression={ `
switch ($_.Version){
"6.0.5000.0" {"RTM"}
"6.0.6246.0" {"SP1 (RC)"}
"6.0.6278.0" {"SP1 (RTM)"}
}
}
}
На рис. 14 показаны выходные данные этого сценария. Он представляет собой расширенную версию примеров, приведенных на странице systemcenterforum.org/checking-operations-manager-2007-agent-and-server-versions-via-powershell.
Рис. 14 Выходные данные с указанием версий агентов Планирование задач Некоторые сценарии Windows PowerShell нужно запускать регулярно. Допустим, мы используем клиентский компьютер для подключения к серверу OpsMgr и управления им. На этом компьютере установлены средства администрирования OpsMgr. Требуется ежедневно составлять отчет о версиях агентов и сохранять его в файл, имя которого должно представлять собой текущую дату. Для запуска сценария с локального компьютера можно использовать встроенный планировщик задач Windows. В нем просто создается новая задача, в качестве программы указывается powershell.exe (обычно она располагается в каталоге C:\Windows\System32\WindowsPowerShell\v1.0). Созданная задача настраивается и запускает примерно следующим образом: C:\Windows\System32\WindowsPowershell\v1.0\powershell.exe
–Command "& {& 'c:\agent_report2.ps1'}"
Выясняется, что в исходный код Windows PowerShell приходится вносить довольно много изменений (см. рис. 15). Мы добавили оснастку OpsMgr PowerShell, создали диск Monitor, соответствующий поставщику Operations ManagerMonitoring, создали подключение к корневому серверу управления. Кроме этого, мы загрузили пользовательский сценарий Windows Power Shell (Microsoft.Enterprise Management.OperationsManager.ClientShell.Startup.ps1) для загрузки функций, относящихся к диспетчеру OpsMgr. Рис. 15. Планирование запуска сценария для определения версий агентов
Add-PSSnapin Microsoft.EnterpriseManagement.OperationsManager.Client
New-PSDrive Monitoring Microsoft.EnterpriseManagement.OperationsManager.Client\
OperationsManagerMonitoring ""
New-ManagementGroupConnection Oxford.contoso.com
Set-Location 'C:\Program Files\System Center Operations Manager 2007'
./Microsoft.EnterpriseManagement.OperationsManager.ClientShell.NonInteractiveStartup.ps1
$file="C:\$(Get-Date -f `"MMddyyyy`").rpt"
Get-Agent -Path Monitoring:\Oxford.contoso.com | `
Format-Table DisplayName,@{ `
Label="Version"
Expression={ `
switch ($_.Version){
"6.0.5000.0" {"RTM"}
"6.0.6246.0" {"SP1 (RC)"}
"6.0.6278.0" {"SP1 (RTM)"}
}
}
} | Out-File $file
И это еще не все. Вы, возможно, обратили внимание на то, что при каждом запуске сценария появляется черное окно консоли, если кто-то входит в систему до окончания работы сценария. Решение этого вопроса описано Доном Джонсом (Don Jones) и Джеффри Хиксом (Jeffery Hicks) из Sapien в блоге blog.sapien.com/index.php/2006/12/26/more-fun-with-scheduled-powershell. Грубо говоря, нужно обернуть сценарий в VBScript. Код будет выглядеть примерно так, как показано на рис. 16. Он используется вместо запуска из запланированной задачи следующего кода: C:\Windows\System32\WindowsPowershell\v1.0\powershell.exe
–Command "& {& 'c:\agent_report2.ps1'}"
Рис. 16. Сокрытие всплывающих окон
Dim objShell
Set objShell=CreateObject("WScript.Shell")
'enter the PowerShell expression you need to use short filenames and paths
strExpression="'c:\agent_report2.ps1'"
strCMD="powershell -nologo -command " & Chr(34) & _
"&{&" & strExpression &"}" & Chr(34)
'Uncomment next line for debugging
'WScript.Echo strCMD
'use 0 to hide window
objShell.Run strCMD,0
В задаче будет использоваться программа wscript.exe, и вызов ее будет выглядеть примерно следующим образом: C:\WINDOWS\System32\wscript.exe C:\agent_report.vbs В конечном итоге, отчеты будут создаваться автоматически и незаметно для пользователя. ЗаключениеЭта статья — лишь краткий обзор функций автоматизации, предоставляемых диспетчером OpsMgr 2007, и возможностей Windows PowerShell в сфере администрирования OpsMgr. Нам хотелось бы поблагодарить всех тех, кого мы упомянули в статье, а таже Пита Зергера (Pete Zerger), основателя SystemCenterForum.org, обладателя звания MVP по MOM, за неоценимую помощь.
Теги:
Комментарии посетителей
Комментарии отключены. С вопросами по статьям обращайтесь в форум.
|
|
