Quote taken from here: http://technet.microsoft.com/en-us/libr … 10%29.aspx

So this continues the problem of driverstore bloat.  What I use in my SAD2 script is the Microsoft tool dpinst.exe.  There are two versions (incompatible with each other) for 32 & 64 bit OS.
Where dpinst excels is that it only installs drivers for the hardware that is present during execution.

About 95% of my script deals with OS detection, path resolution, and driverpack extraction. 
The "meat & potatoes" line that gets the drivers loaded is right here:

Start "MicroSoft Driver Installer Tool Running" /wait /separate /realtime /min CMD /C DPInst.exe /c /s

But in order for this to work, dpinst needs to be copied to the root of the folder containing all the drivers.

The batch-script line I was experimenting with for pnputil usage was this:

:: pnputil -a -i %SystemDrive%\D\*\*.inf

But again, this loads ALL the detected drivers into the driverstore.  The drivers remain there, even after first install.  That's a VERY significant file bloat.  Depending on how many DriverPacks you use, that folder may exceed 3 GB in size.

I have tried both the sad2 tool and the method I use which involves pnputil and a forfiles script:
forfiles /p %1 /s /m *.inf /c "cmd /c pnputil -a @Path"

which I found here: http://deploymentbunny.com/2011/05/07/a … -forfiles/

I can't take credit for the script, but what I can take credit for is avoiding sysprep altogether.  Basically when I build the master image to be deployed, I do it in a virtualbox, but the key is I change the IDE/sata controller driver to 'generic' before uploading the final image.  This allows the image to initially boot on almost any system, then since almost all the drivers have been added to the windows driver store, it automatically finds and installs hardware on the first boot, including the specific driver for the controller installed.  I realize this method isn't for everyone, and avoiding sysprep could potentially cause licensing issues, but I do not activate the master image, and my employer has a sitewide win7 enterprise license with domain keyserver, so it hasn't been an issue.  According to a few things I've read, it's no longer necessary to change the sid when joining machines to a windows 2003 or higher domain, and I have not had any issues.  Although, if you do wish to change the sid, (microsoft best practices, when using imaging tools such as ghost) then are tools that allow you to do so.

Anyway, I really like the idea of sad2, but my current method is great for my fit, I would however like a way combine the best of both worlds: to index the .7z driver packs while they are compressed, thereby leaving them in the image, but also allowing the windows driverstore to enumerate them and load drivers dynamically.    This could aid in minimizing bloat, but also keeping the drivers there for universal deployment.

I am currently using clonezilla to deploy which generally works well, but doesn't dynamically resize ntfs partitions on efi systems, and is a bit tricky to usb boot the clonezilla client on a Mac.

We generally deploy on HP hardware, and so far driverspacks picks up about 93%, since newer hardware requires a few downloads here and there, for things like fingerprint readers, intel AMT hardware, usb 3.0 controllers, AMD/ATI integrated video controllers, etc.

Do you guys have any tips/recommendations/alternatives to my current deployment method?

* 5 Add to that, the fact that every desktop/laptop/server's chips (& many peripherals) are made by manufacturers Other than the OEM of the board.

* 6 Understand that those chip manufacturers are most often the originator of these 'special drivers' & that they often release to many OEM's updated drivers for a wide number of specific HWID's that are contained inside their plastic-encased silicon chippery!

* 7 Look for someone to have already found updated, MS-WHQL'ed drivers from various OEM's, tested them for validity versus actual hardware, collected them in a convenient downloadable form, maybe throw in a kickass custom post-installer like Mr_Smartepants' SAD2 (I don't believe he should be sad, he should be proud ) & there you are @ DriverPacks.net!  Go get 'em! 

SAD2 package - is it ready for testing on 7 x64 installs?

Testing?  It's ready for PRODUCTION!   I've been using it for months and works great.

Well, if you add the drivers to the install.wim with DISM then you're going to have all the drivers remain even after install...significant bloat.
The method I prefer (to minimize the driverstore bloat) is to only integrate dpms & Chipset and use my SAD2 script post-install.  Using dpinst.exe ensures that only the drivers that are needed are installed and the script cleans up after itself.  I'm still planning on getting DriverPacks Finisher to work in an NT6 environment.

Ok, cool! Before I start here with your SAD2 package - is it ready for testing on 7 x64 installs? Or is DriverPacks Finisher required to get this working?

   1. Insert your CD / DVD drive installation disk. In Explorer, select the file you want to view. Scroll down to the file "set", which is identified as an application.
   2. Right-click the file and select "Properties." Top of the window that appears, click the "Compatibility" tab.
   3. Check "Run this program in compatibility mode as:", and then from the popup menu in the "Windows Vista" the.
   4. Also, check "Run this program as an administrator" in the bottom of the window.
   5. Click "Apply", then "OK."