Windows server 2003 перенос пользователей

Обновлено: 02.07.2024

Novell Netware одна из наиболее стабильных и надежных сетевых операционных систем, но имеет один неприятный недостаток - она разработана не в Microsoft, что влечет за собой стремительное сокращение оной на рынке серверных ОС. На сегодняшний день Novell не планирует развитие данной ОС, а стремительно (в 2008 году продано более 400 000 лицензий) выводит на рынок свои Linux дистрибутивы SLES и OES, что заставляет по крайней мере задуматься над миграцией на более перспективные современные ОС.

В этой статье я расскажу о переносе учетных записей пользователей с Novell Netware 6.5, на Windows 2003 Server путем импорта данных при помощи ODBC Driver for eDirectory и экспорта их при помощи пакетного файла Windows.

Пример не практический, но на основе его можно разработать перенос практически любой информации из базы Novel eDirectory в службу каталогов Active Directory.

Сервер с установленным Windows 2003 Server с развернутым контроллером домена.
Сервер с установленным Novell Netware 6.5 с заведенными пользователями и группами.
Рабочая станция (OS Windows) с установленным клиентом Novell Netware, PHP5 и ODBC Driver for eDirectory.

ODBC Driver for eDirectory универсальный программный интерфейс, для доступа к базе Novell eDirectory, позволяющий обращаться к ней различным программным средствам (например MS Access, MS Excel, Vba и многим другим) с использованием SQL синтаксиса, незная внутреннего устройства eDirectory. ODBC позволяет значительно снизить время разработки ПО, но в то же время не расчитан на большое число подключений клиентов.

Для того чтобы установить ODBC Driver надо либо скачать его с сайта Novel, либо если у вас установлена ConsoleOne в папке *\consoleone\1.2\reporting\bin\odbc.exe. После установки необходимо настроить источник данных, для чего запустить Администратор источников данных ODBC . - odbcad32.exe. Далее перейти на вкладку Системный DSN и нажать кнопку Добавить, в следующем списке выбрать Novell ODBC Driver for NDS.

NDS - так называлось то что впоследствии переросло в eDirectory.

Далее ввести имя источников данных и обозначить дерево, имя не важно какое, но мы введем Novell.

Жмем два раза ок.

Имя домена первого и второго уровня

На следующих двух ф-ях заострять внимание пока не следует.

Вспомогательная функция для вывода на консоль в ДОС кодировке:

Функция для записи аварийных ситуаций

Подключаемся к базе данных.

Обращаю внимание что в ф-ии odbc_connect() не обязательно вводить логин и пароль, если вы залогинены под админом, а это лучше сделать.

Тепрерь мы можем сформировать и выполнить запрос к базе eDirectory используя SQL синтаксис

Здесь мы выполняем запрос к таблице UserNDS на выборку имени пользователя в eDirectory, имени, фамилии, дерева, полного имени, группам в которых состоит пользователь, Id пользователя и емейла.

Естественно данная выборка приведена исключительно для примера, на практике можно вытянуть все что угодно, кроме пароля - пароль хеширован.

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

В итоге имеем два массива данных, достаточных для выполнения нашей задачи.

Следующий код будет формировать bat файл, в котором используеться консольная утилита DSADD выполняющая добавление новых объектов в домен AD.

Почему именно бат файл? Почему не внести данные в базу AD прямо из скрипта?

Документация по переносу и соответствующие средства упрощают процесс переноса ролей сервера, параметров операционных систем и данных с существующего сервера под управлением Windows Server® 2003, Windows Server 2008 или Windows Server 2008 R2 на компьютер с Windows Server 2008 R2.

Используя руководства по переносу, ссылки на которых представлены в данном разделе, и Средства миграции Windows Server для переноса ролей, можно упростить процесс развертывания новых серверов (включая работающие под управлением варианта установки Server Core Windows Server 2008 R2 и виртуальные серверы), сократить время простоя, повысить точность процесса переноса и исключить конфликты, которые могут возникнуть в его ходе.

Руководства по переносу Windows Server 2008 R2

Средства переноса Windows Server

Средства миграции Windows Server - компонент, доступный для установки на компьютерах под управлением Windows Server 2008 R2 с помощью мастера добавления компонентов Диспетчер серверов. Средства миграции Windows Server можно удалить с Windows Server 2008 R2 с помощью мастера удаления компонентов.

Для переноса ролей, компонентов и других данных с помощью Средства миграции Windows Server на исходных серверах, с которых требуется мигрировать данные, следует развернуть Средства миграции Windows Server. Для развертывания Средства миграции Windows Server на исходных серверах создается папка развертывания на компьютере под управлением Windows Server 2008 R2, затем эта папка копируется в ОС исходного компьютера Windows Server 2008 R2, представленные в таблице в данном разделе.

