Migrate Win7 between PCs without Migration Tools
#1
Posted 26 November 2011 - 08:38 PM
There are many ways to migrate Windows from an old PC to a new one, and often people want to learn doing it manually instead of using 3-d party tools. It can be done in combination of 2 ways: by modifying online OS volume after booting from it, and/or modifying offline OS volume with or without 3-d party migration tools. One can migrate Win 7 to a new PC by directly restoring its backup image to the new hard drive, or transferring it via a VHD. In both cases you don't have to worry about complex migration and deployment tools, strategies and limitations, eagerly crafted by MS. Its also useful, when attempts to boot OS migrated to a new PC with a 3-rd party tool failed.
1. Transfer your existing Win7 volume to a new hard drive:
- remove an empty hard drive from your new PC and attach it to the old PC without removing its old drive
- boot from the old drive, download a ready to use or prepare Win7 PE on CD, ISO or USB Thumb with WAIK or WinBuilder
- capture an existing Win7 volume with all apps to a WIM image with ImageX (see code example in Create Native Boot VHDs)
- add missing IDE or SATA drivers to Win7 WIM with DISM tool, if your new HD is of a different type than the old one
- then use ImageX to apply the Win7 WIM image you just captured to the new hard drive, OR
- use USB_W7_Fix and other tools from wimb's IMG_XP package to add missing drivers offline and prepare for boot the captured OS image
- alternatively to ImageX, you can backup and restore your old drive with a backup tool like Acronis with Universal Restore or Paragon
2. Generalize transferred Win7 volume on your old PC:
- open Regedit as Admininstrator from Start Search, click on HKEY_LOCAL_MACHINE
- from Menu select File - Load Hive, and point to SYSTEM registry file on the new drive in the folder E:windowssystem32config
- name the new key Win7_Copy, open it and delete DosDevicesC: value in MountedDevices subkey of Win7_Copy key
- click on Win7_Copy key, select File - Unload Hive from Menu, exit Regedit
- shut down the old PC, remove the old drive and reboot from the new drive on your old PC, or set it as 1-st boot drive in BIOS
- open Device Management Console (devmgmt.msc) from Command Prompt
- uninstall 3-d party or manufacturer's drivers one by one for critical boot devices on your PC (IDE and USB Storage Controllers - if booting from a USB drive, and also Display Adapter, Monitor, Network adapter, Keyboard & Mice)
- select Action - Scan for Hardware Changes in Console Menu, choose for each affected device a generic MS driver offered by OS
- update driver for Computer type to standard non-ACPI PC from your Win Setup DVD if available and close the Console, OR
- instead of using Device Manager, run Devcon.exe from Command Prompt to remove these old PC devices
- run from Command Prompt to activate HAL (Computer type) detection: bcdedit /set {default} detecthal on
- open Regedit and enable switching between IDE/AHCI/RAID modes by changing Start values to 0 in subkeys iaStorV, Msahci, Pciide of the key HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservices. Depending on your PC config and Win7 version, other Registry changes might be needed.
- shut down Windows and reboot to Win7 PE
- open Regedit from Command Prompt, click on HKEY_LOCAL_MACHINE
- from Menu select File - Load Hive, and point to SYSTEM registry file on the new drive in the folder E:windowssystem32config
- name the key Win7_Copy, open it and delete MountedDevices subkey in the attached Win7_Copy key
- click on Win7_Copy key, select File - Unload Hive from Menu, exit Regedit
- type notepad in Command Prompt, then click File - Open in Notepad Menu
- browse to E:windowssystem32config, delete all files with extensions evt, sav, log, exit Notepad and Win7 PE
- insert the old drive back to your old PC if removed earlier
3. Re-specialize transferred Win7 volume on the new PC:
- move the new drive back to your new PC and switch it ON
- enter BIOS, select AHCI/SATA mode if supported by your new Motherboard, select ACPI mode, save and exit BIOS
- Win7 will boot and auto install all required generic drivers for the new PC
- once booted, you might want to manually install or update some installed drivers with latest device manufacturer's drivers
- you might need to re-activate Win7 after moving it to dissimilar hardware
- enjoy working on your new PC with familiar OS volume, all previously installed apps and user accounts
DONE!
- Brito likes this
#2
Posted 27 November 2011 - 06:52 AM
Trying the VHD method will not only help to migrate your OS with all installed apps, but also introduce you to very hot Virtual Windows world allowing to run OS in a portable way from VHD (virtual hard drive) without installing it to your new PC:
1. Capture your existing Win7 volume to a Base VHD:
- boot from old drive, and capture an existing Win7 install with all apps to WIM image with ImageX as per Create Native Boot VHDs Tutorial
- add missing IDE or SATA drivers to Win7 WIM with DISM tool, if your new HD is of a different type than the old one
- download or prepare Win7 PE on CD, ISO or USB Thumb with WAIK or WinBuilder
- create a Base VHD on your old HD, attach, format and name it Win7.vhd
- then apply to it using ImageX the Win7 WIM image you just captured, OR
- use USB_W7_Fix and other tools from wimb's IMG_XP package to add missing drivers offline and prepare for boot the captured OS image
- alternatively to ImageX, you can backup and restore your old drive with a backup tool like Acronis with Universal Restore or Paragon
2. Generalize the Base VHD:
- shutdown Windows and reboot from the VHD natively on your old PC
- open Device Management Console (devmgmt.msc) from Command Prompt
- uninstall 3-d party or manufacturer's drivers one by one for critical boot devices on your PC (IDE and USB Storage Controllers - if booting from a USB drive, and also Display Adapter, Monitor, Network adapter, Keyboard & Mice)
- select Action - Scan for Hardware Changes in Console Menu, choose for each affected device a generic MS driver offered by OS
- update driver for Computer type to standard non-ACPI PC from your Win Setup DVD if available and close the Console, OR
- instead of using Device Manager, run Devcon.exe from Command Prompt to remove these old PC devices
- open Regedit and enable switching between IDE/AHCI/RAID modes by changing Start values to 0 in subkeys iaStorV, Msahci, Pciide of the key HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservices. Depending on your PC configs and Win7 version, other Registry changes might be needed.
- shut down the old PC, remove a hard drive from the new PC and add it to your old PC without removing the old drive, OR
- if you can't connect an extra drive to your old PC, remove the old drive from it and attach to the new PC, continue there
- reboot to Win7 PE on a PC with the new drive connected
- copy your Base VHD from old to the new drive as per Boot VHD on Bare Metal PC
- run Diskpart from Command Prompt, and attach the VHD saved on the new drive as V: disk
- add Win7 boot environment and the VHD boot entry with option Detecthal On to the new hard drive
- open Regedit from Command Prompt, click on HKEY_LOCAL_MACHINE
- from Menu select File - Load Hive, and point to SYSTEM registry file in the folder V:windowssystem32config
- name the key Win7_VHD, open it and delete MountedDevices subkey in the attached Win7_VHD key
- click on Win7_VHD key, select File - Unload Hive from Menu, exit Regedit
- type notepad in Command Prompt, then click File - Open in Notepad Menu
- browse to V:windowssystem32config, delete all files with extensions evt, sav, log, exit Notepad and Win7 PE
3. Re-specialize the Base VHD and transfer OS from it to the new PC's HD:
- move the new hard drive back from old to your new PC and switch it ON
- enter BIOS, select ACPI mode, switch to IDE (if your old drive is IDE type), save and exit BIOS
- boot from the VHD to auto install generic device drivers and add the new drive record to OS Registry, reboot
- enter BIOS, select AHCI/SATA mode if supported by your new Motherboard, save and exit BIOS, reboot
- once booted, you might want to manually install or update some drivers with latest device manufacturer's drivers
- keep working on your new PC without ever installing OS to it, OR
- if you want to restore Win7 from VHD directly to your new hard drive, capture the booted system image with ImageX
- then apply it to your new hard drive with ImageX and reboot from the drive
- Win7 might need re-activation after moving it to dissimilar hardware
- move the VHD to a USB Thumb and use for portable Win7 boot to perform service tasks on your PC
- enjoy working on your new PC with familiar OS volume, all previously installed apps and user accounts
DONE!
Experimental:
If your Win 7 version on VHD is not "high end" Enterprise, Ultimate or Win Server 2008R2 , and can't boot natively from Windows Boot Menu, you can boot it with Grub4DOS bootloader and Win7VBlock virtual disk driver. In addition to above described steps, for successful migration add in step 2:
- install Win7VBlock driver to running Win 7 before it's captured to WIM image
- add MBR and Win7 boot environment to the system volume on the attached VHD
- add required Grub4DOS files to your new hard drive's root as per Grub4DOS Guide
- add Grub4DOS entry to Windows Boot Menu
- add Boot Win7 from VHD entry to Grub4DOS menu (credits to Sha0):
title Boot Win7 from VHD with Win7VBlock driver
find --set-root --ignore-floppies /Win7.vhd
map /Win7.vhd (hd0)
map --rd-size=2048
map --mem (rd)+4 (0x55)
map --hook
write (0x55) #GRUB4DOSx00v=1x00Win7.vhdx00x80x00
root (hd0,0)
chainloader /BOOTMGR
Notes:
- WinVBlock 32-bit driver doesn't require signing, but 64-bit driver is signed with a test certificate, so you need to switch On Test Mode in Win7 64-bit on the attached VHD by running from Command Prompt
to activate: bcdedit /set {default} testsigning on , to deactivate: bcdedit /set [default] testsigning off
- The VHD file must be of fixed type and contiguous to boot OS with Grub4DOS. Check it with Contig utility and defrag if needed, also attach and defrag the system volume inside the VHD
- Brito likes this
#3
Posted 27 November 2011 - 04:48 PM
Everything should go well , BUT if you have on the "base" or "source" install either reparse points or sparse files, you may find yourself in trouble , particularly if you have "large" sparse files it is possible that you quickly exceed the available space on the target .
I don't think that the behaviour of Imagex has changed in later versions :
http://support.micro...kb/935467/en-us
In a related thread here:
http://www.msfn.org/...system-backups/
there is BTW a report about problems with the (actually I presume RARE) case of files bigger than 128 Gb....
Wonko
#4
Posted 27 November 2011 - 05:11 PM
Before doing manual migration of Win7 with ImageX, it makes sense to get familiar with ImageX Limitations and, if find something relevant to your case, use another MS developed migration & deployment tool (which can be more complex to master), or your favorite backup & restore package like Acronis or Paragon.
In short, to migrate a Win7 system volume with all apps and user accounts to a new PC, you need to backup OS from old drive & restore it to a new drive on your old PC, then delete old boot drive record in the restored OS Registry, reboot from new drive and replace specific old PC drivers and Computer type with generics, activate SATA and HAL detection, then reboot from Win7 PE and delete MountedDevices key in restored OS Registry, and cleanup its system32/config folder from log files, then move the new drive from old to new PC, reboot and enjoy. Your old drive won't change, so you can keep using it on that old PC.
#5
Posted 02 December 2011 - 09:11 PM
Hence the questions:
- is there a tool that can reflect a driver load order by analyzing certain (log) files (which ones?) of offline Win 7 OS, or can write such a log during boot, so that a problem driver can be identified? Found one - LoadOrder from Sysinternals, but it only runs from inside a booted OS.
- is there a method to change the driver load order set by the system? How the system chooses a certain driver load order anyway at first run after setup?
#6
Posted 03 December 2011 - 12:45 AM
- if such a limited adjustablity OS is applied by ImageX on real hardware from a setup ISO to a VHD, what's the best way to inject extra drivers to it afterwards like WinVBlock, since it can't be done online: it wouldn't even boot in a VM either? Any simple tools to do that from another Win7 install without using elaborate MS deployment or migration packages, or specific WinPEs?
- what tools allow to quickly compare two Registry contents (online and offline) similar to comparing folders content in Beyond Compare or such well visualized disk comparison packages?
#7
Posted 03 December 2011 - 12:17 PM
None AFAIK.- what tools allow to quickly compare two Registry contents (online and offline) similar to comparing folders content in Beyond Compare or such well visualized disk comparison packages?
But regshot is usually "good enough".
If someone of the good programmers would take in their hands the Offline Registry access library:
I guess it could be possible:
http://reboot.pro/11212/
Using the small command line tool by erwan.l:
http://reboot.pro/11312/
i don't think it is possible "as is"
As well, if any of the good programmers guy would take in their hands this approach and extend it to all possible data types and "file choosing":
http://reboot.pro/7681/
which BTW is actually the "right" one IMNSHO, *any* dir compare utility would do.
Wonko
#8
Posted 03 December 2011 - 12:56 PM
Dism integrates drivers to offline images, this includes a offline windows.inject extra drivers to it afterwards like WinVBlock
Driver Servicing Command-Line Options
http://technet.micro...258(WS.10).aspx
#9
Posted 03 December 2011 - 01:02 PM
Of course, would be nice to use MS native Offline Registry Access Library you linked - anyone would be interested to develop such Registry Comparison Tool?
DISM Command Line looks like a simple enough driver injection tool for an average user. Relevant question: at times, when a driver is deleted from Device Management Console, OS requires reboot, and upon reboot installs it again, thus blocking install of a different driver for that device. Is there a way to prevent it - possibly by changing the driver's file name in System32Drivers, unless OS won't look for it in other places after such change?
#10
Posted 03 December 2011 - 01:10 PM
None AFAIK.
But regshot is usually "good enough".
If someone of the good programmers would take in their hands the Offline Registry access library:
I guess it could be possible:
http://reboot.pro/11212/
Using the small command line tool by erwan.l:
http://reboot.pro/11312/
i don't think it is possible "as is"
As well, if any of the good programmers guy would take in their hands this approach and extend it to all possible data types and "file choosing":
http://reboot.pro/7681/
which BTW is actually the "right" one IMNSHO, *any* dir compare utility would do.
Wonko
With the proper specs, I can add extra command line parameters to the offlinereg tool or else come with another tool based on the MS library.
Regards,
Erwan
#11
Posted 03 December 2011 - 01:17 PM
The whole idea of such a Tool is based on the popular GUI concept - it must be visualized similar to Beyond Compare to serve mass user migration needs. Can you make it work?
#12
Posted 03 December 2011 - 01:38 PM
Remove offending drivers.Relevant question: at times, when a driver is deleted from Device Management Console, OS requires reboot, and upon reboot installs it again, thus blocking install of a different driver for that device. Is there a way to prevent it
Dism /Remove-Driver : Removes third-party drivers from an offline image.
Or delete offending default *.inf file(s).
#13
Posted 03 December 2011 - 01:41 PM
Actually it would be enough to "convert" the offline Registry to one or more text file(s), then use *any* text comparison app, GUI or not...The whole idea of such a Tool is based on popular GUI concept - it must be visualized similar to Beyond Compare to serve mass user migration needs. Can you make it work?
JFYI, if you compare the "features" of NTFS (or of the "next" protogon) with the features of a Registry file, a number of common points will be evident.
A filesystem is a Database, not necessarly an OO one, though.
Wonko
#14
Posted 03 December 2011 - 02:18 PM
So, it comes at boot right after disk.sys, hence being a device discovery driver, and apparently WES7 doesn't seem to contain in itself extra drivers stock, it can't find SATA, since IDE disk was used in a VM to install WES7 to VHD, and hangs. Presumably, such thing may happen with any driver type when it comes to WES7 or another portable OS. One suggested way to predict and mitigate this - by injecting target PC drivers with DISM before OS migration. Other suggestions?
#15
Posted 03 December 2011 - 02:36 PM
A 100 per cent portable OS is as simple as perpetual motion http://en.wikipedia....erpetual_motionPresumably, such thing may happen with any driver type when it comes to WES7 or another portable OS.
Enable bootlog http://msdn.microsof...2(v=vs.85).aspx
#16
Posted 03 December 2011 - 03:15 PM
#17
Posted 03 December 2011 - 03:21 PM
Just thinking out loud.
An Idea came to me concerning this.
Would it be doable and without side effects if you just do sysprep /generalize /shutdown command on your old machine. Capture with ImageX OS and System partition. And apply them to new peace of hardware. It should be applied on identical partitions.
I mean, sysprep will remove hardware specific entries, clear Event logs (backup needed), reset product key, remove SID... in other words prepare OS for new machine.
So all u need to do is let specialize faze pass again on your old machine and it would install again MS drivers, relicence you OS. Result of sysprep would also made your machine name all in uppercase characters, create new account, old one will remain, remove computer from domain ofcourse, hmmm ...?
Edited by Sideshow_B0B, 03 December 2011 - 03:26 PM.
#18
Posted 03 December 2011 - 03:41 PM
Why?It should be applied on identical partitions.
Wonko
#19
Posted 03 December 2011 - 03:45 PM
All start=0 drivers are loaded to RAM.What the later mean - expected (or attempted) to load but failed?
Imagine several IDE drivers: pciide, intelide, siside, viaide
All drivers are market at Ntbtlog.txt:
one driver is initialized and used to connect to hardware
other drivers are not used: loading failed
#20
Posted 03 December 2011 - 03:56 PM
Well if your capturing partition type is primary, logical or extended, destination partition should be the same, also if your source partition is mark as active, dest-partition should be also becouse of proper boot constraints, if it's C: destination partition should be C:. Correct me if Im wrong but some applications require persistant C: partitions or else wont work.Why?
I didn't try that idea of mine just bcz I dont have a spare PC right now and it's no use of doing it on virtual machine.
Edited by Sideshow_B0B, 03 December 2011 - 03:57 PM.
#21
Posted 03 December 2011 - 04:29 PM
CurrentControlSetServices Subkey Entries details several possible Start values in Service registry keys, and also mentions Tag atribute to control drivers load order. What happens with start=3 drivers at boot - what OS mechanism prompts them to load? Also, if a user's PC booted successfully in both SATA and IDE modes, yet after installing a new OS to a different partition on the same drive the old OS refuses to boot in one of these modes, what's the most probable cause? Why a new OS installation process appears to affect an existing OS's Registry in multiboot systems?
Sideshow_B0B
MS offered Sysprep tool namely for that. The problem is, most users (just like you) don't want to run Sysprep on their working system merely to migrate it to another PC, when the old PC must remain operational as well. Imaging sysprepping your main OS each time you want to transfer its copy somewhere... Another problem with Sysprep - it can only run on unmodified OS, so if you installed Win7 and later added SP1, Sysprep won't run. As well, if you installed an OS inside a virtual machine, and then want to migrate it to a real PC, Sysprep might have a hard time running inside the VM.
This WIM2VHD tool may be quite handy for P2V migration, since it seems to combine ImageX, Sysprep and BCD Editor functionality to sysprep the target OS on VHD, when hooked with WAIK, so no sysprep run is required on your main source OS system.
#22
Posted 03 December 2011 - 05:00 PM
Your list - which however I don't think is actually applicable entirely as "constraints" when talking of a sysprepped, "ready to deploy") image - DOES NOT equal to "IDENTICAL", that's the whole point of the "WHY?".Well if your capturing partition type is primary, logical or extended, destination partition should be the same, also if your source partition is mark as active, dest-partition should be also becouse of proper boot constraints, if it's C: destination partition should be C:. Correct me if Im wrong but some applications require persistant C: partitions or else wont work.
Whilst some of the "constraints" you listed may apply, "IDENTICAL" means:
- Same status in the MBR[1] (Active/non active) IF Primary
- Same type (Primary vs,. Volume inside extended)
- Same Filesystem ID in MBR or EPBR[2]
- Same Filesystem used
- Same Volume ID (filesystem serial) in VBR[3]
- Same OFFSET in BOTH CHS (If applicable) and LBA address in MBR or EPBR
- Same EXTENSION in BOTH CHS (If applicable) and LBA address in MBR or EPBR
- Same PBR CODE
- Same HS geometry (MBR or EPBR and VBR)
If ANY of the above is different, the partition is NOT "IDENTICAL".
@All
(If I forgot any other condition that may make two volumes different, please post so)
Wonko
[1] MBR= Master Boot Record or sector 0 of the disk or \\.\PhysicalDrive
[2] EPBR= Extended Partition Boot Record
[3] VBR= Volume Boot Record or PBR=Partition Boot Record or bootsector or sector 0 of the \\.LogicalDrive
#23
Posted 03 December 2011 - 05:00 PM
I understand ...
But as I can see your old PC is not operational for some time while executing thing from you tutorial. So my Q is would the old system be fully operational like before running sysprep, if it would then I think we got ourselfs one more time saving method for same thing.
@Wonko
Dude, maybe I didn't use right word. But I explained on what things I meant. Sorry. (nice wiki paste)
Edited by Sideshow_B0B, 03 December 2011 - 05:08 PM.
#24
Posted 03 December 2011 - 05:20 PM
Any and all examples in my posts and Tutorials are irrelevant in every way to my own system (if any ). Just like testing things, and we all learn something new by discussing such issues. They are merely chosen to demonstrate possible but less frequent complexities and irregularities that may come on the way of OS migration depending on its version. No tool can take all that into account, and MS tools like Sysprep aren't free of bugs and limitations - read numerous MS forums.
For example, you don't seem to plan migrating anywhere, yet found this topic intriguing enough, despite irrelevant to your needs.
More about using DISM (which is included in default Win7 and WAIK, and can be installed in WinXP) for OS migration tasks:
DISM - Deployment Servicing and Management
Windows 7 DISM – how to mount, manage, and service WIM images
DISM GUI Tool - with a nice GUI
WIM Imaging Tutorial
Mistakes are the secret of my success.
#25
Posted 03 December 2011 - 05:37 PM
Can't agree more.
Dont get me wrong m8, your tutorial is great. Keep up the good work.
Also tagged with one or more of these keywords: vhd, os migration, win7, migration tools
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users