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

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

Недавно я перезагрузил один мой сервер на Windows 2008 R2, но больше он загружаться не захотел. При любых способах загрузки (Last known good configuration, отключение проверки подписи драйверов, загрузка в безопасном режиме) - сервер загружался в режим восстановления (Recovery mode).

Вот список команд, которые наверняка помогут при подобных ситуациях.

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

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

При тестировании отказоустойчивой конфигурации Microsoft SQL Server 2012 (подробнее: Пошаговое развертывание AlwaysOn - MS SQL 2012) мне нужно было сгенерировать массовую запись данных в базу.

Т.к. я совсем не знаю T-SQL, решил написать небольшой скрипт на Powershell для решения этой задачи.

Нам понадобится:

• Непосредственно база данных
• Таблица в ней для службных нужд

До появления Microsoft SQL Server 2012 и механизма AlwaysOn, администраторы БД имели только одну не совсем удобную технолонию зеркалирования баз данных в SQL Server от Microsoft (Database Mirroring). Причем (как показала практика тестирования, и об этом не написано в документации) - это НЕ синхронная репликация базы и логов транзакций.

Если вкратце - то мы изучали поведение базы данных при интенсивной записи и различных неисправностях. Какие сбои мы смотрели:

• Штатное выключение мастер-сервера без уведомления зеркального сервера.
• Нештатное выключение мастер-сервера.

Как ни странно, именно штатное выключение показало, что есть некоторое различие между зеркалируемыми базами.

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

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

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

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