DPInst with DriverPacks on network repository (Page 2 of 6)

Well...  I was going to try an M1 install, but I don't want them integrated into the image itself (I mean, this is network repository right? lol).  It did create the QSC for me though, and saved me about 1GB of space on my server as a result when I transferred those files over.  The problem I'm running into is that DPInst is a bit... well.... "lacking" would be the word I'd use.  It doesn't seem to install drivers nearly as well as Mini-Setup does, and one thing that was overlooked when OverFlow and I were talking about this was that Mini-Setup isn't capable of having network support.  And no, as we also found out, you cannot pass a "DetachedProgram" parameter to Sysprep - it really is "Mini" when it comes to the setup, because the portion of setup that would normally run the DetachedProgram parameter isn't even initialized for this.  So there isn't a workaround for network support during Mini-Setup meaning I would absolutely rely on DPInst (or something similar if someone used a different program).  Now, one thing I am wanting to try is the program by another member on here (sorry, drawing a blank at the moment and too tired to even try to search for who it was), but not sure how well that's going to work just yet as it's definitely a work in progress at this stage.

Ok, just wanted to point out something that I ran into when testing all of this....

DO NOT LEAVE YOUR VM RUNNING WHEN YOU ARE TESTING IT ON ANOTHER COMPUTER!

By some fluke chance, I had an IP conflict that screwed up my DPInst run part way through and I never saw it.  Thought I was having problems with driver detection having to do with HWIDs, but turns out it might have to do with actual network connectivity.  SOOOOooooo yeah, going to test this again in a few minutes.  Yes, I know, by the magic of DHCP I shouldn't have this kind of problem, but for some reason I did manage to pull the same IP address for both a laptop that hasn't been on in several days as well as a VM that was just created yesterday.

Last edited by DeTard (2008-06-04 01:24:02)

Just wanted to post an update to where I'm at with all of this...

So, as much as I'd LOVE to put the drivers on the network and run them from there (I really feel this is a great idea), I hate DPInst.  DPInst just doesn't seem to install drivers as effectively as running the detection through Mini-Setup.  Yes, it would greatly reduce the amount of space taken up by my images, and would be a whole lot easier to keep them up-to-date, but I've ran in to too many problems with using DPInst.

First, you have to obviously have the LAN drivers put into the image locally.  You can't get around this really unless you are booting from WinPE or some such PreOS.  This was more me overlooking the obvious than an actual problem with DPInst.  Whoops.

Second, if you do keep the LAN drivers on the network (in addition to locally in my case), chances are that it will kill your network connectivity for a moment.  That moment might only be for 2 seconds, but DPInst is still trying to install drivers while the network is down, and will fail every one of those driver installs.

Third, it seems it's not just LAN drivers that will kill your network connectivity as some drivers (particularly chipset) will have to reinitialize some hardware component that will drop your NIC (such as the whole PCI bus in the case of chipset drivers).  It's almost impossible to figure out what drivers will need to be kept locally so that this will not happen.  I ran into so many problems with it that I moved on to the next thing.... SFX archives.

Okay, so I started by using a 7-zip SFX archive... and that was going along well.  Found a modified SFX module (http://7zsfx.solta.ru/en/) and went from there.... but DPInst simply would NOT install drivers for me.  For example, the 845G graphics driver was showing as being installed, but nothing really happened.  The sound for the same machine also was not installed.  But yet, using the Update Driver interface from within Device Manager installed it just fine with no signing errors or warnings.  Even by trying to force the installation by removing the "ScanHardware" flag and turning on legacy mode didn't help.  I'm sure in many many cases that DPInst would work great... for me, it did not.  It simply took way too much of my time to make the little bit of time it would have saved me moot.

Though I may not be using this across the network any longer, I'll still keep trying to come up with other ideas on how to implement this, and I do hope this topic has helped someone out there anyhow.

Hmm we like crazy!

This sounds very much like the recovery partitions on Dell & HP.  Which ISN'T a bad thing (TM)  I actually quite like the idea and would love to sit down one day and make something similar but using my work image...  Hmmm.....  Damnit Mr overflow you've got me intrigued now!!!!

Bah... And I was going to have a quiet day today!!

On a mission to re-educate users the Clue stick way!

An offline sysprep to inject the drivers you only need really is the way to go with this. As annoying as it is.

Last edited by stamandster (2009-03-04 00:06:54)

LOL, SysPrep hater

Ian

Yes he does hate sysprep. I agree that a fresh install is much cleaner but sometimes you have to use sysprep or something similar.

Last edited by stamandster (2009-03-05 00:36:49)

Sorry Jeff, I'm not able to really test Sysprep all too often anymore as my job has changed companies and my responsibilities have evolved. But when, and if, I get a free moment (from the wife, child, house and life) I'll test it

The way I used to do it is only install driver with sysprep that I needed in order to boot and function, network, mass storage and chipset. Everything else was done with an post sysprep mini setup (with either my installer or something else).

Newsid can regenerate new SID and you can command line the workstation name you want.

And basically then we'd need a join domain script, easy enough.

But then find a way to get it so the imaged Windows install will boot with the new hardware without frakin.

Here's a deal with sysprep, it can use both OemDriverPath in the INI and Registry import location. But if you can import the driver locations into the registry you can also install drivers using the windows driver installation DLL too. But its something way different for the mass storage drivers.

Last edited by stamandster (2009-03-05 05:56:52)

What is your thought on making it so the system boots properly with the correct HAL and mass storage drivers?

Yeah MySysprep still uses sysprep lol. But we could do something with editing the boot.ini. I mean it would be a manual process of editing selecting the HAL.

Or you can select a basic HAL that works with both multi and uni processors (which you do anyways before sysprepping).