Vvmebel.com

Новости с мира ПК
17 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Перенос пользователей из одного домена в другой

Перенос пользователей из одного домена в другой

Привет всем!
Имеется домен на Windows 2003 Server Std SP2 R2 название домена firma (т.е. Single Label)
Сейчас возникла необходимость (в связи с переименованием организации) перенести пользователей в новый домен firma1.local (заодно и от Single label избавиться). Планирую сделать следующее
1. Поднять новый домен Firma1.local
2. Установить доверительные отношения между доменами firma и firma1.local
3. Постепенно перевести пользователей и компьютеры из домена Firma в Firma1.local
4. Когда все пользователи и компьютеры будут перенесены разорвать доверительные отношения и убрать домен firma

Важно , чтобы в процессе переноса пользователей и компьютеров из одного домена в другой не было прерывания их работы.
В сети имеется терминальный сервер 1С8, почтовик Мдаемон, развернут Symantec CE 10
Отсюда вопросы
1. Вообще возможен ли такой вариант, хотелось бы узнать мнения тех кто делал подобное.
2. Как к переносу сервера из одного домена в другой отнесется 1С8, Мдаемон, Symantec
3. Что будет с правами пользователей в NTFS на каталоги. Допустим есть каталог Ivanov туда имеет доступ сам Ivanov (ivanov@firma) и группа администраторов домена firma , теперь переносим пользователя ivanov в домен firma1.local изменятся ли права на каталог автоматически или же придется их менять вручную.
4. Спомощью какой утилиты переносить пользователей из одного домена в другой ADMT или есть какие-нибудь другие.

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

Что в данном контексте означает «переносим» и «прерывание работы»? Если «переносим» — создание новой учетки в другом домене, то, разумеется, пользователям придется как минимум перелогиниваться с новыми реквизитами.

2. Как к переносу сервера из одного домена в другой отнесется 1С8, Мдаемон, Symantec

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

Допустим есть каталог Ivanov туда имеет доступ сам Ivanov (ivanov@firma) и группа администраторов домена firma , теперь переносим пользователя ivanov в домен firma1.local изменятся ли права на каталог автоматически или же придется их менять вручную.

И еще раз: что означает «переносим»? Новая учетка? И как сервер должен понимать, что новая и старая учетки принадлежат одному пользователю и должны иметь одинаковые права?

Добавление от 28.01.2008 10:56:

Lotto
Под прерыванием работы имется ввиду следующее. Домен , пользователи и компьютеры в целом должены функционировать , отдельные пользователи , учетки и компьютеры которых переносятся в другой домен могут прерывать работу на 1-2 часа.
Под «переносим» я понимал именно перенос пользовтаеля из одного домена в другой с сохранением SID , а не создание нового пользователя в другом домене с таким же именем.

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

мое мнение — переводить в другой домен гораздо проблематичнее. гораздо больше шансов огрести неделю ночной работы.

1. Такой вариант возможен.
2. 1С и Симантек абсолютно всеравно, Мдаемон не знаю, мигрировал домен с Exchange.
3. Если мигрируешь учетную запись с SID, то права сохранятся.
4. Переносить нужно при помощи ADMT с сохранением SID. Алгоритм переноса таков: переносишь все группы в которые входит пользователь кроме соответственно встроенных и локальных доменных, потом пользователя, потом компьютер пользователя.

P. S. Учетную запись старого домена, под которой будут мигрироваться пользователи, нужно будет внести во встроенную группу администраторы нового домена. Если что-то непонятно, могу расписать подробнее.

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

При переносе групп и пользователей можно указать добавление SID к SID history в новом домене.
Весь процесс можно разделить на два этапа, первый это мигрирование пользователей и групп, второй мигрирование компьютеров.
При мигрировании пользователя или группы в новом домене создается такой же объект в новым сидом, после чего сид из старого домена добавляется к SID history, следовательно NTSF права и все прочее сохраняется.
Миграция компьютеров и серверов это вообще отдельная тема, компьютер обязательно должен быть включен, ADMT после миграции учетки компа удаленно средствами RPC установит и запустит агента, который переколбасит НТФС права и профили юзерей. Ес-но надо не напутаться с ДНС-ами и прочее.

Вообщем лучше всего потренироваться если ранее этого не делал, много всяких тонкостей, всего и не объяснишь на пальцах.

Добавление от 29.01.2008 13:29:

Непонятно как и в какой момент мигрировать группы (в которых пользователи)
и OU в которых компьютеры

Странник
Как там описание поживает?

Вот, наконец закончил.

Подготовка к миграции домена:
1. Установить утилиту ADMT на контроллере домена в старом домене.
2. Удостовериться что новый домен находится в nativ mode.
3. Установить двухсторонние доверительные отношения между старым и новым доменами.
4. Настроить репликацию WINS между серверами WINS старого и нового доменов.
5. В новом домене изменить Default Domain Controllers Policy — открыть Computer Configuration/
Windows Settings/ Security Settings/ Local Policies/ Security Options/ Network access/ — включить
опцию Let Everyone permissions apply to anonymous users.
6. Добавить группу Everyone в группу Pre-Windows 2000 Compatible Access, запустив команду
net localgroup «Pre-Windows 2000 Compatible Access» Everyone /add.
7. Добавить группу Anonymous Logon в группу Pre-Windows 2000 Compatible Access, запустив команду
net localgroup «Pre-Windows 2000 Compatible Access» «Anonymous Logon» /add.
8. Перезагрузить контроллер домена.
9. Создать в старом домене (например в домене firma) пустую локальную группу firma$$$.
10. Удостовериться в том, что все подключенные сетевые диски между контроллерами старого и нового
доменов отключены.
11. На PDC старого домена в реестре создаем запись HKEY_LOCAL_MACHINESystemCurrentControlSet
ControlLsaTcpipClientSupport:REG_DWORD и задаем значение — 0х1. Этот сервер будет
выступать как исходный контейнер для пользователей, групп и компьютеров.
12. Перезагружаем контроллер домена.
13. На контроллере домена старого домена (например в домене firma.local) на котором установлен
ADMT установить дискету в дисковод а и из командной строки перейти в каталог в котором
установлен ADMT и набрать команду admt key firma.local a: * В ответ на запрос — ввести пароль.
14. С установочного диска Windows 2003 Server из каталога i386Admt запустить программу
Pwdmig.exe.
15. При запросе сохраненного файла паролей — указать путь к дискете, созданной в п. 13.
16. Учетная запись, под которой планируется осуществить миграцию домена, должна обладать
следующими правами — быть членом в группе Administrators старого домена, администратором
на всех компьютерах, которые необходимо мигрировать, членом Domain Admins в новом домене.
17. Должен быть включен аудитуправления учетными записями пользователей и групп в старом
и новом доменах.
18. С помощью утилиты Netdom необходимо разрешить применение механизма SIDHistory, выполнив
на контроллере нового домена следующую команду:
netdom trust firma.domain.old /domain:firma.domain.new /enablesidhistory:yes
19. С помощью утилиты Netdom необходимо отключить фильтрацию SID, выполнив на контроллере
нового домена следующую команду:
netdom trust firma.domain.old /domain:firma.domain.new /quarantine:no

Миграция:
1. Мигрируем глобальные и универсальные группы с включением опций Update user rights и
Migrate group SIDs to target domain.
2. Мигрируем пользователя с включенными опциями Migrate password, Enable target accounts,
Migrate user SIDs to target domain, Update user rights, Fix users group memberships.
3. Перед миграцией компьютера проверяем входит ли учетная запись под которой планируется
осуществить миграцию в группу локальных администраторов, отключаем все файерволы и
останавливаем их службы, проверяем запущены ли службы «Удаленный вызов процедур (RPC)» и
«Удаленный реестр». При миграции, если к компьютеру локально не подключены принтеры, то
устанавливаем все флажки кроме printers, если принтер подключен, то устанавливаем и этот
флажок.

Читать еще:  Виды списков в текстовом редакторе word

Вот вроде и все. При миграции важен следующий порядок: сначала мигрируем группы, затем
пользователя и только потом компьютер на котором находится профиль пользователя, иначе
у пользователя в новом домене появится новый профиль и все его настройки потеряются.
Компьютер рекомендуется мигрировать сразу после пользователя. Необходимо иметь ввиду,
что если миграция группы и пользователя занимает несколько секунд, то миграция компьютера
может занять несколько часов, в зависимости от объема данных и мощности компьютера.

Str@nNik13
Супер.

1. Пункт 5,6,7
В статье http://support.microsoft.com/kb/326480/ru я такого не нашел, а в http://www.networkdoc.ru/active-directory/active-dir…n-tool-2.0-3.html эта опция есть. В первой статье (где опции нет) идет миграция с 2000 на 2003 , во второй статье с NT4 на 2003, я думаю если мигрировать с 2003 на 2003 , то эту опцию включать не надо. Прошу опровергнуть , если не прав.

2. Пункт 10.
У меня к каждому компьютеру политиками при загрузке цепляется сетевой диск на котором каждый пользователь имеет свою папку в которой хранит документы. Доступ на папку только у него и администраторов. Поясните необходимость при миграции отключать сетевой диск.

3. Пункт 18,19
Таких опций я не нашел ни в одной статье. Может они по умолчанию выставлены в правильный вариант?

4. Компьютеры у меня разбиты по нескольким OU , не подскажете как мигрировать OU или достаточно их просто заново создать в новом домене?

Добавление от 30.01.2008 12:56:

Не совсем понятно как быть с политиками.
Их в новом доме надо заново создать или можно ка-то перенести.

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

Политики создавать занаво.

Fedorm
А как OU переносить? Просто в новом домене заново создать?
И зачем сетевые диски при миграции отключать?

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

Видимо чтобы не было замены прав пользователей на них.

Миграция объектов между доменами Active Directory

В этой статье я расскажу о том, как правильно организовать процесс миграции пользователей и ресурсов между доменами Active Directory без прерывания доступа. В статье будут рассмотрены:

  • общий подход к миграции
  • как работает SID History
  • сценарии миграции и подход к администрированию для каждого из них

Для понимания изложенного в данной статье материала требуется понимание предыдущей статьи — Построение ролевой модели в Active Directory.

Содержание

  • Общий подход к миграции
  • Сценарии миграции объектов Active Directory
    • Сценарий 0 — исходное состояние
    • Сценарий 1.1 — миграция пользователей в целевой домен
    • Сценарий 1.2 — создание новых пользователей в целевом домене
    • Сценарий 2.1 — развёртывание ресурсов в целевом домене
    • Сценарий 2.2 — развёртывание ресурсов в исходном домене
    • Сценарий 2.3 — миграция ресурсов в целевой домен
    • Сценарий 3 — все пользователи и ресурсы мигрированы
  • Заключение
  • Полезные ссылки

Общий подход к миграции

Пока компания работает в одном домене AD, необходимость в четкой ролевой модели с использованием AGULP не очевидна.

Если для компании настало время реструктуризации, слияний и поглощений, приведение ролевой модели к AGULP является необходимостью для обеспечения предсказуемой работы AD в сложных конфигурациях с несколькими лесами / доменами.

Использование ролевой модели на основе AGULP позволяет проводить процедуры миграции объектов AD так, как задумывалось разработчиками:

  • Миграции пользователей и ресурсов могут проходить отдельными, слабо зависимыми друг от друга потоками
  • При этом в любой момент времени доступ всех пользователей ко всем ресурсам сохраняется в прежнем объеме

Сценарии миграции объектов Active Directory

Рассмотрим возможные сценарии в период миграции Active Directory.

Сценарий 0 — исходное состояние

  • пользователи и ресурсы находятся в исходном домене

Если ролевая модель ещё не приведена к AGULP, то это необходимо сделать на данном этапе, поскольку все рассмотренные далее сценарии подразумевают приведённую к AGULP ролевую модель.

Важное примечание

Встроенные группы, такие как: Domain Users, Domain Admins, Remote Desktop Users и другие, — не могут быть мигрированы в другой домен, поскольку их SID/RDN во всех доменах одинаков.

Из этого вытекает важное правило: не используйте встроенное группы для назначения разрешений. Если со своим предупреждением я опоздал… Для сохранения доступа пользователей во времена миграции вам необходимо перед миграцией переназначить все разрешения, со встроенных групп на обычные.

Полный список встроенных групп можно найти в статье Active Directory Security Groups.

Сценарий 1.1 — миграция пользователей в целевой домен

  • часть пользователей мигрирована в целевой домен
  • в исходном домене остались ресурсы, к ним необходимо сохранить доступ

Пользователи и группы должны мигрировать в новый домен с сохранением SID History и всех связей групп безопасности.

При обращениях пользователей, мигрированных в целевой домен, к ресурсам исходного домена, используется набор родных SID-ы из целевого домена и SID History:

  • Набор родных SID-ов из целевого домена включает SID пользователя и SID-ы всех групп, в которых он состоит в целевом домене (Account Domain).
  • SID History включает скопированные при миграции SID пользователя и SID-ы всех групп, в которых он состоял в исходном домене.
  • SID-ы локальных групп (в том числе мигрированных c SID History), отфильтровываются при прохождении через доверительные отношения и не предъявляются в домене ресурса.
  • Оставшиеся SID-ы проверяются на членство в локальных группах домена ресурса (Resource Domain). Если в домене ресурса обнаружены группы, в членах которых состоят предъявленные пользователем SID-ы, то SID-ы таких локальных групп включаются в токен доступа пользователя.
  • Таким образом, результирующий токен доступа пользователя в домене ресурсов включает SID-ы из: Account Domain (user, global groups, universal groups), SID History (user, global groups, universal groups), Resource Domain (local groups).

Так как в ACL на ресурсах прописаны SID-ы групп доступа исходного домена, ресурсы идентифицируют мигрированных пользователей по описанному выше алгоритму, доступ мигрированных пользователей сохраняется в прежнем объеме, каким он был до миграции.

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

Сценарий 1.2 — создание новых пользователей в целевом домене

  • часть пользователей мигрирована в целевой домен
  • в целевом домене создаются новые пользователи

Описанные в предыдущих сценариях механизмы администрирования ресурсов должны сохраняться.

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

Администрирование групп (вложенность в группы доступа и другие ролевые группы) должно производится в исходном домене.

Читать еще:  Настройка контроллера домена 2020 r2 с нуля

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

Сценарий 2.1 — развёртывание ресурсов в целевом домене

  • часть пользователей мигрирована в целевой домен
  • в целевом домене необходимо развёртывать новые ресурсы

Описанные в предыдущих сценариях механизмы администрирования ресурсов должны сохраняться.

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

  • мигрированные ролевые группы в целевом домене (для доступа к ресурсам мигрированных и новых пользователей, созданных только в целевом домене)
  • ролевые группы из исходного домена (для доступа к ресурсам еще не мигрированных пользователей)

Администрирование доступа к развернутым в целевом домене ресурсам должно осуществляется через группы доступа в целевом домене.

Сценарий 2.2 — развёртывание ресурсов в исходном домене

  • часть пользователей мигрирована в целевой домен
  • в исходном домене необходимо развёртывать новые ресурсы

Описанные в предыдущих сценариях механизмы администрирования ресурсов должны сохраняться.

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

  • ролевые группы из исходного домена (для доступа к ресурсам еще не мигрированных пользователей)
  • мигрированные ролевые группы в целевом домене (для доступа к ресурсам новых пользователей, созданных только в целевом домене)

Администрирование доступа к развернутым в исходном домене ресурсам должно осуществляется через группы доступа в этом же домене.

Данный сценарий зеркально повторяет предыдущий.

