Topic: DPInst with DriverPacks on network repository

Just thought I'd start a post about this since I've been working on this for a little while, with limited success.  Thus far, I've tried running DPInst from C:\ and I've also tried putting DPInst on the share and running that directly.  Access to the share out of the equation (read-only access is set up, and appears to be working fully as intended), I'm having a problem with the AMD CPU drivers, and (though unconfirmed) nothing else.

As it is, I get a prompt from the Hardware Installation Wizard that there was a problem installing this driver and it won't be available until after the next restart.  I have tried "/c /s" as the parameters and used the DPinst.xml file included, and have ALSO tried changing to using the parameters "/c /s /sh /sw /path \\<network server>\Drivers".

I have changed the DPInst.xml file to only have the <search> and <subdirectory> parameters, using "*" as the directory as per the DPInst information on Microsoft's site.  That doesn't really seem to make any difference to the CPU driver though, just things I've tried.

So far, I am of the thought that if I remove the CPU drivers from network, things should work just fine.... but I didn't have one oddity in my testing that makes me question just how well all of this is working.

I tried to leave the CPU drivers on the local computer, and run DPInst (also locally) on the local path (C:\D\CPU).  It had worked before in testing using all DriverPacks together, so I thought this would be a non-issue...  then I got the same error message.  I actually had set up two completely separate entries in ROE for DPInst, one that used a copy of DPInst.exe and DPInst.xml on C:\ and pathing to C:\D\CPU.  I hadn't even gotten to the second run of DPInst (which was completely contained on the network server) when I again got the same error.  It most likely was something I did that is the problem here.


Now that I'm thinking about it, I might not have tried with the XML file supplied with DPs_Base for the CPU-only set of drivers on the local machine.  This I cannot say for certain, but I do think it would be a good idea for me to try that again tomorrow when I get a chance.

I'll try to keep you all up-to-date on my status on this implementation and any idiosyncrasies I run into.

Re: DPInst with DriverPacks on network repository

Stuck

DP BartPE Tutorial   DP_BASE Tutorial   HWID's Tool     Read BEFORE you post    UserBars!
http://driverpacks.net/userbar/admin-1.png
The DriverPacks, the DP_Base program, and Support Forum are FREE!.

Re: DPInst with DriverPacks on network repository

NOTE:  The steps listed here can potentially open your server up to unwanted access from anonymous users.  Please, please read the documentation from Microsoft about Null Session Shares, Anonymous Access, NTFS Permissions, and Sharing Permissions and understand what it means to allow them prior to using these steps.  These steps are meant to be a simple set of steps to make sure you can get everything up and running with minimal effort, and does not take into account the myriad threats that may exist within your environment.  I cannot be held responsible for any security attacks that result from using these steps.  Keep in mind, this is not the ONLY way of accessing drivers across the network, but it does make it the most seamless as I can imagine doing it.

Here are the steps to make a share on a Windows server so there is no authentication needed and no complex scripts are required either (don't worry, I'm pre-med... or was that pre-law?):

1.  Go into Computer Management (either right click My Computer and use Manage or Start > Run > compmgmt.msc).  Navigate to Computer Management (Local) > System Tools > Local Users and Group > Users, and then enable the Guest account.  If this server is a domain controller, you'd have to do this in Active Directory Users and Computers instead, but I'd highly recommend against doing this.  Instead, use a member server or you may have unwanted access to computers via the Guest account elsewhere.

2.  Extract the DriverPacks to a folder on your server.   Keep the INI files and make sure to keep the D folder as part of the folder structure.  E.g. On the server I used, I made a folder at D:\Drivers.  Inside of that are all the INI files and the D folder which contains the C, CPU, etc folders.

3.  Go to the properties of your Drivers folder, go to the Sharing tab, and enable Sharing.  Use whatever you'd like for your share name (I just use Drivers).  Whatever you use here, remember for later on in Step 6.

4.  Click Permissions.  Here, you'll want to explicitly add Guest with Read permissions to the share.  Make sure you are adding the local computer's Guest account, and not the domain Guest account.  I also remove Everyone from the list.  The only time this share will ever be used by me is when I'm imaging and read-only access is all I will ever need.  Click OK after you have added Guest and given it proper permissions.

5.  Click the Security tab.  Here we'll want to add the Guest account and give it Read & Execute permissions.  Note that this is different than Sharing permissions, and if you don't understand the difference, you'll want to do some reading on what the differences are.  I tend to explicitly state what a user can do in both Sharing and NTFS file permissions.  Again, make sure you are using the local Guest account, and not the domain Guest account.  Click OK to accept changes and close the properties window for your shared folder.

6.  Now for adding this share as a "Null Session Share".  Open REGEDT32.exe and navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters.  Open the value NullSessionShares and add a new line at the end with your exact share name used in Step 3, including the trailing "$" if you were making a hidden share.  Make sure you don't remove current data in the value (should already have "COMCFG" and "DFS$" and possibly more depending on your config).

7.  Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.  Create a new DWORD named restrictanonymous if one does not already exist and give it the value of 0.

8.  (XP/2003) There is also a DWORD setting at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa for EveryoneIncludesAnonymous.  The default of 0 is used to differentiate between authenticated and anonymous users.  If you leave this at the default of 0, you MUST explicitly give the Guest account access to each individual resource, including file permissions and share permissions (as I stated that I use above).  If set to 1, this is optional and you may use the Everyone account, but I would suggest you allow for the XP and 2003 security mechanism to function as intended.

9.  Reboot your computer/server and you should be able to test your share by using this command:  NET USE \\<servername>\Drivers /user:""

Re: DPInst with DriverPacks on network repository

Well, it appears that DPInst isn't installing the AMD CPU drivers properly at all.  Not sure the key to it at the moment.  Going to test making an image and pushing it to another computer and see if the other drivers are installing properly or not.  As it is, there's next to nothing to install on the VM.  I'll try this out tomorrow.

Re: DPInst with DriverPacks on network repository

http://bugtracker.driverpacks.net/view.php?id=432

there is a bad file in the MassStorage pack it has been reported at bug tracker, waiting on someone to fix it

DP BartPE Tutorial   DP_BASE Tutorial   HWID's Tool     Read BEFORE you post    UserBars!
http://driverpacks.net/userbar/admin-1.png
The DriverPacks, the DP_Base program, and Support Forum are FREE!.

Re: DPInst with DriverPacks on network repository

This doesn't apply to the CPU driver which is the only one I'm working with locally right now.  It just isn't installing the whole driver or something.... the first INF it looks at it finds no corresponding hardware, and the last two it installs fine.  I'll have to get the log when I'm back at work.

Ah, looked at it a little closer and saw that it appears to include a CPU driver there, but I'm not using that at all at that point.  On the hard drive for the local run of DPInst includes only C:\D\CPU, nothing else in C:\D.

Last edited by DeTard (2008-05-14 10:00:05)

Re: DPInst with DriverPacks on network repository

but you are adding mass storage drivers to your install from the pack so they are there before you add cpu ... yes?

so you are haveing the same issue... which is why i pointed it out wink

DP BartPE Tutorial   DP_BASE Tutorial   HWID's Tool     Read BEFORE you post    UserBars!
http://driverpacks.net/userbar/admin-1.png
The DriverPacks, the DP_Base program, and Support Forum are FREE!.

Re: DPInst with DriverPacks on network repository

Ok, tell ya what... tomorrow I'm going to try the same process with DPInst prior to using the MassStorage DriverPack injected with OSP.  You may be right about this, but I'll be honest, it would definitely surprise me if everything suddenly works afterwards.  The thing about the driver there is that it's not a CPU driver, it's a RAID driver for on an AMD 64-bit system.  It would really be odd if it conflicted with the separate CPU driver wouldn't it?

Thanks for the heads up, I wouldn't have thought of it otherwise.

If this really does work afterwards though, I'm going to remove that INF file and rebuild my BartPE ISO and re-inject drivers again.

Anything else you can think of to try?



Oh, and while I'm here, is there any way to suppress errors from DPsFnsher.exe?  I have the INI set to disable KTD, and of course it's trying to delete the drivers after everything completes (I'm pretty happy now that I made the share read-only!) and it tells me that the INI files on the share cannot be deleted.  The error does go away after some seconds, but just wondering if there was a way to suppress it all.

Last edited by DeTard (2008-05-14 11:19:47)

Re: DPInst with DriverPacks on network repository

not that i am aware of - sounds like a valid "feature request"

finisher ini option - skip driver removal.


PS lots of odd things happen with drivers sometime even "impossible" things

DP BartPE Tutorial   DP_BASE Tutorial   HWID's Tool     Read BEFORE you post    UserBars!
http://driverpacks.net/userbar/admin-1.png
The DriverPacks, the DP_Base program, and Support Forum are FREE!.

Re: DPInst with DriverPacks on network repository

*cracks whip*  Go code monkey, go.

Re: DPInst with DriverPacks on network repository

well where is the post requesting the feature??? lol... waiting on you to cross the T and dot the I

DP BartPE Tutorial   DP_BASE Tutorial   HWID's Tool     Read BEFORE you post    UserBars!
http://driverpacks.net/userbar/admin-1.png
The DriverPacks, the DP_Base program, and Support Forum are FREE!.

Re: DPInst with DriverPacks on network repository

http://forum.driverpacks.net/viewtopic.php?id=2700

Re: DPInst with DriverPacks on network repository

Well, my results weren't at all what I wanted to see unfortunately, which means OverFlow's theory on the cause isn't right. hmm

If I try to run DPInst with the CPU drivers on the server, and didn't inject the HDC drivers, and removed the so-called "crap-inf" file from the Silicon Image RAID controller folder, I still do get the message about the driver not being available until restarting the machine, which in turn stops the whole process until I click OK.

If I run it on just the local drive, it goes through without error still, but it STILL isn't installing the driver properly.  Here is the DPInst.log file from the process:

INFO:   ****************************************
INFO:   05/13/2008 14:19:33
INFO:   Product Version 2.0.1.0.
INFO:   Version: 5.1.2600 Service Pack 3
INFO:   Platform ID: 2 (NT)
INFO:   Service Pack: 3.0
INFO:   Suite: 0x0100, Product Type: 1
INFO:   Architecture: X86.
INFO:   Interactive Windows Station
INFO:   Command Line: 'DPINST.exe /c /s /sh /sw'
INFO:   ****************************************
INFO:   Option set: dumping log info to console.
INFO:   Current working directory: 'C:\'
INFO:   Running on path 'C:\'
INFO:   DPInst.xml does not list the current UI language.
INFO:   User UI Language is 0x409.
INFO:   Install option set: Suppressing Wizard but no OS popups.
INFO:   Install option set: Running in quiet mode. Suppressing Wizard and OS popups.
INFO:   Install option set: Suppress pre-install of Plug and Play drivers if no matching devices are present.
INFO:   Found driver package: 'C:\D\CPU\AmdAway.inf'.
INFO:   Found driver package: 'C:\D\CPU\amdk8.inf'.
INFO:   Found driver package: 'C:\D\CPU\AmdPPM.inf'.
INFO:   Preinstalling 'c:\d\cpu\amdaway.inf' ...
INFO:   ENTER:  DriverPackagePreinstallW
INFO:   Looking for Model Section [AWAY_MODE]...
INFO:   No matching devices found in INF "c:\d\cpu\amdaway.inf" on the Machine.
INFO:   RETURN: DriverPackagePreinstallW  (0xE000020B)
INFO:   Preinstalling 'c:\d\cpu\amdk8.inf' ...
INFO:   ENTER:  DriverPackagePreinstallW
INFO:   Looking for Model Section [AmdK8.NTX86]...
INFO:   RETURN: DriverPackagePreinstallW  (0x103)
INFO:   Preinstalling 'c:\d\cpu\amdppm.inf' ...
INFO:   ENTER:  DriverPackagePreinstallW
INFO:   Looking for Model Section [AmdPPM.NTx86.5.1]...
INFO:   RETURN: DriverPackagePreinstallW  (0x103)
INFO:   Returning with code 0x0
INFO:   05/13/2008 14:19:34

Now, you'd think that that meant the driver isn't going to work on this machine, but if I install the driver manually through Device Manager, it installs fully and without incident.  I'm going to give this a try with DEVCON I think and see if I can make an exception for this one driver and move on.  Not sure at this point what this all means.

Re: DPInst with DriverPacks on network repository

Interesting....  Just put the path to the CPU drivers in my DevicePath in the registry, and even had DSPdsblr.exe running during Mini-Setup.  The driver just didn't install at all for me, was using the Microsoft driver from 2004 instead.  Which is ironic because if I have it automatically find the driver after booting up, it sees it and has no signing issues or anything.  I think it's a problem with the driver itself, not with DPInst, or anything else.  Might not be resolvable as a result until AMD puts another version out there.

Re: DPInst with DriverPacks on network repository

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.

Re: DPInst with DriverPacks on network repository

Thanks for keeping us in the loop... I am sure, as a group, we will win this...

Sorry my info was not the answer we had hoped for...

you mentioned a new driver as a fix... perhaps an old driver is a fix?

DP BartPE Tutorial   DP_BASE Tutorial   HWID's Tool     Read BEFORE you post    UserBars!
http://driverpacks.net/userbar/admin-1.png
The DriverPacks, the DP_Base program, and Support Forum are FREE!.

Re: DPInst with DriverPacks on network repository

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.

Last edited by DeTard (2008-05-16 02:11:17)

Re: DPInst with DriverPacks on network repository

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.

Re: DPInst with DriverPacks on network repository

Keep the good work dude, when you get the solutions I could modify the pack especially for you. big_smile

Re: DPInst with DriverPacks on network repository

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.

Last edited by DeTard (2008-05-16 04:29:01)

Re: DPInst with DriverPacks on network repository

You should use Sysprep Driver Scanner instead of DevPath.exe

Re: DPInst with DriverPacks on network repository

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.

Re: DPInst with DriverPacks on network repository

I just thought of something as I was responding to a new OP in another thread.

It may be to your benefit to use one or more of the features i detailed.
 
M1 for your source which reduces the servers file/folder size by 1 gig
although it does take a long time to extract and cab each pack the first time
if you have Quick Stream Cache = on (QSC = on) then each pack will only be cabbed once (and cached).

Then it occured to me that if you used your network drive as the destination of KTD
then it may not even be neccessary to run dpinst because windows would just automagicaly search the network folder.

i belive this will work... 

IDK if cabbing is a waste of time or not - that is obviously a personal choice for sure. - a time vs. space choice.

In the other post i highly recomended it because he is keeping the drivers localy on the c drive.
I think i would at least put them on a small tertiary partition, but whatever works is good too. wink




http://forum.driverpacks.net/viewtopic. … 733#p20733

DP BartPE Tutorial   DP_BASE Tutorial   HWID's Tool     Read BEFORE you post    UserBars!
http://driverpacks.net/userbar/admin-1.png
The DriverPacks, the DP_Base program, and Support Forum are FREE!.

Re: DPInst with DriverPacks on network repository

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).

Re: DPInst with DriverPacks on network repository

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.