Search options (Page 38 of 213)

do you mean for updating the packs themselves?
If so, that is not possable... There are simply too many steps involved, and too many variables, and way to many exceptions to the rules. the video would be over 100 hours long .

If you mean for slipstreaming the packs... that was done by Carey Holzman and is posted in the FAQs.

OUTSTANDING first post Avatar... that is how it's done people!

Unfortunately SAD is based on the Microsoft redistributable file dpinst.exe.

We have had several reports in the past about failures related to dpinst. For some reason it does not work as well as slipstreaming the drivers and allowing setup to install them. We don't know exactly why.

perhaps with your feedback, and others like you, we can figure it out together. There must be a common denominator with the drivers that fail to install. Many drivers are very poorly written and that may be a contributing factor. Please continue to post your DriverPacks versions and HWIDs as you find failures. It may also be very helpful if you can find the related sections of your setupapi.log for the failed devices.

We will certainly be eager to help you to help us to help everyone else.

Again, I think the answers (or at least the clues) will be in the setupapi.log file(s). With HWIDs API log entries and pack versions we should be able to nail it down. The more examples we have the better the odds we can spot the problem. You may be correct about the signing issue, however it is my belief we have set the proper flags to allow unsigned drivers. perhaps a more aggressive approach to installing unsigned drivers will be the fix. Are all the drivers that fail having signing issues?

Thanks for helping us to help you.

Jeff

PS Welcome to DriverPacks!

PS Is it possable that you could have one of these problem machines for a few days for testing some ideas?

those instructions are over three years old (june of 2007) and not accurate or useful.
because it is based on false assumtions about KTD.

Um looks like DriverPacks BASE ran normally... that's good.

I belive your network install is based on winnt32.exe ... (although i could not access the instructions you linked to)

DriverPacks is designed to be run from CD/DVD useing setup.exe localy... and has known issues with winnt32 installs.

the only way DriverPacks was ever supported with network installs was with RogueSpears AutoImage. RS has retired and is now a linux guy. however his app is still available. RS made DriverPacks compatable with winnt32 installs... at least for RIS installations. the best i can do is to suggest that you use autoimage to integrate DriverPacks into your source. I know that it will work with RIS if you do that. Im not sure how compatable that is with what you are doing but it is the best support that i personally have to offer you. Based on you trying to integrate all the packs with your network install.

Some of our crazy sysprep guys have other methods of integrating the packs for network installs the "universal imaging" forum here may also prove useful and those crazy's may also have some insight .

If I were you i would integrate Mass Storage textmode (Only the textmode drivers) and use the DriverPacks SAD (Stand Alone Drivers) method of updating the machine (post installation update or  what MS calls a "Software First" install method).

Please ask whatever you like somebody will certainly have been in your shoes in the past.

here is a link to AutoImage in case you decide to try that route http://www.doitrightconsulting.net/forum/
RogueSpear is an old and dear friend of the DriverPacks and AutoImage and DriverPacks BASE were designed to work together.

We will see what we can do to help but network installation is not "technically" supported

PS there is absolutely NO reason to EVER use KTD ALL... that is insane and it won't do whatever you were hoping it would. Not only that but the path length of the full set of DriverPacks far exceeds the max size of a single registry entry, IE even if it might do what you were hoping ... it won't work. KTD is good for modems and monitors and USB devices etc... simple devices that might be attached to a fully installed and working machine. Complicated devices like printers or sound cards or video cards that require a setup.exe to be run will never install with KTD (since the DriverPacks Finisher is not called, they will therefore not have their setup.exe called and of course will then fail to install properly)

well they are enabled for building plugins...

and most of them work to some extent.... However only the Intel drivers are actually needed. Most modern video cards support VESA natively and don't need drivers, except intel.

I see absolutely no reason to EVER do a repair...

If windows is trashed so badly that you are considering a repair then a reload is the only viable solution. The result of a repair is a complete disaster as far as registry and related windows files are concerned. I'ts kinda like repairing a nail hole in a bald tire. Why bother patching something that is beyond repair, just replace it with a new one and fix it properly.

If you insist that a repair has to be done in certain instances then I would have a separate disc just for that. That way you can have an unattended install disc and a repair disc. If you are talented you could have a multiboot disc with both attended and unattended on it.

Thanks for all the feedback, this is really good stuff guys!

in his profile click "Send Email"... or on one of his posts click "Email"... it will bring up a form and you can enter your query and send it

at the bottom of our home page is a "contact" link that takes you here http://driverpacks.net/contact...

I'm sure i can find a dozen other ways to do it...

We get enough spam without posting email addresses in the public forum (we are very popular with Google)

email Wim, via forum mail feature, and let's find out (link to this thread)

I now know why your output for SAD is not the same as Somebodys....

Somebody told us to use Method 1 (M1) you chose Method 2 (M2). Well perhaps you did not choose it, since it is the default. BUT the solution is the same... You need to choose M1 for SAD .

In order to boot non standard controllers it is neccessary to FIRST (before you even load your VM with windows) Slipstream the mass storage drivers into the source that you will be useing to load your VM with. *See tutorial in my signature for this* (only add mass storage Textmode at this point). Once you have added the mass storage drivers you may then follow Somebodys guide.

Pig apparently did not copy the files from the DriverPacks.net folder correctly...

yes that was my proposal.

you asked "What's DPSFNSHR anyway?" So i expained it.