Содержание
Чаще всего переезд на новый домен Active Directory может потребоваться в случаях, когда на старом домене были допущены критические ошибки на этапе планирования или домен имеет фатальные повреждения.
Во втором случае все относительно понятно, а вот границы наступления первого для многих очень размыты. Это может быть например миграция с одноуровневого домена (single-label domain) или что-то другое. Ниже в статье постараюсь пролить свет на эти окутанные туманом рассуждения.
Если вам интересна тематика Windows Server, рекомендую обратиться к тегу Windows Server на моем блоге.
Переезд на новый домен Active Directory
Эта статья представляет собой описание моего исключительно субъективного опыта и взгляда на ситуацию. Буду рад увидеть в комментариях ваши мнения и примеры из личного опыта.
Объективные причины
В каждом случае потребность переезда нужно решать индивидуально, основываясь на многих факторах, но что можно сказать относительно точно: необходимость переезда в связи с архитектурными особенностями вашего домена сильно преувеличена. Даже в случае с SLD сильно перегибают палку — такой домен поддерживается во многих продуктах последних версий (например Exchange 2016 поддерживает).
На мой взгляд обязательно нужно переезжать с доменов а-ля microsoft.com, то есть если вы умудрились взять для AD имя реально существующего домена, ещё и очень популярного. Во всех остальных случаях оставайтесь спокойно на существующих доменах.
А может оставить все как есть?
Действительно, а почему бы и нет? Но даже если у вас все в состоянии «работает — не трогай», то все равно находятся системные администраторы, которые скажут: «Надо переехать на новый домен, чтобы начать с чистого листа, чтобы все было сделано правильно.» И таких товарищей достаточно много (например одно из последних обсуждений на форуме Technet).
Справедливости ради надо отдать должное тем людям, которые стремятся сделать что-то лучше, но в случае переезда на другой домен AD можно пойти другим путем. А именно допилить существующий домен до приемлемого состояния.
Именно об этом варианте я и собираюсь рассказать на примере доведения до ума старого домена, который был поднят ещё на Windows Server 2000.
Задачи
Поскольку домен изначально был достаточно старый, он использовал много устаревших технологий и настроек. Многие из них уже официально не поддерживаются (например FRS), а некоторые просто потенциально способны создать в будущем проблемы.
Начнем разбор с самого начала.
Резервное копирование
Первое, о чем вам нужно задуматься — как вы будете бэкапить КД. Если у вас уже настроено регулярное резервное копирование, это значительно упрощает ситуацию. В моем случае использовался DPM 2012 R2 с резервным копированием контроллеров домена целиком как виртуальных машин, а также их содержимого (например в случае, если понадобится провести полномочное восстановление, то состояние системы будет как нельзя кстати).
Как правильно бэкапить виртуальные КД и КД вообще можно написать очень много статей и сценарии будут разными для разных версий ОС. Чтобы кратко ознакомиться с ситуацией, советую почитать статью в блоге 1 .
- Выполняйте контрольное резервное копирование между важными изменениями в ядре инфраструктуры;
- Сохраняйте резервные копии до тех пор, пока вы не убедитесь в нормальном функционировании всех КД;
- Резервное копирование выполняйте поддерживаемыми средствами (например VSS);
- Обязательно убедитесь, что вы имеете восстанавливаемые резервные копии! Да, забэкапить мало, надо ещё и проверить а восстанавливаются ли бэкапы нормально или нет.
Я советую все изменения обкатывать на тестовой инфраструктуре, которую вы как раз сможете создать из существующих бэкапов.
Диагностика AD
Обязательно пройдитесь по всем КД и проверьте состояние их здоровья:
- Проанализируйте ошибки AD DS, DNS и др. служб в просмотре осбытий;
- Проверьте репликацию 2 и состояние КД командами repadmin и dcdiag;
- Установите все обновления ОС.
Только при отсутствии проблем приступайте ко всем изменениям.
Имя домена
Некрасивое или «неправильное» по мнению сисадминов имя домена наиболее часто является главным аргументом для переезда на другой домен. С другой стороны, что такое «правильное» имя домена? Да такого нет в принципе! Есть рекомендации какие домены лучше не использовать (например те же SLD), но это всего лишь рекомендации, которые к исполнению не обязательны. Все зависит от вашего окружения и преследуемых целей.
Админы говорят: «У меня домен domain.local, а я хочу domain.ru как основной домен организации«. То есть они считают домен domain.ru правильным. Дак вот, я скажу, что нет, это неправильное имя домена. Как минимум потому что вам придется очень сильно запариться с разруливанием запросов DNS к реальному DNS-имени domain.ru.
Признаться честно, я и сам долго болел идеей переезда на новый домен (Пара слов про именование доменов Active Directory), но лень победила — перетаскивать эксчи с терабайтами баз, всех пользователей и кучу других сервисов грозило стать неподъемной задачей и я взялся наводить порядок на существующем домене.
Теперь суть вопроса: чтобы пользоваться красивыми именами и логиниться во все доменные сервисы по адресу электронной почты достаточно создать дополнительный UPN-суффикс и назначить его всем нужным учеткам. При этом неважно какое у вас имя домена. Для переезда в облако доп. суффиксов достаточно (если у кого сомнения, читайте Локальная инфраструктура и Azure AD)
Перенос DNS-зоны _msdcs.ForestName
Это первое, с чего я начал. Почему? Нужно привести DNS в нормальное состояние, ведь от этого сервиса зависит здоровье AD в целом.
Для доменов, созданных на Windows Server 2000, зона _msdcs.ForestName располагается на уровне домена и желательно её перетащить на уровень леса, как это по умолчанию сделано на новых доменах AD на Windows Server 2003 и старше:
Сам процесс подробно расписан в официальной документации и на моем блоге в статье DNS-зона _msdcs.ForestName отсутствует.
Изменения вполне можно проводить в рабочее время, но все же обкатайте все на лабе.
Настройка защищенных динамических обновлений DNS
Вероятнее всего большинство разрешают незащищенные обновления DNS 3 . Тем не менее, согласно лучшим практикам рекомендуется разрешать динамические обновления только для авторизованных клиентов 4 .
Раз уж вы решили привести домен к эталонному виду, займитесь и DNS-записями. Тем не менее, не включайте слепо защищенные обновления, возможно в вашей инфраструктуре есть устройства со статикой вне домена, которым необходимо обновлять записи самостоятельно.
Не забывайте, что вы можете настроить обновление клиентских DNS-записей на стороне DHCP-сервера, если он развернут на Windows Server. Изменения можно проводить в рабочее время (я бы даже сказал рекомендуется проводить в рабочее время), будет возможность оперативно отлавливать проблемы пользователей.
Настройка зон обратного просмотра
Настройте зоны обратного просмотра для каждой подсети или групп сетей. Например у меня на старом домене в продакшене была обратная зона, созданная до расширения маски сети. В итоге в эту зону попадали не все записи. Решение — пересоздать зону заново.
Изменения можно проводить в рабочее время.
Обновление уровней леса и домена
Нет никаких причин сидеть на старых уровнях леса и домена 5 и лишь ограничивать себя в функциональности AD. Например пользуйтесь корзиной AD 6 , повысив уровень леса до 2008 R2 и активировав соответствующую функцию.
Повысьте до максимально возможных значений уровни леса и домена (зависит от того на каких версиях ОС у вас работают КД) 7 . Задача относительно безболезненная, можно выполнять её в рабочее время.
Переезд с FRS на DFS-R
Уже с Windows Server 2008 FRS не считается надежной и устарела, а на дворе 2017 год. Смело переезжайте на DFS-R, к тому же последние на сегодняшний момент версии ОС уже перестали поддерживать FRS вообще (то есть даже новые КД на Windows Server 2016 в домен вам не запилить).
Процесс миграции очень хорошо документирован и на некоторых шагах есть возможность откатиться назад, читайте мою статью Заметки: Миграция репликации SYSVOL с FRS на DFS.
Процесс миграции вполне возможно проводить в рабочее время.
Настройка межсайтовой топологии (если актуально)
Вопрос актуален далеко не для всех, только у кого ядро инфраструктуры размазано между несколькими площадками.
Сайты AD 8 созданы для того, чтобы «рассказать» Active Directory о реальной физической топологии сети, на основе которой AD построит топологию репликации оптимальным образом. По идее разбивать инфраструктуру на сайты нужно сразу как только один любой КД появляется в удаленном расположении (то есть вне локальной сети). Но и тут не все так просто, о чем мягко намекает объем гайда (см. статью Active Directory Design Guide) по планированию AD, в котором много внимания уделено именно сайтам.
Строго говоря, сайты можно и не создавать, если между локациями есть стабильный канал с достаточной пропускной способностью и пингом Best practice
Если вы прошли путь, который я расписал выше и который проходил сам и хотите сделать ещё лучше, то предлагаю посмотреть в сторону лучших практик администрирования AD DS. Читайте дальше.
Удаление лишних ролей
Одна из основных идей AD — абсолютная идентичность и равнозаменяемость всех контроллеров домена. И это не корыстный интерес Microsoft, чтобы вы покупали как можно больше лицензий на ОС, это действительно важный аспект.
Идея в том, чтобы построить ядро инфраструктуры из абсолютно идентичных друг другу контроллеров домена (кроме ip и ролей fsmo разумеется). В случае утери любого из них не надо заморачиваться с его восстановлением, просто вычистите его остатки из AD и заведите новый с нуля.
Все поворачивается к вам совсем другим местом, если у потерянного КД имелись какие-то важные данных (многие организации держат и файловые помойки, и терминальные серверы и многое другое на одиночных КД). Таким образом вы лишаете себя той гибкости, которая изначально была заложена в архитектуру AD DS.
Вот пример списка установленных ролей и компонентов с полностью чистого контроллера домена:
По возможности держите на КД только роли AD DS и DNS (в зависимостях подтянутся File Services с DFS). Как минимум не размещайте на КД новые роли, а в идеале снимайте существующие «левые» сервисы (и DHCP тоже), если таковые имеются.
Одна и та же версия ОС
Эта рекомендация намного важнее, чем может показаться на первый взгляд. Дело в том, что для разных ОС совершенно разный порядок восстановления из резервных копий, особенно дело касается виртуализованных КД. Разумеется различаются и нюансы администрирования.
Выполняйте плановый вывод контроллеров домена на устаревших ОС.
Рекомендации по best practice
Если соберетесь перелопатить инфраструктуру ради приведения ядра к идеальному виду, то вам непременно придется выводить старые КД из работы и вводить новые. Когда будете выводить старые КД, не забудьте:
- Предварительно заранее исключить из раздачи DHCP его адрес;
- Предварительно перенастроить сетевые настройки клиентов (в том числе и рядовые серверы) для исключения адреса КД (например сделайте это просто удаленно Заметки: Удаленное изменение сетевых настроек);
- Если выводимый КД является ещё и держателем ролей FSMO, позаботьтесь об их переносе (подробнее об FSMO читайте в FSMO — Fexible Single Master Operations), не забудьте о перенастройке времени;
- После понижения измените сетевые настройки каждого КД, убрав адрес старого;
- После понижения вычистите этот бывший КД из DNS — уберите из списка серверов имен каждой зоны (в том числе и делегирований, например _msdcs);
- После понижения удалите КД из оснастокПользователи и компьютеры или Сайты и службы (при этом сервер останется в списке обычных).
Как только введете новый КД в работу:
- Отредактируйте сетевые настройки каждого КД для включения в список DNS-серверов адрес нового КД;
- Добавьте адрес нового КД (если он является ещё и DNS-сервером, что желательно) в списки серверов имен каждой зоны DNS;
- Проверьте корректность работы нового КД согласно официальным инструкциям 10.
Перенос пользователей Active Directory
По определённым причинам появилась необходимость в переносе пользователей из одного домена в другой. Это возможно сделать штатными средствами операционной системы Microsoft. И в этом нам поможет утилита ldifde.exe. Она предназначена для экспорта/импорта пользователей Active Directory в файл с расширением .ldf. При необходимости его можно редактировать любым текстовым редактором (как в моём случае). Но программа переносит только пользователей, без групп и паролей. Пароли будут сброшены на пустые и при следующем входе в систему будет предложено сменить пароль.
На контроллере домена запускаем командную строку CMD и для удобства переходим в корень диска С c:, так как при выполнении команды вся информация будет выгружена в файл Exportuser.ldf.
Где SRVDC1 — это имя контроллера домена, а dc=DOMAIN,dc=NAME — это текущее доменное имя вашего контроллера. На выходе мы получаем файл Exportuser.ldf в корне диска С.
Так как доменное имя нового домена отличается от текущего, то в файле необходимо заменить все строчки dc=DOMAIN,dc=NAME на необходимые, с указанием нового имени. Сохраняемся, перекидываем файл на новый сервер и выполняем импорт следующей командой
Где NEWSRVDC1 — это имя нового контроллера домена.
Перенос групповых политик
Далее указываем путь, куда будем выгружать политики. Если у вас более одной политики, то лучше под это создать отдельную директорию, так как под каждую политику будет создаваться новый каталог.
Копируем их в новый домен, но домен то у нас новый, а резервная копия может содержать упоминания или ссылки на ресурсы старого домена. Поправить значения можно при помощи утилиты Migration Table Editor (mtedit.exe). Опять-таки штатный софт на борту MS Windows Server. На новом домене запускаем консоль gpmc.msc и на Объекты групповой политики правой кнопкой мыши вызываем меню, выбираем Открыть редактор таблиц миграции.
После выбираем Сервис / Заполнить из резервной копии, указываем путь к каталогу. Перед нами откроется таблица со списком всех экспортированных групповых политик.
Нажимаем OK и перед нами откроется список всех нестандартных атрибутов политик. Ищем где упоминается старый домен и правой кнопкой меняем на правильный атрибут из нашего нового домена
Все приготовления закончены, теперь дело за малым — выполнить импорт. Открываем gpmc.msc, создаём новую пустую политику в которую будем импортировать настройки и по правому клику мыши из меню выбираем Импорт параметров. . Идём далее, выбираем папку архива, выбираем соответствующий объект групповой политики, Готово!
Вот и всё, осталось ввести машины в новый домен.
(Дорогу осилит идущий…)
Мигрируем из одного домена в другой.
К сожалению, на Майкрософтовских курсах, где я когда-то учился, вопрос миграции рассматривается достаточно «скомкано», вероятно, это связано с тем, что данный процесс происходит крайне редко, вероятно, просто не хватило времени на эту тему. Лишь однажды, уже слушая Exchange, Зинченко Максим, рассказывал нам, как мигрировать из домена с 2000 ной инфраструктурой в домен с 2003 инфраструктурой, но это так же не сильно отложилось в моей памяти. Посему хотелось бы об этом по подробней:
Многих системных администраторов отпугивает перенос объектов AD между лесами/доменами из-за громоздкости существующих руководств по данному процессу. В существующих публикациях раскрывается 100% возможностей средств Active Directory Migration Tool 3.1 (этот инструмент рекомендует Майкрософт, но есть еще и альтернативные инструменты, например Pontdiev Migration, но к сожалению они не бесплатны), немалая часть которых редко используется в реальных ситуациях, что и делает процесс подготовки к миграции долгим для многих администраторов, сталкивающихся с этим впервые (к таковым кстати отношусь и я). Классический сценарий требует избыточности в плане подготовки исходного и конечного доменов.
В представленном сценарии описывается процесс межлесовой миграции с минимальными вмешательствами в инфраструктуру исходного домена (например, без доверительных отношений), что несет в себе множество преимуществ. Перед выполнением данного сценария все же не стоит пренебрегать резервированием исходного и целевого доменов и созданием планов миграции и отката в исходную точку. Данная схема работает при минимальных логических изменениях в процессе для доменов любого уровня и на любых ОС, начиная с Windows Server 2000, в том числе и для Small Business Server’s и Essential Business Server’s.
В описываемом сценарии представлено два корневых домена под управлением ОС Windows Server 2008 SP2. Исходный домен SOURCE.LOCAL (FSMO-контроллером которого является сервер dc1.source.local, IP 10.8.2.251) содержит 158 пользователей и 8 групп безопасности, в которых они распределены. Конечный домен TARGET.LOCAL (dc2.target.local, IP 10.8.2.252). Цель – перенести все учетные записи пользователей (с сохранением паролей), группы безопасности и рабочие станции в конечный домен.
- Подготовка исходного домена заключается в настройке DNS-пересылок и отключении DHCP-сервера. Все существующие пересылки необходимо удалить и создать обычную пересылку, указывающую на контроллер целевого домена.
Причем нам необходимо, чтобы IP-адрес контроллера целевого домена ссылался на его имя в FQDN-формате, для чего нужно добавить соответствующую PTR-запись в обратную зону.
Если же исходный домен-контроллер находится под управлением ОС Windows Server 2003, то можно ограничиться созданием пересылки на FQDN конечного домена без добавления в обратную зону PTR-записи контроллера конечного домена.
Подготовка целевого домена состоит в создании conditional forwarder’а, задающего соответствие имени исходного домена SOURCE.LOCAL его контроллеру dc1.source.local и включении DHCP-сервера в конечном домене. Все существующие пересылки также необходимо удалить. Если есть возможность использовать DHCP-сервер на активном сетевом оборудовании, то лучше использовать его.
Наличие PTR-записи исходного домен-контроллера в обратной зоне также является необходимым условием.
Если целевой домен находится под управлением ОС Windows Server 2003, то в DNS достаточно ограничиться пересылкой на исходный домен по IP-адресу контроллера домена. В обратной зоне никаких изменений вносить не требуется при этом.
Registry path: HKLMSystemCurrentControlSetServicesNetlogonParameters
Registry value: AllowNT4Crypto
Type: REG_DWORD
Data: 1
Runas /Netonly /user:ИМЯ_ИСХОДНОГО_ДОМЕНАЛОГИН_АДМИНИСТРАТОРА «Mmc »%windir%ADMTmigrator.msc»»
В нашем случае команда будет выглядеть так:
Runas /Netonly /user:SOURCEAdministrator «Mmc »%windir%ADMTmigrator.msc»»
Запускать командный файл придется каждый раз для запуска средства ADMT.
Admt key /option:create /sourcedomain:ИМЯ_ИСХОДНОГО_ДОМЕНА /keyfile:ПОЛНЫЙ_ПУТЬ_К_КЛЮЧЕВОМУ_ФАЙЛУ
В нашем случае команда генерации ключа будет выглядеть так:
Admt key /option:create /sourcedomain:SOURCE.LOCAL /keyfile:C:PWD.pes /keypassword:
Импортирование ключа для исходного домена на целевом контроллере командой:
admt key /option:import /sourcedomain: ИМЯ_ИСХОДНОГО_ДОМЕНА
/keyfile: ПОЛНЫЙ_ПУТЬ_К_КЛЮЧЕВОМУ_ФАЙЛУ
/ keypassword:ЗАДАННЫЙ_РАНЕЕ_ПАРОЛЬ
В нашем случае импортирование созданного ранее ключа будет выглядеть так:
admt key /option:import /sourcedomain:source.local /keyfile:C:PWD.pes /keypassword:
Следует отметить, что метод миграции паролей с помощью средства Password Export Server работает только с ОС Windows Server 2003 и 2008. Если исходный домен находится под управлением более ранней ОС, то следует обратиться к соответствующему разделу мануала по ранним версиям ADMT.
Но это еще не все. Необходимо еще мигрировать почтовые ящики. Например если в старом домене exch2003, а в новом exch2007. Эту информацию я найти в инете так и не смог. Потому и обратился с вопросом к одному из ГУРУ Exchange — Зинченко Максиму (он кстати и читал у меня все курсы по Exchange). И вот ответ:
Все также актуален вопрос перемещения почтовых ящиков между лесами и почтовыми организациями. Администраторы стараются своими силами, без привлечения консалтерских организаций провести миграцию, причем желательно с минимумом ошибок и простоев. Вам в помощь:
Здесь будет описана процедура переноса ящиков. Т.е. подразумевается, что пользовательские учетки вы уже перевели в новый лес. Если нет – эта процедура первоочередной важности, и должна быть успешно завершена до того как вы будете переносить сами почтовые ящики. Тоже самое касается переноса контактов и групп рассылки. Делается это с помощью Active Directory MIgration Tool 3.0 (ADMT v3.1), а руководство по применению ADMT – здесь
Перенос ящиков между доменами одного леса, или в пределах одного домена является очень уж тривиальной задачей. Однако, если понадобится, рассмотрим и этот вопрос. Перевод же компании между лесами AD, и по-сути, между организациями Exchange – представляется по первому времени – сложной задачей. Однако это не так. Сценарий переноса ящиков справедлив для всех случаев:
Exchange 2000 Server >
Exchange Server 2003 > => Exchange Server 2007
Exchange Server 2007 >
0. Как известно, перенести почтовые ящики из одного леса в другой при помощи графического интерфейса Exchange невозможно, и мы будем использовать EMS – Exchange Management Shell. PS:>_
Итак, учетки перемещены в новый лес Active Directory, переносим почтовые ящики:
1. Минимальные права для выполния переноса ящиков:
В исходной организации (лесу AD):
Администратор получателей Exchange, администратор сервера Exchange (Exchange Full Administrator в Exchange 2000/2003 и Exchange Recipient Administrator + Exchange Server Administrator в Exchange 2007) и членство в локальной группе администраторов, на сервере Exchange.
Эту учетку мы укажем параметром -SourceForestCredential
В целевой организации (лесу AD): такие же –
Exchange Recipient Administrator, Exchange Server Administrator в Exchange 2007 и членство в локальной группе администраторов, на сервере Exchange.
Эту учетку мы укажем параметром -TargetForestCredential
1.1 Для всех топологий с несколькими лесами, содержащих Exchange 2007, необходимо, чтобы в каждом лесу сервера GC (Global Catalog) работали под управлением Windows Server 2003 SP1, а лучше SP2. Тоже самое касается исходных лесов AD, хотя бы один GC должен быть под управлением Windows Server 2003 SP1 или выше, иначе командлет Move-Mailbox не сможет перенести оттуда ящики.
1.2 Содержимое Deleted Items в почтовых ящиках обычно не перемещается, и по этому поводу существует инструкция: «Настройка сохранения удаленных почтовых ящиков и элементов»
2. На целевом сервере Exchange 2007, где будет выполняться командлет Move-Mailbox, нужно провести объявить переменную $SourceCredential, и присвоить ей текущую учетную запись админа, выполняющего миграцию.
$SourceCredential = Get-Credential
Будут запрошены учетные данные. Нужно указать учетную запись администратора исходной организации Exchange.
3. Там же на целевом сервере Exchange 2007, объявляем еще одну переменную – админа целевой организации, выполняющего миграцию.
$TargetCredential = Get-Credential
И вводим учетную запись администратора целевой организации.
4. Все там же на целевом сервере:
Move-Mailbox -TargetDatabase "Target ServerFirst Storage GroupMailbox
Database" -Identity SampleUser -GlobalCatalog GC1.targetdomain.ru
-SourceForestGlobalCatalog GC2.sourcedomain.ru -NTAccountOU
"OU=MigrationOU,DC=targetdomain,DC=ru" -SourceForestCredential
$SourceCredential -TargetForestCredential $TargetCredential
Где SourceDomain.ru – исходный домен, TargetDomain.ru – целевой домен.
Команды отрабатываются на конечном сервере.
Не забывайте, что любые имена серверов, учетных записей, итп, содержащие пробел – должны писаться в кавычках.
Параметры GlobalCatalog и SourceForestGlobalCatalog используются для определения местоположения почтового ящика в исходном лесу и в лесу назначения. Если не указан глобальный каталог исходного леса или конечного леса, лес локального компьютера, на котором запущена команда Move-Mailbox, будет использован для определения используемого сервера глобального каталога. Чтобы переместить почтовый ящик между разными лесами, необходимо указать хотя бы один из этих двух параметров.
Параметр NTAccountOU указывает подразделение организации в конечном лесу, в котором будет создана учетная запись пользователя для почтового ящика, если она не существует, или в месте, где находится учетная запись пользователя (если она существует).
4.1 Если следует сохранить политики получателя в почтовом ящике после его перемещения, используйте параметр:
. -IgnorePolicyMatch:$true
4.2 Если вы хотите отфильтровать перемещаемый контент в ящиках, можно использовать фильтры, например:
. -AttachmentFilenames *.doc -ExcludeFolders InboxNoTransfer,InboxOld
-RecipientKeywords [email protected]
Следующие фильтры указывают типы данных для перемещения в ящиках:
-AllContentKeywords — слова встречающиеся в теме, теле и/или аттачментах писем
-ContentKeywords – слова встречающиеся теле и/или аттачментах писем
-SubjectKeywords – слова встречающиеся теме писем
используйте либо -AllContentKeywords, либо «-ContentKeywords» + «-SubjectKeywords»
-AttachmentFilenames – типы файлов в аттачменте (*.doc,*.docx,*.xlsx)
-StartDate – письма полученные от начала указанной даты (мм/дд/гггг – зависит от региональных настроек сервера)
-EndDate – письма полученные до конца указанной даты (мм/дд/гггг – зависит от региональных настроек сервера)
-ExcludeFolders – исключая следующие папки в ящике, начиная от корня «», через запятую и без пробелов.
-IncludeFolders – включая следующие папки в ящике, начиная от корня «», через запятую и без пробелов.
-RecipientKeywords – для следующих получателей, по имени или smtp адресу.
-SenderKeywords – от следующих отправителей, по имени или smtp адресу.
4.3 для сохранения квот на размеры почтовых ящиков после переноса:
. -PreserveMailboxSizeLimit $true
4.4
-ValidateOnly – проверить права на выполнение миграции ящиков.
4.5
-WhatIf – проверить правильность составления всей команды.
По умолчанию команда Move-Mailbox не удаляет ни исходный почтовый ящик, ни исходную учетную запись пользователя. Если вы перемещаете почтовый ящик пользователя в новый лес, причем учетная запись уже перемещена при помощи ADMT, и необходимо удалить и исходный почтовый ящик, и исходную учетную запись после перемещения почтового ящика
4.6 Операции с исходным ящиком:
-SourceMailboxCleanupOptions DeleteSourceNTAccount
DeleteSourceMailbox – удалить исходный ящик,
CreateSourceContact – удалить учетку и создать вместо нее контакт. Используется для перенаправления почты из старого домена в новый, в ящики на сервере Exchange 2007.
MailEnableSourceAccount – переделать mailbox-enabled user в mail-enabled user с хостингом почтового ящика на Exchange 2007 в целевом домене, разница с предыдущим ключом – сохраняются права пользователя в исходном домене.
5. Остается только проверить успешность переноса ящика на целевой сервер, любым удобным для вас способом – OWA, Outlook, ActiveSync итд.