UUP to ISO - Create Bootable ISO from Windows 10 Build Upgrade Files  

slicendice said:

I really don't think this is a bug. I have a feeling MS is experimenting with even better file compression for smaller delivery sizes. This is why I will continue to try to work out a long term solution for this.

I am convinced this is a bug, the same that we had in 15025 upgrade. I mean, a 10 GB download size can't be right.

I is not a 10GB download size, the download took me 5 minutes. But the files gets locally expanded, thus big size.

EDIT: I know this because I monitored the download folders during the update process.

EDIT2: Based on the ActionList.xml for Build 15042 and Build 15046 the download size were following:

• Build 15042
  
  • 2812282554 bytes
  
  
• Build 15046
  
  • 520601464 bytes

That is only 18.5% in size for the "buggy" download vs the normal UUP-ESD download.
You still think it is a bug?

This is what my XMLParser experiment spits out currently:



EDIT: the first one is the 15042 ActionList and the second one is the 15046. Both are UUP downloads

Something seems to have improved:
===============================================================================
Convert CAB > ESD . . .
===============================================================================




===============================================================================
Creating Setup Media Layout . . .
===============================================================================




===============================================================================
Creating boot.wim . . .
===============================================================================


Using LZX compression with 2 threads
Archiving file data: 890 MiB of 890 MiB (100%) done


===============================================================================
Creating install.wim . . .
===============================================================================


Using LZX compression with 2 threads
Archiving file data: 7120 MiB of 7120 MiB (100%) done


===============================================================================
Adding winre.wim to install.wim . . .
===============================================================================




===============================================================================
Creating ISO . . .
===============================================================================


OSCDIMG 2.56 CD-ROM and DVD-ROM Premastering Utility
Copyright (C) Microsoft, 1993-2012. All rights reserved.
Licensed only for producing Microsoft authorized content.




Scanning source tree (1500 files in 54 directories)
Scanning source tree complete (1707 files in 99 directories)


Computing directory information complete


Image file is 4105633792 bytes (before optimization)


Writing 1707 files in 99 directories to 15046.0.170224-1700.RS2_RELEASE_CLIENTPRO_OEMRET_X64FRE_EN-GB.ISO


100% complete


Storage optimization saved 18 files, 133120 bytes (0% of image)


After optimization, image file is 4109234176 bytes
Space saved because of embedding, sparseness or optimization = 133120


Done.


Press any key to exit.

Exactly! Well Done!

slicendice said:

I DID IT!
Manually created esd files from the package folders:
STEP1: Processed ActionList.XML:
STEP2: Created a bunch of commands:
STEP3: Ran the commands one by one (sry no screenshot)
STEP4: Ran uup2iso as usually
RESULTS:
Converted these
to this
Created ISO
Mounting ISO

Looking at the Wim-files
Everything looks normal! Now we have to automate this! :-D

Great work! I replicated this approach, using DISM to create the ESD files, and have also installed the resulting ISO in a Hyper-V VM. I could not even copy the Download subfolder elsewhere previously, as I always got a PATH too long error when using File Explorer. I did manage to 7-Zip the entire thing but could not extract the files anywhere, due to the same PATH too long error.

The clean install from ISO ran without error and the resulting Windows install also passes sfc /scannow.

---

EDIT: I don't know scripting, but after reading a couple of command line help screens, I came up with this one-liner which will create the ESD files from all folders beginning with "amd":

Code:

@echo off
FOR /D %%a IN (amd*) DO DISM /Capture-Image /Compress:max /ImageFile:%%a.ESD /CaptureDir:%%a /Name:%%a /Description:%%a

EDIT: I was missing one slash in the code above earlier, so I have added it in now.

DonCuthbert said:

Great work! I replicated this approach, using DISM to create the ESD files, and have also installed the resulting ISO in a Hyper-V VM. I could not even copy the Download subfolder elsewhere previously, as I always got a PATH too long error when using File Explorer. I did manage to 7-Zip the entire thing but could not extract the files anywhere, due to the same PATH too long error.

The clean install from ISO ran without error and the resulting Windows install also passes sfc /scannow.

---

EDIT: I don't know scripting, but after reading a couple of command line help screens, I came up with this one-liner which will create the ESD files from all folders beginning with "amd":

Code:

@echo off
FOR /D %%a IN (amd*) DO DISM /Capture-Image /Compress:max ImageFile:%%a.ESD /CaptureDir:%%a /Name:%%a /Description:%%a

Awesome, that someone actually tested this and verified it works.

I love that scripting one-liner, that could be the thing we need, but we need to also consider 32-bit Windows. I like to process the xml-files, because there are all the data we need, I just can't wrap my head around shell scripting for this part. This is why I am working on a .NET assembly in C#.

DonCuthbert said:

I expect that the original authors of UUPtoISO will find it relatively easy to adapt to the changes. I was just trying to find a way to test it and curious if I could do it all with DISM instead of wimlib-imagex.

It sounds like this is the beginning of "differential download packages", as mentioned in this blog post:
An update on our Unified Update Platform (UUP) - Windows Experience Blog

What ends up in the SoftwareDistribution subfolder appears to be a compilation of files that were downloaded by Windows Update and files from our existing OS build (that were unchanged in the new build). That is why it becomes so much larger than what was downloaded.

This could mean that once UUP is giving a different download to each device (which appears to be as of now, with build 15046) an ISO can still be successfully built from the results, as you have discovered.

I was working with the files from C:\Windows.old\Windows\SoftwareDistribution\Download\[hex folder name]. That is where all the UUP files end up after a successful UUP upgrade.

Great that you tried the DISM method. It is always good to stick to MS default tools.

Yes, I agree that all these updates are moving towards differential updates. This is why it is imperative to be able to process the XML-files. All information is there. If the required files for updates are not located in the HEX-folder, then they are scattered all around the HDD in Windows folder and the XML-files will help located the required files for building a proper ISO.

The Windows.old usually still has the upgrade files after upgrade, but sometimes the update process cleans up the HEX-folder after it's completed, and everything is gone. This is why I always backup the HEX-folder, just in case, before hitting reboot.

Wimlib-imagex.exe is a renamed open source version of imagex.exe, which was the original imaging tool for creating and handling .Wim files. Since it is open source, you can rename it back to Imagex for your own use! wimlib - Main page

Generally DISM has an unnecessarily long-winded syntax, often requiring the console to be widened to see the command on a single line, with a lot of hyphenated switches. Why "apply-image" instead of just "apply", for instance?

Since MS Imagex predated DISM for the handling of Windows image format files I am hard put to understand why the imagex syntax was not adopted when these imaging functions were included in DISM in the early days of Windows 8