[mclone]

Are there known update slipstreaming issues when running nLite on an nLite'd OS? Obviously if a required component is missing; something will break, but I don't believe that's the case here. Other than a few updates (always the same ones) failing with the "not expected type of hotfix" message, everything completes normally. The other machine I was using to make my discs had no such problems running the exact same job - but now that I don't have access to that machine it has become a problem!

I'm starting from a pressed XP Professional SP3 OEM installation disc (OEM as in licensed to one PC permanently, not a Dell/Toshiba/etc. OEM manufacturer version). The four updates that always fail are:

KB2510581
KB2509553
KB2675157
KB2719985

I've attached two files:

• nlite2.ini - The output of this session is approximately what the machine is running right now - it's my starting point for every build.
  
• nlite5.ini - This is the session on which I got the errors (almost identical except for more updates being added).

Attached File(s)

•  nlite2.ini (38.07K)
  Number of downloads: 3
•  nlite5.ini (40.78K)
  Number of downloads: 2

[-X-]

You're better off downloading and running my UDC script located at http://xdot.tk/updates.html . It will download all the needed updates for XP SP3 and in the case where an add-on is needed, create one for you.

[mclone]

Hi -X- and thanks for the suggestion. While I tried your script and it did work, I'm left with even more questions now. Previously, I had prefixed each update file with a number representing the order in which it was (automatically and successfully) installed by Windows Update. This was to avoid issues with the several updates having invalid or missing "Build Date" meta-info - which I was surprised to see UDC does not appear to address. When running your script, I simply stripped these numbers to restore the original names, then dumped the files into the UDC folder.

None of the files which caused errors was altered, replaced, or removed by UDC, so the errors must have been caused either by the order I was adding them in, or by one of the dozen or so updates UDC moved to its "Obsolete" folder. Neither of these explanations holds up very well, because of the renaming convention mentioned above, and also because all of these "obsolete" updates are still being downloaded by Windows Update on a fresh non-slipstreamed install.

This post has been edited by mclone: 02 September 2012 - 04:25 PM

[-X-]

I'm afraid finding the answer will take up to much time researching all the updates you originally had, etc. All I can tell you is that you should use my UDC script, apply ONLY those updates and everything will work fine. I would not have started with your current updates in the UDC folder as there are probably some that don't belong there and the obsolete routine will not catch them. So delete everything not on my high-priority list. They are not needed and may cause problems.

I'm sorry I cant help you get to the bottom of this but the work entailed will be hours upon hours of research and back and forth questions.

[submix8c]

As a general rule, I Sort by Date (wget downloader retains original dates) when using the UDC script.
1 - Use UDC Script all by itself, i.e. JUST the contents of the ZIP file in a Directory
2 - Add ONLY EXE files, then Sort Date Ascending
3 - Add WMP CABS one-by-one in order by FileName (* note - see below for WMP11)
4 - Add "Other" CABS one-by-one (name/date irrelevant)
5 - If slipping IE8
5a - Create the Add-On then Add at end
5b - REMOVE those marked in the List as "IE6 Replace"
5c - Add the IE8 one-by-one in order by FileName
6 - Continue with nLite process

As for WMP11, Use WMP11 SlipStreamer process BEFORE using nLite then
1 - Proceed as above but DO NOT include the WMP11 Cabs (Step#3 above)
2 - Get the corresponding ORIGINAL "EXE" files (see contents of Script)
2a - EXCEPT KB952069 (does NOT apply to WMP11)
2b - Add WMP11 "EXE" files in order by FileName
* note - above in essence replaces the Step#3

HTH

[bphlpt]

mclone, on 31 August 2012 - 04:26 PM, said:

Are there known update slipstreaming issues when running nLite on an nLite'd OS?

While this has sometimes worked for some people, there are just too many possible ways this can go horribly wrong. Hence it is almost always recommended to start from scratch with a fresh, clean, "virgin", official source and run nLite once with everything you wish to do on it. (The exception to this is running nLite to slipstream SP3 onto an earlier official source is usually a safe stand-alone step.) The method described above is one of the proven ways to make sure you end up with all the required updates you need in order to end up with an updated OS.

Cheers and Regards

[submix8c]

Quote

when running nLite on an nLite'd OS?

Missed that. See above comment.
Short answer - DON'T nLite an nLited Source!

[-X-]

I think he means his source is untouched but the OS he is running nLite on has been nLited.

@submix8c, there's no need to do all those steps. Just add them all and sort by date ascending. And the only reason you need to sort them is because of KB977816 and KB2115168. nuhi forgot to put version checking for .ax file and those updates contain l3codecx.ax. XP Home has on other thing that needs to be sorted.

Quote

XP Home only! Due to a bug in nLite, KB978338 must be put below KB2509553 when the target source is XP Home. To do this, first sort the updates by date ascending, then with the arrows on the right, move KB978338 below KB2509553.

This post has been edited by -X-: 03 September 2012 - 03:25 PM

[mclone]

Hi everyone and thanks for all the replies! Just to clarify, what -X- said in his last post is indeed what I meant. The computer running nLite is an nLite'd installation, but the XP source that I am feeding nLite is untouched.

I've done some more playing around and I think I've solved the original problem, though I'm not sure of the exact cause. One of the last times I tried to run nLite, I got a .NET error regarding accessing a bad memory address or similar. I usually install .NET 1.1, 3.5 etc. and 4.0, so the next time around I installed only .NET 3.5 just to see what would happen. I used my original set of updates and I had no issues. So it could be an issue with .NET, or it could be some kind of addressing bug due to having more/different RAM (3GB now where I have 1GB before).

So that problem seems to be taken care of... Now I just need to figure out why parts of my configuration script (computer/workgroup name, owner/company, etc.) aren't working any more.