akelsey

В русском языке есть проблема кодировок, по этому видимо вам видится слово "слово" (1251), а Exchange его видит как "ёыютю" (866). Я не знаю в какой кодировке Exchange ожидает слова, т.е. какая является базовой для кириллицы, но думаю это windows-1251 (а может UTF8), стало быть что бы правило отработало с русскими словами - придется искать не только слово "слово", а и "ёыютю" так же.

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

Воспользоваться халявным транспортным агентом на свой страх и риск. Например этим:
https://www.corelan.be/index.php/2008/07/21/free-t...

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

Всё верно нужно использовать EWS (Exchange Web Services) - они используются для получения данных из Exchange для сторонних приложений.
И использовать придется EWS Managed https://github.com/OfficeDev/ews-managed-api
далее использовать документацию отсюда: https://msdn.microsoft.com/ru-ru/library/office/dd...
С кодом не помогу, трудно будет 100%, удачи :-)

Суть инкрементал бэкапа - бэкап транзакшн логов, после успешного бэкапа - BackupExec должен сообщить Exchange что бэкап прошёл успешно, и тот должен удалить забэкапленные логи.
Процесс рестора же обратный - восстанавливается фуллбэкап, потом транзакционными логами доигрывается база до нужного времени.
Так что либо вы торопитесь - либо инкрементал бэкап проходит с фейлами, либо галочку надо поставить - сообщать exchange об успешном завершении инкрементал бэкап и делать truncate logs.
PS
Когда включены circular logging - по дизайну самого Exchange невозможно сделать incremental backup - технически.

Вам нужно разрешить анонимную отправку для внутренних айпиадресов - лучше создать отдельный receive connector.

Данные хранятся в Active Directory, не в Exchange. Через ECP вряд ли получится. Можно попробовать групповое редактирование в оснастке "Active Directory Users & Computers". Если не получится, можно написать Powershell скрипт, который обнулит приватные аттрибуты определенного набора пользователей.
После этого если ничего не делать, Exchange обновит GAL/OAB, обновление данных в аутлюке - если никак не форсить, может не быть до 2х суток.

Концепция миграции немного неверная, правильно было бы создать на эксчендже ту же самую зону (можно думаю сделать это и на данном этапе), т.е.
* создаем Accepted Domain - company.com - тип Internal Relay
* создаем SMTP connector для company.com - смарт-хосты - указывают на гугл
* меняем MX записи на Exchange IP
с этого момента логика будет следующая - почта приходит на эксчендж - если ящика vasya@company.com нет - то всё улетает на Gmail.com, если есть - почта остается уже только на эксчендж.
по imap - почта синкается в локальный pst на объёмный сторадж на сервере - после полной синхронизации почтового ящика, в ночь создается майлбокс пользователя на Exchange, пароль на Gmail меняется, что бы он не мог туда заходить.

Единственный вопрос отправка почты на company.com - когда пользователь всё еще сидит на гугл, а другой переехал на Exchange - но тут нужно маны гугла читать по настройке планов миграции (или чужой опыт).

PS
После миграции последнего юзера - тип домена меняется на Authoritative - smtp connector - удаляется.

По задаче разделения существует несколько варианто:
1. Exchange 2010 оставить транзитным - тогда домены которые будут обслуживаться другим почтовым сервером сделать External Relay
2. Разделить на уровне MX записей - две разных инфраструктуры.

По вопросу общей GAL - адресная книга действительно хранится в AD, для того что б она функционировала - необходимо создавать MailContacts в домене с Exchange - обычно это делается либо отдельным приложением (например это может FIM), либо скриптом.
Других вариантов нет.

При нажатии Sign Out в OWA как раз происходит завершение всех сессий, нейтрализация всех куков.
При прямом подключении браузера к Exchange OWA - всё работает корректно (странно было бы ожидать другого поведения от Microsoft).
В вашем случае - похоже кто-то кэширует информацию между браузером и почтовиком, подозреваю корпоративный прокси сервер с агрессивным кэшированием, например Squid.
В таком случае - нужно скрипте автоконфигурации прописать корректно локальные ресурсы, или через GPO их разлить пользователям, в крайнем случае добавить руками исключения в IE (на время теста - лучше прокси вообще отключить).

Как я понял на Exchange в качестве смарт-хоста указан постфикс.
Первое что нужно сделать это проверить телнетом с сервера Exchange доступ на 25ый порт Postfix. Если он недоступен, то Expiration закономерен, Exchange пытается отправить письма на несуществующий хост.

Нужно сконфигурировать firewalls для подключения Outlook по протоколу Outlook Anywhere (RPC over HTTPS) - по POP3 к PF подключиться у вас не выйдет.
SyavaSyava в комментариях вам подсветил даже сервис проверки подключения.

get-mailboxserver | get-messagetrackinglog -sender sender@domain1.ru -recipient recipient@domain2.ru -start "10/20/2016 2:00"

PS
Через свойства, можно собрать кол-во байт, отправленных, принятых. Обычно retention период для этих логов 30 дней, если не меняли на другую величину.