Resue media has wrong drive letters


Author
Message
MysteryGuy
MysteryGuy
New Member
New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)
Group: Forum Members
Posts: 29, Visits: 74
I recently installed Macrium Reflect 7.2.3957 on a Windows 10 (1803) system with multiple physical disks. I created WinRE rescue media and initially everything seemed to work out o.k.. The various drives showed the same logical drive letters in both the normal Windows 10 environment and the UEFI booted WinRE USB drive environment.

I then encrypted my drives with Bitlocker. I created new Windows RE media with auto-unlock of bitlocker drives.

Rebooting into the Windows RE USB media, the drive letters no longer match in the two environments. The MAC-WIN-1 and MAC-WIN-2.jpg files show the drive letter arrangement under regular Windows 10.

MAC-RE-1 and MAC-RE-2.jpg show the drive letter assignments after booting Windows RE rescue media under UEFI.

For example, my 'C' drive on drive 5 shows as 'C:' in Windows. In the Windows RE environment Drive 5 shows as 'F:'.

Any idea why the drive letters would change after bitlocker encrypting the drives? Is this going to be a problem?

As I mentioned I believe that the drive letters in both environments matched before I encrypted most of them with Bitlocker.

The only somewhat unusual thing is that 'GPT DIsk 3' is split into two logical drives and only the 'G:' partition is Bitlocker encrypted.

Any way to fix this?

Thanks;


Attachments
MAC-WIN-1.jpg (4 views, 294.00 KB)
MAC-WIN-2.jpg (2 views, 285.00 KB)
MAC-RE-1.jpg (7 views, 1.00 MB)
MAC-RE-2.jpg (5 views, 1.00 MB)
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (6.2K reputation)Macrium Evangelist (6.2K reputation)Macrium Evangelist (6.2K reputation)Macrium Evangelist (6.2K reputation)Macrium Evangelist (6.2K reputation)Macrium Evangelist (6.2K reputation)Macrium Evangelist (6.2K reputation)Macrium Evangelist (6.2K reputation)Macrium Evangelist (6.2K reputation)
Group: Forum Members
Posts: 4.3K, Visits: 31K
Reflect does embed some info into Rescue Media to help achieve drive letter consistency between Windows and Rescue (with regular Windows PE, it's normal for your drive letters to be all over the place), but it doesn't always work, and being a BitLocker user myself, I've noticed the inconsistency quite a bit too.  My guess as to why BitLocker affects things is that drive letters get assigned before partitions unlock, and the info Reflect embeds into Rescue Media to "match" known partitions to known drive letters isn't usable while partitions are still locked, so it's too late by the time they're unlocked.  However, drive letters are arbitrary and only exist while a given instance of Windows or Windows PE/RE is running.  When you switch back to "real" Windows, the partition that the system booted from will always be C, and Windows will still remember the drive letters that it (or you) last assigned to any other partitions.  Worst case, if you make a significant change to your disks in Rescue, Windows might not recognize it anymore and therefore might assign a different drive letter than you expected, but you can fix that quickly in Disk Management.  Just obviously make sure that when performing operations within Reflect (or Command Prompt in Rescue), you're targeting the partition you actually mean to be rather than thinking in terms of drive letters.

In terms of BitLocker on GPT Disk 3, BitLocker is a partition-level encryption solution, not a disk-level encryption solution.  So if you want to encrypt the second partition, you can do so, but it's normal that you would have to enable that separately.  And of course you'll need to back up a separate Recovery Key for it.

On a side note, the GPT GUIDs you obscured on GPT Disks 3 and 5 aren't sensitive info.  Those are randomly generated whenever a disk is initialized with a GPT partition layout, just like the much shorter hex strings next to the MBR disk listings that you left in the clear.  And I believe the other portion was the serial number of the hard drive?  That's not particularly sensitive either.  Not that they're necessary to see for these purposes of course, but there's no need to take time obscuring them either.

Edited 1 February 2019 3:21 PM by jphughan
MysteryGuy
MysteryGuy
New Member
New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)
Group: Forum Members
Posts: 29, Visits: 74
jphughan - 1 February 2019 3:19 PM
Reflect does embed some info into Rescue Media to help achieve drive letter consistency between Windows and Rescue (with regular Windows PE, it's normal for your drive letters to be all over the place), but it doesn't always work, and being a BitLocker user myself, I've noticed the inconsistency quite a bit too.  My guess as to why BitLocker affects things is that drive letters get assigned before partitions unlock, and the info Reflect embeds into Rescue Media to "match" known partitions to known drive letters isn't usable while partitions are still locked, so it's too late by the time they're unlocked.  However, drive letters are arbitrary and only exist while a given instance of Windows or Windows PE/RE is running.  When you switch back to "real" Windows, the partition that the system booted from will always be C, and Windows will still remember the drive letters that it (or you) last assigned to any other partitions.  Worst case, if you make a significant change to your disks in Rescue, Windows might not recognize it anymore and therefore might assign a different drive letter than you expected, but you can fix that quickly in Disk Management.  Just obviously make sure that when performing operations within Reflect (or Command Prompt in Rescue), you're targeting the partition you actually mean to be rather than thinking in terms of drive letters.
...

It sounds like this mismatch when using bitlocker encrypted drives is expected. (I was wondering if I needed to somehow force the media builder to start over from scratch since it previously built something before the drives were 'bitlockered'.).

Does this drive letter mismatch cause any problems (in and of itself) if I were to do something like restore my C: partition (which it thinks is F: in that environment)?

Also, I'm under the impression that the drive letter assignments are changeable after WINPE/RE boot if I were to manually mess around in DISKPART. (Although I haven't actually tried it to see if it worked and if it specifically worked with bitlocker drives).

If so, then it would seem as though it should be possible for Reflect to take a stab at 'fixing up' things after the bitlocker unlocking was complete (if it got them wrong earlier).

Edited 1 February 2019 4:12 PM by MysteryGuy
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (6.2K reputation)Macrium Evangelist (6.2K reputation)Macrium Evangelist (6.2K reputation)Macrium Evangelist (6.2K reputation)Macrium Evangelist (6.2K reputation)Macrium Evangelist (6.2K reputation)Macrium Evangelist (6.2K reputation)Macrium Evangelist (6.2K reputation)Macrium Evangelist (6.2K reputation)
Group: Forum Members
Posts: 4.3K, Visits: 31K
No, restoring your Windows partition won't be a problem even if it's drive F at the time.  First of all, the partition loses its drive letter when Reflect takes it offline for restore anyway, so it doesn't matter what it was at the beginning of the restore, and second of all as I said earlier, Windows always assigns letter C to the partition it boots from, so that one will always be correct in "real" Windows.  Partitions don't get "tagged" with drive letters, so the assignments made by one environment will not affect another.  Reflect is an exception because it specifically tries to achieve drive letter parity in some cases, but that's one-way, i.e. trying to make Rescue match Windows.  But real Windows will never end up trying to match what happened in Rescue.

Yes, I suppose it would theoretically be possible to have Reflect go auto-unlock whatever partitions it can and then go back and re-evaluate drive letters afterward, but even that wouldn't be a perfect solution.  As just one example, some people don't like embedding auto-unlock keys into their Rescue Media for security reasons (myself included), so they'll have to manually unlock them using Command Prompt anyway, which means Reflect wouldn't be able to do anything about those unless it continuously monitored for manual partition unlocks and messed with drive letters after each one, but I personally don't think that would be a good idea.  Suppose the correct drive letter for that newly unlocked partition had already been assigned to an external flash drive you had connected -- should Reflect try to assign that drive a new drive letter just to free it up for the partition that "should" have that one?  And then as with any functionality, there's a more fundamental question of whether the value justifies the amount of upfront development effort it would require as well as the potential maintenance if the implementation contains bugs or creates other side effects.  I personally don't think drive letter parity is that important in the Rescue environment.  Again, most people use Rescue to restore partitions, at which point the originally assigned drive letter no longer matters, although I admit I may be biased since I maintain this Wish List thread that contains a long list of features I think would be nice to have in Reflect (many of which were originally suggested by others).

Edited 1 February 2019 4:36 PM by jphughan
GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Similar Topics

Reading This Topic

Login

Explore
Messages
Mentions
Search