Windows 2000 перенос на другое железо

Как перенести Windows 2000 на новый компьютер с минимальными потерями

Я уже рассказывал об использовании утилиты User state Migration Tool (USMT) из комплекта ресурсов Microsoft Windows 2000 Resource Kit, служащей для переноса информации о пользователе (особенно настроек рабочего стола, параметров приложений и набора персональных данных) со старой операционной системы на Windows 2000. Еще одна типичная задача миграции — перенос ранее установленного экземпляра Windows 2000 на новую машину с иными аппаратными устройствами. Процедура повторной инсталляции операционной системы с нуля — не лучший вариант. После того, как была установлена система со всеми приложениями, инструментами, специальными настройками и параметрами, необходимыми для работы, мне хотелось сохранить ее в существующем виде и на другой системе. Но иногда повторной инсталляции не избежать. Типичный случай, требующий переустановки операционной системы, — покупка нового ПК, который должен стать основным настольным компьютером.

Вероятно, не все знают, что в Windows 2000 имеются новые функции, предназначенные специально для переноса настроек установленной системы с одной машины на другую. Данная функциональность реализована в одном из режимов работы утилиты резервного копирования (ntbackup.exe), которую можно найти в меню Start, Programs, Accessories, System Tools. Утилита Backup позволяет объединить сведения об аппаратной конфигурации старой системы с информацией о новой системе, сохранив данные реестра, необходимые для переноса на новый компьютер. Таким образом, существующий экземпляр операционной системы можно перенести на новую аппаратную платформу, просто создав резервную копию системы и восстановив ее на новом ПК, где установлен свежий экземпляр Windows 2000.

Магия слияния реестров

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

Экран 1. Подраздел реестра KeysNotToRestore.

Алгоритм работает следующим образом. Утилита ntbackup.exe начинает процедуру восстановления с обращения к разделу реестра HKEY_LOCAL_MACHINESYSTEMCurrentControl SetControlBackupRestoreKeysNotToRestore (См. Экран 1). Значения этого раздела указывают ntbackup.exe, данные каких подразделов из раздела HKEY_LOCAL_MACHINESYSTEM необходимо сохранить для восстановления системы (раздел HKEY_LOCAL_MACHINESYSTEM содержит информацию о системной конфигурации, в том числе инсталлированных и работающих службах и драйверах). Если подраздел в данном разделе содержит данные, заканчивающиеся обратной наклонной чертой (), то подраздел защищен, и ntbackup.exe не будет восстанавливать значения ниже этого подраздела. Но если данные подраздела заканчиваются обратной наклонной чертой со звездочкой (*), то ntbackup.exe объединяет подразделы исходной и целевой систем. Для этого используется набор заранее определенных правил на основе параметра start. Этот параметр определяет, следует ли запускать соответствующую службу или драйвер, и приоритет запуска (в процессе начальной загрузки, системный, автоматический, ручной или блокирован). Целевой подраздел имеет преимущество, если значение его параметра start меньше, чем в подразделе источника.

Данный метод гарантирует корректный запуск всех необходимых системных служб и устройств целевой системы после восстановления состояния с помощью утилиты ntbackup.exe — даже если аппаратные средства двух компьютеров сильно различаются. Возможные нестыковки между аппаратными устройствами нового компьютера и объединенной системной конфигурацией, как правило, устраняются механизмом Plug and Play при начальной загрузке системы.

Проблемы миграции

Новые возможности впечатляют, но, приступая к копированию Windows 2000 на другие системы, следует помнить о некоторых ограничениях и особенностях утилиты. Во-первых, на исходной и целевой системах должны существовать идентичные папки %systemroot% (например, C:winnt) и тома, содержащие системные компоненты (например, тома Active Directory — NTFS и SYSVOL). В некоторых случаях приходится изменять разделы или даже переустанавливать операционную систему на целевой машине, чтобы получить идентичную конфигурацию и иметь возможность восстановить резервную копию. Если папки %systemroot% на исходной и целевой машинах различны (например, при ликвидации последствий аварии), восстановить исходный экземпляр операционной системы на целевой машине иногда все же можно. Необходимые рекомендации даны в статье Microsoft «Recovering from Failed System Drive with non-Default %systemroot% Folder» по адресу http://support.microsoft.com/support/ kb/articles/q235/4/78.asp).

Во-вторых, обе системы должны иметь одинаковый уровень аппаратной абстракции (HAL). Чтобы выяснить текущий HAL системы Windows 2000, следует запустить приложение System Панели управления; на закладке Hardware нужно щелкнуть на кнопке Device Manager, а затем развернуть контейнер Computer.

В-третьих, если исходная система содержит файлы, использующие точки повторной обработки (reparse points) на томах NTFS, то перед восстановлением этих файлов, вероятно, придется запустить специальные драйверы фильтров. Примеры файлов, использующих точки повторной обработки — файлы образа службы Remote Installation Services (RIS) на базе Single Instance Storage (SIS); файлы Remote Storage Server (RSS), восстанавливаемые на управляемых томах; сторонние служебные файлы, для которых необходимы драйверы фильтров. В этом случае, вероятно, придется перезапустить компьютер после копирования установок операционной системы, а затем восстановить файлы, использующие точки повторной обработки.

В-четвертых, файл setup.log в папке winnt
epair исходного компьютера (содержащей системный реестр) может быть несовместим с аппаратными устройствами на целевом компьютере. Возможно, из-за этого впоследствии не удастся использовать функцию Repair процедуры Windows 2000 Setup для восстановления вновь установленной системы. Чтобы убедиться, что данный файл пригоден для этой задачи, после завершения миграции можно попробовать сразу обновить целевой компьютер.

День миграции

Теперь все готово для переноса системы на новую аппаратную платформу. Для этого необходимо выполнить следующие шаги:

1. На целевом компьютере следует установить новую копию Windows 2000, убедившись, что на целевой и исходной машинах используются версии Windows 2000 одного типа (например, Windows 2000 Professinal, Windows 2000 Server). Символ диска и имя папки %systemroot% на обоих компьютерах должны совпадать.
2. С помощью инструмента Windows 2000 Disk Management следует создать, отформатировать и назначить символьные обозначения всем дополнительным томам, необходимым для хранения системных компонентов (например, SYSVOL, AD и журналов AD). Все символьные обозначения на целевом и исходном компьютерах должны соответствовать друг другу.
3. Чтобы подготовиться к резервному копированию, нужно зарегистрироваться на исходном компьютере в качестве администратора и остановить все службы, за исключением основных.
4. С помощью утилиты ntbackup.exe следует создать копию загрузочного тома на исходной системе (том, содержащий папку %systemroot% и информацию о состоянии системы).
5. На целевом компьютере следует зарегистрироваться в качестве администратора и запустить ntbackup.exe. Из меню Tools утилиты нужно выбрать пункт Options. На закладке Restore отметить флажок Always replace the file on my computer.
6. Восстановить загрузочный том, информацию о состоянии системы и ассоциированные тома с резервной копии исходной системы. Следует убедиться, что местонахождение восстановленных файлов соответствует исходному.
7. После завершения операции восстановления на целевой машине, и перед ее перезапуском, необходимо убедиться в том, что компьютер отключен от сети. В результате удается избежать потенциальных конфликтов с другими машинами и службами.
8. Перезапустить целевой компьютер. Затем следует зарегистрироваться в качестве администратора и инициировать процесс обновления на месте, запустив Windows 2000 Setup (то есть, winnt32.exe) из папки /i386 на компакт диске с Windows 2000.

В процессе модернизации перестраиваются журнал setup.log и файлы реестра в папке %systemroot%
epair. При этом система гарантированно имеет требуемый HAL. Если, вопреки моему совету, уровни HAL не были приведены в соответствие, и система не перезапускается из-за различий в HAL, то положение небезнадежно. Можно запустить процедуру Windows 2000 Setup (например, с 3,5-дюймовой дискеты или компакт диска) и выполнить операцию восстановления или установки.

В любом случае, процедура Setup произведет переучет аппаратных средств системы, в том числе HAL, и выполнит модернизацию на месте, не затронув текущей системной конфигурации.

Большие преимущества

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

Шон Дейли — старший редактор журнала Windows 2000 Magazine и главный управляющий компании Realtimepublishers.com. Его последние книги — серия «The Definitive Guide to Windows 2000 Administration». С ним можно связаться по адресу электронной почты: sdaily@win2000mag.com.

Исходное положение: имеется старый десктоп с Win2K на борту. Установлены некие древние, но очень дефицитные программы, инсталляции к которым утеряны в веках, т. е. переустановке на новую систему не подлежат, да и совместимость хотя бы с WinXP под вопросом. Наряду с этим имеется свежайший десктоп с крутым i7 процессором и предустановленным Windows 7. Задача: избавиться от старого компа, сохранив при этом старые проги со всеми установками.

Варианты решения:

1. Перенос Win2K на новый комп в качестве второй системы с мультизагрузчиком. Создать новый логический диск, клонировать на него Win2K, установить на Семерке мультизагрузчик (например, бесплатный EasyBCD), решить проблему совместимости с SATA AHCI и прочими драйверами. Несомненный минус этого варианта — необходимость выгружаться из каждой системы для входа в другую, и это при условии, что нашлись драйвера для весьма-таки старой системы под современное оборудование. Да и установка драйверов контроллера SATA через Intel Matrix Storage — те еще танцы с бубном, да и не факт, что получится.

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

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

В свое время я успешно переносил Windows XP на VMWare машины используя VMWare Converter. Однако в данном случае несколько разных версий конвертера одинаково не справились и выдали ошибки конвертации. Пришлось действовать ассиметрично.

Описанный ниже процесс подходит для миграции как Win2K, так и WinXP.

Дисклеймер: все выполняется вами на ваш страх и риск. В случае материального или морального ущерба автор статьи умывает руки ;))

Итак: хост — новый комп с Windows 7 64 bit, на нем установлена свеженькая (на время написания статьи) VMWare Workstation 8.0.2. Что иметь перед процессом:

1. Утилиту для создания и восстановления образа и клонирования разделов и дисков (Acronis True Image, Symantec Norton Ghost (платные), Clonezilla (бесплатный) и др.). Я использовал первую, и в дальнейшем для краткости буду называть ее просто «Акронис».

2. Дистрибутив Windows 2000 или XP (CD или ISO-образ) — для запуска консоли восстановления (Recovery Console).

3. Образ дискеты с драйвером SCSI для VMWare (можно скачать здесь или здесь).

4. Обновление KB835732 (на сайте Microsoft: Win2K — английский, русский; WinXP — английский, русский)

5. Внешний USB HDD (если при переносе системы (шаг 3) используется способ 1) или IDE to USB адаптер или коробка (способ 2).

Пошагово:

1. Подготовка Win2K к переносу.

a. Убедиться, что установлен SP4. Не повредит установить все возможные обновления.

b. Скачать соответствующий нашей системе KB835732 и скопировать его в корень (или другой легкодоступный фолдер) системного диска.

2. Создание новой виртуальной машины. Выбираем Windows 2000 Professional на предложение выбрать операционную систему для VM (Select a Guest Operating System). На вопрос о максимальном размере диска я выставил 40 ГБ, поскольку таков размер физического диска с Win2K, и заполнен он более чем на две трети. Остальное можно по умолчанию. Дойдя до экрана Ready to Create Virtual Machine, жмем на кнопку Customize Hardware… и меняем тип New CD/DVD с дефолтного IDE на SCSI. Если оставить IDE, система не подключит CD/DVD после первого успешного запуска, а он нужен для установки VMWare Tools. После установки VMWare Tools и, соответственно, всех виртуальных драйверов можно поменять тип обратно на IDE.

3. Перенос содержимого физического диска на диск VM. Есть несколько способов:

Способ 1:

a. Создаем Акронисом образ физического диска с Win2K и копируем его на внешний USB диск. Подсоединяем диск с образом к хосту.

b. Стартуем виртуальную машину с CD или образа Акронис, и в меню VM > Removable Devices находим наш внешний диск и жмем на подменю Connect (Disconnect from Host). Диск теперь будет распознан Акронисом.

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

c. Восстанавливаем образ на диск виртуальной машины

Способ 2:

a. Снимаем оригинальный диск со старого компа, подсоединяем его как внешний (через адаптер или коробку) к хосту.

b. Те же действия, что и в п. b способа 1.

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

Первый способ требует только внешний диск (или даже большую и быструю флешку, что в наше время не редкость). Если нет IDE to USB адаптера или лениво снимать оригинальный диск — он предпочтительнее. Да и лишний бэкап системы не помешает. Минус — если в старом компе USB1.1, процесс создания образа может быть долгим. Ну так поставьте на ночь!

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

4. Запуск виртуальной машины — система вылетает в BSOD с сообщением:

Inaccessible boot device.

Это происходит из-за того, что диск в VM подключен к виртуальному SCSI контроллеру, и в системе нет соответствующего драйвера. Разрешить данную проблемы можно, заменив файл драйвера IDE atapi.sys на файл с таким же именем, но содержащий драйвер виртуального SCSI контроллера VMWare. Этот трюк обманет систему на момент загрузки, подсунув ей нужный драйвер с именем, соответствующим настройкам в реестре.

a. Вставляем в CD/DVD-ROM диск с дистрибутивом Win2K/WinXP и в настройках VM CD/DVD указываем использовать физический привод, или же монтируем образ дистрибутива (ISO image) в привод виртуальной машины. Во флоппи VM монтируем образ дискеты с драйвером SCSI для VMWare. Отмечаем чекбоксы Connect at power on в разделе Device status для обоих вышеуказанных виртуальных устройств.

b. Запускаем VM с CD/DVD (выставив последовательность загрузки в BIOS виртуальной машины раз и навсегда, либо же нажав Esc после включения VM и выбрав CD-ROM drive). Стартует процесс установки Windows. Заходим в Recovery Console, выбираем нашу систему и попадаем в системный фолдер C:WINDOWS или C:WINNT. В командной строке вводим:

cd SYSTEM32DRIVERS
del atapi.sys
copy a:vmscsi.sys atapi.sys

Вторую строку можно пропустить, тогда соглашаемся перезаписать существующий atapi.sys.

Все вышеописанное относится к случаю, когда старый диск IDE типа. Если же он подключен к SCSI или SATA контроллеру, atapi.sys не может быть использован. Нужно определить, какой файл содержит драйвер контроллера вашего типа диска и заменить его на vmscsi.sys. Команда консоли восстановления LISTSVC, выдающая список сервисов системы, может помочь идентифицировать файл драйвера. Он должен относиться в категории Boot (2й столбец).

c. Перезапускаем VM, введя exit в командную строку. На этот раз система загружается успешно.

Здесь надо отметить, что система при старте заменяет подсунутый ей поддельный IDE драйвер обратно на оригинальный, так что в случае перезагрузки без установки в системе драйвера VM SCSI контроллера синий экран вернется. Поэтому я отверг все предложения системы по ручной установке драйверов и перезагрузке и первым же делом установил драйвер SCSI Controller через Device Manager с той же дискеты. Теперь перезагрузка не чревата синим экраном, и система стартует успешно (а перезагрузиться разок таки пришлось, о чем далее). Если вы случайно перегрузили VM и снова получили BSOD — повторите 4-й шаг.

5. Установка VMware Tools. Запускаю — и получаю сообщение:

Microsoft Runtime DLLs cannot be installed on this operating system. Please see Microsoft KB835732 for details.

Поставил обновление KB835732, перегрузился (теперь можно), и VMware Tools установились без проблем. Ура, мы успешно переехали в виртуальную машину!

Кстати, не факт, что у вас тоже выскочит подобная проблема с установкой VMware Tools. Особенно если, как я упоминал в начале, в оригинальной системе еще до переноса были установлены все обновления. Все же имейте KB835732 под рукой, желательно — прямо на диске для удобства доступа.