Think App-V can’t handle drivers and certificates? You’re absolutely right, but that doesn’t mean you’re out of options.
Application Virtualization is a powerful technology that isolates applications from the underlying operating system, reducing conflicts and simplifying deployment. However, it comes with some strict limitations, one of the most notorious being its inability to handle drivers and certificates inside virtual packages.
This limitation poses a real challenge for packagers dealing with applications that rely on hardware-level access or certificate-based trust. Once sequenced into an App-V format, these components are excluded, often silently, leading to broken functionality or failed installation.
Fortunately, there’s a reliable way to deliver these components alongside the App-V package and make the application work as intended.
How We Handle It in Practice
- To start, enable package scripts in the environment by running the following PowerShell command:
Set-AppvClientConfiguration -EnablePackageScripts 12. You should have a set of files similar to those shown below ready for the App-V package.

🟡 IMPORTANT:
- Name
dpinst.exeexactly as shown in the screenshot, based on its architecture. - Certificate files must include the correct prefix corresponding to their certificate store (e.g.
TrustedPublisher-SL1000.cer,Root-SL1000.cer, etc.).

3. Next, archive these files into a .ZIP file.
🟡 IMPORTANT:
The archive should contain only the specified structure of files and folders, not an additional parent folder (e.g. driver.zip\dpinst-amd64.exe, not driver.zip\driver\dpinst-amd64.exe).
4. Add the created .ZIP archive and PowerShell script to the Scripts location in the Package Files tab.
📌 This script stages device drivers for an App-V package. Since drivers can’t be virtualized, they must be installed directly to the operating system or, as it’s often called in App-V terms, “outside the bubble.”

5. After saving the project, open the DeploymentConfig.xml file and add the following code inside the <MachineConfiguration> tag, directly after the <Subsystems> tag:

<MachineScripts>
<AddPackage>
<Path>powershell.exe</Path>
<Arguments>-ExecutionPolicy ByPass -File script.ps1 -DriverSource "driver.zip" -LogName "install.log"</Arguments>
<Wait RollbackOnError="true" Timeout="30"/>
</AddPackage>
<RemovePackage>
<Path>powershell.exe</Path>
<Arguments>-ExecutionPolicy ByPass -File script.ps1 -DriverSource "driver.zip" -LogName "uninstall.log" -Remove</Arguments>
<Wait RollbackOnError="false" Timeout="60"/>
</RemovePackage>
</MachineScripts>
Explanation of the script arguments:
- –
File– the name of the added PowerShell script - –
DriverSource– the name of the added.ZIParchive - –
LogName– the name of the log file, which will be stored in theC:\Windows\Tempfolder
6. At this stage, the App-V project must be added with config:

7. The driver and the Trusted Publisher certificate have been added to the target system.


8. In addition, the script can add certificates to other stores — Root, AuthRoot, or CA.
You just need to include a .cer file with the appropriate store prefix, and it will be added using the same logic.
🟡 IMPORTANT:
After you re-save the App-V package, the .xml file refreshes. That’s why you need to add the machine scripts again to the new .xml file or replace it with a previously copied one.
This is how Apptimized handles App-V limitations – and helps you do the same.
At Apptimized, we deal with edge cases like this every day, so if you’re struggling with App-V or complex packaging scenarios, feel free to reach out.