Пользователь должен быть членом группы Администраторы на компьютере, на котором нужно установить , зарегистрировать или использовать Средства миграции Windows Server. Кроме того, если Средства миграции Windows Server выполняется на серверах под управлением Windows Server 2008 или Windows Server 2008 R2, Средства миграции Windows Server должен выполняться с повышенными правами пользователя. Для этого нажмите кнопку Пуск, выберите Администрирование, правой кнопкой мыши щелкните Средства переноса Windows Server, а затем в контекстном меню выберите пункт Запуск от имени администратора.

Поддерживаемые операционные системы

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

Выполняя миграцию леса из Server 2003 в Server 2012 R2, можно вручную удалить учетную запись каждого компьютера из исходного леса, а затем вручную присоединить его к целевому лесу. Конечно, это довольно неудобно, если требуется перенести несколько тысяч учетных записей компьютеров из одного леса в другой.

На такой случай предусмотрено специальное средство миграции Active Directory (ADMT), располагающее функциями, которые позволяют перенести учетные записи компьютера из одного домена в другой. Вы можете задействовать мастер миграции учетных записей компьютера, вызвать ADMT из командной строки или подготовить сценарий для автоматической миграции.

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

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

Политики миграции и изоляции доменов в Server 2003

Переход от Server 2003 к Server 2012 R2 — подходящая возможность повысить безопасность с помощью политик изоляции доменов. Переход от Server 2003 позволяет многим компаниям изменить способы взаимодействия клиентов с серверами. Одно из возможных изменений — внедрение политик изоляции доменов. Основная идея заключается в настройке политики сетевого экрана таким образом, чтобы серверы в компании обменивались данными только с клиентами, прошедшими проверку подлинности с использованием выбранного метода. Этот метод может подтверждать членство в домене, подлинность сертификата или даже, хотя это менее безопасно, общий секретный пароль.

Идея безопасности домена основана на понимании, что локальные сети начала 21 века сильно отличаются от локальных сетей конца 20 века. К сожалению, безопасностью локальных сетей занимаются в основном люди, осваивавшие технологию в конце прошлого века, и многим из них не удалось перестроиться на новое мышление.

Например, в 1990-х можно было быть вполне уверенным, что к внутренней сети компании подключены только проверенные компьютеры. Большинство сотрудников не располагали портативными компьютерами, и не в каждой сети использовался протокол DHCP. А для подключения компьютера к сети (многие из которых были сетями стандарта 10Base2 на основе коаксиального кабеля) требовался сетевой адаптер. Сегодня сетевые адаптеры окружают нас повсюду, но в середине 1990-х для большинства пользователей они не были частью повседневной жизни. Внутренние сети состояли из компьютеров, подключенных ИТ-специалистами, которые также в основном устанавливали сетевые адаптеры, загружали драйверы и физически подключали сетевые адаптеры к проводной сети.

Во время, когда был выпущен Windows Server 2003, соединительные кабели ценой в 2 доллара нечасто удавалось видеть на полках канцелярских магазинов. В 2003 году компьютеры в сети компании в основном также устанавливались ИТ-специалистами. Очень немногие сотрудники пытались подключать свои персональные компьютеры к сети компании.

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

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

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

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

Политики изоляции доменов не сделают серверы неуязвимыми при переходе от Server 2003 к Server 2012 R2, и следует принимать во внимание все возможные способы повышения уровня безопасности.

Совершенствуем настройку сетевого экрана Windows

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

Надо сказать, что сетевой экран, поставляемый вместе с Windows Server 2003, имеет неважную репутацию. Именно поэтому некоторые администраторы приобрели привычку отключать сетевой экран вместо того, чтобы работать с ним. Оправданием такого подхода отчасти может служить то, что серверы все равно находятся в защищенной внутренней сети, поэтому сетевой экран как таковой не нужен.

Как отмечалось выше, локальные сети внутри компании 12-летней давности сильно отличаются от внутренних сетей современных компаний. 12 лет назад портативные компьютеры были редкостью. А сейчас они как кошки: только отвернешься, невозможно предсказать, куда они отправятся и чем займутся. И что притащат, когда вернутся в дом (в защищенную внутреннюю сеть).

Поэтому, переходя с Windows Server 2003 на Windows Server 2012 R2, ни в коем случае не отключайте сетевой экран Windows. Настраивая его, можно воспользоваться групповой политикой, чтобы обеспечить единый набор базовых правил на всех серверах, а затем назначить отдельным серверам особые правила. Включите и используйте журналы сетевого экрана, чтобы понять, какие правила нужно создать, вместо того чтобы просто отключать сетевой экран, когда он доставляет неудобства.

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

Оцениваем инфраструктуру WSUS

В большинстве сетей, в которых развернут Windows Server 2003, имеется пара серверов WSUS. Перед переходом на Server 2012 R2 следует оценить инфраструктуру WSUS и выбрать способ переноса служб WSUS для их размещения на новой операционной системе.

Напомню, что WSUS — это службы обновления Windows Server. Они предназначены для размещения локального репозитария программных обновлений. С их помощью локальные администраторы контролируют, какие обновления применяются к клиентам WSUS, не полагаясь на стандартные подтверждения при выпуске обновлений компанией Microsoft. Большинство компаний используют службы WSUS, чтобы иметь возможность одобрять обновления в удобное время.

Оценивая инфраструктуру WSUS компании, необходимо проверить следующие характеристики:

Где хранятся обновления. Некоторые серверы WSUS настроены таким образом, что выполняют лишь одобрение, а клиенты извлекают обновления из серверов Microsoft Update.
Интеграция с другими продуктами. И диспетчер параметров настроек, и диспетчер виртуальных машин могут быть интегрированы с WSUS.
Какая используется схема настройки — восходящая или нисходящая. В некоторых компаниях одобрения и обновления на сайтах филиалов извлекаются из центрального сервера WSUS.

Следует также попытаться выяснить, сколько серверов WSUS требуется компании. Главная особенность WSUS, которую необходимо учитывать: при включенной службе BITS каждый сервер WSUS может теоретически обслуживать до 25 000 клиентов.

Далее речь пойдет о том, как выполнить миграцию WSUS-сервера.

Перенос WSUS из Server 2003 в Server 2012 R2

Вы можете перенести экземпляр WSUS, размещенный на Windows Server 2003, на сервер Windows Server 2012 R2. Для этого достаточно выполнить определенную последовательность шагов.

Первый шаг — убедиться, что экземпляр Windows Server 2003 WSUS обновлен до уровня WSUS 3.0 SP2.

Можно выполнить миграцию, если сервер WSUS использует базу данных Windows Internal, или если сервер WSUS задействует SQL Server. Можно выполнить миграцию из исходного сервера, использующего базу данных Windows Internal, на сервер назначения, который использует базу данных Windows Internal или SQL Server, но нельзя перейти от сервера WSUS с базой данных SQL Server к целевому серверу WSUS, в котором применяется база данных Windows Internal.

При выполнении миграции для TCP-порта 7000 используются команды Send-SmigServerData и Receive-SmigServerData. Это означает, что необходимо обеспечить связь через этот порт между исходным и целевым серверами.

После того, как TCP-порт 7000 будет открыт, нужно выполнить следующие шаги:

Active Directory - от теории к практике. Часть 4 - перенос учетных записей в домен.

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

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

А сколько таких учетных записей? Явно не одна и не две, а если принять во внимание, что все равно что нибудь забудете или упустите из виду, то становится понятно, что процесс перевода инфраструктуры от обычной сети к службе каталогов способен превратиться в настоящий ад, как для администратора, так и для сотрудников. Что же делать? Не спешить и, для начала, внимательно прочитать нашу статью.

К сожалению не одни только ученые записи способны вызвать затруднения при переходе на Active Directory, поэтому самое время вспомнить о том, что такое SID. SID компьютера - это уникальный идентификатор безопасности, который генерируется при установке системы и используется в качестве основы при создании прочих идентификаторов (для пользователей, групп и т.п.). Хотя в настоящее время многие специалисты считают проблему дублирующегося SID преувеличенной, например см. статью М. Руссиновича "Миф о дублировании SID компьютера", мы не рекомендуем рисковать и включать в домен машины с одинаковыми SID.

Когда может возникнуть такая ситуация? При клонировании уже установленной системы на несколько ПК, например столь любимыми многими утилитами Norton Ghost или Acronis. Появление в сети подобным машин может привести к неправильному применению групповых политик и некорректной работе некоторых сетевых служб, например WSUS. Мы не будем однозначно утверждать, что данные проблемы возникают именно от дублирующегося SID, но лучше предупредить возможные проблемы, чем потом заниматься их решением. Поэтому лучше позаботиться об уникальности SID до включения машин в домен и появления возможных проблем.

Для обеспечения уникальности SID следует использовать утилиту sysprep, о использовании которой мы рассказывали в данной статье, в Windows 7 данная утилита входит в состав системы и расположена в C:\Windows\System32\sysprep.

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

Итак, у нас есть некая рабочая станция за которой работает сотрудник Иванов и которую нужно ввести в домен. В первую очередь убедитесь что ПК имеет желаемое имя и при необходимости переименуйте компьютер, не забудьте перезагрузиться. Следующим шагом необходимо правильно настроить сеть, так как в нашей сети развернут DHCP-сервер достаточно установить автоматическое получение сетевых параметров и убедиться в получении правильных значений.

Для серверов, которые должны иметь статические сетевые параметры укажите необходимые значения вручную, особое внимание следует уделить DNS-серверам, это должны быть адреса двух любых контроллеров домена (которые совмещают роль DNS-сервера), в противном случае у вас не получится ввести такой компьютер в домен.

Если вам нужно чтобы какая-либо рабочая станция имела статический адрес, то не стоит указывать его вручную, более правильно будет использовать такую функцию DHCP-сервера как резервирование. Это позволит вам в последующем менять настройки сети без необходимости вносить изменения на каждой рабочей станции (например поменять адрес шлюза). Для резервирования откройте оснастку управления DHCP-сервером, перейдите в папку Арендованные адреса и щелкнув на нужном хосте правой кнопкой мыши выберите Добавить к резервированию. Этим вы закрепите выделенный адрес за данным компьютером на постоянной основе.

Теперь самое время включить наш компьютер в домен. Для этого перейдите в Свойства системы - Имя компьютера и нажмите кнопку Изменить. В открывшемся окне выберите Является членом домена и укажите имя домена в который мы хотим войти, затем нажмите OK, затем укажите имя и пароль пользователя имеющего право на включение компьютера в домен (по умолчанию администратор домена).

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

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

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

Поэтому самое время заняться переносом профиля локальной учетной записи в доменную. Для этого следует воспользоваться инструментом User State Migration Tool, который входит в состав Пакета автоматической установки Windows (AIK), скачать его можно здесь.

Данный пакет нет необходимости устанавливать на всех ПК, вполне достаточно будет установки на компьютер администратора или один из серверов. Искомый набор утилит находится в папке C:\Program Files\Windows AIK\Tools\USMT нам нужно будет скопировать их на целевую систему или сделать доступными по сети.

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

Внимание! Вы можете перенести профиль из 32-х разрядной системы в 64-х разрядную, однако обратный перенос из 64-х разрядной в 32-х разрядную не поддерживается!

Для создания файла переноса используется утилита ScanState с синтаксисом которой можно ознакомиться здесь. В нашем случае мы будем переносить локальный профиль пользователя WWW в профиль доменного пользователя ivanov. Для создания файла переноса войдите в систему под учетной записью администратора домена, перейдите в папку с нужной версией USMT (32 или 64 бит) и выполните следующую команду:

Синтаксис команды на первый взгляд довольно сложен, но это не так. Первый аргумент указывает расположение файла переноса, ключ /i: указывает какие правила переноса следует использовать, ключ /v: задает необходимый уровень детализации лога, сочетание ключей /ue: и /ui: исключает из переноса всех пользователей кроме WWW, а ключ /l: определяет расположение лога.

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

Итак, файл переноса создан, но не спешите переходить ко второму этапу. Если вы уже входили в систему под целевым пользователем, то необходимо удалить или переименовать папку с профилем в каталоге C:\Users и удалить соответствующий профилю раздел в ветке реестра:

В противном случае при попытке восстановления профиля вы получите ошибку с кодом 71: LoadState return code: 71.

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

Структура команды во многом похожа на предыдущую, одноименные ключи имеют аналогичное значение, ключ /mu: указывает исходный профиль и профиль назначения, доменные учетные записи указываются как Domain\User. В нашем случае профиль локального пользователя WWW будет восстановлен в профиль пользователя interface31.lab\ivanov.

Теперь, выполнив вход под доменной учетной записью пользователь Иванов обнаружит привычное рабочее окружение, как видно на скриншоте ниже, перенеслось даже содержимое корзины.

Данный метод можно использовать для операционных систем Windows Vista/7, для переноса профилей в среде Windows XP также можно использовать USMT несколько изменив синтаксис команд, но лучше воспользоваться утилитой moveuser, которая входит в состав Windows Server 2003 Resource Kit Tools (скачать). Точно также, как и в предыдущем случае, нет необходимости устанавливать пакет на каждую машину, достаточно скопировать утилиту moveuser которая находится в папке C:\Program Files\Windows Resource Kits\Tools.

Для переноса профиля также войдите на целевой ПК как администратор домена и выполните команду:

Синтаксис данной утилиты гораздо проще и его можно изучить запустив ее без аргументов. Ключ /y разрешает перезаписать профиль назначения если он существует, т.е. вы можете предварительно выполнить вход доменным пользователем на эту машину, это никак не помешает переносу, после переноса вход под локальным пользователем будет невозможен, если вы хотите продолжать использовать локальный профиль укажите дополнительно ключ /k.

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

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

Читайте также: