Windows 7

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.

Microsoft Deployment Toolkit, how Microsoft almost got it right.

Anyone who is deploying Windows 7 to the Enterprise should already be familiar with Microsoft’s Deployment Toolkit (MDT).  It is a great tool and so much easier than what used to be around.  There are other alternatives, however if you are already running a Microsoft Server this is a free option.

Coming from a Mac background there is still much to be desired, but Microsoft has done a good job in getting closer to what can work.  Here are a few things that Microsoft could/should change to make using MDT more useful (and things for you to watch out for when using MDT).

  1. Copying workflows, you can’t.
    • The workflows have unique ID’s.  If you copy one you are just making a reference to the original.  Modify one of them and the other gets modified as well.  Create a new workflow and copy the Task Sequence if you want a new workflow to follow the original.
  2. Active Directory binding to OU group naming
    • The AD binding feature of MDT is a great tool.  However, without hacking the MDT you are limited to seeing only the full path of the OU you are putting the computer into.  Make sure the last OU is named something that you can easily identify.
  3. You can’t move the order of your Applications.
    • There are tools to re-organize your application packages once you’ve uploaded them, but nothing native to MDT.  Things change, orders should be able to be changed as well.  This feature makes it seem like the developers never used it to modify complex workflows.
  4. The OS specific options can not be altered without a separate deployment.
    • There are some options that are set for the entire deployment, and some that are set on the individual task sequence.  It would be so useful to be able to alter some of the deployment options based on Task Sequence selected, not the deployment share it resides on.

While these are just some of the annoyances of MDT, it does the job well enough to consider it, especially for it’s price.  It’s driver injection & easily modified application installation scripts make it a useful tool to for your IT toolbox.

Till next time.