Базы данных Exchange 2013

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

Предлагаю начать издалека – с реализации некоторых лучших практик администрирования Exchange Server. Главным образом будут рассмотрены базы данных Exchange 2013 – их создание и необходимые настройки.

---

Если вы хотите сразу заняться настройкой Exchange для приема/отправки почты и пропустить обзор некоторых лучших практик, предлагаю перейти к головной статье непосредственно по настройке сервера – Настройка Exchange 2013  или основной статье тематики – Exchange 2013 — Установка, настройка, администрирование.

---

Разделение БД по назначению

Отличным началом будет разнесение по разным БД системных и пользовательских почтовых ящиков. Сценарий задачи – создать необходимое количество баз с нужными настройками и перенести существующие да данный момент почтовые ящики в нужные БД.

Подробнее о назначении каждого системного ящика в Exchange Server 2013 можно прочитать в моей недавней статье Системные почтовые ящики в Exchange 2013.

Краткий обзор системных почтовых ящиков дает понять, что они необходимы для нормальной работы Exchange. Исходя из этого, важно обеспечить сохранность этих ящиков и потому размещение их в отдельной БД выглядит более чем разумно. Сколько конкретно баз данных создавать, решать вам – вы можете создать по базе для каждого системного ящика, а можете всех их разместить в одной. Тут стоит упомянуть, что максимально доступное количество смонтированных баз данных зависит от редакции вашего сервера Exchange – 5 для Standard и 100 для Enterprise начиная с CU2 и более поздних версий ¹.

У себя я создам 4 БД: 3 ящика SystemMailbox будут храниться в первой базе, ящик Migration во второй, FedaratedEmail в третьей и DiscoverySearchMailbox в четвертой. Разделение исходя из максимального размера ящика по умолчанию. Повторюсь, что у себя в рабочей среде вы можете сделать как вам угодно. Суть в том, чтобы отделить системные ресурсы.

Для создания БД используем командлет New-MailboxDatabase ²:

[PS] C:\Windows\system32>New-MailboxDatabase -Server “EXCH02” -Name “System Database 01 – SystemMailbox” -EdbFilePath “D:\Program Files\Microsoft\Exchange Server\V15\Mailbox\System Database 01 – SystemMailbox\System Database 01 – SystemMailbox.edb” -LogFolderPath “D:\Program Files\Microsoft\Exchange Server\V15\Mailbox\System Database 01 – SystemMailbox”

Повторим команду для создания других баз:

Не обязательно использовать PowerShell, можно и через веб-интерфейс – Серверы/Базы данных/Создать – (значок “+”):

Также не забудьте в конце процедуры перезапустить службу Microsoft Exchange Transport. Если база находится в состоянии “Отключена”, подключите её через веб-интерфейс или с помощью командлета Mount-Database ³. У меня были отключены все созданные базы, я запустил их одной командой:

[PS] C:\Windows\system32>Get-MailboxDatabase  | Mount-Database

После того как базы созданы и подключены, необходимо перенести системные почтовые ящики. Для начала перенесем почтовые ящики с префиксом “SystemMailbox”. В моем примере перенос осуществляется с помощью командлета New-MoveRequest ⁴, которому передается вывод другого командлета – Get-Mailbox. Подробнее о перемещении ящиков между БД можно прочитать в моей статье – Перенос ящика в другую базу данных Exchange Server.

[PS] C:\Windows\system32>Get-Mailbox -Arbitration -Identity “SystemMailbox*” | New-MoveRequest -TargetDatabase “System Database 01 – SystemMailbox”

Если ящики занимают большой объем, не лишним будет понаблюдать над прогрессом переноса с помощью командлета Get-MoveRequestStatistics:

[PS] C:\Windows\system32>Get-Mailbox -Arbitration -Identity “SystemMailbox*” | Get-MoveRequestStatistics

Проверим результат переноса:

[PS] C:\Windows\system32>Get-Mailbox -Arbitration -Identity “SystemMailbox*” | fl Name, Database

Выполним следующие команды для перемещения оставшихся ящиков:

[PS] C:\Windows\system32>Get-Mailbox -Arbitration -Identity “Migration*” | New-MoveRequest -TargetDatabase “System Database 02 – Migration”
[PS] C:\Windows\system32>Get-Mailbox -Arbitration -Identity “FederatedEmail*” | New-MoveRequest -TargetDatabase “System Database 03 – FederatedEmail”
[PS] C:\Windows\system32>Get-Mailbox -Identity “DiscoverySearchMailbox*” | New-MoveRequest -TargetDatabase “System Database 04 – DiscoverySearchMailbox”
[PS] C:\Windows\system32>Get-Mailbox -Identity “bissquit*” | New-MoveRequest -TargetDatabase “User Database 01 – 2GB MB Size”

Для переноса ящика DiscoverySearchMailbox ключ -Arbitration не нужен, поскольку Exchange этот ящик системным фактически не считает. При установке сервера также автоматически создается пользовательский почтовый ящик для учетной записи, под которой идет установка Exchange. У меня учетка называется bissquit.

Перенести базы данных можно все также через веб-интерфейс – Получатели\Миграция – значок “+” – Переместить в другую базу данных.

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

[PS] C:\Windows\system32>Get-MailboxDatabase -Identity “Mailbox*” | Remove-MailboxDatabase

Кстати, первое предупреждение связано с отсутствием необходимых прав ⁵ у службы “Exchange Trusted Subsystem”.

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

Пользовательские базы данных Exchange 2013

После создания базы данных Exchange 2013 для пользователей необходимо изменить некоторые её настройки, о которых пойдет речь ниже.

Начать нужно с подключения автономной адресной книги. Можно выполнить командлет Get-OfflineAddressBook, если вы не знаете имя. Хотя единственная OAB создается при установке сервера и имеет имя по умолчанию “Default Offline Address Book”. Подробнее про OAB можно прочитать ещё в одной моей статье – Exchange 2013 OAB. Для заметки – в инфраструктуре из этой статьи имя OAB не менялось при установке, но оно отличается, поскольку, вероятнее всего, OAB мигрировала с предыдущей версии Exchange – 2010 (инфраструктура серверов из этой статьи была тестовой площадкой для обкатки миграции Exchange с 2010 на 2013 версию, но это было очень давно и все действия, к сожалению, я не задокументировал).

[PS] C:\Windows\system32>Set-MailboxDatabase -Identity “User Database 01 – 2GB MB Size” -OfflineAddressBook “Default Offline Address Book”

Чтобы привязать к БД нужную OAB через веб-интерфейс, необходимо пройти в Серверы\Базы данных – выделить нужную БД, нажать значок карандаша (Изменить) – Параметры клиента\Автономная адресная книга.

Системным БД подключение OAB ни к чему.

Подавляющее большинство организаций используют собственные политики хранения данных. Главным образом это касается максимального объема почтового ящика пользователей. При этом у сотрудников разных должностей чаще всего разные квоты на размеры ящика. Например у штатного сотрудника это может быть 2ГБ, у руководителя отдела – 4ГБ, у члена совета директоров – 16ГБ.

Обычно квоты объема ящика определяются на уровне базы данных и автоматически применяются ко всем ящикам, которые в этой базе находятся. Это очень удобно, поскольку вы точно знаете, что в конкретной базе все ящики имеют одну и ту же политику хранения данных. Тем не менее доступна возможность определения квот для каждого почтового ящика ⁶. Этот способ не очень удобен как с точки зрения учета, так и с точки зрения последующего администрирования – вы просто запутаетесь у кого сколько.

У себя на тестовой инфраструктуре, а также в продакшене, я использую несколько баз данных с разными квотами и при необходимости увеличения ящика пользователя, просто экспортирую его в другую БД. Разумеется у этой БД совсем другие – увеличенные – квоты на хранение. Учитывая, что перенос ящиков для пользователя происходит совсем незаметно и работоспособность ящика полностью сохраняется, этот вариант для меня является наиболее приемлемым.

Есть один нюанс – максимальный объем БД. Не беспокойтесь, никаких проблем с быстрой достижимостью этого объема нет, он равен без малого 16ТБ. Дело в том, что рекомендуется не доводить размер каждой БД до значения в 200ГБ согласно официальным рекомендациям Microsoft ⁷ для инфраструктуры стандартной конфигурации и 2ТБ для высокодоступной среды:

Database size
Stand-alone: supported or best practice
Supported: Approximately 16 terabytes.
Best practice:
200 gigabytes (GB) or less.
Provision for 120 percent of calculated maximum database size.

Database size
High availability: supported or best practice
Supported: Approximately 16 terabytes.
Best practice:
2 terabytes or less.
Provision for 120 percent of calculated maximum database size.

Стоит отметить тот факт, что в некоторых источниках я встречал рекомендуемое значение объема отдельно взятой базы данных Exchange 2013 не более 100ГБ. В вашей инфраструктуре могут быть утверждены другие максимальные объемы, отличающиеся как в меньшую, так и в большую степень. Это зависит от SLA на случай выхода серверов из строя, производительности серверного и сетевого оборудования и др.

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

[PS] C:\Windows\system32>Set-MailboxDatabase -Identity “User Database 01 – 2GB MB Size” -IssueWarningQuota 1920mb -ProhibitSendQuota 2gb -ProhibitSendReceiveQuota 2176mb

Через веб-интерфейс: Серверы\Базы данных – выделить нужную БД, нажать значок карандаша (Изменить) – Предельные значения.

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

Следующее изменение, о котором пойдет речь – включение циклического ведения журнала ⁸:

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

Стоит отметить, что включение циклического ведения журнала рекомендуется лишь в случае отказоустойчивой инфраструктуры Exchange (речь идет о DAG), в противном случае включение этой функции может сделать невозможным восстановление БД при возникновении каких-либо сбоев. По умолчанию функция отключена. Включить можно командой ⁹:

[PS] C:\Windows\system32>Set-MailboxDatabase “User Database 01 – 2GB MB Size” -CircularLoggingEnabled $True

Чтобы выполнить аналогичные действия через веб-интерфейс, достаточно поставить соответствующую галочку: Серверы\Базы данных – выделить нужную БД, нажать значок карандаша (Изменить)\Обслуживание – Включить циклическое ведение журнала.

У себя на тестовой инфраструктуре я это делать не стал.

Описанные выше настройки относятся к так называемым лучшим практикам и, по большому счету, не обязательны к исполнению. Тем не менее их применение в будущем может значительно облегчить жизнь админам. Есть ещё огромное множество советов касательно резервного копирования и восстановления, но эти рекомендации очень сильно привязаны к окружению и к требуемому уровню SLA. А я на этой ноте перейду к следующей части начальной настройки Exchange и в ней речь пойдет уже о необходимых изменениях, без которых нормальная работа почтового сервера Microsoft в принципе не возможна.