Комментарии 25
Спасибо, более грамотно чем у меня :)
И да, здесь хоть как-то рассказано что можно переносить пароли пользователей, с этим у меня были проблемы, пришлось всем один делать (хотя можно было разные и разослать его на корпоративную почту).
И да, здесь хоть как-то рассказано что можно переносить пароли пользователей, с этим у меня были проблемы, пришлось всем один делать (хотя можно было разные и разослать его на корпоративную почту).
При нашем количестве пользователей так просто не получилось бы. Да и «не комильфо», когда пароль пользователя знает кто-нибудь кроме пользователя (пусть даже и на короткое время, пусть даже и администратор).
А можно для тех, кто не очень в теме пояснить, откуда вообще взялась такая задача и что дает такой переход? Обычно все вроде как раз наоборот мигрируют — в первую очередь с целью сэкономить на лицензии Windows-сервера.
Откуда взялась задача, я вроде подробно описал в разделе «Почему отказались от Samba». Просто надо было переделывать либо на Samba, либо на что-то другое. Причём трудозатраты были соизмеримые.
Что дал такой переход: заработали в штатном режиме инструменты, которые нужны бизнесу.
Иногда в жизни компаний наступает момент, когда они перестают экономить на мелочах, отдавая себе отчёт, что потраченные средства вернутся прибылью. К сожалению бизнесу нужны всё больше продукты от MS, либо те, которые с ними тесно интегрируются.
Что дал такой переход: заработали в штатном режиме инструменты, которые нужны бизнесу.
Обычно все вроде как раз наоборот мигрируют — в первую очередь с целью сэкономить на лицензии Windows-сервера.
Иногда в жизни компаний наступает момент, когда они перестают экономить на мелочах, отдавая себе отчёт, что потраченные средства вернутся прибылью. К сожалению бизнесу нужны всё больше продукты от MS, либо те, которые с ними тесно интегрируются.
Почему к сожалению? :)
Ну, я ровно к тому, что обозначенная в «Почему отказались от Samba» позиция ограничивается словами про «имела некоторые просчёты, которые проявили себя при масштабировании домена». Я догадываюсь, что тема rationale на самом деле соизмерима с объемом (если не больше) данной статьи и вы прямо сейчас не очень хотите писать такой текст — но может быть как-то в будущем — интересно было бы узнать об этих «просчётах», например, чтобы не допускать их впредь. Ну и о каких-то плюсах-минусах, что дает вообще AD по сравнению с Samba — какие именно инструменты заработали в штатном режиме и т.д.
Постараюсь объяснить в двух словах на пальцах как это было реализовано (хотя я искренне надеюсь, что вы никогда не столкнётесь с такой архитектурой):
В центральной точке был LDAP сервер, и работающая с ним Samba, которая считала себя PDC сервером.
На удалённых площадках тоже были LDAP сервера, и с ними тоже работали экземпляры Samba, и каждый из них считал себя PDC.
Пулы RID назначались администратором на каждую новую площадку (Администратор выполнял роль RID Master ;) )
«Дерево» LDAP в центре было не монолитно — оно было «склеено» из баз-бэкендов. Сделано это было для того, чтобы на удалённую площадку можно было реплицировать только данные о пользователях с этой площадки + набор пользователей с «доступом везде». В центральную точку реплицировалось всё.
Схема прекрасно работала… до набора «критической массы» — потом начались проблемы с LDAP сервером, которому при каждом запросе приходилось «склеивать» данные из большого количества баз. Собственно в этом и был просчёт.
P.S. Помидорами не кидать — схему придумал не я.
P.P.S. Я прекрасно знаю, что можно было применить расширенный фильтр (для фильтрации по dn — есть в том же OpenLDAP) в параметрах репликации и реализовать ту же схему но без «склейки» баз. Получилось бы даже более гибко. Но переделка была соизмерима с описанной миграцией, а на выходе был бы всё тот же NT4 домен.
В центральной точке был LDAP сервер, и работающая с ним Samba, которая считала себя PDC сервером.
На удалённых площадках тоже были LDAP сервера, и с ними тоже работали экземпляры Samba, и каждый из них считал себя PDC.
Пулы RID назначались администратором на каждую новую площадку (Администратор выполнял роль RID Master ;) )
«Дерево» LDAP в центре было не монолитно — оно было «склеено» из баз-бэкендов. Сделано это было для того, чтобы на удалённую площадку можно было реплицировать только данные о пользователях с этой площадки + набор пользователей с «доступом везде». В центральную точку реплицировалось всё.
Схема прекрасно работала… до набора «критической массы» — потом начались проблемы с LDAP сервером, которому при каждом запросе приходилось «склеивать» данные из большого количества баз. Собственно в этом и был просчёт.
P.S. Помидорами не кидать — схему придумал не я.
P.P.S. Я прекрасно знаю, что можно было применить расширенный фильтр (для фильтрации по dn — есть в том же OpenLDAP) в параметрах репликации и реализовать ту же схему но без «склейки» баз. Получилось бы даже более гибко. Но переделка была соизмерима с описанной миграцией, а на выходе был бы всё тот же NT4 домен.
По поводу «JoinDomainOrWorkgroup» на офсайте написано
Remarks
When moving a computer from a domain to a workgroup, you must remove the computer from the domain before calling this method to join a workgroup. After calling this method, restart the affected computer to apply the changes.
Да и вообще ОС не позволяет сменить домен без перезагрузки. Или у Вас есть другие данные?
Remarks
When moving a computer from a domain to a workgroup, you must remove the computer from the domain before calling this method to join a workgroup. After calling this method, restart the affected computer to apply the changes.
Да и вообще ОС не позволяет сменить домен без перезагрузки. Или у Вас есть другие данные?
Всё правильно — не позволяет.
Просто начиная с XP/2003 можно сменить домен AAAAA на домен BBBBB с одной перезагрузкой.
На VBScript примерно так:
На 2000-х придётся:
Просто начиная с XP/2003 можно сменить домен AAAAA на домен BBBBB с одной перезагрузкой.
На VBScript примерно так:
Const DOMAIN_JOIN_IF_JOINED = 32
Const NETSETUP_ACCT_DELETE = 2
Set objNetwork = CreateObject("WScript.Network")
strComputer = objNetwork.ComputerName
Set objComputer = GetObject("winmgmts:{impersonationLevel=Impersonate}!\\" & strComputer & "\root\cimv2:Win32_computerSystem.Name='" & strComputer & "'")
intReturn = objComputer.JoinDomainOrWorkgroup(<имя нового домена>, <пароль учётки в правом введения ПК в новый домен>, <учётная запись нового домена с правом введения ПК в домен>, <organizationalUnit для размещения объекта ПК в новом домене> , JOIN_DOMAIN + DOMAIN_JOIN_IF_JOINED)
Set objWhs = WScript.CreateObject("WScript.Shell")
objWhs.Run "shutdown /r /t:15"
На 2000-х придётся:
- сначала выводить в рабочую группу
- перезагружаться
- авторизоваться локально с какой-то учётной записью
- вводить в новый домен
- опять перезагружаться
Во-вторых надо достать newsid. На официальном сайте её удалили, но, как говорится, что попало в интернет…
А вот это разве не она?
Какой у вас все-таки объем парка машин? Серверов и рабочих мест, чтобы можно было оценить.
Паша, ты молодец!
Правильно что взялся это всё описать — это будет как полезно, так и плюс в твою карму работника. Если хочешь, не против могу твой цикл статей разбавить описанием как мы готовили образ для автоматической установки сотен домен контроллеров. Или не стоит? Черновик валяется давно, но его нужно основательно допиливать для «паблика»
Скоро тебя оторвут с руками :)
Правильно что взялся это всё описать — это будет как полезно, так и плюс в твою карму работника. Если хочешь, не против могу твой цикл статей разбавить описанием как мы готовили образ для автоматической установки сотен домен контроллеров. Или не стоит? Черновик валяется давно, но его нужно основательно допиливать для «паблика»
Скоро тебя оторвут с руками :)
Боюсь что здесь это никому не нужно…
P.S. И не надо мне ничего отрывать. ;)
P.S. И не надо мне ничего отрывать. ;)
Да и фиг с остальными, кто столкнётся с такой задачей хоть будет знать откуда и как копать (ну по крайней мере в каком направлении), даже если это уже и пережёвано, лишним не будет.
Мне вот интересно как это автоматизировать, ведь лень — двигатель прогресса :)
Даёшь множество статей разных и интресных!
Мне вот интересно как это автоматизировать, ведь лень — двигатель прогресса :)
Даёшь множество статей разных и интресных!
Мне вот интересно как это автоматизировать
Всмысле?
В описанном мною плане всё просто автоматизируется ;)
Или Вы про:
как мы готовили образ для автоматической установки сотен домен контроллеров?
Это уже нужно Baf пытать — он готовил образ, я и без этого завален работой был.
на какой версии? в 12м сервере это вроде уже стало попроще с configmgr'ами всякими…
Пишите!
Будем ждать =)
Будем ждать =)
промазал
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Миграция домена с SAMBA 3 на ActiveDirectory (опыт миграции домена без простоя)