Posts tagged ‘Петлевой’

SCOM Dashboard — unhealthy objects with missing monitor alert

Привет.

Всем администраторам Operations Manager известно, что пользователи системы мониторинга иногда закрывают алерты, которые создаются мониторами. Одно из решений это проблемы — автоматический Reset этого монитора, используя тот же Orchestrator (детали тут). Не хотите поднимать ради этой задачи Orchestrator — используйте аналогичный скрипт и Scheduled Task. Но все это работает с алертами только после того, как вы внедрили одно из этих решений. Как же быть с уже закрытыми алертами? Или если вы приехали к клиенту впервые, как понять что он уже закрыл вручную, например, 90 дней назад?
Continue reading ‘SCOM Dashboard — unhealthy objects with missing monitor alert’ »

обновление серверов через Orchestrator 2012 (часть 4)

Привет!

Первая часть

Вторая часть

Третья часть

Продолжаем цикл статей, посвященных работе с Orchestrator.

В прошлый раз мы закончили вопросом «как запускать runbook?».

Общепринятый вариант — это использование activity Monitor Date/Time. В комбинации с Check Schedule можно создавать достаточно гибкое расписание. Например, перегрузка сервера в 08:00 в воскресенье.

Обновлениесерверов024

У данного метода я вижу, как минимум, два недостатка.
Первый: реальную работу этот runbook будет выполнять всего 1 раз в неделю, но запущен будет всегда! То есть мы получаем максимальное значение одновременно выполняемых на runbook сервере runbook-ов, минус — количество подобных  runbook-ов. Эту проблему можно решить, используя Invoke Runbook. У вас будет один главный runbook, который будет запускать все остальные. Я пробовал. Пока количество менее 10-20, еще можно работать, но чем их больше, тем труднее вносить изменения. Orchestrator начинает менять местами activity, переплетать link-и. И еще, чтобы внести изменения нужно остановить этот runbook и, следовательно, можно пропустить запуск какого-нибудь runbook-a!

Второй: я не нашел простого способа получить информацию о том, какие runbook-и когда стартуют. К sql-базе я запросы не писал , может быть, это как-то и можно получить. Если кто-то знает, буду рад вашим ответам в комментариях.

Continue reading ‘обновление серверов через Orchestrator 2012 (часть 4)’ »

автоматическое добавление Boundary в BoundaryGroup

Привет

Я, как было заявлено Евгением, хороший специалист по System Center Operations Manager. Поэтому я пишу про Orchestrator, а теперь еще хочу коротко затронуть SCCM.

Хочу поделиться маленькой идеей автоматизации в SCCM. Суть вопроса в следующем. В средних и крупных компаниях количество физических расположений (сетевых сегментов) большое и динамически меняющееся. То есть имеется большое количество AD sites, которые появляются иногда часто, иногда нет. Все вы знаете, что при помощи Active Directory Forest Discovery могут автоматически создаваться Boundary. Но автоматически они добавляться в Boundary Group не могут. На вопрос почему, сегодня утром Евгений дал мне ответ: «Неизвестен критерий» (он немного иначе сказал, лаконичнее что ли 🙂 ).

Итак, давайте представим часто встречающуюся ситуацию. Есть регионы (страны), в них есть центральный сайт и дочерние сайты. Часто серверное оборудование есть  только в центре региона,  а на дочерних объектах максимум RODC. Distribution Point находится в центральном сайте региона. Вы создаете Boundary Group с именем ИМЯ_РЕГИОНА-CENTER. К нему привязывайте региональную DP. И все Boundary этого региона добавляете в эту Boudary Group. В итоге имеем рутинную задачу, которая так и просится быть автоматизированной.

Одно примечание. Очень желательное, я бы даже сказал, обязательное правило — это стандарт именования.
Пример
Регион — UA. Boundary Group — UA-CENTER. Boundary: UA-Kiev,UA-Lviv и т.д.
Регион — RU. Boundary Group — RU-CENTER. Boundary: RU-Moscow,RU-Razan и т.д.

Реализовать это на Orchestrator не получится, нет у него таких activity :-). Можно запускать ps скрипт, но мы можем запускать его на любом сервере, нужна только SCCM Console и powershell.

Сам скрипт


# подключаемся к SCCM через ps
Import-Module -Name "$(split-path $Env:SMS_ADMIN_UI_PATH)\ConfigurationManager.psd1"
$site = Get-PSDrive -PSProvider CMSite
Set-Location "$($site.name):" #тут может намудрил чуток, но как есть



# получаем все boundry, которые не включены в группы 
$boundries_orphan = Get-CMBoundary | ?{$_.GroupCount -eq 0} 

foreach($b in $boundries_orphan)
{

	$BoundaryName = $b.DisplayName # Тут у нас имя пример 'contoso.com/UA-Kiev'

	if($b.DisplayName -match "(^.+/)(.+)(-.+)") # какой же ps без непонятного кода, читайте про -match

	{
		$BoundaryGroupName = "$($matches[2])-CENTER"
		Add-CMBoundaryToGroup -BoundaryGroupName $BoundaryGroupName -BoundaryName $BoundaryName
	}		

}

Если нет стандарта именования, скрипт просто будет содержать больше проверок.

Создавайте пользователя, делегируйте ему права на модификацию Boundary Group. Не знаете как? Спросите доброго хозяина блога! И через Scheduled Tasks запускайте с необходимой вам частотой.

P.S. Это было не руководство к действию, а просто идея! Если у вас есть хорошие идеи, но пугает реализация, пишите — возможно, мы поможем друг другу.

Александр Петлевой

обновление серверов через Orchestrator 2012 (часть 3)

Привет.

Первая часть

Вторая часть

В первой и второй части мы обсудили различные моменты нашего процесса обновления серверов. Давайте же перейдем в конце концов к Orchestrator-у.

Начнем с настройки Orchestrator-a.

На каждом Runbook сервере по умолчанию одновременно могут работать 50 runbook-ов. Увеличим это количество до 200, если серверов на обновление у вас очень много, это значение должно быть еще больше.
cd <System Drive>:\Program Files (x86)\Microsoft System Center 2012\Orchestrator\Management Server

aspt * 200

И перезапуск Orchestrator Runbook Service.

Теперь давайте создадим несколько глобальных переменных. Мы будем их использовать в наших runbooks. Как минимум, вот такие:

OpalisUpdate001

Создавайте ваши runbook-и максимально гибкими. Это необходимо и для переноса в другие среды, и для простоты обслуживания их в дальнейшем. Представьте ситуацию, что у вас 100 runbook-ов, в которых вы используете activity Send Mail и жестко прописали smtp сервер. Сколько у вас займет времени и сколько вы допустите ошибок, если будет нужно его изменить? В случае же использования variables, достаточно ОДНОГО единственного изменения. Вот так, например, должен выглядеть ваш activity.

OpalisUpdate002

 

Continue reading ‘обновление серверов через Orchestrator 2012 (часть 3)’ »

обновление серверов через Orchestrator 2012 (часть 2)

Привет.

В первой части мы создали базу данных и таблицу в ней для хранения нашей информации. Давайте внесем несколько записей в таблицу. Это можно сделать разными вариантами:

  1. Вручную, нажав на таблице правой клавишей и выбрав Edit Top 200 Rows, и далее заполнить таблицу.
  2. Пункт 1, только вставив содержимое ранее сформированного xls файла.
  3. Запросом Insert.
  4. Создать runbook и заполнять эту таблицу, получая данные отуда вам угодно.
  5. Используя ETL пакеты.
  6. Да еще с десяток способов.

Мы же внесем информацию согласно п.1.

Обновлениесерверов003

Поле Type принимает 2 значения, Auto — автоматическая установка и оповещение, Manual — проверка на наличие обновлений, но без автоматической установки. Так же очень удобно в этой таблице хранить информацию о всех серверах, для предоставления информации по требованию руководству (простейший отчет на SSRS).  Все остальное интуитивно понятно.

Разобьем наш процесс на основные блоки:

  1. Проверка на наличие обновлений.
  2. Оповещение о предстоящих работах.
  3. Установка обновлений.
  4. Оповещение об успешно выполненных обновлениях.

Проверка на наличие обновлений. Проверяем каждый сервер на наличие доступных обновлений.  Если обновления есть, то обновляем нашу таблицу и в поле NeedToUpdate ставим 1. Запуск в 07-00 каждый будний день.
 
Оповещение о предстоящих работах. Определяем из запроса к базе данных сервера, у которых по расписанию обслуживание завтра и NeedToUpdate=1. Особый случай, если сервер обслуживается в воскресенье и понедельник, оповещение должно прийти в рабочий день, в пятницу. Уведомляем ответственных (Это может быть и группа рассылки, и, конечно, ИТ специалисты. В таблице в поле Descr можно, например, написать  ФАЙЛОВЫЙ СЕРВЕР БУХГАЛТЕРИИ и оповестить бухгалтеров.) В зависимости от Type, будет указание в ручном либо автоматическом режиме. Запуск в 09-00 каждый будний день.
 
Установка обновлений. На момент выполнения runbook получаем список серверов, у которых время совпадаем с текущим и Type = Auto AND NeedToUpdate=1. Запускаем процесс обновления. Более детально будет рассмотрено далее. Запуск каждый час (наше расписание кратно 1 часу).
 
Оповещение об успешно выполненных обновлениях. Тут может быть 2 варианта. Сразу после выполнения или, например, каждый день в 10-00.
 

И в этот раз мы будем строить наши runbook-и с обработкой ошибок.

Orchestrator все-таки появится, но уже в третьей части.
Оставайтесь с нами. Пишите комментарии. Дальше будет интереснее!

Александр Петлевой

обновление серверов через Orchestrator 2012 (часть 1)

Привет.

Что больше всего любит делать системный администратор?
Перегружать ночью сервера?!

Представьте, что вам нужно выполнить установку обновлений по очень гибкому графику.
Например, такой вот вариант (и это 10%, или 1%, или 0.1 % от общего количества серверов):

имя сервера время для обслуживания
Server001 Понедельник 11:00-13:00
Server013
Server014
Server013
Server022
Server016
Server023 Четверг 3:00-4:30
Server035
Server046 Четверг 20:00-22:00
Server012
Server003
Server005 Четверг 20:00-21:00
Server111 Пятница 14:00-16:00
Server234 Суббота 00:00-2:00
Server012 Воскресенье 01:00-3:00

У каждого сервера свой список ответственных лиц. И в случае, если на сервере есть доступные для установки обновления, этим лицам нужно написать заранее, предупредить о планируемых работах. А потом еще и написать, что все прошло удачно.

Ну очень не хочется делать все это вручную.

А вам? Как же избавиться от этой рутины?

WSUS или SCCM? Расписание еще можно попробовать, но оповещение?

Нам поможет Orchestrator.

Continue reading ‘обновление серверов через Orchestrator 2012 (часть 1)’ »

новый автор блога

Совершенно внезапно для меня у моего хорошего приятеля из Киева Александра Петлевого появилось желание делиться своим практическим опытом. Сашу я знаю давно, как признанного эксперта по SCOM, и неоднократно обращался к нему за консультациями, поскольку он работает в крупной компании и, мониторя сотни серверов, наработал огромный практический опыт. Я неоднократно предлагал ему завести свой блог, но он всё отнекивался. Теперь он таки решился на это, но будет это делать в рамках моего блога, чему я очень рад. Первая его статья рассказывает о создании runbook в Orchestrator.

Слово Саше:

Меня зовут Александр Петлевой. В ИТ более 10 лет. Последние годы большую часть времени занимаюсь программными продуктами Microsoft System Center (SCOM,Advanced SCOM Management Pack authoring, SCCM, SCORCH).
Профиль Microsoft

Посмотрим, насколько хватит его запала. 🙂

А вот так он размышляет о наследовании сущностей внутри класса SCOM:

Петлевой

оповещение пользователей о необходимости смены пароля через Orchestrator 2012

Привет.

Хочу поделиться маленьким, но достаточно нужным автоматическим процессом в любой организации, где есть пользователи, работающие с сетью исключительпо через Wi-Fi. Проблема заключается в том, что после конца периода использования пароля пользователи, работающие через Wi-Fi, подключиться к сети уже не могут и изменить пароль, соответственно, тоже. Таким образом получаем недовольного пользователя, простой в работе и  заявку в сервисдеск.
Предлогаемое решение — это оповещение о необходимости смены пароля за 10 дней до конца срока действия. Оповещение — раз в день по почте.
Ранее использовался скрипт на vbs и scheduled task, но время идет и нужно соответствовать 🙂 . При очередном разворачивании в новой инфраструктуре было принято решение перенести данный функционал в Orchestrator 2012.

Для работы необходимо:

1. На Runbook сервере, где будет работать runbook, установить Active Directory Powershell Module 

2. Добавить в Orchestrator Active Directory Integration Pack
Для начала создадим стркутуру папок. Советую иметь строгую иерархию в любой системе.
Например, вот такую:01 Catalog
Создадим runbook, например, Password expire.

Первым элементом в нашем runbook будет Run .Net Script:

01 FirstItem_01
Этот скрипт на powershell будет получать из Active Directory значение Maximum Password Age.

$Value = powershell{
import-module ActiveDirectory
(Get-ADDefaultDomainPasswordPolicy).MaxPasswordAge.Days
}

Continue reading ‘оповещение пользователей о необходимости смены пароля через Orchestrator 2012’ »