BikinDutchman

Have been using the guide for >month now. Do not confuse slipstreaming and overinstalling. The latter means you have windows installed already and "upgrade" to a new SP.

Did you try the driver from support.dell.com? It is listed for Windows 2003 x64 but I would be surprised if it is any different than for what is needed for WinXP x64. The dell driver is older than the LSI driver but has SUBSYS identifiers so there might be a special DELL implementation of the hardware.

Goto http://support.dell.com/ and select "I am looking for drivers and download" and follow instructions for your own PC or monitor. Download all you need, extract the downloads and see what works for your unknown devices in the Device Manager.

I would first try installing with a vanilla WinXP disk that is known to work. -If possible set the SATA mode in the BIOS to IDE emulation (which means no HDD drivers needed, and no F6 floppy needed) If the Vanilla/IDE method does not work, you probably have hardware issues. -If it works try native SATA mode (BIOS) and installation with an F6 floppy. If you have no floppy drive try integrating the native SATA (Intel AHCI?) drivers with nLite, nothing else. If that does not work you might report back and upload some files.

link fixed.

nLite 1.4.8: solved

I had similar issues and some succes with setting: HKLM\SYSTEM\CurrentControlSet\Control\Windows ErrorMode 2 This redirects error messages to the event queue and does not pause execution. The default ErrorMode value is 0 and it is best that is stays there. The above tweak is a last resort.

Look under WinXP\I386\NLDRV for each new integration and what is in those folders. Not sure what you are exactly doing but it looks like you keep adding the same drivers.

Not sure which ones you have. Look in your WinXP\I386\SVCPACK folder. If you see the installers showing up there you can assume they are not fully integrated.

This might be a method to distinguish the x64 versions from the x32 versions, although unnessary. I guess the idea is that you rename the *.inf_64 if any, if you want to use them.

Do you mean a driver inf file name as: *.inf_64? In that case no. The x64 components of an *.inf file are specified with decorations (NTamd64), see here.

I guessed it would work out much in the same way for WinNT installs (avoiding the long name problems) I assume we consider this case closed now. Let this topic sink deep to the bottom of the forum .

Hi all, In the past week I found a special problem with nLite integration of Dell PERC5 and 6 RAID 64 bit drivers. I reported this to Nuhi but I think it is also interesting for those who are struggling with this integration. Below is the TXTSETUP.oem with comments removed and my edits: The edits for the [Disks], [scsi] and [Files.scsi.PERC_64] sections are cosmetic. The percsas is for something that, according to INF file scripture does not make sense, but I see it a lot in Dell TXTSETUP.oem files. The edits for the [HardwareIds.scsi.PERC_64] section are mandatory for the integration to work with nLite 1.4.7. Warning: it gets a little technical from here and I continue in geek speek: Problem is that someone (at Dell?) was so fond of the PERC_64 key that (s)he used it for almost every entry. -Well that looks just strange for the [Disks], [scsi] and [Files.scsi.PERC_64] sections but it is dead wrong for the [HardwareIds.scsi.PERC_64] section. -It might be that the latter is no problem with an official F6 install, but nLite 1.4.7 does not take this so lite, and does not include the entries under the HardwareIdDatabase of TXTSETUP.sif. -That, in turn, causes the PERC 5 or 6 array to be not detected during textmode install . I hope this was the only one TXTSETUP.oem that has this problem but I am not optimistic so we can probably add this one concern to the many that we already have. OK it keeps us from the street .

I have no experience with Tablet, maybe someone else can help. -The SP3 is for tablet as well so you can try sliptreaming on your disk 1, assuming it has the i386 or AMD64. Look if something has changed. -I am not sure about combining the two disks. It might work if you copy the file set of the second into the first file set without overwriting any important files. I remember there have been posts about that. Please keep the topic at nLite integration or they kick me out of the forum .

Decided to NOT adding something for KB942766, see here. -Any thoughts welcome.

Direct integration in the SP3 install set makes only sense if you have the SP2 MUI already integrated. From what I see that is not so easy. -It is probably meant to update already installed Windows XP Prof. SP2. Regardless, the KB942766-v6-x86 integrates nicely in the WinXP-SP3 set (using /integrate). The updates appear to be all QFE but I would have expected GRD for a real SP3 extension . I have no ides how the pack works: I see a small number of help (chm) files: those for RDP show foreign titles and mostly English explanation. That is supposed to fix the language problem in RDF, MMS etc. The others have script errors. I am not sure how that works out in the installation . -Ant thoughts welcome.

Good I will have a look. WinNT32 unattended installations can be started from any 32/64 bits Win OS, typically WinPE 2.0. Google is your friend here.

For the official way of doing this see: here and related chapters. Good luck

jwolberg, Please edit your post to remove all file content and put them in a code box or better upload.

Two questions: -Can you upload your Last session.ini, dosnet.inf and txtsetup.sif? -Did you try a WinNT32 installation with OEM customization?

Mikesw: Thanks for info, agree there are many more things obsolete in the WinXP-SP3 as I created. My goal was to create a folder that was most up to date, given the tools MS provides. If the RTM version of WinXP SP3 is ever released we may further fine-tune. I put effort in this to create a starting point for nLite modifications as clean as possible after we encountered problems discussed here. Integrating tswebsetup.exe is a windows 5.2 component and would, imho, be a slipstreaming issue typically taken care of by nLite. KB942766-v6-x86 is a borderline case since it is listed as an update to SP3; I will look into that one to see if direct integration works. Likewise there is, in the meantime, a slew of SP3 fixes reported here. -Those are not the regular security updates and apply for special cases. I am not sure what to do about that. RE: the Components folder: I think it can be deleted but netfx.cab is actually specified in Dosnet.inf. I would be best to take all related Dosnet entries out; I have become very cautious about potential copy, registration and signing errors during windows install, you never know what else is screwed up.

No attachement as far as I can see. May be I miss something.

The label name that you put in the upper left box ends up as the CD label (this info is stored inside the ISO image). The file name of the ISO has nothing to do with that; nLite could change the default file name to the name in the box but, apparently Nuhi did not choose to or had other priorities . After creating the ISO file you can change the file name but changing the CD label in the ISO is not so easy.

FuttBuck: I do not have the retail SP2. It should be better than a slipstreamed SP0 or SP1 but I believe that my miniguide will lead to the same result. -Other thoughts welcome; and I will include suggestions in the mini-guide as needed. I did the following to detect the files that are really obsolete: -Slipstreamed RTM > SP3 -Slipstreamed RTM > SP2 >SP3 -I compared both folder sets with a synchronization program (ViceVersa) and that shows clearly what is no longer updated: only the old RDP client.

Hi Boooggy, I did an nLite (v1.4.7)+Slipstreamer (v1.3.2.0) integration for a WinXPx64 installation running on a WinXPx64 OS. Everything was perfect, better than ever before . Howerever there was one small error left: after installation the log showed a registration error for qasf.dll. -I found this was caused by the 32 bit version of qasf.dll being present in the system32 as well as the sysWOW64 folder. -I fixed it by copying the x64 version of QASF.DL_ back into AMD64. Official MS installations do not show this problem. Please look into this