yogurt

Not really because because the surviving driver.inf [install_section] is identical to that of the deleted driver.inf (remember they are duplicates) The surviving driver.inf that remains resides in it's OS folder along with all the source files required for a successful installation. No?

What I have learned thus far is that folders in which Duplicate driver files are found are safe to purge from a DriverPack. These 'now' incomplete driver folders will be satisfied by the surviving driver file / folder. Make sense since the source source files of the duplicate are identical to the source files of surviving driver / folder and their should be no adverse effects with the installation of the custom 7 build.

If you have space to spare on your hard drive you could try to reduce your windows partition by lets say 16gb and install your custom build and test that way on real hardware. Then once tested remove the OS using Easy Boot Manager to remove the test installation and reclaim the hard drive space. Another option would be to test on a virtual hard drive. If you search the forum, I think Ricktendo64 has a tutorial on how to install Window 7 on a VHD.

I just want to bring something to your attention that I've only just realized before you try my method. Mr_Smartepants and mooms have pointed out to me that It may be wise to remove non-releavant OS folders first, prior to scanning for duplicates. You will also have to check for Incomplete folders as well. The reasons can be clearly seen in posts #20, #22, and #23.

Thanks for pointing this out. I'll be revising my method to remove non-relevant folders prior to scanning for duplicates with Duplicate File Finder. I think the left over incomplete folders could also be deleted because the one remaining would satisfy the now defunct incomplete.

You make an excellent point. Any duplicates found in the other OS folders that are deleted will most likely break that folders specific driver in the sense that they will not install properly because of the now missing driver file. Further as mooms has pointed out that the same applies for other drivers found in 01, 02, 03, etc...Thanks Mr. Smartepants for pointing this out.

Merci encore pour ce travail mooms.

@compstuff Let me know how you make out.

Je ne savais pas que vous aviez ces 'packs' de mise à jour. Merci beaucoup pour les partage. Sont universels à Windows 7 EN?

@mooms I did not know you had these light update packs. Thanks very much for sharing. I assume the updates are universal with the Windows 7 EN?

For the process of cleaning up my DriiverPacks I use two file utilities. Both of which are portable, lightweight and require no installation 1. Duplicate File Finder (to find and delete duplicate driver files) 2. Remove Empty Directories (RED) (to delete any empty folders resulting from step 1) Example Scenario -- For this example I'll use 'DP_Chipset_wnt6-x64_1212' from DriverPacks. It's a good example because it contains quite a few duplicates. 164 duplicates are found in this pack to be exact. The first thing I do is unpack the driver package somewhere on my hard drive maintaining the original folder structure. The second thing I do is run 'Duplicate File Finder' to find duplicates on the folder where I unpacked the DriverPack. As you can see from the screen shots Duplicate File Finder found 164 files that have a duplicate (Size 14mb) all with the same MD5 Hash. The next step is to simply tell Duplicate File Finder to Select all duplicates and delete them. Optionally with the file utility you can choose to copy the dups or move them elsewhere. I choose to delete. Done! No more duplicates. [sCREEN SHOT REMOVED] -- I need the online space for other stuff. Sorry The last step is to run 'Remove Empty Directories' as shown is the screen shot below. As you can see 'RED' found 45 empty folders in the DriverPack. Now hit the Delete Folders Button and your done. As you can see WinToolkit shows no duplicates and anything left in the Win7 and vista folders are drivers that were not found in the ALL folder. This process shouldn't take an avid user no more than two minutes. [sCREEN SHOT REMOVED] -- I need the online space for other stuff. Sorry Update: I just want to bring something to your attention that I've only just realized before you try my method. Mr_Smartepants and mooms have pointed out to me that It may be wise to remove non-releavant OS folders first, prior to scanning for duplicates. You will also have to check for Incomplete folders as well. The reasons can be clearly seen in posts #20, #22, and #23.

You can make further customizations after Windows Setup completes by adding commands to the %WINDIR%\Setup\Scripts\SetupComplete.cmd file. This file enables you to install additional applications, run custom Windows scripts (cscript/wscript), or make other modifications to the system before a user logs on. Note: Commands in the Setupcomplete.cmd file are executed with local system privilege. After Windows is installed, but before the logon screen appears, Windows Setup searches for the SetupComplete.cmd file in the %WINDIR%\Setup\Scripts\ directory. If a SetupComplete.cmd file is found, the file is executed. Otherwise, installation continues normally. Windows Setup logs the action in the Setupact.log file. Here's the post on how to use SAD2: http://forum.driverpacks.net/viewtopic.php?id=5336 You double-click it and it works. Otherwise you can use the "setupcomplete.cmd" method Create the following folder structure to your Win7 disc: %Win7-Disc%\sources\$oem$\$1\D\SAD2 (entire SAD2 folder with all DriverPacks goes here) %Win7-Disc%\sources\$oem$\$$\Setup\scripts\setupcomplete.cmd Add the following code to the setupcomplete.cmd file.

I personally don't integrate drivers that have the same MD5 Hash (Drivers Marked in Blue). The reason I don't integrate them, is because they are duplicates. Also If my memory serves, I believe DISM will ignore them. I takes me about 2 minutes to clean up a driver pack of it's duplicates and recompile a Custom Driver Pack with no duplicates. Just my 2 cents on the subject.

I don't think you will find anymore than what has already been discussed in the forums, The way the WinToolkitRunOnce works is relatively straight forward. When Win Toolkit integrates a silent installer it copies the silently installer to an Apps folder on the root of your installation source media then adds an entry to the registry RunOnce key which is then executed during first desktop load after windows has installed on the target machine. Here is discussion that might help you in your quest. http://www.wincert.net/forum/topic/10697-howto-removing-changing-a-silent-installer-switch-after-integration/unread/ http://technet.microsoft.com/en-us/library/dd346765.aspx

When I integrate driverpacks into a Win 7 SP1 (7601) x64 I delete the Win 7 Folders When an All folder is present in the pack. I also delete all non-relevant OS folders. The All folders contains drivers for all nt6.x Operating Systems so I tend to integrate those and delete the Vista, Win7, Win8 and server folders. The effect is that I end up with NO duplicates and a relatively minimal set of drivers with no unnecessary clutter. The only time I might consider a driver from another folder is when It has a newer version number than the duplicate found in the All folder -- This, however is seldom the case.

Use the Registry tool and mount this hive. Wim Registry Editor > Wim_Software\\WinToolkit

When adding iconrestore.exe -restore to the silent installers list select the copy entire folder. Make sure the folder containing iconrestore.exe also contains the iconlayout.ini file. Using the copy entire folder option copies bother the binary and .ini file to the dvd. This way when WinToolkit Installer runs iconrestore.exe -restoreiconlayout.ini it will find the file. Hope this helps.

@dhjana I've also had this issue with my integrations that involve IE 9. I have searched the tweaks section also looking for something I may have overlooked and the only thing that I can find that might effect this odd behavior is setting a custom home page. However, the problem for me seems to be random, I wish I had something more for you. Rica, seems to have an idea, Rica, can you be more specific?

Thanks Compstuff for this intuitive methodology, I think I will adopt this method. I find your method to be quite sound. Thanks for sharing. I look forward to your next update.

Lego, point #1 brings me back to my original question. Does this Flaw effect the current 1.4 build? The reason I'm asking again, is because in a previous post you mentioned that Win Toolkit Installer will search all drives for the apps folder. If I put the apps folder on the root of a USB drive should I also include a 'nul' (empty) Install.wim file to ensure the Win Toolkit Installer finds the folder?

Thanks Lego, that's what i thought but I wasn't sure. This is only in the 1.5 branch and not the 1.4 branch right? I presume that for the time being you mean the 1.5 branch when you say "All of these changes are in the latest test build"

I'm not sure I understand what you mean in Point #3. Can you please provide an example scenario?

@bphlpt Just a thought, but I suspect that when WinToolKitRunOnce.exe initiates the scan for the apps folder. It maybe scanning for a certain string or file that would be unique to that specific apps folder identifying it as belonging to WinToolKit. Just a working theory right now, but I will test it post my results at a latter time.

I believe this statement made by Lego pretty much sums of up where Win Toolkit scans for the 'Apps' folder.

Sorry, What I meant to say was that, maybe you could add to the description '...Does not disable HomeGroup services...' Anyhow, I think the current description pretty much implies that. Just a suggestion. Best Regards.