Группы доступности базы данных

Обзор процесса развертывания

Хотя фактические действия, используемые каждой организацией, могут незначительно отличаться, общий процесс развертывания Exchange Server в высокодоступной конфигурации или на сайте, как правило, один и тот же. После выполнения необходимых задач планирования и разработки для построения и развертывания группы доступности базы данных (DAG) и создания копий базы данных почтовых ящиков необходимо выполнить следующие действия.

Создание DAG. Дополнительные сведения см. в разделе Create a database availability group

Важно отметить, что все серверы в DAG должны работать в одной Exchange. Например, нельзя смешивать серверы 2013 Exchange 2013 Exchange 2016 года в том же DAG.

При необходимости перед этапом объекта кластерного имени (CNO)

Предварительная постановка CNO требуется при развертывании DAG с серверами почтовых ящиков, работающими Windows Server 2012. Если развертывание DAG без точки административного доступа с помощью серверов почтовых ящиков, работающих Windows Server 2012 R2, не требуется предварительной стадии CNO. Предварительная постановка также необходима в средах, где создание учетной записи компьютера ограничено или когда учетные записи компьютеров создаются в контейнере, помимо контейнера компьютеров по умолчанию. Дополнительные сведения см. в разделе Pre-stage the cluster name object for a database availability group.

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

Настроить свойства группы DAG в соответствии с требованиями.

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

Включить режим согласования активации центра обработки данных (DAC) для группы обеспечения доступности баз данных. Это защищает группу обеспечения доступности баз данных от разделения вычислительных мощностей на уровне базы данных при повторном переключении на главный центр данных после начального переключения центра данных, а также позволяет использовать встроенные командлеты восстановления группы обеспечения доступности баз данных. Дополнительные сведения см. в разделе Режим координации активации центра данных.

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

Развертывание Exchange 2016 или Exchange 2019

На этапе развертывания устанавливается Exchange в организации. Перед началом этапа развертывания необходимо выполнить планирование организации Exchange. Дополнительные сведения см. выше в разделе .

Используйте указанные ниже ссылки со сведениями, полезными при развертывании Exchange.

Всегда устанавливайте последний накопительный пакет обновления Exchange (CU) (номера сборок и даты выпуска Exchange Server | Документация Майкрософт). Нет необходимости устанавливать сборку RTM или предыдущие сборки, а затем обновляться до последнего накопительного пакета обновления. Это связано с тем, что каждый накопительный пакет обновления является полной сборкой продукта.

Перед запуском сервера в сети обновитесь с помощью последнего обновления для системы безопасности Exchange (SU). Выполните проверку с помощью сценария средства проверки работоспособности Exchange: https://aka.ms/ExchangeHealthChecker.

Поддерживайте серверы в наиболее актуальном состоянии. Всегда используйте последний накопительный пакет обновления Exchange (CU) или предыдущий накопительный пакет обновления.

Эта страница содержит ссылки на последние накопительные пакеты обновления Exchange: Номера сборок и даты выпуска Exchange Server | Документация Майкрософт.
См. статью: Обновление Exchange до последнего накопительного пакета обновления | Документация Майкрософт.

Включите Центр обновления Windows или Центр обновления Майкрософт (WU/MU) и рассмотрите возможность включения автоматического обновления для получения обновлений системы безопасности (SU).

Используйте командную строку с повышенными привилегиями для запуска любого накопительного пакета обновления или обновления для системы безопасности. Если у вас возникли проблемы при установке обновления, см. раздел https://aka.ms/exupdatefaq.

Периодически запускайте сценарий средства проверки работоспособности Exchange, проверяющий, установлены ли последние обновления для системы безопасности Exchange: https://aka.ms/ExchangeHealthChecker.

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

В этом примере копия базы данных почтовых ящиков DB1 добавляется на сервер почтовых ящиков MBX3. Время задержки воспроизведения и время запаздывания усечения остаются без изменений (0), а для приоритета активации устанавливается значение 2.

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

В этом примере копия базы данных почтовых ящиков DB3 добавляется на сервер почтовых ящиков MBX5. Время задержки воспроизведения задается до 3 дней, время задержки по умолчанию остается при значении нуля по умолчанию, а предпочтение активации настроено со значением .

Дефрагментация

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

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

Get-MailboxDatabase -Status | ft Name, DatabaseSize, AvailableNewMailboxSpace

Пример ответа:

Name DatabaseSize AvailableNewMailboxSpace
—- ———— ————————
Base1 686.4 GB 286.4 MB
Base2 170 GB 69.42 GB

* где DatabaseSize — текущий размер базы; AvailableNewMailboxSpace — пространство, которое можно освободить при дефрагментации.

Саму оптимизацию можно выполнить двумя способами:

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

В текущем подразделе мы рассмотрим первый способ.

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

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

Операция дефрагментации выполняется из Exchange Management Shell с применением утилиты eseutil.

Сначала переходим в каталог хранения базы данных, например:

cd C:\Program Files\Microsoft\Exchange Server\V14\Mailbox\Base1

Выполняем команду для отмонтирования базы:

Dismount-Database Base1

* напомним, что это приведет к отключению базы и приостановки обслуживания.

Запускаем дефрагментацию:

eseutil /d Base1.edb /t \\share\base1_tmp.edb

* где опция d — имя файла базы; t — путь до временного файла на момент дефрагментации, если его не указать, временный файл будет создан в каталоге с основным файлом и, в таком случае, нужно убедиться, что на диске достаточно свободного места (110% от размер дефрагментируемого файла).

После завершения операции, снова подключаем базу:

Mount-Database Base1

Quorum and witness server requirements

You must always have an odd number of voters in a cluster. If you have an even number of mailbox servers in the DAG, the DAG will use a node and file share majority quorum model where it will use a file share witness which is created on a witness server during the DAG setup. If you have an odd number of mailbox servers in the DAG then the DAG will use the node majoirty quorum model and the file share witness will not be used. The witness server can be any server in the domain running Server 2003 or later but not a DAG member because you’ll lose two votes if that member goes down and ideally not a domain controller as this means that the Exchange Trusted Subsystem has more permissions than it requires which is not a best practice. The DAG will create a file share on the witness server and will use this as a voter in case you have an even number of mailbox servers.

Для чего необходимо резервное копирование Exchange с помощью DPM?

При принятии решения о резервном копировании данных Exchange с помощью собственных средств защиты Exchange 2016 и Exchange 2019 или DPM необходимо учитывать следующее.

Собственные средства защиты обеспечивают:

Аварийное восстановление
Восстановление случайно удаленных элементов
Долгосрочное хранение данных.
Моментальные снимки базы данных на определенный момент времени

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

Требуется меньше групп обеспечения доступности (DAG) — собственная защита требует использования дополнительных почтовых серверов для размещения копий активных данных. Не следует рассчитывать на DAG для выполнения резервного копирования при наличии защиты DPM.
Более простое восстановление — DPM обеспечивает простое и централизованное восстановление данных из резервных копий на определенный момент времени.
Увеличенный диапазон хранения — DPM обеспечивает более длительное время хранения для резервных копий данных. Собственная защита ограничена сроком в 14 дней.
Согласованное резервное копирование рабочих нагрузок Майкрософт — DPM предоставляет централизованные и простые процессы резервного копирования и восстановления рабочих нагрузок Майкрософт, в том числе Exchange, файловых серверов, SQL Server, Hyper-V и SharePoint.

Использование Центра администрирования Exchange для создания группы обеспечения доступности баз данных

В центре администрирования Exchange последовательно выберите пункты Серверы > Группы обеспечения доступности баз данных.
Чтобы создать группу обеспечения доступности баз данных, щелкните .
На странице Создание группы обеспечения доступности баз данных укажите приведенные ниже сведения о группе обеспечения доступности базы данных.
- Имя группы доступности базы данных. Используйте это поле, чтобы ввести допустимое и уникальное имя для DAG до 15 символов. Имя эквивалентно имени компьютера, и с таким именем в Active Directory будет создан соответствующий CNO. Этим именем будет называться как группа обеспечения доступности базы данных, так и базовый кластер.
- Сервер свидетелей. Используйте это поле, чтобы указать сервер свидетелей для DAG.
  
  Примечание. Для сервера-свидетеля необходимо использовать либо имя хозяина, либо полное доменное имя (FQDN). Использование IP-адреса или подстановочного имени не поддерживается. Кроме того, следящий сервер не может входить в группу обеспечения доступности баз данных.
- Каталог свидетелей. Используйте это поле для введите путь к каталогу на сервере свидетелей, который будет использоваться для хранения данных свидетелей. Если каталог не существует, он будет создан системой на следящем сервере. Если оставить это поле пустым, на сервере свидетелей будет создан каталог по умолчанию (%SystemDrive%\DAGFileShareWitnesses \<DAG FQDN). >
- IP-адреса группы доступности баз данных. Используйте это поле для назначения одного или более статических ip-адресов IPv4 в DAG. Введите адрес IPv4 и нажмите кнопку чтобы добавить его. Если необходимо, чтобы группа обеспечения доступности баз данных использовала протокол DHCP для получения необходимых IPv4-адресов, оставьте это поле пустым. Кроме того, введите значение 255.255.255.255, чтобы создать группу обеспечения доступности баз данных без IP-адреса или административной точки доступа кластера, которое применяется только к группам обеспечения, предназначенным для серверов почтовых ящиков под управлением Windows Server 2012 R2.
Нажмите кнопку Сохранить, чтобы создать группу обеспечения доступности баз данных.

Общие требования

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

Служба доменных имен (DNS) запущена. В идеальном случае DNS-сервер должен принимать динамические обновления. Если DNS-сервер не принимает динамические обновления, необходимо создать запись DNS Host (A) для каждого сервера Exchange. Иначе Exchange будет работать неправильно.
Каждый сервер почтовых ящиков в группе доступности базы данных должен являться рядовым сервером в том же домене.
Добавление сервера Exchange почтовых ящиков, который также является сервером каталогов, в DAG не поддерживается.
Имя, присваиваемое группе обеспечения доступности баз данных, должно быть допустимым, доступным и уникальным именем компьютера, состоящим из 15 или менее символов.

Exchange 2016 DAG Basics

Exchange DAGs don’t require shared storage (mailbox databases are stored on the local disks on the server and logs are shipped to other servers)
All mailbox servers must be in the same AD domain
You create database copies but are limited to 16 copies for each database
You can’t create a database copy on a server that already has an active or passive copy of that database
The mailbox servers cannot be domain controllers — this is not supported
When a DAG is set up, a Windows Failover Cluster is set up. You cannot use this cluster for any other servies – this is not supported.
Datacenter activation coordination (DAC) mode prevents a split brain scenario where the same database is active in both datacenters and you then get dirvergence of data where changes are made to both databases but not replicated across. DAC is not enabled by default but should be enabled for all DAGs. We’ll enable this on our DAG.
DAGs only provide high availability for the mailbox role (the mailbox databases). It doesn’t provide high availability for the client access services (OWA, Outlook, ActiveSync etc). You will need to set up load balancing for the client access services using either DNS round robin or a hardware load balancer. For information on how to configure DNS round robin and the advantages/disadvantages of using this over a hardware load balancer, see here.

Дизайн пространства имен

В статьях Принципы планирования и балансировки нагрузки в namespace за Exchange Server 2016 г. Росс Смит IV обозначил различные варианты конфигурации, доступные с Exchange 2016 г., и эти понятия продолжают применяться Exchange Server 2019 г. Для пространства имен необходимо либо развернуть связанное пространство имен пользователей, имеющих предпочтение работать из определенного центра обработки данных), либо неограниченое пространство имен пользователи подключаются к любому центру обработки данных без каких-либо предпочтений).

Рекомендуется использовать неограниченную модель, развертывая единое пространство имен Exchange для клиентского протокола для пары устойчивых к обработке данных на сайте (где предполагается, что каждый центр обработки данных представляет свой собственный сайт Active Directory . дополнительные сведения см. ниже). Например,

Для службы автооткрытия: autodiscover.contoso.com
Для клиентов HTTP: mail.contoso.com
Для клиентов IMAP: imap.contoso.com
Для клиентов SMTP: smtp.contoso.com

Каждое Exchange пространства имен балансирует нагрузку между обоими центрами обработки данных в конфигурации 7 уровня, которая не использует сродство сеансов, в результате чего 50 процентов трафика перенагружено между центрами обработки данных. Трафик в равной степени распределяется между центрами обработки данных в паре веб-сайтов с помощью круглых DNS, geo-DNS или других аналогичных решений. С нашей точки зрения, более простое решение является наименее сложным и простым в управлении, поэтому наша рекомендация заключается в использовании круговой DNS.

Одним из предостережения для клиентов является назначение низкого значения TTL (время для жизни) для любой записи DNS, связанной с Exchange архитектурой. Если полное отключение центра обработки данных при использовании DNS кругового робина необходимо сохранить возможность быстрого обновления записей DNS, чтобы удалить IP-адреса из автономного центра обработки данных, чтобы они не возвращались для запросов DNS. Например, если ваши DNS-записи имеют более длительное значение TTL в течение 24 часов, для правильного обновления кэшей DNS вниз по течению может потребоваться до одного дня. Если вы не сделаете этот шаг, некоторые клиенты не смогут должным образом перейти на доступные IP-адреса в оставшихся центрах обработки данных. Не забудьте добавить IP-адреса обратно в записи DNS, когда ваш ранее автономный центр обработки данных будет восстановлен и снова готов к обслуживанию.

Сродство центра обработки данных требуется для ферм Office Online Server, поэтому пространство имен развертывается в центре обработки данных с баланситором нагрузки, использующим уровень 7, и поддерживает сродство сеанса с помощью сохраняемости на основе файлов cookie.

Если в среде имеется несколько пар устойчивых к устойчивости центра обработки данных на сайте, необходимо решить, нужно ли иметь единое пространство имен во всем мире или управлять трафиком каждого конкретного центра обработки данных с помощью региональных областей имен. Ваше решение зависит от топологии сети и связанных с этим затрат с использованием неограничаемой модели; например, если у вас есть центр обработки данных, расположенный в Северной Америке и Южной Африке, сетевое сообщение между этими регионами может быть не только дорогостоящим, но и с высокой задержкой, что может привести к проблеме с работой пользователей. В этом случае имеет смысл развернуть связанную модель с отдельным пространством имен для каждого региона. Однако такие параметры, как географические DNS, предоставляют вам возможность развертывания единого пространства имен, даже если у вас есть дорогостоящие сетевые ссылки; geo-DNS позволяет направить пользователей в ближайший центр обработки данных на основе IP-адреса клиента.

Включение активной копии базы в DAG

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

Графический интерфейс

Конфигурация организации — Почтовый ящик — вкладка Управление базой данных — ставим указатель на нужную группу баз:

Ниже кликаем правой кнопкой по базе, которая находится на нужном нам сервере и выбираем Включить копию базы данных…:

В появившемся всплывающем окне выбираем параметр для автоматического переопределения активного сервера или оставляем в положении «Нет».

Powershell

Для смены активного сервера базы из группы DAG вводим:

