Month: February 2012

Printers are from hell

Setting Default Printer in Windows 7 with GPO (and a VB Script)

Printers are from hell

Sometimes Printers Just Print What They Want, Where They Want, When They Want

Previously I mentioned using the “Deployed Printers” of GPO’s to push printers to lab machines.  This works great so far but doesn’t solve one problem, the default printer.

While there are lots of options for how to set a default printer, we have the AD architecture to be able to have each lab/area have a specific GPO.   We also have a GPO that covers all the areas.  The higher GPO installs a script (I called it AssignDefaultPrinter-Arguement.vbs) into our standard script location.  This script can be called upon to set a printer as default dynamically.  Here’s the script, before we discuss more.

'  Script to set default printer via passed argument.
'  Taken from
'  Modified by C. Tangora to have a printer passed as an argument.

Option Explicit
Dim objPrinter
Dim objArgs

WScript.Sleep 1000

Set objArgs = Wscript.Arguments
Set objPrinter = CreateObject("WScript.Network")
objPrinter.SetDefaultPrinter objArgs(0)

The script can then be called on individual logon scripts (administered by the GPO for the specific area), without the need to specialize each script.  Since the script is in the same location for all machines, you just call the script and pass the printer you want to have as the default as the argument.  I would suggest using the quotation marks around the argument, as the arguments are separated by spaces.

A test run of this would be for a printer that was setup via the deployed printers, //printserver/LAB100A Color is the server and name of the printer.  To get it to be the default we run ….

AssignDefaultPrinter-Argument.vbs "//printserver/LAB100A Color"

… and in a few seconds (I built in some time to wait for printers to get in place in case they aren’t), the default printer gets assigned.

There may be other ways to skin this cat, and the code could be a bit cleaner, but I am not a big VBScripter, I’m a BASH kind of guy.  If I decided to forgo my UNiX love and dive deeper into Microsoft scripting, I promise to come back and make this cleaner.

Till next time.

Extension Attribute Check for Installed Files

Some applications do not have actual .app packages installed when you run the installer.  One example of this is Lab Stats.  The installer will install multiple files and some UNiX applications, so how do you know if the application is on a machine?  Casper offers a few options:

  1. Turn on UNiX application gathering for your inventory collection.
  2. Only install via Casper and look at the application package receipts.
  3. Run a script via an Extension Attribute to check for installed files.

The first two are good options, but some people do not want to turn on the UNiX application list due to the size & time it takes to gather the inventory report.  If you are implementing Casper on a site you will already have some computers with applications installed outside of Casper, so you may not be able to rely on an accurate installer receipt.  The third option will work regardless of which installer was used (as long as they all install the same files), and doesn’t increase the report time drastically.

The first two options are common tasks in Casper, the third is also but requires a bit of your own scripting.  Under Settings -> Inventory Options -> Inventory Collection Preferences -> Extension Attributes you can create a new extension attribute by clicking on “Add Extension Attributes” and change the Input Type to Populated By Script.  The script is simple, in this example I’ll show how to see if a specific file ( is in the Shared User’s directory.


if [ -e /Users/Shared/ ]
echo <result>TRUE</result>
echo <result>FALSE</result>

The extension attribute will now show TRUE if the file is there and FALSE if it is not.  You can create smart computer groups filtering on this attribute.

If you want to change the type of file it searches for (say you just want to know if a specific directory is in a specific location).  Fire up the terminal and do a ‘man if’ to see all options available.

Till Next Time.

Deploying Windows 7 Printers (really, really easy way) with GPO’s

So we spent days trying to figure out how to get the right printers to the Windows 7 machines.  In XP we utilized a script that ran at login, however that required a window that popped up and stayed up for 30 seconds or so for every user. This script was managed through Ghost, and since we are trying to avoid using Ghost we spent days figuring out how to get GPO’s to do the printer pushes.  Hopefully if you are trying to do the same we can cut down your research time.

We combed the web, we tried multiple approaches, scripts, GPO’s, scripts pushed through GPO’s.  When we tried pushing multiple printers through the Printers option (inside of Both Computer & User Preferences -> Control Panel Settings -> Printers) we had a very strange effect.  Only three printers were being displayed, but if you refreshed the Devices & Printers window a new set of three would show.  We were about to give up when I went back to the GPO’s.

Suffering from slight memory loss I couldn’t remember where the GPO’s we used were.  So I just started from the top and went opened each of the folders to find the “Printers”.  Low and behold I found a different option, “Deployed Printers”.  So I opened it up, thinking that this was the location, but it wasn’t.  So I went and found the original “Printers” and disabled the printers and headed back to my new friend, “Deployed Printers”.

If you have dealt with the “Printers” section of GPO’s, then you know it can be a hassle.  However, the “Deployed Printers” were just the opposite.  You put the server and printer queue name in and whala!  This supports multiple printers, and is super fast.

My coworkers & myself must have seen the “Deployed Printers” under the Comp/User Policies -> Windows Settings at least 100 times, but never realized it’s potential.  We were focusing a bit to much on what Google said rather than just getting down and dirty with the program (Group Policy Management Editor) like we used to before the days of Google.  Being able to get information through Google is essential for IT work, but nothing beats getting your hands dirty.

After creating 30+ new OU’s and GPO’s (which we planned on doing before this) we are now ready to start pushing out the printers from our AD/PaperCut print server to our Windows 7 machines.  The printers come in quicker than they did with any other method we tried, and removal of printers is as easy as removing the printer setting from the GPO.

There is one downside, you can not set the default printer from this window.  However, since the majority of the work is done (getting the printers properly deployed to the workstations), we decided to delay re-visiting the default printers, as it’s priority was lower.