У любой IT-службы со временем накапливается пачка визийных схем: сетевые схемы, схемы хождения почты, схемы серверных помещений и серверных стоек и тд. и т.п. Такие схемы в основном используются для того, чтобы понять, какие объекты IT-инфраструктуры вообще имеются в компании и как они взаимосвязаны. Блягодаря свежевышедшему Add-in’у стало возможным по этим схемам отслеживать ещё и здоровье всех объектов.

Работает это следующим образом – на рабочую станцию оператора мониторинга ставится консоль SCOM, Visio 2007 Pro и Add-in. После установки Add-in’а в Visio появляется новый пункт меню – «Operations Manager». Далее нужно создать визийную схему или открыть готовую и из нового пункта меню сопоставить с объектами этой схемы объекты Operations Manager’a. Разумеется, предварительно нужно внедрить Operations Manager.

В этом посте я пошагово разберу, как сделать интерактивной небольшую схему сети.

1. Установка.

На самом деле, подобный add-in уже давно существовал для версии SCOM 2007 (не R2). Однако, чтобы заставить Visio 2007 работать со SCOM’ом, требовалось странное – наличие на рабочей станции оператора полноценной среды разработчика Visual Studio 2005 Pro (далеко не бесплатной, между прочим). Для новой версии Add-in’а предварительные требования следующие:

• Operations Manager 2007 R2 Operations console
• Microsoft Office Visio 2007 Professional
• The Microsoft .NET Framework 3.5 SP1
• Visual Studio Tools for Office system Runtime 3.0
• 2007 Microsoft Office System Update: Redistributable Primary Interop Assemblies

После установки перечисленного выше софта и патчей, можно скачать и установить Add-in. Установка всего этого добра на мою рабочую Windows 7 не вызвала у меня никаких затруднений, думаю, и у вас всё получится.

2. Создание соединения с сервером SCOM.

Для начала нужно заполучить схему, с которой будем работать или нарисовать таковую самому. Дружественный отдел IT-диспетчеров прислал мне одну из своих схем, на ней отображена связь московского офиса одного из наших клиентов с офисом в Краснодаре.

Схема сети

Открываем схему в Visio. Заходим в меню «Operations Manager». Выбираем – «Configure Data Source».

Настройка соединения схемы Visio с серером SCOM

Указываем имя RMS сервера, url его web-консоли (у меня даже сработал автопоиск url), выбираем, как часто обновлять схему.

3. Сопоставление объектов.

Переходим к самой интересной части. Будем сопоставлять цискам и каналам на визийной схеме циски и каналы из SCOM’а, и да пребудет с нами Сила.

В Visio открываем меню «Operations Manager» и выбираем пункт «Add Data Links». Далее мы должны, используя выпадающий список и фильтр, выбрать класс, объекты которого мы хотим добавить на схему. Наш выбор – рутеры.

Выбираем класс

После этого надо определиться, какие именно рутеры нам нужны. Наш выбор – два московских и один краснодарский. Кое-какие данные на скриншоте пришлось вымарать. Не обессудьте, отдел информационной безопасности не дремлет.

Выбираем, какие именно рутеры нам нужны.

Нажимаем кнопочку Add и вуаля, прямо в Visio появляются объекты из SCOM.

Объекты из SCOM в панели Visio

Полдела сделано, осталось только прилинковать их к объектам на схеме. Сделать это можно несколькими способами, например, подхватить объект SCOM из новой панельки и перетащить его на объект на схеме Visio (drag’n drop рулит). В результате, на схеме появится знакомый нам по SCOM кружок.

Зелёный кружок с галочкой означает, что объект в порядке.

Если же кружки на схеме вас не устраивают и вы предпочитает раскрашивать объекты в цвет их здоровья, то нужно зайти в меню Data, выбрать пункт Display Data on Shapes и в появившемся меню произвести соответствующую настройку.

Окрашиваем объекты в цвет их здоровья.

Итак, с цисками покончили, переходим к каналам. У нас на схеме есть 4 линка: KRDR_PU-J_1, KRDR_PU-J_2 – публичные, KRDR_MU-J_1 – mpls, KRDR_U-J_2 – интегральный.

Получаем их из SCOM’а.

Выбираем класс "jitter"

Выбираем класс "jitter"

Далее, линкуем появившиеся в панели Visio джиттеры к линкам на схеме.

4. Подводим итоги.

В результате у меня получилась вот такая схемка:

Как видите, связь с Краснодаром в порядке, но когда случаются потери пакетов или обрывы, то кружки на схеме становятся жёлтыми или красными.

Что ещё можно делать с этой схемой? Можно ткнуть правой кнопкой по объекту и вызвать Health Explorer или Alert view.

Верхних двух пунктов раньше не было.

Health Explorer и Alert View откроются в окне браузера. Для этого на вашем сервере SCOM конечно должна быть установлена web-консоль.

Health explorer.

Теперь можно развернуть Visio на весь экран (кнопка F5) и получится вполне взрослый Monitoring Dashboard. Ставите вокруг себя пяток мониторов с такими dashboard’ами и можно считать, что мониторинг удался.

Что вообще можно мониторить в принтере? Самые очевидные ситуации, требующие вмешательства техподдержки – закончился картридж и замята бумага. Можно конечно ждать, пока пользователи создадут заявку, но, если вы будете знать обо всём заранее, то это снизит время реакции техподдержки и увеличит степень удовлетворённости клиентов.

Ситуация с мониторингом печатающих устройств посредством System Center Operations Manager 2007 на сегодняшний день сложилась довольно печальная.

Изначально System Center Operations Manager 2007 (далее SCOM 2007) не умеет мониторить принтеры. В версии R2 в этом плане ничего не изменилось. Теоретически, для мониторинга печатающих устройств можно приобрести management pack (далее MP) компании Quest, который умеет обрабатывать целых 6 трэпов. Дороговато для стоимости в 400 долларов за лицензию, не так ли?

Однако, если у вас в фирме МФУ только от компании Xerox – считайте, что вам повезло. Xerox сделала management pack для мониторинга своих МФУ с помощью SCOM 2007 и даже любезно выложила его для бесплатного скачивания. Этот MP носит гордое имя Xerox CentreWare for Microsoft SCOM по аналогии с отдельным продуктом для мониторинга МФУ Xerox.

Давайте разберёмся, достаточно ли функционала этого MP для нормального мониторинга, а также, можно ли его использовать для мониторинга МФУ не только Xerox, но и других производителей.

1. Установка.

MP состоит из одного XML файла, но, несмотря на это, программисты Xerox запаковали его в инсталлер. Запускать инсталлер нужно строго на рутовом сервере SCOM, он проверят, действительно ли SCOM есть на том сервере, где его запустили, затем распаковывает и импортирует XML в репозитарий. Вероятно, установщик был сделан для нашего удобства, но на практике, на одном из моих серверов он упорно не находит SCOM и отказывается продолжать установку.

Если вам не повезёт, то вы увидите это.

Будем считать, что вы успешно установили MP, и перейдём к обзору его интерфейса и возможностей.

2. Интерфейс и функционал.

Так как MP состоит из одного XML файла, то у него нет собственного интерфейса по добавлению принтеров. MP анализирует сетевые устройства, добавленные в SCOM, разбирается, принтер это или нет, и мониторит то, что считает принтерами.

Интерфейс MP настолько по-спартански прост и суров, что я приведу его на скриншотах целиком.

Корневая, она же единственная, папка.

Список неприятностей, происходящих с принтерами.

В алёрты попадают как действительно важные события: принтер зажевал бумагу, кончился картридж, так и всякий мусор: «в принтере почти кончилась бумага», «входной лоток пуст». По модели состояния видно, какие алёрты теоретически возможны.

Принтер-хулиган.

На графиках, как ни странно, отображается не количество отпечатанных листов в час или в день (по таким данным можно было бы отслеживать активность печати), а общее число листов, которое, естесственно, постоянно растёт. Зачем нужна такая информация? Разве что, чтобы понять, какие принтеры используются наиболее активно, хотя, на поверку может оказаться, что они просто были раньше куплены.

Графики количества отпечатанных листов.

 Окинуть орлиным взором список принтеров, чтобы понять, в каком они сейчас состоянии, не получится – в MP нет state view. Однако, можно увидеть принтеры и их состояние в общем списке сетевых устройств. Правда там отчаянно путаются под ногами источники бесперобойного питания и активное сетевое оборудование.

Общий список сетевых устройств.

 К сожалению, как и ожидалось, MP работает только с МФУ, произведёнными компанией Xerox. На скриншоте видно, что принтеры HP 10.100.19.10 и 10.100.19.100 не мониторятся.

 

3. Баги.

Ошибки при установке MP сразу навеяли тревожные предчувствия, которые позже подтвердились. После установки MP в логи Operations Manger на сервере SCOM стали регулярно сыпаться ошибки.

Последствия установки MP.

Все ошибки одинаковы по содержанию.

Достаточно ли функционала, предоставляемого MP от Xerox для мониторинга принтеров? Если бы можно было мониторить принтеры любых производителей, то ответ был бы положительный.

На самом деле, достаточно одного alert view и возможности посылать уведомления по почте и SMS. Графики общего количества отпечатанных листов в общем-то нафиг никому не нужны.

Для полного счастья, пожалуй, хотелось бы иметь общий список принтеров (state view), а от мусорных алёртов напротив хотелось бы избавиться. Кроме того, неплохо было бы убратьошибки в логах.

Во второй части этой статьи я вскрою MP, и объясню, как он работает. В третьей части я доработаю его насколько это возможно и выложу улучшенную версию для скачивания. Следите за обновлениями блога.

Расскажу вкратце о том, чем они хороши, а также о том, куда пропала вкладка Relay Restrictions.

В славные времена Exchange 2003 настройки приёма сообщений по SMTP делались для всего сервера сразу. Конечно, можно было на одном Exchange создать несколько виртуальных SMTP серверов c разными настройками и прикрепить каждый виртуальный сервер к одному из локальных IP адресов сервера Exchnage. Но такой вариант редко был полезен.

В итоге, если в сети был хотя бы один умный МФУ, который умел отсылать результаты сканирования документов на почту, но при этом совершенно не подозревал об аутентификации, то рано или поздно приходилось делать страшное – разрешать отсылку писем без аутентификации всем подряд.

Вот как настраивалась аутентификация.

Зато, если нужно было открыть релей неавторизованным пользователям, то это делалось просто и секьюрно.

А вот так настраивался релей.

Open relay, если кто подзабыл – это возможность отсылать сообщения адресатам, чьи почтовые ящики находятся вне почтовой организации отправителя. Открытый релей – опасная штука, если к нему получат доступ спамеры, то ваш сервер может стать пунктом пересылки рекламы всему миру. Ваш сервер мгновенно попадёт в блеклисты всех почтовых служб, и хождение почты будет парализовано.

С выходом Exchange 2007 для любителей разрешать пользователям минимально необходимый набор действий наступило раздолье. Теперь можно создавать receive connector’ы с уникальными настройками аутентификации хоть для каждого устройства в сети.

Receive connector – это, фактически, набор правил для почтовых серверов с ролями Hub Transport и Edge Transport, которые объясняют серверам, что делать с полученными по SMTP(S)-протоколу сообщениями.

Согласно этим правилам серверы:

• прослушивают подключения, поступающие через заданные локальный IP-адрес и порт сервера из заданного диапазона клиентских IP-адресов,
• решают, как аутентифицировать отправителя и что вообще делать с сообщением, отправлять получателю или прибить на месте.

Receive connector’ы нужны исключительно для того, чтобы правильно разрулить поступающий на Hub Transport Server/Edge Transport Server SMTP-трафик. Это могут быть сообщения от соседних почтовых серверов, от почтовых серверов вне организации, от почтовых клиентов не умеющих работать с MAPI, от МФУ, от серверных приложений и т.д. и т.п.

Стоит помнить, о существенном ограничении – для каждого клиентского IP адреса должен быть активен только один receive connector.

Exchange упорно сопротивляется попыткам пересечь коннекторы.

В настройках коннектора можно разрешить принимать сообщения как от прошедших проверку (Exchange users), так и от неизвестных (Anonymous users) пользователей.

Загадочная вкладка Permission Groups.

Однако настроек релея в консоли управления больше нет. Более того, на поверку выясняется, что если прошедшие проверку пользователи (Exchange users) могут пользоваться коннектором, то им автоматически разрешён релей. А вот если галкой отмечена группа Anonymous users, то не прошедшие проверку пользователи хоть и могут отправлять почту, но только в пределах почтовой организаци.

