Наша компания (небольшая веб-фирма) скоро перейдет из среды рабочей группы в среду на основе домена (Windows Server 2008). Некоторые из членов нашей команды (в том числе и я) работают в основном с наших ноутбуков, и у них установлено много личных вещей (приложений, документов).
В настоящее время это не проблема, поскольку мы можем использовать одну локальную учетную запись для входа в систему. Чего я бы хотел по возможности избежать, так это переустановки и перенастройки 90% настроек и, возможно, даже установки одного и того же приложения дважды в одной и той же системе просто потому, что оно не было установлено для вновь созданного пользователя домена.
У нас пока не было большого опыта работы с доменами, и мне довольно сложно дать простую, но подробную информацию и ответы.
Как лучше всего выполнить эту миграцию?
Существует уже вопрос в отношении миграции рабочей группы в домен, но на самом деле он не содержит подробных сведений о фактических конфигурациях рабочих станций и о вещах, которые следует учитывать с точки зрения конечного пользователя.
Любой совет будет принят во внимание.
Присоединение вашего клиентского компьютера (ов) к домену не лишит вас возможности продолжить вход в систему как локальную учетную запись пользователя, которую вы уже используете. Групповая политика начнет применяться к компьютеру, как только он присоединится к домену, но в стандартной версии Windows Server 2008 Active Directory на самом деле не будут применяться какие-либо параметры групповой политики, поэтому для всех намерений и целей будет отображаться клиентский компьютер. не зависит от присоединения к домену.
Что касается ваших опасений относительно приложений и настроек: профиль существующей локальной учетной записи пользователя можно перенести в профиль учетной записи пользователя домена, и при этом будет сохранено большинство настроек. Однако особенно оскорбительным является то, что приложения хранят пути, ссылающиеся на «C: \ Documents and Settings ...» (или «C: \ Users ...», если вы находитесь в мире Windows Vista / 7) в реестр. В этом случае, если вы хотите, чтобы эти пути продолжали «работать», вы должны выполнить миграцию профиля таким образом, чтобы учетная запись домена в конечном итоге использовала тот же каталог на локальном жестком диске для хранения профиля, что и локальная учетная запись, которая в конечном итоге означает перемещение или удаление локального профиля пользователя.
Лично на вашем месте я бы присоединил клиентский компьютер к домену, один раз зашел в систему под своей учетной записью домена, перезагрузился (чтобы убедиться, что нет открытых дескрипторов ни в каких реестрах пользователей, оставшихся открытыми), войти в систему как «Администратор "(при условии, что локальная учетная запись, которую вы использовали, не является« Администратором »), и используйте функцию« Копировать в »в диалоговом окне« Настройки профилей пользователей », доступном через вкладку« Дополнительно »в« Свойства »раздела« Мой компьютер ", чтобы скопировать профиль локальной учетной записи пользователя поверх профиля учетной записи домена. Укажите учетную запись домена в разделе «Разрешено использовать» диалогового окна «Копировать в».
Я бы вошел в систему как учетная запись домена (которая тогда должна иметь внешний вид вашей старой локальной учетной записи) и использовать REGEDIT для сканирования через HKEY_CURRENT_USER в поисках ссылок на "C: \ Documents and Settings \ old-local- user ... "и измените их, чтобы они указывали на расположение профиля новой учетной записи домена. Это утомительно, но у вас, вероятно, будут какие-то дурацкие приложения, которые сохраняют абсолютные пути к местоположениям профилей. (Спасибо, глупые разработчики приложений ...)
Преимущество этого метода в том, что он сохраняет локальную учетную запись пользователя. Вы все равно можете войти в систему как локальный пользователь, если обнаружите, что что-то не работает с учетной записью пользователя домена.
Плохо в этом методе то, что он сохраняет локальную учетную запись пользователя. Вы по-прежнему можете входить в систему как локальный пользователь и при этом вносить изменения в локально хранимые документы и т. Д., И в конечном итоге запутаться в том, что к чему, и уничтожить данные.
Как только учетная запись пользователя домена заработает так, как вам нужно, я удалю локальную учетную запись пользователя и ее профиль. Если вы параноик, сделайте резервную копию каталога профиля и просто отключите локальную учетную запись пользователя. Лично я бы попытался сделать полный перерыв, чтобы вы не выбросили навсегда этот старый каталог профилей пользователей.
Наконец, если у вас нет доступа к кому-то с хорошими знаниями Active Directory для разработки вашей Active Directory, использования групповой политики для развертывания программного обеспечения / централизованного управления развертыванием обновлений / централизованного хранения файлов данных пользователей / использования профилей пользователей для создания ромов и т. Д. Я рекомендую вам найти кого-нибудь, кто сможет потратить пару часов на помощь. Вы можете получить множество действительно полезных функций из Active Directory, и некоторые очень простые параметры групповой политики могут использоваться для централизованного хранения и резервного копирования пользовательских данных, централизованного развертывания и управления обновлениями приложений Windows и Microsoft и т. Д. Это хорошо прочее, и может сэкономить много времени и избавить вас от головной боли в будущем.
Удачи!