Win32_Printer Put() Throwing a "Generic Failure" Error

Karl Malone
Karl Malone used Ask the Experts™
on
We've been trying to deploy a TCP/IP printer to a non-AD-joined machine using PowerShell.

The function we're using is:

Function CreatePrinter {
    $wmi = ([WMIClass]"\\$ComputerName\Root\cimv2:Win32_Printer")
    $Printer = $wmi.CreateInstance()
    $Printer.CreationClassName = "Win32_Printer"
    $Printer.Caption = $PrinterCaption
    $Printer.DriverName = $DriverName
    $Printer.PortName = $PrinterPortName
    $Printer.DeviceID = $PrinterCaption
    $Printer.Put()
}

Open in new window


However, when running Put(), we receive the following error:

Exception calling "Put" with "0" argument(s): "Generic failure "

We've made sure the driver is pointing correctly, the driver is installed, and all of the required parameters are filled in. Interestingly, this works on a local Windows 10 machine using a different printer, but when trying on a different Windows 7 machine using a different printer, it fails.

Any and all help would be greatly appreciated.
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Distinguished Expert 2018

Commented:
If your goal is to use powershell, why aren't you using the add-printer cmdlet? WMI via powershell can be clunky and you really have to dig into MSDN to get the API right.
Distinguished Expert 2018

Commented:
And then there's native GPO printer deployment which works stable and is very convenient... why use powershell?
Karl MaloneMailman

Author

Commented:
Cliff Galiher, the Add-Printer cmdlet doesn't exist in Windows 7. The goal of the script is to be flexible and executable on any non-AD machine, 7 or 10, that we need to deploy printers on, which is why we've resorted to trying to use WMI.

McKnife, as stated in the original post, the machine is not joined to Active Directory.
Learn Ruby Fundamentals

This course will introduce you to Ruby, as well as teach you about classes, methods, variables, data structures, loops, enumerable methods, and finishing touches.

Distinguished Expert 2018
Commented:
I don't think you'll be able to get where you want then.  Powershell V2 was very limited, even with its WMI interactions.  There is a *reason* that module wasn't backported and why V3 is a minimum to use it.  (even though you aren't trying to use it, you are hitting similar limitations that prevented it from being backported.)

You could write a gnarly script that might eventually work if you have a separate function for each OS, but realistically I'd just maintain two scripts at that point.  There is the "theory" of it being nice to have one script to maintain, but if the function calls are effectively per-OS, you are maintaining two separate blocks of code that just happened to be lumped together.  Or you can keep things simple and use powershell where it makes sense, and use other methods for older OSes on an "as needed' basis.

If you really want to try to get the code to work, unfortunately I have little advice.  I don't recall the win7 WMI specifics anymore (long since purged from personal brain-RAM), and digging through MSDN for an OS I don't regularly support and in extended support is a bit more effort than I have time to do on a volunteer basis. Sorry.
Distinguished Expert 2018

Commented:
Sorry, for missing that detail.

An idea: your deployment, is it to several machines? Why not do it from remote?
https://powershell.org/forums/topic/powershell-v3-on-win7/ shows, how someone uses an OS (there: win8.1) that has the add-printer cmdlet to install a printer on server 2008 R2 from remote - I guess it will work the same way against a remote Win7.
Distinguished Expert 2018

Commented:
Just for me: was my suggestion tried? It looked very promising and easy at the same time.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial