Deploying printers with Group Policy

Reading Time: 3 minutes

In Microsoft Windows Server 2003 R2 Microsoft introduced a feature called Deploying Printers with Group Policy from within the new and improved Print Management Console. I like the new feature, but I’m not using it, because it’s not a 100% solution to the printing problems many organizations face today.

What’s lacking in R2?

I played around with the Print Management Console of Microsoft Windows Server 2003 R2 and here’s what I think is lacking:

  • The inability to set a default printer.
  • The inability to change printer settings and keeping them.
  • The inability to connect LPT ports.
  • Pushprinterconnections.exe

 

The default printer

Many companies have many views on printing. I know of companies that deploy multiple printers to employees, so they can also print on that huge colour printer when they need to, but make the most use of the black and white LaserJet across the room. This is also convenient for those rare occasions you can’t print on your default printer, because it’s out of paper or perhaps gone up into ozone. Microsoft did not give you tools in the Print Management Console to set the default printer, because it seems to assume your users only need one printer.

Printer Settings

Your printers will get connected each time you start up your computer (when printers are pushed on a per-machine basis) or you logon to it. (when printers are pushed on a per-user basis) This is extremely useful for Systems Administrators that fiddle a lot with the settings of your printers, because the new settings go into effect the next time the printers get connected. I consider this is best practice by the way… But it might not be what your boss or users want. The accountant might need to change portrait to landscape all the time for his reports. Your users might be used to adding pre-printed upside-down in the printer they just flip their prints in the printer settings… The Print Management Console forces you and your organization to look differently to printers and it might be more than what you wished for.

LPT Ports

The Print Management Console doesn’t give you the option to connect a local LPT port to a deployed printer. Your users might need this for their archaic DOS application, which happens to be critical within your organization. You’ll need to script it and when using Microsoft Windows XP you might even need to use devcon too.

Pushprinterconnections.exe

It’s good that Microsoft keeps telling us Microsoft Windows Vista is coming soon, because it will be the first Windows operating system where you don’t need to run pushprinterconnections.exe anymore. Running it isn’t really a pain in the behind, but the need for the Microsoft Windows Server 2003 R2 schema updates might be for some companies.

 

Scripting it is!

Some people will tell you to use the new Microsoft Print Console and script everything you lack around it with VBS or KIX. This way you get the most out of your Active Directory.

I consider KIX (and it’s UDFs) to be the only 100% solution for Print Management whether you’re still using Microsoft Windows NT4 or successfully migrated to Longhorn yet. It used to be a great solution in the dark ages of Microsoft Windows NT4 Server, the Microsoft Windows 2000 Server era and it still is today. When using KIX you don’t need some Print Management Console or the fancy Windows Server 2003 R2 schema updates. All you need is kix32.exe and a nice reference somewhere supplying your users and computers with startup and logon scripts.

You might read the previous piece of text and you might be wondering why I’m stating ‘You don’t need the Active Directory for all this’. It’s the truth, you don’t need it. It just makes deploying printers a lot easier. Setting logon and startup scripts through Group Policy Objects is fantastic! Checking the location description within the computeraccount, the description of the computer or the name of the computer can be done easily within KiXtart. The Organization Unit the useraccount (or for that matter the computeraccount) is a member of can be easily deducted using the InContainer() UDF. … Please don’t get me started on the way you can see whether an useraccount or a computeraccount is a member of an Active Directory or local group. This has been around for dozens of versions of KiXtart. VBS can do it too, no doubt about that, but have you seen the security alerts?

 

Conclusion

If you need a couple of examples on how to deploy printers in a way that is a 100% match with your organization’s wishes and using KiXtart just send me a message.

I’m Dutch and proud of it. [:)]
Not particularly because we have the Gay Parade, gay marriage and legal drugs, but because Ruud van Velsen is Dutch too! He’s like a hero to me, the lightning example of Microsoft ability to come up with solutions for our everyday problems and my no1 scripting guru. (I haven’t donated anything YET although I like KiXtart a lot, so this blogpost will have to suffice for the time being, Ruud. I hope you’ll excuse me…)

More reading

Click here for more info on KiXtart
A list of KiXtart UDF’s
Microsoft's Step-by-Step Guide for Print Management

Mitch Tulloch on “Deploying Printers With Group Policy in Windows Server 2003 R2

leave your comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.