System Center Service Manager – это сервис деск от компании Microsoft. Не самый простой продукт в настройке, но при использовании совместо с System Center Orchestrator позволяет конфигурировать довольно не тривиальные вещи. Например, в этой публикации я покажу, как выполняется настройка назначения заявки Service Manager на пользователя из группы AD через Orchestrator.
Описание задачи
В системе Service Manager нам необходимо автоматически назначать заявку на пользователя из определенной группы Active Directory. Группу Active Directory мы также будем находить автоматически на основе названия группы поддержки в Service Manager.
Предположим, что в SCSM для всех инцидентов, которые назначены на группу поддержки Tier1 мы каким-то образом (об этом далее) будем находить группу AD. Из этой группы AD мы будем в режиме round-robin выбирать пользователей.
Конфигурация на стороне Active Directory
В Active Directory мы создадим группу Support. В описании этой группы мы укажем значение “SCSM-FG-Tier 1”. Именно по нему мы и будем сопоставлять группы поддержки SCSM с группами Actve Directory.
Состав группы Active Directory следующий:
Именно этих пользователей мы и будем назначать исполнителями заявок. Назначать заявки мы будем последовательно – от пользователя u1 до пользователя u6. Следом за пользователем u6 снова будет идти пользователь u1 и т.д.
Таким образом, как только в инциденте Service Manager будет указан группа поддержки Tier 1, то в Active Directory будет искаться группа с описанием SCSM-FG-[support_group_name], т.е. “SCSM-FG-Tier 1”. Из этой группы мы будем последовательно выбирать пользователей.
Настройка назначения заявки Service Manager через ранбук Orchestrator
Это относительно простой ранбук. Общий вид ранбука будет следующий:
Теперь рассмотрим более детально каждый из этих шагов.
1. Шаг “Monitor New IR”. Это довольно простой шаг. Мы отслеживаем все новые заявки класса “Incident”. Вот настройки этого шага:
2. На втором шаге “Get IR” мы должны получить объект инцидента. Соответственно, в условиях фильтрации мы указываем “SC Object Guid” от предыдущего шага.
3. А вот теперь мы должны сопоставить имя группы поддержки Service Manager с определенным описанием группы Active Directory. Ну, тут на ваше усмотрение и организационную структуру AD. Можете сопоставлять, например, по имени группы.
4. Теперь, пожалуй, самая объемная часть ранбука – это шаг “Get current user”, который запускает сценарий PowerShell.
Полный текст скрипта:
Import-Module activedirectory
$Group = Get-ADGroup -Identity {Common Name from "Get AD Group"} -Properties *
[array]$Users = Get-ADGroupMember -Identity $Group.Name
$CurrentOrder = $Group.info
$Order = 0
if (($CurrentOrder -ne $null) -and ($CurrentOrder -lt $Users.Count - 1)){
$Order = [int]$CurrentOrder + 1
}
$Name = $Users[$Order]
$UserDN = $Name.distinguishedName
Set-ADGroup -Identity $Group.Name -Replace @{info=$Order}Этот сценарий PowerShell делает именно то, о чем я говорил ранее – последовательно выбирает пользователей из группы Active Directory. Последнее состояние (позицию выбранного пользователя) сценарий сохраняет в атрибуте “Info”.
Искать пользователя Active Directory в SCSM мы будем по атрибуту “distinguishedName”. Соответственно в настройках шага ранбука “Get current user” мы опубликуем переменную “UserDN”.
5. На шаге “Get User Object in SCSM” нам необходимо получить объект пользователя в SCSM по distinguishedName из предыдущего шага.
6. И самым последним шагом “Assign IR to User” мы назначаем инцидент на пользователя.
В классе Incident нет непосредственно как такового поля “Assigned User”. Вместо этого для класса инцидент формируется связь с типом “Assigned To User” для класса “Active Directory User or Group”. И указываются SC Object Guid как для исходного, так и для целевого класса.
Если мы не допустили никаких ошибок, то, например, посмотрев ход выполнения ранбука в отладчике (Runbook Tester) мы должны увидеть тот факт, что все шаги ранбука выполняются успешно.
А так же мы увидим соответствующее назначение инцидента на пользователя на форме инцидента.
Вместо заключения
Пара моментов:
1. Аналогично инцидентам вы можете использовать этот ранбук и для запросов на обслуживание. Только имейте в виду, то в запросах на обслуживание дополнительно еще есть действия (ручные действия, параллельные действия, действия рецензирования и т.д.). Их тоже можно назначить в соответствии с ранбуком выше.
2. Ранбук не учитывает, например, отпуска или больничные сотрудников. Для этого вам нужно немного доработать шаг ранбука “Get current user”, чтобы он учитывал именно вашу логику исключения отпусков или больничных сотрудников.
3. Если вам не обязательно назначать именно пользователя, а, например, чтобы с заявкой могла работать целая группа пользователей, то можете рассмотреть Support Group Mapping от Cireson.
Он есть даже в бесплатной версии портала Cireson и позволяет сопоставлять группы поддержки инцидентов или запросов на обслуживание с группами Active Directory.