We rise up for the things we believe in over and over again
Показанное на скрине выше - не самая типичная, но тем не менее рабочая конфигурация System Center Operations Manager. Суть ее в том, что одна консоль SCOM наблюдает за узлами из двух доменов. Но что на скрине не показано, так это то, что это не просто два разных домена, это абсолютно разных леса без всяких доверительных отношений между ними. В случае одного леса SCOM настраивается буквально в пару кликов. В случае безтрастовых лесов - все несколько интереснее.
Суть в следующем. Основной управляющий сервер находится в домене Hive.com (говорящее название, да). Подключение к нему агентов - штатная процедура, которую можно выполнить прямо из консоли SCOM. Задача - подключить к этой же консоли агенты из соседнего домена Umbrella.corp (еще более говорящее название
). Задачу можно несколько упростить - развернуть в домене Umbrella.corp сервер-шлюз, через который будет строиться все общение агентов Umbrella с сервером SCOM из Hive. И этот шлюз, действительно, очень сильно упрощает задачу. И вот почему:1. Если между лесами куча файрволлов - на них требуется открыть только один порт в каждую сторону для только двух серверов: для управляющего и для шлюзового. А не для каждого агента.
2. Если между доменами или лесами нет трастов, нужно как-то обеспечить защищенный канал связи для агентов и управляющего сервера. И единственный вариант - сертификаты. В случае прямого подключения агентов стороннего домена к управляющему серверу придется выпускать сертификат для КАЖДОГО агента отдельно. Это не есть хорошо.
Таким образом получаем следующую раскладку. Агенты из домена Hive.com связываются с управляющим сервером посредством Kerberos, с ними все хорошо. Агенты из домена Umbrella.corp будут связываться с сервером-шлюзом (в дальнейшем просто шлюз) так же через Kerberos, потому что будут в одном домене с ним. А вот уже шлюз будет общаться с управляющим сервером, предоставляя последнему свой сертификат, который нужно будет выпустить заранее.
Собственно, инструкций, как настроить сертификацию и связь в такой раскладке, довольно много. Но практически все они спотыкаются на одном шаге. И имя ему - MOMCertImport.exe. Все дело в том, что мало просто выпустить сертификат для обоих серверов, что управляющего, что шлюза. Необходимо при помощи указанной утилиты этот сертификат импортировать ПРЯМО В SCOM. Сделать это надо на обоих серверах. И именно этот момент везде описан по-разному. Один из вариантов инструкции предполагает импорт сертификата только на стороне шлюза, другой - только на стороне управляющего сервера. Третий - предполагает импорт сертификатов на обеих сторонах, но меняет сертификаты местами (то есть на стороне управляющего сервера мы импортируем сертификат шлюза и наоборот). Ни один из этих вариантов не является правильным. Вся раскладка заработала только после того, как было выполнено следующее:
На стороне управляющего сервера:
MOMCertImport.exe "c:\users\admin\Downloads\spb-01-scom1.pfx" - то есть импортируем в SCOM сертификат управляющего сервера
На стороне шлюза:
MOMCertImport.exe "c:\users\admin\Downloads\geo-01-scom1.pfx" - импортируем в SCOM сертификат шлюза.
Вот тогда оно работает.
Однако, вопросов в сторону MS это не снимает. Ладно, возня с сертификатами - я еще пойму, других методов аутентификации без трастов еще не придумали. Но неужели нельзя было как-то нагляднее сделать процедуру импорта сертификатов, вместо того, чтобы возиться с этой несчастной утилитой. А про создание объекта шлюза в списке устройств SCOM я вообще молчу. В гуях этого ничего нет. Все через "сторонее" ПО. Но тогда хотя бы ставьте его вместе с самим SCOM. Почему несчастный комплект Support Tools нужно ставить отдельно, а применительно к Microsoft.EnterpriseManagement.GatewayApprovalTool.exe еще и поди узнай, в какой каталог его нужно скопировать, чтобы он просто заработал (его нужно распаковывать в C:\Program Files\Microsoft System Center 2012 R2\Operations Manager\Setup).
Короче говоря, много нервных клеток было сожжено в процессе. Очень много. И ведь можно было бы без этого обойтись...
