Exchange в вопросах и ответах: Автоматизация и консолидация

Существует много способов решения проблем автоматизации, общих почтовых ящиков и консолидации в Exchange.

Хенрик Уолтер

Приглашенный специалист — Джордж Хинтерхофер.

Надежность сайта с соединителями отправки

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

Ответ В соединитель отправки можно легко добавить множественные промежуточные узлы и Exchange будет просто циклически обращаться к ним. Но при этом удовлетворяется только одно требование — по избыточности между сайтами. Трафик все равно будет распределяться равномерно, если все сайты находятся в рабочем состоянии, а это будет излишне нагружать линии связи между сайтами.

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

Для решения этой проблемы нужно применить хитрый прием, о котором рассказывали на курсах для Microsoft Certified Master. Он основывается на том малоизвестном факте, что промежуточные узлы в Exchange (версий 2003, 2007 и 2010) принимают не только DNS-записи A и разрешенные IP-адреса, но и записи MX (Mail Exchanger). Однако записям MX можно назначать приоритеты.

Прежде всего убедитесь, что на месте все DNS-записи A для ваших шлюзов почты. Затем создайте произвольное имя для создаваемой записи MX в DNS В данном примере я выбрал имя allsmarthosts.forest1.local. Создайте необходимые записи MX в DNS.

Как и при простой машрутизации с использованием MX сервер Exchange использует запись MX с большим приоретитом при условии, что такая запись (или записи) существует. Теперь осталось только переконфигурировать соединитель отправки Exchange для обращения к allsmarthosts.forest1.local как к единственному промежуточному узлу.

В этом случае Exchange будет использовать узел primary.forest1.local для исходящей почты пока тот доступен. Если этот узел станет недоступным, Exchange начнет использовать в качестве промежуточного узла secondary.forest1.local. Вот как можно решить проблему, применив несколько приемов работы с DNS.

Совместное использование несколькими организациями

Вопрос Мы недавно приобрели компанию, в которой, как и у нас, используется Exchange 2010. Мы планируем консолидировать обе среды, но сейчас нужно срочно обеспечить совместное использование календаря (и не только информации о доступности) обеими организациями. Похоже, что по этой теме информации немного. Не могли бы вы рассказать, как работает совместное использование календаря в режиме 1:1, и что нужно для этого сделать?

Ответ Эта функциональность была разработана для Office 365 для облегчения сосуществования в локальной среде. Ее можно также использовать в вашей ситуации.  В обеих организациях должен использоваться Exchange 2010. Клиенты могут представлять собой Outlook Web Access 2010 (OWA) или Outlook 2010.

В этом случае клиент, предоставляющий календарь в общий доступ, может определить, сколько информации (только сведения о доступности, сведения о доступности и местоположение, сведения о доступности и все подробности) предоставляется в такой доступ. Так как же это работает? С технической точки зрения ваш собственный сервер почтовых ящиков создаст копию или кеш общего календаря и отобразит его в Outlook или OWA. Это одна из самых главных трудностей. Ваши серверы почтовых ящиков должны иметь доступ к Интернету, так как только они запрашивают элементы общего календаря.

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

Для настройки этой возможности нужно сконфигурировать федерацию со шлюзом Microsoft Federation Gateway (MFG). Нужно также убедиться в том, что если в организации используется необновленная версия Exchange, ее нужно обновить как минимум до первого пакета исправлений, чтобы у вас были одинаковые экземпляры MFG. В этом случае изменений организации не потребуется. (Они нужны были бы при совместном использовании информации о доступности, но в данном случае вам требуется совместное использование всего календаря.)

Для организации федерации своей организации с MFG просто следуйте инструкциям, приведенным на следующей странице: https://technet.microsoft.com/en-us/library/dd335198.aspx. Вам потребуется опубликовать дополнительные записи TXT в DNS, чтобы подтвердить права на домен. Выполните это в обоих сайтах, для которых надо организовать федерацию, и добавьте нужные домены. Далее желательно настроить политики совместного использования на совместное использование всей информации календарей.

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

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

Сначала предоставьте календарь в общий доступ. После этого получатель может добавить этот общий календарь. Вскоре ваш календарь появится в списке общих элементов.

При устранении неполадок лучше всего начинать с реального URL-адреса. Он хранится в почтовом ящике получателя, а получить его можно средствами MFCMAPI. Убедитесь, что URL-адрес доступен с ваших локальных серверов почтовых ящиков.

Агенты расширения командлетов

Вопрос Мы хотим, чтобы в каждом создаваемом почтовом ящике по умолчанию отключалась служба. Доступ должен предоставляться только по запросу. Однако при создании нового почтового ящика с помощью командлета New-Mailbox нет возможности отключить ActiveSync. Нам дополнительно приходится вручную выполнять команду Set-CASMailbox –ActiveSyncEnabled:$false. Люди иногда забывают об этой команде и ActiveSync остается включенным и доступным тем, у кого доступа быть не должно. Не знаете, можно ли каким-то образом глобально отключить эту функциональность или может есть какое-то другое более удобное решение?

Ответ Этот вопрос возникает довольно часто. К сожалению, ответ на этот вопрос отрицательный. Нет возможности изменить эти значения по умолчанию (по умолчанию Web Access и ActiveSync включены, Litigation отключено и т.п.). Exchange всегда задает этим параметрам значения, жестко прописанные в коде.

К счастью, есть возможность обойти это ограничение — с помощью агентов расширения командлетов. Задача агента расширения командлетов (еще их называют агентами сценариев — прослушивать все выполняемые в Exchange команды). Соответствующим образом сконфигурированный агент выполняет команду или изменяет данные в случае выполнения определенного командлета.

Вот пример, соответствующий вашему вопросу:

New-Mailbox -Name "Georg Hinterhofer" -Database DB1 -UserPrincipalName hiho22@hihosoft.local –Password $p.password

Здесь создается пользователь со всеми значениями, заданными по умолчанию. Агент расширения комаднлетов обнаруживает выполнение командлета New-Mailbox и автоматически запускает второй командлет (его здесь не видно). Но выполняет команду Set-CASMailbox –identity hiho22 –ActiveSyncEnabled:$false, настраивая параметры в соответствии с вашими предпочтениями.

Но как создать и запустить агент? Прежде всего, определите, какое действие должно инициаторовать агент и какое действие должен выполнять агент. В данном случае все просто. Каждый раз при выполнении командлета New-Mailbox нужно выполнят команду Set-CASMailbox, которая отключает ActiveSync.

Теперь можно, собственно, приступить к кодированию. Найдите и скопируйте файл по имени scriptingagentconfig.xml.sample в папке %ExchangeInstallPath%\bin\CmdletExtensionAgents. Измените имя файла на scriptingagentconfig.xml и откройте его в своем любимом редакторе. Например, можно поменять содержимое файла на это:

<?xml version="1.0" encoding="utf-8" ?> <Configuration version="1.0"> <Feature Name="DisableEASonNewlyCreatedMailboxes" Cmdlets="new-mailbox"> <ApiCall Name="OnComplete"> if ($succeeded) { $dc = (Get-ADServerSettings).DefaultPreferredDomaincontrollers $user = $provisioninghandler.UserSpecifiedParameters["UserPrincipalName"] set-casmailbox $user -ActiveSyncEnabled:$false -DomainController $dc.item(0) } </ApiCall> </Feature> </Configuration>

Сохраните измененный файл. Если у вас больше одного Exchange-сервера, полученный файл нужно скопировать на каждый из этих серверов. Также обратите внимание на то, как Get-ADServerSettings определяет предпочтительный контроллер домена, чтобы избежать ошибок, возможных из-за задержки репликации Active Directory. Эту часть можно опустить, если в вашей среде только один контроллер домена.

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

Enable-CmdletExtensionAgent "Scripting Agent"

Проверьте результат, и если все нормально, все готово. Теперь при каждом запуске командлета New-Mailbox служба ActiveSync будет отключаться автоматически.