В Exchange 2013 (CU1, в CU2 не проверял и не смотрел) изначально почему-то OAB (Автономная Адресная Книга) находится в неопубликованном состоянии.

Это приводит к тому, что на выходе клиент Outlook выдает ошибку 0x8004010f при загрузке книги.

Если вдруг вы попытаетесь подключить Outlook 2007/2010 на Windows XP к серверу Windows XP, вы обязательно столкнетесь с проблемой, когда Outlook запрашивает учетные данные, причем запрос будет постоянно повторяться.

Это связано с особенностями работы сертификатов в Windows XP.

Вы можете столкнуться со следующими ошибками при выполнении командлетов Get-MailBox, New-MoveRequest и других в Powershell в EMS (Exchange Management Shell):

The requested search root domain is different from the scope root domain.

или

The requested search root domain.local/Users’ is not within the scope of this operation. Cannot perform searches outside the scope ‘child.domain.local’.

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

Причем тот ящик, который не используется, не помечен ни как Disconnected, ни как SoftDeleted.

Такие ящики в баще данных называются ghost-mailbox (ящиками-призраками).

Иногда при аудитах Exchange нужно получить список пользователей, которые имеют доступ к другим почтовым ящикам. Или наоборот - получить список почтовых ящиков, к которым имеют доступ другие люди. В Exchange 2010/2013 есть специальный командлет Get-MailboxPermission который умеет опрашивать список ACL (Access Control List) почтовых ящиков.

Можно расширить область применения этого командлета на все почтовые ящики в организации:

Общие ящики (Shared MailBox) появились уже очень давно (начиная с Exchange 2007), но по-прежнему их почему-то используют очень редко. А ведь с ними так легко обеспечить работу нескольких пользователей с одним почтовым адресом\ящиком!

Мне постоянно приходят запросы на возможность работы нескольких сотрудников (обычно - целого отдела) с одним адресом. Например, для поддержки кого-нибудь софта. Сегодня я очень кратко расскажу, как я решаю такие вопросы.

Вчера я разбирался с очень дурацкой проблемой в моей гибридной установке Exchange 2010 + 2013. У одного пользователя не отправлялись автоматические ответы о том, что он в отпуске (out-of-office). Не работало ни для внутренних, ни для внешних пользователей.

Что мы делали?

• Проверили, что не настроено перенаправление почты на какой-нибудь другой адрес. Настроено не было.
• Мы отключили все правила для почтового ящика (Inbox rules). У человека был настроен форвард на другой адрес в правилах, поэтому на всякий случай отключили все.
• Мы пробовали мигрировать ящик в другую базу данных на случай, если сам ящик или вся база каким-нибудь образом оказались поврежденными.
• Пробовали отключить автоответ и снова включить его.
• Мы просмотрели все транспортные правила на всех транспортных серверах, на случай если вдруг где-нибудь заглючила репликация AD.

Все эти действия не дали положительного результата.

Exchange 2010 и 2013 частично управляется с помощью Exchange Control Panel (ECP). Это веб-сервис, который выполняется на IIS на Client Access сервере. Проблема заключается в том, что когда вы публикуете OWA в Интернет, Вы автоматически публикуете ECP в Интернет тоже. А это означает угрозу безопасности.

Если вы используете IIS ARR в качестве Reverse Proxy для публикации Exchange в Интернет, можно создать правило обрабоки, которое запретит доступ к URL вида https://owa.domain.com/ecp/.

Как в Exchange 2010/2013 найти все почтовые ящики с настроенной переадресацией почты?

Это всего лишь одна строчка в Powershell:

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

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

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

Начиная с версии Exchange 2010, разработчики предоставили нам очень удобное решение по обеспечению отказоустойчивости и высокой доступности серверов баз данных почтовых ящиков (Mailbox Server).

С отказоустойчивостью серверов клиентского доступа Client Access Server (CAS) в Exchange 2010 все оказалось не так радужно. Приходилось создавать массивы CAS-серверов и NLB-кластеры (на базе Windows-решения или "железное" решение).

К счатью, в Exchange 2013 производитель перешел к абсолютно новому решению клиентского доступа. По сути, сейчас мы имеем "бывший" Outlook Anywhere, который работает как для клиентов снаружи сети, так и для внутренних пользователей. Запросы клиентов к серверу теперь обрабатываются независимо от подключения, т.е. абсолютно неважно, какой именно CAS-сервер отвечает клиенту, т.к. обработка всех запросов выполняется на серверах баз данных, а сервера клиентского доступа только отправляют\принимают данные.

Огромная масштабируемость системы Exchange кроме всех своих преимуществ, несет в себе и большие минусы. Один из таких минусов - сложность в отслеживании почтовых сообщений в логах. Ведь имея несколько транспортных серверов (не дай Бог еще и объединенных в DAG), мы получаем ситуацию, когда письмо проходит через все сервера и оставляет свой след в логах на каждом.

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

Поскольку все сообщения пользователей Exchange хранятся в базе данных, мы можем производить по ним поиск и, при необходимости, удалять. Это может потребоваться в разных ситуациях, например - когда сотрудник отправил письмо с конфиденциальной информацией "не туда" или просто надо найти и просмотреть сообщение... вариантов может быть масса.

Что в данном вопросе предлагает нам Exchange 2010/2013/2016? Мы можем произвести поиск по почтовым ящикам (всем или каким-то конкретным) в базе данных и скопировать результаты поиска в какой-то другой ящик. При необходимости, можно удалить найденные сообщения из исходных ящиков.