Сценарий 2.3 — миграция ресурсов в целевой домен

  • часть пользователей мигрирована в целевой домен
  • из исходного домена необходимо мигрировать ресурс в целевой домен

Описанные в предыдущих сценариях механизмы администрирования ресурсов должны сохраняться.

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

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

Как перенести учетные записи пользователей из одного домена в другой на Windows 2008?

(Как скопировать учетные записи пользователей из одного домена в другой на Windows 2008)

Абсолютно не травильная задача особенно если хочется перенести пользователей с паролями.

Есть несколько способов от примитивных до самых изощрённых. Отличия в трудоемкости переноса и в конечном результате. (Для своей задачи рассмотрел всего лишь несколько первых попавшихся из-за ограниченности времени).

Итак, способы (обзор):

1) Командная строка и Excel.

2) Утилита CSVDE.

3) Утилиты из Resource Kit 2008 Server.

4) Active Directory Migration Tool.

5) Программа POINTDEV IDEAL Migration.

1. Командная строка и Excel

Для создания пользователей используется команда net user (Использование команды «net user»), например так

net user bob 123 /add /comment:»My user» /fullname:»Иванов Иван» /domain

Чтобы получить набор строк net user, нужно получить список пользователей, который можно обработать в Excel. Пример, вот такой список

В столбце D – формула:

=СЦЕПИТЬ(«net user «;A2;» 123 /add /comment:»;СИМВОЛ(34);»My user»;СИМВОЛ(34);» /fullname:»;СИМВОЛ(34);C2;» «;B2;СИМВОЛ(34);» /domain»)

Как получить список пользователей: Список может существовать в виде файла (админы иногда сохраняют списки пользователей в файлы). Можно с помощью программы POINTDEV IDEAL Migration, она даже в триальном варианте позволяет выгрузить пользователей в файл cvs. Можно прямо с экрана снять снимок и распознать в ABBYY FineReader, если снимок снимать SnagIt то он сам умеет распознавать.

— Пользователи создаются в примитивном варианте, большая часть полей и опций не переноситься

— Пароль не переноситься

+ Всё очень просто и может быть быстро

2. Утилита CSVDE

Позволяет импортироватьэкспортировать данные из каталога LDAP в файл cvs (в том числе и учетные записи пользователей).

Есть целый сайт посвященный описанию CSVDE Home

— Желательно знать устройство LDAP Active Directory (какие поля чего означают)

+ Бесплатно и не нужно устанавливать

3. Утилиты из Resource Kit 2008 Server

Утилиты addusers, moveuser. Addusers – аналог net user, но более функциональный, например позволяет создавать сразу кучу пользователи из файла-списка. Moveuser – позволяет перенести учетную запись прямо с одного компьютера на другой.

Описание есть здесь:

Сам набор утилит Resource Kit 2008 Server официально он продается в виде набора классных книг (сам не читал – сужу по отзывам) и CDROM диска к ним. Не официально есть на торренте.

— Нужно искать, скачивать или покупать

— Платно

+ Более функционально чем net user

4. Active Directory Migration Tool

Набор средств (утилит) для миграции Active Directory. Изучить – не просто.

— Сложно освоить (документация 263 страницы)

+ Бесплатно

+ Перенести можно наверное что угодно (например, пароли переносятся, но при установке еще каких-то дополнительных компонентов)

5. Программа POINTDEV IDEAL Migration

Позволяет переносить полные сведения домена. Программа платная. Можно получить триальный ключ за просто так, но только на 15 дней и мигрировать можно только 5 пользователей. Программа в триальном варианте позволяет просто выгрузить список пользователей в файл cvs.

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

Перенос групповых политик между доменами

В этой статье мы покажем как можно с минимальными усилиями перенести объекты групповых политик из одного домена в другой. Вопрос миграции доменных политик возник в рамках одной из задач миграции данных и пользователей из одного домена (на базе Windows Server 2008 R2) в новый «чистый» домен на базе Windows Server 2012. В общем-то, версия доменов и схем принципиального значения не имеет, главное, чтобы в обоих доменах использовалась свежая версия консоли управления групповыми политиками (GPMC).

