As I continue to dive deeper into PowerShell WMI, I continue to be surprised by new things I discover. I’ve been playing today with the WMI Class WIN32_printer. Sometime ago, I posted a code sample over on MSDN using this class with Powershell (see the original sample here).
The original sample produced a test page on a specific printer – but I thought it would be interesting to see what happened if I ran the script against ALL the printers define on my workstation. And that got interesting.
On my system, I have two ‘real’ printers installed (a colour Inkjet and a colour laser) and two additional printers: an XPS Document Writer “printer” and a SnagIt 9 “printer”. As expected, the real printers printed their test pages just fine. But the virtual printers did not fare so well. The SnagIt printer failed to print a test page. It generated two “Unable to open message queue” error messages (in a pop-up window), then failed with a message “Unable to send a message to SnagIt” (and another pop-up). But at least it failed gracefully although the Result code was 0. Attempting to print to the XPS document writer just hung.
This result shows that, at least with WMI (and probably ALL other classes), when you start writing scripts based on base objects (i.e. WMI, COM, .NET and home grown), you need to know what you are doing. And in writing production scripts, you need to be extra careful with testing, and coding around the problem issues.
This last point is illustrated in the updated script that I published to my scripts blog: http://pshscripts.blogspot.com/2009/04/get-printertestpageps1.html. Look at lines 63-65 – these avoid calling the PrintTestPage on those printers you know to not work. This is another interesting reference to the fact that production scripting is more about “error” handling (you might call it “reality handling” too"!) than anything else. And a lot of wide testing.
No comments:
Post a Comment