RogueSpear

Just thought of a little something. As part of my unattended install procedure I copy the i386 folder from the media to the \Windows directory and change the registry to look there for installation source files. I wonder if a new hardware detection would look there as well as the Driver Cache directory. Just a thought...

X-Savior, first of all excellent work and I commend you on your tenacity with this. With that said, I checked a couple of installations and it appears that the built in driver cab files are only in the Windows\Driver Cache\i386 directory. It would seem to me that a custom cab shouldn't be any different.

or just type msiexec /?

On a DVD I am considering leaving the DPs decompressed on the DVD so that someone can easily install a new device down the road. On CD it's obviously a different story. Every single little byte counts. And unfortunately I still run into a LOT of cases where CD is the only option.

Maybe some experimentation with UHARC is in order. The other possibility is to use a machine with a gig or two of RAM and make all of the driverpacks one big 7z file. I'm sure a little room could be saved that way.

I run a series of VBscripts in my runonceex, but you could just as easily run batch files I assume. You could stick that sleep command in the batch file.

Well for what it's worth, when I do a fresh install of XP SP2 for a client and then later deploy the unit and plug in their MS Optical mouse (USB), I get that same dialog box about the drivers. And I KNOW that these are built in drivers. All I do is click on search and away it goes. Annoying at best for sure. If you look in your i386 folder you should see a ton of pnf files compressed. Each inf file needs a corresponding pnf. I forget what it stands for at the moment, but I remember researching it in regards to RIS installations.

Well it looks like the creation of this forum is a sign Now if only they were all as easy as Intel's drivers..

Ok I'm following all of this without too much difficulties because I looked into myself a number of months ago. At that time I decided it was simply too much for me to tackle. What I remember though was wondering about layout.inf, which I believe IS digitally signed. If true integration can be achieved without breaking (editing) layout.inf, then what is the true purpose of this file? It almost seems to be redudant to me. Second. Does the driver index file map out the drivers contained within drivers.cab? I know that when you slipstream SP2 over Gold, you end up with drivers.cab and sp2.cab (unless you merge with nLite or manually). Both of these contain drivers as I understand it. Soooo.. can we make say DP_MS.cab, DP_LAN.cab, etc? Because without any compression, the collection of BTS DriverPacks is enormous to just keep around the hard drive. Especially when I have my unattendeds copy over the i386 directory and install basic apps, a 30 gig laptop drive starts to look pretty small pretty fast.

I just had the opportunity to run through Method 1 again and I can confirm that the .sys files from DP MassStorage were not copied over to i386. Luckily I had kept them aside from the last time so all I had to do was copy them over. FYI using latest versions of everything as of 03/27/2005.

Or you would need a batch method to add all of the appropriate lines into the LAYOUT.INF file. Certainly not a task for the weak. Ultimately a batch or script that would recursively go through all of the BTS DPs, adding the lines to the inf and making the new HUGE drivers.cab file.

I for one am beginning to point fingers at RealTek here. I just bought a Dell Inspiron 6000 for my girlfriend and it has a Sygmatel (sp?) sound chip in it, NOT a SoundMAX. I got the same bluescreen portcls.sys that I've had with almost any mobo that has a SoundMAX chip. And just like the SoundMAX, removing the reference to the RealTek directory gets rid of the bluescreen. Between this problem and a couple of weeks of sheer hell due to RealTek NICs built in to some Compaq Evo laptops, I'm about ready to boycott anything RealTek. As it stands I have to remove the RealTek NIC drivers from DP LAN because they break a machine that is a member of a domain (it's a long story I can post in DP LAN if anyone is interested). OFF TOPIC: I didn't know where to post this where people who normally read my posts would see it, so I figure this is as good a place as any. I may not be on here or able to respond to threads/PMs that fast for a little while. I'm goin' to the big D (and I don't mean Dallas). I have no idea how long this will take or what all is involved, but if I'm absent for a couple weeks at a time, that's why.

I'm still really happy with my own hybrid method. Essentially I run the Method 1 setup and let it go through all of it's duties. Then when it's done I delete all of the cabbed up drivers, put the original DP 7zip archives into a folder and have DetachedProgram call a batch file. It gives me the 7z compression so I have much more space on a CD and it works great. I've never had much sucess with Method 2 and to be honest, I just don't feel that comfortable with all the shenanigans going on in the background either.

Erik, this was a problem I ran into as well. For me as it turned out, none of the driver files copied over to the i386 folder. I ended up manually compressing all of them and copying over myself. I never mentioned anything earlier because I had seen so many success reports. I figured I must had f'ed up somewhere along the procedure. I was using Method 1 with V5.03.2 base I believe. I used Windows search to search for all .sys files within the DP MassStorage directory, then used Jcarle's Compression Bin to compress them all, and finally just tossed them into the i386 directory.

In my testing, the 9.0.3.1000 release seems to have fixed the pagefile.sys bug. Now if they could only resovle the Terminal Services issue with the Desktop Firewall, I'd finally feel like they halfway got it together. Also, anyone ever see the changelog for 9.0.3.1100? Sort of wondering if I should even care.

First regarding PXE and WLAN adapters. I don't think this exists. The WLAN adapter would have to be active immediately upon power up in order to boot to the network and do a DHCP. Along the same lines you won't find Wake on LAN as a feature of WLAN adapters. Regarding RIS. I have been using the BTS Driverpacks (along with nLite and RyanVM's Update Pack) as a part of my RIS images for quite some time. It works very similar to the Unattended CD/DVD. There are some subtle differences, but not that much. Mostly some entries in the WINNT.SIF file. The only thing I would mention is that in my experience you should make your RIS image (not talking about RipPrep here) BEFORE using nLite, RyanVM UP, or BTS DP. I have not been able to take an unattended CD, for instance, and have that be used as a source for a RIS image. I always start with a plain vanilla XP SP2 CD.

It works just fine from the svcpack.inf. In fact I made a switchless silent installer for it yesterday. Works nice too..

Well I had planned on donating whether or not you had revenue coming in from ads, so it's all fine by me. I would only ask that it be made a little easier for those of us in the states to send you something. The page I was sent to previously to make a donation was not so easy and I really had no way of verifying their trustworthiness.

As I was typing out that suggestion I had a feeling I was going over old territory

@BTS The same thing is happening to me. Latest versions of everything are being used, but it seems to be an issue directly with the BASE update checker V5.02.9. When you run the update checker, a secondary command prompt window opens for a fraction of a second and then closes. Then another opens and closes. This goes on infinately. When I was finally able to catch the X close button to stop the process, it left a file in the base directory called get_update.cmd if I remember correctly.

A suggestion: Would it be possible to make the batch files for the Graphics and Sound driverpacks a part of BASE? This way when there is only a change to the batch files, they could be updated with the Update checker instead of having to download a 41MB driver pack. Just throwing in my .02

In circumstances like this I usually do a compare on the date modified property of the two files. I almost exclusively script with VBscript however so I'm not really sure how it would be done in batch. The date created and date accessed are obviously useless, but the date modified is usually a pretty reliable method for comparison.

Well I commonly change the private properties and they do take. Using AdminStudio.

Well I change the RebootYesNo to "No" and I manually ad to the msi file the REBOOT property with the corresponding "ReallySuppress" entry. And I've never had the issues described in this thread. For the sake of completeness, I install the package during RunOnceEx.

If anything, just a simple verification that the 3ware drivers removal also removes any remaining problems. If this is the case, maybe they could be saved for a future revision. This way we know that the "theory" behind the driver packs is solid, just a set of drivers has some sort of problem that either requires special troubleshooting or outright omission.