If the pre-job VSS snapshot completes and doesn’t get deleted in order to free up storage during the clone, then nothing would interfere with the data involved in the clone process. If the pre-job VSS snapshot doesn’t complete or gets deleted mid-job, then the clone fails. The latter would obviously leave your destination disk unusable, but there isn’t a possibility of something surreptitiously tampering with the data Reflect is cloning while the clone is happening. Same for image backups. Otherwise it wouldn’t be advisable for ANYONE to perform these operations inside Windows. VSS has been around since Windows XP and is very widely used to perform online clones and backups, so although you are of course free to do whatever you want, cloning from Rescue truly isn’t necessary. The only exceptions would be if you’re having VSS problems, in which case you should try to solve that because VSS issues can create other problems in Windows, or if you have a third-party anti-virus solution that creates interference, but even that would only either prevent the clone from occurring or cause it to take a lot longer. It would not affect the integrity of the data being cloned. Bottom line: If your clone operations work at a reasonable speed within Windows, there’s no reason not to perform them within Windows.
Clone. I copy the partitions which contents is changed (usually Windows and data partitions, but not the DOS and Ubuntu partitions) to an identical drive (same manufacturer, same model number), so that I can quickly replace the drive in my PC in case of an emergency.
Sorry to labor the point but I assume (at some stage in the past) you have confirmed to cloned OS is bootable. How did you do the test?
The external drive is/was in an eSATA enclosure. I can boot from that. Or maybe rather: I could, as I haven’t retested lately...
Booting the cloned OS with both HDs attached to the MB can be an issue as you can mess up the drive letter assignment in the cloned OS registry and when you try to boot the cloned OS with the original drive removed from the computer, the cloned OS won't boot. The message is never boot the cloned OS unless the original HD is disconnected from the MB. Maybe that's what you did. Disconnected the original drive. That's OK.
Just a comment and maybe a question. I'm not quite sure what I did. I updated to the latest version. Then, it occured to me to create a new rescue DVD. There was a 'build' option that I could use to update since that particular menu stated that I did not have the latest version. Somehow I ended up with a Macrium boot option at the startup sequence of my computer where I could choose between booting my Windows 7 system and Macrium. That was annoying. The installation of was a default setting. Nothing I couldn't fix by restoring an image, but I don't think many people would want to have to deal with that menu each time that turn on their computer.
@Fly I've made similar mistake (thought that Build is the same as Re-Build in previous version). Luckily you can easily remove that start menu option.
Can test MR v7.2.3858 on Windows 10 v1809 build 17763.107 (New October 2018 Update). A new Win10 ISO now is available for download.
Sounds like you already fixed it the hard way, but for future reference, when you first launch Rescue Media Builder, you have to select a build "target". Those targets can be USB drives, an ISO file, or...the Windows Boot Menu entry. If you have that last one selected and you also have the "Add boot menu" radio button underneath selected, then when you click Build, Reflect will update your Rescue Media file set and create the boot menu entry. You can just as easily remove it by changing that radio button selection, at which point the Build button changes to a Remove button. As others have said though, it is a very handy option to have since it allows you to access a Rescue environment without needing "external" Rescue Media (assuming no severe hardware/file system damage), which can be handy if you just want to roll back an undesired change. You can also minimize the "inconvenience" of this option by going into MSConfig and reducing the boot menu timeout to something like 3 seconds. That's long enough to select the Rescue environment as the boot target when you need it, but not long enough to create a significant delay when booting normally.
The boot menu can be handy, if you are restoring to the same disk. I don't care for all of the new recovery image options. As all of our backups are on network drives at work, it took me 3 hours of testing to find the options that would work and allow me to access the network.
The only new one is WinRE, which often makes it more convenient because it avoids a large download and allows WiFi to work in Rescue if needed. All of the other options were already there. Prior to 7.2, they were accessed by clicking the "Change PE Version" button on the first step of the wizard. The only other difference is that 7.2 updated the WinPE 10 option to use 1709 rather than 1607, so I'm not sure why it took so much testing to get network connectivity working. All you need are network drivers, which would either be built into the WinPE/RE version you selected or would be pulled out of your host OS and added to the Rescue Media by the wizard assuming the driver in your host OS was compatible with the kernel of the PE version you selected. The only other stumbling block I'm aware of is that starting with WinPE/RE 10 1709, support for SMB1 is disabled by default because it's ancient and insecure. SMB is up to V3 by now, but if you have very old NAS hosts that require SMB1, you either need to use an older WinPE version or modify the WIM after it's built in order to re-enable SMB1. But the ideal solution would be to update/replace the NAS hosts in that case, since newer SMB versions perform much faster and are more secure. Still, I guess if you'd been using WinPE 10 for your Rescue Media in the past and just updated to 7.2, the resulting move from PE 10 1607 to 1709 would create this new issue for you.
Yes, the default changed which is why there were issues, and yes, SMB1 is an issue, but tell the boss to buy new NAS units because of a software update and don't expect to get a "Hey, that sounds great!" response. I don't mind that they added updates, just that they added updates and changed defaults without notification in the software and it took trial and error to get a working combo when before it just worked.
Aren't there any software updates for your existing NAS devices? Even SMB2 was introduced over a decade ago. How old are these NAS boxes? But if you were using PE 10, you would have received a notification that something was changing when you first tried to create 7.2 Rescue Media because you would have been prompted to download PE 10 1709 from Microsoft, since you only would have had PE 10 1607 from your 7.1 installation. As for the change to SMB specifically, technically that's a Microsoft change, not a Macrium change, and while I agree notification of changes would be nice, Microsoft has pretty well made it clear that they won't be publishing comprehensive changes anymore -- although even if they did, I suspect very few people would read them, as evidenced by the number of people who ask questions in forums that are already clearly answered in documentation, for example. But as for your boss, this practice on Microsoft's side of deprecating something but making it available via manual effort to re-enable it is typically the precursor to support being removed entirely, and that may also extend to "real" Windows rather than just WinPE/RE, so even if Rescue Media has been your only casualty thus far, you will likely find that in the near future, the impact of continuing to use SMB1 devices will increase, and the feasibility of workarounds will decrease.
Nope, no software updates available. They are new enough they should have had something else, at least as an option. They are Buffalo TeraStation units. In a desperate situation we can add more drives to the Synology RackStation, but the Buffalo units don't seem to be very well supported.
Bummer. Well fwiw, I PMed Macrium on their forums about this, because to your point, the fact that this was done by Microsoft rather than Macrium won't be obvious to Reflect users, and they might not care even if it was. From their standpoint, the end result will be that 7.1 Rescue Media was able to access their network shares, and 7.2 Rescue Media can't, unless they jump through some fairly technical hoops to force SMB1 back on or fall back to PE 5, but the latter may not always be practical for other reasons. I suggested that they at least put up a KB article about this, or better yet add an "Enable SMB1 support" option in Rescue Media Builder options when the Rescue Media will be built with WinPE/RE 10 1709 or later. Enabling that option would perform the manual re-enable tasks automatically during the build. I haven't tested whether re-enabling SMB1 is still available on WinRE 10 1809 yet since I don't have any SMB1 targets to test with, but at the very least it would fix the WinPE 10 build option, which always uses 1709. (Still though, Microsoft is really serious about getting rid of SMB1....)
Correct, Microsoft is worthy of the blame, but won't necessarily be the ones to get it in this situation. The PE 5 does work as you mentioned, and does require additional downloads unfortunately. I have over 50 TB of space on these things, they only have backup images on them, and encrypting those backups really makes it feel like there should be bigger problems with security than continuing to use these. I can understand the push to eliminate them, but I hope they don't make it too difficult for me to use them until it is time to budget in a replacement system.
In your case if the data crossing the wire is already encrypted through other means (Reflect), then I agree that the SMB1 security issues pose a much lower risk, but of course from Microsoft's perspective, the overwhelming majority of data crossing the wire on networks is not encrypted, and there is no shortage of examples of inertia in the tech industry, where product manufacturers and users don't move to newer/better technology until they're forced to, especially when it comes to security. The fact that you've got a modern NAS from an established vendor that doesn't support SMB2 even though that arrived with Vista in 2006 is a perfect example. Product vendors even today still seem not to consider security improvements as "marketable", so R&D effort tends to get focused elsewhere instead -- although in your case SMB2 also performs dramatically better, so I'd have thought they'd support it for that reason if nothing else. And that's exactly why large industry players like Microsoft, Google, etc. occasionally deprecate or completely drop support for old technologies, like SMB1, LanMan, PPTP, older versions of SSL, MD5 certificate signing, WEP Wi-Fi "security", etc. Otherwise all of those would probably still be widely used, and then when people suffered a breach because of that support, they'd rail at Microsoft saying, "Why does your modern-day OS still allow those decades-old, insecure technologies to be used when far better options that would have protected us already exist and you already support those too!?" You can't win. Anyway, I wrote this post in the Macrium forums containing the commands to enable SMB1 even on newer WinPE 1709 Rescue Media if PE 5 ever stops being a viable solution for you and Macrium doesn't end up providing a way to achieve this with a checkbox.
When building WinRE-based rescue media, there is an option on the advanced tab called "add Wi-Fi support" that can be unchecked. Are there any issues with unchecking this option? I don’t need Wi-Fi support in the rescue environment, so I would prefer not to add the Wi-Fi drivers as long as it doesn’t cause any problems.
