Is there a recommended order for configuring NTLite?

4

43.onsomeday

New Member
Messages
19
Reaction score
0
Here's the translation of your message into English:

While configuring with NTLite, it seems like there's an order of operations to follow.

  1. I first configured "Remove_Scheduled Tasks" and then modified "Remove_Components." After doing so, I noticed changes in the counter for the "Remove_Scheduled Tasks" settings (although the previously modified items were no longer editable).

  3. When I configured "Remove_Scheduled Tasks," "Remove_Components," and "Configure_Settings," I found that many items in "Configure_Services" became uneditable.
So, I'm thinking that to modify the items I want, the correct order might be: "Configure_Services" > "Remove_Scheduled Tasks" > "Configure_Settings" > "Remove_Components."

Additionally, due to the concept of dependencies, if I uncheck an unnecessary lower-level item, the necessary upper-level items are also removed. So, wouldn't it be better to set as many services to "Disabled" as possible and then only uncheck the items that cannot be set this way?

I'd like to hear your thoughts on this.
 
When NTLite loads an image, it performs a full inventory of all WinSxS component folders and creates an internal dependency map.

Based on the results, NTLite decides which Components, Services and Services are available for your editing. If a component no longer exists, then Services and Settings attached to that component will be gone. This dependency map is recreated every time the image is reloaded.

If you intend to remove components, the correct sequence is:
1. Load a clean ISO image.
2. Add optional Language Packs to the image (always done before Updates), and Apply changes.
3. Add Windows Update files, optional Features on Demand, or Appx package files. Apply changes.
4. After you have finished adding to Windows, you may begin removing unwanted components or Features. Apply changes.
5. When the processed image (add + subtract components) is reloaded, then finally edit your Services and Settings.

By removing a component, the matching Services for that component will be automatically removed. There is no need to separately remove the Service, before removing its parent component. That is an unneeded duplication of work.
 
When you delete a component, NTLite deletes the tasks, services, etc... linked to this component
So by unchecking a component, you can have several "entries" of unchecked/modified (the number in the counter changes)
The services and tasks are grayed out and indicated "deleted", NTLite does it automatically
Conversely, you can delete a task or modify the parameter of a service, while keeping the component

I have already noticed when deleting (unchecked) a "child" component, it can happen that the "parent" component is also unchecked
Just need to re-check it, but it happens very rarely

No recommended order for configuration
The integration of update, App, delete components, etc... (everything that NTLite offers) it does it very well in one go, and in the necessary "order"
No need to make the modifications in several times

My preset "integrates/modifies" everything and it works very well

View attachment 12667
 
tistou77 said:
When you delete a component, NTLite deletes the tasks, services, etc... linked to this component
Click to expand...
Yes, everything related to the component will be greyed out as they have been selected for removal.

nuhi garlin - suggestion - when that happens maybe add a note something like "Selected for removal" or similar so it can be differentiated from a component that is greyed either for a Compatibilty or "component removal not allowed".
 
Clang2 said:
Yes, everything related to the component will be greyed out as they have been selected for removal.
Click to expand...
Yes, that's what I said ;)

Clang2 said:
nuhi garlin - suggestion - when that happens maybe add a note something like "Selected for removal" or similar so it can be differentiated from a component that is greyed either for a Compatibilty or "component removal not allowed".
Click to expand...
I don't think nuhi has had any feedback on this but maybe, it seems to be pretty clear, I have this impression

- If not allowed for deletion, it is indicated (Explicit removal not supported) and grayed out
Still possible to remove it by modifying the xml file (not at all recommended)
- If it is grayed out by a compatibility, it is indicated for which compatibility

For services and Tasks,
- If deleted by NTLite (removing a component), grayed out and marked Remove for tasks (but not for services, that's true)
- If not deleted by NTLite, it is not grayed out and possible to modify the service or delete the task
 
I believe that deleting a service is very problematic because if the deleted service is needed later, it cannot be reactivated immediately.

Grouping the concept of parent-child relationships into a hierarchy also seems very unstable.

While a simple parent-child structure is manageable, in cases where the hierarchy goes deeper, such as parent-child-child-child, it becomes impossible to deselect the last component without deleting all the related components in the hierarchy.

As a result, I think it's better to disable the service item first and then delete the last component, which allows unnecessary components to be deactivated.

If the components are configured first, it's impossible to disable unnecessary elements from the service items.

I believe NTLite's structure should be reconsidered. The most intuitive structure for users would be something simplified, like "App - System - Security." However, NTLite requires checking multiple locations, such as "Remove_Components_Drivers" and "Remove_Components_Hardware support_Individual" to delete drivers, which is both inconvenient and cumbersome.

In other words, the process involves switching back and forth between different sections.

Eventually, this leads to confusion about what actions have been taken and what still needs to be done.

I hope these suggestions will be considered.
 
"Components_Drivers" and "Components_Hardware support_Individual" are 2 different things

For "Components_Drivers"
You can delete the drivers that you don't need, or because you integrate a replacement driver (more recent or a manufacturer like Intel, etc...)

For "Components_Hardware support_Individual"
This is the "root" of the component for the driver, the "name" of the device (if I can say that)
If this component is deleted, it will no longer appear in the device manager or with an error but you will not be able to install an associated driver

On the contrary, if you delete a necessary driver, the device will appear with a ? (or other) for a missing driver and you will still be able to install it
 
I do a lot of my changes live(meaning the os is already up and running) This is how I learned what does what and restore from a backup when buggering up.

I have found that something removed might not show it's ugly head with issues till later. It took me a good year and a half to truely know what is what. Don't worry if you cannot figure it out instantly because I didn't but I learned.
 
You must log in or register to reply here.
Back
Top