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.

Wow, just found something very very cool for you Ghost users...   Symantec Ghost Solution Suite 2.5 now supports using a VDMK file as your image file directly, though you cannot use Ghost Explorer to open it.  But digging through the help file (yes, amazingly I'm a male IT person reading documentation, go figure), I found that there is a new switch that can be ran on GHOST32.EXE.  If you use "/AD=<full path to VDMK file>" you can specify a VM disk directly and it'll show up in your list of disks to send an image from.  This means no more booting from a DOS-mode ISO within VMWare Workstation, which means no more 100% non-throttled CPU usage.  Testing it right now as we speak and so far I'm very impressed!!

Edit:  I put this here as a response to the convo about using VMWare Converter, which didn't seem to work for me.  This isn't really a Driverpacks topic, but it's big enough news for me, and not sure where else to say it. smile

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


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.

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.

Helmi wrote:
DeTard wrote:

T's dotted?  Check.
I's crossed?  Check.

[OT]Isn't the old naval saying more like "Crossing the T"?

Hehe, yes... I was being sarcastic, in two ways at once. smile 

OverFlow wrote:

As i think about this more i belive i will create a new platform button "Create Drivers Only CD".

this would dump a M1 style folder structure (less the $OEM$\$1\)
to a selectable location with the DP_finisher files and DPInst (Identical to a M1 layout)

I belive this is better than modifying qsc because QSC is disigned to hold more than one version of each pack.
where as a destination folder will only contain the most current.

this will aslo tie in with possably supporting the attended install...

And yes, I agree Jeff...  Making a whole new section of it and keeping QSC as-is might be the more correct way of doing it since it really isn't part of the same goal, and I hadn't even thought about the multi-version detail of QSC.

As I'm working on the process to host all my drivers from a network repository, being able to easily re-process the QSC without going through with a slipstream to a source could become necessary, otherwise I'll have to keep a dummy source out there to re-run it.  I'm not sure of any other use for it other than putting it on the server, but then again, this is what matters to me at the moment. smile

And as per conversation, possibly make it so that the QSC options can accept a folder destination (possibly directly to a UNC path if needed).  And even the option to create an extracted DP-style directory tree (called "Consolidated QSC"?).  Not sure.

T's dotted?  Check.
I's crossed?  Check.

You still clearly are not getting the point here.  Ok, first by "different platform" he is talking about an attended setup.  Yes, YOU want one little checkbox to be a convenience so you don't forget to remove a few lines from a file.  But he is suggesting doing it the right way - if you are going to do something that would imply an attended setup, why wouldn't you do everything else that it might entail?

And then when he does spend all that time in front of a computer typing code to do things the right way?  Then the rest of the testers have to spend countless hours making sure it works in all cases, or if not, noting where it breaks.

Sure, you are helping, but only in suggesting a new path for where BASE will take us.  It's a big topic, don't trivialize it.

Jaak, got a link to this "DUPEFINDER"?  Only one I see is in Linux.  I usually use Easy Duplicate Finder, but it doesn't have a setting to do a simple file name check, it actually does a true duplicate file check only with no other options for it.

Ok, doing my first M1 integration.... remember that talk about how I use the PNP switch regardless, and then go about my business doing other things while I wait?  lol, seems M1 tries my patience a little more.

Gonna give it a try...  but lets be honest, I can see what you are doing here.  You want me to go through the 3 hours of rebuilding my image to point out that Sysprep is not the way to go with deployment, aren't ya?!  lol  wink

What you say makes sense, but just wondering how it's going to handle things when it comes to NIC drivers since obviously if they aren't installed it won't be able to do that search path.  This might be interesting how this all goes though... never thought about doing a KTD to the network share.  Though that's going to be a major pain in the butt when all I'm trying to do is update my image from time to time... maybe I'll tell it to KTD to a "temp" Drivers share at the exact same UNC path with maybe a modification of the HOSTS file so it thinks it's going to the server, but rather pointing to my host OS, then remove the HOSTS entry.  It's a thought anyhow, and it'll store the UNC path just the same, and still pull from the same path "automagically".

My question is, why would it save 1gb on the server using M1?  Sorry, I am an M1 noob, clearly.  I don't know how it works exactly, I've pretty much always used M2, going back a couple years now.  M1 always seemed to be a lot more inefficient, but maybe I was missing the point of it.  That and I was making physical CD's rather than ISOs that are mounted which can be infinitely big (within reason of course).

Well, the odd thing is, installing from INF from directly in the Hardware Update Wizard and it works perfectly - and that is from either the drivers I linked or from the ones included in the 8.05 DP.  Apparently DPInst isn't the absolute same thing as installing from Device Manager as some have said, or possibly I'm using it wrong (though there really aren't a lot more options to set from the ones I have tried).  Not really sure where to go from here unfortunately.  I really really don't want to put the DriverPacks back into my image and have Mini-Setup do the installs for me, that will grow my image by approx 600mb.  hmm

Well, it appears that the drivers for the ATI IDE controller don't want to be installed over the Standard IDE drivers.  I'm going to try again using DPInst with the forced flag and with legacy mode and see if that'll let it update.  It's not a signed driver, so the hardware update wizard sees the standard drivers as more suitable.  *sigh* back at it again.  Be back later when I get a chance.

I'm using SP3, and not including 888111 in my install manually (so not downgrading what should already be there).  And btw, I just tested this out using the driver from the link above, and it did the same thing.  Hrm, I think you are right, it isn't a driver issue, it's a method of installing the driver.  E.g. OverFlow's fault.

unseen, I'm going to take back what I said about the dupes, I'm getting them too it seems.  I'm going to keep my image the way it is now, but also add in the MassStorage drivers locally for use at Mini-Setup and see how that goes.  Hopefully that resolves it.  Not ideal in any way, but I'd rather see the computers using the proper driver rather than some compatibility driver.  Will post again here with my results.

Hey guys, having a problem with the above device using Sound B 8.05 DP.  It installs just fine using DPInst, but no sound can be produced (Windows is just using the Beep driver for everything).  It's under the SMD4 folder where it's being identified, and Windows says the device is working properly, but under the Properties tab of the device, and then properties of each of the multimedia device in the list, you'll see the problem here:


Here's how it should look:


I downloaded the drivers from this link:
http://support.dell.com/support/topics/ … ile=172546

They are from 2006, not from 2007 like in the DP, but seem to work fine.  I have also sent these to JTDoom in a zip file.

Yes, you do need the drivers added to your image at some point, but you don't need to integrate your original install of Windows to make it all work.  Remember, I've been trying to find a good use for OfflineSysprep in my implementation (as it is, it was meant more for someone using WinPE, which I am not using), and the injection of HDC drivers makes it absolutely golden to me.  Is it required for me to have my image work though?  No, it's just relieving a BIG amount of work needed to maintain my images.

Before, I had to use a script to parse all the HDC INFs to get a list of paths and HWIDs.  From this list, I would have to remove all the references to drivers that are for 2000 or 2003 and not for XP.  Then I would have to remove all the duplicate HWIDs.  Add on to that, some drivers cause problems with Sysprep (such as the V and V4 folders, and even more recently the SC folder containing the AMD64 driver which can easily be removed).  All of this work is unneeded if you inject the drivers from OSP.  This method also makes it so it doesn't install services that are unneeded and that can be installed by Windows later when it's required.

Just remember, install only what is needed for your VM to work ok, then update to your Standard IDE drivers, and then make a snapshot before executing commands like Sysprep and setting up your ROE.  Typically, my snapshots are one from right after installing Windows, one from right after installing .NET (1.1 through 3.5 in my case, with reboots between each version) since that is kind of a critical point, and right before booting into OSP and injecting drivers.  Then one from right before Sysprep (actually have command lines open with all the commands I'm about to run right there so all I have to do is hit Enter... leaves very little room for error that way and this is the most critical point of your whole image), and one after Sysprep shuts my VM down.

Don't worry, if you make the drivers available, either via SysprepMassStorage or via OSP injecting drivers, so long as you have Standard IDE set, you should be ok.

Ok, guess I'll give that a try from now on... for the time being, things are good though as I again am using C:\D.  That may change, not sure yet.

Anyhow, I got the AMD drivers to load!  The trick was removing the amdk8.* files and running DPInst on just this directory without scanHardware (though I would HIGHLY recommend using that flag elsewhere so you don't have every driver copied to your somewhat clean image).  Also, I had to copy AMDPPM.SYS to AMDPPM64.SYS as the driver install will fail without this file existing.  The file just has to be present, it isn't even used, and doing a search through the registry shows that there are no references to it, so I don't believe me cheesing my way through that one will have any impact on any computers I deploy to.  Anyhow, I had to run DPInst twice, once for the CPU drivers, and a second time using scanHardware on everything (having it look through everything, which included the CPU drivers again, but this time with different settings, didn't appear to have any negative effects).

I did this on an Intel machine using a Core 2 Duo didn't show any improper install, with it still using Microsoft's CPU driver.  I don't have any non-Intel, non-AMD systems to test on though, so YMMV.  It appears I'm well on my way to having a totally universal image.

lol, Yes you are correct, it was the shade, though it's WC3, not WoW3 smile

I'm not really sure why you are seeing the dupes in there.  You said you were using VMWare, which I am using as well, so not sure where you are getting those from.  The difference I guess is I'm not integrating the DriverPacks into my install, and I would suggest you don't either if you are using a Sysprepped image.  That's not really needed as what you are planning on doing is using Sysprep to identify the basic devices and then have DPInst pick up after Mini-Setup to install all the remainders.

On my VM, I don't even have video drivers loaded, nor do I load the VMWare Tools as I don't want them to end up on every non-VM machine afterwards.  I still get to run at 800x600 on XP, though on 2000 I actually do load just the video driver for VMWare as the Java control panel doesn't function properly without at least 800x600 and 16-bit color.

I did make a LOT of headway on the DPInst on Network today though... I'll post more over there on that thread.

Oh, found a bug I forgot to mention last night...

Originally I had tried to put the CPU drivers in the Windows folder (C:\Windows\CPU), and went to run DevPath on it.  It didn't error or anything, but it didn't update the DevicePath value either.  It did, however, work just fine when I ran it on C:\D.  It was only one folder, so I manually entered it into DevicePath, but not before I went through Mini-Setup once without any results and went on to investigate why it didn't see the driver.

Yeah, so I'm going to put this in it's own topic in the Bugs forum. lol Not sure why I decided to put it here.

Just found out one other tidbit - if I run DPInst without the scanHardware flag (whether by XML tag or by command line parameter), it will make the attempt to install the driver and give me the error about it not being available until restart (even in silent mode).

And yet another thing that seemed to get me a step closer to the solution.  I removed amdk8.* from the folder.  I then added a second <subDirectory> for the CPU directory (I want to run with different parameters for this directory... get to that in a second).  I want to run on this directory WITHOUT the scanHardware flag, apparently this driver isn't PnP, so the attempt to install is effectively nil if it tries to see if it's useable.  I think the Hardware Update Wizard does it this way as well, it was the only way of installing the driver before I figured this part out.  So installing with the parameters "/c /s /path C:\D" (don't path to C:\D\CPU or that will fail, you have to specify the last directory for it to look in within the XML file, so effectively when I say C:\D it looks for C:\D\D and C:\D\CPU and only the latter one exists) seemed to install the latest driver fine.  amdk8.sys appears to be an old driver while amdppm.sys is new and "should" work on all AMD CPUs, K8 or better.

Now the only problem I may have is it might try to install this driver on a non-AMD system.  I'm going to try this out within the next couple hours.

Might want to post the exact BSOD error code too.  Could be something unrelated to the NTLDR memory issue.

lol.... and TOTALLY unrelated to anything, everytime I look at your username I think "I go unseen...."   Guess the game where that is said repeatedly. wink

Yeah, see I had thought about that, but I do not know at what point I can just simply run DPInst safely.  Clearly, it works by the point of ROE, but if I could run it from Mini-Setup that would be great.  I would still need to have LAN drivers locally, that I will never be able to get around for (I hope) obvious reasons, but I'd like to do as much as possible before the GUI loads.  Then again I've never tried to run anything during Mini-Setup, so not sure where to begin (is it just simply a SVCPACK thing?).

And just a lil FYI, I don't use the DP_Install_Tool.cmd for my implementation, I just use the direct command in ROE. I make a 936 key, and make a "1" string in there with "C:\DPInst.exe /s /sh /sw /path \\<servername>\Drivers" and just let it run like that, hidden.  If I run into problems, I just look at %windir%\DPINST.LOG.  Or sometimes I set "1" to be "CMD.EXE /C (C:\DPInst.exe /c /s /sh /sw /path \\<servername>\Drivers)" if I'm sure of errors and want to see it as it runs.

I had thought about an old driver as well, but then we're losing support for the newer CPUs, which also defeats our purpose.  I might write an email to AMD and see if we can get any reasonable fix for this as I'm sure they would want as much support for their products in large environments as possible.  I might even look at the INFs and see if they have a simple syntax error or some such that utilities might be a bit more sensitive about.

LOL, just thought I'd share this thing I just ran into.  I forgot a small detail about imaging a computer and having it pull drivers from the network: You need to have NIC drivers loaded for it to find the network share.  DOH!  Hah, so yeah, I'll have to include the LAN DP on the local hard drive too, but everything else will be possible to keep on a server.  I'm going to also leave the LAN DP on the server too, so it can update drivers to the latest (and sometimes greatest) drivers that I have uploaded without having to update the image file.