Get-databaseavailabilitygroup

Рекомендации по сетевым возможностям подключения

Настоятельно рекомендуется использовать одни и те же сетевые соединения для обмена данными между узлами WSFC и репликами доступности. Использование отдельных сетевых соединений может привести к непредвиденному поведению в случае отказа даже некоторых из них.

Например, чтобы группа доступности поддерживала автоматический переход на другой ресурс, вторичная реплика, которая является участником обработки отказа, должна находиться в состоянии SYNCHRONIZED. В случае отказа (даже временного) сетевого соединения с этой вторичной репликой она переходит в состояние UNSYNCHRONIZED и не может начать повторную синхронизацию до тех пор, пока соединение не будет восстановлено. Если кластер WSFC запрашивает автоматический переход на другой ресурс, пока вторичная реплика не синхронизирована, автоматический переход на другой ресурс не выполняется.

Термины и определения

Отказоустойчивый кластер Windows Server (WSFC) — это группа независимых серверов, совместная работа которых позволяет повысить доступность приложений и служб.

Узел
Сервер, который является членом WSFC.

Ресурс кластера
Физическая или логическая сущность, которая может принадлежать узлу, которую можно переводить в режимы «в сети» и «вне сети», перемещать между узлами и которой можно управлять как объектом кластера. Ресурс кластера может принадлежать одновременно только одному узлу.

Роль
Коллекция ресурсов кластера, управляемая как единый объект кластера и предоставляющая определенные функциональные возможности. Для SQL Server ролью будет группа доступности AlwaysOn или экземпляр отказоустойчивого кластера AlwaysOn. Роль содержит все ресурсы кластера, необходимые для роли группы доступности или экземпляра отказоустойчивого кластера. Отработка отказа и восстановление размещения всегда выполняются в контексте ролей. Роль экземпляра отказоустойчивого кластера содержит ресурс IP-адреса, ресурс сетевого имени и ресурсы SQL Server. Роль группы доступности содержит ресурс группы доступности, а также, если настроен прослушиватель, ресурсы сетевого имени и IP-адреса.

Ресурс сетевого имени
Имя логического сервера, которое управляется как ресурс кластера. Ресурс сетевого имени должен использоваться с ресурсом IP-адреса. Для этих элементов могут требоваться объекты в доменных службах Active Directory или в службе доменных имен (DNS).

Зависимость ресурсов
Ресурс, от которого зависит другой ресурс. Если ресурс А зависит от ресурса Б, то Б является зависимостью А. Ресурс A невозможно будет запустить, если отсутствует ресурс Б.

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

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

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

Обязательный кворум
Процесс запуска кластера несмотря на то, что на связи недостаточное количество элементов для кворума.

Ручное удаление файлов журанала

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

Запускаем Exchange Management Shell. Переходим в каталог хранения базы данных, например:

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

* в данном примере подразумевается, что база находится в каталоге C:\Program Files\Microsoft\Exchange Server\V14\Mailbox\Base1.

Находим файл, в котором находится информация из контрольной точки фиксации журналов:

ls E*.chk

Результат будет, примерно, следующим:

Mode                LastWriteTime     Length Name
—-                ————-     —— —-
-a—        21.07.2019     11:18       8192 E05.chk

* в данном примере, нужный нам файл называется E05.chk.

Теперь узнаем последний файл журнала, действия из которого были занесены в базу Exchange:

eseutil /mk .\E05.chk

Мы получим информацию о фиксации журналов — нас интересует Checkpoint

…
LastFullBackupCheckpoint: (0x0,0,0)
Checkpoint: (0x561299,8,16)
FullBackup: (0x0,0,0)
…

* в данном примере для нас важно значение 561299. ..

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

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

Теперь можно удалять все файлы журналов (их название начинается с E<номер> и это txt-файлы), которые старше найденного нами файла.

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

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

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

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 — пространство, которое можно освободить при дефрагментации.

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

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

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

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

Если используется база на основе группы 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

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

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

В этом разделе.

Контрольный список. Требования (базы данных доступности)

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

Требования	Ссылка
Быть пользовательской базой данных. Системные базы данных не могут принадлежать к группе доступности.
Находиться на экземпляре SQL Server , на котором создана группа доступности, и быть доступной для экземпляра сервера.
Быть базой, доступной для чтения и записи. Базы данных только для чтения не могут быть добавлены в группу доступности.	sys.databases (is_read_only = 0)
Быть многопользовательской базой данных.	sys.databases (user_access = 0)
Не использовать параметр AUTO_CLOSE.	sys.databases (is_auto_close_on = 0)
Используйте модель полного восстановления (также известную как режим полного восстановления).	sys.databases (recovery_model = 1)
Необходима по крайней мере одна полная резервная копия базы данных. Примечание. После установки базы данных в режим полного восстановления потребуется полная резервная копия для включения цепочки журналов полного восстановления.	Создание полной резервной копии базы данных (SQL Server)
Не принадлежать ни к одной другой группе доступности.	sys.databases (group_database_id = NULL)
Не быть настроенной для зеркального отображения базы данных.	sys.database_mirroring (если база данных не участвует в зеркальном отображении, все столбцы с префиксом «mirroring_» имеют значение NULL)
Перед добавлением в группу доступности базы данных, в которой используется FILESTREAM, следует убедиться, что FILESTREAM поддерживается на всех экземплярах серверов, на которых размещены или будут размещены реплики доступности для группы доступности.	Включение и настройка FILESTREAM
Перед добавлением автономной базы данных в группу доступности убедитесь, что параметру сервера contained database authentication присвоено значение 1 на каждом экземпляре сервера, где размещена или будет размещена реплика доступности для группы доступности.	Параметр конфигурации сервера «проверка подлинности автономной базы данных»Параметры конфигурации сервера (SQL Server)

Примечание

Группы доступности AlwaysOn работает с любым поддерживаемым уровнем совместимости базы данных.

Ограничения (базы данных доступности)

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

  • Мастер создания группы доступности/Мастер добавления базы данных в группу доступности: Параметр Полная не поддерживается (на странице Выбор начальной синхронизации данных).

  • RESTORE WITH MOVE: для создания базы данных-получателя файлы базы данных должны иметь атрибут RESTORED WITH MOVE в каждом экземпляре SQL Server, в котором размещена вторичная реплика.

  • Воздействие на операции добавления файлов. Операция добавления файлов, выполняемая позднее в первичной реплике, может завершиться неудачей в базах данных-получателях. Эта ошибка может вызвать приостановку работы баз данных-получателей. Это, в свою очередь, вызовет переход дополнительных реплик в состояние NOT SYNCHRONIZING.

    

    

    

    

    

    

    

    

    

    

    Примечание

    Дополнительные сведения об отсутствии отклика на неудачную операцию добавления файла см. в разделе Устранение неполадок с операцией добавления файлов, давшей сбой (группы доступности AlwaysOn).

• Нельзя удалить базу данных, которая принадлежит какой-либо группе доступности.

Дальнейшие действия для баз данных, защищаемых прозрачным шифрованием

Если используется прозрачное шифрование данных (TDE), то сертификат или асимметричный ключ службы для создания и расшифровки других ключей должен быть одинаков на всех экземплярах сервера, где размещены реплики группы доступности. Дополнительные сведения см. в разделе Перемещение базы данных, защищаемой прозрачным шифрованием, в другой экземпляр SQL Server.

Связанные задачи (базы данных доступности)

Задача	Статья
Подготовка базы данных-получателя (вручную)	Подготовка базы данных-получателя для присоединения к группе доступности вручную (SQL Server)
Присоединение базы данных-получателя к группе доступности (вручную)	Присоединение базы данных-получателя к группе доступности (SQL Server)
Изменение числа баз данных доступности	Добавление базы данных в группу доступности (SQL Server)Удаление базы данных-получателя из группы доступности (SQL Server)Удаление базы данных-источника из группы доступности (SQL Server)

Moving the Active Database Copy to another DAG Member (aka Switchover)

Figure 3: Activating a Database Copy

This brings up the Activate a Database Copy wizard (Figure 4).

Figure 4: Activate Database Copy wizard

Here we can see the name of the database and on which DAG member it currently is mounted. To move the database copy to another DAG member, click Browse.

Figure 5: Selecting the server holding the database copy to be activated

When you have selected the DAG member on which the databse copy should be activated, click OK. Then decide if you want to change the database mount dial settings on the target mailbox server. As you can see in Figure 6 its set to None (change nothing) by default. If you want to change the current setting (set to Best Availability by default) instead choose Lossless, Best Effort, or Best Availability.

Figure 6: Automatic database mount dial settings

Here’s a description of each of the available database mount dial settings:

• Lossless: (when selecting Lossless the database will not mount automatically until all logs generated on the active database copy has been copied to the passive database copy)
• Good Availability: (when selecting Good Availability, the database will mount automatically as long as you have a copy queue length less than or equal to 6. If the copy queue holds more than 6 log files, the database will not mount)
• Best Effort: (with Best Effort the database will mount no matter the copy queue length. Be careful with this setting as you could loose a lot of mailbox data!)
• Best Availability: (with Best Availbility the database will mount automatically as long as the copy queue length is less than or equal to 12. If the copy queue length is more than 12, the database will not be able to mount)

Unless there’s a specific reason to chose another database mount dial override than the setting currently configured, leave this option at None. When you are ready to activate the database copy in the target mailbox server specified, click Move.

To activiate a database copy using the EMS, we can use the following command:

Preparing an Exchange Server 2010 SP1 or Later DAG Member for Updates

For Exchange 2010 with Service Pack 1 the process is a little easier thanks to some scripts provided by Microsoft. Open the Exchange Management Shell and navigate to the scripts folder on the Exchange server.

cd $exscripts

1	cd$exscripts

Next run the StartDagServerMaintenance.ps1 PowerShell script.

.\StartDagServerMaintenance.ps1 -serverName ho-ex2010-mb1

1	.\StartDagServerMaintenance.ps1-serverName ho-ex2010-mb1

The script will automatically do the following tasks for you:

• Calls Suspend-MailboxDatabaseCopy on the database copies.
• Pauses the node in Failover Clustering so that it can not become the Primary Active Manager.
• Suspends database activation on each mailbox database.
• Sets the DatabaseCopyAutoActivationPolicy to Blocked on the server.
• Moves databases and cluster group off of the designated server.

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

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

В этом разделе.

Контрольный список. Требования (базы данных доступности)

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

Требования	Ссылка
Быть пользовательской базой данных. Системные базы данных не могут принадлежать к группе доступности.
Находиться на экземпляре SQL Server , на котором создана группа доступности, и быть доступной для экземпляра сервера.
Быть базой, доступной для чтения и записи. Базы данных только для чтения не могут быть добавлены в группу доступности.	sys.databases (is_read_only = 0)
Быть многопользовательской базой данных.	sys.databases (user_access = 0)
Не использовать параметр AUTO_CLOSE.	sys.databases (is_auto_close_on = 0)
Используйте модель полного восстановления (также известную как режим полного восстановления).	sys.databases (recovery_model = 1)
Необходима по крайней мере одна полная резервная копия базы данных. Примечание. После установки базы данных в режим полного восстановления потребуется полная резервная копия для включения цепочки журналов полного восстановления.	Создание полной резервной копии базы данных (SQL Server)
Не принадлежать ни к одной другой группе доступности.	sys.databases (group_database_id = NULL)
Не быть настроенной для зеркального отображения базы данных.	sys.database_mirroring (если база данных не участвует в зеркальном отображении, все столбцы с префиксом «mirroring_» имеют значение NULL)
Перед добавлением в группу доступности базы данных, в которой используется FILESTREAM, следует убедиться, что FILESTREAM поддерживается на всех экземплярах серверов, на которых размещены или будут размещены реплики доступности для группы доступности.	Включение и настройка FILESTREAM
Перед добавлением автономной базы данных в группу доступности убедитесь, что параметру сервера contained database authentication присвоено значение 1 на каждом экземпляре сервера, где размещена или будет размещена реплика доступности для группы доступности.	Параметр конфигурации сервера «проверка подлинности автономной базы данных»Параметры конфигурации сервера (SQL Server)

Примечание

Группы доступности AlwaysOn работает с любым поддерживаемым уровнем совместимости базы данных.

Ограничения (базы данных доступности)

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

  • Мастер создания группы доступности/Мастер добавления базы данных в группу доступности: Параметр Полная не поддерживается (на странице Выбор начальной синхронизации данных).

  • RESTORE WITH MOVE: для создания базы данных-получателя файлы базы данных должны иметь атрибут RESTORED WITH MOVE в каждом экземпляре SQL Server, в котором размещена вторичная реплика.

  • Воздействие на операции добавления файлов. Операция добавления файлов, выполняемая позднее в первичной реплике, может завершиться неудачей в базах данных-получателях. Эта ошибка может вызвать приостановку работы баз данных-получателей. Это, в свою очередь, вызовет переход дополнительных реплик в состояние NOT SYNCHRONIZING.

    

    

    

    

    

    

    

    

    

    

    Примечание

    Дополнительные сведения об отсутствии отклика на неудачную операцию добавления файла см. в разделе Устранение неполадок с операцией добавления файлов, давшей сбой (группы доступности AlwaysOn).

• Нельзя удалить базу данных, которая принадлежит какой-либо группе доступности.

Дальнейшие действия для баз данных, защищаемых прозрачным шифрованием

Если используется прозрачное шифрование данных (TDE), то сертификат или асимметричный ключ службы для создания и расшифровки других ключей должен быть одинаков на всех экземплярах сервера, где размещены реплики группы доступности. Дополнительные сведения см. в разделе Перемещение базы данных, защищаемой прозрачным шифрованием, в другой экземпляр SQL Server.

Связанные задачи (базы данных доступности)

Задача	Статья
Подготовка базы данных-получателя (вручную)	Подготовка базы данных-получателя для присоединения к группе доступности вручную (SQL Server)
Присоединение базы данных-получателя к группе доступности (вручную)	Присоединение базы данных-получателя к группе доступности (SQL Server)
Изменение числа баз данных доступности	Добавление базы данных в группу доступности (SQL Server)Удаление базы данных-получателя из группы доступности (SQL Server)Удаление базы данных-источника из группы доступности (SQL Server)

Просмотр содержимого базы

1. Список элементов базы можно увидеть командой в Powershell:

Get-MailboxStatistics -Database «Base1»

* где Base1 — имя базы данных, содержимое которой необходимо посмотреть.

Важно отметить, что это могут быть уже перенесенные элементы. 2

Список действующих ящиков, находящихся в базе:

2. Список действующих ящиков, находящихся в базе:

Get-Mailbox | Where {$_.Database -eq «Base1»}

3. Размер почтовых ящиков в базе:

Get-Mailbox -Database Base1 | Get-MailboxStatistics | sort TotalItemSize -descending | ft DisplayName, TotalItemSize, ItemCount

4. Список всех элементов в базе и занимаемый ими размер:

Get-MailboxStatistics -Database Archive | Sort TotalItemSize -descending | ft DisplayName, TotalItemSize 

5. Посмотреть системные почтовые ящики:

Get-Mailbox -Arbitration | FL Name, DisplayName, ServerName, Database, AdminDisplayVersion

6. Установленные квоты

На все базы данных:

Get-MailboxDatabase | fl Name, *Quota

На конкретную базу:

Get-MailboxDatabase Base1 | fl Name, *Quota

Join Database Fails (SQL Server Error 35250)

This section discusses the possible causes and resolution of a failure to join secondary databases to the availability group because the connection to the primary replica is not active. This is the full error message:

Resolution:

Summary of steps is outlined below.

For detailed step-by-step instructions, please refer to Engine error MSSQLSERVER_35250

1. Ensure the endpoint is created and started.
2. Check if you can connect to the endpoint via Telnet and ensure no firewall rules are blocking connectivity
3. Check for errors in the system. You can query the sys.dm_hadr_availability_replica_states for the last_connect_error_number that may help you diagnose the join issue.
4. Ensure the endpoint is defined so it correctly matches the IP/port that AG is using.
5. Check whether the network service account has CONNECT permission to the endpoint.
6. Check for possible name resolution issues
7. Ensure your SQL Server is running a recent build (preferably the to protect from running into fixed issues.

Changing the Log file Replication Port

In Exchange 2007, the Microsoft Exchange Replication Service copies log files to the passive database copy (LCR), passive cluster node (CCR) or SCR target over Server Message Block (SMB). With DAGs in Exchange 2010, the asynchronous replication technology no longer relies on SMB. Instead, Exchange 2010 uses TCP/IP for log file copying and seeding and, even better; it provides the option of specifying which port you want to use for log file replication. By default, DAG uses TCP port 64327, but you are free to specify whatever port you want to use. To see the current port used, you must use the Get-AvailabilityGroup cmdlet with the –Status parameter. To see the port used in our lab environment, use:

Get-DatabaseAvailabilityGroup DAG1 –Status | fl

Figure 16: Checking Replication port settings for a DAG

To change the port used we must use Exchange Management Shell (EMS) as this option isn’t included in the Exchange Management Console (EMC). Since this setting is configured per DAG, we must use the Set-DatabaseAvailabilityGroup cmdlet.

For instance to change the port for the DAG in our lab to TCP port 7580, we must use the following command:

Set-DatabaseAvailabilityGroup DAG1 -ReplicationPort 7580

When the port have been changed, we can verify the new setting using:

Get-DatabaseAvailabilityGroup DAG1 –Status | fl ReplicationPort

Figure 17: Checking new Replication port settings for a DAG

Now when updating a database copy, we can see that TCP/7580 is used (below I ran Netstat –an while the database copy were updated.

Figure 18: Checking the new replication port is used (by running Netstat -an)

Описание

Объект компьютера для DAG создается в Active Directory при добавлении первого сервера в DAG. Этот объект используется для проверки подлинности серверов друг другом в группе DAG.

Чтобы добавить сервер почтовых ящиков в DAG, сервер почтовых ящиков должен работать с операционной системой Windows Server 2008 R2 Enterprise или Datacenter, операционной системой Windows Server 2012 Standard или datacenter или операционной системой Windows Server 2012 R2, и она не должна принадлежать к какой-либо другой операционной системе DAG. Сервер почтовых ящиков должен запускать те же версии операционной системы Windows и Microsoft Exchange и быть в том же домене Active Directory, что и все другие серверы почтовых ящиков в DAG. Кроме того, сервер почтовых ящиков не должен настраиваться как контроллер домена Active Directory или сервер глобального каталога.

Чтобы добавить первый сервер в DAG и создать объект компьютера для DAG, группа безопасности Exchange Windows разрешений должна иметь соответствующие права на добавление учетных записей компьютера в домен. Можно также создать учетную запись компьютера и отключить ее перед добавлением сервера. Добавление первого сервера в группу обеспечения доступности баз данных включает учетную запись компьютера для этой группы. Таким образом, учетной записи, используемой для этой задачи, не нужны разрешения на добавление учетной записи компьютера в домен. При предварительном создании учетной записи компьютера ее имя должно совпадать с именем данной группы. Например, если группа называется DAG1, учетная запись компьютера тоже должна называться DAG1.

Для его запуска необходимо получить соответствующие разрешения. В этой статье перечислены все параметры командлета. Но некоторые из них могут быть вам не доступны, если они не включены в назначенные разрешения. Сведения о необходимых разрешениях для запуска командлетов и использования параметров в организации см. в статье Find the permissions required to run any Exchange cmdlet.

Особенности установки программы в группе доступности баз данных Microsoft Exchange

Программа Kaspersky Security может быть установлена на серверах, входящих в группу доступности баз данных Microsoft Exchange (группу DAG). В этом случае Сервер безопасности и Консоль управления устанавливаются вместе на каждом сервере Microsoft Exchange, входящем в группу DAG. Вы можете дополнительно установить Консоль управления на любой другой компьютер в сети вашей организации для удаленного управления Серверами безопасности.

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

Установка Kaspersky Security в группе доступности баз данных имеет следующие особенности:

• Требуется использовать единую базу данных для всех узлов группы DAG. Для этого вам нужно указать эту базу данных при установке Kaspersky Security на всех узлах группы DAG.
• Учетная запись, от имени которой выполняется установка, должна иметь права на запись в раздел конфигурации Active Directory.
• Если на серверах, входящих в группу DAG, включен брандмауэр, вам нужно добавить службу Kaspersky Security для Microsoft Exchange Servers в список доверенных программ на каждом сервере, входящем в группу DAG. Это необходимо для работы Kaspersky Security с резервным хранилищем.

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

После установки программы на серверах группы DAG большая часть параметров программы хранится в Active Directory, и все серверы, входящие в группу DAG, работают с этими параметрами. Kaspersky Security автоматически определяет активные серверы и распространяет на них конфигурацию из Active Directory. Однако индивидуальные параметры сервера Microsoft Exchange требуется настроить вручную для каждого сервера. Индивидуальными параметрами сервера Microsoft Exchange являются, например, параметры антивирусной защиты для роли Транспортный концентратор, параметры проверки на спам, параметры резервного хранилища, параметры отчетов о работе Анти-Спама и работе Антивируса для роли Транспортный концентратор, параметры обновления баз Анти-Спама.

Использование профилей для настройки параметров серверов, входящих в группу DAG, имеет следующие особенности:

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

После удаления Kaspersky Security с серверов в составе группы DAG конфигурация хранится в Active Directory и может быть использована при повторной установке программы.

Configure DAG in Exchange 2010

Configuring DAG (Database Availability Group) in Exchange 2010 is a straightforward process.  Note following points before you start configuring DAG in Exchange 2010.

• A unique name for DAG is required which can be not more than 15 characters long.
• A dedicated additional IP address is recommended on the MAPI network subnet for the mailbox server.
• Installing Mailbox server role on at least two Exchange Servers.
• Exchange Server will automatically configure Hub Transport server as a witness server.
• Based on your scenario you might want to configure an alternate witness server.

Our environment involves the following setup

• MBG-CAS01: Running CAS and Hub Transport roles
• MBG-CAS02: Running CAS and Hub Transport roles
• MBG-MBX01: Running Mailbox Server role
• MBG-MBX02: Running Mailbox Server role
• DAG NAME: MBGDAG01

Below is the representation of our intended setup for configuring DAG:

Step 2: Configuring DAG from Exchange Management Console

From the Console Root Select Organization Configuration  →  Mailbox.  In the right panel click on Database Availability Tab.  From the action pane click on New Database Availability Group.

Type in the DAG name MBGDAG01 and click New.

Once the DAG is created successfully, the wizard will show the completion screen as shown below.

Now the DAG is ready we need to assign an IP Address, type the following command in the Exchange management shell.  This IP should be fromt he

set-DatabaseAvailabilityGroup -Identity MBGDAG01 -DatabaseAvailabilityGroupIpAddresses 10.10.10.103

You may note that we have not specified any witness server in the New Database Availability Group wizard.  However, Exchange will identify a Server with Hub Transport Role, select it as a witness server and creates the Witness Server folder automatically.  As you can see in the below screenshot, DAG witness file share is created on MBG-CAS01 ( running both CAS and Hub Transport Roles).

We have created the DAG successfully, now we will have to add member servers to the DAG.  From the Database Availability Group Tab right-click on the newly created DAG MBGDAG01 and click Manage Database Availability Group Membership.

Click on the +Add button to add member serves to the DAG.  As per my scenario I will be selecting both MBG-MBX01 and MBG-MBX02 and adding them to the DAG, and then Click Manage

Configuring DAG through Exchange Management Shell:

Create a new DAG by using following command

New-DatabaseAvailabilityGroup -Name MBGDAG01 -DatabaseAvailabilityGroupIpAddresses 10.10.10.103

Add Member servers to the DAG by Issuing the following Command:

Add-DatabaseAvailabilityGroupServer -Identity MBGDAG01 -MailboxServer MBG-MBX02
Add-DatabaseAvailabilityGroupServer -Identity MBGDAG01 -MailboxServer MBG-MBX01

Step 03:  Configure the DAG to Replicate Mailbox Databases only on the Replication Network

After adding both servers to the Database Availability Group, you will see the following in the Exchange Management Console:

The above screen shows that replication is enabled on both MAPI and Replication Network.  But as per our scenario, we must enable replication only on a dedicated NIC configured for replication.  To this right click on the MAPI network name and click properties as shown below.

In the MAPI network properties of the DAG, uncheck the option “Enable Replication” and then click OK as shown below.

Once you disable the replication on the MAPI network, now the database will only replicate on the Replication network (10.10.10.101/30). In this way you can configure DAG in exchange 2010.

The following two tabs change content below.

Bipin is a freelance Network and System Engineer with expertise on Cisco, Juniper, Microsoft, VMware, and other technologies. You can hire him on UpWork. Bipin enjoys writing articles and tutorials related to Network technologies. Some of his certifications are, MCSE:Messaging, JNCIP-SEC, JNCIS-ENT, and others.

• Install Exchange 2019 in Windows Server 2019 — November 28, 2020
• Why Backup your Microsoft Office 365 — November 27, 2020
• What’s New in VMware vSphere 7 — September 18, 2020