Вступна.

Є два ліси AD. Кожен ліс складається з одного домену: forest1.localі forest2.local. В одному лісі (forest1) розташовані облікові записикористувачів. В іншому лісі (forest2) розгорнуто організацію Exchange 2010 SP3, де знаходяться поштові скриньки користувачів з forest1. Відображення облікових записів користувачів немає.

Завдання.

Розгорнути в forest1 організацію Exchange 2010 і перенести контент користувача поштових скриньокз forest2 до forest1.

Опис інфраструктури.

Forest1

forest1.local

• forest1-dc1.forest1.local- контролер домену


• forest1-cas1.forest1.local


• forest1-mbx1.forest1.local


• forest1-tmg1.forest1.local

Принцип іменування користувачів - [перша буква імені] [прізвище]. Наприклад, Іван Іванов - iivanov

Forest2

Ліс AD, що складається з одного домену - forest2.local

У лісі розгорнуто такі сервери:

• forest2-dc1.forest2.local- контролер домену


• forest2-cas1.forest2.local- сервер Exchange 2010 SP3 (CAS та Hub)


• forest2-mbx1.forest2.local- сервер Exchange 2010 SP3 (Mailbox)


• forest2-tmg1.forest2.local - міжмережевий екран, проксі, зворотний (реверсний, реверсивний тощо) проксі

Принцип іменування користувачів – [ім'я]. [прізвище]. Наприклад, Іван Іванов - ivan.ivanov

Організація Exchange обслуговує SMTP домен - forest.com. Користувачі отримують доступ до поштових скриньок за допомогою Outlook Anywhere, OWA, ActiveSync.

Перенесення поштових скриньок.

Підготовка інфраструктури мережі.

Перед початком перенесення поштових скриньок необхідно виконати кілька попередніх умов:

• Забезпечити маршрутизацію трафіку між двома лісами (VPN Site-To-Site тощо).


• Налаштувати взаємне розіменування внутрішніх імен (передача зони, зони-заглушки, умовне пересилання тощо)


• Впевнитися, що сервера Exchangeв обох організаціях довіряють сертифікати один одного.

Підготовка серверів клієнтського доступу.

Ініціювати передачу контенту поштової скриньки можна як з вихідного лісу (у моєму прикладі -forest2), так і з кінцевого лісу (у моєму прикладі - forest1). Якщо команда на переміщення ініціюється з кінцевого лісу, то параметр має бути дозволено у вихідному лісі. Якщо команда переміщення ініціюється з вихідного лісу, то параметр Mailbox Replication Service Proxy (MRS Proxy)повинен бути дозволений у кінцевому лісі.

Я ініціюватиму перенесення контенту поштових скриньок з кінцевого лісу, тому включити MRS Proxy я повинен на сервері forest2-cas1.forest2.local.

Set-WebServicesVirtualDirectory -Identity "Forest2-Cas1\EWS (Default Web Site)" -MRSProxyEnabled $true

Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory -MRSProxyEnabled $true

Підготовка облікових записів користувача в кінцевому лісі.

Я буду переносити пошту для користувача Семен Петров, який має такі параметри:

• Ім'я, що відображається в обох лісах - Семен Петров


• Ім'я користувача в Forest1 - spetrov


• Ім'я користувача у Forest2 - semen.petrov


• Поштова адреса - [email protected]

Перед початком перенесення контенту необхідно підготувати облікові записи користувача в кінцевому лісі (forest1). Це виконується у два етапи.

Перший етап підготовки облікових записів користувача в кінцевому лісі.

На першому кроці необхідно всіх користувачів у кінцевому лісі, чиї поштові скриньки переноситимуться, зробити користувачами з увімкненою підтримкою пошти (Mail User).

Другий етап підготовки облікових записів користувача в кінцевому лісі.

На другому кроці необхідно за допомогою скрипту Prepare-MoveRequest.ps1скопіювати деякі атрибути користувача з вихідного лісу.

Prepare-MoveRequest.ps1 -Identity ‘ [email protected]' -RemoteForestDomainController forest2-dc1.forest2.local -RemoteForestCredential (Get-Credential forest2\adm) -UseLocalObject

Я передаю до скрипту параметр -UseLocalObject. Це потрібно зробити, т.к. у мене в кінцевому лісі вже існує користувач із включеною підтримкою пошти.

Перенесення контенту поштової скриньки з вихідного лісу до кінцевого лісу.

Перенесення контенту здійснюється за допомогою командлету New-MoveRequest.

New-MoveRequest -Identity "semen.petrov" -Remote -RemoteHostName forest2-cas1.forest2.local -RemoteCredential (Get-Credential forest2\adm) -TargetDeliveryDomain "forest1.local"

Що в цей час відбувається у користувача?

Після перенесення контенту поштової скриньки користувача з'явиться наступне повідомлення:

Після перезапуску Outlook користувачпідключитися до сервера Exchange, який розташований у його власному лісі.

Я пояснював підхід переміщення поштових скриньок, що використовується в Exchange 2007. Це в основному робота з Move-Mailboxкомандою Exchange Management Shell, хоча, звичайно, можна використовувати консоль управління Exchange Management Console для переміщення поштових скриньок. У Exchange 2010 також можна переміщувати поштові скриньки за допомогою консолі керування Exchange Management Console та оболонки Exchange Management Shell, хоча в сам процес було внесено низку змін. У цьому циклі статтею з трьох частин я розповім про те, як переміщувати поштові скриньки в Exchange 2010 і більшою мірою акцентуватиму увагу на нової функції Move Request.

Запити переміщення (Move Requests)

Отже, хочу почати статтю, сказавши, що команда Move-Mailbox більше не доступна в Exchange 2010. Весь підхід до переміщення поштових скриньок у Exchange 2010 сконцентрований навколо функції під назвою запити переміщення (move requests). Оскільки команда Move-Mailbox більше не використовується, виходить, що ви не можете скористатися Exchange 2007 Move-Mailbox командою для переміщення поштових скриньок з Exchange 2007 до Exchange 2010; вам доведеться використовувати функцію запитів про переміщення продукту Exchange 2010.

Запит переміщення створюється адміністратором Exchange за допомогою консолі керування Exchange Management Console або Exchange Management Shell. У цій статті я зосереджу увагу на переміщенні поштових скриньок в одному лісі. Такий тип переміщення називають локальним запитом переміщення (local move request). Коли ви переміщаєте поштові скриньки між лісами, цей тип називається віддалений запит переміщення (remote move requests). Видалені запити переміщення розглядатимуться у наступних статтях тут на MSExchange.org.

Команди, що є частиною запиту переміщення, виконуються службою Microsoft Exchange Mailbox Replication ServiceЦе нова служба в Exchange 2010, яка працює на ролі сервера Client Access Server. Ця служба показана малюнку 1.

Рисунок 1: Microsoft Exchange Mailbox Replication Service

Запит переміщення містить спеціальне системне повідомлення до системної поштової скриньки бази даних поштових скриньок. Служба Microsoft Exchange Mailbox Replication повіряє вміст системної поштової скриньки у кожній базі даних поштових скриньок щодо наявності там запиту переміщення, після чого обробляє такі запити відповідним чином. Є багато переваг переміщення поштових скриньок за допомогою цієї служби. Ось три основні області, з якими я зазвичай стикаюся у процесі реалізації проектів міграції, які виправлені цими запитами переміщення:

• Поштові скриньки можна переміщувати в режимі онлайн, навіть коли користувачі увійшли до них. Така можливість доступна, лише якщо поштові скриньки працюють під керуванням Exchange 2007 SP2 або більше пізньої версії, або Exchange 2010. Однак це дуже корисне доповнення до процесу переміщення поштових скриньок загалом, оскільки воно допоможе уникнути необхідності переміщення поштових скриньок у неробочий час.
• Об'єкти в кошику тепер переміщуються як частина процесу. У попередніх версіях Exchange переміщення поштових скриньок не переміщувало об'єкти кошика, тому користувачеві потрібно було відновлювати всі віддалені об'єкти назад у поштову скриньку, перш ніж перемістити його. Можна було легко забути проінформувати користувачів про це, і в деяких випадках користувачі, чиї поштові скриньки були переміщені, намагаючись відновити об'єкти з кошика, виявляли, що кошик порожній.
• Вміст поштових скриньок більше не обробляється комп'ютером, з якого відбувається переміщення. Найчастіше в Exchange 2007 було так, що команда Move-Mailbox або пов'язаний з нею сценарій виконувався на машині адміністратора, а не на цільовому сервері Exchange 2007. Однак у такому сценарії вміст поштової скриньки переміщається з вихідної бази даних на машину адміністратора, а потім у цільову базу даних. Такого сценарію можна було уникнути шляхом виконання команди або командного сценаріюбезпосередньо на сервері цільової бази даних. У Exchange 2010 ця ситуація більше не буде зустрічатися, оскільки переміщення поштової скриньки виконується службою Microsoft Exchange Mailbox Replication, яка працює на сервері Client Access Server.

Коли я вперше прочитав про те, що служба Microsoft Exchange Mailbox Replication на кожному сервері Client Access Server відповідає за обробку переміщень поштових скриньок, мені стало цікаво, як наявність кількох серверів Client Access Server вплине на переміщення. Наприклад, чи будуть два сервери Client Access Servers намагатися перемістити ту саму поштову скриньку одночасно? На щастя, Microsoft повідомили, що був застосований загальний механізмміж усіма серверами Client Access Servers одного сайту Active Directory, щоб уникнути таких ситуацій.

Створення локального запиту переміщення

Тепер, коли ми трохи розібралися із запитами переміщення, настав час подивитися, як на практиці можна перемістити поштову скриньку за допомогою цієї нової функції. Почнемо з того, як створювати локальний запит переміщення за допомогою консолі Exchange Management Console.

1. Коли консоль Exchange Management Console завантажена, розгорніть Конфігурацію одержувача (Recipient Configuration)у дереві консолі. У вузлі Recipient Configuration виберіть об'єкт Поштова скринька (Mailbox), який відображає список усіх поштових скриньок на панелі результатів.
2. На цьому етапі потрібно вибрати поштові скриньки, які потрібно перемістити. Ви можете вибрати кілька поштових скриньок, які будуть переміщені одночасно.
3. Коли ви вибрали поштові скриньки для переміщення, виберіть опцію Новий локальний запит переміщення (New Local Move Request)на панелі дій, або натисніть правою клавішею на об'єкті Mailbox і виберіть цю опцію з контекстного меню, як показано на малюнку 2.

Малюнок 2: Створення нового локального запиту переміщення

1. У вас запуститься майстер New Local Move Request Wizardта відобразить вступну сторінку Introduction, як показано на малюнку 3. На цій сторінці будуть відображені обрані поштові скриньки, а також важлива інформація, що включає базу даних поштових скриньок, в якій Наразірозташовані ці поштові скриньки.

Малюнок 3: Вступна сторінка майстра New Local Move Request

1. На вступній сторінці натисніть кнопку Огляд (Browse), яка викличе вікно вибору бази даних поштової скриньки (Select Mailbox Database)Як показано на малюнку 4. Це вікно відобразить бази даних, які доступні на всіх серверах вашої організації. У своєму прикладі я просто переміщу поштову скриньку з бази даних Mailbox Database 001в Mailbox Database 002на одному сервері з ім'ям DAG1. Таким чином, я просто вибираю цю базу даних та натискаю OK.

Рисунок 4: Сторінка вибору бази даних поштових скриньок

1. Тепер на вступній сторінці поле бази даних має бути заповнене ім'ям бази даних. Натисніть Далі (Next).
2. Далі відкриється вікно опцій переміщення (Move Options)Як показано на малюнку 5. Це вікно має бути вам знайоме, якщо ви використовували попередні версії Exchange. Тут ви можете вказати, як обробляти пошкоджені повідомлення, якщо вони будуть знайдені у вихідній базі даних. Тут у вас є опція повністю пропустити поштову скриньку, або дозволити певну кількість пошкоджених повідомлень. Тут немає правильних або неправильних налаштувань, все залежить від того, як у вашій організації ставляться до втрати даних. На малюнку нижче я вибрав опцію пропуску поштової скриньки повністю; якщо будь-які пошкоджені елементи будуть знайдені, поштову скриньку не буде переміщено. Потім я перегляну базу даних за допомогою таких утиліт, як ISINTEG щодо можливості виправлення пошкоджень.

Рисунок 5: Сторінка опцій переміщення

1. Як тільки ви вибрали відповідні параметри на сторінці опцій переміщення, натисніть Далі. Це відобразить фінальну сторінку, де ви зможете переглянути інформацію про конфігурацію, перш ніж натиснути кнопку Новий (New)створення локального запиту переміщення.
2. Після цього локальний запит переміщення буде створено та надіслано серверу Client Access Server; майстри можна закрити.

Створення запиту про переміщення за допомогою PowerShell

Для створення локального запиту переміщення за допомогою оболонки Exchange Management Shell можна скористатися командою New-MoveRequestта пов'язаними з нею параметрами. Проста командадля створення локального запиту переміщення для переміщення однієї поштової скриньки з однієї бази даних до іншої може виглядати так:

New-MoveRequest "Identity neil "TargetDatabase "Mailbox Database 004"

Тут параметр Identityвикористовується для вказівки поштової скриньки, яка буде переміщена, а параметр TargetDatabaseвказує базу даних, до якої буде переміщено поштову скриньку. Виконання цієї команди створить результати, подібні до тих, що показані на малюнку 6.

Рисунок 6: Команда New-MoveRequest

На малюнку 6 ви помітите, що деяка інформація в стовпцях дещо неясна. стандартне форматування, що використовується в Exchange Management Shell. Щоб виправити цю ситуацію, можна прогнати результати команди New-MoveRequest через команду format-table(скорочену до ft у прикладі нижче), а також скористатися параметрами "AutoSizeі "Wrap, як показано в цьому прикладі:

New-MoveRequest "Identity neil" TargetDatabase "Mailbox Database 004" | ft "AutoSize-Wrap

Це надає результати, подібні до тих, що показані на малюнку 7, що значно спрощує читання даних.

Малюнок 7: Форматована команда New-MoveRequest

Тут я також хочу згадати про помилку, з якою ви можете зустрітися на даному етапі. Якщо я зараз спробую перемістити ту саму поштову скриньку в іншу базу даних, я отримаю таке повідомлення про помилку:

Mailbox (name) has completed move request associated with it. Після того, як ви створили новий прийом ретельності для електронної пошти, запустіть Remove-MoveRequest cmdlet для очищення повноцінного процесу.

Це повідомлення про помилку показано малюнку 8.

Малюнок 8: Помилка New-MoveRequest

Як йдеться в повідомленні про помилку, для поштової скриньки вже є повний запитпереміщення, яке потрібно видалити, перш ніж створювати інші запити переміщення. Таким чином, це означає, що запит переміщення має бути видалено відразу після його виконання.

Примітка:запити переміщення не видаляються автоматично навіть при успішному переміщенні поштової скриньки. Це також має наслідки для видалення баз даних поштових скриньок, які ми розглянемо пізніше у цьому циклі статей. Ми також розглянемо далі.

Команда New-MoveRequest містить багато доступних параметрів, які можна використовувати для керування запитами переміщення. Як ви, можливо, очікували, якщо знайомі з Exchange 2007, в оболонці Exchange Management Shell є більше способівконтролю запиту переміщення, ніж у консолі Exchange Management Console. Повний списоквсіх параметрів можна знайти, але в цій статті я опишу кілька самих важливих параметрів:

• BadItemLimit -Як було показано на малюнку 5, можна вирішувати, скільки пошкоджених елементів поштової скриньки програма може допускати при переміщенні скриньки. У Exchange Management Shell параметр BadItemLimit керує цією настройкою.
• BatchName -це корисний параметр, що дозволяє вказувати ім'я пакета під час переміщення кількох поштових скриньок. Потім можна використовувати це ім'я пакета для пошуку конкретних поштових скриньок під час використання команди Get-MoveRequest, про що я розповім у третій частині цього циклу.
• IgnoreRuleLimitErrors -якщо ви зіткнетеся з помилками обмеження правил під час переміщення поштової скриньки, ви можете не переміщати правило користувача як частину поштової скриньки. Цей параметр дозволяє вам це робити. Наприклад, ви можете змінити параметри запиту переміщення після надання, щоб переконатися, що правила не обробляються. Про це ми також поговоримо у третій частині циклу.
• MRSServer -зазвичай, запит переміщення обробляється одним сервером Client Access Servers сайту Active Directory. Щоб вказати конкретний сервер Client Access Server, використовуйте параметр MRSServer разом із Fully Qualified Domain Name (FQDN) іменем сервера Client Access Server.
• SuspendWhenReadyToComplete -цей параметр використовується для призупинення запиту переміщення, перш ніж поштова скринька буде остаточно переміщена до цільової бази. Тобто всі дійсні дані поштової скриньки переміщаються, але остаточне переміщення не відбувається, поки адміністратор не відновить переміщення за допомогою команди Resume-MoveRequest. Однією із ситуацій, у яких можна використовувати такий підхід, буде ситуація отримання остаточного схвалення на переміщення поштової скриньки. Цей параметр буде розглянуто у третій частині цього циклу статей.

Управління цільовими базами даних

Цікавим є те, що параметр TargetDatabase команди New-MoveRequest насправді є необов'язковим. У прикладах, наведених на початку цієї статті, видно, що цей параметр використовувався, щоб переконатися, що поштова скринька була переміщена в базу під назвою Mailbox Database 004. Якщо ви виключите параметр TargetDatabase, процес запиту переміщення автоматично вибере базу даних.

Якщо у вас одна і більше баз даних поштових скриньок, які ви хочете виключити з цього процесу вибору, ви можете змінити значення параметра Це виключено звідповідностібази даних, яку бажаєте виключити. Цей параметр показано на малюнку 9, де він вказаний у значенні за замовчуванням false, що означає, що база даних доступна для заповнення поштових скриньок. Якби я хотів змінити значення цього параметра для бази даних Mailbox Database 004 на true, я виконав би наступну команду:

Set-MailboxDatabase "Mailbox Database 004" "IsExcludedFromProvisioning $True

Рисунок 9: Виключення баз поштових скриньок із запиту переміщення

Управління запитами переміщення

Тепер, коли створено локальний запит переміщення, вам потрібно відстежити його прогрес. У консолі Exchange Management Console натисніть об'єкт Move Request, розташований у вузлі Recipient Configurationу дереві консолі. Це викличе вікно подібне до того, що показано на малюнку 10. На цьому малюнку я видалив панель дій для більшої ясності.

Малюнок 10: Управління запитом переміщення

Тут видно, що відображено перелік запитів переміщення. На даний момент у прогресі знаходиться лише один запит переміщення та поле стану запиту Move Request Statusпоказує статус переміщення Moving. За замовчуванням у консолі відображаються лише поля Ім'я дисплея (Display Name), Псевдонім (Alias), Стан запиту переміщення (Move Request Status) та Тип запиту переміщення (Move Request Type). Є два способи розширити інформацію, яка буде доступна вам:

1. У консолі Exchange Management Console виберіть меню Вид (View), потім опцію Додати або видалити стовпці (Add/Remove Columns), щоб викликати вікно Add/Remove Columns, як показано малюнку 11. Тут видно, що поля Ім'я (Name), Ім'я віддаленого хоста(Remote Host Name), Вихідна база даних (Source Database) та Цільова база даних (Target Database) також доступні. Використовуючи різні кнопки на екрані, ви можете вказувати, які додаткові поля відображати, а також порядок, в якому вони будуть відображені.

Рисунок 11: Додавання додаткових інформаційних стовпців

1. Іншим способом додавання інформації до консолі Exchange Management Console є перегляд властивостей запиту переміщення. Для цього просто натисніть правою клавішею на запит переміщення і виберіть Властивості (Properties)в контекстному меню. Це викликає вікно властивостей запиту переміщення, схоже на те, що відображено на малюнку 12.

Рисунок 12: Властивості запиту переміщення

Одним із найцікавіших полів, представлених на малюнках 10 та 12, є поле стану Move Request Status. На малюнку 12 видно, що стан вказано як Completing, але звичайно це поле може набувати і таких значень, як InProgress, Completed, Failedі т.д. Це дозволяє бачити, на якій стадії знаходиться запит переміщення в загальному процесі.

Управління запитами переміщення

Оболонку Exchange Management Shell можна використовувати для перегляду того, як просується запит переміщення за допомогою команди Get-MoveRequest. У стандартному стані команда Get-MoveRequest поверне результати всіх доступних запитів переміщення. Для прикладу подивіться на рисунок 13, де показаний зразок інформації, повернутою командою Get-MoveRequest. Тут показано лише один запит переміщення, а також видно, що моя поштова скринька була переміщена в цільову базу даних під назвою TEST. Ви також бачите, що запит переміщення завершено.

Малюнок 13: Результати Get-MoveRequest

Як і у випадку з командою New-MoveRequest, для цієї команди також є безліч параметрів Get-MoveRequest. Повний список параметрів можна знайти. Декількома з найважливіших параметрів є наступні:

MoveStatus: за допомогою цього параметра можна використовувати результати команди Get-MoveRequest для отримання запитів переміщення лише з певним станом. Наприклад, якщо вам потрібно переглянути всі запити про переміщення зі статусом InProgress, потрібно використовувати наступну команду:

Get-MoveRequest "MoveStatus InProgress

Приклад результатів такої команди показаний малюнку 14. Дійсними параметрами статусу будуть None, Queued, InProgress, AutoSuspended, CompletionInProgress, Completed, CompletedWithWarning, Suspendedі Failed.

SourceDatabase:цей параметр показує всі поштові скриньки, які переміщуються з певної бази даних, тому він корисний для визначення навантаження на вихідний сервер поштових скриньок.

SuspendWhenReadyToComplete:цей параметр використовується для припинення запитів переміщення, перш ніж ящик буде остаточно переміщений до цільової бази даних. Про цей параметр ми поговоримо трохи згодом.

TargetDatabase:цей параметр схожий на SourceDatabase, за винятком того, що він показує цільову базу.

Призупинення запиту переміщення

Як ми коротко розглянули у другій частині цього циклу та у попередньому розділі, команди New-MoveRequest та Get-MoveRequest включають SuspendWhenReadyToCompleteпараметр, який використовується для призупинення запиту переміщення, перш ніж остаточне місце для цільової бази даних буде оновлено. З таким підходом дані поштової скриньки переміщуються, проте останнє перемикання здійснюється лише після того, як зупинений запит переміщення знову запущено. Також можна призупинити існуючий запит переміщення за допомогою команди Suspend-MoveRequest.

Давайте розглянемо використання параметра SuspendWhenReadyToComplete для команди New-MoveRequest. Прикладом команди для виконання буде:

New-MoveRequest "Identity neil" SuspendWhenReadyToComplete

Якщо ви читали попередні частини цього циклу, ви помітите, що команда вище не включає параметр TargetDatabaseдля вказівки будь-якої певної бази даних, до якої буде переміщено скриньку. Без цього параметра базу даних буде вибрано системою.

Як ми вже говорили, процес переміщення поштової скриньки буде відкладено, доки не відбудеться остаточне переміщення. Його можна налаштувати за допомогою виконання команди Get-MoveRequest. Погляньте на малюнок 15, де видно, що поштова скринька була переміщена за допомогою параметра SuspendWhenReadyToComplete. Трохи пізніше статус цього запиту переміщення набуде значення InProgress, та вміст поштової скриньки переміщується. Після чергового оновлення команда Get-MoveRequest покаже, що статус запиту тепер змінився AutoSuspended, а такий статус відображається при використанні параметра SuspendWhenReadyToComplete. Подібно до цього консоль Exchange Management Console показує цей статус, як видно на малюнку 16.

Рисунок 15: Зупинений запит переміщення Exchange Management Shell

Малюнок 16: Зупинений запит переміщення Exchange Management Console

Коли адміністратор вирішить, що можна завершити рух, запит переміщення можна відновити виконанням команди Resume-MoveRequestз наступним синтаксисом:

Resume-MoveRequest "Identity neil

Коли цю команду виконано, повторний запуск команди Get-MoveRequest має показати статус Completed.

Пакетні імена (Batch Names)

У попередній частині цього циклу ми розглянули параметри команди New-MoveRequest і побачили, що один із цих параметрів називається BatchName. За допомогою цього параметра можна вказати ім'я пакета при переміщенні кількох поштових скриньок, яке можна використовувати з командою Get-MoveRequest для пошуку певних пакетів переміщення поштових скриньок.

Імена пакетів цілком корисні при переміщенні вмісту однієї бази поштових скриньок до іншої. Щоб спростити все, я просто створюю два запити для однакових поштових скриньок і призначу кожному різні імена пакетів. Потім ми скористаємося командою Get-MoveRequest, щоб продемонструвати, як шукати ці назви пакетів. Спочатку, давайте створимо два простих запитупереміщення за допомогою оболонки Exchange Management Shell із зазначенням різних імен пакетів:

New-MoveRequest "Identity neil" TargetDatabase "Mailbox Database 003" "BatchName Batch001

New-MoveRequest "Identity rob" TargetDatabase "Mailbox Database 004" "BatchName Batch002

Після створення цих запитів переміщення можна використати команду Get-MoveRequest з BatchName параметром для виявлення всіх запитів переміщення поштових скриньок, пов'язаних із певним ім'ям пакета. Наприклад, щоб переглянути всі запити про переміщення поштових скриньок, пов'язані з ім'ям пакета Batch001, потрібно скористатися наступною командою:

Get-MoveRequest "BatchName Batch001

Результати цієї команди показані на малюнку 17, де видно, що тільки одна з двох поштових скриньок повернулася, оскільки друга скринька була переміщена з використанням іншого імена пакета.

Малюнок 17: Фільтрування на ім'я пакета

Переміщення кількох поштових скриньок

У другій частині цього циклу ми розглянули переміщення поштової скриньки користувача за допомогою команди New-MoveRequest. Переміщення однієї поштової скриньки є простим завданням, оскільки псевдонім цієї скриньки просто потрібно вказати у параметрі Identityкоманди New-MoveRequest. А як щодо переміщення кількох поштових скриньок? Це можна зробити кількома способами, деякі з яких будуть описані нижче.

По-перше, досить просто перемістити всі поштові скриньки з однієї бази даних до іншої просто шляхом передачі команди Get-MailboxDatabaseу команду New-MoveRequest. Прикладом може бути наступна команда:

Get-Mailbox "Database "Mailbox Database 001" | New-MoveRequest "TargetDatabase `

"Mailbox Database 002"

Якщо вам потрібно перемістити лише кілька поштових скриньок, ви можете скористатися функцією масиву PowerShell. Припустимо, що нам потрібно перемістити поштові скриньки, що належать користувачам Neil, Rob та Mark. У цьому прикладі імена користувачів є псевдонімами поштових скриньок. Можна скористатися наступним сценарієм для виконання цього завдання:

$MailboxesToMove = "neil","rob","mark"

ForEach ($SingleMailbox in $MailboxesToMove) (New-MoveRequest "Identity $SingleMailbox `

"TargetDatabase "Mailbox Database 002" "BatchName Batch001)

У цьому сценарії видно, що ми спершу визначили $MailboxesToMoveяк масив, що містить імена трьох псевдонімів поштових скриньок для переміщення. Потім кожен псевдонім поштових скриньок передається до команди New-MoveRequestдля обробки незалежно від розташування вихідної бази даних поштових скриньок.

Також можна скористатися командою Get-Content, що є в PowerShell. Насамперед, потрібно створити простий текстовий файл, що містить список псевдонімів поштових скриньок, які ви збираєтеся перемістити. На малюнку 18 показаний приклад такого файлу, це файл під назвою mailboxes.txt.

Малюнок 18: Зразковий Mailboxes.txt файл

Потім зразковий сценарій для переміщення поштових скриньок, перерахованих у файлі mailboxes.txt, може виглядати так:

$Mailboxes = Get-Content ./mailboxes.txt

For ($Start = 0; $Start -lt $Mailboxes.length; $Start++) (New-MoveRequest "Identity `

$Mailboxes[$Start] -TargetDatabase "Mailbox Database 002")

У цьому сценарії команда Get-Contentвикористовується для отримання вмісту mailboxes.txtфайлу та призначення вмісту для $Mailboxes. Потім виконується петля через вміст $Mailboxesі для кожної петлі використовується команда New-MoveRequest.

Хоча існують різні способипереміщення поштових скриньок Exchange 2010 за допомогою декількох команд Exchange Management Shell, слід знати про те, що компанія Microsoftнадає MoveMailbox PowerShell сценарій, який можна знайти у папці \Program Files\Microsoft\Exchange Server\V14\Scriptsпісля інсталяції Exchange 2010. Цей сценарій буде виконувати локальний запит переміщення в одній організації Exchange, і має додатковою перевагою, що полягає в тому, що він видаляє запит переміщення відразу після його виконання. Перш ніж розглянути пару приблизних сценаріїв, погляньмо на параметри, що використовуються з ним. Цей сценарій використовує кілька параметрів, які ми вже обговорювали у цьому циклі статей, хоча кілька параметрів мають інші назви.

По-перше, є AutoSuspendпараметр, функція якого така сама, як і у параметра SuspendWhenReadyToComplete, що використовується з командами New-MoveRequestі Get-MoveRequest. Також, BadItemLimitЦей параметр можна використовувати зі сценарієм MoveMailbox. Є також параметри MailboxDatabaseі TargetDatabase, що управляють вихідною та цільовою базою даних відповідно. Одним з основних параметрів, які ви використовуватимете з цим сценарієм, є DatabaseMapпараметр. Це справді корисний параметр, який дозволяє вам вказувати, куди потрібно перемістити поштові скриньки. Ми трохи згодом докладно розглянемо цей параметр.

А поки що, давайте розглянемо простий процес переміщення однієї поштової скриньки з використанням сценарію MoveMailbox. Щоб перемістити свою поштову скриньку в базу під назвою Mailbox Database 002, я просто виконую сценарій з наступними параметрами:

./MoveMailbox.ps1 "Identity neil "TargetDatabase "Mailbox Database 002"

Виконання цієї команди видає результати, подібні до тих, що вказані на малюнку 19. Як я вже казав, одним із чудових моментів у цьому сценарії є те, що він очищає запит переміщення автоматично.

Малюнок 19: Переміщення однієї поштової скриньки за допомогою командного сценарію MoveMailbox.ps1

Карта бази MoveMailbox.ps1 Database Maps

Параметр DatabaseMapкомандний сценарій MoveMailbox дуже корисний при обробці кількох поштових скриньок у ньому та переміщенні цих скриньок у кілька цільових баз даних. Можна вказувати кілька пар джерело/ціль у командному рядкущо значно підвищує її ефективність. Синтаксис використання цього параметра буде таким:

DatabaseMap @("Source Database"="Target Database";"Source Database"="Target Database")

У цьому синтаксисі видно два зіставлення джерело/ціль, і вони поділяються крапкою з комою. Таким чином, використовувати це для прикладу, в якому ви хочете перемістити поштові скриньки бази Mailbox Database 001до бази Mailbox Database 003, а поштові скриньки бази Mailbox Database 002до бази Mailbox Database 004, потрібно виконати команду з наступним синтаксисом параметра DatabaseMap:

