The problem is that after restoring the PC from a disk image, I am able to see the recovery partition (with ID 27) in "This PC", which should not happen. Before restoring the PC I have removed the drive letter to the recovery partition with DISKPART.
The question is: how do I prevent Windows from reassigning a letter to the recovery partition after restoring the PC from disk image?
Edit:
I have Windows 10 (64-bit) version 1903 (May 2019 Update) (clean install).
I don't want to have to remove the drive letter after the restore, I want instead that Windows doesn't assign it after the restore.
I have a MBR disk with an Standard BIOS that even in the last supported update doesn't implement the support for GPT disks. In any case, I could only convert basic MBR disks without any partitions or volumes into a GPT disk, making data backup operations difficult.
The GUID method doesn't work because i have an MBR disk.
SET ID=de94bba4-06d1-4d40-a16a-bfd50179d6ac
and therefore neither:
gpt attributes=0x8000000000000001
For me works only:
attributes volume set nodefaultdriveletter
But in this case Windows 10 continues to assign a drive letter to the recovery partition after the system restore, therefore it doesn't have the desired effects.
I have used the Windows 10 built-in "Backup and Restore (Windows 7)" to create the image only of the "C" partition and for the restore I have used the procedure on the Windows 10 version 1903 (May 2019 Update) installation CD downloaded from the official website. I don't think that this procedure changes the attributes of the recovery partition but I can't verify it with DISKPART because I don't have a GPT disk but I was able to verify that the "nodefaultdriveletter" attribute is remained even after that the system was restored, however Windows has anyway reassigned the drive letter to the recovery partition.
I backed up on the recovery partition when it still had a letter, otherwise it wouldn't have been seen by the Windows 10 utility "Backup and Restore (Windows 7)".
In my MBR disk I have tested that a logical recovery partition that is located within of an extended partition and a primary recovery partition have the same behavior.
Last edit:
The startup task method may not always work because the volume number of the recovery partition can change depending on the devices connected at the time of the restore and is also useless to identify a volume based on some features, because there can be multiple volumes with the same characteristics and volumes can have the same label even within of a single disk. Since I have an MBR disk, the partitions cannot be uniquely identified thanks to the GUID. In other words, this isn't the solution.
I have read the release notes of the BIOS updates for my motherboard on the official Fujitsu website and none of the updates have GPT disk support implemented. The latest BIOS version supported by my motherboard (FUJITSU D3011-A1) is the V6.00 Release R1.06.3011.A1 (Phoenix SecureCore(tm) Setup Utility).