Среди нововведений в Windows Server 8 – и новая версия гипервизора, Hyper-V 3.0, снабженная новыми возможностями. Виртуальные машины в Hyper-V 3.0 будут поддерживать больше 16 виртуальных процессоров, и бОльший объем оперативной памяти.

Судя по информации о возможностях новой версии-конкурента VMware vSphere 5, максимальное количество поддерживаемых виртуальных процессоров вряд ли будет меньше 32.

Также появилась интересная возможность Hyper-V Replica – возможность онлайновой репликации работающей виртуальной машины по сети на другой сервер, даже расположенный в удаленной локации. Все, что для этого требуется – сетевое соединение.

На скриншотах видеодемонстрации видно, что для создания реплики достаточно указать удаленный Hyper-V-сервер, на который будет производиться репликация, и выбрать тип аутентификации – как Windows Integrated, так и по сертификатам (что, возможно, позволит реплицировать виртуальные машины на хост, находящийся в совершенно отдельном лесу Active Directory, без доверенных отношений). Передаваемые по сети данные могут сжиматься. Также, можно выбрать, какие конкретно виртуальные диски нужно реплицировать.

Настройка истории восстановления для реплики виртуальной машины позволяет указать, сколько снапшотов репликаций данной виртуальной машины нужно сохранить на удаленном сервере – чтобы можно было выбрать, на какой момент машину можно было бы запустить при сбое основной копии.

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

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

Возможнось Hyper-V Replica не зависит от используемого железа, систем хранения и сетевых подключений, и является чисто программной. Вероятно, Hyper-V Replica схожа с технологией репликации, реализованной программными решениями DoubleTake, рассказ о которых еще предстоит в нашем блоге.

Полностью видео о Windows Server 8 и Hyper-V Replica можно посмотреть здесь, примерно на 37й минуте.

После этих манипуляций принтеры появлялись на клиентских ПК, но не работали, так как 64-битные драйверы с сервера конечно же не подходили:

Казалось бы, что может быть проще? Идем добавлять дополнительные драйверы на сервер, и получаем следующую ошибку:

Все дело в том, что дополнительные драйверы с отличающейся архитектурой нужно добавлять с хоста той же архитектуры. Пробуем добавить из-под ХР:

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

Оказалось, что при добавлении дополнительных драйверов их названия должны быть полностью идентичными. В нашем случае на сервере были установлены драйверы с названием HP LaserJet 1505n, а 32-битная версия называлась HP LaserJet  P1500 Series PCL5e, потому ничего и не работало. В случае с более новыми принтерами проблема решается скачиванием с сайта производителя  одинаковых драйверов для х32 и х64. Но и тут все было не так просто, мало того, что для 2008 сервера не было драйверов с таким же названием, так мы еще и не имели возможности поменять драйвер на ХР, потому что в этом случае одно очень важное приложение распечатывало страницы некорректно. К тому же у НР все официальные драйвера идут с приставкой series, поэтому даже если бы была возможность использовать другие драйвера на клиентах, то ничего бы не вышло.  Было сделано много предложений, как быть в такой ситуации, но в итоге сработало переименование драйверов в inf-файле. Файл выглядел так:

Сначала я попробовал изменить наименования драйвера только в секции, относящейся к русскоязычному CAB-файлу, но это результатов не дало. После этого я изменил в файле все записи HP LaserJet P1500 Series PCL5e на HP LaserJet 1505n.

Затем добавил драйвер из-под ХР, уже при добавлении было видно, что фокус сработал, оставалось понять, сработает ли это на сервере:

Смотрим результат на сервере:

Все получилось. После этих манипуляций принтеры инсталировались вместе с драйверами.

Диагностика

При первоначальной диагностике мы выяснили, что вышедший из строя контроллер домена был хозяином всех операций и единственным сервером глобального каталога в сайте. Кроме того данный контроллер домена также был прописан на остальных  в качестве единственного сервера DNS, хотя сами DNS сервера были развёрнуты на каждом контроллере.

Исправление

Соответственно первое, что мы сделали, это прописали на оставшихся двух контроллерах домена в качестве DNS серверов 127.0.0.1 и второй контроллер. Затем при помощи утилиты ntdsutil и команды seize мы произвели захват fsmo ролей на один из контроллеров домена. После того, как все роли были перенесены, мы попытались назначить оставшиеся контроллеры домена серверами глобального каталога, но галка «Global Catalog» в свойствах NTDS Settings в оснастке Active Directory Sites and Services была неактивна. Проанализировав записи DNS-серверов, мы обнаружили, что в разделе Forward Lookup Zones\_msdcs.domain.ru\gc\_sites, отсутствовала запись Default-First-Site-Name, а именно в этом сайте находились корневые контроллеры домена. Мы вручную создали запись Default-First-Site-Name\_tcp, где создали 2 SRV-записи, ссылающиеся на 2 оставшихся контроллера домена:

_ldap Service Location (SRV) [0][100][3268] dc2.domain.ru
_ldap Service Location (SRV) [0][100][3268] dc3.domain.ru

После перезагрузки контроллеров домена, нам удалось поставить галку «Global Catalog» для каждого из контроллеров.

К сожалению сейчас не помню всех подробностей, но были ещё какие-то проблемы с записями в DNS, часть из которых была решена утилитой netdiag /fix. Кроме того, на определённом этапе восстановления структуры DNS, галка «Global Catalog» стала активной, но тем не менее, мы обнаружили, что на контроллерах домена служба lsass не слушает порт 3268. И проблема решилась только после того, как мы вручную прописали srv-записи описанным выше способом.

На данном этапе аутентификация  всех пользователей в центральном офисе заработала. Exchange Server также успешно запустился и заработал.

Восстановление репликации

Осталось решить проблему с репликацией 80 дочерних доменов. Топология репликации была таковой, что все дочерние филиалы реплицировались через Default-First-Site-Name. Проблема оказалось в том, что вышедший из строя в главном офисе контроллер домена был назначен единственным «preferred bridgehead» в данном сайте. Таким образом, ни один из 80 дочерних контроллеров домена даже не пытался начать репликацию ни с одним из оставшихся контроллеров домена основного офиса. Кроме того, ниодин из дочерних контроллеров домена более не мог узнать ни о каких изменениях в конфигурации главного сайта, ни о появлении новых bridgehead-ов, ни об удалении старого контроллера домена, в общем, ни о чем!

По умолчанию топологией репликации управляет служба KCC, она выстраивает связи между контроллерами домена в разных сайтах. Если по каким-либо причинам один из контроллеров домена перестаёт отвечать, то связи перестраиваются автоматически. Но в случае, когда bridgehead настроен вручную, служба KCC связи не перестраивает. В центральном филиале мы отключили ручное назначение bridgehead-ов, осталось только рассказать об этом дочерним филиалам.

Мы составили некий алгоритм по восстановлению репликации с каждым дочерним филиалом:

1) Нужно зайти на контроллер домена каждого дочернего филиала, запустить оснастку Active Directory Sites and Services, раскрыть \сайт соответствующего филиала\Servers\контроллер домена\NTDS Settings, и удалить связи, ссылающиеся на удалённый контроллер домена.

2) Затем нажать правой кнопкой на NTDS Settings, нажать New Active Directory Connection, и выбрать из списка любой из двух оставшихся в сайте Default-First-Site-Name контроллеров домена.

3) Затем проделать тоже самое на контроллере домена центрального филиала, желательно на том же, который мы выбрали в предыдущем шаге.

4) Далее сначала в дочернем филиале нажать по вновь созданной связи и выбрать Replicate now. Подождав несколько минут, убедиться что репликация прошла успешно, из Default-First-Site-Name должен исчезнуть удалённый контроллер домена центрального филиала.

5) Далее лучше удалить вручную созданные связи с обоих контроллеров домена и перезапустить службу Kerberos Key Distribution Center, спустя какое-то время (около 15 мин) служба KCC автоматически сгенерирует связь между филиалом и сайтом центрального офиса.

Соответственно данную процедуру  пришлось проделать вручную с каждым из 80 дочерних филиалов!

Восстановление репликации с устаревшими контроллерами

При восстановлении репликации описанным выше способом на некоторых контроллерах домена мы столкнулись с ошибкой:

The naming context is in the process of being removed or is not replicated from the specified server.

 Скорее-всего данная ошибка была вызвана тем, что репликация данных контроллеров не производилась уже достаточно давно больше периода времени захоронения tombstone lifetime (128 дней). Для того, чтобы возобновить репликацию не переустанавливая контроллер домена, мы решили отключить проверку целостности и разрешить репликацию с неправильным партнёром. Для этого в реестр каждого контроллера домена были добавлены следующие ключи:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]

«Strict Replication Consistency»=dword:00000000

«Allow Replication With Divergent and Corrupt Partner»=dword:00000001

После перезагрузки всех контроллеров домена, репликация была восстановлена описанным выше способом. Затем эти ключи рекомендуется удалить.

Очистка метаданных.

В итоге репликация была успешно восстановлена, но во всех журналах событий возникла ошибка репликации контекста именования одного из дочерних доменов, который был давно удалён.

Кстати, если кому-то интересно, то для удобства анализа большого числа данных монитора репликации, очень удобно использовать Excel. Для этого данные можно выгрузить в формат .csv:

repadmin /showrepl * /csv > showrepl.csv

Для удаления контекста именования отсутствующего домена мы решили воспользоваться утилитой ntdsutil и командой metadata cleanup, более подробно об этом написано здесь: http://support.microsoft.com/kb/216498/en-us Но к сожалению данная попытка удаления не увенчалась успехом, мы получили ошибку 0×2162<The requested domain could not be deleted because there exist domain controllers that still host this domain.>. Данная ошибка говорит о том, что невозможно удалить домен, т.к. существуют контроллеры домена, которые содержат данный домен.

Пытаясь найти решение данной ошибки, мы попали на статью: http://support.microsoft.com/default.aspx?scid=kb;en-us;Q235416, которая к сожалению тоже никак не помогла, т.к. ни в одной оснастке уже не отображался ни сайт, относящийся к этому домену, ни сам домен. Но при помощи оснастки ADSI Edit, в разделе Configuration\Partitions\ всё ещё находился раздел этого домена. Попытка его удалить через ADSI Edit приводила к аналогичной ошибке:

Мы решили найти данный контекст именования в удалённых объектах, для этого воспользовались утилитой Active Directory Explorer (ADexplorer) от sysinternals, хотя в принципе с таким же успехом можно было использовать и ldp.exe. В итоге в разделе Configuration\Sites мы обнаружили удалённый сайт, содержащий в себе удалённый объект Servers, внутри которого был удалённый объект контроллера домена, но вот внутри объекта контроллера домена ничего не было, хотя там должен был быть объект NTDS Settings, что нас и навело на определённые мысли.

В итоге мы догадались заглянуть в контейнер LostAndFoundConfig и обнаружили там объект NTDS Settings от данного сайта, который не был удалённым, но принадлежал удалённому серверу и сайту.

После удаления объекта NTDS Settings, мы снова вернулись к ntdsutil > metadata cleanup и успешно удалили остатки старого домена.

На семинаре будут рассмотрены решения на базе Windows Server 2008 R2, Exchange Server 2010, и платформа для объединённых коммуникаций на базе Office Communications Server 2007 R2. В рамках семинара будет рассказано о продуктах для обеспечения информационной безопасности компании GFI.

Программа семинара ориентирована как на руководителей ИТ-подразделений, так и на технических специалистов и системных администраторов. Также семинар будет интересен для владельцев, руководителей организаций и предприятий, топ-менеджеров, принимающих решения о стратегическом развитии компании. На данном семинаре вы узнаете о новых возможностях каждого из продуктов, узнаете, как с помощью того или иного решения можно сократить затраты на ИТ-инфраструктуру, обеспечить надёжность и отказоустойчивость информационной системы, повысить производительность труда пользователей, и тем самым обеспечить конкурентные преимущества для вашего бизнеса.

Количество мест ограничено!

Для участия в семинаре требуется регистрация: http://www.lankey.ru/?id=1072#reg

