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.

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.

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). nlite2.ini nlite5.ini

Hi, I'm interested in maintaining my own ULZ file for a specific XP machine, and I am also concerned about the order of their addition since there are several patches which do not appear on Windows Update until others have been installed. I have thought up two main ways to handle this: 1. Keep WUD's existing folder output structure, but edit the ULZ to prepend each local filename with an incrementing number (so that they can easily be re-ordered in another utility, in this case nLite). 2. Manually track the updates that appear/are installed in each session, and create a ULZ list for each iteration, so set 1, set 2, etc., and then integrating updates from one iteration at a time. Will these ideas work? Is there a better solution? edit: After some further reading, I can probably answer my own question. it would appear that the order (for XP) MAY be important depending on the update, since obviously one can't install a service pack for .NET without first installing .NET. It appears nLite will integrate by the order the updates are shown, and that the column headers can be clicked to sort by that field. That's great because most of the hotfixes have an entry in the Date field, which should resolve most issues. Using the default WUD XP-SP3 list however, there are several updates which are not dated. I'mm have to see if those are the ones it's giving me errors on...