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

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

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

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

If you try to connect Outlook 2007 or 2010 on Windows XP to Exchange Server 2013, you will face an issue of continuous password prompt for an account.

This issue is about some special kind of work with certificates in 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 (ящиками-призраками).

In Exchange you can encounter issues when you move mailbox between databases. And after this issues you can have, for example, 2 (or several) mailboxes in your databases which belongs to a single user. And of course, only one mailbox from them linked to Active Directory user account.

And one more thing - mailboxes that are not used, NOT marked as Disconnectedor SoftDeleted.

These mailbox are known as ghost-mailboxes.

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

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

Shared Mailboxes first appeared a long time ago (in Exchange 2007), but usually administrators do not use them, despite the fact that this type of mailboxes is very useful to provide conjoint mailbox for multiple users!

I'm constantly getting requests from my users to create common e-mail address for a bunch of users (even departments). Now I'll very briefly show you how to perform the task.

Общие ящики (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? Мы можем произвести поиск по почтовым ящикам (всем или каким-то конкретным) в базе данных и скопировать результаты поиска в какой-то другой ящик. При необходимости, можно удалить найденные сообщения из исходных ящиков.