Главная Exchange/UC, Без рубрики, Новое Exchange 2010, Items Recovery
  • Восстановление удаленных и модифицированных элементов в Exchange 2010

    image В прошлой статье – «Поиск в нескольких почтовых ящиках в Exchange 2010 » мы начали обсуждать проблему контроля над оборотом конфиденциальных данных, и было рассказано про возможности Exchange 2010 в расследовании утечки информации методом поиска в почтовых ящиках пользователей. Но один лишь поиск определенных фраз не всегда решает задачу, стоящую перед сотрудниками службы внутренней безопасности. Чтобы предупредить удаление или модификацию записей в почтовых ящиках, Exchange 2010 предлагает администраторам функционал Юридического удержания (Litigation Hold) и восстановления отельных элементов (Single item recovery).

  • Главная Exchange/UC, Без рубрики, Новое Exchange 2010, Multi-Mailbox Search
    • Поиск в нескольких почтовых ящиках в Exchange 2010 (Multi-Mailbox Search)

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

    • Главная Exchange/UC, Без рубрики, Новое Exchange 2010, Personal Archive
      • Личные архивы в Exchange 2010 (Personal Archive)

        image Для того, чтобы отделить устаревшие элементы в почтовых ящиках пользователей от актуальных, ранее в MS Outlook применялся механизм архивации почты, в результате которого, все элементы с определенным сроком давности перемещались в локальный PST файл и тем самым удалялись с сервера Exchange. Этот механизм работает и сейчас, но он является устаревшим и малоэффективным, хотя бы просто потому, что локальными PST файлами уже нельзя управлять с сервера Exchange. На смену, или точнее на помощь, этому функционалу в Exchange 2010 пришла новая технология создания личного архива (Personal Archive), которая сильно заинтересовала администраторов Exchange 2010, а с учетом изменений, которые были внесены в неё в SP1, она стала очень полезной и для организации в целом.

      • Главная Exchange/UC, Без рубрики, Новое Exchange 2010, Retention policies
        • Политики хранения в Exchange 2010 (Retention policies)

          image Зачастую, в связи с нехваткой дискового пространства в системе хранения данных, администраторы Exchange 2010 вынуждены накладывать на размер почтовых ящиков пользователей достаточно жесткие квоты. Естественно, что мало кто из сотрудников задумывает о том, сколько места на полке СХД занимает их почтовый ящик и совсем редкие сотрудники готовы тратить свое время на то, чтобы регулярно наводить в нем порядок. При этом у пользователей существует задача длительного хранения определенных записей, касающихся важных бизнес процессов, а перемещение их в локальный PST файл несет с собой ряд неудобств, хорошо знакомых всем администраторам Exchange.

        • Главная Exchange/UC, Без рубрики, Новое Exchange 2010, Конкурс
          • Exchange Server 2010 Service Pack 1 Beta Overview

            Краткий обзор Exchange Server 2010 Service Pack 1 Beta

            В Service Pack 1 внесено множество улучшений и обновлений, также в SP1 входят все вышедшие обновления с момента релиза RTM версии. В данном маленьком обзоре я попытаюсь рассказать вам о некоторых новых возможностях, показать на скринах отличие и новшества, одним словом пробежимся поверхностно по нововведениям которые нас ждут в Service Pack 1.

          • Главная Security, Без рубрики, Новое Exchange 2010, Forefront Security for Exchange, TMG, Конкурс, спам
            • Защита сервера Exchange от спама и вирусов

              image Согласно последним статистическим данным, доля спама в почтовом трафике Рунета составляет 85 процентов. Спам остается серьезной интернет-­угрозой, ущерб от которой из­меряется далеко не только потраченным трафиком. И не столько им. При стремящейся к нулю стоимости трафика ущерб российских пользователей и провайдеров, по некоторым оценкам, составляет 50 млн долларов в год, но это лишь прямой ущерб. Гораздо больше — косвен­ный. Со спамом все чаще распространяются вредоносные вложения (0,5–1% всего трафика), фишинговые письма (около 1%). В результате, компании теряют не только драгоценное время сотрудников, они рискуют быть зараженными вредоносным ПО и могут, сами того не подозревая, раскрыть конфиденциальные данные в результате фишинг-атак.

            • Главная Exchange/UC, Без рубрики, Новое Exchange 2010, Конкурс
              • Построение системы высокой доступности в Exchange 2010

                cluster Много копий ломается по поводу построения систем высокой доступности. Раньше считалось, что систему высокой доступности могут позволить себе только крупные предприятия, потому что за каждую девятку после запятой надо платить в десятикратном размере. Безусловно, это правда – высокая доступность стоит денег. Но что изменилось с выходом Exchange 2010? Какие подходы к высокой доступности существуют и какие возможности у вас есть для того, чтобы построить такую систему?

                Прежде всего надо разделять высокую доступность данных и высокую доступность сервиса. Вы можете построить многомиллионную SAN и при этом иметь недоступный сервис электронной почты. Однако доступность данных является неотъемлемым условием доступности сервиса.

                Теперь, когда мы с этим определились, можно идти дальше и рассмотреть подходы к обеспечению сервиса высокой доступности Exchange 2010

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

                Какие преимущества у этого подхода? Их не так уж мало

                • Если у вас уже активно используется такая модель обеспечения отказоустойчивости, вам потребуется меньше усилий на внедрение системы и ее обслуживание
                • Стандартные преимущества серверной виртуализации – консолидация, управление и так далее
                • Экономия на серверных лицензиях
                • Удобство резервного копирования

                Но и недостатков немало

                • Единое хранилище – это единая точка отказа. Аппаратное резервирование данных стоит очень дорого. То есть цена решения сильно возрастает. Кроме того, СХД с возможностью подключения нескольких серверов стоят значительно дороже хранилищ, подключаемых к серверу напрямую (DAS)
                • Exchange ничего не знает про такую модель. Соответственно в данной модели не предусматривается отказоустойчивость на уровне данных Exchange. Например на уровне базы данных.
                • Восстановление на уровне ящиков также становится более сложным делом.
                • Немаловажный момент – в данном случае получается, что вам придется использовать разные инструменты для управления Exchange и отказоустойчивостью

                Ограничения использования виртуализации:

                  Поддерживается серверная виртуализация вендоров – участников SVVP (Server Virtualization Validation Program). Подробнее о программе можно почитать здесь
                  Не поддерживается (хотя и работает) виртуализация роли Unified Messaging. То есть нужно относиться к этому осторожно, возможны проблемы при использовании неподдерживаемой конфигурации
                  Хранилищем может быть как VHD, так и ICSCI (то есть раздел в сети). Учитывайте, что производительность  дисковой подсистемы часто является узким местом системы виртуализации

                Подытоживая, надо сказать, что такой подход приводит к сокращению затрат на программное обеспечение, но вместе с тем – к значительным затратам на аппаратное обеспечение. Кроме того, возможности такой системы ограничены. Очевидно, что в реализации таких схем заинтересованы производители аппаратного обеспечения, поскольку они стимулируют приобретение производительных серверов, СХД, оборудования для сетей хранения данных и так далее

                2. Прогрессивный подход. Не будем забывать, что мы имеем дело с Exchange 2010, у которого имеется много возможностей для построения отказоустойчивой системы.

                Для начала немного истории

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

                С появлением Exchange 2007 для отказоустойчивости на уровне данных стали использоваться технологии репликации (LCR, SCR, CCR). Репликация позволяет избавиться от единой точки отказа в виде общего хранилища. К недостаткам данной системы следует отнести то, что для разных целей используются различные технологии. Кроме того, единственная технология, обеспечивающая доступность системы при выходе из строя одного из серверов (CCR), требует построения кластера Exchange и Enterprise редакции сервера. Также следует заметить, что совмещение ролей на одном сервере в этом случае невозможно.

                В Exchange 2010 появились новые возможности по повышению доступности системы.  Давайте посмотрим – что же это за возможности

                • Database Availability Groups или группы доступности баз данных. Новая технология позволяет реализовать доступность на уровне баз данных, а не серверов. Вы можете иметь до 16 серверов в одной группе выскокой доступности, и соответственно до 16 копий одной базы данных. При этом активные копии разных баз данных могут быть расположены на разных серверах. Использование DAG позволяет решить проблему доступности данных как в основном ЦОД (на случай аппаратного сбоя), так и в резервном ЦОД (на случай катастрофы). Кроме того, DAG можно использовать как инструмент резервного копирования. Эту технологию хорошо иллюстрирует рисунок ниже

                DAG

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

                • CAS Arrays или массивы серверов клиентского доступа. В Exchange 2010 клиенты Outlook  (за исключением общих папок, от которых уже многие отказались) подключаются через RPC Client Access Service на серверах клиентского доступа. Все остальные клиенты подключались к CAS еще в версии 2007, так что теперь схема является также унифицированной. Итак, что такое CAS Array и для чего он нужен? Массив – это логическое объединение серверов клиентского доступа, которое позволяет задать единое имя массива и использовать его при подключении клиентов (например cas.contoso.com). Кроме того, вы можете использовать CAS Array в свойствах базы данных почтовых ящиков (параметр RPC Client Access Server). Далее дело за вами.
                  • Вы можете использовать балансировку в DNS (например создав 2 записи cas.contoso.com). При выходе из строя одного из серверов массива вам придется вручную удалить одну из записей из DNS (что конечно снижает доступность системы). При этом TTL записи не должен быть большим
                  • Вы можете использовать ip адрес DAG (при создании DAG указывается ip адрес), который является ресурсом кластера. При выходе из строя одного из серверов, ip адрес перейдет на другой. Но во первых данная схема не поддерживается Microsoft (хотя и работает). Подробнее об этом можно почитать здесь. А во вторых, при выходе из строя IIS, кластерный ресурс никуда не переедет и клиенты будут получать ошибку.
                  • Вы можете использовать NLB. При этом вы можете использовать как Windows NLB, так и любой другой балансировщик (аппаратный или программный). Стоит заметить, что вы не можете использовать Windows NLB и DAG на одних и тех же серверах. Если вы совмещаете роли клиентского доступа и транспорта, стоит учитывать некоторые нюансы, о которых я писал ранее. Применяйте технологию балансировки сетевой нагрузки осторожно, неправильная настройка может привести к проблемам при доступе к сервисам. Схема с DAG и NLB на рисунке нижеDAG NLB

                  Данная схема конечно же более универсальна, не требует немедленного вмешательства администратора при выходе из строя одного из серверов, но при этом она требует большего количества серверов

                • Online Mailbox Move, то есть перемещение почтового ящика в режиме online (на лету). Перемещение почтового ящика может понадобиться вам по разным причинам. Например при логическом повреждении базы данных или ее переполнении. Независимо от причины переноса, раньше приходилось ждать окна обслуживания системы или мириться с недоступностью сервиса для пользователя в процессе переноса, который мог занимать и несколько часов (в зависимости от размера ящика и количества элементов). Использование окон обслуживания приводило к удорожанию операций обслуживания системы. Конечно вы можете запланировать перенос ящиков по расписанию. Но что, если окно обслуживания у вас только одно и вам надо убедиться, что перенос выполнен успешно и иметь возможность оперативно исправить ситуацию, если что то пойдет не так? Как правило работать ночью администраторы Exchange не очень любят – сужу по собственному опыту. Поэтому предпочитают, чтобы такая работа дополнительно оплачивалась. Теперь же можно смело переносить ящики из одной базы в другую, не опасаясь жалоб пользователей. Данный принцип изображен на рисунке ниже

                Online mailbox move

                Таким образом, мы с вами рассмотрели отказоустойчивость двух ролей Exchange 2010 – почтовых ящиков и клиентского доступа. Как же насчет остальных, спросите вы? Здесь мало что меняется по сравнению с Exchange 2007 SP1. Все очень просто

                • Транспортные сервера. Здесь отказоустойчовость внутренней маршрутизации реализована встроенными способами. При наличии более одного сервера Hub Transport в сайте Active Directory вы автоматически получаете отказоустойчивую схему внутреннего транспорта. Правда если у вас используются внутренние smtp клиенты, вам потребуется приложить определенные усилия для отказоустойчивости данного сервиса. Вы также можете использовать NLB, учитывая определенные соображения, описанные мною ранее
                • Пограничные сервера. Балансировка и отказоустойчивость внешней почты обеспечивается с помощью MX записей во внешней зоне DNS (можно использовать MX записи с одинаковым или разным весом). Балансировка почты из организации осуществляется автоматически при подписывании серверов Edge на сайт Active Directory
                • Сервера Unified Messaging. Вы можете настроить ip шлюз таким образом, чтобы он ссылался более чем на один сервер UM. Таким образом будет обеспечена высокая доступность и этой роли
                  Надо заметить, что вы можете использовать технологии высокой доступности Exchange и виртуализацию. Однако совмещение технологий высокой доступности (кластера виртуализации и отказоустойчивости Exchange) не поддерживается. Выбирайте – или то, или другое

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

              • Главная Exchange/UC, Без рубрики, Новое ECP, Exchange 2010, Exchange Control Panel, Конкурс
                • Exchange Control Panel – средство управления для пользователя и администратора

                  UserFriendlyНаверняка каждый администратор мечтал облегчить свой труд, переложив часть задач на конечных пользователе. С приходом Exchange 2010 эта мечта становится ближе. В Exchange 2010 появилась обновленная консоль управления сервером – Exchange Control Panel (ECP). ECP является самостоятельным веб-сервисом и доступна либо из Outlook Web App, либо по адресу https://yourCAS/ecp. Данная консоль предназначена как для администраторов Exchange, так и для конечных пользователей, причем уровень доступа пользователей к серверу Exchange по средствам ECP легко настраивается при помощи новой системы управления ролями – Role Based Authentication Control (RBAC) (подробнее про RBAC тут и тут).

                • Главная Exchange/UC, Без рубрики, Новое Exchange 2010, Конкурс
                  • Интернет почта через Edge Transport в Exchange 2010

                    transport Недавно обнаружил, что в сети нет достаточно подробных инструкций по настройке сервера Exchange 2010 на работу с внешней почтой. В данной статье я постараюсь как можно более подробно и доступно описать процесс настройки Exchange Server 2010 для работы с внешней электронной почтой через Edge Transport Server.

                    Для того чтобы сделать действительно полный Step-by-Step Guide, давайте рассмотрим процесс настройки внешней почты с самого начала. Как правило, данный процесс состоит из трех основных этапов:

                    1. Регистрация доменного имени предприятия;
                    2. Настройка MX записи на DNS сервере, обслуживающем доменное имя;
                    3. Настройка Exchange сервера на работу с внешним доменом.

                    На первом пункте мы останавливаться не будем, т.к. у подавляющего большинства компаний уже есть свое доменное имя в сети Интернет, а те, у кого ещё нет, могут легко его купить у любого регистратора (например, RU-CENTER www.nic.ru). Зарегистрировав доменное имя, вам нужно будет найти и прописать в настройках домена, по крайней мере, два DNS сервера, которые будут его обслуживать, это также можно сделать у регистратора, либо воспользоваться бесплатными DNS-серверами (например, http://freedns.ws/ru/).

                    Первый этап пройден, теперь у провайдера нужно получить статический IP-адрес для своей организации и можно переходить ко второму этапу – настройке MX-записи на DNS сервере, обслуживающем внешний домен. Запись типа MX (Mail Exchange – почтовый сервер) определяет почтовый сервер, который будет обрабатывать почту для вашего домена.

                    Редактируем зону на DNS сервере следующим образом:

                    1. Регистрируем А-запись, например mail.firma.ru и указываем для неё внешний IP-адрес, на котором опубликован сервер Exchange;
                    2. Регистрируем MX-запись и указываем для неё имя хоста – mail.firma.ru.

                    Примечание: Если вы только что создали зону для вашего домена, то не думайте, что ping firma.ru будет сразу указывать на нужный IP, может потребовать довольно продолжительное время для того, чтобы все DNS сервера Интернета «узнали» о внесенных изменениях.

                    Чтобы проверить правильность сделанных настроек нужно воспользоваться командой nslookup следующим образом:

                    1. Проверяем MX-запись домена (к примеру, mail.ru):

                    nslookup -type=mx mail.ru

                    В результате, мы узнали, что почта на mail.ru ходит через хост mxs.mail.ru.

                    1. Проверяем IP-адрес хоста mxs.mail.ru:

                    nslookup mxs.mail.ru 8.8.8.8

                    Примечание: В данном примере мы проверяем, что «знает» о хосте mxs.mail.ru не наш локальный DNS-сервер, а DNS сервере Google`a (8.8.8.8).

                    Рис.1: Проверка MX-записи.

                    Если все настроено правильно и MX-запись вашего домена резолвится во внешний IP-адрес вашего сервера, то можно приступать непосредственно к настройке Exchange`a.

                    Публикация сервера Exchange.

                    Есть два варианта публикации сервера Exchange в сети Интернет:

                    1. Сервер с ролью Hub Transport находится в локальной сети предприятия и публикуется в Интернет через корпоративный Интернет шлюз;
                    2. На шлюзе публикуется сервер с ролью Edge Transport, который располагается в DMZ-зоне и пересылает почту на локальный Hub Transport.

                    В данной статье будет рассмотрен второй и наиболее правильный (на мой взгляд) вариант публикации сервера Exchange. Возможным минусом данной схемы является то, что вам необходимо будет приобрести дополнительную лицензию на Exchange Server 2010 и установить дополнительный Windows Server 2008.

                    Примечание: Чтобы сэкономить на лицензии Windows Server и на аппаратном обеспечении, малые и средние организации могут поставить роль Edge Transport прямо на шлюз под управлением Threat Management Gateway (TMG), такая конфигурация официально поддерживается компанией Microsoft, поэтому так мы и сделаем (на ISA-сервер поставить Edge не получится). Подробнее про установку Exchange 2010 Edge Transport на TMG можно прочитать тут – http://www.alexxhost.ru/2010/04/exchange-server-2010-edge-server.html.

                    В результате, схема нашей организации Exchange будет выглядеть следующим образом:

                    Рис.2: Схема организации Exchange.

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

                    Коммутация почты через Edge Transport

                    Перед тем как начать настройку, давайте разберемся, как будет происходить взаимодействие пограничного транспортного сервера (Edge) с локальным транспортным сервером концентратором (Hub). Данная тема подробно описана в статье MS Exchange 2007/2010 – Edge Subscription (http://www.alexxhost.ru/2011/05/ms-exchange-20072010-edge-subscription.html) и из этой статье можно сделать вывод, что основой для взаимодействия данных транспортных серверов является пограничная подписка (Edge Subscription). О том, как она делается мы и поговорим далее.

                    Настройка сетевых параметров Edge Transport сервера

                    Перед тем, как оформлять подписку нужно правильно настроить сетевые параметры на сервере с ролью Edge Transport. Напомню, что в данном сценарии он не включён в доменную структуру предприятия, находится в DMZ-зоне и расположен на одном сервере с TMG (не забудьте правильно настроить правила на TMG для отправки/получения почты). Исходя из данного сценария, рекомендуется сделать следующие настройки:

                    1. Получить у провайдера и установить на внешнем интерфейсе сервера IP-адрес (на который указывает ранее настроенная MX-запись), маску, шлюз и адреса DNS серверов провайдера;
                    2. Если у вас в DMZ-зоне нет своего DNS-сервера, то нужно прописать в файл hosts в папке \%Systemroot%\System32\Drivers\Etc сопоставление имени Hub Transport сервера с его IP-адресом, т.е. добавить в конец файла строчку вида 192.168.0.10 hub.domain.local;
                    3. На интерфейсе, смотрящем в локальную сеть предприятия установить IP-адрес и маску. Шлюз вписывать НЕ нужно;
                    4. Настроить имя и DNS-суффикс компьютера, как показано на рис.4. (потом изменить эти настройки не получится);

                    Рис.4: Настройка DNS-суффикса сервера.

                    1. На локальном DNS сервере создать А-запись, указывающую на IP-адрес Edge-сервера.

                    В результате Edge сервер должен уметь резолвить адреса Интернета и адрес сервера с ролью Hub Transport, а Hub Transport сервер, в свою очередь, должен знать, как найти Edge-сервер по его FQDN-имени (для проверки можно использовать команды ping и nslookup).

                    Оформление Edge Subscription

                    Как уже говорилось выше, компьютер, на котором установлена роль пограничного транспортного сервера, не имеет доступа к Active Directory. Все сведения о конфигурации и получателях хранятся в экземпляре служб облегченного доступа к каталогам (AD LDS) Active Directory. Данную службу заранее придется установить, как показано на рис.5.

                    Рис.5: Установка службы облегченного доступа к каталогам (AD LDS).

                    Для выполнения задач, связанных с поиском получателей, пограничному транспортному серверу требуются данные, которые находятся в Active Directory. Эти данные синхронизируются с пограничным транспортным сервером с помощью EdgeSync. EdgeSync представляет собой коллекцию процессов, выполняемых на компьютере с ролью транспортного сервера-концентратора (Hub Transport) для организации односторонней репликации сведений о получателе и конфигурации из Active Directory в AD LDS на пограничном транспортном сервере (Edge Transport).

                    После установки AD LDS и правильной настройки сетевых параметров можно приступать к конфигурированию совместной работы Edge и Hub Transport серверов. Для этого оформим Edge Subscription следующим образом:

                    1. На сервере c ролью Edge Transport выполним команду:

                    New-EdgeSubscription –FileName c:\edge_subscr.xml

                    Рис.6: Создание Edge Subscriprion.

                    1. Полученный файл edge_subscr.xml скопируем на локальный Hub Transport сервер;
                    2. Зайдем в консоль управления Exchange -> раздел Конфигурация организации -> действие New Edge Subscription

                    Рис.7: Создание Edge Subscription на сервере Hub Transport.

                    1. Выберем необходимый сайт AD и XML файл подписки. Не забудем оставить включенной галочку для автоматического создания отправляющих коннекторов.
                    2. После завершения работы мастера, будут созданы коннекторы отправки, и через некоторое время будет выполнена синхронизация с сервером Edge Transport. Чтобы не дожидаться сеанса синхронизации, его можно выполнить вручную командой:

                    Start-EdgeSynchronization

                    После успешного создания пограничной подписки, необходимо настроить сам Exchange сервер на работу с получателями.
                    Создание Accepted Domain и E-mail Address Policy
                     

                    Обслуживаемый домен (Accepted Domain) — это любое пространство имен SMTP, для которого организация Microsoft Exchange отправляет и принимает электронную почту. В связи с тем, что имя внешнего домена у нас отличается от локального (firma.ru и domain.local), необходимо на уровне организации добавить обслуживаемый домен firma.ru, с той целью, чтобы сервер Exchange смог с ним работать.

                    Для этого перейдем на уровень конфигурирования организации -> Hub Transport -> Accepted Domain.

                    Рис.11: Создание нового обслуживаемого домена.

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

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

                    E-mail Address Policy создаются на уровне организации в свойствах роли Hub Transport, выбором действия New E-mail Address Policy…

                    Рис.12: Добавление E-mail Address Policy.

                    Политику нужно применить ко всем типам получателей, без каких либо фильтров, привязать к нужному FQDN имени (как показано на рис.12) и указать в расписании немедленное выполнение (Immediately). В результате, политика адресов электронной почты (E-mail Address Policy), будучи привязанной к доверенному домену (Accepted Domain), автоматически создаст соответствующие адреса электронной почты всем получателям, к которым она применена.

                    Примечание: Создание дополнительных адресов у получателей происходит не сразу, поэтому, чтобы не ждать, вы сами можете добавить e-mail адрес в свойствах почтового ящика, либо выполнить командлет Update-EmailAddressPolicy.

                    Вы должны создать две политики – одну для домена firma.ru, другую для domain.local. В результате, каждый получатель в организации будет иметь по 2 e-mail адреса, причем в качестве обратного адреса, будет использоваться тот, который принадлежит политике с меньшим номером приоритета.

                    На этом работа с сервером Hub Transport завершена и можно переместиться на Edge Transport.

                    Переопределение адресов (Address Rewriting)

                    В связи с тем, что у нас имена внешнего домена и домена AD отличаются, нам переписывать адреса во входящих и исходящих сообщениях (*.ru <-> *.local). В Microsoft Exchange Server 2010 для этих целей есть функция переопределения адресов (Address Rewriting), которая позволяет изменять адреса отправителей и получателей во входящих и исходящих сообщения. Подробнее про данную функцию можно почитать тут – http://technet.microsoft.com/ru-ru/library/aa996806.aspx.

                    Для добавления политики переопределения адресов воспользуемся командлетом New-AddressRewriteEntry на сервере Edge Transprot:

                    New-AddressRewriteEntry –Name “Lan – Internet” –InternalAddress “domain.local” – ExternalAddress “firma.ru”

                    Рис.13: Добавление политики переопределения адресов.

                    Примечание: Данная политика применяется не сразу, для немедленной её активации можно в ручную перезапустить службу Microsoft Exchange Transport.

                    Возможные проблемы

                    На этом базовая настройка Exchange Server 2010 на работу с внешней почтой через сервер Edge Transport, расположенный в DMZ-зоне предприятия, закончена. Следующим шагом будет проверка отправки и получения этой почты. Если по каким либо причинам почта не отправляется, либо не принимается, то я посоветовал бы для начала выполнить следующие шаги:

                    1. Воспользоваться мастером Remote Connectivity Analyzer, расположенном в меню Toollbox. Данный мастер отправит вас на страничку http://testexchangeconnectivity.com/, с которой можно произвести тестирование многих сервисов Exchange`a.
                    2. Посмотреть очередь сообщений Toolbox -> Queue Viewer с той целью, чтобы определить, на какой стадии зависло письмо. Данная утилита может показать не только очередь сообщений, но также текст последних ошибок, которые произошли с конкретной очередью и заголовки писем, находящихся в ней.
                    3. Команда telnet YourServer 25 поможет вам проверить, доступны ли ваши сервера для приема почты.
                    4. Если в Queue Viewer вы обнаружили проблемы связанные с DNS, то скорее всего вы не правильно настроили сетевые параметры интерфейсов, либо неверно отредактировали файл hosts.
                    5. Также, для Edge Transport сервера можно указать адреса DNS-серверов, отличные, от тех, которые установлены на сетевых интерфейсах, делается это в меню Properties выбранного сервера – вкладки Internal DNS Lookups и External DNS Lookups.
                    6. На коннекторах необходимо проверить вкладки Network, Authentication и Permission Group.
                    7. После внесенных изменений на Hub Transport`e не забывайте выполнять синхронизацию (Start-EdgeSynchronization).
                    8. Если ничего из выше озвученного не помогает, то можно посмотреть в сторону анализа логов системы, и включить Protocol Logging на вкладке General в свойствах коннекторов. Подробнее про анализ журналов транспорта можно почитать тут – http://technet.microsoft.com/ru-ru/library/aa998617.aspx.

                    Заключение.

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

                    Алексей Богомолов

                  • Главная Exchange/UC, Без рубрики, Новое Exchange 2010, TMG, Кон, Конкурс
                    • Exchange Server 2010 Edge Server и Microsoft Threat Management Gateway

                      usb-email Для повышения уровня безопасности в среде Exchange Server 2010 вы можете использовать Edge Transport Server, установленный в демилитаризованной зоне (DMZ) либо в сети периметра. По умолчанию в Edge Transport Server включена функция фильтрации спама, а после установки Forefront Protection for Exchange на Edge Transport Server вы также включаете и антивирусную защиту.