SCOM – удаление старых групп с агентов

Агенты SCOM могут быть multihomed, иначе говоря могут отправлять отчёты нескольким серверам SCOM. При миграции SCOM это удобно: можно постепенно переносить MP пакеты и настраивать их на новом сервере Operations Manager, в то же время имея полный контроль на старой системе. Но в какой-то момент миграция заканчивается и с агентов нужно удалить старые MG группы управления.

Реклама

Один нюанс при миграции почтовых групп Exchange

При миграции учётных записей и почтовых ящиков из одного леса в другой чаще всего есть период времени, когда две организации Exchange должны сосуществовать и тесно взаимодействовать. Описанные в документации стандартные процедуры миграции содержат лишь достаточный минимум. При этом существует множество мелких полезных нюансов. Например, можно настроить надёжную передачу сообщений (Exchange – надежная доставка сообщений между лесами) задействовав Shadow Redundancy.

Ещё одна хитрость касается групп рассылки (distribution groups). При миграции почтовых групп (mail groups) пользователи и группы могут оказаться в разных лесах. При этом де-юре два наших леса это одно целое, но технически это не так. Когда пользователь из одного леса попробует отправить сообщение в группу рассылки другого леса, то получит отказ, т.к. по умолчанию отправлять в группы рассылки могут только пользователи прошедшие аутентификацию, а пользователь другого леса по умолчанию будет анонимным. Как быть?

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

Как определяется, что пользователь прошёл аутентификацию? В рамках одного леса сервер, к которому происходит первичное подключение пользователя производит его аутентификацию и выставляет соответствующий флаг. Когда письмо передаётся на другой сервер, то аутентификация пользователя уже не производится: письмо просто передаётся с флагом, и принимающий сервер доверяет этой информации. Ключ здесь – «доверяет». Все Exchange серверы в одном лесу доверяют друг другу: передают и получают служебную информацию и доверяют ей, в том числе сведениям об аутентификации. Вопрос в том, как настроить доверие между Exchange серверами разных лесов. Возможно ли это? Да, это возможно. Exchange серверы взаимодействуют друг с другом через коннекторы, и именно свойства этих коннекторов определяют механизмы аутентификации и уровень безопасности (доверия) между серверами. Так коннектор принимающий почту из Интернета не доверяет внешним серверам и не принимает от них никакой служебной информации, а коннектор между Exchange серверами одного леса полностью доверяет служебной информации от соседних серверов его почтовой организации. Регулируется это выставлением прав (permissions) на коннекторах.

Фактически для решения нашей задачи в каждом лесу нужно создать внутренний (Internal) принимающий коннектор и указать в нем группы прав Exchange Servers и LegacyExchange Servers, а также аутентификацию External Secured. Безусловно нужно защититься указав адрес передающего сервера/серверов другого леса. Аналогично поступаем для передающего коннектора. Всё! Теперь пользователи наших лесов смогут отправлять сообщения в группы рассылки.

Полезные ссылки:

1. How to Create a receive connector to authorize Cross forest emails in Exchange 2013
2. Receive connector permissions
3. Allowing application servers to relay off Exchange Server 2007

Exchange Server и SIDHistory

При миграции из одного леса в другой традиционно используется специальный инструмент – ADMT. Так как ресурсы, к которым имеют доступ пользователи мигрируются на втором этапе после миграции учётных записей, то для сохранения доступа к ещё несмигрированным ресурсам используется SIDHistory. ADMT имеет возможности для миграции некоторых видов ресурсов: миграция заключается в замене старых SID на новые, например, при доступе к файлам.

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