I thought about that, but the partition numbering in Reflect's view always matches diskpart's, even when the partitions are not numbered sequentially from left to right. I once had a disk where the partition numbers were 1, 2, 3, 5, 4 because I had shrunk Partition 3 to make space for Partition 5. Reflect's view showed them numbered that way, not 1-5 left to right. And Beethoven's Reflect screenshot shows that Partition 2 is the Windows partition.
Hi Brian. As your post is related to this, I'll ask this question. In TBOSDT, when I type this: Code: list hd 0 /f /u /w Why would I get the message, "Invalid Drive"? I am not concerned about it. Just curious. When I type the above Diskpart commands, I can see that it it drive 0.
JP, You are correct. The numbers in Macrium are the MBR slot numbers, not the physical partition order. Just checked.
Thanks. As JP said, your recovery files are in the Win10 partition. Mine are too... Can you check winre.wim , its date and size? From an Admin command prompt... Code: dir /a C:\Recovery\WindowsRE You should see winre.wim along with ReAgent.xml and boot.sdi
And then look at winre.wim in the Recovery partition... Open BIBM, Partition Work Drive 0 Select the RE partition Edit File Recovery (press Enter) WindowsRE (press Enter) you should now see Winre.wim and 2 other files Size and date of winre.wim?
Brian, as usual you are quite correct. I did the checking above both ways and the results are as you expected. I am just not sure what that means for my imaging with Macrium. Also, what would I need to image in IfW?
beethoven, Were both winre.wim the same? I think it's good news. The RE in your Win10 is enabled so you don't need the Recovery partition. I'd delete it and you only need to image the Win10 partition. You will then have a spare MBR slot for another partition. eg TBWinRE, IFL, Macrium?
The downside to the approach above is that if there's ever an issue that renders the Windows partition unreadable, then you've lost the Recovery partition as well. And that design wouldn't be workable at all for anyone who wanted the ability to use BitLocker. Then again, I doubt many regular Reflect users will ever really need the Recovery partition anyway, so it might be moot. I'm not sure I'd recommend deleting the Recovery partition though. Since that's Partition #1, I believe that will affect the numbering of the other partitions, in which case the RE path might break -- if you care about it at all -- but I'm not 100% sure on that. I actually didn't even realize Windows allowed you to set up the WinRE path to be on the Windows partition. Did you do that manually, Beethoven?
Actually, checking carefully the details are not the same. On my "live" system the size is 443.717.121 and date 10/1/20 while when using BIBM the size is 436.996.799 with a date of 19/2/20
JP, I will leave the recovery partition in place as I don't need that space atm. As for changing the path, I must have done that during the installation of BIBM and splitting the original partition in two, though honestly I don't remember the details. Maybe Brian has a clearer view on that.
beethoven, It would be interesting to run reagentc /info from your second Win10 OS. Does it say partition 1 or 4? Partition 4 refers to the 4th MBR slot which is actually the third physical partition on your drive. The second Win10. Those of us who played with WinXP should remember... You saw this error when boot.ini on the active partition was pointing to a non bootable partition. In this line... multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /fastdetect partition(1) refers to the partition in the first MBR slot. Not the first physical partition on the drive. So if you saw the hal.dll error on booting you had two choices to enable WinXP to boot... Edit boot.ini to the MBR slot number of WinXP or Move WinXP into the first MBR slot.
Brian, I do remember now some errors preventing the win7 partition to be bootable as planned. However I had forgotten that I had left it there last time, taking a break, so was surprised last night when I could not boot to the alternate partition. Then I realised that I had never installed the Win 10 partition after giving up on Win 7, so for the last reagent test, I need to do that first. Don't think I have time for that today though.
Mostly to tinker, I decided to shrink the WIM file on my own system's Windows Recovery partition. Reflect was showing that partition in red on my system too now, and I also noticed that a fresh install of Win10 2004 results in a significantly smaller WIM file than I currently had. I knew from prior experience that WIM files can bloat beyond what's needed to store their data if they get modified in-place, and I also knew that the WinRE WIM file does get modified in-place. Windows feature releases update it, and apparently it can get modified during driver installations, since one of my systems has a Winre.wim file that contains its Synaptics touchpad driver package, including the few hundred MB worth of video animations to demonstrate multi-touch gestures. But it's also possible to export the contents of a WIM file into a new one, in which case the bloat gets left behind because the new one is essentially "compacted". So I copied the WinRE.wim file from my Recovery partition to C:\WIM, then ran the following in an elevated Command Prompt: dism /Export-Image /SourceImageFile:c:\wim\winre.wim /SourceIndex:1 /DestinationImageFile:c:\wim\winre2.wim The new WIM file was over 100 MB smaller, even though it contained exactly the same data. Then I deleted the Winre.wim file on the Recovery partition, copied the new WIM file there, and changed its name back. (Steps omitted above included temporarily assigning the Recovery partition a drive letter, using the "attrib" command to remove the system and hidden attributes from the Winre.wim file on the Recovery partition for simplicity, then adding them back to the replacement WIM I copied back onto the Recovery partition, then removing the drive letter.)
Bug fixes and Improvements v7.2.4884 - 9th May 2020 Email Notifications Some customers have reported that Reflect notification emails have been rejected by their email service providers. This has been resolved.
I have encountered a strange problem with v7.2. It had been executing its scheduled backups for over a year very efficiently (where a typical incremental backup ran for about a minute or two) ...that is until this week. Now it takes hours to make an incremental backup of my C-drive (even when there has not been any notable changes), spending almost all of that time 'Determining files to copy'. Earlier this week (right before experiencing this problem) I decided to 'skin' my desktop by installing Winstep Xtreme, so maybe that's causing the problem? Without suggesting I uninstall Winstep Xtreme, which I really like, I would appreciate any other advice as to how I should go about troubleshooting this MR problem.
Did you recently update? If so, what version were you running before? The reason I ask is that the Reflect 7.2.4797 update included a note that the first Incremental created after the update could take much longer than normal because Macrium had changed something. I believe -- but am not certain -- that technically it was the first Incremental created in each set after that update, so for example if you have a disk rotation, then the first post-update Incremental created on each destination would take quite a while. Or you can work around it by just creating a new Full.
Given that one of these changes applies to ReDeploy, it's strange that Macrium didn't add the red text "Rebuild your Rescue Media after updating if you care about this change" note.
Thanks for the reply. I'm not one to update every time a new build is released so I'm still on v7.2.4063 as it was working perfectly for me until this past week. So unless you know of a good reason for me to update my version, I'll just try creating a new backup schedule and see how that goes.
Updated to 7.2.4942 as well as the bootable rescue media. Backup and restore performed normally here, however I've noticed that usually my incremental daily backup would take between 50 - 70 seconds with hardly any changes, but after the last 2 updates it takes almost 2 minutes with the same interval and few changes. Not an issue by all means, but I would expect new versions to to be faster than slower...It is also possible that it might be due to my version of Windows 10 that is v. 2004 build 19041.264