When I looked how the existing original disk was partitioned to my surprise I saw 5 (that’s right – five) partitions. They were marked as follows:

1. OEM Partition (1023 MB in size) – now I know that such partition contains Windows Recovery Environment
2. EFI System Partition called ESP (360MB in size) – it is similar to “Active Partition” known in MBR formatted disks, the UEFI looks for boot manager only on partitions of this type
3. Boot, Primary partition – the first partition which is actually seen in My Computer as C: drive and it contains Windows system files
4. Primary Partition – the second and biggest partition which contains my other data (seen as drive D: in My Computer)
5. OEM Partition (labeled “Recovery Image”) – contains recovery image which was created by laptop manufacturer

So the biggest question was – which of those partitions should I clone to the new disk and how to do this? In the past, when working with Windows XP and MBR formatted disks the only partition I had to clone was the partition, that contained the Windows system files (in the above scenario it would be number 3). But here it was not the case. The files that are required for the system to boot lie on the partition number 2. So after checking what these all 5 partitions contain I went to conclusion, that I need to clone at least 2 partitions:

• EFI System Partition (partition number 2 in my case)
• Boot, Primary Partition (partition number 3 in my case)

When I finally identified which partitions I should clone, I then needed to chose a tool to actually clone them. In the past I was using SelfImage to do such work, however for some reason this program has problems with GPT disks. So then I used a good old tool, known from UNIX like systems, called DD. There is a port of this wonderful tool for Windows called “DD for Windows“.

Having all my questions answered I started to work with cloning the partitions. This is the procedure I followed to successfully clone my current system to a new SSD disk:

1. Create 2 partitions on new disk (EFI System partition and Windows Primary partition)

   		
   select disk <destination_disk_number>
   clean
   convert gpt
   create partition efi size=SOURCE_EFI_PARTITION_SIZE
   format quick fs=fat32 label="SYSTEM"
   create partition primary
   format quick fs=ntfs label="Windows"
   exit

2. Using DD program (or any other partition cloning program) copy all contents of source EFI System partition and Windows Primary partition to the new, just created, partitions.

   WARNING: cloning of the partition which contains Windows system files must be done when the system contained on it is not running – I did that using Win7PE DVD, but you could do this using for example any live Linux distribution.

3. After cloning is complete you have to assign a letter to both cloned partitions (assume that ESP will be mounted to S, and Windows partition will be mounted to W). Although assigning a letter to cloned Windows partition is not a big deal (you can do this from Disk Management), then assigning the letter to the cloned ESP is not so easy – you cannot do this from Disk Management snap-in. To assign a drive letter to ESP partition you have to do this using DISKPART utility:

   		
   select disk <destination_disk_number>
   select partition <index_of_cloned_esp_partition>
   assign letter=s
   exit

4. Process of cloning the ESP partition makes one nasty thing to boot manager contained on it – it invalidates the “device” and “osdevice” variables stored within its configuration. So to make the cloned system bootable without BSOD, after the letter to cloned partitions are assigned, you have to edit boot manager configuration contained on ESP partition and properly set the “device” and “osdevice” variables so they point to cloned Windows partition. To do so use the BCDEDIT utility (I assumed below that you mounted cloned ESP partition under S letter and cloned Windows partition was mounted under letter W):

   		
   bcdedit /store s:\boot\bcd /set {default} device partition=W:
   bcdedit /store s:\boot\bcd /set {default} osdevice partition=W:

   WARNING: It is very important to use here a cloned ESP and Windows partitions (mounted under letter S and W), not the original ones.

5. Done – you should now have a working, cloned Windows 8 system on a new disk.

In the below table I described all of the registry locations I know which programs are using to start automatically with Windows:

Some information in the above table has been taken from this forum: Registry AutoStart Locations

To be able to successfully install Windows 8 in such situation you must set SATA controller mode of system hard disk to IDE for the time of system installation. After the system is installed first thing to do is to install the newest RAID driver from AMD site and disable the buggy amdsbs.sys driver in the registry (without disabling it you will still sporadically encounter BSODs even though the newer and bug free driver from AMD is installed). To completely disable the buggy driver you have to perform the following steps:

1. Open Registry Editor
2. Navigate to the “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\amdsbs” key.
3. In the right pane find “Start” parameter, double click it and set its value to 4.
4. Close the Registry Editor and reboot the system.

After installing the newest RAID driver and disabling the buggy one, you can set back the SATA mode of your disks to RAID and the Windows will be working stable now.

But first let think why the old os cannot successfully boot on the new hardware. The problem lies in two places (or at least in one of them). First is the controller of the system disk – if the controller in the new motherboard comes from other vendor or is simply incompatible with the old controller (for examle the old one was Intel IDE and the new is VIA IDE), then the os does not have the right device driver for it and as the result it cannot access the hard drive during boot resulting in BSOD. The second lies in the processor architecture (but only if the new processor is from other vendor, for example the old one was from Intel and the new one comes from AMD).

To cope with the problem with device driver for disk controller you have to have a Live CD or bootable USB flash (with BartPE, VistaPE, etc.) in which you can access the system partition and the registry of the installed system. You will have then manually place the right driver for the new disk controller in the “%systemroot%\system32\drivers” folder and manually add or edit the registry to make the driver being loaded with the system (the drivers are being represented as services in the following registry key: HKLM\System\CurrentControlSet\Services).

When you will be fine with the driver for the hard disk controller, then you need to ensure that the IntelPPM service is disabled  (in the registry the start value must be set to 4). Without disabling it, when the new processor comes not from Intel, you will end up with BSOD as well.

This is not a detailed explanation of what to do exactly but it shows the way you shall go if you don’t want to reinstall the whole operating system after changing your hardware like motherboard, disk controller or processor.

So to sum up – always read %ERRORLEVEL% variable outside any IF clause. Not doing so will cause wrong exit code to be retrieved. This is very strange behavior which made me to spend all day searching what is wrong with my BAT files not working.

The problem with such operation is that after restoring for example 20GB partition image to a partition which has 40GB, you will see, that the file system says that there is only 20GB of total partition’s space. This is caused due to old partition size information saved inside internal filesystem’s structures, which was made during the format of the partition on the original drive. Fortunately, the DISKPART utility built in Windows XP and newer systems can fix that problem. To do that follow the following steps after you restore the image to the new, reater partition:

1. Launch the diskpart command line utility.
2. Execute “select volume <number>” command, where “<number>” is a number of the volume containing the restored partition image (the list of all volumes and their numbers can be retrieved by executing “list volume” command).
3. Execute “extend filesystem” command.
4. And this is all – now exit the diskpart utility by executing “exit” command and the system will correctly see the real partition size.

Thanks to this tip you can use programs like SelfImage not only for making backups but also for moving entire partitions (including system partitions) to other hard drives even, when they size do not match.

The solution to such problems is quite easy – you only have to add /usepmtimer switch to your server’s boot.ini file and restart the virtual server. This will cause a different approach during time measurement and will fix mentioned problems.

To fix this irritating behavior clearing the dnscache will not always work. The best way to cope with this problem is to stop DnsCache service – after doing that every time you try access any network resource by its name, the DNS name query will be passed directly to your DNS servers omitting your local cache.

EDIT:

After some time I noticed one more problem with DNS especially when using VPNs established using RRAS. Simply the names were not being resolved by DNS servers provided by RRAS but they were trying to be resolved by DNS servers outside of VPN. This prevented accessing VPN network resources using names. The problem can be fixed by following the following steps:

1. Go to Network Connections in Control Panel.
2. Go to Menu: Advanced -> Advanced Settings -> Adapters & Bindings
3. Move DialUp connections to the top of the list.
4. Save changes by clisking OK button.
5. In Windows XP & 2k also follow the instructions described under the following link: http://support.microsoft.com/default.aspx?scid=kb;en-us;311218
6. Reboot your computer.

After performing the above operations you should not have any DNS issues when using VPNs on your computer.

So even when you request the server to boot from Virtual media, during the installation the Windows Installer will be using the physically inserted DVD as a source. To avoid that sick behavior you have to disable any optical drives in server’s BIOS setup for the time of installation.  After disabling them, Windows Installer will look for source files only on virtual media and not on physical DVD allowing you to successfully install the OS.

Mentioned problem sometimes arises after some malware installation – the disinfection not always repairs that problem automatically.