Search options (Page 66 of 159)

That's actually a valid point.  And something that I can test as well.
My site has nearly a 1000 users.  We also use an AD network (biometric Common Access Card-CAC logins) with GPO using Security Groups.  Anyone logging in with any elevated privileges other than "user" gets denied access to the proxy server.  So admins can have access to the shared network drives, but denied access to the outside world.  Pings and Traceroutes to common sites DO work (sometimes), but no traffic is allowed. 

I'll smuggle in a copy of DriverPacks BASE and test in both user and admin access on our network tomorrow and report back.
We're in the middle of upgrading all our Vista workstations to Win7 (finally!) so even if I blow it up, I'll just wipe it and install Win7 fresh.

Ah, there's the problem.  I've had this argument with our administrators the the nth degree.  With DriverPacks, there are no absolutes.
It's greatest strength is also it's greatest weakness.
DriverPacks is a community project.  Yes, we have a small number of core developers and a larger group of testers BUT (and here's the kicker) we cannot guarantee 100% "chain of custody" of the drivers.
I can personally vouch for about 90% of the drivers that are directly sourced from the OEM vendors themselves, but lots of hands have been in these cookie jars.  It's these unknowns that scare away the organizations that require the utmost security.  That saddens me.

I built the LAN-RIS Third Party DriverPack myself and I can guarantee that ALL the drivers were directly sourced from the vendors BUT only roughly half of them are digitally signed.

And this is the main reason that my organization refuses to use DriverPacks.  They insist on gathering the drivers themselves.  Ah well.

The AHCI controller is on your motherboard.

Please?

Your post told me nothing about your HDD controller. As a result, nothing in your post can help us help you.
Please read the "read before you post" linked in my signature.
Then post your HWID list and DPs_BASE.log here.

I know it's a long shot, but can you try this driver (it's for Vista, but might work)?
Or this older one:

LOL, I just couldn't help but laugh   You two are so similar in demeanor!

YES.  An update is being developed with the downloads in mind.  However no timeline is given.

Considering what you said about the large array of PCs available to you for testing...would you have any with nvidia RAID controllers?  We're in desperate need of Nvidia testers in this thread.
I'd be grateful for any feedback you'd be able to provide.

I make it a point to ALWAYS include the txtsetup.oem file in dpms (when possible) because it contains some valuable info that the .inf does not.  Like you said, it's easy enough to write a script the seek out and rename them all if you need to.

LOL, and I had just moved it onto the main server too.

WRONG!  DriverPacks Finisher does NOT install drivers!  It only executes tasks set in the DPsFnshr.ini only if certain criteria are met.  It does NOT install missing drivers.
DPinst.exe WILL do what you are asking.  It will install missing drivers, which is what we programmed it to do in the DP_Install_Tool.cmd file.

Sorry, my mistake.  The OEMpnpDriversPath limit set by Microsoft is actually 2047 characters, not 2048.
Read: http://support.microsoft.com/kb/285902

So I am still confused about what problem you are having or what you want to accomplish.  Sysprep is not my strong point (I don't use it).
1) Does the Nvidia control panel install normally during a normal disc-based install with DriverPacks integrated (either method-1 or 2) using DriverPacks BASE?
2) If not, please post your DPs_BASE.log and DPsFnshr.log (zipped/uploaded to mediafire.com)

You are trying to use tools for things they were not designed for.

Actually they are NOT missing.  The .inf file renames certain source files INTO those files during the 'copyfiles' phase of installation.  So while they APPEAR to be missing, they will not be missing during the installation.
Example:

[alta.CopyFiles]
*name-of-file*,*file-to-copy-from*,,*destination_dir*
dlh5x.sys,dlh5xnd5.sys,,2

Did you try the DriverPacks?

You could always download the driver from Dell.com

From what I understand, the problem with sysprep is that it has half the normal size allocated to ram for caching the drivers. (4096 for normal install, 2048 for sysprep).  File path limits in sysprep is a known issue.  You have to be VERY selective in which drivers you choose to use in sysprep.

When I slipstream drivers into Vista/Win7, I only use dpms, Chipset, & LAN.  I use SAD for the rest post-install.
I'm certain you'd have success by following the same procedures for sysprep.  Limit your sysprep-installed drivers to ONLY dpms, Chipset & (maybe) LAN, and use the dpinst cmd file for the rest.

You can call DriverPacks Finisher at any point during GUIRunOnce or RunOnceEx (or after).

You can have DriverPacks Finisher execute AFTER the first desktop loads by using a trick suggested by our forum member Ricktendo64.
Here's an example for how I execute WPIW after the first desktop loads.
Contents of $OEM$\cmdlines.txt

[COMMANDS]
"rundll32 advpack.dll,LaunchINFSection RunWPI.inf,,1,N"

Contents of $OEM$\RunWPI.inf

;###################################################################
;#### The post install starter for WPI designed by: ricktendo64 ####
;#### Used for Windows 2000, XP and 2003...                     ####
;###################################################################

[Version]
Signature="$CHICAGO$"

[DefaultInstall]
AddReg=Run.AddReg

[Run.AddReg]
HKLM,"%RUN%","%WPI%",,"RunDll32 advpack.dll,LaunchINFSection ""%01%\%INF%"",Execute"


[Execute]
AddReg              = OfficeFix
RunPreSetupCommands = Launch.WPI:1
DelReg              = Run.DelReg

[officefix]
HKCU,"Software\Microsoft\Internet Explorer\Main","Disable Script Debugger",0x0,"no"
HKCU,"Software\Microsoft\Internet Explorer\Main","DisableScriptDebuggerIE",0x0,"no"

[Launch.WPI]
CMD /Q /C CD /D """%01%\..\WPI""" & START /WAIT /B WPI.exe

[Run.DelReg]
HKLM,"%RUN%","%WPI%"

[Strings]
RUN="SOFTWARE\Microsoft\Windows\CurrentVersion\RUN"
WPI="Windows Post Install"
INF="RunWPI.inf"

Rick is VERY clever!

So really, you're using a method 2 1/2 (driver files are not compressed during run).  I don't think we ever tried that in testing.
You're doing a lot of effort for little gain.  Method 1 decompresses the .7z files, then .cab compresses them all.  You're then decompressing them AGAIN and .7z compressing AGAIN!
You'd be better off just selecting method 2 (DriverPacks compressed in 7zip).  If you really wanted to, you could decompress all the individual DriverPacks, then recompress into a single pack (rename using the standard convention: DP_*name*_wnt5_x86-32_*date*.7z) and just double-click the DP_Install_Tool.cmd file like normal.  You'd still get your desired result.

We've also been working on a new replacement SAD2 command file you could test for us (used for both NT5 & NT6 OS).
Link here:
http://forum.driverpacks.net/viewtopic. … 590#p41590

As to the Nvidia control panel, it's embedded in the driver files now.  There's no separate installer.  The DPsFnshr.ini entry just writes a registry entry based on whether the user wants the new/old control panel style (or none).  I'm not even sure if that works anymore with the new control panel nvidia is using.