Summary: Microsoft Scripting Guy, Ed Wilson, talks about using Windows PowerShell to send a test page to a printer.
Microsoft Scripting Guy, Ed Wilson, is here. This morning I am sipping an awesome orange-cream tea that I picked up at a tea shop in Leipzig, Germany. It smells wonderful, and it tastes just like a Dreamcicle that I used to eat when I was a kid. That orange candy-covered vanilla ice cream was just the thing for hot, humid days when I was growing up in Florida. I have absolutely fallen in love with this tea.
Anyway, something else I have fallen in love with is all the printer cmdlets available in Windows PowerShell on Windows 8.1. I can do nearly everything I need to do to manage printers. The operative word, however, is nearly.
After I add a printer, I like to print a test page—especially if I am going to be printing something important (which I believe, should be the only documents printed). But dude, I do not want to have to mouse around, open Control Panel, find the printer tool, and scramble until I find the print test page button. Instead, I simply want to use Windows PowerShell to print a test page. How hard is that? As it turns out, it is not very hard at all.
WMI to the rescue
I have always been able to print a test page from within a script. Even 15 years ago in the old VBScript days, I could print a test page. This is because Windows Management Instrumentation (WMI) has always had a print test page method for the printer class.
Win32_Printer class
The WMI class I need to use is the same WMI class that I used way back in the days of Windows NT 4.0. The class is Win32_Printer…talk about backwards compatibility. The cool thing about WMI since Windows PowerShell 3.0 is that with the CIM cmdlets, using WMI is simple. In the VBScript days, it would have taken me nearly 30 minutes to write out a WMI script to send a test page to a printer. And in the end, it would have required about 18 lines of code.
With Windows PowerShell, it can be a one-line command. But anything that I do on a regular basis becomes an immediate candidate for a Windows PowerShell function. When I have a function, I tend to add it to my profile somewhere. In this case, I have a module that contains utility code, and this is where the function would reside.
Note Tomorrow I am going to make a serious improvement to this function, and that will be the function I actually add to my utility module.
I need to call the PrintTestPagemethod from the Win32_Printer WMI class. With the CIM cmdlets, I have an Invoke-CimMethod cmdlet that is designed to invoke methods. The Invoke-CimMethod requires an instance of a printer object (something returned from Win32_Printer) before it can execute the method.
The easiest way to get this instance of the printer object is to use the Get-CimInstance cmdlet. All I need to do is to tell the Get-CimInstance cmdlet the name of my printer. Maybe I am not certain of the exact name of the printer. In that case, there is still no problem because I can use the LIKE operator to find the printer I need. This goes into the –Filter parameter, and it looks like this:
Get-CimInstance win32_printer -Filter "name LIKE '$printer'"
When I execute this code, I can then supply the returned printer object to the InputObject parameter of the Invoke-CimMethod cmdlet. I need to execute the Get-CimInstance cmdlet first, so I return a WMI printer object to the Invoke-CimMethod cmdlet.
No sweat. It works just like high-school algebra—stuff inside the parentheses executes before stuff outside the parentheses. Therefore, I put the Get-CimInstance command inside a pair of parentheses, and the I call Invoke-CimMethod. The method name is the same one that I used in Windows NT 4.0: PrintTestPage. Therefore, that is the value I supply to the –MethodName parameter. This command is shown here:
Invoke-CimMethod -MethodName printtestpage -InputObject (
Get-CimInstance win32_printer -Filter "name LIKE '$printer'")
Put it in a function
So I have my one-line command, and it works. Now I put it in a function. This is not hard. Basically, there are three things to do:
- Use the Function keyword.
- Add a function name.
- Add a script block.
Dude, that’s it. A Windows PowerShell function is as easy as one, two, three. I have a script block (that is my one-liner), so I am all set to create a function. I decide that I need to have a variable for the printer name—after all, a function with a hard-coded printer name is not all that useful. To do this, I use the Param statement, and I assign a variable to hold the printer name. This portion of the script is shown here:
Param(
[string]$printer = "hp2005dn")
Now I will add in the Function statement, name the function, and add my script block. The complete function is shown here:
Function out-TestPage
{
Param(
[string]$printer = "hp2005dn")
Invoke-CimMethod -MethodName printtestpage -InputObject (
Get-CimInstance win32_printer -Filter "name LIKE '$printer'")
}
That is it. With only a few lines of script, I have the ability to use Windows PowerShell to send a test page to my default printer. Pretty cool stuff. The only thing I do not like is figuring out what the name of the printer might be. So, I will fix that tomorrow by creating a dynamic parameter. This will add a bit of complexity, but it will be worth it for me in the end.
Using Windows PowerShell to print a test page will continue tomorrow when I will talk about creating a drop-down list to enumerate all printers on the target computer.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy