Yes, yes. I do list a lot of crappy products (go on, laugh; I don’t really care). Yesterday I had quite a struggle with Microsoft Windows Server 2003 and Terminal services (or more precisely with their way on how to deal with network printers).
As most of you know, there a two (possibly three) different ways on how to do network printers.
- would be, to simply share a local connected printer by simply creating a share for the printer
- buy a smart printer with integrated print server
- a combination of 1. and 2.
We luckily enough do have printers with integrated print servers, so that wouldn’t be a problem. *But* you get a problem if you’re trying to monitor the printer queue if you simply create a new TCP/IP connection from another target. You simply can’t tell who’s printing what.
So we tried to find a way to reuse the already shared printers. And there actually is. Simply create a new local printer (as you would if you’d use the TCP/IP way), but don’t select TCP/IP, select Local Port instead. That’s the whole catch (I’ve been trying to figure that out half the day yesterday). Then simply supply the location (it’s URI formatted like this.is.my.printer.servarYour shady Printer) and click through the dialog.
The only catch with this is, that you have to install any non-standard printer drivers locally. That’s why I tried reusing the already present network drivers, but Windows treats Printers and Network printers differently. The former is treated as a global object (as in visible to all users on the current machine), the latter is only visible to the current user.
2 thoughts to “Windows terminal services & network printers”
The steps you performed sound unnecessarily complicated.
Microsoft offers so-called “Printing services for Unix”. These include an LPD which can be managed through the standard lpr/lpq/lprm commands
And that helps me how exactly ? I’m not using them on a Linux box, I’m using them on a Windows Terminal server, so I don’t see the point in adding a LPD interface there.