1

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.

  • 1
    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. I'll have to do some testing when I have access, but I suspect File System Redirector and/or Registry redirector 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
1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.