Да и вообще всё это выглядит странно. Кто такие Exchange users и Partners, нет таких групп в AD. И если вкладка называется Permission Group, то какие «пермишены» получают эти группы если они отмечены галкой. И самый главный вопрос – как всё же разрешить анонимным пользователям отсылать сообщения наружу?

Давайте разбираться во всей этой путанице.

Начнём с того, что Exchange 2007, так же как и его предшественник, хранит большинство настроек в Active Directory (AD).  Receive connector’ы – не что иное, как объекты в AD. Их можно найти в разделе «конфигурация» с помощью оснастки adsiedit.msc из пакета support tools примерно по такому пути:

CN=SMTP Receive Connectors,CN=Protocols,CN=ExcServer1,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=ExchangeOrganizationName,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Domain,DC=ru.

Консоль управления Exchange

А это adsiedit.msc, ничего не напоминает?

Так вот, когда вы расставляете галочки на вкладке Permission Groups свойств коннектора, эти самые «пермишен группы» получают заранее предопределённый разработчиками Exchange набор разрешений на объект  AD, соответствующий этому коннектору.

Увидеть действующие на коннектор разрешения можно как из PowerShell командой Get-ReceiveConnector «Receive Connector Name» | Get-ADPermission, так и открыв вкладку Security объекта коннектора в AdsiEdit – кому как удобнее.

Само-собой, в AD нет групп Exchange users, Anonymous users и некоторых других с вкладки Permission Groups, но им сопоставлены реально существующие в AD группы.

В хелпе есть замечательная табличка под номером 6, в которой объясняется, какой Permission группе какая доменная группа безопасности соответствует, и какие разрешения она получает, если отмечена галкой на вкладке Permission Groups.

Вот наиболее интересный кусок этой таблицы:

Несмотря на некоторые неточности в написании названий групп, из таблицы становится ясно, что группе Exchange users сопоставлена группа Authenticated users (Прошедшие проверку), а группе Anonymous users – группа ANONYMOUS LOGON (Анонимный вход).

А теперь обратите внимания на отличия в разрешениях, которые получают по умолчанию Anonymous users и Exchange users.

• Accept any sender. Анонимы могут использовать в качестве адреса отправителя что угодно, а авторизованные пользователи – только свой собственный почтовый адрес. И это понятно, проверить адрес анонима невозможно, а позволять прошедшим проверку пользователям шутки ради отсылать письма гендиректору с адреса vvputin@cremlin.ru не стоит.
• Bypass anti-spam filters. Письма прошедших проверку пользователей минуют проверку спамфильтром.
• Accept any recipient. И самое важное, прошедшие проверку пользователи могут посылать письма адресатам вне организации, а анонимы не могут.

Вот почему даже если  группа Anonymous  users отмечена галкой на вкладке Permission Groups, всё равно отослать письмо наружу без авторизации не получается.

Дело за малым, добавить этой группе недостающие разрешения на коннектор. Сделать это можно как из оснастки AdsiEdit, так и из консоли PowerShell .

Причём тут есть различия. В свойствах коннектора в AdsiEdit вы увидите опцию «Submit Messages to Any Recipient» и вам надо будет просто отметить её галкой.

Ставите галку здесь и релей разрешён.

А вот с PowerShell всё сложнее. Сначала нужно выяснить, как обозначается разрешение, соответствующее видимому имени (display name)  »Submit Messages to Any Recipient». Для этого придётся изучить таблицу 4 хелпа, из которой становится ясно, что нам нужно разрешение «ms-Exch-SMTP-Accept-Any-Recipient».

Потом придётся искать, какой командой можно поменять свойства безопасности receive connectora’а.

Хотя можно поступить проще, и подглядеть готовую командную строку на текнете. Вот она:

Get-ReceiveConnector «Receive Connector Name» | Add-ADPermission -User «NT AUTHORITYANONYMOUS LOGON» -ExtendedRights «Ms-Exch-SMTP-Accept-Any-Recipient»

Ну и напоследок напрашивается вопрос . Зачем всё так усложнять вместо того, чтобы сделать одну единственную галку в настройках receive connector’а – разрешить релей для неавторизованных пользователей?

Скорее всего, разработчики хотели спрятать опасную опцию от неопытных админов. Что ж, им это удалось.