Вводная.
Имеются два леса 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 Servers повлияет на перемещение. Например, будут ли два сервера Client Access Servers пытаться переместить один и тот же почтовый ящик одновременно? К счастью, в Microsoft сообщили, что был применен общий механизм между всеми серверами Client Access Servers одного сайта Active Directory, чтобы избежать таких ситуаций.
Создание локального запроса перемещения
Теперь, когда мы немного разобрались с запросами перемещения, пришло врем посмотреть, как на практике можно переместить почтовый ящик с помощью этой новой функции. Давайте начнем с рассмотрения того, как создавать локальный запрос перемещения с помощью консоли Exchange Management Console.
- Когда консоль Exchange Management Console загружена, разверните Конфигурацию получателя (Recipient Configuration) в дереве консоли. В узле Recipient Configuration выберите объект Почтовый ящик (Mailbox) , который отобразит список всех почтовых ящиков в панели результатов.
- На этом этапе вам нужно выбрать почтовые ящики, которые нужно переместить. Вы можете выбрать несколько почтовых ящиков, которые будут перемещены одновременно.
- Когда вы выбрали почтовые ящики для перемещения, выберите опцию Новый локальный запрос перемещения (New Local Move Request)" в панели действий, или нажмите правой клавишей на объекте Mailbox и выберите эту же опцию из контекстного меню, как показано на рисунке 2.
Рисунок 2: Создание нового локального запроса перемещения
- У вас запустится мастер New Local Move Request Wizard и отобразит вводную страницу Introduction , как показано на рисунке 3. На этой странице будут отображены выбранные вами почтовые ящики, а также важная информация, включающая базу данных почтовых ящиков, в которой на данный момент расположены эти почтовые ящики.
Рисунок 3: Вводная страница мастера New Local Move Request
- На вводной странице нажмите кнопку Обзор (Browse)" , которая вызовет окно выбора базы данных почтового ящика (Select Mailbox Database) , как показано на рисунке 4. Это окно отобразит базы данных, которые доступны на всех серверах вашей организации. В своем примере я просто перемещу почтовый ящик из базы данных Mailbox Database 001 в Mailbox Database 002 на одном сервере с именем DAG1 . Таким образом, я просто выбираю эту базу данных и нажимаю OK .
Рисунок 4: Страница выбора базы данных почтовых ящиков
- Теперь на вводной странице поле базы данных должно быть заполнено именем целевой базы данных. Нажмите Далее (Next) .
- Далее откроется окно опций перемещения (Move Options) , как показано на рисунке 5. Это окно должно быть вам знакомо, если вы использовали предыдущие версии Exchange. Здесь вы можете указать, как обрабатывать поврежденные сообщения, если таковые будут найдены в исходной базе данных. Здесь у вас есть опция полностью пропустить почтовый ящик, или разрешить определенное количество поврежденных сообщений. Здесь нет правильных или неправильных настроек, все зависит от того, как в вашей организации относятся к потере данных. На рисунке ниже я выбрал опцию пропуска почтового ящика полностью; если какие-либо поврежденные элементы будут найдены, почтовый ящик не будет перемещен. Затем я просмотрю базу данных с помощью таких утилит, как ISINTEG на предмет возможности исправления повреждений.
Рисунок 5: Страница опций перемещения
- Как только вы выбрали подходящие параметры на странице опций перемещения, нажмите Далее . Это отобразит финальную страницу, где вы сможете просмотреть сводную информацию о конфигурации, прежде чем нажать кнопку Новый (New) для создания локального запроса перемещения.
- После этого локальный запрос перемещения будет создан и передан серверу 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 a completed move request associated with it. Before you create a new move request for the mailbox, run the Remove-MoveRequest cmdlet to clear the completed move request.
Это сообщение об ошибке показано на рисунке 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, процесс запроса перемещения автоматически выберет базу данных.
Если у вас одна и более баз данных почтовых ящиков, которые вы хотите исключить из этого процесса выбора, то вы можете изменить значение параметра IsExcludedFromProvisioning базы данных, которую хотите исключить. Этот параметр показан на рисунке 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). Есть два способа расширить информацию, которая будет вам доступна:
- В консоли Exchange Management Console выберите меню Вид (View) , затем опцию Добавить или удалить столбцы (Add/Remove Columns") , чтобы вызвать окно Add/Remove Columns , как показано на рисунке 11. Здесь видно, что поля Имя (Name), Имя удаленного хоста (Remote Host Name), Исходная база данных (Source Database) и Целевая база данных (Target Database) также доступны. Используя различные кнопки, имеющиеся на экране, вы можете указывать, какие дополнительные поля отображать, а также порядок, в котором они будут отображены.
Рисунок 11: Добавление дополнительных информационных столбцов
- Другим способом добавления информации в консоли 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 | ./MoveMailbox.ps1 "DatabaseMap @{"Mailbox Database 001"="Mailbox Database 003";"Mailbox Database 002"="Mailbox Database 004"}
Этот код сначала получается подробности об учетных записях тех пользователей, чей 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-MRSHealth
На рисунке 22 видно, что команда Test-MRSHealth проверяет, работает ли служба репликации Mailbox Replication Service, затем выполняет RPC ping этой службы и, наконец, проверяет, как много времени прошло с момента сканирования очереди базы почтовых ящиков.
Удаление базы данных почтовых ящиков
В качестве части обычных обязанностей администратора вам иногда приходится списывать существующий Exchange 2010 сервер или просто удалить старую базу данных почтовых ящиков. Из предыдущих частей вы, возможно, помните, что запросы перемещения не очищаются автоматически, даже если перемещение было завершено. Исключением являются ситуации, когда используется сценарий MoveMailbox.ps1, но если запросы перемещения создавались вручную с использованием Exchange Management Shell или Exchange Management Console, их нужно будет удалить до того, как будет удалена база почтовых ящиков. Это применимо даже в тех ситуациях, когда данная база почтовых ящиков не содержит ни одного почтового ящика, но все еще имеется запрос перемещения.
Попытки удалить базу данных почтовых ящиков с существующим запросом перемещения приведут к выводу отчета об ошибке, начинающегося текстом "Эта база почтовых ящиков связана с одним или несколькими запросами перемещения (This mailbox database is associated with one or more move requests)"". Такая ошибка показана на рисунке 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.