DatabaseMap @("Mailbox Database 001"="Mailbox Database 003";"Mailbox Database 002"="Mailbox Database 004")

Припустимо, ви хочете перемістити всі поштові скриньки, що належать користувачам, які є співробітниками відділу Консультантів (Consultants), в нову базупоштових скриньок у такий же спосіб, як ми щойно обговорили. Для цього можна скористатися наступною командою PowerShell, якщо припустити, що атрибут "department" у Active Directory правильно заповнений:

Get-User | Where ($_.Department "eq "Consultants") | Get-Mailbox |

Цей код спочатку виходить подробиці про облікові записи тих користувачів, чий Active Directory "department" атрибут має значення Consultants. Результати цієї команди подаються на обробку до команди Get-Mailboxз метою отримання подробиць про поштові скриньки цих користувачів. Потім ці подробиці про поштові скриньки обробляються у сценарії. MoveMailboxта поштові скриньки переміщуються відповідним чином. Як показано на малюнку 20, команда викликає сценарій MoveMailbox і тепер сценарій очікує закінчення процесу переміщення. Після завершення цього процесу інформація стану відображається на екрані, як показано на малюнку 21. В результаті виконання цієї команди в моєму простому тестовому середовищі одна поштова скринька переміщена з бази Mailbox Database 001до бази Mailbox Database 003, а ящик із бази Mailbox Database 002переміщений до бази Mailbox Database 004.

Малюнок 20: Переміщення кількох поштових скриньок у процесі

Рисунок 21: Процес переміщення кількох поштових скриньок завершено

Здоров'я служби реплікації поштових скриньок

У цій статті ми вже говорили, що служба Microsoft Exchange Mailbox Replicationє дуже важливою для загального процесу запитів переміщення, тому слід виконувати відповідний моніторинг цієї служби. У попередньому циклі статей на msexchange.org, я розповідав про різні Exchange 2007 "тестові" Exchange Management Shell команди, які можна використовувати для тестування певних функцій Exchange 2007. Exchange 2010 включає Test-MRSHealthкоманду, де MRS – це скорочення служби реплікації поштових скриньок (Mailbox Replication Service). Для перевірки здоров'я певного сервера Client Access Server потрібно просто скористатися параметром "Identity, що містить відповідне ім'я сервера Client Access Server, наприклад:

Test-MRSHealth "Identity DAG1

У наведеному вище прикладі сервер Client Access Server називається DAG1. Результат виконання цієї команди буде схожий на те, що показаний на малюнку 22.

Малюнок 22: Результати виконання команди Test-MRSH

На малюнку 22 видно, що команда Test-MRSHealth перевіряє, чи працює реплікаційна служба Mailbox Replication Service, потім виконує RPC ping цієї служби і, нарешті, перевіряє, як багато часу пройшло з моменту сканування черги бази поштових скриньок.

Видалення бази даних поштових скриньок

Як частина звичайних обов'язків адміністратора вам іноді доводиться списувати існуючий Exchange 2010 сервер або просто видалити стару базуданих поштових скриньок. З попередніх частин ви, можливо, пам'ятаєте, що запити про переміщення не очищаються автоматично, навіть якщо переміщення було завершено. Винятком є ​​ситуації, коли використовується сценарій MoveMailbox.ps1, але якщо запити переміщення створювалися вручну за допомогою Exchange Management Shell або Exchange Management Console, їх потрібно буде видалити, перш ніж буде видалено базу поштових скриньок. Це можна застосувати навіть у тих ситуаціях, коли дана базапоштових скриньок не містить жодної поштової скриньки, але все ще є запит переміщення.

Спроби видалити базу даних поштових скриньок з існуючим запитом переміщення призведуть до висновку звіту про помилку, що починається текстом "Ця база поштових скриньок пов'язана з одним або декількома запитами переміщення". на малюнку 23. З цієї причини потрібно використовувати Get-MoveRequest та Remove-MoveRequest команди для пошуку та видалення існуючих запитів переміщення.

Малюнок 23: Наявний запит переміщення під час видалення бази даних

Висновок

На цьому завершуємо цикл із чотирьох частин про локальні запити переміщення в Exchange 2010. Зверніть увагу на те, що ми розглянули не всі команди та пов'язані з ними параметри, але ви можете самостійно знайти інформацію щодо них у відповідній документації. Сподіваюся, цей цикл статей став хорошим фундаментом для вас, як здійснюється весь процес запитів переміщення поштових скриньок у Exchange 2010.

Нейл є основним консультантом у Silverslands (www.silversands.co.uk), Золотому партнері Microsoft у Великій Британії та відповідає за розробку, застосування та підтримку додатків для багатьох великих клієнтів по всій Європі. В IT галузі він працює з 1987 року та спеціалізується на надсиланні повідомлень з 1995. Він починав працювати ще з Exchange 4.0. Він також має звання Exchange MVP і приділяє деяку частину свого особистого часу на допомогу різним користувачам Exchange, веде блоги, присвячені Exchange. Ці блоги ви можете знайти за адресою www.msexchangeblog.com. З Нейлом можна зв'язатися на адресу

Підготовка. Інвентаризація операційних систем на робочих станціях, клієнтів Outlook, антивірусів. Виділення ресурсів для сервера Exchange 2013 та встановлення операційної системи. Перевірка записів DNSта визначення готовності до зміни прокидів на зовнішньому маршрутизаторі.

Встановленнясервера Exchange 2013 поруч із Exchange 2010.

Налаштуваннята тестування спільної працідвох серверів одночасно.

Перемиканняпотоку пошти на Exchange 2013 року.

Перенесенняпоштових скриньок на Exchange 2013 року.

Виведенняіз роботи сервера Exchange 2010.

Вступна : Усі ролі Exchange 2010 встановлені на одному сервері. Потрібно також компактно переїхати на Exchange 2013.

Підготовка

На етапі підготовки необхідно перевірити готовність мережі підприємства до оновлення Exchange 2013.

Найкраще, якщо операційна системана робочих станціях Windows 7або пізніша. Хоча доводилося бачити нормальну роботуз Exchange 2013 під Windows XP SP3 з Outlook 2007. Однак XP знято з підтримки і розраховувати на неї не доводиться. Якщо потрібно забезпечити роботу клієнтів під Windows XP, то від установки Exchange 2013 краще утриматися. Або в тестовому середовищі знайти надійний спосіб змусити їх працювати в такій конфігурації і тільки після цього повертатися до цієї витівки. У крайньому випадкукористувачі під старими або іншими операційними системами завжди можуть підключитися до пошти браузером через OWA.

Клієнти Outlook 2003 не підтримуються. Для пізніших бажано встановити оновлення (вони приходять на WSUS, потрібно лише схвалити):
— для Outlook 2007 — KB2687404
— для Outlook 2010 — KB2687623
– для Outlook 2013 – KB2863911 (практика показала, що для SP1 – не потрібно)

Якщо у вас не Outlook, то і Exchange, швидше за все, вам не потрібні.

Декілька слів про антивірус. Касперський 8 із включеним “Веб контролем” блокує роботу Outlook. Потрібно або вимкнути "Веб контроль", або налаштувати винятки, або оновити все до версії 10 Касперського.

Декілька слів про DNS. Налаштування DNSдля поштового серверавже. За одне відразу можна додати зовні запис CNAMEна ту адресу, куди вказує основний запис MX. Щось типу: "autodiscover CNAME mail". Для можливості підключення клієнтом Outlookзовні повинен прослуховуватися порт 443. Хоча, як і раніше можна налаштувати через IMAP або POP3 будь-якого іншого клієнта.

Для невеликої організації (на 200…300 поштових скриньок) під Exchange 2013 логічно виділити в віртуальному середовищісервер з 4 ... 6 ядрами, 12 Гб ОЗУ, HDD: 100 ... 120 Гб ( системний диск) + Диск під поштову БД. У нашому випадку на Exchange 2010 файл EDB бази даних займав близько 120 Гб. Приблизно таким він і залишився після перенесення на 2013 рік. Нам місця було не шкода зробили C+D = 120 + 500 (на виріст). ОС бралася російська - Windows Server 2012 R2. Обов'язково інсталювати всі оновлення.

ВАЖЛИВО! У вас має бути діючий центр сертифікації. Якщо його з якоїсь причини досі немає, саме час підняти. Тим більше що це не складно. Без сертифікатів Exchange 2013 працювати не буде. І ще є нюанс: штатний центр сертифікації (CA) Windows доводиться небагато, щоб він підтримував можливість задавати кілька імен в одному сертифікаті. за Крайній міріу Windows 2008 R2 було потрібно. Можливо, з того часу Windows порозумнішав.

Встановлення

Спочатку робимо резервну копію AD. Хоча можливість подальшого відновлення з неї дуже сумнівна. Штатними засобамина DC: Start - Administrative Tools - Windows Server Backup.

Для зручності виконання всіх маніпуляцій, пов'язаних із встановленням Exchange 2013, з одного сервера встановлюємо на нього (на новий сервер Exchange 2013) засоби адміністрування. У Windows Power-Shell:

Import-Module ServerManager Install-WindowsFeature RSAT-ADDS Install-WindowsFeature AS-HTTP-Activation, Desktop-Experience, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, Web -Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http -Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console , Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation

(Так, це одна дуже довгий рядок. Але за те все просто і швидко.

Встановлюємо на сервер:

Решта, якщо потрібно, підкаже програма інсталяції сервера Exchange 2013.

Як дистрибутив використовувався не той ISO, що викладений на MVLS (www.microsoft.com/Licensing/servicecenter), а той, що в відкритому доступі- KB2936880

Переміщення поштових скриньок Exchange 2013 з однієї БД в іншу можна легко виконати через EAC (Exchange Admin Center), але в цій статті я розгляну варіант перенесення з допомогою powershell, т.к. веб-інтерфейс навіть версії SP1 досить сирий і періодично виникають помилки в завданнях при банальному перетягуванні скриньки з однієї бази в іншу.

Знайти більше інформаціїз налаштування та адміністрування Exchange 2013 на моєму блозі ви зможете в основній статті тематики - .

Переміщення поштових скриньок Exchange 2013

Для створення запитів переміщення скриньок між базами даних використовується командлет New-MoveRequest. приклад повної командибуде виглядати так:

C:\Windows\system32> New-MoveRequest -Identity « [email protected]»-TargetDatabase «Name of you target database» -BatchName «Enter your request name» -BadItemLimit «200»

Запит на переміщення зробили, добре. Але що, якщо ящик має або великий розмір, або безліч елементів і ви просто хочете відстежити прогрес операції, який на початку з'явився в стовпці PercentComplete? Тут настає найцікавіше, тому що для відстеження прогресу виконання завдання нам буде потрібен вже інший командлет, ось він: Get-MoveRequestStatistics.

Приклад використання на основі даних із команди на початку статті:

C:\Windows\system32> Get-MoveRequestStatistics -Identity [email protected]

А ось і висновок команди:

Праворуч можна побачити стовпець із відсотком виконання завдання.

Слід окремо розповісти про параметр BadItemLimitкомандлета New-MoveRequest: він відповідає за кількість пошкоджених елементів, що буде пропущено. За промовчанням, якщо його не вказувати, він дорівнює 0 і Microsoft суворо рекомендують його не чіпати. Однак якщо у скриньці є пошкоджені елементи, запит буде завершуватися з помилкою і скринька залишиться в тій самій базі даних. На моїй практиці при перенесенні двох сотень ящиків з одних баз до інших (при міграції з Exchange 2010 на 2013) було не більше 2-4 ящиків з хоча б одним пошкодженим елементом, при тому що сервер 2010 працював кілька років. Тому можна зробити висновок, що при грамотному адмініструванні Exchange випадків із присутністю пошкоджених елементів у вас буде досить мало.

Також хочу зазначити, що якщо значення BadItemLimitу вас більше 50, то потрібно примусово вказати ключ AcceptLargeDataLoss, принаймні так написано на Technet, але реально я завжди ставив кількість елементів 200 і мене жодного разу ніхто не запитав про те, чи я згоден на «великі втрати даних» і не заборонив при цьому виконання команди (див. перший скріншот, параметр AcceptLargeDataLossтам не вказано).

Треба відзначити, що концепція Exchange 2013 полягає в тому, що центри адміністрування включають лише базовий функціонал, мінімальний набір. Для отримання доступу до тонких параметрів, а часто навіть до деяких функцій (наприклад, до операцій над Offline Address Book, але про це в інший раз), потрібно використовувати виключно Powershell.