System Center Configuration Manager и как с ним бороться

Привет!

Первая часть

Вторая часть

Третья часть

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

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

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

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

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

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

Привет.

Первая часть

Вторая часть

В первой и второй части мы обсудили различные моменты нашего процесса обновления серверов. Давайте же перейдем в конце концов к 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. Как минимум, вот такие:

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

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

Привет.

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

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

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

Поле 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 все-таки появится, но уже в третьей части.
Оставайтесь с нами. Пишите комментарии. Дальше будет интереснее!

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

Привет.

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

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

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

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

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

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

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

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

Привет.

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

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

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

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

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

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

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

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