Heya,

Well, first let me say that this is a good question as drivers are always an interesting thing to figure out what to do with.  However, SVS and virtualization generally does not allow you to package them.  I am not sure on MSI, but I would guess that you can script out the driver installation somehow.  For example, if you find the executable file, try performing a "/?" query on it to see what options are available.  Alot of times, you can perform a silent install of drivers by simply using <name of file.exe> /s.

If you still can not script it out, I would suggest that you try integrating the drivers directly into your Operating System via a method such as using nLite to recompile Windows so that the drivers are in the driver.cab library.

Thanks for the input. I have tried using a /s with the install. I have also tried using /? and /H and /silent and /Quiet. Nothing is working for a full silent install.

I think this is becuase this in an old application that the company got so used to using it's integrated into the work process. Sadly, the application is no longer being produced and thus no support of any kind exists for it anywhere.

I think for now, we're just going to make it a part of the standard image for all new deployments and old systems will get a manual install.

I'm just finding it very hard to believe Wise Packager or SVS can't capture drivers. What makes them any different than other applications and services that I can capture and package and deploy without any problems?

 Nothing can "capture" drivers properly.  It's not a particular limitation of Wise or SVS.  Drivers are very dynamic and must run code to install properly for a given machine.  Doing a capture on your packaging machine won't satisfy all the other machines in your environment, particularly in the case of printers.

I would guess that your packaging machine started out with 0 installed printers (prior to your capture of this application).  So afterwards you'd have 1.  In the registry, there are keys that deal with hardware enumeration.  Many of your users likely have 1, 2 ,3 or even more printers already set up for their machine.  So Windows would be expected to number the new printer as, say, printer number 4 instead of printer number 1.  The registry entries that you've captured are therefore unlikely to play nicely with those machines.

Also, in the case of printers, you'd have to at least bounce the spooler service to see the new printer appear.

If your virtual printer is rather basic, you might be able to get it to appear by adding a Post-Activate event that stops and starts the Spooler service.  You also want to add a Post-Deactivate event to stop and start the Spooler service.

You may also want to consider installing just the printer driver as a conventionally installed driver, rather than virtualizing.

Hi Evan,

Great to hear from you.  I'm sure you have explained this to me before, but I can't remember what causes a driver to be dynamic vs. non-dynamic.  I understand your I have more than one printer example, but if we capture Adobe Acrobat with Global Capture, all is well.  Is it that Adobe is using DIFx and the package in question is not?

Next time I see you we will party like rock stars.

Printer drivers are often missed by capture tools as part of their registry entries are treated as "hardware" and are therefore skipped by the capture tools which excludes the hardware keys unless you explicitly select scanning of hardware. Then of course you need to be aware that spurious hardware content will also be captured and need cleaning up before any deployment..

It is often easier to note down the name of the printer driver after a manual installation, then search the registry for that string. That should throw up the relevant registry keys, from where you can at least determine if those keys are in your capture, and also whether they are sequenced with other printer drivers meaning that you have to handle the sequencing with a custom action rather than just writing the same keys.

If your printer driver has an associated INF file, you can check out alternative methods of installation using RunDLL32.exe - if I recall correctly this method is explained at www.dx21.com