четверг, 8 марта 2012 г.

Миграция Active Directory. Готовим слоты миграции.

Процесс миграции службы каталогов не столько сложен в техническом плане, сколько в организационном. Перед тем как нажимать на кнопки ADMT, необходимо подготовить список мигрируемых объектов (конечно, это не единственный этап организационного процесса). Этого можно и не делать и смигрировать всех пользователей и компьютеры разом, без разбору. Но как правило это невозможно уже в инфраструктуре от 100 рабочих станций, не говоря уже про инфраструктуры с тысячами и десятками тысяч рабочих станций и пользователей. Процесс миграции в таких инфраструктурах становится неуправляемым, что в конечном итоге ведет к провалу. Также в службе каталогов, в процессе ее долгой эксплуатации, скапливается множество так называемых «мертвых душ», то есть неактивных пользователей и недействующих объектов компьютеров. И их количество иногда превышает количество активных пользователей или компьютеров. И зачем они вам нужны в новой службе каталогов? И даже если у вас есть список всех активных компьютеров и пользователей, то всех проблем это не решает. Поскольку необходимо наличие соответствия пользователей и компьютеров, на которых эти пользователи работают.

Состав.

Предлагаемый набор скриптов позволяет получить актуальный список миграции.

В набор входят следующие скрипты:
  • CHWAMSSlotCollect.vbs – производит сбор информации о пользователях и компьютерах; 
  • CHWAMSSlotCollect.bat – запускает скрипт CHWAMSSlotCollect.vbs, перенаправляет вывод в файл с именем “Компьютер%пользователь”; 
  • GenerateMigrationList.ps1 – обрабатывает собранную информацию и генерирует список миграции в формате xml. 
  • genmig1.xsl – трансформатор, позволяющий разложить информацию из XML-файла в более удобный для восприятия формат (xhtml). 


Как использовать?


1) Необходимо создать общий ресурс (shared folder) на каком-нибудь файл-сервер. Например, UNC-путь будет \\сервер\общая_папка\. В нашем случае \\SRV-MIG01.target.ru\SlotInfo$\.
2) Разрешить запись в этот ресурс для пользователей из обследуемого домена. На уровне общего ресурса Everyone – Full Control, на уровне NTFS – для группы Domain Users из обследуемого домена полномочия Write.
3) Необходимо, в обследуемом домене, создать групповую политику, например, с именем MigrationSlotCollect.
4) В групповой политике определить Logon Script (конфигурация пользователя) со следующими параметрами:
Важно! Параметр должен завершаться обратной косой чертой. Параметр не должен заключаться в кавычки. Обратите внимание на имя сервера с общим ресурсом. Это имя должно разрешаться, предпочтительно используйте полное имя (fqdn).
5) CHWAMSSlotCollect.bat и CHWAMSSlotCollect.vbs должны находиться в одном каталоге. Скопируйте эти два файла в Script\Logon созданной групповой политики.
6) Желательно, для групповой политики, отключить конфигурацию компьютера. Также для связи групповой политики определите опцию No Override (или Enforced в GPMC).
7) Привяжите групповую политику MigrationSlotCollect к обследуемому домену. В некоторых случаях лучше привязать групповую политику к организационному подразделению пользователей. Это стоит делать для доменов, где используются замыкания групповой политики, поскольку в таких случаях скрипт будет выполняться два раза, что, в общем-то, не страшно.

Должно получиться как-то так:
 

Что делает скрипт?

При входе пользователя в систему, отрабатывает logon-скрипт. В контексте пользователя собирается информация о логине и домене пользователя, информация об операционной системе, дисках, сетевых картах и антивирусных продуктах. Собранная информация перенаправляется в общую папку в файл с именем Компьютер%Пользователь.

Далее.

Некоторое время спустя (например, одна-две недели), в созданном общем ресурсе должно скопиться определенное количество файлов с собранной информацией.

Теперь необходимо эту информацию обработать. Для этого необходимо воспользоваться скриптом GenerateMigrationList.ps1. На компьютере с powershell (на Windows 7 и Windows 2008 R2 powershell предустановлен, на других версиях придется устанавливать дополнительно) запустите GenerateMigrationList.ps1 со следующими параметрами:
  • SourceDir <каталог с собранной информацией> - каталог, общий ресурс, с собранной информацией. Если не указан, то будет использоваться текущий каталог. 
  • ResultFile <целевой файл (xml)> - целевой файл, в формате xml. Если не указан, то имя файла сгенерируется автоматически. 
  • XslFile <xsl-файл для трансформации> - Если не указан, то используется genmig1.xsl. 
Пример запуска:
.\GenerateMigrationList.ps1 -SourceDir C:\Migration\slotInfo\source.local -ResultFile sourcedomain.xml

Важно! Скрипт нужно запускать на компьютере в домене, при этом должны быть установлены доверительные отношения с обследуемым доменом. То есть, это может быть как компьютер из обследуемого домена, так и компьютер из другого доверяемого домена. Иначе информация по пользователю будет сгенерирована не полностью.

В результате создастся файл. Откройте этот файл в обозревателе интернет (например, Internet Explorer). Файл xsl при этом должен находиться в том же каталоге, что и сгенерированный xml-файл.

Далее можно скопировать информацию из html-файла (из обозревателя) и вставить в Excel.

Набор скриптов можно скачать отсюда: https://skydrive.live.com/redir.aspx?cid=4facb5d44ace70b7&resid=4FACB5D44ACE70B7!222&parid=4FACB5D44ACE70B7!214

3 комментария:

apavlyuchenko комментирует...

Отличная статья, спасибо!

Подскажите, как поступить в моем случае!

Иметься домен на базе Windows 2003 x64(уровень леса 2003, уровень домена 2003) с инфраструктурой Exchange 2007 SP1.
Необходимо мигрировать на домен 2008 R2 + Exchange 2010

Будет проще поднять отдельный домен в другом лесу 2008 R2 и сделать миграцию пользователей между лесами? Как быть с почтовыми ящиками, ADMT переместит корректно?

Efimov Gennady комментирует...

to apavlyuchenko:
если нет причин, по которым требуется миграция между лесами (создание нового леса), то лучше делать внутри леса. То есть, это получится даже не миграция, а обновление. Обновляете лес, схему, ставите контроллеры, удаляете старые контроллеры. Далее в режиме сосуществования устанавливаете Exchange 2010 и перемещаете почтовые ящики с Exchange 2007 (нужен SP2) на Ex2010. ADMT для этого не понадобится.

Если мигрируете между лесами, то миграцию почты ADMT не делает, для этого необходимо использовать командлеты New-MoveRequest (PowerShell).

p.s.: обновление на много легче проделывать, чем миграцию.

apavlyuchenko комментирует...

Спасибо за совет!