Add 32-bit printer drivers to 64-bit windows server programmatically

Question

GOAL: To install both x64 and x32 drivers for printers on a Windows 2012 R2 print server automatically.

INFORMATION: So far, I've been able to install x64 print drivers with no problem. My attempt to install x32 on existing printers is below:

# - Set the driver name
$driverName = "HP Universal Printing PCL 6"

# - Get a list of printers that already have x64 drivers installed
$printers = get-Printer | where {$_.drivername -eq $driverName}

Foreach ($printer in $printers) {
    # - This is the only way I could think to get the x32 print driver. It is already installed on the system with pnputil
    $driver32 = get-printerdriver | where {$_.name -eq $driverName -and $_.printerenvironment -eq "Windows NT x86"}

    # -- Turn off the share so we can add the driver.
    $sharename = get-printer -name $printer | select -expand ShareName
    set-printer -name $printer -Shared $false -confirm:$false

    # -- This does not work. The set-printer cmdlet does not accept pipeline input.
    $driver32 | set-printer -name $printer -confirm:$false

    # -- Re-share the printer.
    set-printer -name $printer -Shared $true -Sharename $sharename
}

PROBLEM: Since Set-Printer does not accept pipeline input, I can't think of another way to tell it which driver to install. The x32 and x64 driver names are identical, so I don't know how to differentiate by using the -DriverName parameter.

I don't have Windows access just now, but what happens if you run the working x64 PS1 from a 32-bit Powershell prompt on the print server? — jscott, Dec 15 '15 at 23:27
Interesting question jscott! It appears that when creating a printer, if both x86 and x64 drivers exist on the system, it adds them both. For an existing printer, I ran the script in the x86 PowerShell and it seemed to add both drivers. I can't test the actual printer, but this appears to have fixed it. Do you know why running it in x86 Powershell worked? — McKenning, Dec 15 '15 at 23:37
From a 32-bit application's view C:\Windows\system32 would really be C:\Windows\SysWOW64. See [File System Redirector](https://msdn.microsoft.com/en-us/library/windows/desktop/aa384187(v=vs.85).aspx). I'll have to do some testing when I have access, but I suspect File System Redirector and/or [Registry redirector](https://msdn.microsoft.com/en-us/library/windows/desktop/aa384232(v=vs.85).aspx) play a role in the behavior. — jscott, Dec 15 '15 at 23:45
This is why I love serverfault. I learned a lot today. If you post your comment as an answer, I will mark it accordingly. — McKenning, Dec 15 '15 at 23:47

score 1 · Accepted Answer · answered Dec 15 '15 at 23:50

This is cop out, placeholder answer. I should like to follow up when I am able to do some testing on a Windows box to verify the [in]accuracy of the following.

Run the working "x64" PS1 script from a 32-bit Powershell prompt.

From a 32-bit application's view C:\Windows\system32 would really be C:\Windows\SysWOW64. See File System Redirector. I suspect File System Redirector and/or Registry redirector play a role in the behavior.

Add 32-bit printer drivers to 64-bit windows server programmatically

1 Answers1