* где ActivateOnServer указываем на целевой сервер, на котором должна быть активирована копия базы; MountDialOverride — параметр для автоматического подключения базы (возможны варианты: None, Lossless, GoodAvailability, BestAvailability, BestEffort); Confirm — требование от администратора вводить подтверждение перемещения активной копии (необходимо отключать для скриптов). В данном примере мы перемещаем активную копию базы DB5 на сервер SERVER15 без переопределения автоматического переноса сервера; консоль не потребует подтвердить наши намерения.

Дизайн парной пары центра обработки данных на сайте

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

Хотя мы поддерживаем растяжение сайта Active Directory в нескольких центрах обработки данных, для центра обработки данных рекомендуется, чтобы каждый центр обработки данных был собственным сайтом Active Directory. Существует две причины:

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

Наблюдение

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

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

Настройка уведомлений мониторинга

В консоли администратора DPM щелкните Мониторинг > Действия > Параметры.
Щелкните SMTP-сервер, введите имя сервера, порт и электронный адрес, с которого будут отправляться уведомления. Адрес должен быть допустимым.
В разделе SMTP-сервер с проверкой подлинности введите имя пользователя и пароль. Имя пользователя и пароль должны относиться к доменной учетной записи пользователя, адрес которого используется в качестве адреса отправителя; в противном случае доставка уведомления не сработает.
Чтобы проверить параметры SMTP-сервера, щелкните Отправка тестового сообщения, введите адрес электронной почты, по которому DPM должен отправить тестовое сообщение, а затем нажмите кнопку ОК. Выберите Параметры > Уведомления и выберите типы оповещений, о которых необходимо уведомлять получателей. В элементе Получатели введите адрес электронной почты для каждого получателя, которому DPM должен отправлять копии уведомлений.
Чтобы проверить параметры SMTP-сервера, щелкните Отправить тестовое уведомление > ОК.

Публикация оповещений для Operations Manager

В консоли администратора DPM щелкните Мониторинг > Действия > Параметры.
В разделе Параметры щелкните Публикация оповещений > Публиковать активные оповещения.
После включения функции Публикация предупреждений все существующие оповещения DPM, которые могут потребовать действий пользователей, публикуются в журнале Оповещения DPM. Затем агент Operations Manager, установленной на сервере DPM, публикует эти оповещения в Operations Manager и продолжает обновлять консоль при создании новых оповещений.

Networking requirements

Use at least 1Gb connections for the DAG members but 10Gb is preferable
You can configure a DAG with a single network which will be used for MAPI and REPLICATION or you can set up two separate networks – one for MAPI and one for REPLICATION. The latter is preferred for performance and high availability although it adds some complexity.
If you’re using separate MAPI and REPLICATION networks, a MAPI network failure will cause a server failover. If the REPLICATION network fails then the MAPI network will be used for replication even if the RecplicationEnabled property on the network is set to False. Manual fail back to the REPLICATION network will be necessary if it is restored. To fail back, suspend and resume the mailbox database copy. The other option is to restart the Microsoft Exchange Replication service but this causes a brief outage.
Each DAG member requires the same number of networks and network adapters
Additional REPLICATION networks can be added and you can configure teaming on the REPLICATION network adapters although this does add complexity
Each DAG member must only have one MAPI network which needs to have access to other Exchange servers, DNS and AD
The MAPI network adapter for each server must be able to communicate with each other server’s MAPI network and should be the only network adapter configured with a default gateway
The REPLICATION network adapter for each server must be able to communicate with each other server’s REPLICATION network
The REPLICATION network should be isolated from other REPLICATION networks (if you’re using multiple REPLICATION networks) and also isolated from the MAPI network
Roundtrip latency must be lower than 500ms however you must also look at the effect of this latency on other services e.g. CAS services
Automatic Private IP Addressing (APIPA) for DAG members is not supported

Как проверить, что все получилось?

Чтобы убедиться, успешно ли создана копия базы данных почтовых ящиков, выполните одно из следующих действий:

В центре администрирования Exchange откройте раздел Серверы > Базы данных. Выберите базу данных, которая была скопирована. В области «Сведения» отображается состояние копии базы данных и индекса ее содержимого, а также текущая длина очереди копирования.
В командной Exchange управления запустите следующую команду, чтобы проверить, что копия базы данных почтовых ящиков создана и здорова.

Состояние самой копии и индекса содержимого должно быть указано как работоспособное.

Для чего необходимо резервное копирование Exchange с помощью DPM?

Собственные средства защиты обеспечивают:

Аварийное восстановление
Восстановление случайно удаленных элементов
Долгосрочное хранение данных.
Моментальные снимки базы данных на определенный момент времени

Требуется меньше групп обеспечения доступности (DAG) — собственная защита требует использования дополнительных почтовых серверов для размещения копий активных данных. Не следует рассчитывать на DAG для выполнения резервного копирования при наличии защиты DPM.
Более простое восстановление — DPM обеспечивает простое и централизованное восстановление данных из резервных копий на определенный момент времени.
Увеличенный диапазон хранения — DPM обеспечивает более длительное время хранения для резервных копий данных. Собственная защита ограничена сроком в 14 дней.
Согласованное резервное копирование рабочих нагрузок Майкрософт — DPM предоставляет централизованные и простые процессы резервного копирования и восстановления рабочих нагрузок Майкрософт, в том числе Exchange, файловых серверов, SQL Server, Hyper-V и SharePoint.

Наблюдение

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

Настройка уведомлений мониторинга

В консоли администратора DPM щелкните Мониторинг > Действия > Параметры.
Щелкните SMTP-сервер, введите имя сервера, порт и электронный адрес, с которого будут отправляться уведомления. Адрес должен быть допустимым.
В разделе SMTP-сервер с проверкой подлинности введите имя пользователя и пароль. Имя пользователя и пароль должны относиться к доменной учетной записи пользователя, адрес которого используется в качестве адреса отправителя; в противном случае доставка уведомления не сработает.
Чтобы проверить параметры SMTP-сервера, щелкните Отправка тестового сообщения, введите адрес электронной почты, по которому DPM должен отправить тестовое сообщение, а затем нажмите кнопку ОК. Выберите Параметры > Уведомления и выберите типы оповещений, о которых необходимо уведомлять получателей. В элементе Получатели введите адрес электронной почты для каждого получателя, которому DPM должен отправлять копии уведомлений.
Чтобы проверить параметры SMTP-сервера, щелкните Отправить тестовое уведомление > ОК.

Публикация оповещений для Operations Manager

В консоли администратора DPM щелкните Мониторинг > Действия > Параметры.
В разделе Параметры щелкните Публикация оповещений > Публиковать активные оповещения.
После включения функции Публикация предупреждений все существующие оповещения DPM, которые могут потребовать действий пользователей, публикуются в журнале Оповещения DPM. Затем агент Operations Manager, установленной на сервере DPM, публикует эти оповещения в Operations Manager и продолжает обновлять консоль при создании новых оповещений.

Переиндексация базы (восстановление поиска или репликации)

Данную процедуру необходимо выполнять, если наблюдаются проблемы с поиском в почте или репликации DAG-копии. Выполняется в Exchange Management Shell.

Одна копия базы

Переходим в каталог Exchange:

cd «\program files\microsoft\exchange server\v14\scripts»

Запускаем переиндексацию:

.\ResetSearchIndex.ps1 BASE1

При использовании DAG

Смотрим, у какой копии базы произошел сбой индекса:

Get-MailboxDatabaseCopyStatus -Identity DAG01 | Format-List Name, ContentIndexState

Пример ответа:

Name : DAG01\Server1
ContentIndexState : Failed

Name : DAG01\Server2
ContentIndexState : Healthy

Активируем копию базы на сервере с исправным индексом:

Запускаем копирование каталога с исправного сервера:

Делаем активной копию базы на старом сервере: