mesheree

In your PM to me, you told me that a "clean" XP CD is defined as one that does not have winnt.sif.Winnt.sif is the only place where OemPreinstall can be set. I think all of you should study Windows Setup before subjecting me to any more of your knee-jerk "NO IT'S NOT!!!" reactions. My solution is not a theory. I have duplicated the incompatibility with and without nLite. nLite's failure is that it does not document its dependencies, which, at least for the two options in question, deviate from Microsoft's. Thank you, everyone, for your help.

These lines go in a txtsetup.oem file. Your method requires OemPreinstall="Yes". nLite's method uses the txtsetup.sif & dosnet.inf files instead. nLite's method requires OemPreinstall="No".

This is documented at Microsoft: http://support.microsoft.com/kb/950722 Sheree

From everyone's responses, I gather that I haven't been clear enough. Here is a more concise version of what I've found: Windows XP offers two different methods of SCSI driver integration. One of them only works with OemPreinstall="Yes", and one of them only works with OemPreinstall="No". As far as I can tell, nLite does not implement the OemPreinstall="Yes" method at all. Also, using nLite's 'autologon' option or changing the name of the Administrator account depends on 'cmdlines.txt', which in turn depends on OemPreinstall="Yes", and this is not documented in the help tooltips. So, this is my tested-and-working workaround: Don't use nLite to enable autologon or change the name of the Administrator account. As far as a solution, I think that's going to require changes to the nLite program--it needs to either change driver integration methods in accordance with the OemPreinstall option, or warn about dependencies. Thank you to everyone, for all your help!

I am trying to accomplish being able to use nLite to integrate a SCSI driver and tweak the Windows XP install. That's what nLite is supposed to do, right? I think I might have figured it out... nuhi posted on this thread, that nLite uses a file called cmdlines.txt for autologon (and to rename the administrator account, which I don't care about). Where is cmdlines.txt? In the $OEM$ folder. What option needs to be enabled for crap in the $OEM$ folder to work? OemPreinstall. Autologon was one of the options that I was using. So I'm going to try it again tomorrow, without autologon. Is this documented in that oft-mentioned help tooltip next to the OemPreinstall option? If not, it should be. I can't read it, or find any help file for that matter, without actually making changes to an actual Windows installation--and I don't happen to have one of those at home. I guess that would be Idea #2 for the suggestion box. That is precisely what enabling OemPreinstall does. It's an option that's built into Windows setup, which nLite manipulates. It has nothing to do with VMware. VMware Server 2 on Ubuntu Server 8.10.

I only use the floppy image while troubleshooting. The driver gets integrated into every ISO I build for VM use. Her drivers. Windows XP will install just fine on the default IDE-type virtual device. However, the general consensus seems to be that using the SCSI virtual device yields better performance. You're right, there's no actual RAID. 'RAID driver' is jut a lazy way of saying that it's a driver for a controller which is capable of RAID (SCSI/SATA). So, after more troubleshooting, I find that it will integrate the driver... but then when I need to enable OemPreinstall to get certain nLite options to work, the driver integration breaks. When OemPreinstall is enabled, successful integration requires a different method of driver integration than nLite uses by default, and I think that nLite is failing to correctly implement that method. johnhc, I don't have a LastSession.ini yet for you. They are all messed up by my troubleshooting. I'll get you a clean one where I exactly duplicated the problem, ASAP. (Personally, I don't think the LastSession.ini files look descriptive enough to tell anyone why something went wrong, but maybe I'm missing something?)

That allowed the driver to integrate (manually--nLite still won't integrate it), but then some of the options that I selected within nLite didn't work at all. For example, DEP was not disabled, Fast User Switching was still enabled, and Outlook Express was still there. I think nLite needs OemPreinstall enabled to work correctly. The kind of game where I make a stripped-down version of Windows to run in a VM. That's not such a stretch, is it?

The method I've been doing all my testing with does not use any $OEM$ folder tree. So of course, I would not have enabled OemPreInstall. But I went to go look at my winnt.sif, and there it was: OemPreInstall="Yes". But I can't disable it--nLite uses the $OEM$ folder tree even with minimal tweaks, to run 'cmdlines.txt'. It honestly hadn't occurred to me that nLite might have used the $OEM$ folder just for the simple stuff I was asking it to do. Thanks for pointing that out. So, you're right. It's not a bug. It breaks two out of three RAID driver integration methods intentionally. Nice. So, as it stands, it looks like I need to start working exclusively with the $OEM$\TEXTMODE method. I'll work with that method more tomorrow and report back. As mentioned in the original post, I have the same problem using nLite to integrate the driver as I do manually integrating it before or after running nLite. Cool! I'd love to not have to manually integrate textmode drivers. The driver package contains only five files, all in the same folder: disk.tag txtsetup.oem vmscsi.cat vmscsi.inf vmscsi.sys

I can take a brand-new Windows XP disc, and manually install my RAID driver (vmscsi.sys) using one of three methods, and all three of them work independently: using txtsetup.oem/winnt.sif editing txtsetup.sif/dosnet.inf pressing F6 to load the driver from a floppy disk ... But when I try to use any of these methods, either before or after using nLite on a brand new Windows XP install, Windows setup gets halfway through the "copying files" phase, and then complains about not being able to find vmscsi.sys. Coincidentally, attempting to use nLite to include this driver as a textmode driver yields the same result. This happens even if the only thing I do with nLite is use its "unattended" settings. Anyone? EDIT: Found a workaround. Do not use either the 'autologon' option, or change the name of the Administrator account, when you are integrating textmode mass storage drivers. The only textmode driver integration method that nLite uses is incompatible with OemPreinstall="Yes". These two nLite features are dependent on 'cmdlines.txt', which is in turn dependent on OemPreinstall="Yes". nLite does not warn you about these dependencies, and they are not documented in the program's help tooltips. I hope that this gets fixed soon. At the very least, nLite should warn the user when they use an option that depends on OemPreinstall="Yes", that their mass storage driver integration will fail. (As of now, the only hint about this that you get is that selecting OemPreinstall="Yes" will break F6 integration. That's part of it--it also breaks the method of integration that nLite uses.) Even better: implement the other method of textmode driver integration, and switch methods according to the OemPreinstall option that the user selects. EDIT: Didn't realize nuhi wasn't actively working on nLite. Oh well, I suppose that if you just had to use those options with a RAID driver, manually integrating the driver using the Microsoft method (above) might work too. I haven't tried it, but g-force says that it works. Sheree