This is really just me relaying my experience in dealing with applications that contain drivers. Like I said in my previous post, vendors are not consistent with how they deliver their applications, so I may not cover absolutely every possibility but these are examples of some that I have.
1.) Separate Driver Installer extracted
In some glorious cases, vendors actually split out their drivers into separate packages. I’d love if this was the standard but it’s not! If you run the install you may find a Drivers folder or Drivers MSI in the extracted installer under %temp%
For a great example, check out Nicke Kallens great blog post HERE
2.) Vendor MSI
In a few cases, you may notice during an install of a vendor supplied MSI, there may be a feature for the actual driver install, if it’s optional.
If you are lucky enough, your application install may have an optional feature in it. If you go to the custom setup option during the install, you can usually tell if such an option exists. You can then open the MSI and go to the Feature table and find the name of the feature you want:
You might be able to just install the MSI with the ADDLOCAL= parameter with the Feature e.g. msiexec /I FoxitPhantomPDF706_Business_enu_Setup.msi ADDLOCAL=FX_Evernote
In which case, Add a scrip to the MachineScripts of your App-V application Deployment Configuration file to install the driver as above.
In some cases, you may discover that if the driver is not installed by the primary feature, the installer will not allow you to install with only the feature you want, you might have to install with the primary feature AND the driver you want which is useless. That means putting much more of the application local, which can defeat the purpose of sequencing in the first place.
What you could do is created a Response Transform, selecting the primary feature and the other feature you want. Then you could remove everything else from the File table that are not related to the drivers. If you do this, ensure you test the install, repair and uninstall thoroughly. If you do it correctly, only the drivers should be installed.
You can then have the MSI with the Transform install as part of the Deployment Configuration Machine Scripts
3.) Reverse Engineer Print Driver from MSI
At this point, if you didn’t get lucky with an easy to configure installer or possibly a separate MSI for the driver install, I think you need to ask yourself how much time and effort you want to go to. I’ll be describing how you could script this and that is all.
If you have a tool such as those by AppSense or RES, you have a very powerful and nice scripting engine to work with. So it may be a little easier for you. If not, you’ll have to script using Powershell or vbscript. I have had AppSense and\or RES at my disposal whilst working for almost all of my previous employers, so I’m afraid I don’t have a script example for this, I can just share my logic used.
For this one I used a tool called DLL Export Viewer which you can find HERE
If you look through the MSI Custom Action table you may find one for Installing the Print Driver. You can see a pointer to a dll.
You should be able to find that dll in the Binary table. If you’re not lucky enough to have a great MSI editing tool like Advanced Installer, you could use Orca, go to the Binary table, right click and export. With Advanced Installer, I just need to browse to the Binary folder in my AppData directory. I take a copy of the file I want and then rename it to have the .dll extension.
Launch the DLL Export Viewer tool and browse to your DLL
You can now use these functions along with the files for the print driver in your MSI file table to install the print driver. Your script would start with a command to close the Spooler Service e.g. net stop Spooler, copy the Print Drivers files (usually held in a Print Driver component within the MSI), Merge registry related to Print Driver (Usually not contained within the MSI, you’ll have to find these on a machine after install ), perform a net start Spooler, a net. If desired you can also run a command to set the install driver as the Default.
Some of the files will likely go to the SYSWOW64 and\or System32, in case you’re having a hard timing find them in your MSI. Typically files will be prefixed with printdriver, driver, pdf or something to indicate what they are for.
For the registry, it appears there’s two SharedDLL directories which often point to files which are used for the PrintDriver. You may also find references to the following hives:
To discover the above, I actually ran a tool during the application install called InstallRite which is really old, but it gives a really nice view of what registry keys were added, modified or removed during the install, it also gives the option to export directly into a .REG file which is great!
This example is for a Print Driver, you may have some other kernel mode driver which you could apply this same logic to with some obvious differences. e.g. Spooler service would be irrelevant, drivers would likely be installed in the DriverStore..
4.) Device Driver
This one is probably very rare but if you have a request to sequence an application which also installs a device driver, I suggest using a third party tool. I’m not aware of any free tools but your company should own one 🙂 You may need to ask your Admins if they have one. I’ve used Driver Magician and Driver Genius in the past. You simply install the application on a test machine. Launch the tool, in this example Driver Magician. Go to options and set the output the auto-package.exe
Select the device driver that you’d like to extract and then click Backup
You’ll then have an executable which you can deploy. I strongly advise that you not deploy these as part of the App-V package itself, as many device drivers require a reboot after install. It’s a good idea to deploy the device driver first and then make the App-V package available. You could suppress the reboot and script the install as part of the App-V packages machine scripts in Deployment Configuration but by their nature, you may have issues with the drivers, if the machine does not get rebooted before use.
5.) Non-MSI Installer with a driver
If it’s a device driver then section 4.) Could still apply. You may need to ensure the driver is removed from the App-V package and is only present on the desktop in order to avoid a conflict but it should work.
If it’s a Print Driver, it’s a little more difficult. The beauty of the MSI is that you can view the contents with a nice organized UI. Without that, it’s more of a needle in a hay stack to find the correct files and registry.
If I ever find myself in a scenario such as 3.) and 5.), I tend to set myself a strict deadline. If I can’t get it to work within that deadline, I just give up. Like I’ve said, vendors are not consistent with how they deliver drivers, you can find yourself getting lost down that rabbit hole very easily. In some cases the vendor MSI are well labelled and logical which can me step 3.) relatively quick. Other times they are a major pain. In fact, in the screenshots I posted, you can see there’s actually different files required if the app is being used on Windows 8!
Drivers still remain as a sore point when it comes to Application Virtualization. At one point Cameyo looked like they were attempting to virtualize drivers but they have since stopped working on that. Perhaps with Microsoft creating these virtual subsystems in App-V 5.0, we may get a Print Driver virtual subsystem but I’m not that optimistic. I can recall years ago that Citrix struck a deal with HP to standardize on how they delivered their print drivers. It would be great if Microsoft could use their sway to get Print Drivers delivered in a uniform manner and then get the Sequencer to parse and handle those auto-magically. Print Drivers account for the vast majority of driver issues I face.