Just got a new printer, a little laser job that costs about one-twenty-fifth of the first LaserWriters. And it can do color, too. I now have it set up on our little home network, so that both the Macs and the Windows machines can print to it. Mac setup was done in five minutes, including the time it took to find an extra power strip for the JetDirect box. Windows setup took about two days….
As a long time Mac zealot, the five minutes doesn’t surprise me. Two days to get the Windows side running, however, is disappointing in a number of ways. First off, this product is targeted at the SOHO market: it will typically land in situations without a knowledgeable IT person. Secondly, I hate playing uncompensated IT guy. If I am to put up with this ****, I’d like to see some $$$$ out of it. Finally, there still those who will maintain that Windows has now caught up to the Mac and that Apple has no usability advantage anymore. Sorry folks, five minutes versus two days does not look caught up to me. And yes, I am a zealot.
OK, let’s do the full ESR on this. The network has a FreeBSD box with a DHCP and DNS server and a Win2k workstation that shared the old inkjet printer. There are two Windows XP Pro laptops, a Powermac G4 and a Powerbook. The JetDirect box gets its IP address from the BSD box, its configuration web page shows up immediately in Safari on the Powerbook and I give the printer a name (ShangriLaserJet), turn off IPX and AppleTalk, all that good stuff. Actually printing to the printer requires a driver install from CD, which does not present any problems.
Now, Windows. The CD has an installation wizard, which finds the printer on the network in about a minute. It probably does a MAC address search, or has a Rendezvous browser (although that wouldn’t take that long). Click, click, complete wizard and I now have a printer entry in my Windows. Great, except it can’t print. Turns out that it made one of those weird backwards Windows constructions where a TCP/IP connection to the printer is in fact at the same level as a direct parallel or USB port connection. In Windows-speak, a ‘network printer’ is one that’s accessible through one of those \\server\printername constructions. It also turns out that the installer used the printer’s name rather than its IP address for the port. Where did the installer get that name? Must be from the printer itself, not from the DNS because my DNS server doesn’t know about “ShangriLaserJet???. That’s a pity, because now the PC can’t find the printer.
So, I add a fixed address for the printer to the DHCP server on the BSD box, and an A record (and IN record) to the name server configuration. I power-cycle the JetDirect interface, and now the printer can be pinged by name from the Windows laptop and I can print to the printer. Rejoice!
Oh wait, not quite. On the other Windows XP machine, we’re running as a non-privileged user. This in itself causes no end of hassles, as numerous software packages (cough cough Autodesk cough) don’t really deal with running without administrative privileges. On the printing front, however, it turns out that an unprivileged user doesn’t have access to that strange looks-local-but-is-actually-a-network-port. I open up the port properties, Security tab and grant all possible privileges to every account on the box, then add specific blanket privileges to that non-privileged account. All this according to the first principle of Software Security Management: when it doesn’t work, open that bad boy up. Second principle also applies: totally forget to close the hole again when opening it doesn’t work. Which it doesn’t. Solution to this one: install the driver on the final, Windows 2000, PC and share it so the unprivileged user on the XP box can access the printer. We’re up and running.
So, could I have done this without knowing what I know about networking? No way. Must I run my own DHCP and DNS server on my five host home network? Not really: I can just use IP addresses to access the printer from each host. However, the fact that the printer installer uses the Rendezvous hostname of the printer when creating its Windows printer port is severely broken behaviour: it should at least do a reverse lookup on the IP address and figure out that (on most SOHO networks) the printer IP address won’t resolve. Using IP addresses in the local/network printer port would have made this work out of the box, but it would fail as soon as the DHCP address of the JetDirect changed… that’s why Zero Configuration Networking was invented and why this technology needs to come to Windows: otherwise, Fry’s Electronics is going to get a whole lot more printers back because their users couldn’t get them to work on the network.
As for the other problem, I actually hope I’m overlooking some feature in Windows that would allow that unprivileged user access to a local/network printer port. One should not have to run as Administrator in order to access a TCP/IP printer. What if the network doesn’t have a spare PC sitting around that can take the role of print server? This is another thing SOHO users shouldn’t have to put up with. Or maybe the average Windows user knows a heck of a lot more about security and access privileges than I do. Or they just run as Admin.
