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 нам тут не помощник: этот инструмент не имеет средств для исправления нюансов связанных с особенностями доступа к почтовым ящикам. Читать далее

Миграция почтового ящика побитого Яблоком


При миграции почтовых ящиков в новый лес наткнулся на такую ситуацию:

Get-MailboxFolderStatistics -Identity iqv -FolderScope RecoverableItems | Format-Table Name,FolderAndSubfolderSize,ItemsInFolderAndSubfolders -Auto

Name FolderAndSubfolderSize ItemsInFolderAndSubfolders

—- ———————- —————————

Recoverable Items 10.23 GB (10,981,634,268 bytes) 2549585

Deletions 4.273 GB (4,587,644,217 bytes) 518278

Purges 0 B (0 bytes) 0

Versions 0 B (0 bytes) 0

Да, число элементов в папке Recoverable Items более полутора миллионов!

В папке Deletions тоже немало – около полумиллиона.

Во время перемещения этого почтового ящика процент добежал до 50% и встал: копирование двух миллионов элементов обещало занять более суток.

Миграцию почтового ящика пришлось остановить и начать чистку от мусора.

Очистка папки Deletions успешно была выполнена командлетом:

Search-Mailbox -Identity iqv -SearchDumpsterOnly -DeleteContent

Но тем не менее в папке Recoverable Items все еще оставалось огромное количество элементов, которые никак не хотели удаляться. После выполнения:

$a=New-MailboxRepairRequest -Mailbox iqv –CorruptionType SearchFolder,AggregateCounts,ProvisionedFolder,FolderView

число элементов в папке Recoverable Items уменьшилось до 1.7 миллиона. Очень неплохо! Но что делать с остальным мусором? Пришлось пускать в ход тяжёлую артиллерию – утилиту MFCMAPI.

Когда я нашел и открыл папку Recoverable Items в проблемном почтовом ящике, то очень скоро убедился, что не все так просто: элементы подгружались в окно непрерывно, и это обещало занять не менее часа времени. Подсказка внизу окна предлагала нажать Esc для остановки загрузки элементов. Но MFCMAPI не реагировала на эту клавишу, упорно продолжая загрузку элементов. Что поделаешь, если программисты так реализовали цикл загрузки: вряд ли они тестировали эту функцию более чем на нескольких сотнях элементах. Когда счетчик загрузки добежал до 800 тысяч элементов, MFCMAPI выдала ошибку «Мало памяти», закрыла окно загрузки и перестала реагировать адекватно на команды. Пришлось ее перезапустить, и искать выход из ситуации. Решение оказалось простым: раз программа отображает каждый элемент в окне, то логично сделать окно загрузки элементов как можно меньше. Когда я уменьшил окно загрузки элементов до минимально размера, то MFCMAPI стала не только быстрее загружать элементы, но и реагировать на клавишу Esc, останавливая загрузку и давая тем самым выбрать все загруженные элементы и удалить их навсегда.

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

Остается отметить, что проблемный почтовый ящик был забит мусором от клиента iPad: помните проблему с его почтовым клиентом?

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

Dealing with the ActiveSync bug on iDevices with Exchange 2010

Clean Up the Recoverable Items Folder

MFCMAPI home site

Миграция Retention Policy между лесами


В предыдущей статье я описал миграцию Retention Policy Tags в другой лес (другую организацию Exchange) – Миграция RetentionPolicyTagsмежду лесами. Теперь очередь за миграцией политик и привязкой их к почтовым ящикам. Такая задача возникает при миграции учетных записей пользователей и их почтовых ящиков в новый лес.

Читать далее

Миграция Retention Policy Tags между лесами


Задача: смигрироватьсExchange 2010 наExchange 2013 вдругомлесуRetention Policy Tags

Если тегов несколько работу можно выполнить с помощью GUI. Но если тегов много, то поможет Powershell.

Читать далее

Миграция с WSUS на SCCM


Установка обновлений через WSUS достаточна проста. Если тщательно проработать группы и правила автоматического одобрения, то установка обновлений становится совсем не обременительной для администраторов. Более того, можно использовать скрипты для управления установкой обновлений, чтобы еще более повысить гибкость и удобство. Для небольших компаний такой подход идеальный.

Если же инфраструктура усложняется и растет в объемах, появляются многочисленные группы серверов и пользователей требующих особого подхода, то гибкости WSUS может уже не хватать. Обычно в такой инфраструктуре появляется Configuration Manager, и через какое-то время все процессы управления начинают тяготеть к SCCM. В том числе это касается установки обновлений.

И тут начинается ломка сознания: как жалко ломать настроенный и отлаженный механизм WSUS и заново отстраивать новый в SCCM! А сколько сил и времени это займет!

Оказывается, не все так ужасно – все уже написано до нас! Мне попалась статья Migrating from WSUS to Configuration Manager, в которой описаны скрипты миграции. Первый скрипт выгружает из WSUS список групп и одобренных для них обновлений, а второй импортирует эту информацию в SCCM, создавая в нем группы и включая в них нужные обновления. Эти скрипты не сделают всю работу за нас, но саму черновую да! Администратору остается (всего лишь!) продумать и реализовать процедуры установки обновлений, используя все расширенные возможности SCCM, которых нет в WSUS.