Группы рассылки Exchange – проблема нескольких OU

Время от времени встречается вопрос: как сделать динамическую группу рассылки, которая включает в себя объекты из нескольких OU?

Иначе говоря нужно составить фильтр LDAP или OPATH, который фильтрует по OU.

Но у объектов в Active Directory нет такого атрибута OU. Есть только атрибут DN. И проблема в том, что фильтры по DN не работают.

Реклама

Exchange Server 2013, Shadow Redundancy и сетевой трафик

Exchange Server 2013, внося множество усовершенствований в технологии Exchange прошлых лет, добавляет некоторые подводные камни, которые могут усложнить как миграцию на него, так и его эксплуатацию. Рассмотрим один такой подводный камушек, который связан с теневой надежностью (Shadow Redundancy).

Сценарий выглядит так. Есть два датацентра (в терминах Exchange) – головной офис и крупный филиал. Для обеспечения автономности работы филиала в нем размещены локальные домен-контроллеры и серверы Exchange. Каждый офис это сайт Active Directory. Для обеспечения надежности в филиале поднята DAG с двумя локальными копиями почтовой базы и одной копией в головном офисе.

Теперь рассмотрим расчет пропускной способности канала между офисами. Если это выделенный канал, то его стоимость очень высокая, и нужно арендовать минимальную полосу, чтобы минимизировать затраты. Во-первых, берем потребности AD. (При аккуратной оптимизации репликации сайтов, DFS и групповых политик можно уложиться минимум в 128 Кбит/с.) При переходе от Exchange 2010 к Exchange 2013 этот трафик не меняется при правильном построении сайтов AD. Затем берем внутренний почтовый трафик и трафик репликации DAG. Если вы взяли логи Exchange 2010 и оценили этот трафик для расчета канала (или взяли фактический трафик Exchange 2010), то эти расчеты окажутся заниженными для рассмотренного нами сценария – вот он подводный камень!

Поясню, как это работает в Exchange 2013. Как только сообщение приходит на почтовый сервер филиала, механизм Shadow Redundancy сразу же создает резервную копию сообщения на другом почтовом сервере. Только после этого сообщение обрабатывается и записывается в активную копию почтовой базы. При успехе этой операции сообщение перемещается из Shadow Redundancy в Safety Net (ранее Dumpster) на обоих серверах. Затем сообщение реплицируется в пассивные копии почтовых баз входящих в DAG филиала.

Т.к. в головном офисе по нашему сценарию есть одна пассивная копия почтовой базы филиала, то в нее при репликации DAG копируется одна копия сообщения. Но как мы помним, Shadow Redundancy тоже делает одну копию сообщения и делает он ее туда же – на сервер в удаленном сайте! Таким образом Exchange 2013 копирует сообщение на удаленный сайт не один раз как Exchange 2010, а заведомо два раза. Это означает, что этот сетевой трафик увеличивается в двое (общий не обязательно в двое). Такова плата за надежность и безотказность.

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

При отправке внутреннего сообщения из филиала в головной офис ситуация аналогичная.

Таким образом Shadow Redundancy в Exchange 2013 при наличии DAG распределенной между сайтами AD увеличивает почтовый трафик между сайтами.

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

Что делать, если существующий между филиалами канал не способен пропускать увеличенный почтовый трафик? Разработчики дают нам возможность понизить надежность DAG и указать Shadow Redundancy создавать не удаленную, а локальную копию сообщения (выбирается сервер в локальном сайте). Делается это с помощью параметра ShadowMessagePreferenceSetting командлета Set-TransportConfig. По умолчанию значение параметра равно PreferRemote. Для выбора сервера в локальном сайте нужно значение LocalOnly.

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

1. Shadow Redundancy http://technet.microsoft.com/en-us/library/dd351027(v=exchg.150).aspx

2. Safety Net http://technet.microsoft.com/en-us/library/jj657495.aspx

Проблемы Exchange c Windows Management Framework 3.0 (PowerShell 3.0)

Раз уж есть грабли, то надо на них обязательно наступить. Или не обязательно? Решать вам. Для начала вот вам описание «граблей» связанных с установкой WMF 3.0 на серверы с установленным Exchange 2007/2010 или на рабочие станции с оснастками управления.