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

This article describes almost everything what you should do except the following:

1. What to do with “schema-root”, “OWAScratch{GUID}” and “StoreEvents{GUID}” system folders.
2. How to delete the first AG when removing the last server from it.

Ad. 1. It is best to rehome mentioned system folders to the other server as you did with the OAB folders and others, so their content is removed from the server being decommissioned but stays on the other one. This would be the best way to get rid of them from the “Public Folder store” of the retiring server.

This is in contrast to simply deleting the folders – I noticed that deleting these folders can lead to strange behavior: they structure is being regenerated by the Exchange after decommissioning the first server however they do not have a replica so they cannot be used. This is not preventing the public folders from working fine, however this causes errors when looking at them using “Exchange System Manager”. I do not know if this can lead to some other, serious problems but seeing an errors in ESM is not a good sign I think.

When there are no mailboxes and public folder instances left on the decommissioned server and other steps mentioned in Microsoft’s article are already done then you can remove the “Public Folder Store” and “Mailbox Store” from it.

Ad. 2 If you want to remove whole Administrative Group which will be empty after decommissioning the server, then before uninstalling the Microsoft Exchange from the server follow these steps:

1. Move the “Public Folders” tree to the other AG if it exists in the current AG being removed.
2. Remove all the connectors from the routing groups stored within this AG and all connectors from other routing groups in other AGs which were connected to the routing groups in the AG being removed.
3. Uninstall the Microsoft Exchange from the server being decommissioned in this group.
4. Remove all routing groups from the AG.
5. Remove all containers from the AG.
6. Remove the AG.

Steps 1,2,4,5,6 are best to be performed using ESM on other Exchange server (anyone which is not being decommisioned).

Fortunately it was not as bad as I firstly thought. The raid was not seen by the BIOS itself, thats true, however the operating system did see my RAID array without any problems – like nothing happened. I only lost the boot availability from any hard drives which were connected to my RAID controller.

First thing I did was to change my system hard drive mode from RAID to IDE in system BIOS. That allowed me to boot my system and after that the system saw my RAID array without any problems. That was a relief, because I thought that I have lost my array together with the data contained within.

But that was no solution to me, because the system hard drive operating in IDE mode works noticeably slower and I did not buy an expensive video card to slow down my computer!

Then I started thinking what could have caused such strange behavior. I tried upgrading the BIOS but that did nothing. Then I recalled, that the system BIOS is mapping boot roms of hardware within a special memory, called a Conventional Memory which is always 640KB in size. So maybe the system BIOS has wrongly mapped the roms and not all of them fit into 640KB? And that was it! Disabling some built-in roms (in my case I disabled buil-in IDE BIOS ROM because I do not boot from IDE devices normally) did the trick – the system BIOS started to see my RAID array again. Uff.

So if anyone would ever go into similar problems after replacing a video card – to workaround the issue you will have to disable some unused built-in roms in BIOS setup to allow RAID BOOT ROM to fit into conventional memory and be seen by the system BIOS.

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.

To do this follow the following steps:

1. Start IIS Manager
2. Click on <server name> and then in the right pane go to “FastCGI Settings”.
3. Right click on php-cgi.exe file and choose “Edit…”.
4. Set the “Standard error mode” option to “IgnoreAndReturn200” value.
5. Click OK and close IIS Manager.

After performing mentioned steps you shall no longer see HTTP 500 error messages in the browser.

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.

This worked in IE8 browser, however I am almost sure it will work in other versions of IE as well.