Внимание - без рута это не работает!
Это касается по большей части стандартных прошивок. Во многих "кастомных" все "лишние программы" просто вычищены изначально.
Как я уже сказал ранее, я по возможности стараюсь избегать "инвазивных" методов, типа установок "кастомных прошивок", или замены ядра. Да и вариант со "свапом на SD карточку" не только требует замены ядра, но еще и чреват ускоренным "отходом карточки в небытие", вместе со всем что на ней, что тоже "не совсем рулез" :) Но если не хватает ОЗУ, то кое что можно сделать и без вышеописанных "радикальных методов". Поможет нам та же программа System Tuner (https://play.google.com/store/apps/details?id=ccc71.pmw&hl=ru) которую мы использовали в предидущий раз для переноса на SD карточку "непереносимых" программ, и длля освобождения места во внутренней памяти. В ней же есть возможность "отключить автозапуск" любой программы. Для этого заходим в пункт "Startups". Все программы, которые "автоматически запускаются при старте системы" отмечены галочками. Просмотрев что же там у нас "автозапускается", мы обнаружим огромное количество программ, как системных так и нами установленных, которые стоят на "автозапуск", и каждый раз запускаются, тормозя перезагрузку и занимая место в RAM, которого обычно, если у Вас ОЗУ метров 512 всегда и катастрофически не хватает. Просматриваем, и снимаем галочки "автозапуска" с тех, автозапуск которых нам не нужен или вообще бессмысленен, и сделан авторами просто чтобы программа" докладывалась" автору что "она установлена и используется". Главное не трогайте системные программы, типа "Система Android", "Графический интерфейс системы", "телефон" итд - ато последствия могут быть непредсказуемыми, вплоть до "умирания тела". Но в общем, там половину если не больше можно спокойно убрать из автозапуска, и весь "побочный эффект" будет - ускорение старта телефона и меньше занятой памяти.

А теперь о лишних "системных" програмах.
Их можно тоже убрать из "автозапуска" но это не поможет, они еще стартуют и по "событиям", и поэтому все равно запустятся. Поэтому возвращаемся в главное меню, и нажимаем пункт "System".
После чего, выбираем "лишние", по одной, и выбрав, нажимаем кнопоку "Freeze" внизу. И так для каждой. Вот перечень программ, которые вообще не влияют на работу, и некоторые нужны для слежения за юзером, некоторые для функций, которые Вы скорее всего никогда в жизни использовать не будете:
"Лишние" системные программы, кушающие ОЗУ:
Atci_Service - Отключайте спокойно, никаких побочных эффектов вообще не заметите. Она используется для тестирования Fm радио из инженерного меню. Смысла в ее "постоянном висении в памяти" - вообще никакого.
Голосовой поиск - если Вы им не пользуетесь - отключайте - это сразу несколько метров, и он имеет привычку висеть в памяти, пользуетесь Вы им или нет.
Живые обои Android - по вкусу. Вообще они и батарею дополнительно жрут и несколько метров памяти, и имеют привычку занимать ОЗУ, даже если Вы их реально не используете. Замораживаем.
Каталог живых обоев - если не нужны "живые обои", то и он тоже - замораживаем.
Настройка Google Patrner - Большинство людей в нете, сходится на том, что это просто программа-шпион, для сбора статистики, а также для установки программ на Ваш Андроид без Вашего ведома, и для Вас собсно бесполезна, если Вы не любите чтобы за Вами лишний раз следили, и не готовы платить за это удовольствие потерей места в ОЗУ и доп разрядом батареи:)
Отзывы о Маркете - Зачем она вооще нужна для меня загадка. Можно спокойно отключать - на реальной фукнциональности не скажется.
Поиск - Вы часто пользуетесь строкой поиска в верху экрана? Я обычно вызываю браузер, чтобы что то поискать в гогл. И не вижу никакого смысла в том, чтобы тратилось несколкьо метров ОЗУ за сомнительное удовольствие наблюдать занимающую место на десктопе строку поиска, которой не пользуюсь:) - Freeze:) После этого можете убрать с экрана и гаджет "поиска" и поместить на это место что нибудь более полезное.
Службы Exchange - Нужны толкьо тем, кто забирает почту с Microsoft Exchange, используя "нативный" почтовый клиент. Если Вы пользуетесь стандартными SMTP/POP3/IMAP они Вам вообще не нужны, но место в памяти "жруть справно" - Freeze.
Фейсконтроль - Если Вы не используете авторизацию по своему фотоснимку (следует заметить достаточно ненадежную) - freeze. Потому что память она время от времени "кушает" - используете Вы ее или нет.
MobileLog - Пишет логи работы радиомодуля (GSM, bluetooth и т.д) на sd-карту, в
папку /mnt/sdcard/mtklog/mobilelog, вызывается из инженерного меню. Можно спокойно замораживать, если Вы не используете логи, записанные на SD карту. Работе LogCat ее заморозка никак не мешает.
Поставщик средств поиска. Для чего она нужна, я толком не нашел описаний. Предполагаю что связана с возможностью "поиска прямо с десктопа Андроид", который для меня лично бесполещен, и платить за то что он занимает место на экране лишними несколькими десятками метров ОЗУ... Кое кто пишет что она-же используется "для поиска установленных программ". Где, если после ее заморозки и маркет продолжает работать нормально, и списки установленных программ в настройках отображаются? В общем я ее заморозил - побочных эффектов пока не заметил.

Условно-ненужные.
Сервисы Google Play - Реально я заметил только одну программу на которую они влияют - Google Keep. Если Вы ее не используете - можете "замораживать". В памяти они висят постоянно, не зависимо от использования или не использования. А если Вы всеже найдете программу, которой они нужны, то при ее запуске увидите ошибку и предложение "установить сервисы google play" - тогда просто идете и "размораживаете их".

Заодно я обычно "замораживаю" и часть других программ, например тот же, рекомендованный мною "Lucky Patcher" - размораживая" только если мне его нужно использовать, и потом замораживая вновь - если этого не делать он будет "атвозапускаться" и висеть в памяти (проверяет обновления). Так же можно "замораживать" и антивирус, если Вы не ставите никаких программ, и "размораживать" его когда собираетесь что то ставить.

Все "замороженные" программы Вы можете в любой момент "разморозить", нажав кнопку "Boil", которая появится в меню на том месте где была "Freeze ", после того как программа была "заморожена" - действие полностью "обратимо". Но естественно, не замораживайте ядро системы и системные приложения, на счет которых Вы не уверены насколько они влияют на работоспособность, чтобы не получить "кирпич для перепрошивки".

Суммарно так мы освободим 40-100 метров ОЗУ.

Мало? Нужно еще освободить памяти ОЗУ? Продолжение смотрите здесь.

Разберитесь, что такое сервер Microsoft Exchange server, как настроить его и как с ним работать. Это сервис для пересылки электронных писем. Есть поддержка клиентских протоколов вроде POP3, SMTP, MAPI и IMAP. Интегрируется с Outlook . Эту программу используют, если нужно предоставить доступ к mail сразу нескольким пользователям. Она незаменима в организациях с большим количеством сотрудников. Но и в маленьких фирмах она пригодится.

Сервер позволяет совместно работать с контактами, задачами и другими сервисами mail. Можно создать почту с собственным доменом.

У Exchange server (ES) много версий, которые выпущены в разное время. В каждую из них Microsoft добавлял новые функции. Или удалял. Например, из программы 2003 года разработчики убрали поддержку мгновенных сообщений. Далее будет рассмотрена именно эта утилита. Настройка других её версий функционально ничем не отличается. Да и можно узнать, как поднять схему Exchange 2003 до актуальной.

В программе доступна работа с голосовой почтой, факсами, мобильными устройствами. На почтовый сервер можно выйти с любого компьютера, если есть подключение к интернету . Поддержка HTTP, POP3, SMTP, LDAP, IMAP 4, MAPI.

ES может взаимодействовать с другими утилитами компании Microsoft: ActiveSync, Windows Mail и Outlook. Работа утилиты тесно связана с компонентом Active Directory (AD).

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

• 64-разрядная архитектура.
• 10 Гигабайт оперативной памяти. Прибавлять по 20 Мегабайт для каждого нового пользователя.
• 30 Гигабайт свободного места в винчестере.
• 200 Мегабайт памяти на системном диске.

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

Установка

Чтобы установить и настроить утилиту, вначале надо загрузить ряд компонентов и сервисов.

• WWW Publishing.
• SMTP и NNTP.
• NET Framework
• Windows 2003 Support Tools (цифры зависят от версии ES).
• Средства администрирования.

Если у вас есть диск или другой накопитель с Exchange server, запустите установку с него. Или найдите программу на сайте microsoft.com.

Официальный сайт Microsoft

1. Введите запрос в строку поиска (она справа сверху).
2. Перейдите в раздел «Загрузки».
3. Откройте страницу с нужной вам версией.
4. Нажмите кнопку «Скачать».
5. Откройте загруженный файл. Будут извлечены данные.

Перед тем как устанавливать ES сервер, надо подготовить AD. В Active Directory находится большая часть информации, которая связана с Exchange server 2003: контакты, учётные записи, конфигурации, атрибуты.

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

• В распакованной папке с ES найдите файл setup.exe.
• Откройте командную строку Windows.
• Введите команду «[Путь к файлу Setup] /PrepareSchema /IAcceptExchangeServerLicenseTerms».

• Подождите, пока директория применит нужные параметры.
• Далее надо задать название организации для Microsoft Exchange server 2003. Напишите «[Путь к файлу Setup] /PrepareAD /OrganizationName:»Название организации» /IAcceptExchangeServerLicenseTerms». В имени компании могут быть только латинские символы, цифры, тире. Его нельзя изменить после установки.

• Снова подождите.

Теперь подготовьте домены.

1. Введите команду «[Путь к setup] /PrepareAllDomains /IAcceptExchangeServerLicenseTerms».
2. Для выбора домена - «[Путь к setup] /PrepareDomain: /IAcceptExchangeServerLicenseTerms»

Инсталлятор делает всё это автоматически.

Чтобы увидеть результат работы, зайдите в редактор AD Service Interfaces. Найдите «Schema» («Схема»). Выберите свойство «rangeUpper». В «ms-Ex-Verision-Pt» должно быть написано значение для Microsoft Exchange server (это не версия программы 2003; значения можно узнать на официальном сайте Майкрософт).

Создание доменов

Чтобы ES принимал и отправлял электронные письма по протоколам POP3, SMTP, IMAP, добавлял пользователей и работал, надо сделать домен.

1. Зайдите в консоль программы.
2. Перейдите к пункту «Конфигурация организации».
3. Откройте «Транспортный сервер-концентратор».
4. Раздел «Обслуживаемые домены».
5. Кнопка «Создать домен».
6. В открывшемся окне напишите название. Это может быть название вашей компании, направление деятельности. Или всё вместе в любых сочетаниях.
7. Отметьте опцию «Уполномоченный домен».
8. Откройте вкладку «Политики адресов».
9. Нажмите «Создать политику» (в списке «Действия»).
10. Напишите её название.
11. Добавьте контейнер «Users». Для этого кликните на кнопку «Обзор» и укажите к нему путь.
12. Нажимайте «Далее», пока не появится окно с настройкой правил для адресов почты.
13. Отметьте «Выбрать принятый домен».
14. Кнопка «Обзор».
15. Укажите только что сделанный вами домен.
16. Подтвердите.

Теперь Exchange server 2003 может работать с внутренней электронной корреспонденцией. То есть этот тип ресурса позволяет сотрудникам отправлять письма друг другу. Чтобы задать приём и отправку электронных писем по протоколам IMAP, POP3 и SMTP:

1. Зайдите в «Транспортный сервер-концентратор».
2. «Соединители отправки».
3. В разделе «Действия» выберите «Создать соединитель».
4. Напишите название коннектора.
5. Введите имя вашего домена.
6. Нажмите «Далее».
7. В следующем меню нужно указать, на какие адреса будет отправляться почта. Если надо, чтобы Microsoft server 2003 работал со всеми доменами, напишите в поле «Адресное пространство» символ «*» (звёздочка).
8. Снова «Далее».
9. Выберите опцию «Использовать MX-записи DNS для автоматической маршрутизации».
10. Ещё несколько раз нажмите «Далее». И кликните «Создать».

Затем надо настроить приём электронной корреспонденции из внешних источников:

1. Перейдите в «Настройки серверов».
2. Откройте «Транспортный концентратор».
3. Там только два коннектора: «Default» («По умолчанию») и «Client» («Клиентский»). Первый используется для работы почти со всеми доменами, второй - для пользователей Outlook. Там заблокировано получение сообщений из источников, которые не прошли аутентификацию. А это почти все ресурсы в сети.
4. Два раза щёлкните по названию соединителя. Откроется меню свойств.
5. В разделе «Общие» напишите актуальное имя домена.
6. Зайдите на вкладку «Группы разрешений».
7. Поставьте галочку в «Анонимные пользователи».
8. Раздел «Проверка подлинности».
9. Уберите отметку из опции «Проверять подлинность».

Программа настроена и может работать.

Настройка

Теперь можно разобраться, как выбрать тип аккаунта Exchange (POP3, IMAP 4). Оба протокола подключены к Client Access. В версии 2003 - к IIS. За них отвечают отдельные службы.

Найдите одну из них в списке консоли.

1. Откройте её свойства.
2. В пункте «Вариант запуска» выберите «Автоматически».
3. Нажмите «Запустить».
4. Перейдите в Локальный - Настройка серверов - Клиентский доступ.
5. В списке «Имя протокола» будет «POP3» и «IMAP 4». Откройте свойства одного из них.
6. Можете указать номера портов, по которым программа сможет подключить домен.
7. На вкладке «Проверка подлинности» расставьте параметры безопасности. Они зависят от параметров, которые можно установить на компьютере пользователя.

В новых версиях Microsoft server (от 2013 и выше) настройки расставляются через ECP (Центр администрирования).

Эти протоколы могут принимать электронную корреспонденцию. Разница между ними:

• В IMAP 4 электронные письма находятся на сервере. Для доступа к ним нужен интернет.
• POP3 сохраняет сообщения на стороне получателя (компьютере, мобильном устройстве), но при этом удаляет их с домена. Если вы один раз загрузите их на ПК, они исчезнут из домена. Этот протокол имеет свои преимущества. Но пользователи обычно предпочитают IMAP.

Создание почтовых ящиков

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

1. Запустите консоль управления.
2. Разверните «Конфигурирование почтового ящика в получателе».
3. «Создать ящик».
4. Откройте раздел «Введение».
5. Нажмите «Почтовый ящик».
6. В пункте «Тип пользователя» выберите «Новый».
7. Откроется страница с информацией, которую надо ввести: ФИО сотрудника; логин (имя входа); пароль.
8. В следующем окне надо заполнить поле «Алиас» (обычно совпадает с логином).
9. Загрузите базу данных ящика и его политику.
10. Подтвердите и нажмите «Создать».

В ES 2016 это делается так:

1. Откройте Центр администрирования (ECP).
2. Щёлкните на кнопку «Получатели» (она слева сверху).
3. Нажмите на «Почтовые ящики».
4. Разверните список с тем же названием. Для этого кликните на стрелочку около символа «+» (Плюс)
5. Опция «Ящик пользователя».
6. Откройте страницу «Создать».
7. «Новый пользователь».
8. Заполните информацию о владельце аккаунта.
9. Сохраните изменения.

После этого ящик можно подключать к Outlook или другой почтовой программе .

Права администратора

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

1. Щёлкните правой кнопкой мыши на «Мой компьютер».
2. Пункт «Управление».
3. «Локальные пользователи».
4. Нажмите на «Группы».
5. Двойной клик на «Администраторы».
6. «Добавить».
7. Выберите «Поиск».
8. Найдите нужного пользователя.

1. Зайдите в консоль.
2. «Конфигурация».
3. Нажмите «Добавить администратора».
4. Кликните на «Обзор».
5. Выберите пользователя и задайте ему роль.
6. Подтвердите.

1. В консоли разверните «Инструментарий».
2. Найдите страницу «Работа».
3. Откройте «Редактор управление доступом».
4. Выделите пользователя (должна быть разблокирована возможность изменения данных пользователя).
5. Кнопка «Регистрация».
6. «Роли администратора».
7. Найдите «Управление получателями». Откройте «Сведения».
8. В разделе «Члены» нажмите «Добавить».
9. Выберите пользователя и сохраните.

1. В Центре администрирования перейдите в Почта - Опции - Управление.
2. Нажмите на «Роли и аудит».
3. Два раза кликните на «Управление получателями».
4. Кнопка «Добавить».
5. Выберите пользователя.
6. Нажмите «OK».

Подключение Outlook

1. Вот как подключить Outlook к серверу Exchange:
2. Зайдите в Панель управления.
3. Откройте меню «Почта» в разделе «Учётные записи и безопасность».
4. Кнопка «Учётные записи».
5. Нажмите «Создать».
6. Выберите службу и кликните «Далее».
7. Опция «Параметры вручную».
8. Отметьте пункт к ES.
9. В поле «Сервер» введите exchange[версия].[домен].
10. В «Имя пользователя» напишите логин.
11. Отметьте пункт «Использовать кэширование», если собираетесь заходить в почту с мобильных устройств.
12. В открывшемся окне поставьте точку в «Автоматически определять состояние».
13. Перейдите на вкладку «Подключение».
14. Поставьте метку «По протоколу HTTP».
15. Нажмите кнопку «Прокси-сервер».
16. В поле «Адрес URL» напишите exchange[версия].[домен].
17. В списке «Способ проверки подлинности» выберите «Проверка NTLM».
18. Нажмите «OK».

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

Повышение схемы

В пределах одной сети доступна только одна организация. Нельзя использовать разные ES параллельно. Если вы уже установили почтовый ресурс, можно разобраться, как повысить схему Exchange 2003 до 2007, 2010, 2013 или 2016. Это достаточно сложный процесс, в котором надо учитывать большое количество факторов. Начиная от установленных программ, заканчивая настройками каждого пользователя. Для миграции программы ES надо хорошо в ней разбираться.

1. Загрузите все обновления для ES.
2. Разверните утилиту, на которую собираетесь перейти. Делать это надо в таком порядке: Клиентский доступ, Транспортный концентратор, Система сообщений, Почтовые ящики.
3. На передний план поставьте старую утилиту. На место клиентского доступа поставьте желаемую версию.
4. Настройте транспортный концентратор и систему сообщений.
5. Переместите ящики на новый сервер.
6. Обновите все службы AD.

Ещё один способ. На technet.microsoft.com есть интерактивный помощник по работе с ES. Зайдите на этот сайт, введите в строку поиска запрос и откройте нужную страницу. Чтобы поднять схему, нажмите «Локальное развёртывание». Выберите версию, на которую хотите перейти. Там есть обновление среды.

Без Microsoft Exchange server невозможно представить большую компанию. Собственный почтовый домен повысит эффективность компании. Но в маленьком предприятии сервер тоже незаменим. В программе очень легко сделать приём и отправку сообщений по всем протоколам. Её можно подключать к Outlook.

Www.microsoft.com

В статье Служба Exchange 2013 Transport вы найдете краткую информацию о принципе функционирования одной из основных служб транспортного конвейера Exchange 2013 — Транспортной службы на серверах с ролью MBX. Помимо внутреннего устройства службы, я расскажу о соединителях отправки и соединителях получения, связанных с Microsoft Exchange Transport.

Это вторая статья из серии, посвященной принципам работы служб транспортного конвейера Exchange 2013, а вот полный список:

А также статьи по управлению логированием этих служб:

Не забывайте об официальной документации.

Найти больше информации по настройке и администрированию Exchange 2013 на моем блоге вы сможете в основной статье тематики - .

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

• на серверах клиентского доступа (Отображаемое имя - Microsoft Exchange FrontEnd Transport, сокращенное - MSExchangeFrontEndTransport);
• Транспортная служба на серверах почтовых ящиков (Отображаемое имя - Microsoft Exchange Transport, сокращенное - MSExchangeTransport);
• на серверах почтовых ящиков (Реально включает в себя две службы - Microsoft Exchange Mailbox Transport Delivery и Microsoft Exchange Mailbox Transport Submission, сокращенные имена - MSExchangeDelivery и MSExchangeSubmission соответственно);
• Транспортная служба на пограничных транспортных серверах (Отображаемое имя - Microsoft Exchange Transport, сокращенное - MSExchangeTransport).

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

Транспортный конвейер

В прошлой статье я рассматривал первый компонент транспортного конвейера Exchange 2013 — службу FrontEnd Transport (Транспортная служба переднего плана ) на серверах клиентского доступа. Сейчас пришло время перейти ко второму компоненту — службе Microsoft Exchange Transport (Транспортная служба ) на серверах почтовых ящиков. Напоминаю, что в общем плане транспортный конвейер выглядит следующим образом:

В контексте данной статьи нас будет интересовать роль Сервер почтовых ящиков (MBX или MailBox Server) и конкретно одна служба этой роли — на рисунке выше ей дали имя Служба передачи . В реальности же она называется Microsoft Exchange Transport . Не заостряя внимание на Транспортной службе почтовых ящиков, получаем схему:

Именно в этом компоненте нам и предстоит разобраться.

Принцип работы

Хочу напомнить, что всего у Exchange 2013 есть три серверные роли — CAS, MBX и Edge (добавлена в Exchange Server 2013 SP1). При этом Транспортная служба присутствует на двух ролях — MBX и Edge — и обладает примерно одинаковым функционалом и возможностями. Некоторые отличия все же есть, но они сведены к минимуму. Конечно о них стоит рассказать, но сделаю это я вероятнее всего в отдельной статье.

Итак, ниже описан порядок прохождения сообщений через определенные обработчики Транспортной службы на серверах почтовых ящиков:

1. Первым делом сообщения проходят через агенты транспорта (на рисунке Агенты протокола), которые проводят фильтрацию по заданным критериям . Агенты могут быть как встроенными в Exchange Server 2013 (системными), так и написанными сторонними разработчиками ПО или даже администраторами организаций. Агенты позволяют расширять функционал почтового сервера Exchange путем добавления в логику обработки сообщений собственный код. Вызов агентов происходит при возникновении событий SMTP;

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

Сообщения также могут попасть сразу в очередь через каталоги раскладки и преобразования:

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

Главное назначение этих каталогов — передать сообщения классификатору, минуя агентов транспорта (к этому моменту для определенных сообщений может отсутствовать необходимость прохождения через агентов транспорта, например когда сообщение уже прошло через них на другом сервере MBX. Зачем делать одну и ту же работу дважды?);

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

Казалось бы, чего тут думать — принял сообщение и сразу отправил его в базу данных на этом же сервере. Но на деле все функционирует значительно сложнее. Начнем с того, что Транспортная служба на серверах MBX вообще не занимается доставкой сообщений в базу (да, это действительно так. Сообщения в БД отправляет Транспортная служба почтовых ящиков на серверах MBX). Кроме того, конфигурация Exchange 2013 может быть очень сложной и иметь множество групп доступности баз данных (DAG) на разных серверах, да ещё и расположенных на разных сайтах AD или даже в разных лесах;

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

5. Последний этап — отправка сообщений в место назначения . Самое близкое назначение — Транспортная служба почтовых ящиков на этом же сервере MBX, но существует также огромное множество различных вариантов, подробнее читайте в официальной документации.

Пришло время рассмотреть каким образом сообщения попадают к Транспортной службе .

Соединители приема и соединители отправки

Транспортная служба на серверах MBX прослушивает различные порты для приема сообщений, в том числе от Транспортной службы переднего плана на CAS-серверах даже в том случае, если обе роли (MBX+CAS) установлены на одном и том же сервере. Для более наглядного представления предлагаю обратиться к иллюстрации:

Хочу отметить, что в соединителях отправки у меня активировано (имеет значение $true ) свойство FrontendProxyEnabled . Этот параметр определяет поведение Транспортной службы MBX-сервера при отправке почты внешним отправителем — значение $true говорит о том, что почта наружу будет всегда уходить через сервер CAS (не считая случаев, когда используется сервер Edge. Подробнее читайте в статье ). В противном случае MBX-сервер может самостоятельно отправлять почту внешним получателям, минуя роль CAS.

Теперь разберемся какие соединители на каких портах работают.

По умолчанию при установке роли MBX создается два соединителя получения. Этими соединителями могут управлять системные администраторы, они доступны в EAC и PowerShell:

Помимо этих двух соединителей получения, существует также один скрытый соединитель отправки:

• Intra-Organization SMTP Send Connector (SMTP 25/2525 в Транспортную службу на других серверах почтовых ящиков)

В русскоязычной версии этот соединитель будет иметь имя .

UPD: 12.06.2016: Судя по всему, соединитель Отправляющий соединитель SMTP Intra-Organization используется для двух задач :

• Отправка по SMTP на порт 2525 к Транспортной службе на других серверах почтовых ящиков;
• Отправка по SMTP на порт 475 к Транспортной службе почтовых ящиках на локальном сервере или на других серверах почтовых ящиков.

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

Shell

*,Sending blob EPROP-1.2.0.0 192.168.1.7:10195,192.168.1.7:475,<,"250 2.6.0 CHUNK received OK, 1759 octets", 192.168.1.7:10195,192.168.1.7:475,>,BDAT 9409 LAST, 192.168.1.7:10195,192.168.1.7:475,<,250 2.0.0 OK, 192.168.1.7:10195,192.168.1.7:475,>,QUIT, 192.168.1.7:10195,192.168.1.7:475,<,221 2.0.0 Service closing transmission channel, 192.168.1.7:10195,192.168.1.7:475,-,Local 192.168.1.5:2525,*,attempting to connect +, 192.168.1.7:10215,192.168.1.5:2525,<,"220 EXCH02.sc.local Microsoft ESMTP MAIL Service ready at Thu, 9 Jun 2016 17:17:35 +0300", 192.168.1.7:10215,192.168.1.5:2525,>,EHLO EXCH01.sc.local, 192.168.1.7:10215,192.168.1.5:2525,<,250-EXCH02.sc.local Hello , 192.168.1.7:10215,192.168.1.5:2525,<,250-SIZE, 192.168.1.7:10215,192.168.1.5:2525,<,250-PIPELINING, 192.168.1.7:10215,192.168.1.5:2525,<,250-DSN, 192.168.1.7:10215,192.168.1.5:2525,<,250-ENHANCEDSTATUSCODES, 192.168.1.7:10215,192.168.1.5:2525,<,250-STARTTLS,

192.168.1.7:10195,192.168.1.7:475,*,Sending blob EPROP-1.2.0.0 192.168.1.7:10195,192.168.1.7:475,>,BDAT 9409 LAST, 192.168.1.7:10195,192.168.1.7:475,<,250 2.0.0 OK, 192.168.1.7:10195,192.168.1.7:475,>,QUIT, 192.168.1.7:10195,192.168.1.7:475,<,221 2.0.0 Service closing transmission channel, 192.168.1.7:10195,192.168.1.7:475,-,Local 192.168.1.5:2525,*,attempting to connect 192.168.1.7:10215,192.168.1.5:2525,+, 192.168.1.7:10215,192.168.1.5:2525,<,"220 EXCH02.sc.local Microsoft ESMTP MAIL Service ready at Thu, 9 Jun 2016 17:17:35 +0300", 192.168.1.7:10215,192.168.1.5:2525,>,EHLO EXCH01.sc.local, 192.168.1.7:10215,192.168.1.5:2525,<,250-EXCH02.sc.local Hello , 192.168.1.7:10215,192.168.1.5:2525,<,250-SIZE, 192.168.1.7:10215,192.168.1.5:2525,<,250-PIPELINING, 192.168.1.7:10215,192.168.1.5:2525,<,250-DSN, 192.168.1.7:10215,192.168.1.5:2525,<,250-ENHANCEDSTATUSCODES, 192.168.1.7:10215,192.168.1.5:2525,<,250-STARTTLS,

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

· Комментариев нет

Не знаю, как вы, а когда я думаю о роли Client Access Server в Exchange 2007, я немедленно вспоминаю о Outlook Web Access, Outlook Anywhere, ActiveSync и других non-MAPI формах подключаемости к почтовому серверу. Однако роль Client Access Server является домом для других важных сервисов, таких как Autodiscover и Availability. Это жизненно важные сервисы для инфраструктуры Exchange 2007, и в этой статье мы детально ознакомимся с сервисом Availability и его основной задачей.

Что такое служба Availability?

Служба availability в Exchange 2007 в основном связана с тем, как пользователи получают доступ к информации планировщика (Free/Busy — свободен/занят) других пользователей. Прежде чем мы перейдем к деталям этой службы, важно понять, как информация свободен/занят хранится, и как к ней открывается доступ в Exchange 2000 и Exchange 2003, чтобы можно было сравнивать работу этого процесса в старых версиях, и, что более важно, какие усовершенствования имеют место в Exchange 2007. В предыдущих версиях Exchange, папка сайта существует с именем Schedule+ Free/Busy , в которой хранится информация планировщика для каждого пользователя. Эту папку можно увидеть в Exchange System Manager, просмотрев системные папки, а не общие. На рисунке 1 приведен пример системных папок Schedule+ Free/Busy, которые открыты в Exchange System Manager.

Рисунок 1: Системная папка Schedule+ Free/Busy

Вы заметите, что есть две системные папки, по одной папке для каждой административной группы. По умолчанию, Outlook периодически публикует информацию планировщика в эти системные папки, которая потом позволяет клиентам Outlook других пользователей запрашивать данные для различных назначений. На небольших системах это обычно хорошо, а вот в системах больших размеров использование общих папок хранения такой информации может вызвать определенные проблемы. Например, всегда существует вероятность недостатка свежей информации планировщика из-за задержек репликации общих папок, или, в худшем случае, сбой процесса репликации общих папок по каким бы то ни было причинам. Однако основная проблема такого подхода заключается в будущем общих папок в Exchange. За последние пару лет вы, возможно, слышали или читали о планах Microsoft убрать общие папки из будущих версий Exchange, в результате потребуется новый механизм для работы с запросами информации планировщика. Именно здесь приходит на помощь служба availability в Exchange 2007.

Более удачный метод Free/Busy

Служба availability в Exchange 2007 представляет собой один из новых веб-сервисов. Говоря вкратце, веб-сервисы Exchange 2007 позволяют приложениям получать доступ к содержимому почтовых ящиков через HTTP, поэтому очевидно, что развитие приложений нацелено на эти сервисы Exchange 2007. Информация планировщика (free/busy information) для пользователей Exchange 2007 теперь будет храниться непосредственно в почтовом ящике, поэтому доступ к ней можно получить с помощью веб-сервисов, как и к службе Availability. Как мы увидим далее, этот новый метод полагается на Outlook 2007 и Exchange 2007, поэтому не всегда можно будет достичь желаемого результата с помощью этого метода, если в сети есть Outlook 2003 и Exchange 2003. Outlook 2007 определяет службу Availability посредством сервиса Autodiscover.

В этой статье мы не будем останавливаться на сервисе Autodiscover, поскольку этот сервис сам по себе представляет большую отдельную тему для разговора. Однако важно понять, что собой представляет сервис Autodiscover, если вы этого еще не поняли. Вкратце, сервис Autodiscover дает клиентам Outlook 2007 доступ к определенным параметрам Exchange 2007, таким как служба Availability, как уже было отмечено, плюс другим общим сервисам, таким как Offline Address Book (OAB), а также к менее общим службам, например Unified Messaging (UM). По сути, Outlook 2007 делает запрос на виртуальную директорию под названием Autodiscover, которая находится на Client Access Server. Этот сервис Autodiscover возвращает клиенту множество различных частей информации, некоторые из которых представляют собой URL для сервисов и служб, например службы Availability.

Проблемы версии

Различные методы получения информации планировщика используются, когда сеть состоит из Outlook 2003 и Outlook 2007, а также Exchange 2003 и Exchange 2007. Например, когда Outlook 2007 используется в связке с Exchange 2007, усовершенствованием является тот факт, что информацию планировщика теперь можно получить непосредственно из нужного почтового ящика Exchange 2007, а не из системной папки Schedule+ Free/Busy. Таким образом, информация планировщика будет более свежей, чем при использовании традиционного метода. Посмотрите на рисунок 2, расположенный ниже, там пользователь Outlook 2007 с почтовым ящиком Exchange 2007 запрашивает информацию планировщика у другого пользователя Exchange 2007. В этом случае, соединение Outlook создано с сервисом Availability, запущенным на сервере Client Access Server, который в свою очередь определяет, какой почтовый ящик является целевым ящиком Exchange 2007. Затем осуществляется соединение Remote Procedure Call (RPC) с почтовым сервером, и результаты возвращаются на сервер Client Access Server, прежде чем будут направлены непосредственно пользователю.

На рисунке 2 показана ситуация, в которой сервер Client Access Server и почтовый сервер находятся на одном сайте Active Directory. Что если запрос информации планировщика делается пользователем, чей почтовый ящик находится на почтовом сервере Exchange 2007, расположенном на сайте другой Active Directory? В этом случае, сервер Client Access Server на сайте Active Directory пользователя, который посылает запрос, направит этот запрос на сервер Client Access Server расположенный на сайте Active Directory целевого пользователя, к которому направлен запрос. Результаты вернутся на сервер Client Access Server пользователя, отправившего запрос, и в итоге будут переданы этому пользователю.

Есть еще один важный момент, который следует учитывать. Что если запрос информации планировщика был одновременно направлен и на другой почтовый ящик, а этот почтовый ящик все еще находился на сервере Exchange 2003? Эта ситуация будет встречаться довольно часто во время любого перехода с Exchange 2003 на Exchange 2007. В этих случаях, информация планировщика для пользователя Exchange 2003 будет храниться в системной папке Schedule+ Free/Busy, как уже было показано ранее. В результате службе Availability придется получить соответствующую информацию из этой папки. Она делает это путем отправки HTTP запросов в /Общую виртуальную директорию на целевом почтовом сервере Exchange 2003. Этот процесс отражен на рисунке 3. Как только информация была получена с серверов Exchange 2007 и Exchange 2003, служба Availability объединяет результаты и возвращает их пользователю Outlook 2007.

Рисунок 3: Пользователь Outlook 2007 запрашивает информацию Exchange 2003 и Exchange 2007 Free/Busy

Итак, мы рассмотрели, что происходит, когда пользователь использует Outlook 2007. Как на счет пользователя Outlook 2003, имеющего ящик Exchange 2007? В этом случае не имеет значения, расположен ли целевой ящик на Exchange 2003 или Exchange 2007, поскольку клиент Outlook 2003 будет пытаться получить информацию планировщика из системной папки Schedule+ Free/Busy. Причина здесь следующая: Outlook 2003 всегда ожидает публикации информации планировщика в этом месте, и поэтому не имеет представления о существовании службы Availability. И как вы, вероятно, догадались, эта ситуация применима и к более ранним версиям Outlook, таким как Outlook 2002 или Outlook 2000.

До этого момента я перечислял Outlook лишь как тип клиента. Должен сказать, что эти же принципы применимы и к Outlook Web Access. Другими совами, если целевой почтовый ящик находится на Exchange 2007, служба Availability создаст RPC соединение с этим почтовым сервером. Если целевой почтовый ящик находится на Exchange 2003, служба Availability сделает HTTP запросы и получит информацию из системной папки Schedule+ Free/Busy.

Заключение

Служба Availability в Exchange 2007 очень важна, поскольку она несет ответственность за получение свежей информации планировщика для пользователей, если они используют Outlook 2007 и Exchange 2007. В этой статье я раскрыл основы службы Exchange 2007 Availability, и то, как она используется для получения информации планировщика.

Источник http://www.msexchange.org

Смотрите также:

Readers Comments (Комментариев нет)

Да человек я, человек! =)

Exchange 2007

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Проведение мониторинга Exchange 2007 с помощью диспетчера System ...

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

Если вы пропустили первую часть этой серии, пожалуйста, прочтите ее по ссылке Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (Часть...

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Мониторинг Exchange 2007 с помощью диспетчера System Center Operations ...

Служба обновления получателей Exchange Server Recipient Update Service (RUS) - это важный компонент системы, определяющий общее состояние среды передачи сообщений. В небольших организациях RUS нередко остается на вторых ролях. Но у тех, кто работает с крупными или сложными системами, наверняка возникают проблемы с политиками получателей или со службой RUS, которая по непонятным причинам ведет себя не так, как ожидалось. Так или иначе, разобравшись с тем, как функционируют политики получателей, в каких случаях нужно, чтобы RUS переформировывала списки адресов, и с какими проблемами, скорее всего, придется столкнуться при эксплуатации этой службы, вам будет проще избегать осложнений в работе.

Политики получателей

Служба обновления получателей выполняет плановые проверки Active Directory (AD) на наличие обновлений в списках и затем принимает меры к тому, чтобы найденные объекты могли получать сообщения электронной почты. Когда администратор редактирует свойства объекта, имеющего адрес электронной почты, и выставляет флажок Automatically update e-mail addresses based on recipient policy (на закладке Email Addresses диалогового окна Properties соответствующего объекта), как показано на экране 1, служба RUS определяет, какую политику получателя следует применять к данному объекту, а затем выполняет команды, содержащиеся в этой политике. Некоторые организации, скажем поставщики услуг доступа к приложениям (application service provider, ASP) или Internet-провайдеры, предпочитают не использовать в своих системах службу обновления получателей для создания почтовых адресов. Во многих таких организациях реализуется мультиплатформенный процесс инициализации и синхронизации каталогов, и они могут использовать программы или утилиты от независимых поставщиков. Этот подход вполне приемлем; главное, чтобы избранная программа передавала в каталог AD обновленную информацию, необходимую для того, чтобы система Exchange могла маршрутизировать и доставлять сообщения.

При установке в организации первого сервера система Exchange создает принимаемую по умолчанию политику получателя. Поскольку функции базового механизма маршрутизации в системах Exchange выполняет протокол SMTP, данная стандартная политика обеспечивает наличие адреса SMTP у каждого объекта, которому выделен адрес электронной почты, и использует формат [email protected] (где вместо domain.com используется часть имени леса AD, в котором размещается данная организация Exchange). Значение атрибута mailNickname для конкретной организации уникально, так что на основании политики можно генерировать уникальные почтовые адреса. Сотрудники небольших организаций могут ничего не менять в предлагаемой по умолчанию политике, однако в большинстве крупных организаций, как правило, используется общепринятый формат адресов SMTP - first_name.last_name@domain. Можно создать новую политику получателя и дать службе обновления получателей команду создавать адреса в этом формате, после чего нужно будет указать, что в первую очередь выполняется новая политика и лишь после этого - стандартная; теперь служба обновления получателей будет первым делом обрабатывать команды новой политики. Отметим, что Microsoft рекомендует не вносить изменения в стандартную политику, а создавать новую (по причинам, которые излагаются в статье Microsoft "How to customize the SMTP e-mail address generators through recipient policies", опубликованной по адресу http://support.microsoft.com/?kbid=285136 ). Это хороший совет: вы никогда не ошибетесь, проводя четкое разграничение между настройками, характерными для организации, и параметрами, предлагаемыми по умолчанию.

Чтобы создать новую политику получателя, следует открыть диспетчер Exchange System Manager (ESM), правой кнопкой мыши щелкнуть на контейнере Recipient Policies (в разделе Recipients) и в открывшемся контекстном меню выбрать пункт New. Эффективная политика получателя должна включать в себя фильтр на базе облегченного протокола доступа к каталогам LDAP (Lightweight Directory Access Protocol). С его помощью служба обновления получателей будет идентифицировать объекты, на которые воздействует политика, и задавать формат адресов электронной почты, которые RUS будет генерировать для этих объектов.

Теперь создадим фильтр LDAP. Для этого нужно открыть диалоговое окно Properties данной политики, перейти на закладку General и щелкнуть на элементе Modify. После этого можно создать требуемый фильтр. Необходимо выбрать тип объектов, которые он будет обрабатывать, и атрибуты, в соответствии с которыми будет осуществляться сортировка. На экране 2 показан сформированный фильтр LDAP. В этом примере служба обновления получателей будет отыскивать объекты с имеющим то или иное значение атрибутом mailNickname и просматривать все категории объектов; обратите внимание на правила фильтров, которые ссылаются на типы objectClass, такие как user и contact, а также на тип objectCategory msExchDynamicDistributionList (список рассылки на базе запросов). Эта новая политика напоминает стандартную политику, которая тоже выбирает любой объект любого класса, лишь бы у объекта был атрибут mailNickname с заданным значением. Новую политику отличает от стандартной финальное правило фильтра, в котором содержится присваивание department=HQ: новый фильтр применим лишь к тем объектам, у которых атрибут department имеет значение HQ. Надо сказать, что для получения наилучших результатов для фильтров LDAP нужно всегда задавать в качестве критерия поиска полное совпадение с ключевым словом. Если же создать фильтр, в результате применения которого служба обновления получателей будет проверять множество атрибутов на наличие значений, начинающихся с тех или иных символьных строк, производительность сервера снизится.

Чтобы указать другие форматы почтовых адресов, которые будет создавать служба обновления получателей, следует перейти на закладку E-Mail Addresses (Policy). Как видно на экране 3, на этой закладке перечисляются различные форматы, применимые внутри организации. В данном примере я решил не создавать адресов других форматов для CCMAIL (т. е. Lotus cc: Mail), MS (т. е. Microsoft Mail) и для NOTES (т. е. для Lotus Notes), поскольку пользователи, на действия которых влияет данная политика, не пользуются этими почтовыми системами. Два оставшихся формата - SMTP и X400 (т. е. X.400) - играют важную роль в организациях Exchange. SMTP ныне является стандартным протоколом передачи сообщений для Exchange, а X.400 по-прежнему остается глубоко интегрированным в этот продукт. Как показано на экране, формат SMTP будет создавать адреса вида first_name.last_name@domain. Если объект имеет действительный адрес другого формата, можно в любой момент посылать этому объекту электронные почтовые сообщения по упомянутому адресу. Так, если известно, что новый объект «пользователь» имеет SMTP-адрес [email protected], можно отправлять электронные сообщения по этому адресу и система Exchange обеспечит для них корректную маршрутизацию, даже если этот объект не представлен в глобальном списке адресов (поскольку еще не завершено тиражирование данных AD или пока не установлена автономная адресная книга OAB - Offline Address Book). Это полезная возможность, поскольку, если объект не относится к категории скрытых, он должен присутствовать по крайней мере в одном списке адресов, иначе клиенты Messaging API (MAPI), такие как Outlook, не смогут его обнаружить. Более того, существует возможность отправки сообщений получателям, не представленным в глобальном списке адресов (Global Address List, GAL); достаточно, чтобы эти получатели имели действительные адреса SMTP. Именно таким образом многие администраторы отправляют сообщения получателям, когда знают, что их адреса скрыты. Тем, кто работает в крупной организации, вероятно, придется применять множество политик получателей. Но лучше обходиться как можно меньшим их числом: чем проще система, тем меньше вероятность ошибки. Каждая политика получателя имеет в контейнере Recipient Policies определенный приоритет исполнения. Служба обновления получателей обрабатывает политики в порядке от высшего приоритета к низшему. Чтобы изменить порядок политик, следует правой кнопкой мыши щелкнуть на политике в окне ESM, выбрать элемент All Tasks, а затем - элемент Move Up или Move Down. Предлагаемая по умолчанию политика всегда должна иметь самый низкий приоритет. Ее назначение - выступать в качестве последней линии перехвата и извещать службу обновления получателей о том, каким образом обрабатывать объекты, не охваченные другими политиками.

Экран 3. Выбор почтовых форматов

Когда служба обновления получателей активизирована, она выявляет обновления в каталоге AD (для этого она сравнивает значения USNchanged объектов AD и находит объекты, изменившиеся со времени последней проверки); не изменявшиеся объекты служба игнорирует. Поэтому, создавая новую политику или модифицируя существующую, вы, возможно, исходите из того, что служба обновления получателей достаточно «интеллектуальна», чтобы автоматически перепроверить правильность почтовых адресов во всей организации и обеспечить соответствие всех адресов новой политике. Имейте в виду - это ошибочное представление! Чтобы немедленно активизировать новую или модифицированную политику, следует правой кнопкой мыши щелкнуть на ней в окне ESM и в открывшемся контекстном меню выбрать пункт Apply this policy now. Когда вы будете создавать новую политику или модифицировать существующую, ESM напомнит о том, что нужно выполнить эту операцию (см. экран 4 ). При этом придется применять не только новую или модифицируемую политику, но и все другие политики, которые могут претерпеть изменения вследствие внесенных модификаций. Поскольку политики получателей хранятся в контейнере на уровне организации, для их применения требуются полномочия Exchange Administrator во всей организации.

Повторное составление списка адресов

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

Когда вы поручаете службе обновления получателей вновь создать списки адресов для домена, она устанавливает значение атрибута USNchanged равным 1; это действие в свою очередь приводит к тому, что служба RUS приступает к обработке всех связанных с электронной почтой объектов домена. Обычно обработка начинается по истечении планового интервала, но если вслед за командой Rebuild ввести команду Update Now, выполнение этой операции начнется немедленно. Логично предположить, что в доменах, содержащих десятки тысяч объектов с адресами электронной почты, на выполнение необходимых LDAP-запросов и других операций уходит довольно много времени. В некоторых системах процедура повторного формирования списков адресов может занять более одного дня - даже в тех случаях, когда задействованные в этой операции сервер Exchange и контроллер домена связаны быстрым соединением. Кроме того, операции повторного формирования списков адресов создают большую нагрузку на соответствующие серверы и на всю сеть, которой приходится передавать LDAP-запрос и репликационный трафик AD, генерируемый в процессе повторного формирования списков. Словом, я не рекомендую выполнять операцию повторного формирования списков адресов, если, конечно, вы не уверены в том, что это единственный способ решить проблему со списком адресов (скажем, в тех случаях, когда раз за разом не удается удалить из глобального списка адресов недействительные или устаревшие данные либо внести в этот список обновленные данные).

В ходе процесса переформирования списка адресов система Exchange определяет для атрибута msExchDoFullReplication службы обновления получателей значение TRUE, а по завершении данного процесса изменяет это значение на FALSE. Таким образом исключается возможность одновременного проведения процедуры повторного формирования списков адресов несколькими администраторами (по той, например, причине, что они не видят явных признаков выполнения этой процедуры кем-то другим). Если же проведение операции повторного формирования списков адресов средствами службы обновления получателей может повлечь за собой неприятные последствия для организации, можно ограничить доступ к этому атрибуту, оставив право на обновление его значения за администратором всего предприятия.

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

Самая элементарная проблема, с которой, вероятно, придется столкнуться, состоит в том, что новые объекты, имеющие адреса электронной почты, не отображаются в глобальном списке или в других списках адресов. Это значит, что служба обновления получателей не смогла обработать данные объекты. Предположительно все дело в ошибочной политике получателя. Возможно, объяснение состоит в том, что указанный в службе обновления получателей контроллер домена по той или иной причине недоступен (это могут быть неполадки с сетью или временная приостановка работы). Еще одна возможная причина рассматриваемой проблемы - задержки с тиражированием данных AD. В этом случае часто бывает, что в рамках одной и той же организации обновленные данные присутствуют в одних местах и отсутствуют в других. Необходимо проверить все указанные возможности и устранить все связанные с ними неполадки, прежде чем приступать к операции повторного формирования списка адресов.

В статье Microsoft «Proxy addresses are not removed when the recipient policy is removed in Exchange Server» (http://support.microsoft.com/?kbid=286302 ) описывается любопытная проблема. Когда администратор удаляет политику получателя, служба обновления получателей не удаляет адресов других форматов, созданных с помощью этой политики. Проблема, по-видимому, возникает потому, что Microsoft так и не включила в спецификацию службы обновления получателей функции «проверка-удаление». Администратор вынужден удалять эти адреса вручную; в статье рассказывается о том, как это сделать.

Проблемы могут возникнуть и в связи с недостаточной осведомленностью сотрудников в вопросах, касающихся функционирования службы обновления получателей. Если, к примеру, администратор начнет экспериментировать с этой службой и применит какую-либо политику получателя, в результате могут измениться почтовые адреса пользователей. Система Exchange не генерирует предупреждений о возможных последствиях применения новой политики; разъяснений относительно различий между текущей политикой и новой политикой она тоже не предлагает, так что при оценке последствий применения новой политики администратор может опираться только на собственные знания особенностей конкретной организации. Здесь еще будет уместно напомнить, что особую осторожность при изменении политик получателей следует соблюдать администраторам тех организаций, в которых не используется функция RUS по автоматическому генерированию адресов электронной почты; в этой ситуации велика вероятность того, что модифицированная политика получателя будет конфликтовать с процессом, который используется для создания адресов.

И последнее. Планируя разобраться с тем, как функционирует служба обновления получателей в организации и намереваясь черпать данные для анализа из журналов регистрации событий, нужно иметь в виду следующее. Отладка и диагностика службы обновления получателей - дело весьма сложное. В журналах регистрации событий можно найти массу относящейся к делу информации, но интерпретировать ее нелегко. Рекомендую ознакомиться с состоящей из трех частей превосходной статьей на эту тему - «You Had Me at EHLO», опубликованной в сетевом журнале Microsoft Exchange Team по адресу http://blogs.technet.com/exchange/archive/ 2004/07/07/175444.aspx .

Приоритеты и подготовка

Искусство администратора часто сводится к умению правильно расставлять приоритеты, иначе говоря, к умению определять, каким задачам следует уделять время, а какие пока можно оставить без внимания. Если на начальных этапах уделить немного внимания службе обновления получателей, в дальнейшем она, скорее всего, будет проходить по второй категории - прекрасно функционировать без какого-либо вмешательства со стороны администратора. Но и подготовкой - изучением того, какие функции выполняет служба RUS и как она это делает, - тоже нельзя пренебрегать. Разобравшись с этими вопросами, администратор будет во всеоружии, если в системе возникнут проблемы с почтовыми адресами, с доставкой сообщений или новые объекты не будут отображаться в глобальном списке адресов.

Тони Редмонд - Внештатный редактор Windows IT Pro, старший технический редактор выпусков Exchange & Outlook Administrator, вице-президент и главный технолог в HP Services, автор «Microsoft Exchange Server 2003 with SP1» (Digital Press). Связаться с ним можно по адресу: (