Собрание заметок об информационных технологиях
После обновления System Center 2012 Operations Manager (SCOM) до уровня Service Pack 1 встал вопрос об обновлении консолей у всех администраторов имеющих доступ к Operations Manager. Выполним эту задачу с помощью System Center 2012 Configuration Manager (SCCM).
Совсем недавно стал доступен Service Pack 1 (SP1) для линейки продуктов Microsoft System Center 2012. Попробую рассмотреть процесс обновления тех продуктов линейки, с которыми у меня есть возможность работать.
Из документа Upgrade Sequencing for System Center 2012 SP1 можно понять, что в средах, где используется несколько продуктов линейки System Center 2012 важна правильная последовательность обновления этих продуктов до уровня SP1, а именно есть рекомендация соблюдать следующий порядок обновления:
1. Orchestrator
2. Service Manager
3. Data Protection Manager
4. Operations Manager
5. Configuration Manager
6. Virtual Machine Manager
7. App Controller
В этой заметке мы рассмотрим первый пункт этой последовательности – обновление System Center 2012 Orchestrator (SCO) до уровня SP1.
При мониторинге некоторых объектов ИТ-инфраструктуры в System Center 2012 Operations Manager (SCOM) может возникнуть потребность получать оповещения об изменениях состояния этих объектов не только по электронной почте, но и на мобильные устройства (телефоны, коммуникаторы и.т.п.) в виде сообщений Short Message Service (SMS). Например в нашей инфраструктуре решено использовать SMS оповещения при изменении параметров электропитания в серверных помещениях, чтобы оперативно ставить в известность о проблемах ответственных лиц. SCOM умеет работать с GSM-устройствами напрямую подключёнными к COM-порту сервера управления (Management Server).
Для начала хочу рассказать предысторию того как я пришёл к использованию System Center 2012 Orchestrator (SCO), которая по сути прямого отношения к самому этому продукту не имеет, но возможно информация изложенная здесь кому-то покажется интересной и даст ответы на некоторые вопросы.
Итак, жила-была ферма Remote Desktop (RD) Connection Broker состоящая из трёх виртуальных серверов RD Session Host на базе Hyper-V, которые обслуживали пользователей в рабочее время и без каких-либо проблем подвергались резервному копированию с помощью System Center 2012 DPM в нерабочее время. И всё бы ничего если бы не возникшая необходимость начать использовать на этих виртуальных серверах клиента Application Virtualization Client (App-V) for Remote Desktop Services. Клиент то конечно установился и прекрасно справляется со своей задачей – виртуализацией в многопользовательской среде весьма специфических приложений, требующих от пользователей расширенных привилегий в системе. Но вот незадача…сразу после начала использования клиента App-V я заметил две вещи: во первых - на DPM пропала возможность нативно на горячую с помощью метода Backup Using Child Partition Snapshot бэкапить виртуальные сервера фермы полноценно используя VSS (осталась доступной лишь возможность бэкапа с помощью Backup Using Saved State), а во вторых – при бэкапе в режиме Save State каждую ночь фиерично разваливался кластерный экземпляр службы RD Connection Broker. По сути вторая проблема является прямым следствием первой. Но это стало ясно позже...А пока я взялся за изучение проблемы систематично разваливающегося кластера RDS…
В ходе настройки политик управления клиентами любого антивирусного ПО необходимо определять список каталогов, имён процессов или даже расширений фалов, которые должны исключаться из Real-Time сканирования. Постараюсь собрать в одном месте информацию о рекомендуемых параметрах исключений и по мере необходимости буду его корректировать. Стоит отметить, что список составлен исходя из приложений, которые эксплуатируются в моём рабочем окружении. Список разделен по основным категориям сервисов и там где возможно есть ссылки на официальные рекомендации производителей ПО. Во всех случаях подразумевается что программное обеспечение установлено в каталоги «по умолчанию».
В процессе работы с System Center 2012 Operations Manager (SCOM) может создаваться некоторое количество пакетов управления (Management Pack, MP), в которых мы сохраняем переопределения (Overrides) или же собственные мониторы (Monitors) / правила (Rules) и т.п. объекты. Время от времени эти кастомизированные настройки могут меняться, и для того, чтобы организовать их сохранность, можно воспользоваться процедурой экспорта этих незапакованных (Unsealed) пакетов управления в xml файлы.
Большое количество пакетов управления (Management Pack) в System Center 2012 Operations Manager для корректной работы механизмов обнаружения и мониторинга требуют наличия включенной опции Agent Proxy
При добавлении нового управляемого агента в SCOM эта опция по умолчанию выключена. Для того чтобы автоматизировать процесс включения этой опции на всех агентах, где она ещё не включена можно применить PowerShell скрипт:
Import-Module OperationsManager
$Agents = Get-SCOMAgent | Where {$_.ProxyingEnabled -ne $True}
$Agents | ForEach {$_.ProxyingEnabled = $True}
$Agents | ForEach {$_.ApplyChanges()}
Этот скрипт ставим на периодическое выполнение в планировщик заданий на сервере управления SCOM, вызывая его командой:
PowerShell.exe -NoProfile -command "C:ScriptsSCOM-Agent-Proxy.ps1"
В процессе процедуры обнаружения (Discovery) для удалённой установки агента (Push-installation) SCOM 2012 на сервера с Forefront TMG мы можем получить ошибку по причине блокировки необходимых нам соединений.
После развёртывания роли сервера управления (Management Server) в SCOM 2012, этот самый сервер начинает работать в полнофункциональном ознакомительном режиме (Evalution), который действует в течение 180 дней. При этом в консоли SCOM можно наблюдать соответствующую информацию об этом.
Если сервер установлен в продуктивном режиме и у нас есть ключ продукта, полученный по программе лицензирования System Center 2012, то мы можем перевести наш сервер в режим полной активной версии. Для этого на сервере SCOM открываем консоль Windows PowerShell с правами Администратора и выполняем:
Import-Module OperationsManager
Set-SCOMLicense -ProductId XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
После этого, после следующей перезагрузки сервера, мы сможем убедиться в том, что наш сервер поменял свой уровень лицензии (product license level) на Retail
Если же в нашей группе управления несколько серверов, то для того, чтобы изменить уровень лицензии для каждого, выполним:
Import-Module OperationsManager
Get-SCOMManagementServer | ForEach {Set-SCOMLicense -ComputerName $_.HostComputer -ProductId "XXXXX-XXXXX-XXXXX-XXXXX-XXXXX" -Confirm:$False}
В процессе процедуры обнаружения сетевых устройств (Network Devices Discоvery) в SCOM 2012 можно получить статус No Response Ping, то есть якобы устройство не отвечает на запросы ICMP, хотя на самом деле устройство доступно.
Определить - только экспериментальным путём. Вставите накопитель в слот корзины и сами увидите, что контроллер его без проблем определит и…
Сейчас не вспомню какой точно был объём хранилища, но решающей роли это не сыграло. Для проверки ОЗУ увеличивалась сначала в…
RSS - Записи
Последние комментарии