В первую очередь в домене-источнике создадим копию текущих групповых политик с помощью консоли GPMC. Для этого запустите консоль gpmc.msc, перейдите в раздел Group Policy Objects и в контекстном меню выберите пункт Backup Up All.

Укажите каталог, в который необходимо сохранить резервную копию всех GPO (в нашем примере это S:Backup), краткое описание копии и нажмите кнопку Back Up.

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

В каталоге с резервной копией должны появится несколько каталогов, соответствующих содержимому доменного каталога с политиками (\domain.ruSYSVOLdomainPolicies).

Следующий этап – импорт политик в домен-приемник. Но прежде, чем приступить к переносу, нужно избавиться в старых политиках о любых упоминаниях или ссылок на ресурсы исходного домена (ссылки на домен, его объекты, SID-ы и пр.), исправив их на значения нового домена. Для этого нам понадобится утилита Migration Table Editor, которая входит в состав консоли GPMC.

В новом домене откройте консоль GPMC, перейдите на уровень Group Policy Objects. В контекстном меню выберите пункт Open Migration Table Editor (утилиту можно запустить вручную, находится она тут: C:WindowsSystem32mtedit.exe).

В открывшемся окне утилиты Migration Table Editor выберите пункт меню Tools -> Populate from Backup.

Читать еще:  Activex hosting plugin

Укажите путь к каталогу с резервной копией объектов GPO первичного домена. Выберите список политик, которые нужно обработать (в нашем случае все) и нажмите ОК.

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

После того, как вся проверка будет окончена, сохраните результаты в специальный файл с расширением .migtable (файл имеет xml формат). Итак, у нас получился –файл соответствуй между различными объектами и именами двух доменов.

Что же, подготовительные операции завершены и мы переходим непосредственно к импорту старых политик в новый домен. Для этого в консоли GPMC создайте новый пустой объект групповой политики с именем, аналогичному имени политики в старом домене. Щелкните по ней ПКМ и в меню выберите пункт Import Settings.

Укажите путь к каталогу с резервной копией политик первого домена и выберите политику, настройки которой нужно импортировать.

В окне Migrating References выберите опцию Using this migration table to map them in the destination GPO, и укажите путь к ранее созданному файлу .migtable. Нажмите Next, после чего должен осуществится процесс импорта настроек старой политики в новую по правилам, указанным в файле миграции.

Таким же способом нужно перенести все оставшиеся политики. Осталось привязать перенесенные политики к нужным OU, предварительно протестировав их работу на тестовых пользователях/компьютерах.

Перенос профилей пользователей в Windows XP

Andrew | Posted on 02.11.2009 |

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

Профиль пользователя отличается от учетной записи пользователя, которая используется для входа в Windows. У каждой учетной записи есть по крайней мере один связанный с ней профиль пользователя.

Перед нами стоит задача перенести пользователей из одного домена в другой домен с сохранение профиля пользователя.

Естественно есть несколько различных способов. Рассмотрим некоторые из них.

Самое правильное наверное воспользоваться специальной утилитой от Microsoft’а USMT.

Так же в Windows есть «Мастер переноса файлов и параметров«. Пуск -> Все программы -> Стандартные -> Служебные -> Мастер переноса файлов и параметров

Еще есть специальная утилита Ideal Migration, тоже можно попробовать.

На просторах интернета был найден следующий способ.

Шаг 1. Переводим машину в новый домен.

Шаг 2. Входим новым пользователем, создается профиль

Шаг 3. Выходим. Входим под локальным администратором

Шаг 4. Удаляем новый профиль. Переименовываем старый в новое имя. Добавляем права для нового пользователя на доступ.

Шаг 5. Грузимся новым пользователем и попадаем в старый профиль со всеми настройками.

— не требуется дисковое пространство

— перенос моментален, вместо копирования — переименовывание папки

— бОльшая часть программ и их настроек сохраняет работоспособность

Пароли к прокси слетают (хотя настройки остаются — домашняя страница, история, прокси)

Пароли к почте слетают (хотя настройки остаются — адреса почты, POP3-SMTP сервера, имя пользователя)

Адресную книгу надо также переименовывать или импортировать, если имя отличается

Слетают все пароли к посещавшимся сайтам, запомненные браузером.

Вот еще вариант для пробы найденный на форуме:

1) Зайти на комп под учеткой из рабочей группы

2) Зайти под админом, дать все права на папку со старым доменным профилем новому пользователю из рабочей группы

3) Загрузить в regedit под любым именем файл NTUSER.DAT, расположенный в старом профиле и добавить разрешения на эту (загруженную) ветку реестра для нового пользователя из рабочей группы.

Смысл этого пункта в том, чтобы дать разрешение новому пользователю из рабочей группы на использование ветки реестра HKEY_CURRENT_USER, доставшейся в наследство от старого (в данном случае доменного) пользователя. Соответственно эта ветка (куст) реестра хранится в профиле в файле NTUSER.DAT. А дать на неё права можно с помощью regedit, предварительно загрузив этот файл, для этого в regedit ставим курсор на HKEY_USERS, далее «Файл»->»Загрузить куст»->Выбираем NTUSER.DAT из профиля старого пользователя->Имя раздела присваеваем для примера «1» (без разницы), хотя лучше для этого взять SID старого пользователя. Далее для загруженного куста добавляем права для полного доступа для нового пользователя.

4) В реестре перейти в раздел HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionProfileList, найти раздел, в котором параметр ProfileImagePath имеет значение, ссылающееся на путь к профилю нового пользователя из рабочей группы и заменить его на путь к профилю старого (доменного) пользователя.

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

Там же советуют, попробовать перенести при помощи программы transwiz либо profwiz. Обе живут по адресу http://www.forensit.com/

Восстановление пути к профилю пользователя на рабочей станции Windows

Если пользователь вошёл в систему на рабочей станции с операционной системой Windows после выполнения работ по включению рабочей станции в домен Active Directory и его рабочий стол, папка с документами и настройки пропали, то это значит, что вместо старого профиля пользователя создался новый. Ведь даже если пользователь локальный и доменный имеют одинаковые имена, это совершенно разные пользователи и поэтому система справедливо создаёт для доменного пользователя новый профиль. Восстановить настройки рабочего стола пользователя и документы можно, указав путь к старому профилю в системном реестре.

Порядок действий для восстановления настроек рабочего стола пользователя Windows:

Войти в систему под другим пользователем, который имеет права администратора на компьютер, например, под «Администратор» компьютера

Исправить список доступа во вкладке безопасность папки профиля — добавить доменного пользователя в список с правами на полный доступ. Папки с профилями пользователей обычно находятся в C:Documents And Settings_ имя_пользователя_

Запустить редактор реестра (regedit). В ветке HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionProfileList находится список профилей пользователей компьютера. Ветки ключей, описывающие профили именуются по SID пользователей. Нужно просмотреть каждую из этих веток и найти по имени каталога старый профиль и новый (доменный), затем в ветке для нового профиля указать старый путь. Параметр реестра в котором содержится путь к профилю пользователя ProfileImagePath.

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

Вот еще немного по теме (грабли) :

1. дай созданной учётке права админа
2. зайди под ней и проверь работоспособность профиля — запуск программ, расположение ярлыков, если всё ОК, значит дело всё-таки в правах на hkey_current_user
3. открой REGEDIT.EXE
4. на ветке HKEY_CURRENT_USER правый клик мышой->пункт меню «разрешения»
5. в появившемся списке ты скорее всего увидишь неизвестную учётную запись (S-1-…..), имеющую полные права на эту ветку, так вот, тебе нужно её заменить на созданную тобой учётку, после чего права админа можно забирать

менять разрешения нужно для всех элементов ветки, т.е. ставить галочку «заменить разрешения….»

голоса
Рейтинг статьи
Ссылка на основную публикацию
Adblock
detector