Christian’s blog

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.

1. would be, to simply share a local connected printer by simply creating a share for the printer
2. buy a smart printer with integrated print server
3. 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.servar\Your 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.

*Babing*

Life Local port, Network printer, Windows 2003, Windows Terminal Services

As I posted earlier, I tried working around some limitations in Microsoft’s Active Directory by teaching the script some intelligence.

But, since we recently started using Thin Clients, all the stuff I did with the fancy vbs was just a waste-of-time. Turns out, Windows XP Embedded doesn’t work quite the same as a “normal” Windows XP (that’s where I tested the script on), and it simply dies when running the WMI Query. Bollocks.

So I switched back, utilizing a shortcut in Startup, but pointing to the shortened vbs (see below) instead of the ugly batch file someone wrote.

Set WshNetwork = CreateObject("WScript.Network")
 
WshNetwork.AddWindowsPrinterConnection "\\nas.barfoo.org\Kyocera FS-9100DN KX"
' Set the default printer to something useful
WshNetwork.SetDefaultPrinter "\\nas.barfoo.org\Kyocera FS-9120DN KX"

But even that doesn’t work all the time, I still have to figure out why.

Life Active Directory, Coding, Thin Clients, Windows XP Embedded, WMI, Work, WScript

OK, since I last posted about my problems with screen and irssi being unable to handle unicode chars, I got a lot of feedback (here or on IRC), and actually it was Alexander who pointed me into the right direction. LANG=C doesn’t seem to support UTF-8 characters. So after adding

export LC_ALL="en_US.UTF8"
export LANG="en_US.UTF8"

to my environment *everything* is just fine …

Gentoo irssi, screen, unicode