" The DriverPacks were not found ??? "   
   -      implied, can not continue...  -

the finisher does all the cleanup as part of it's function
- if you run it, it will remove all traces of the DriverPacks
and the finisher itself gets removed after your first reboot.

the finisher uses the INI's to identify drivers that have software to be (Co)installed
IE the graphics INI has an entry that runs the ATI control panel
(but only if an ATI card is installed in the machine)

INIU has convienient office hours to review any course related material, even the basics 

I build the computer, ground up from RIS.  C:\ has all the .INI files.  No .7z, but C:\D\ still exists.

If I manually run dpsfnshr.exe, it all goes away.  Revert (yay VMs), and run dp_install_tool.cmd, and get:
"Searching current drives..

Searching all drives...

The DriverPacks were not found ???

Press any key to continue"

and it exists, without calling dpsfnshr.exe.

so...  during the initial installation of the computer, is there any process running that looks at the INIs?

I think I need to go back to basics a bit...  seems like I'm missing something pretty basic here.

Its just these silly laptops that have their custom stuff on them!

Agree, Its notebooks and all the apps that sit on top of the drivers, Bluetooth, finger readers, Hotkeys, TPM, Mouse Pads, etc, etc, the list goes on ...

I use the default DriverPacks for the core components, and create custom driver packs, a pack for each hardware model. This is so I can add/remove full driver pack support when hardware models come into the business or when  fully decommissioned.

The Toshiba Bluetooth stack should work, I have'nt seen any vendors customise this yet (but I'm shore they will :-)).

If my pack does not work, let me know and i can help to customise. There is a file AS.INI that needs to be modified to make this into a silent installation. Then run:

START /WAIT MSIEXEC.EXE /I "%DPSROOT%\D\3\BT\BtSwInst.msi" /QB REBOOT=R ALLUSERS=1

The files are extracted from the SETUP.EXE first, so AS.INI can be changed and the MSI can be run.

my thanks to you since INIU is nothing without its student body...

are you sure the exe is getting called?

Well, no, I'm not.  I don't know if msiexec is available to the operating system at that point during install...  and I don't know if setup.exe just calls msiexec, and subsequently fails.

lol good idea.  Noob moment, I suppose.  I've got a build going with that right now, and I'll see what happens.

Er..  Yes, first one does work (and installs the software).

2nd one (from the finisher) fails - and maybe I am in the wrong place to test, because %DPSROOT% isn't set when I am finally at a point where I can use a command line.

Fantastic   I didn't know.  I keep going back to this post because, so far, its the best page for consolidated information on the finisher.  You guys need a wiki or something...

It's not, but that's how Setup.exe wants to see it...

7yler - Thanks!  I will gladly try it out, but I have my doubts - this is a Dell laptop...  my experience with Dell so far is that they tend to "brand" their stuff somehow so you need to use their device drivers.  A bit of a pain, but thanks to the flexibility of AutoImage and DriverPacks, its eeeeaaaasyyyy.  I will certainly give the pack a shot.  And I completely agree with you on the simplifying work - I'm in a shop with AMD, Intels from PIII to Core 2 Duo's and all the peripherals in between..  and boy does deploying a machine go nice n easy and hardly any issues.  Its just these silly laptops that have their custom stuff on them!

What can I say
that  is a very strong first post... step up and offer a completed pack to another user.

VERY well done!

Welcome to DriverPacks we are very glad your here and thanks for giving back to the community.

have an awesome day!  and,  Welcome to the forum!

jeff

Info: I installed on a machine and extracted all the drivers, as installing directly from the installer caused me problems. Therefore the drivers install first, and the applications runs if the drivers are detected.

I have uploaded it to RapidShare (DP_BT_wnt5_x86-32_080722.7z) - 28534 KB:

http://rapidshare.com/files/135965710/D … 22.7z.html

If its works and its useful, you can move it to 3rd party packs, and modify to your liking.

While here, I would just like to say a big thanks for the fantasic work you guys are doing, its much appreciated, and saved me a great deal of work, as drivers can be a big pain.

PS. Heres the main Toshiba link, to check for updates: http://aps2.toshiba-tro.de/bluetooth/?page=download

try these too which should work for a regular MSI...

/qn
/quiet
/qb
/passive

for full logging try adding
/lv  ( /  "L"  v)
IE "%DPSROOT%\D\3\BT\setup.exe /passive /lv C:\stupid_BT_driver.log"

It looks like the setup includes a firmware upgrade too... interesting... looks like toshiba wrote it...
try launching the msi directly with %DPSROOT%\D\3\BT\BtSwInst.msi /qb and see if that works for you...

you should be able to get a single driver in a custom pack though... hmmm

are you sure the exe is getting called?

did you try it without the command line switches?  IE "%DPSROOT%\D\3\BT\setup.exe"
to see if it launched in attended mode?

did you try running      "c:\D\3\BT\setup.exe" /S /v/qn        from a command line?
did you try "%DPSROOT%\D\3\BT\setup.exe" /S /v/qn       from the finisher?
or """%DPSROOT%\D\3\BT\setup.exe"" /S /v/qn" ?
or ""%DPSROOT%\D\3\BT\setup.exe" /S /v/qn" ?
or """%DPSROOT%\D\3\BT\setup.exe"" /S /v/qn" ?

you might add the log switch 
           Logging Options 
                /le <LogFile>
    e - All error messages

IE "%DPSROOT%\D\3\BT\setup.exe" /S /v/qn /le %SystemRoot%\BTinst.log ?

you can run the finisher over and over - simply use the directions for a SAD disk and only put your BT 3rd party DriverPack in the OEM folder instead of all the packs

IE copy your OEM folder to the Local HDD (creating C:\OEM\) delete the main packs... except your BT Pack
and run the DP_Install_Tool.cmd as many times as neccessary till you got it workin

how about that for a shortcut to test the finisher ?

INI University - classes starting daily!

Has INIU been opened up yet?  The pack I'm working on doesn't seem to work

What I've got....

A Dell Latitude D630 laptop with a Dell Wireless 360 Bluetooth module in it.  I think it's basically a USB device at the end of the day.

The drivers are recognized, as the device shows in your Computer Management window.  So I took the driver paths from the devices, and created a .INI for it, called "DriverPack_dell630_wnt5_x86-32.ini"

[DriverPack]
platform	= "wnt5_x86-32"
name		= "Dell 630"
rootDir		= "D\3"
; OPTIONAL
classes		= "Bluetooth"
driverCount	= 4


[BT]
; REQUIRED
exc_count	= 1
; OPTIONAL
exc_1_tagFiles	= 1
exc_1_tagFile1	= "%SystemRoot%\system32\DRIVERS\tosrfbd.sys"
; exc_1_tagFile2	= "%SystemRoot%\system32\drivers\tosrfusb.sys"
; exc_1_tagFile3	= "%SystemRoot%\system32\drivers\tosrfhid.sys"
exc_1_+hwids	= 0
exc_1_-hwids	= 0
exc_1_+infFiles	= 1
exc_1_+infFile1 = "%DPSROOT%\D\3\BT\Drivers\*.inf"
exc_1_-infFiles	= 0
exc_1_commands	= 1
exc_1_command1  = "%DPSROOT%\D\3\BT\setup.exe /S /v/qn"

So from what I've seen in other DriverPacks, and from the documentation..  it's pretty straightforward. 

The driver path (in tagFile1) is found in the device properties: [url]http://www.timatlee.com/sites/timatlee.com/files/MWSnap 2008-08-08.png[/url] (weird, IMG bbcode wasn't working...)

Does the character case of paths and whatnot matter in the file system paths?

setup.exe I think basically calls msiexec.  I don't know if that's available when the the ini file is getting parsed.  Thoughts?

Is there an easier way to test .INIs instead of reinstalling a PC each time?  Gets a little..  er, tedious and time consuming?

Thanks again...

Tim

well you would have had a tough time searching like that...

it is actually documented in the docs\ folder of the DriverPacks base program folder it is called

DriverPack_reference_wnt5_x86-32.ini

you can use the terms in the reference file to find search keywords if you still have questions...

sorry that our documentation is not well documented ;D

Jaak may even steal some of this and use it for .INI University training...
and then U & I 2 could be a graduate of INIU - LOL

It really is not well documented and not surprizeingly therefore that it is also not well understood.
I am always eager to take opportunity to explain how powerful Bâshrat the Sneaky's INI / DP_finisher combo is.
It is a very versitile system and was well implemented.

the drivers get installed during setup
then the finisher checks what was installed and runs appropriate programs
based on installed hardware and the INI settings associated with that hardware.

Please ask questions as it does tend to lead to documentation that benifits many.

ps
the Finisher was often in the past plagued by people who had gotten the idea that it would install drivers - it doesn't  -

We are Now able to offer a redistributable MS tool 'DPinst.exe' which does install drivers... ty ty ty
- this is for people who need a SAD disk
- (since base ver 8.*)

I apologize for not searching it out on the forums; wasn't certain what wording to use.

Thanks again, and keep up the great work

you can create a driverpack (or modify an existing) and
use the INI in the DriverPack to launch an application
based on the presence of a specific HWID. or specific File name (like its driver file name).

the entry in the ini may look like this

[CR2]
; REQUIRED
exc_count    = 1
; OPTIONAL
exc_1_tagFiles    = 2
exc_1_tagFile1    = "%SystemRoot%\system32\drivers\P17.sys"
exc_1_tagFile2    = "%DPSROOT%\D\S\CR2\Ctzapxx.ini"
exc_1_+hwids    = 0
exc_1_-hwids    = 0
exc_1_+infFiles    = 1
exc_1_+infFile1    = "%DPSROOT%\D\S\CR2\Win2k_xp\*.inf"
exc_1_-infFiles    = 0
exc_1_commands    = 1
exc_1_command1    = "%DPSROOT%\D\S\CR2\ctzapxx.exe /S"

this says that if the file "%SystemRoot%\system32\drivers\P17.sys" is found
execute --> ctzapxx.exe /S

explained...
P17.sys will only exist if the device is present and its driver was successfully installed in the machine
if both of these things are true then we need to run the devices installer
to provide control panels and other features that compliment but are not part of the actual driver.

there is quite a bit of info already documented here on this topic -

I never wrote exception rules from the ground up, but there are quite a few examples across the various DriverPacks showing how it is done.
(( DriverPack MassStorage is a SPECIAL case, this is documented.. but right now I am hoping special post install exceptions can be added to DriverPack MassStorage because there is something funny going on with a Jmicron installer I am testing at home..))

Far as I know, a well written DriverPacks INI will get processed.
I hope we will get an academy for the DriverPacks team to help all team work together (with documentation on how exceptions are written and developed), and I hope that is not in a pipedream.

I've got a Dell Latitude D630 laptop.  It came with a Dell Bluetooth module.  I've been able to get the device to be recognized (no longer showing up as an error or warning in the device manager) by packing up a 3rd party driver, however it seems to need the Dell software to actually work (the device is recognized, but no Bluetooth control panel is available, etc).

Is there any way I can tweak the INF, or use some post-install hook to install the associated software?  It would seem to me that this has been done with NVidia video stuff and their control panel, but I've got no clue where to begin looking to see how that was handled.

I don't particularily want to put it in CMDLINES.TXT or some other location, as the application should only get installed when a specific device is present.  Unless there's a way I can check that the device is there, then install..  from a .CMD script...

Thanks,

Tim