Информация о семинаре на сайте Microsoft: http://www.microsoft.com/rus/events/detail.mspx?eventid=1032445810

Информация о семинаре на сайте GFI: http://www.gfi.ru/getnews.php?newsid=50

Информация о семинаре на сайте LanKey: http://www.lankey.ru/?id=1072

Журналисты цитируют следующее заявление Дмитрия Сумина, президента Passware: «Полное шифрование диска представляет собой серьезную проблему для следователей. Мы смогли предоставить полиции, правоохранительным органам и частным детективам инструмент, который позволяет обойти BitLocker шифрование.»

Вот лишь некоторые примеры:

http://news.softodrom.ru/ap/b5920.shtml

http://www.inattack.ru/news/3291.html

http://www.xakep.ru/post/50347/

Меня задолбали сообщения в аську от друзей и знакомых, которые увидев подобные новости, спешили проинформировать меня и позлорадствовать «типа поломали твой Microsoft».

Мне эта чушь надоела, и я решил написать статью на блог.

И так, BitLocker – это средство шифрования дисков, которое присутствует в Windows 7 и Vista, Windows Server 2008 и 2008 R2. А весь шум гам  возник, после выхода продукта Passware Kit 9.5, который, по заявлению производителя, теперь умеет взламывать BitLocker.

Давайте разберёмся, как же работает сие чудо. Для так называемого взлома зашифрованного тома программе требуется предоставить собственно дамп зашифрованного тома и (внимание!) дамп физической памяти компьютера! Мало того, дамп должен быть сделан, после того, как вы ввели правильный пароль и разблокировали зашифрованный диск!

Товарищи, о чём мы говорим? Где здесь взлом?

Естественно, что в процессе работы с зашифрованным томом, в оперативной памяти находятся ключи шифрования. Но как только вы компьютер выключили, память очищается! Даже если вдруг, к злоумышленнику попадёт включенный компьютер, но залоченный, всё равно шансы извлечь ключи из памяти практически равны нулю.  (не надо мне только про жидкий азот). Ещё один способ получить дамп памяти – это использовать файл hiberfil.sys. Но вопервых этот файл создаётся только, когда используется режим гибернации, а во вторых он располагается на системном томе, который по идее тоже должен быть зашифрован.

Сами разработчики, так вообще предлагают сделать дамп памяти при помощи утилиты MDD от компании ManTech, которая для работы требует администраторские права, пытается установить неподписанный драйвер, что естественно блокируется системой. Но даже после всего этого у меня на Windows 7 x64 утилита, так и не смогла сделать дамп.

Так, что мне вообще не понятен практический смысл возможности «взлома» BitLocker, предлагаемый Passware. М.б. кто-то объяснит?

PS.

Кстати, Passware Kit включает в себя достаточно много средств взлома. Но на своём опыте могу сказать, что и они не отличаются особой эффективностью. Так например, уже достаточно давно Passware предлагает нам средства взлома EFS. Кто-нибудь его взломал? Нет? А почему? Да потому, что предлагается почти тоже самое, для взлома нужно предоставить сертификат с закрытым ключом, которым всё шифровалось, да и ещё кажется и пароль. – ну это же бред! С паролем и сертификатом и сам Windows может всё открыть.

По моему ничего эффективнее ректотермального криптоанализа ещё не изобрели.

Сразу скажу, что история произошла больше, чем полгода назад так, что особых подробностей я не помню. Но поскольку мне уже неоднократно задавали аналогичные вопросы, я решил поднять свои старые записи и написать об этом на блоге.

Проблема случилась у одного из наших клиентов, ИТ-инфраструктуру которого мы обслуживаем по договору ИТ-аутсорсинга. Компания занимается разработкой систем биометрической аутентификации. В рамках одного из плановых аудитов информационной системы инженеры отдела сервисного обслуживания заметили аномальное увеличение размера базы данных службы каталогов ntds.dit. Когда проблема была обнаружена, размер ntds.dit составлял 2 ГБ, но в течение недели он вырос до 8 ГБ. В компании работает всего 50 человек, и в аналогичных компаниях размер базы данных службы каталогов варьируется от 20 до 40 МБ. Поиски в Интернете ни к чему не привели, поэтому нам пришлось разбираться самим. Параллельно мы открыли инцидент в службе поддержки Microsoft, которая в данном случае нам не помогла. Кто-то из специалистов мне пытался объяснить, что мне следует почистить Event Logs, по его мнению они хранились в Active Directory. А я всю жизнь думал, что они хранятся в C:\WINDOWS\system32\config\. Ну да ладно, может быть в тот раз трубку взяла уборщица, кто его знает

Локализация проблемы.

Проблему удалось локализовать в течение одной недели. Просматривая службу каталогов низкоуровневой утилитой ldp.exe, мы обнаружили огромное количество однотипных объектов в контейнере CN=Deleted Objects. В имени всех объектов содержалось название программного обеспечения биометрической аутентификации, которое как раз и разрабатывает эта компания. Мы немедленно обратились к разработчикам и сообщили о проблеме. Мы глубоко не погружались в технологию работы их программного обеспечения, но смысл был в том, что ПО генерировало маркер доступа, сохраняло его в AD, затем считывало и удаляло. И так создавалось и удалялось несколько миллионов объектов в день. Но, видимо, никто не учёл, что удалённые объекты в AD хранятся ещё 180 дней. И таким образом, они всё время накапливались. Разработчики поправили ошибку, и перед нами осталась только одна проблема – Как теперь уменьшить размер БД и избавиться от удалённых объектов?

Решение проблемы.

Сейчас точно не вспомню, но удалённых объектов накопилось более 100 миллионов. По умолчанию удалённые объекты хранятся 180 дней. Чтобы началось их удаление, мы уменьшили время хранение удалённых объектов до 1 дня. Для этого запустили ADSIEdit.msc и в разделе Configuration\Services\Windows NT\Directory Service, задали значение атрибута tombstonelifetime = 2.

Но не всё оказалось так просто. Захоронённые объекты даже с истёкшим сроком хранения не удаляются сразу. Их удаление происходит при запуске процесса Garbage Collector, который запускается 1 раз в 12 часов и удаляет не более 5000 объектов. Затем мы сократили интервал запуска процесса Garbage Collector до 1 часа.  Для этого запустили ADSIEdit.msc и в разделе Configuration\Services\Windows NT\Directory Service, задали значение атрибута garbageCollPeriod = 1.

Но это не сильно спасло ситуацию. Т.к. удаление 100 000 000 объектов продолжалось бы боле 2-х лет!   (100000000/5000/24/365=2,28 лет).  А по умолчанию, так и вообще более 27 лет.

Честно-говоря, нам не хотелось столько ждать,  и мы обратились за помощью к разработчикам Active Directory. После переписки с Тимом Спрингстоном (Tim Springston), у нас получилось удалить все захоронённые объекты в течение нескольких дней.  Для запуска непрерывного процесса удаления захороненных объектов мы использовали процедуру DoGarbageCollector.

Для её запуска используется LDP.EXE. Запускаем ldp.exe в меню Connection выбираем connect, подключаемся к контроллеру домена, затем выбираем Connection\bind и вводим учётные данные. Затем нажимаем Browse\Modify и заполняем соответствующие поля.
Attribute: DoGarbageCollection
Value: 1
Нажимаем Enter, а затем Run.

Чтобы отслеживать процесс, можно запустить логирование. Для этого меняем соответствующее значение реестра:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics
6 Garbage Collection = 3

В Event Viewer смотрим события 1005, 1006 – они говорят о работе Garbage Collector, после завершения его работы, появляется событие: 1646, в котором будет указано на сколько может быть уменьшена БД AD оффлайновой дефрагментацией.

После этого перезагрузились в режиме Directory Service Restore Mode, и использовали ntdsutil для offline дефрагментации ntds.dit. Не буду расписывать процесс дефрагментации, боюсь наврать, но в нём ничего сложного нет, читайте тут: http://support.microsoft.com/kb/232122.

Само железо было оттестировано различными мемтестами – ничего не показало. Да и очень вряд ли в брендовых серверах что-то не так с компонентами

В журнале производительности записывается ошибка:

The computer was rebooted from a bugcheck. The bugcheck was: 0x00000101 (0x000000000000000d, 0x0000000000000000, 0xfffff880022e2180, 0x000000000000000c).


Причина оказалась очень интересной. Дело в том, что в серверах стоят новые процессоры Intel Xeon E5520, с архитектурой Nehalem. И, оказывается, в этих процессорах есть ошибка – что-то не так с прерываниями. Intel выпустила описание ошибки, и соответственно, Microsoft сформировала knowledge base и опубликовала патч – http://support.microsoft.com/kb/975530. И проявляется эта ошибка именно под управлением операционной системы Windows Server 2008 R2 и ролью Hyper-V. Причем, так как проблема проявляется только на строго определенных процессорах – данный патч недоступен через Windows Update, и его надо качать вручную.

Решение: установка патча с сайта Microsoft, взятого по адресу http://support.microsoft.com/kb/975530. После установки – перезагрузить сервер.

Ждем патча от Intel в виде паяльника и набора радиокомпонентов «Сделай сам»

В представленном сценарии описывается процесс межлесовой миграции с минимальными вмешательствами в инфраструктуру исходного домена (например, без доверительных отношений), что несет в себе множество преимуществ. Перед выполнением данного сценария все же не стоит пренебрегать резервированием исходного и целевого доменов и созданием планов миграции и отката в исходную точку. Данная схема работает при минимальных логических изменениях в процессе для доменов любого уровня и на любых ОС, начиная с 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). Цель – перенести все учетные записи пользователей (с сохранением паролей), группы безопасности и рабочие станции в конечный домен.

1. Подготовка исходного домена заключается в настройке DNS-пересылок и отключении DHCP-сервера. Все существующие пересылки необходимо удалить и создать обычную пересылку, указывающую на контроллер целевого домена.

   

   Причем нам необходимо, чтобы IP-адрес контроллера целевого домена ссылался на его имя в FQDN-формате, для чего нужно добавить соответствующую PTR-запись в обратную зону.

   Если же исходный домен-контроллер находится под управлением ОС Windows Server 2003, то можно ограничиться созданием пересылки на FQDN конечного домена без добавления в обратную зону PTR-записи контроллера конечного домена.

2. Подготовка целевого домена состоит в создании conditional forwarder’а, задающего соответствие имени исходного домена SOURCE.LOCAL его контроллеру dc1.source.local и включении DHCP-сервера в конечном домене. Все существующие пересылки также необходимо удалить. Если есть возможность использовать DHCP-сервер на активном сетевом оборудовании, то лучше использовать его.

   
   

   Наличие PTR-записи исходного домен-контроллера в обратной зоне также является необходимым условием.

   Если целевой домен находится под управлением ОС Windows Server 2003, то в DNS достаточно ограничиться пересылкой на исходный домен по IP-адресу контроллера домена. В обратной зоне никаких изменений вносить не требуется при этом.

   

3. Пароли для администраторов доменов должны отличаться. Также в обоих доменах должны быть одинаковые групповые политики в отношении сложности паролей. На время миграции настоятельно рекомендуется отключить встроенные брэндмауэры на клиентских ПК. Соответственно, в конечном домене также должна быть активной политика, отключающая службы Windows Firewall и Internet Connection Sharing (ICS). Это может сильно повлиять на работу агента миграции клиентских ПК, который будет закачиваться на них и совершать необходимые операции.
4. Перед началом процесса миграции все клиентские ПК должны быть включены и разлогинены. Никто не должен работать.
5. Если в исходном домене находятся ПК под управлением ОС Windows XP, Windows 2000 или Windows Server 2003, а конечный домен находится под управлением контроллеров с ОС Windows Server 2008, то необходимо на всех контроллерах в целевом домене создать/изменить ключ в реестре:

   Registry path: HKLM\System\CurrentControlSet\Services\Netlogon\Parameters
   Registry value: AllowNT4Crypto
   Type: REG_DWORD
   Data: 1

6. После создания пересылок необходимо установить средство ADMT на целевой контроллер в зависимости от версии ОС. Для Windows Server 2008 подходит только версия 3.1 (Active Directory Migration Tool version 3.1). Для всех остальных – любые вплоть до третьей (здесь мы намеренно не рассматривает вариант, когда целевой контроллер домена находится под управлением NT4). После установки средства ADMT на конечный сервер, необходимо узнать куда оно проинсталлировалось (вариантов несколько: от X:\Program Files (x86) до X:\WINDOWS). Необходим точный путь до файла оснастки migrator.msc.
7. Создание командного файла для запуска оснастки средства ADMT migrator.bat (поскольку доверие между доменами, строго говоря, не является необходимым условием). migrator.bat должен содержать в себе следующую команду:

   
Runas /Netonly /user:ИМЯ_ИСХОДНОГО_ДОМЕНА\ЛОГИН_АДМИНИСТРАТОРА "Mmc \"%windir%\ADMT\migrator.msc\""


   В нашем случае команда будет выглядеть так:

   
Runas /Netonly /user:SOURCE\Administrator "Mmc \"%windir%\ADMT\migrator.msc\""


   Запускать командный файл придется каждый раз для запуска средства ADMT.

8. В данном сценарии предполагается миграция существующих паролей. Для того, чтобы это осуществить необходимо проделать следующие шаги.
   1. Генерация ключа для исходного домена на целевом контроллере командой:

      
Admt key /option:create /sourcedomain:ИМЯ_ИСХОДНОГО_ДОМЕНА /keyfile:ПОЛНЫЙ_ПУТЬ_К_КЛЮЧЕВОМУ_ФАЙЛУ /keypassword:ПАРОЛЬ_УДОВЛЕТВОРЯЮЩИЙ_ПОЛИТИКЕ ПАРОЛЕЙ_В_ОБОИХ_ДОМЕНАХ


      В нашем случае команда генерации ключа будет выглядеть так:

      
Admt key /option:create /sourcedomain:SOURCE.LOCAL /keyfile:C:\PWD.pes /keypassword:{microsoftkey777}


   2. Импортирование ключа для исходного домена на целевом контроллере командой:

      
admt key /option:import /sourcedomain: ИМЯ_ИСХОДНОГО_ДОМЕНА
/keyfile: ПОЛНЫЙ_ПУТЬ_К_КЛЮЧЕВОМУ_ФАЙЛУ
/ keypassword:ЗАДАННЫЙ_РАНЕЕ_ПАРОЛЬ


      В нашем случае импортирование созданного ранее ключа будет выглядеть так:

      
admt key /option:import /sourcedomain:source.local /keyfile:C:\PWD.pes /keypassword:{microsoftkey777}


   3. Размещение полученного ключа локально на исходном контроллере.
   4. Установка средства Password Export Server version 3.1 (ADMT Password Migration DLL) на исходный контроллер. При установке будет запрошен ключевой файл, на который надо указать и ввести указанный выше пароль. После установки следует перегрузить сервер.
   5. Установка разрешений на запуск службы Password Export Server Service. Для этого необходимо в обоих доменах завести пользователей с одинаковыми логинами и паролями. В нашем случае это пользователь PES с правами обычного доменного пользователя. Служба должна запускаться от имени созданного пользователя. После установки разрешений службу можно запустить. Начиная с этого момента, возможна миграция существующих паролей в целевой домен.
      Следует отметить, что метод миграции паролей с помощью средства Password Export Server работает только с ОС Windows Server 2003 и 2008. Если исходный домен находится под управлением более ранней ОС, то следует обратиться к соответствующему разделу мануала по ранним версиям ADMT.

9. Начало миграции. Для запуска средства ADMT используем созданный ранее командный файл. При запуске будет запрошен пароль администратора исходного домена.

   1. Для миграция учетных записей пользователей необходимо запустить User Account Migration Wizard из меню Action. Далее необходимо ввести информацию об исходном и целевом доменах, указав при этом именно те контроллеры, которые были использованы при создании DNS-пересылок. В нашем случае это dc1.source.local и dc2.target.local. После выборки необходимых пользователей из исходного домена необходимо указать контейнер в целевом домене для размещения мигрированных объектов. Далее отмечаем опции Migrate Passwords, Do not update passwords for existing users и вводим контроллер исходного домена, на котором запущена служба PESSVC, в поле Password migration source dc. В нашем случае это dc1.source.local. В меню Account Transition Options отмечаем опции Target same as source и Migrate user SIDs to target domain. Далее будет предложено включить аудит учетных записей в исходном домене. Следует согласиться со всеми предложениями, после чего перезагрузка исходного контроллера будет необратима. После загрузки исходного контроллера необходимо запустить на нём службу PESSVC и продолжить миграцию учетных записей пользователей на конечном сервере. После чего необходимо ввести логин и пароль администратора исходного домена. В меню User Options отметить опции Translate roaming profiles, Update User Rights, Fix users’s group membership. В меню Conflict Management отметить опцию Do not migrate source objects if a conflict is detected in the target domain. С конфликтующими объектами лучше разобраться вручную. Меню с выбором исключений можно пропустить. Следует отметить, что в данном сценарии вместе с учетными записями пользователей также мигрируются перемещаемые профили, что делает данный процесс незаметным для конечного пользователя. Если в домене не используются перемещаемые профили, то рекомендуется заведомо их сделать таковыми.
   2. Для миграции групп безопасности необходимо запустить Group Account Migration Wizard из меню Action. Далее необходимо ввести информацию об исходном и целевом доменах, указав при этом именно те контроллеры, которые были использованы при создании DNS-пересылок. В нашем случае это dc1.source.local и dc2.target.local. После выборки необходимых групп безопасности из исходного домена необходимо указать контейнер в целевом домене для размещения мигрированных объектов. В меню Group Options необходимо отметить опции Update user rights, Fix membership of group, Migrate group SIDs to target domain. В меню Conflict Management отметить опцию Do not migrate source objects if a conflict is detected in the target domain. Меню с выбором исключений можно пропустить. Никогда не следует выполнять миграцию таких глобальных групп безопасности как «Издатели сертификатов», «Администраторы DHCP», «Пользователи DHCP», DnsAdmins, DnsUpdateProxy, «Администраторы домена», «Компьютеры домена», «Контроллеры домена», «Гости домена», «Пользо¬ватели домена», «Администраторы предприятия», «Владельцы-создатели групповой политики», «Серверы RAS и IAS», «Администраторы схемы» и «Пользователи WINS» и их аналоги.
   3. Миграция рабочих станций осуществляется через Computer Migration Wizard меню Action. Дойдя до меню Translate Objects можно отметить те опции, которые нам необходимы, после чего в Security Translation Options выбрать опцию Add (Add equivalent security references for target objects and have source reference intact). В следующем окне необходимо выставить временную задержку, по истечении которой клиентский ПК будет перезагружен (при условии, что агент мигрирования завершится успешно). Меню с исключениями можно пропустить. В меню Conflict Management отметить опцию Do not migrate source objects if a conflict is detected in the target domain. После того, как работа мастера завершится, будет запущено диалоговое окно управления агентами миграции ПК с перечнем всех выбранных ранее ПК, подлежащих переносу в новый домен. В разделе Agent Actions следует отметить опцию Run pre-check and agent operation и нажать Start. Со временем агент начнет перегружать клиентские ПК и выполнять процедуру POST-CHECK, которая может завершаться с ошибкой, если перед миграцией не были корректно настроены службы DHCP в обоих доменах. Чаще всего это свидетельствует о том, что клиентский ПК не получил корректных настроек от DHCP-сервера в конечном домене. По статистике примерно на 100 рабочих станций приходится 10-15, которые не обрабатываются агентом миграции. Такие ПК придется переносить вручную, если сходу не попытаться устранить проблему, которая, скорее всего, кроется в службах Workstation, Netlogon и RPC.

10. По завершении миграции необходимо вернуть обратно удаленные ранее пересылки на обоих контроллерах, удалив при этом служебные (созданные для целей миграции).