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

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:

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 Promptto 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

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 .

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.

Testing migration of a system with limited abilities to adjust, I installed Win7 Embedded SP1 64-bit inside a virtual machine on a VHD, added test signed WinVBlock to it, and tried to boot it in Test Mode on real HW with Grub4DOS after performing above described migration fixes. The problem is, it hangs at boot every time after loading classpnp.sys driver. So I assume the driver that goes after it might cause this hang. WinVBlock however loads OK long before.

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?

- 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?

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.

Windows Registry is rather an Object Oriented Database (OODB), and in that respect BCD Store is another usage of similar OODB with each object (an OS Boot Entry) having multiple descriptors. A filesystem is also OODB of sort, and symbolic links may connect objects within it. It might be, such OODB comparison tools already exist, since such DBs are used for quite a long time.

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?

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.

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

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?

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...

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.

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?

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 ...?

All start=0 drivers are loaded to RAM.Imagine several IDE drivers: pciide, intelide, siside, viaideAll drivers are market at Ntbtlog.txt:one driver is initialized and used to connect to hardwareother drivers are not used: loading failed

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.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.

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.

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.

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?".

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

@sambul61
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)

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: