capture wim compatible with windows7 setup.exe

[synchronicity]

@JFX

1.9.0-BETA6 now handles the ARM64 architecture value and alternate system roots (at the top level only).

[JFX]

Thanks, Beta-6 works nice here.

There a small problem with The Version\BUILD property on WinXP.

the value of HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion, CurrentBuild is: "1.511.1 () (Obsolete data - do not use)"

CurrentBuildNumber in the same key has the correct data on WinXP, 7 and 10.

[bliblubli]

Hi,
It works to replace the install.wim on an installation media with the one from a --snapshot capture of a live system (without , sysprep, without booting another windows or linux) but it's not completely clean. For some reason, 2 folders ($Windows.~BT and LS) and one file WinPEpge.sys are left on the drive.
Applying from Linux resolves this problem, but makes the harddrive extremely slow.
Ho can I get a "live media" windows (like a linux live cd) with a command line and wimlib, to just run the apply command? It would make the whole process clean and faster.

[bliblubli]

Just to say that I used the new --snapshot option many times and it works like a charm with a winPE usb key It even works from a live system, the only thing is that it will warn on first boot that windows wasn't shut down properly. Makes happy to reinstall a clean windows in 5 minutes.
For those who want to do it:
1) wim capture c:\ d:\win.wim --snapshot
2) create a winpe usb with the windows ADK (good tutorials available on the net)
3) wim update path_to_the_winpe_dir\source\boot.wim 1 --command="add path_to_folder_with_wim.exe_and_libwim.dll Windows"
4) copy your snapshot "win.wim" to the usb key
5) boot on the usb key and:
a) Format c:\
b) wim apply path_to_your_wim c:\
Note that the path to your usb drive will depend on how many partition you have, just make some trial with cd e:, cd f:, etc... to find the drive containing your wim. By default, you will be on x:\ which is a virtual ramdisk with your winPE.
Hope it helps. It makes a clean partition without fragmentation unlike a restore from linux, so the boot time is much faster.

[synchronicity]

@JFX

In wimlib-1.9.0-BETA7 the build number should be set correctly on all versions of Windows.

[k3dar7]

@synchronicity

Although this is not technically problem(minimal for using with setup.exe), maybe before release 1.9 final can you look please to bad parsing ProductName ?

[synchronicity]

Well I'm not sure it's "wrong" just because WIMGAPI writes something else. I am reading the "ProductName" value of the Window NT CurrentVersion key in the registry, which seems like the most applicable value. I will see if there are other options though.

[JFX]

For me is perfect now

ProductName shouldn't be important.
Wimgapi/Imagex read it from the kernel32.dll.mui, so there will be almost 40 different correct values

[larsm]

So I can set all metadata of my existing wims with 'wimlib-imagex info' but '--flags'?
Maybe this is a valid workaround: 'wimlib-imagex info a.wim 1 --image-property WINDOWS/EDITIONID = "Professional"'. Is it the same as '--flags "Professional"'? It would be great to add '--flags' to 'info. Then you can use the same commands on capture and info.

[bliblubli]

After several week of test, the new snapshot option seems rocksolid. However, when doing 2 capture directly after each other, without doing anything parallel to it, the 2 one has about 80MB of changed datas. Note that even with those strange behavior, I didn't get any errors, bug or crash after several backups and restore and many hours of intensive use with different programs. So it seems to work properly despite some omited changes due to --update-of. To reproduce:
-Do a capture of c: with --snapshot on another partition than c:
- Wait for it to complete, but do nothing in the meantime
- just after it finished, run another capture with --delta-from="the first capture.wim"
1) You will get many MBs of changed datas.
2) Even stranger, if you do it from a windowsPE (so not a live system) doing this with --update-of and --delta-from doesn't give the same result as with only --delta-from. So it seem some files are modified in a way that make them unoticed by the --update-of option.