Проблемы с учетными записями после миграции

Micrus · Отправлено: **13:22, 22-03-2007** | #11

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

sfap · Отправлено: **14:11, 22-03-2007** | #12

С пользователями, входящими в какие-либо группы, кроме пользователи домена ситуация так и не разрешилась. Может быть нужно еще какие-то объекты мигрировать?

sfap · Отправлено: **14:29, 22-03-2007** | #13

А что есть глобальная группа? При создании групп- я видел, что можно выбрать локальная она, или глобальная..... И еще вопрос есть. Что нужно кроме этих вещей мигрировать? Мне не хотелось бы переносить групповую политику со старого сервера, так как она там совсем не настроена. И еще мне не понятно: нужно ли переносить стандартные группы BUILTIN, или только те, что руками создавал- и этого будет достаточно для работы.

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

Так же в описании написано, что в исходном домене должна быть группа {SourceNetBIOSDom}$$$. А с ней нужно что-нибудь делать? Я ее завел, но ее миграцию не проводил......

sfap · Отправлено: **16:24, 22-03-2007** | #14

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

Micrus · Отправлено: **17:15, 22-03-2007** | #15

Цитата:

А что есть глобальная группа?

Читаем статьи по AD на данном сайте

1. Настаиваешь доверительные отношения между доменами
2. отключаешь SID filtering с помощью утилиты netdom (http://www.microsoft.com/technet/pro....mspx?mfr=true)
3.

Цитата:

группа {SourceNetBIOSDom}$$$.

http://support.microsoft.com/kb/322970/en-us

так же читаем хелп по ADMT, там все что нужно документированно

4. переносятся сервисные учетные записи
http://technet2.microsoft.com/Window....mspx?mfr=true

5. переносятся глобальные группы

6. переносятся пользователи/или компы

sfap · Отправлено: **18:33, 22-03-2007** | #16

Я, тут уже чудес натворил: Убил всех юзеров в новом домене (все- равно они не правильно перенеслись). Случайно кильнул юзера, который был перенесен успешно. Начал его заново переносить, а после миграции у него уже другой SID и опять ерунда получилась. Я не понимаю: как такое может быть? Хочет- переносит SID, а хочет- выдает новый........

А ссылки, приведенные выше- несомненно вещь-полезная, но с них я и начинал. И, я думаю, что, если бы я неправильно настроил доверительные отношения, то ни один пользователь бы вообще не смог мигрировать, а у меня некоторые очень даже удачно мигрировали... Может такие глюки из-за того, что я много раз переустанавливал Migration tools, пробуя различные версии? Положение усугубляется тем, что несколько человек уже работают в новом домене, и сейчас- даже откат системы делать как-то не хочется....

sfap · Отправлено: **19:25, 22-03-2007** | #17

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

Micrus · Отправлено: **07:15, 23-03-2007** | #18

Цитата:

Хочет- переносит SID, а хочет- выдает новый.......

В том то и дела что при миграции, всегда будет новый SID, старые будут сохранятся в атрибуте user-a SID-History

Кстати , когда переносишь глобальную группу выставляй галочки Update user rights, Fix membeship of group, Migrate group SIDs to target domain
Для пользователя ставишь галочки Migrate user SIDs to target domain

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

Цитата:

группа {SourceNetBIOSDom}$$$

должна быть просто Domain Local Security
Пользователь под которым производишь миграцию должен быть Domain Admin в целевом домене , а группа Domain Admins из целевого домена, должна быть в группе Builtin\Administrators исходного домена

sfap · Отправлено: **09:49, 23-03-2007** | #19

Пользователь под которым производишь миграцию должен быть Domain Admin в целевом домене , а группа Domain Admins из целевого домена, должна быть в группе Builtin\Administrators исходного домена

А я провожу миграцию от имени админа исходного домена- хотя в целевом он тоже является админом......... Попробую таким образом.....

sfap · Отправлено: **10:31, 23-03-2007** | #20

Цитата:

В том то и дела что при миграции, всегда будет новый SID, старые будут сохранятся в атрибуте user-a SID-History

Не понял я этой фразы. Я думал, что суть миграции как-раз в сохранении SID, ведь там даже есть опция мигрировать SID в новый домен. К стати, как можно почистить SID History, а то я некоторых пользователей уже мигрировал раз по 20, так и ничего не получилось.........?