Forum member “ymboc” has long been a great technical contributor in the MediaSmartServer.net forums. First he uncovered the layout of the MediaSmart Server debug port, then figured out how to modify the BIOS of the EX470 and EX475 to use an AMD X2 processor, next he documented the registry keys that manage the fan speed of the EX470 and EX475 MediaSmart Servers (subsequently used by the MSS Fan Control Add-In), and has continued to support all the hardware tweaking enthusiasts in the forums.
Now he’s at it again with a new guide describing how to successfully clone and upgrade your Windows Home Server system drive using the uniqueid feature of the Windows diskpart command. I’ll preface this by saying this is not a solution to back up the WHS System drive, this process is only useful as a mechanism to replace or upgrade the system drive in your Windows Home Server. It is also a fairly lengthy process that requires a significant attention to detail in order to be successful, and of course this carries the risk of possibly damaging your Windows Home Server installation or could even result in data loss.
With all the scary caveats and disclaimers out of the way, here’s a description of the issue from ymboc’s forum post.
WHS uses (GU)ID numbers stored in the partition table of each disk to help identify them. When using disk imaging software to migrate an operating system from one disk to another disk, these disk ID numbers are typically not cloned during the disk imaging operation.
To Function properly, WHS requires that the disk ID number of the newly imaged disk match that of the image source.
A cloned WHS system disk with a mismatched disk ID number will still boot normally but will exhibit a number of Critical Health Warnings the most common of which is the “Backup Service is not Running” warning.
ymboc found that he could manipulate the disk ID using the uniqueid feature of the diskpart command to transfer the old Disk ID from the original disk and apply it to the new disk, allowing Windows Home Server to boot successfully with none of the warnings usually encountered. He tried this process first on a test system and then on his main home system and both worked successfully. Note that the original version of Vista does not support the uniqueid feature, you’ll need at least SP1.
I wanted to verify his findings and become familiar with the process, so I took my recently retired but still running EX475 with 3 drives in the storage pool including the stock 500GB System drive. I started by shutting down the Home Server, removing the System Drive, and inserting both it and a spare 750GB drive into my iStoragePro eSATA storage enclosure that was connected to my Vista SP2 PC. A multi-drive eSATA or USB external enclosure is the most simple way to directly attach the drives for cloning, however other alternatives are certainly possible such as installing the drives internal to your PC or by creating an image of the original disk and then applying it to the upgrade disk.
The next step was to use the “Clone Drive” feature of Acronis True Image Home 2010 to clone the original 500GB system drive to the spare 750GB drive. I selected the “Automatically resize partitions” option in Acronis so that the D: partition would fill up the new disk. Other disk imaging software or older versions may not support the “Automatically resize partitions” option, in which case ymboc includes instructions on how to do this manually. The disk clone took a bit over an hour to complete. I ended up with a 30GB system partition instead of the default 20GB system partition, with the remainder of the space utilized by the expanded D: DATA partition. This was due to the “proportional” default behavior of Acronis which resized each partition.
I wanted to verify the negative behavior of adding a cloned drive to the system to demonstrate the failure seen when the DISK ID’s don’t match, so I inserted the 750GB cloned drive into the server and powered it on. As you can see, Windows Home Server is not happy at all and my system is effectively unusable. The most common symptoms are the original System Drive showing up as missing from the storage pool, the new System Drive appearing to be Not Added, and the scrolling “Calculating sizes…” message where the usage pie charts normally reside.
I then shut down the server, removed the 750GB drive, and added it back to the eSATA storage enclosure. I followed ymboc’s instructions to read the old uniqueid from the original System Drive, and then applied it to the new System Drive. One important note: I found that I could not set the original Disk ID to the new disk, this was due to the original drive still being in my eSATA enclosure. Apparently diskpart won’t assign the same Disk ID to two drives in the system, or else it won’t display the same ID for two drives, I’m not certain which is true. Once I removed the original system drive from the eSATA enclosure I was able to successfully apply the Disk ID to the new drive.
After this completed I was ready to put the newly modified 750GB drive into the server and power it on. I have to admit to some apprehension as the system booted, and unfortunately that apprehension was justified as the system was still in a bad state similar to before I modified the uniqueid. ymboc and I discussed this, I cloned the original drive again while this time leaving the stock 20GB partition and following his resize instructions but still was unsuccessful. ymboc did some additional testing and discovered that prior to the Windows Home Server Power Packs the uniqueid was the only step needed, but with the latest Power Pack 3 this process failed.
Discouraged but not deterred, we both spent the next few days investigating and experimenting in similar directions, focused on how Windows Home Server stores data about the server drives and volumes in the Windows Registry. We identified some Volume and Disk info that was incorrect in the Storage Manager section of the Registry, and eventually ymboc made the final connection with the MountedDevices that links the C: and D: devices to their correct Volume paths. After he shared his updated process I followed it and had a successfully working system.
I’ve not run the system extensively, however I’m reasonably confident that everything is working just fine and that this is a reliable way to replace the System Drive in your Windows Home Server. While the process isn’t the full System Drive Backup that many people would like to see, it is a process that will be very handy for anyone looking to upgrade their smaller stock System Drive to a larger disk, or if you have a failing System Drive that is still working well enough to make a clone. I will remind you that this is not a process for the faint of heart, and requires a very careful attention to detail in order to be successful.
ymboc is looking for feedback from others following the process, so be sure to share your experience in his forum post or here in the comments and let us know how it goes.