Using nLite for our family's PCs

[OldB]

I am a NewB to nLite although I have now twice managed to create trimmed-down (no WMP, .Net etc.) XP Pro and Home CDs with Windows Updates post SP3.

Because I manually downloaded Windows Updates from the WU Catalogue and some require manual intervention it takes almost an hour to re-run (that part of) the nLite process.

1. Is it possible to merge Windows Updates into the Pre-ISO-build nLite'd folder using the MS WU "/Integrate" options OR is there a better way?

2. If there ARE options to do the above then would it make any difference if I used the "xable.net post SP3 UDP" bearing in mind which branch of the development tree the originals are from as noted by 5eraph in post about update source choices

I have already tried running nLite a 2nd time on the nLite'd folder with the latest updates but that failed with a BSoD on the final re-boot of XP installation.

Apologies if parts of the above have been asked before - I DID try to search but found nothing matching... B.

[tomasz86]

Using update packs is definitely the easiest way to get your source updated. If you want to play with single updates then HFSLIP is a better choice than nLite. HFSLIP can directly slipstream almost everything while nLite is much more limited.

This site may be the best start for you.

[OldB]

Thanks for the input but perhaps I put too much detail in my original post...

I REALLY LIKE nLite and what it does - especially getting rid of "surplus" software but ALSO TWEAKS...

What I want to be able to do is create an nLite'd folder and THEN ADD UPDATES from MS as it is often 6 months between my complete re-installs.

If I use the updates from MS directly (QFE branch?!) does that mean that I can then add more as they arrive each month?

I ask about xable.net because with THAT approach I am guessing that nLite would simply accept all updates from MS without intervention so I could perhaps use nLite from scratch (XP SP3) every time... But does that mean I can't add further updates manually because they are from the wrong branch (GDR?) of the development tree. TiA... B.

Using update packs is definitely the easiest way to get your source updated. If you want to play with single updates then HFSLIP is a better choice than nLite. HFSLIP can directly slipstream almost everything while nLite is much more limited.

This site may be the best start for you.

Edited February 9, 2012 by OldB

[Guest]

Using nLite more than once on the same source has been known to cause problems. Using the /Integrate (or /s) switch on an update package (*.EXE) only adds that package to SvcPack.inf for installation at T-13—it does not truly slipstream the update and it will greatly increase the size of the finished ISO as more executables are added over time.

The easiest approach is to download Xable's latest update pack when you plan on a Windows reinstall, and keep your "Last Session.ini" from previous nLite sessions to reapply all of your preferred tweaks and removals. Then run nLite on your unmodified source using the INI file and the new update pack.

[OldB]

Using nLite more than once on the same source has been known to cause problems. Using the /Integrate (or /s) switch on an update package (*.EXE) only adds that package to SvcPack.inf for installation at T-13—it does not truly slipstream the update and it will greatly increase the size of the finished ISO as more executables are added over time.

The easiest approach is to download Xable's latest update pack when you plan on a Windows reinstall, and keep your "Last Session.ini" from previous nLite sessions to reapply all of your preferred tweaks and removals. Then run nLite on your unmodified source using the INI file and the new update pack.

Thanks for the quick response.

Presumably that also means that the size of the base installation (i.e. disk space of XP SP3 installation just after install) grows because of all the Uninstall + other ...... that the Update process generates.

So as you were the author of the post that I quoted about branches (GDR vs QFE) - presumably if one of my offspring was away from home at College and needed to use Windows Update on their Laptop then both the xable and what I have done with nLite and updates from Windows Catalogue would be able to accept them. If so - what is the scenario that causes a problem with GDR-branch updates?

[Guest]

Presumably that also means that the size of the base installation (i.e. disk space of XP SP3 installation just after install) grows because of all the Uninstall + other ...... that the Update process generates.

That's true, but modern hard drives should not be starved for space. Your installation CD/DVD might be, depending on what else you're including.

[... If using a GDR update pack] - what is the scenario that causes a problem with GDR-branch updates?

Let's say your college student is running into a problem with a printer that could be solved by installing KB959482, which has QFE file Win32k.sys v5.1.2600.5815. However, you installed Windows with Xable's latest update pack which includes only the GDR v5.1.2600.6178 of the file as included with KB2639417. The hotfix will not install an older file version over a newer one, and the update pack does not include the latest QFE version of the file.

In this case you should be able to get the hotfix by downloading KB2639417 and installing it on the system using the "/B:SP3QFE" switch. But is your college student savvy enough to use a Windows command prompt, or resourceful enough to determine which security update has the latest currently installed version of the needed file?

Edited February 10, 2012 by 5eraph

[OldB]

Presumably that also means that the size of the base installation (i.e. disk space of XP SP3 installation just after install) grows because of all the Uninstall + other ...... that the Update process generates.

That's true, but modern hard drives should not be starved for space. Your installation CD/DVD might be, depending on what else you're including.

[... If using a GDR update pack] - what is the scenario that causes a problem with GDR-branch updates?

Let's say your college student is running into a problem with a printer that could be solved by installing KB959482, which has QFE file Win32k.sys v5.1.2600.5815. However, you installed Windows with Xable's latest update pack which includes only the GDR v5.1.2600.6178 of the file as included with KB2639417. The hotfix will not install an older file version over a newer one, and the update pack does not include the latest QFE version of the file.

In this case you should be able to get the hotfix by downloading KB2639417 and installing it on the system using the "/B:SP3QFE" switch. But is your college student savvy enough to use a Windows command prompt, or resourceful enough to determine which security update has the latest currently installed version of the needed file?

Again - many thanks for the rapid response - I will attempt to close this down with one last question...

With remote assistance and a .BAT file or two I could just about handle both home and a remote Laptop situation you describe BUT...

What about "Patch Tuesday" updates - would they be applied if I switched "Automatic Updates" on before the Laptop left home?

Also - thanks for explaining the limitations of /Integrate - that is probably why the final stages of the XP install took so long although it was in a virtual PC.

So presumably when nLite processes the list of Hotfixes it works out the format, extracts the content then replaces files in the source without using MS update.exe...

[Guest]

What about "Patch Tuesday" updates - would they be applied if I switched "Automatic Updates" on before the Laptop left home?

Automatic updates will be applied as expected when switched on. No problems there.

So presumably when nLite processes the list of Hotfixes it works out the format, extracts the content then replaces files in the source without using MS update.exe...

Correct. nLite also checks within the packages for the file "update_SP3QFE.inf" and parses the [Product.Del.Reg] and [Product.Add.Reg] sections for registry entries to add to nLite.inf.