Executive Summary:
Troubleshooting printer problems in a large environment where multiple techs can make configuration changes can be difficult unless you're recording all changes over time. PrinterInfo.vbs can be run as often as needed to capture print queue data with a simple Windows Management Instrumentation (WMI) VBScript that writes data to an Excel spreadsheet and an XML-based database. PrinterInfoCompare.hta, an HTML Application (HTA), provides a simple and easy-to-use GUI for performing comparisons on the data collected by PrinterInfo. |
I've faced a couple of ordeals troubleshooting printer problems where I didn’t have a reference to past printer configurations, so I decided to start keeping a history of all my print queues. I’ve found that having this history is particularly helpful in my environment because several other people have rights to maintain and troubleshoot printer problems, namely senior Help desk techs and senior desktop techs. They're the level 1 and level 2 technicians who get first crack at resolving printer problems. However, if they can’t resolve a problem, I'm the one who ultimately ends up with the support ticket. So I devised a solution for capturing my print queue data with a simple script; I can then compare the data from the current state to past states to reveal any changes and often discover problems more quickly.
A Little Background on the Problem
In addition to having eleven print servers and many printers, the number of queues in my environment is exceptionally high—more than 1000—because many of the printers have multiple queues set up, some with PostScript drivers, some with Printer CL (PCL) drivers, and some with drivers that might appear to be incorrect because they don’t match the make or model of the printer.
Having multiple techs with different levels of expertise in such an environment has its advantages. But it has its disadvantages as well. I've seen cases where someone has changed settings on a print queue while trying to troubleshoot a problem, then failed to return the original settings after discovering that the modification didn't resolve the problem. I've also frequently found that someone changed a driver from PCL to PostScript or PostScript to PCL to get a user's document to print. When the change lets the user successfully print, the tech assumes that all is well, but in fact a new problem was created for users who need the original driver.
I’ve seen printers that needed to have a competitor’s driver installed so they would function to a certain specification that the original manufacturer's driver couldn't meet. At first sight, I can see why someone would say, “Hey, that can’t be right. No wonder the user can’t print.” So the tech changes the driver to one that matches the printer; however, now documents don’t print for the users who needed the specialized driver, and unfortunately the technician doesn’t remember what the original driver was and can’t reset it.
Another problem I occasionally run up against is that a print queue has been renamed, something that generally happens when a printer is moved. In a facility as large as where I work, it's sometimes very difficult to coordinate migration efforts or new printer installations with all the right people, so communications occasionally get lost in the shuffle. And yet another potential problem: Sometimes I need to have information about a printer that's called back into action after being set aside in storage for a long period of time.
As you can see, a print queue history in my environment can be a vital resource. With as many printers and queues as we have and with possible changes being made at any time by multiple individuals, I've found that it's beneficial for me to capture printer information daily. If you work at a smaller site, you probably need to capture the data only once a week or a few times a month.
Developing the Solution
At first, I devised a solution for capturing my print queue data with a simple Windows Management Instrumentation (WMI) VBScript that gathered information from all print servers and wrote that data to a Microsoft Excel spreadsheet. This solution worked fairly well for tracking down changes; I could spot differences simply by comparing spreadsheets from different dates. But eventually I found that visually searching through numerous spreadsheets for changes, or writing macros to do comparisons, was tedious and inefficient.
Ultimately I modified my script slightly so that in addition to writing data to Excel, it wrote and saved the printer data to an ADO database as an XML file. With the data in a database, I could easily write a script that compared the data from different days in a fraction of the time it would take to do so manually.
The first of my scripts, the one I run daily, is called PrinterInfo.vbs; Listing 1 shows the code, and you can download the script by clicking the Download the Code Here button at the top of this page. When you run this script, it displays a spreadsheet that consists of a worksheet tab for each print server, an Error worksheet, and a Summary worksheet. The Summary sheet shows all of the print servers by name and the total number of print queues on each one. The summary also shows the number of printer errors detected on all servers combined as well as any differences between the last run of the script and the current run, such as new or deleted printers, driver changes, location or comment changes, and changes on other pertinent fields. Each of the printer worksheet tabs contains print queue information for that particular print server, and the Errors worksheet houses printer errors detected for all print servers. The first time you execute this script, of course, you won't have comparison information reported in the spreadsheet.
What PrinterInfo.vbs Does
As I mentioned, the PrinterInfo script uses WMI to gather the printer information and stores that data in an XML-based database using ADO. Here’s a list of the fields that it acquires data on:
- PrintShare (a concatenation of PrinterServer and Printer ShareName)
- PortName
- DriverName
- PrinterName
- Location (as entered in the printer properties Location field)
- DetectedErrorState (see the DetErr array at callout B in Listing 1 for possible errors)
- Status (i.e., error or OK)
- Comment (as entered in the printer properties Comment field)
- PrintProcessor
- PrinterStatus (see the PrtStatus array at callout B for a list of statuses)
- BiDirectionalEnabled (i.e., true or false)
- PrinterState (e.g., Paper Jam, Out of Paper; see Function PrnState in Listing 1 for a complete list)
After writing all the current data to the spreadsheet and to the database, the script opens the database from the previous run of the script (if one exists) and does an item-to-item comparison, writing any differences to the spreadsheet. First, the script compares the latest database with the previous one to find new entries, then it compares the previous to the latest to find items that might have been deleted. Finally, it compares the printers that exist in both databases to see if significant fields differ; any differences between fields are considered changed items. Figure 1 shows a sample Summary sheet.
