More granular control when Reapplying tasks across editions

[tired-it]

There are some operations that I want to selectively apply when making an ISO. For example, I want to add drivers to a particular edition via install.wim, but I also need a select few drivers to be added to the Setup under boot.wim. However, if I check the option to apply the drivers to boot.wim, all drivers get copied over.

For another similar example, there are a few settings related to installation requirements that require application to boot.wim. I have other settings I want to apply, but they do not need to be applied to boot.wim. So I often have to have two separate presets for handling circumstances like this.

In other words, I am looking to have more granular control over how tasks are getting reapplied when I check in other options like Microsoft Windows PE or Microsoft Windows Setup. Is this something that is possible to implement? Or perhaps there is a setting I missed? Is it okay if extraneous settings/drivers/etc. get applied to other editions?

 

[garlin]

There's no harm if you apply extraneous Settings or Drivers to boot.wim.

boot.wim will increase by size. This isn't normally a problem unless you're trying to add a full 1GB NVIDIA or Realtek audio driver folder.

WinPE is a reduced version of Windows, it's missing most of the normal services and desktop features. So those extraneous Settings are ignored, because nothing cares about their presence. You can put junk data into any registry, as long as it's not being executed on.

 

[tired-it]

There's no harm if you apply extraneous Settings or Drivers to boot.wim.

boot.wim will increase by size. This isn't normally a problem unless you're trying to add a full 1GB NVIDIA or Realtek audio driver folder.

WinPE is a reduced version of Windows, it's missing most of the normal services and desktop features. So those extraneous Settings are ignored, because nothing cares about their presence. You can put junk data into any registry, as long as it's not being executed on.

Good to know! In regards to the drivers, I definitely want to avoid inflating the overall ISO size anymore than Microsoft already has. And there are a few instances where I have GPU and audio drivers that I want to include.

 

[nuhi]

In general I do agree it would be nice to select all individually.
The thing where it is not worth it the development effort is the point that garlin mentioned, it does no harm as is and UI clutter scares everyone else.

Thinking outloud, I would like to have a tabbed interface with parallel processing of editions - maybe one day - but the complexity of setup and user error, then to debug such reports would be hell.
Also it's not like it's needed that much next to the current system for spreading tasks across editions.

Some existing not so known relevant usage tips:
- it is already possible running a second NTLite instance, so take your second preset and start boot.wim processing in parallel.
- you can also automate all of it via scripting (check ntlite.exe /?), so it doesn't require mental effort once set up.

Then NTLite UI becomes just a preset editor when needed on changes, just fire away parallel processing inside one script.
[not an exact syntax, just an illustration, see ntlite.exe /? for more details]
start ntlite.exe .... install.wim preset1 create iso (takes longer, then iso includes boot.wim changes)
start ntlite.exe .... boot.wim preset2

 

[tired-it]

In general I do agree it would be nice to select all individually.
The thing where it is not worth it the development effort is the point that garlin mentioned, it does no harm as is and UI clutter scares everyone else.

Thinking outloud, I would like to have a tabbed interface with parallel processing of editions - maybe one day - but the complexity of setup and user error, then to debug such reports would be hell.
Also it's not like it's needed that much next to the current system for spreading tasks across editions.

Some existing not so known relevant usage tips:
- it is already possible running a second NTLite instance, so take your second preset and start boot.wim processing in parallel.
- you can also automate all of it via scripting (check ntlite.exe /?), so it doesn't require mental effort once set up.

Then NTLite UI becomes just a preset editor when needed on changes, just fire away parallel processing inside one script.
[not an exact syntax, just an illustration, see ntlite.exe /? for more details]
start ntlite.exe .... install.wim preset1 create iso (takes longer, then iso includes boot.wim changes)
start ntlite.exe .... boot.wim preset2

Fair enough, I appreciate the insight! I figured it might be more trouble than it's worth, but I'm always chasing new ways to streamline a process. I didn't know NTLite could be ran in a script like that!

 

[garlin]

Run NTLite on a command line with /? flag.

Most users don't run in automated mode, because they're tweaking their presets in the UI. But suppose you understood the preset XML enough to change the list of update files, driver files, and Post-Setup files, then you could regenerate a new ISO every month. That's assuming you copied the right files into place before running NTLite.

 

[tired-it]

Run NTLite on a command line with /? flag.

Most users don't run in automated mode, because they're tweaking their presets in the UI. But suppose you understood the preset XML enough to change the list of update files, driver files, and Post-Setup files, then you could regenerate a new ISO every month. That's assuming you copied the right files into place before running NTLite.

Yeah, I have gotten into a habit of manually editing the presets as needed. Regenerating a new ISO every month is the goal. All I have left is to make sure the Windows Updates portion works and pulls the latest updates without issue.