Бази даних Exchange 2013

www.microsoft.com

Після установки 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 в принципі не можлива.