E
e_web
Guest
I recently decided to "Merge" some older versions of Windows 10 WIMs [Started my tests using NTLite 1.9.0.7455 if that matters and I did re-test some aspects using the latest non beta version but honestly not as fully] (including 1809 LTSC + 1809 Consumer + 1809 VL) from inside the ISOs (eg just exporting each entry to the same new wim) I had in order to try and save some space with the mostly redundant images (eg consolidate them).
It was partially successful. The WIM gets created and without an autounattend.xml being used all seems well at first glance.
However if you try to use the autounattend.xml to define a specific version where there are multiple versions containing the same <NAME></NAME> of it in an ISO then setup ends up requiring manual input (potentially an issue in larger environments, less so for me but I still found it annoying enough to look into)
Priority Notice...all examples below are based off the same merged WIM, only difference is that one tries to use an autounattend.xml and the other does NOT.
Example...I have the vanilla "Windows 10 Enterprise LTSC" merged into a WIM alongside a custom version I had created "Windows 10 Enterprise LTSC w Photos" (also happened to be the first one I exported and is shown in the autounattend_fail image) that if you can't guess is a version of "Windows 10 Enterprise LTSC 2019" where I had inserted the files/registry entries/permissions needed for the AppX Photos package to get installed and even show up with dism etc [gathered from a normal 1809 ENT as I still don't use Store and thus wouldn't update Photos through it but still wanted to use it instead of the old dllhost.exe based viewer I never trusted and cringe upon reading 'restoration' blogs about - I know I could just grab a more recent version (and its dependencies) then install it using powershell but I find the old version is less bloated and works fine so I did it this way and I ended up here
] just like in a normal non-LTSC version
View attachment 4080
In this case the autounattend.xml then [fails isn't the right word?], stalls, as it can't differentiate between the two versions and setup requires that someone tell it which one to use from a list. (as shown above)
As it happens both retain the original<NAME>Windows 10 Enterprise LTSC 2019</NAME> despite the edits with NTLite!
Without an autounattend.xml existing and intended to point setup at the 'w Photos' version I get the normal expected list of options (and they also seem to work as intended) in the merged WIM
View attachment 4081
but trying to make alterations that allow an autounattend.xml to use the 'w photos' version fails via NTLite. Heck I even tried changing the Edition name of the intended entry to a brand spanking new (nonexistent) one. The root issue seems to be that <NAME></NAME> is NEVER changed by editing any of the NTLite context options and yet this, ultimately, seems to be what's finally used when comparing via entires in the autountattend.xml in such a scenario. Editing this (eg updating the entry for <NAME></NAME>) outside of NTLite to mirror the other/expected name resulted in the autounattend.xml working as originally expected and not needing any extra manual input to continue with the setup!
If you want to reproduce this on your side you can use *any* edition/name and substitute changes as desired so long as they are consistent.
eg if you Export the first edition to a new file there is no [1].xml inside the WIM (and that's OK)
But if you then edit the Name of the original/same one (that you just exported) to something else then export but APPEND it to the same wim as we first exported to aka 'NO' the newly merged WIM DOES have a [1].xml!
Even without altering the image itself you can test it by changing all three (currently) available context options in NTLite (2.0.0.7656 and earlier) Source list entry > Right Click on it > Edit
Name
Description
Flag
altering them all to the new entry
eg my case after changing
Name will change <DISPLAYNAME></DISPLAYNAME>
Description will change <DISPLAYDESCRIPTION></DISPLAYDESCRIPTION> & <DESCRIPTION></DESCRIPTION>
Flag will change <FLAGS></FLAGS>
Some older NTlite versions didn't even get this much right but thankfully I retested it with v2.0.0.7656 [non-beta] before posting here...and it does now seem those 3 done as expected.... [but I haven't tested or used NTLite much recently]
Yet the <NAME></NAME> entries inside the wim still remain virgin/unchanged (and as such can exist as duplicates)! It's at this point windows setup can't figure out which version it's meant to use via autounattend.xml even if I already specifically told it to use <Value>Windows 10 Enterprise LTSC w Photos</Value> instead of <Value>Windows 10 Enterprise LTSC</Value> because they both retain the same <NAME></NAME> entry inside the [1].xml!
Maybe I simply missed something in my scenario for which you thought you already accounted for but even if so there seems to be a case where it can still fail to be handled /shrug
Maybe you could add an 'InstallFrom" value to edit for instances like this to the context options in NTLite?
I realize that it's not one of the more standard cases but here we are talking about a piece of software designed to be useful to those people who don't care to settle for Windblows 'normal'... :-/
I came across it..it bugged me...I looked into it...figured out what wasn't working the way *I thought* it should and so here we are...with you reading my latest drunken thread.
To further clarify this is the section taken from the autounattend.xml in question as related to the examples above that only worked after editing the <NAME></NAME> in that particular WIM entry outside of NTLite.
In short <NAME></NAME>&<DISPLAYNAME></DISPLAYNAME> should get changed together just like <DESCRIPTION></DESCRIPTION> & <DISPLAYDESCRIPTION></DISPLAYDESCRIPTION> now do....
On the (almost) same subject, can I suggest that in the export options for WIMs\ESDs you change some things...like perhaps change the 'No' button to 'Append' instead of just relying on the user to read the above text then hit 'No' to append. I mean come on, in what world is Cancel/Abort not also a negative aka 'No' in a query for that operation to a 'normal user'? Obviously if you changed any buttons you'd also want to change the text displayed above the options to reflect it.....Heck change 'Yes' to 'Overwrite' while you are at it and maybe you could end up with something like this:
"Choose 'Overwrite' to DELETE the existing file and save a new file containing only the currently exported one!!!! Choose 'Append' to ADD this to an already existing file!! Choose 'Cancel' to ABORT this operation and do nothing!"
Then you could have "Overwrite" "Append" and "Cancel" as buttons instead.
To me it seems that such changes could prevent potential confusion and the query would also be easier to answer without a 'real need' for a user to first read the text above it simply to select the option appropriate for what they initially intended.
I can't pretend to understand why it was needed to edit that entry along with the others....I only know that with two editions of the same in one WIM it does seem to be needed in order to not require manual input alongside an autounattend.xml meant to define which to install anyway.
UPDATE: After sorting out and posting all the above I finally got around to adding the x86 versions of the same build (I haven't yet gotten so far as to figure out how to ensure the boot ISO can operate as intended for both x64 & x86) to the merged WIM and I now see the same issue cropping up with the x86 and x64 versions having the same <NAME> entries in the xml and so I assume autounattend (untested) would still fail here as I suspect they'd end up having the same issue as described above [at least on a x64 system, unsure about x86 at this point]. One step at a time though I guess...
It was partially successful. The WIM gets created and without an autounattend.xml being used all seems well at first glance.
However if you try to use the autounattend.xml to define a specific version where there are multiple versions containing the same <NAME></NAME> of it in an ISO then setup ends up requiring manual input (potentially an issue in larger environments, less so for me but I still found it annoying enough to look into)
Priority Notice...all examples below are based off the same merged WIM, only difference is that one tries to use an autounattend.xml and the other does NOT.
Example...I have the vanilla "Windows 10 Enterprise LTSC" merged into a WIM alongside a custom version I had created "Windows 10 Enterprise LTSC w Photos" (also happened to be the first one I exported and is shown in the autounattend_fail image) that if you can't guess is a version of "Windows 10 Enterprise LTSC 2019" where I had inserted the files/registry entries/permissions needed for the AppX Photos package to get installed and even show up with dism etc [gathered from a normal 1809 ENT as I still don't use Store and thus wouldn't update Photos through it but still wanted to use it instead of the old dllhost.exe based viewer I never trusted and cringe upon reading 'restoration' blogs about - I know I could just grab a more recent version (and its dependencies) then install it using powershell but I find the old version is less bloated and works fine so I did it this way and I ended up here
] just like in a normal non-LTSC versionView attachment 4080
In this case the autounattend.xml then [fails isn't the right word?], stalls, as it can't differentiate between the two versions and setup requires that someone tell it which one to use from a list. (as shown above)
As it happens both retain the original<NAME>Windows 10 Enterprise LTSC 2019</NAME> despite the edits with NTLite!
Without an autounattend.xml existing and intended to point setup at the 'w Photos' version I get the normal expected list of options (and they also seem to work as intended) in the merged WIM
View attachment 4081
but trying to make alterations that allow an autounattend.xml to use the 'w photos' version fails via NTLite. Heck I even tried changing the Edition name of the intended entry to a brand spanking new (nonexistent) one. The root issue seems to be that <NAME></NAME> is NEVER changed by editing any of the NTLite context options and yet this, ultimately, seems to be what's finally used when comparing via entires in the autountattend.xml in such a scenario. Editing this (eg updating the entry for <NAME></NAME>) outside of NTLite to mirror the other/expected name resulted in the autounattend.xml working as originally expected and not needing any extra manual input to continue with the setup!
If you want to reproduce this on your side you can use *any* edition/name and substitute changes as desired so long as they are consistent.
eg if you Export the first edition to a new file there is no [1].xml inside the WIM (and that's OK)
But if you then edit the Name of the original/same one (that you just exported) to something else then export but APPEND it to the same wim as we first exported to aka 'NO' the newly merged WIM DOES have a [1].xml!
Even without altering the image itself you can test it by changing all three (currently) available context options in NTLite (2.0.0.7656 and earlier) Source list entry > Right Click on it > Edit
Name
Description
Flag
altering them all to the new entry
eg my case after changing
Name will change <DISPLAYNAME></DISPLAYNAME>
Description will change <DISPLAYDESCRIPTION></DISPLAYDESCRIPTION> & <DESCRIPTION></DESCRIPTION>
Flag will change <FLAGS></FLAGS>
Some older NTlite versions didn't even get this much right but thankfully I retested it with v2.0.0.7656 [non-beta] before posting here...and it does now seem those 3 done as expected.... [but I haven't tested or used NTLite much recently]
Yet the <NAME></NAME> entries inside the wim still remain virgin/unchanged (and as such can exist as duplicates)! It's at this point windows setup can't figure out which version it's meant to use via autounattend.xml even if I already specifically told it to use <Value>Windows 10 Enterprise LTSC w Photos</Value> instead of <Value>Windows 10 Enterprise LTSC</Value> because they both retain the same <NAME></NAME> entry inside the [1].xml!
Maybe I simply missed something in my scenario for which you thought you already accounted for but even if so there seems to be a case where it can still fail to be handled /shrug
Maybe you could add an 'InstallFrom" value to edit for instances like this to the context options in NTLite?
I realize that it's not one of the more standard cases but here we are talking about a piece of software designed to be useful to those people who don't care to settle for Windblows 'normal'... :-/
I came across it..it bugged me...I looked into it...figured out what wasn't working the way *I thought* it should and so here we are...with you reading my latest drunken thread.
To further clarify this is the section taken from the autounattend.xml in question as related to the examples above that only worked after editing the <NAME></NAME> in that particular WIM entry outside of NTLite.
Code:
<InstallFrom>
<MetaData wcm:action="add">
<Key>/IMAGE/NAME</Key>
<Value>Windows 10 Enterprise LTSC w Photos</Value>
</MetaData>
</InstallFrom>In short <NAME></NAME>&<DISPLAYNAME></DISPLAYNAME> should get changed together just like <DESCRIPTION></DESCRIPTION> & <DISPLAYDESCRIPTION></DISPLAYDESCRIPTION> now do....
On the (almost) same subject, can I suggest that in the export options for WIMs\ESDs you change some things...like perhaps change the 'No' button to 'Append' instead of just relying on the user to read the above text then hit 'No' to append. I mean come on, in what world is Cancel/Abort not also a negative aka 'No' in a query for that operation to a 'normal user'? Obviously if you changed any buttons you'd also want to change the text displayed above the options to reflect it.....Heck change 'Yes' to 'Overwrite' while you are at it and maybe you could end up with something like this:
"Choose 'Overwrite' to DELETE the existing file and save a new file containing only the currently exported one!!!! Choose 'Append' to ADD this to an already existing file!! Choose 'Cancel' to ABORT this operation and do nothing!"
Then you could have "Overwrite" "Append" and "Cancel" as buttons instead.
To me it seems that such changes could prevent potential confusion and the query would also be easier to answer without a 'real need' for a user to first read the text above it simply to select the option appropriate for what they initially intended.
I can't pretend to understand why it was needed to edit that entry along with the others....I only know that with two editions of the same in one WIM it does seem to be needed in order to not require manual input alongside an autounattend.xml meant to define which to install anyway.
UPDATE: After sorting out and posting all the above I finally got around to adding the x86 versions of the same build (I haven't yet gotten so far as to figure out how to ensure the boot ISO can operate as intended for both x64 & x86) to the merged WIM and I now see the same issue cropping up with the x86 and x64 versions having the same <NAME> entries in the xml and so I assume autounattend (untested) would still fail here as I suspect they'd end up having the same issue as described above [at least on a x64 system, unsure about x86 at this point]. One step at a time though I guess...
Last edited by a moderator: