Macrium Reflect

Interesting.
The second tip, you judge, good or bad. Disable the network in WinPE by removing the folders with the network drivers from the .wim, usually two folders.

 

You‘d have to remove the drivers from both the WIM and the root of the built Rescue Media. Probably easier to just remove them from the staging folder upfront.

 

It was always enough for me to remove two folders from boot.wim\Windows\System32\DriverStore\FileRepository\, I did not remove anything from the root of the Rescue Media.

 

You could add "<EnableNetwork>false</EnableNetwork>" in an answer file as I see no point in deleting / remove network drivers as I / you might one day want to restore an image from a remote location, NAS etc.

I doubt Reflect does any sort of online checks whilst booted in a PE, so a Reflect paid user can just create the boot media on their computer and place the wim file on family members / friends computers and add an entry into the BCD, so they can boot into that for making / restoring images with all of Reflect features available.

 

Can you guide me more precisely, what kind of file is it?

 

That’s the Windows driver store. That’s supposed to be managed by DISM. But network drivers typically aren’t loaded into the WinPE/RE driver store anyway because they’re not boot-critical and also exist in two other places. The Rescue environment checks the root of all available volumes for drivers when it starts. There’s a Drivers folder at the root of the WIM image, which becomes the X drive when you boot from it, and another copy of that folder at the root of the Rescue Media itself.

 

WinPE. In the root of the Rescue Media in the \Drivers\ folder, there is only an empty Macrium.oem file of zero size.
I mounted the .wim in the \mount\ folder.
In the \mount\Drivers\ folder (root of the WIM image), there is only an empty Macrium.oem file of zero size and a SearchPaths.txt file with this content
# Enter paths to search for drivers
# Paths and sub-folders will be searched
# Use UNC paths for network shares
#
# e.g. \\server\share\drivers\
#
# Comment lines begin with #
#
The drivers are only here \mount\Windows\System32\DriverStore\FileRepository\, I have done this operation many times with different versions and always get the required result - the network icon is gray, no ping, network is disabled.

 

See here - https://serverfault.com/questions/866479/disable-network-connection-in-windows-pe/

Answer files are great especially if you've got the misfortune of reinstalling Windows for family members.

 

Ok, then it sounds like you're removing network drivers that are native to the WinPE/RE kernel you're using, since Reflect doesn't seem to be adding any network drivers to the build.

 

Thank. Very interesting, I will study it.

 

Made it easy, I checked with Paragon Hard Disk Manager WinPE on an x64 system. The unattend.xml file content is different for x64 and x86 computers, does it mean that when I boot on the x64 system there will be no network, but when I boot on the x86 system there will be a network?

 

The XML file should vary based on the architecture of the WinPE/RE environment you’re building, not the architecture of the system it’s running on. So if for some reason you needed x86 support, you could build a WinPE x86 environment with networking disabled, and that should be respected even on x64 hardware that would be running in x86 mode in that scenario. But who really needs x86 anymore? I’m pretty sure x86 support was dropped for Win11, and in the server world it was dropped as of Server 2008 R2 (Win7 kernel).

 

I always cut the cord from networking when making backup images and here is why. Microsoft (at least for me) has an uncanny knack for interruption of my backups or at the least stressing my backup program (slowing it down) when it's operationally doing it's routine when they have an open network forthwith installing a pile of files nonstop i guess as part of their updating certain internals and that reeks havoc and slows my backup progress. I caught on to that and now disconnect internet whenever doing mine.

 

Interesting, I never unplug from network when backing up or restoring. Have done hundreds of this routine without a single hitch. Macrium has always done great job.

 

I agree, I just want to add to my knowledge. Thanks for the reply.
Is it possible to determine the bitness of WinPE only by determining the bitness of an .exe from boot.wim, or is there an easier way?

On the contrary, I never disable the network when I create an image under Windows, as the firewall is working and nothing can get onto the network uncontrollably. I do not observe any slowdowns or brakes.
To disconnect/connect the network instead of pulling the cable, I use two batch files, which are run by shortcuts.

 

That's good of an alternative for you and works to satisfaction. But yeah i knock out any chances of interruptions by cutting network off.

 

DISM /Get-WimInfo /WimFile:C:\WIM\MyWIMFile.wim /index:1

Look at the Architecture field you’ll see in the output. You’ll also see a lot of other useful information, including the WinPE/RE kernel version. And if it were a WIM image for full Windows, you’d be able to see the edition as well.

 

Utilize DISM a good deal on this end- Multiple uses- Great that your reply assist makes mention of it (and command string) for the question.

 

As I wrote above, using unattend.xml, I was able to disable the network in Paragon WinPE. But using the same unattend.xml, I could not disable the network in Macrium WinPE. Checked several times, made several attempts

Thank for tip, it works.

 

Found this topic, but it does not offer any solutions
https://forum.macrium.com/59533/Ability-to-disable-networking-in-WinPE-mode

 

Net Disabler Portable runs in the WinPE environment https://www.sordum.org/9660/net-disabler-v1-1/

 

Bug fixes and Improvements v8.0.7097 - 31st October 2022

Note: The latest update can be skipped if it doesn't apply to your installation or usage.
Please see here

From the UI.

 

This was hit and miss as far as it wanting a reboot. Most of them did.

 

Yeah, Reflect updates can be a little strange that way. I've had an update on one machine which required a restart, but the same update on my other machine did not need a restart.

 

A reboot was required on my end. Gladly done because Macrium is a proven life saver.