Как стать автором
Обновить

Комментарии 24

Стоит чуток подправить орфографию, отформатировать, добавить пару скриншотов и отличный Users Guide готов.
С орфографией проблематично, насчёт скринов всё в принципе понятно и без них, но если надо добавить, говорите к какому пункту, сделаю.
А не проще ли сделать так:
Свойства системы -> Вкладка дополнительно -> Профили пользователей -> параметры и там выбираем старую учётку которую надо скопировать, выбираем папку новой учетки и пользователя и всё!!! До этого надо залогиниться под новым пользователем, что бы создалась папка его папка в Documents and settings.
Попробовал перенести вашим способом, когда указываю конечный профиль пишет ошибка отказано в доступе, делаю всё из под Администратора домена
// 6 Следующий шаг, надо дать права на ветку реестра с пользовательскими настройками. Они хранятся в
// файле ntuser.dat. Запускаем regedit.exe,

Насколько я помню, то пермишины на реестр можно выставлять через regedt32.exe Там по пкм есть пункт «Разрешения» (в рус версиях).
User Profile Wizard 3.0 нормально переносит учетки, все сохраняется, только там особенность есть, при включении в новый домен, User Profile Wizard 3.0 не видит имена ползователей старого домена, показывает только SID каждого пользователя. В остальном все проходит довольно быстро.
А переносит он всё? Пароли, настройки, принтеры и тп.
Переносит все, в том числе и пароли, настройки и пр.

Непонятно, только зачем так извращаться если, второй домен тоже windows? Есть же ADMT( Active Directory Migration Tools ), почему не воспользоваться им?

Нам предстоит переход с win2000 на Samba, поэтому выхода нет.
Не зря писал статью уже узнал про ADMT, попробую может проще. А Самба не может корректно получить роли?
Вроде может, но только если win2k домен находится в mixed-режиме. В Samba4-alpha делают полную интеграцию с AD.
На самбу? Могу помочь.
Спасибо, но надеемся помощь не нужна будет. Миграции пользователей как таковой не будет, было решено сделать всем пользователям нормальные учетки ( ФамилияИО ), а не так как сейчас fedya21 и пр., поэтому нужно только перенести настройки. Уже все поднято и настроено, думаю, в выходные будем осуществлять переезд.
отлично. возможно, что-то такое и придется делать в ближ время :)
Если ошибки не в АД я бы переставил с помошью второго сервера и переноса FSMO ролей, будет проще и быстрей, хотя если SBS вариант не пройдёт.
это из разряда must know для любого системного администратора/эникейщика/хелпдеска.
думаю, мало кому эта статья откроет что-то новое.
Тогда вопрос, а есть подобный подход, но автоматизированный? Запустил скриптик написал из какого пользователя куда(интересует именно скрипт, а не програмный продукт )
думаю, совсем универсального подхода нет, но подход изложен у вас. всё зависит от политик компании (права пользователей, имена компьютеров/пользователей, групповые политики и ещё много всего).
есть возможность проделать такую операцию с Roaming Profile, можно хранить профиль пользователя на сервере в папке \\Servername\Sharename\%Username% и в свойствах Учётной записи в AD указать местоположение профиля. В этом случае нужно разобраться с NTFS-правами доступа. оставить действющими права можно при помощи ADMT (копировать учётки вместе с SID'ами), либо можно написать скрипт, который проходит по всем папкам и изменяет права доступа (см. xcacls). Минус Roaming Profile-ов — в случае большго объёма профиля, долго будет проходить первый вход в систему (профиль копируется на компьютер пользователя).
Сейчас есть такая крутая штука как PowerShell, которая позволяет скриптовать такие операции, как описана в посте.
Собственно, у меня не было необходимости проделывать такую операцию на большом количестве пользователей, поэтому особо подробно не изучал. Самое главное — это понимать подход.
С перемещаемыми профилями не совсем корректный вариант так как не всё содержиомре папки пользователя переносится, часть программ может потерять настройки и встречаются оригиналы которые умудряются в папке username хранить свои документы т.к туда у них есть права на запись. В принципе и с помошью VBS можно заскриптовать но к сожалению не хватает знаний
Ну почему же? Не думаете же Вы, что вся аудиторя Хабра состоит только из тех, кто хоть раз с этим сталкивался? Новичкам в самый раз.
Хммм… очень непонятно зачем перекидывать юзеров в новый домен, если можно просто поднять новый доменконторллер и повысить его, после чего приведущий домен отключить.

Если же надо мигрировать пользователей именно на новый домен ( в моем случае это была невозможность понижения Riser Domain functional level )тогда можно настроить политики доверия и использовать ADMT, после чего пользователи старого домена без проблем смогут заходить в новый…
А если глюки в АД? Они плавно перетекут на другой сервак. А насчёт ADMT пользователи будут числиться в новом или старом домене?
глюки в АД? например?
Если просто доверенные зоны — в старом. Если выполнить миграцию — и в новом и в старом. Самое главное что при миграции сохранится SID, что немаловажно. А ваш способ это исключает.
Насчёт глюков так сходу и не скажешь. Могу привести пример в Small Business Server 2003нельзя создавать второй DC. Остаётся только такой способ.
Это не глюк, это лицензионное ограничение.
По поводу глюков — действительно было бы любопытно узнать, какие глюки могут «перейти»…
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.