Struggling to install printer drivers using PowerShell in deployment tools like Recast or Liquit? We break down why it fails and provide three battle-tested solutions, from quick fixes to robust, enterprise-ready methods.

From the Trenches: Taming Printer Drivers with PowerShell in Recast & Liquit

I’ll never forget it. 2 AM, the on-call phone blares. It’s a P1 ticket because the entire finance department can’t print their end-of-quarter reports from the new VDI environment we just pushed. The culprit? A single, finicky printer driver that our deployment tool swore was “successfully installed.” That night, fueled by lukewarm coffee and pure frustration, I learned a hard lesson about the ghost in the machine: the difference between a user session and the SYSTEM context our tools live in. If you’ve ever watched a script work perfectly when you run it, only to fail silently when deployed, this one’s for you.

The “Why”: The Ghost of Session 0

Before we dive into the fixes, you need to understand why this is happening. When you run a PowerShell script on your machine, you’re in an interactive user session (Session 1, 2, etc.). Your script has access to the GUI, your user profile, and a whole world of context.

Deployment tools like Recast, Liquit, SCCM, or Intune don’t work that way. They typically execute scripts as the NT AUTHORITY\SYSTEM account in a non-interactive session known as Session 0. This is a secure, isolated space with no desktop, no GUI, and none of the context a user has. The problem is that many driver installers, and even some built-in PowerShell cmdlets like Add-PrinterDriver, are built with the assumption that they’re being run by a user in an interactive session. When they run in Session 0, they can’t find the components they need and either fail silently or throw cryptic errors.

The trick isn’t to fight Session 0; it’s to use commands that are designed to work within it.

Solution 1: The Quick Fix (The `Start-Process` Gamble)

Sometimes, you just need to get it done. This method is essentially a “fire-and-forget” approach that calls the driver’s own installer executable. It’s quick, dirty, and its success depends entirely on how well-behaved the manufacturer’s installer is.

How it Works:

You use Start-Process to launch the driver’s setup.exe with silent installation arguments. We use -Wait to ensure our script doesn’t continue before the installer finishes and -PassThru to get some feedback.

# Path to the driver installer executable
$InstallerPath = "C:\Temp\Drivers\HP_Universal_PCL6\install.exe"

# Manufacturer-specific silent install switches
$Arguments = "/s /n /norestart"

try {
    Write-Host "Attempting to install driver using Start-Process..."
    $process = Start-Process -FilePath $InstallerPath -ArgumentList $Arguments -Wait -PassThru -ErrorAction Stop

    if ($process.ExitCode -eq 0) {
        Write-Host "Installer completed with success code 0."
    } else {
        Write-Warning "Installer completed with non-zero exit code: $($process.ExitCode)"
    }
}
catch {
    Write-Error "Failed to execute installer. Error: $_"
}

Darian’s Pro Tip: This is a gamble. You are at the mercy of the driver developer. I’ve seen installers that ignore the `/s` silent switch and pop up a GUI in Session 0, causing the process to hang forever until it times out. Use this for one-off deployments, but don’t build your entire imaging process around it.

Solution 2: The ‘Right’ Way (Mastering `pnputil`)

This is my go-to method and the one I trust for enterprise-wide deployments. Instead of running a setup file, we use a built-in Windows command-line tool, pnputil.exe, to directly add the driver’s .inf file to the Windows Driver Store. This tool is designed to be run programmatically and works perfectly in the SYSTEM context of Session 0.

How it Works:

The command pnputil /add-driver <path_to_inf> /install stages the driver and then installs it on any matching plug-and-play devices. It’s clean, reliable, and gives you explicit control.

# Path to the folder containing the extracted driver .inf files
$DriverPath = "C:\Temp\Drivers\Zebra_ZT410"

# Find all .inf files in the specified directory and subdirectories
$infFiles = Get-ChildItem -Path $DriverPath -Recurse -Filter "*.inf"

if ($infFiles) {
    foreach ($inf in $infFiles) {
        Write-Host "Staging and installing driver from $($inf.FullName)..."
        # We use Start-Process because it handles output and exit codes cleanly
        $process = Start-Process -FilePath "pnputil.exe" -ArgumentList "/add-driver `"$($inf.FullName)`" /install" -Wait -NoNewWindow -PassThru
        
        if ($process.ExitCode -eq 0) {
            Write-Host "Successfully installed driver: $($inf.Name)"
        } else {
            # PnPUtil exit codes are weird. 3010 means success but needs a reboot.
            if ($process.ExitCode -eq 3010) {
                Write-Warning "Driver installed successfully, but a reboot is required. Exit Code: 3010"
            } else {
                Write-Error "Failed to install driver $($inf.Name). PnPUtil Exit Code: $($process.ExitCode)"
            }
        }
    }
} else {
    Write-Warning "No .inf files found in path: $DriverPath"
}

This is the method we used to fix that 2 AM finance department meltdown. It’s predictable, scriptable, and robust.

Solution 3: The ‘Nuclear’ Option (The Full Driver Store Import)

What if you’re building a new golden image for your VDI farm (e.g., `VDI-GOLD-IMG-22H2`) and you need to pre-load it with every printer driver used in the company? Installing them one by one is a nightmare. The solution is to export all the third-party drivers from a fully configured machine and then import them in bulk on the new image.

How it Works:

This is a two-step process. First, on a “golden” PC that has all the drivers you need, you run a PowerShell command to export them. Then, in your deployment script, you run another command to import them all back into the driver store.

Step 1: Export from a configured machine

# Run this on a machine with all the necessary drivers installed
# This will export all non-Microsoft drivers to a folder
Export-WindowsDriver -Online -Destination C:\Temp\AllCompanyDrivers

Step 2: Import into the target machine (via Recast/Liquit)

# This script will run on the new VDI or PC during deployment
$DriverSourcePath = "C:\Temp\AllCompanyDrivers"

Write-Host "Starting bulk driver import..."
# We use the same pnputil logic from Solution 2, just pointed at our exported folder
$infFiles = Get-ChildItem -Path $DriverSourcePath -Recurse -Filter "*.inf"

foreach ($inf in $infFiles) {
    Write-Host "Importing driver: $($inf.FullName)"
    pnputil.exe /add-driver "$($inf.FullName)" /install
}

Write-Host "Bulk driver import complete."

Warning: This approach is powerful but can significantly bloat your image size. The exported driver folder can be several gigabytes. Use this for building base images, not for deploying a single driver to an existing machine.

Summary of Solutions

At the end of the day, managing drivers via automated systems is about understanding the context your code is running in. Once you stop trying to make the SYSTEM account act like a user, and start using the tools designed for it, you’ll save yourself a lot of late-night calls. Happy scripting!

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions