Перевести компьютер из одного домена в другой
По определённым причинам появилась необходимость в переносе пользователей из одного домена в другой. Это возможно сделать штатными средствами операционной системы Microsoft. И в этом нам поможет утилита ldifde.exe . Она предназначена для экспорта/импорта пользователей Active Directory в файл с расширением .ldf . При необходимости его можно редактировать любым текстовым редактором (как в моём случае). Но программа переносит только пользователей, без групп и паролей. Пароли будут сброшены на пустые и при следующем входе в систему будет предложено сменить пароль.
На контроллере домена запускаем командную строку CMD и для удобства переходим в корень диска С c: , так как при выполнении команды вся информация будет выгружена в файл Exportuser.ldf .
ldifde -u -f C:Exportuser.ldf -s SRVDC1 -d "dc=DOMAIN,dc=NAME" -p subtree -r "(&(objectCategory=person)(objectClass=User)(givenname=*))" -l "cn,sn,description,givenName,initials,displayName,name,objectclass,profilePath,homeDirectory,homeDrive,samAccountName,mail"
Где SRVDC1 — это имя контроллера домена, а dc=DOMAIN,dc=NAME — это текущее доменное имя вашего контроллера. На выходе мы получаем файл Exportuser.ldf в корне диска С.
Так как доменное имя нового домена отличается от текущего, то в файле необходимо заменить все строчки dc=DOMAIN,dc=NAME на необходимые, с указанием нового имени. Сохраняемся, перекидываем файл на новый сервер и выполняем импорт следующей командой
Где NEWSRVDC1 — это имя нового контроллера домена.
ПЕРЕНОС ГРУППОВЫХ ПОЛИТИК
Для нормальной работы моего сервера также необходимо было перенести настройки групповых политик (GPO). На старом домене запускаем консоль gpmc.msc. Раскрываем домен, выбираем Объекты групповой политики, в содержимом отмечаем те политики, что собираемся переносить и правой кнопкой мыши вызываем меню. Выбираем Архивировать. Архивирование групповых политик через gpmc.msc
Для нормальной работы моего сервера также необходимо было перенести настройки групповых политик (GPO). На старом домене запускаем консоль gpmc.msc. Раскрываем домен, выбираем Объекты групповой политики, в содержимом отмечаем те политики, что собираемся переносить и правой кнопкой мыши вызываем меню. Выбираем Архивировать. Архивирование групповых политик через gpmc.msc
Далее указываем путь, куда будем выгружать политики. Если у вас более одной политики, то лучше под это создать отдельную директорию, так как под каждую политику будет создаваться новый каталог.
После выбираем Сервис / Заполнить из резервной копии, указываем путь к каталогу. Перед нами откроется таблица со списком всех экспортированных групповых политик.
Нажимаем OK и перед нами откроется список всех нестандартных атрибутов политик. Ищем где упоминается старый домен и правой кнопкой меняем на правильный атрибут из нашего нового домена
Все приготовления закончены, теперь дело за малым — выполнить импорт. Открываем gpmc.msc , создаём новую пустую политику в которую будем импортировать настройки и по правому клику мыши из меню выбираем Импорт параметров. . Идём далее, выбираем папку архива, выбираем соответствующий объект групповой политики, Готово!
Есть комп с юзером «user_1», когда то был в домене «domain_1». Надо перенести этого юзера в новый домен «domain_2» с новым именем «user_2». При этом надо сделать так, что бы когда пользователь зашел в новый домен, он не заметил изменений, т.е. все на своих местах (ярлыки\гаджеты\все настройки всех программ\etc)
Пробовал USMT и Easy Transfer Wizard.
Easy Transfer Wizard не фига не перенес толком, а в USMT я видимо не так что то сделал — тоже не получилось нечего.
Вы что-то всё не то советуете.
Истинная цель это переименование профиля на локальном ПК в новое имя, но для этого надо чтобы пользователь хоть один раз уже залогинился и ему создался профиль из нового домена.
или создать ветку с его SID и явно указать (можно даже на старый профиль)
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
Всё это отлично автоматизируется
Самое правильное решение переименовать профиль старый профиль в новый, после хотя бы одного логина нового пользователя.
Если же Вы не против использования стороннего ПО в момент миграции, то могу посоветовать Forensit Profile Wizard. Скажу из личного опыта, перевод белее двухсот машин из одного домена в другой занял небольшое кол-во времени, и фактически без потери данных пользователей.
Присоединюсь. Очень удобная программа. По приблизительным подсчетам около тысячи профилей (сорее чуть чуть меньше) ей перенес уже.
Реально, необходимо использовать USMT, расскажите, почему не получилось использовать USMT, что пошло не так?
Ответил ниже. Уточню, я вошел, но в пустую учетку, а в папке пользователи была еще папка с пользователем которого я переносил, как то так вроде.
Я видимо не понял до конца логику действий, делал примерно так:
scanstate \\fileserver\migration\mystore /ue:*\* /ui:domain1\user1 /i:miguser.xml /i:migapp.xml /o
Потом ввожу комп в новый домен «domain2», захожу сразу под админом (не заходя под новым пользователем) и ввожу следующее:
loadstate \\fileserver\migration\mystore /mu:domain1\user1:domain2\user2 /i:miguser.xml /i:migapp.xml
Потом почему то не смог войти под пользователем, возможно я что то напутал.
В общем я рекомендую Вам сделать следующее:
1. бэкапим полностью файлы, настройки и.т.д. с помощью USMT, если честно предпочитаю пользоваться мастером переноса, а не командной строкой
2. Вводим новый компьютер в домен, создаем нового доменного пользователя, логинимся в его учетку.
3. И только потом в сеансе созданного пользователя, распаковываем наш архив.
По идее все должно переехать, но иногда некоторые закладки браузера, и некоторая другая лабуда не хочет переезжать, но это не более 5% информации, ее можно вручную перенести.Так что рекомендую держать инфу пользователя еще хотя бы недельку, пока он (она) все проверит.
К примеру есть сеть в 30 пк и AD DS. И AD просто здох. И мы не успели отвязать от него никого. И теперь имеем печальную картину. Можно ли просто поднять новый заново и подключить клиентов без проблем без переустановки осей?
- Вопрос задан более трёх лет назад
- 2983 просмотра
В разных ОС могут быть нюансы, но в целом сценарий такой. Когда прописываем безопасность папок или реестра, не забываем удалять старого пользователя из старого домена, чтобы не пытался его искать и не тормозило.
. ВНИМАНИЕ . Если были у пользователя зашифрованные папки средствами EFS - не перезагружайте компьютер, если он выключен - отключите кабель (чтобы не было сети ethernet), и войдите под старой учёткой (ОС win xp - win7 точно позволяют несколько входов без доступа к домену, кэшируют пароль). Потом скопируйте эти папки и файлы на ФС без поддержки шифрования, например, на флешку fat/exfat. Иначе данные потом будет сложно (но можно) достать.
20ivs, ага, посмотрел на сайте. Стоимость 1 лицензии почти 75 долларов. Это около 4700 р. Извините, но не стоит того, когда 30 машин. Ещё бы посмотреть как лицензируется, а то окажется что 1 лицензия 1 машина, то вообще разорительно выйдет.
Алексей Харченко, pro версия не так чтобы и нужна. Я всегда обходится их версией с бесплатной лицензией.
Алексей Харченко, там есть утилита profwiz, она вам и нужна. есть бесплатная старая версия, не требующая установки вроде даже как. вполне будет достаточно.
20ivs, точно! А profwiz я и забыл, сам тоже пользовался, но не при смене домена, и при переносе профиля на другого пользователя.
По определённым причинам появилась необходимость в переносе пользователей из одного домена в другой. Это возможно сделать штатными средствами операционной системы Microsoft. И в этом нам поможет утилита ldifde.exe. Она предназначена для экспорта/импорта пользователей Active Directory в файл с расширением .ldf. При необходимости его можно редактировать любым текстовым редактором (как в моём случае). Но программа переносит только пользователей, без групп и паролей. Пароли будут сброшены на пустые и при следующем входе в систему будет предложено сменить пароль.
На контроллере домена запускаем командную строку CMD и для удобства переходим в корень диска С c:, так как при выполнении команды вся информация будет выгружена в файл Exportuser.ldf.
Где SRVDC1 — это имя контроллера домена, а dc=DOMAIN,dc=NAME — это текущее доменное имя вашего контроллера. На выходе мы получаем файл Exportuser.ldf в корне диска С.
Так как доменное имя нового домена отличается от текущего, то в файле необходимо заменить все строчки dc=DOMAIN,dc=NAME на необходимые, с указанием нового имени. Сохраняемся, перекидываем файл на новый сервер и выполняем импорт следующей командой
Где NEWSRVDC1 — это имя нового контроллера домена.
Все ответы
Настраиваете трасты между доменами и переносите пользователей.
- Предложено в качестве ответа Alexander Rusinov Moderator 12 февраля 2018 г. 15:21
- Помечено в качестве ответа Petko Krushev Microsoft contingent staff, Moderator 19 февраля 2018 г. 8:33
- Предложено в качестве ответа Alexander Rusinov Moderator 12 февраля 2018 г. 15:21
- Помечено в качестве ответа Petko Krushev Microsoft contingent staff, Moderator 19 февраля 2018 г. 8:33
Формулировка вашего вопроса мягко намекает о некоторой полной вашей не компетенции в данном вопросе(логично, иначе вы бы и не спрашивали)
Если конторы маленькие (где то +- менее 50 сотрудников) - зачастую имеет смысл не заморачиваться миграцией, а просто создать новые учетки и перезагнать клиентские машинки в новый домен. мелкие объемы данных конвертнуть ручками(права там и все такое)
Более крупные (и\или старые конторы с большим количеством данных) требуют более аккуратного подхода. Тут уже включаем трасты, вышеупомянутый ADMT, зачастую sid-history и все такое. Обычно вылазит куча проблем с интеграцией данных и приложений в новую среду и прочее.
В случае больших контор (навскидку от 5к народу и более) вам прямая дорога к интеграторам, реально дешевле выйдет чем самим.
- Помечено в качестве ответа Petko Krushev Microsoft contingent staff, Moderator 19 февраля 2018 г. 8:33
Да, действительно, ни разу не стояла такая задача. Организация, что одна, что вторая менее 50 человек. Время есть, обдумаю варианты.
если менее 50 человек народу, несите аз из напрямую, это реально проще и не парьтесь.
Она у них сеичас общая. В марте одни планируют переехать. Как вы предлагаете ее общей оставить? Через VPN? Да и организация , что переезжает хочет все отдельно иметь.
давайте будем жрать слона по частям.
Сетка пока не суть как важна, давайте определитесь с ресурсами:
есть ли в сурс домене(который вы собираетесь мигрировать в существующую инфраструктуру) следующее - Файловые сервера(включая и мигрируемые\перенаправляемые профили пользователей),Сервера приложений и БД(в случае БД какой тип аутентификации был использован), критичные приложения типа 1Ски и банковских прог следует вообще рассматривать отдельно.
Какое время вы готовы уделить самой миграции? Подход херакс-херакс и в продакшен тоже имеет место быть, однако будьте готовы к крикам юзверей что чтото не работает.
Каким образом организована система доступа пользователей и их данных? Имеет ли место быть использование пользователями локальных хранилищь и ресурсов(шаренные папки на клиентских компах, доступ до расшаренных принтеров и т.п). Практика пользователей хранить данные локально и т.п.
Насколько сильно различаются инфраструктуры пользовательских мест(различные ОС, версии офиса, антивирус, нейминг клиентских машин и прочее). Нужна ли будет стандартизация с ребилдом?
Миграция это не только ценный мех, но и возможность реорганизовать структуру(однако это затребует определенных ресурсов, времени и телодвижений). Оно вам надо или и так сойдет?
З.Ы. контроллеров домена таки желательно 2. Сурс домен насколько сильно делеко расположен географически? Нужен ли будет геореданс? Репликация данных?
Очень много букв.. )) Половина из того что вы написали, на самом деле ни каких сложностей скорее всего не представляет. Есть файл сервер, есть сервер 1С, который крутится на скуле. В чем сложность создать доверие между существующим и созданным доменом и дать права на папку пользователей нового домена? И далее перенести папку на новый файлсервер, который будет переезжать. А 1С, с ним какие проблемы могут быть? Скуль работает в режиме аутентификации скуля и windows. Все базы подключаются или создаются с учеткой sa. Проблемы перемещения баз на новый сервер скорее всего та же не возникнут. А под банковскими программами - с какими из них могут возникнуть проблемы? И по поводу двух КД. Я делаю всегда один. Так меньше проблем с восстановлением. На всех серверах у меня стоят контроллеры Adaptec и подняты рейд массивы. Всегда в запасе есть запасной контроллер, и дисков уж не помню сколько. Архивация серверов сеичас делается средствами акронис в зону безопасности акронис. Это все так же реализовал на новых серверах.
Очень много букв.. )) Половина из того что вы написали, на самом деле ни каких сложностей скорее всего не представляет. Есть файл сервер, есть сервер 1С, который крутится на скуле. В чем сложность создать доверие между существующим и созданным доменом и дать права на папку пользователей нового домена? И далее перенести папку на новый файлсервер, который будет переезжать. А 1С, с ним какие проблемы могут быть? Скуль работает в режиме аутентификации скуля и windows. Все базы подключаются или создаются с учеткой sa. Проблемы перемещения баз на новый сервер скорее всего та же не возникнут. А под банковскими программами - с какими из них могут возникнуть проблемы? И по поводу двух КД. Я делаю всегда один. Так меньше проблем с восстановлением. На всех серверах у меня стоят контроллеры Adaptec и подняты рейд массивы. Всегда в запасе есть запасной контроллер, и дисков уж не помню сколько. Архивация серверов сеичас делается средствами акронис в зону безопасности акронис. Это все так же реализовал на новых серверах.
Если вы "подготовленные" и в чем суть проблемы, вопроса?
Перенос групповых политик
Для нормальной работы моего сервера также необходимо было перенести настройки групповых политик (GPO). На старом домене запускаем консоль gpmc.msc. Раскрываем домен, выбираем Объекты групповой политики, в содержимом отмечаем те политики, что собираемся переносить и правой кнопкой мыши вызываем меню. Выбираем Архивировать. .
Далее указываем путь, куда будем выгружать политики. Если у вас более одной политики, то лучше под это создать отдельную директорию, так как под каждую политику будет создаваться новый каталог.
После выбираем Сервис / Заполнить из резервной копии, указываем путь к каталогу. Перед нами откроется таблица со списком всех экспортированных групповых политик.
Нажимаем OK и перед нами откроется список всех нестандартных атрибутов политик. Ищем где упоминается старый домен и правой кнопкой меняем на правильный атрибут из нашего нового домена
Все приготовления закончены, теперь дело за малым — выполнить импорт. Открываем gpmc.msc, создаём новую пустую политику в которую будем импортировать настройки и по правому клику мыши из меню выбираем Импорт параметров. . Идём далее, выбираем папку архива, выбираем соответствующий объект групповой политики, Готово!
Добрый вечер. В одной локальной сети находятся две организации. Обслуживает их один DC на Server 2012r2. В ближайшее время одна организация будет переезжать, а имеющийся DC остается в старом офисе. Для организации, что будет переезжать, приобретен новый сервер. В данный момент на нем поднят второй контроллер так же на server 2012R2 с новым доменом. Такой вопрос. Можно ли часть пользователей и компьютеров из одного домена перенести в другой?
Ответы
Формулировка вашего вопроса мягко намекает о некоторой полной вашей не компетенции в данном вопросе(логично, иначе вы бы и не спрашивали)
Если конторы маленькие (где то +- менее 50 сотрудников) - зачастую имеет смысл не заморачиваться миграцией, а просто создать новые учетки и перезагнать клиентские машинки в новый домен. мелкие объемы данных конвертнуть ручками(права там и все такое)
Более крупные (и\или старые конторы с большим количеством данных) требуют более аккуратного подхода. Тут уже включаем трасты, вышеупомянутый ADMT, зачастую sid-history и все такое. Обычно вылазит куча проблем с интеграцией данных и приложений в новую среду и прочее.
В случае больших контор (навскидку от 5к народу и более) вам прямая дорога к интеграторам, реально дешевле выйдет чем самим.
- Помечено в качестве ответа Petko Krushev Microsoft contingent staff, Moderator 19 февраля 2018 г. 8:33
Настраиваете трасты между доменами и переносите пользователей.
- Предложено в качестве ответа Alexander Rusinov Moderator 12 февраля 2018 г. 15:21
- Помечено в качестве ответа Petko Krushev Microsoft contingent staff, Moderator 19 февраля 2018 г. 8:33
- Предложено в качестве ответа Alexander Rusinov Moderator 12 февраля 2018 г. 15:21
- Помечено в качестве ответа Petko Krushev Microsoft contingent staff, Moderator 19 февраля 2018 г. 8:33
ПЕРЕНОС ГРУППОВЫХ ПОЛИТИК
Для нормальной работы моего сервера также необходимо было перенести настройки групповых политик (GPO). На старом домене запускаем консоль gpmc.msc. Раскрываем домен, выбираем Объекты групповой политики, в содержимом отмечаем те политики, что собираемся переносить и правой кнопкой мыши вызываем меню. Выбираем Архивировать. Архивирование групповых политик через gpmc.msc
Для нормальной работы моего сервера также необходимо было перенести настройки групповых политик (GPO). На старом домене запускаем консоль gpmc.msc. Раскрываем домен, выбираем Объекты групповой политики, в содержимом отмечаем те политики, что собираемся переносить и правой кнопкой мыши вызываем меню. Выбираем Архивировать. Архивирование групповых политик через gpmc.msc
Далее указываем путь, куда будем выгружать политики. Если у вас более одной политики, то лучше под это создать отдельную директорию, так как под каждую политику будет создаваться новый каталог.
После выбираем Сервис / Заполнить из резервной копии, указываем путь к каталогу. Перед нами откроется таблица со списком всех экспортированных групповых политик.
Нажимаем OK и перед нами откроется список всех нестандартных атрибутов политик. Ищем где упоминается старый домен и правой кнопкой меняем на правильный атрибут из нашего нового домена
Все приготовления закончены, теперь дело за малым — выполнить импорт. Открываем gpmc.msc , создаём новую пустую политику в которую будем импортировать настройки и по правому клику мыши из меню выбираем Импорт параметров. . Идём далее, выбираем папку архива, выбираем соответствующий объект групповой политики, Готово!
Есть комп с юзером «user_1», когда то был в домене «domain_1». Надо перенести этого юзера в новый домен «domain_2» с новым именем «user_2». При этом надо сделать так, что бы когда пользователь зашел в новый домен, он не заметил изменений, т.е. все на своих местах (ярлыки\гаджеты\все настройки всех программ\etc)
Пробовал USMT и Easy Transfer Wizard.
Easy Transfer Wizard не фига не перенес толком, а в USMT я видимо не так что то сделал — тоже не получилось нечего.
Вы что-то всё не то советуете.
Истинная цель это переименование профиля на локальном ПК в новое имя, но для этого надо чтобы пользователь хоть один раз уже залогинился и ему создался профиль из нового домена.
или создать ветку с его SID и явно указать (можно даже на старый профиль)
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
Всё это отлично автоматизируется
Самое правильное решение переименовать профиль старый профиль в новый, после хотя бы одного логина нового пользователя.
Если же Вы не против использования стороннего ПО в момент миграции, то могу посоветовать Forensit Profile Wizard. Скажу из личного опыта, перевод белее двухсот машин из одного домена в другой занял небольшое кол-во времени, и фактически без потери данных пользователей.
Присоединюсь. Очень удобная программа. По приблизительным подсчетам около тысячи профилей (сорее чуть чуть меньше) ей перенес уже.
Реально, необходимо использовать USMT, расскажите, почему не получилось использовать USMT, что пошло не так?
Ответил ниже. Уточню, я вошел, но в пустую учетку, а в папке пользователи была еще папка с пользователем которого я переносил, как то так вроде.
Я видимо не понял до конца логику действий, делал примерно так:
scanstate \\fileserver\migration\mystore /ue:*\* /ui:domain1\user1 /i:miguser.xml /i:migapp.xml /o
Потом ввожу комп в новый домен «domain2», захожу сразу под админом (не заходя под новым пользователем) и ввожу следующее:
loadstate \\fileserver\migration\mystore /mu:domain1\user1:domain2\user2 /i:miguser.xml /i:migapp.xml
Потом почему то не смог войти под пользователем, возможно я что то напутал.
В общем я рекомендую Вам сделать следующее:
1. бэкапим полностью файлы, настройки и.т.д. с помощью USMT, если честно предпочитаю пользоваться мастером переноса, а не командной строкой
2. Вводим новый компьютер в домен, создаем нового доменного пользователя, логинимся в его учетку.
3. И только потом в сеансе созданного пользователя, распаковываем наш архив.
По идее все должно переехать, но иногда некоторые закладки браузера, и некоторая другая лабуда не хочет переезжать, но это не более 5% информации, ее можно вручную перенести.Так что рекомендую держать инфу пользователя еще хотя бы недельку, пока он (она) все проверит.
К примеру есть сеть в 30 пк и AD DS. И AD просто здох. И мы не успели отвязать от него никого. И теперь имеем печальную картину. Можно ли просто поднять новый заново и подключить клиентов без проблем без переустановки осей?
- Вопрос задан более трёх лет назад
- 2983 просмотра
В разных ОС могут быть нюансы, но в целом сценарий такой. Когда прописываем безопасность папок или реестра, не забываем удалять старого пользователя из старого домена, чтобы не пытался его искать и не тормозило.
. ВНИМАНИЕ . Если были у пользователя зашифрованные папки средствами EFS - не перезагружайте компьютер, если он выключен - отключите кабель (чтобы не было сети ethernet), и войдите под старой учёткой (ОС win xp - win7 точно позволяют несколько входов без доступа к домену, кэшируют пароль). Потом скопируйте эти папки и файлы на ФС без поддержки шифрования, например, на флешку fat/exfat. Иначе данные потом будет сложно (но можно) достать.
20ivs, ага, посмотрел на сайте. Стоимость 1 лицензии почти 75 долларов. Это около 4700 р. Извините, но не стоит того, когда 30 машин. Ещё бы посмотреть как лицензируется, а то окажется что 1 лицензия 1 машина, то вообще разорительно выйдет.
Алексей Харченко, pro версия не так чтобы и нужна. Я всегда обходится их версией с бесплатной лицензией.
Алексей Харченко, там есть утилита profwiz, она вам и нужна. есть бесплатная старая версия, не требующая установки вроде даже как. вполне будет достаточно.
20ivs, точно! А profwiz я и забыл, сам тоже пользовался, но не при смене домена, и при переносе профиля на другого пользователя.
По определённым причинам появилась необходимость в переносе пользователей из одного домена в другой. Это возможно сделать штатными средствами операционной системы Microsoft. И в этом нам поможет утилита ldifde.exe. Она предназначена для экспорта/импорта пользователей Active Directory в файл с расширением .ldf. При необходимости его можно редактировать любым текстовым редактором (как в моём случае). Но программа переносит только пользователей, без групп и паролей. Пароли будут сброшены на пустые и при следующем входе в систему будет предложено сменить пароль.
На контроллере домена запускаем командную строку CMD и для удобства переходим в корень диска С c:, так как при выполнении команды вся информация будет выгружена в файл Exportuser.ldf.
Где SRVDC1 — это имя контроллера домена, а dc=DOMAIN,dc=NAME — это текущее доменное имя вашего контроллера. На выходе мы получаем файл Exportuser.ldf в корне диска С.
Так как доменное имя нового домена отличается от текущего, то в файле необходимо заменить все строчки dc=DOMAIN,dc=NAME на необходимые, с указанием нового имени. Сохраняемся, перекидываем файл на новый сервер и выполняем импорт следующей командой
Где NEWSRVDC1 — это имя нового контроллера домена.
Читайте также: