How come a “printing system” has to be a 300mb download or CD ordered by mail? I’m all for having that as an OPTION, but for servers and for shared printers, all I need is a driver and that can probably still fit on a floppy disk… if my computers and servers still had floppy drives, but that’s another post!

I already posted about 32-bit printing in an increasingly 64-bit world, and my medium-term solution for that was to stand up a 32-bit Windows Server 2008 VM and use that as a print server.

This post is the next step: printer drivers. Specifically migrating printer drivers from one server to another. For the small amount of printers I have to manage (three printers and two plotters in this office) or even the amount of printers (queues) at my last job (about 40) it’s not so difficult to do it manually. I did just that when we moved into a new building at my last job and stood up a VM just for print queues. Pretty straightforward, really: download the latest printer drivers from the manufacturers web site, unpack them to a network location, Add Printer from the printers window/control panel, new local port, new TCP/IP port, punch in the printer’s IP address, have disk, browse, click, select… done. 40 times. A wee bit time consuming. For this migration here I only had the six, so it should be even easier. But what if the newer version of a printer driver doesn’t work properly with your as-configured software?

That’s where I am right now. We have a Kyocera CM3232 photocopier/printer/scanner/fax. It’s a big one with it’s own onboard cost accounting and “proper” network scanning & faxing. It does color and black & white and prints on up to 11x17 paper (although not borderless printing). On the old OLD server, printing CAD drawings from Acrobat Reader plots properly. On the new-old server, it didn’t. There were some weird issues where drawings would not be rotated based on the settings you selected in Acrobat, but if you left Acrobat’s settings on Portrait but clicked Advanced Print Properties and changed it to landscape on the driver settings, it would work. Not very intuitive and sure to be the cause of plenty of helpdesk calls.

We tried a different driver, we tried an old driver from a CD that presumably came with the printer and nothing seemed to work. In the end, I re-pointed everyone’s printers back to the old server and removed the queues from the new-old server… but that old server isn’t going to last much longer and it’s not easy to find parts for an old IBM X-series Pentium III tower server, and having a single Windows 2000 Server in the mix is also holding the rest of the network back.

The new-old server blew up in December. No big deal for printing, but HUGE FUCKING DEAL for everything else. I managed to get it up and running again, Frankenstein-style and convert it to a virtual machine before shutting it down for good and sending the carcass to the recycling center.

That new one is here, and one of it’s roles is hosting a Windows Server 2008 32-bit VM for print queues, so I’m back to trying to make the new server play nice and plot drawings properly… the Windows Server 2008 driver for the copier is doing the same weird things the 2003 driver was doing… If only there was a way to migrate those queues, drivers and ports over to a new server… oh wait! there is! Hallelujah I think I hear a choir of angels singi—wait, what? that only really works for moving from NT4 to 2000? It wasn’t really updated for 2003, 2003 R2 or 2008? The tool has been retired? Oh good grief!

Fortunately there’s a new version built-in to Server 2008 and Server 2008 R2. You access it from Print Management Administrative Tool, as opposed to the Printers control panel applet. From there you can add the old server as a network print server, right-click it and export printers to a file… then right-click your new server and import printers from a file. I’m in the process of doing that right now, and will be testing it with CAD drawings later today. Fingers crossed.

(or a 64-bit domain anyway)

Hooray! 32-bit is dead! Long live 64-bit! … … … not exactly.

While there are more 64-bit machines out there now than there were a year ago and tons more than a few years ago, a lot of businesses are still firmly entrenched in 32-bit Windows XP. I know we are.

We’re a pretty good example of someone who SHOULD make the leap to a 64-bit OS. If there’s one segment of the market that supports 64-bit and is extremely memory-hungry, it’s CAD work. And we’re all about CAD work. I’ve recently upgraded all the computers to 4GB of RAM and standardized them on one video card (nVidia Quadro FX 580 512MB), they’re not taking full advantage of that 4GB of memory because the 32-bit XP Professional can’t address it all. Even with the /3GB switch in the win.ini file, that just means acad.exe can use more than the 2GB limit per process… but I’m getting off topic.

When I started here in Q4 of 2008, I took one look at the “datacenter” and my jaw dropped. The main file server was an old IBM x-server with a Pentium III and a whopping 768mb of RAM and a couple 160GB hard drives in RAID1. The web/intranet server was an even older one. Both were running Windows Server 2000. The Domain Controller was newer, it at least had Windows Server 2003 on it, but it was consumer-grade, non-redundant components in a 2U rackmounted case.

Before Christmas rolled around I had replaced the ancient file server with a pair of Supermicro SuperServers with Quad-core Xeons, 4GB of RAM and 5x1TB SATA2 drives in RAID5 configurations and added an LTO-4 tape backup to the mix. Between Christmas and New Years, the web server died so I replaced that one with another Supermicro identical to the first two, but with just 2x250 and 2x500GB drives in RAID1. All of these servers were running Windows Server 2008 Standard x64.

This led me to a major problem: I was able to install printer drivers for each of the printers on the servers themselves, but with the 64-bit drivers. Client computers (XP Pro SP2 x86) tried to connect and failed because they couldn’t use the 64-bit drivers. In the old days, you could go to the sharing tab of the printer properties and click “Additional Drivers” and that was pretty much that, but cross-architecture is a little more squirrelly, and the solution is counter-intuitive.

Here is how to provide a 32-bit driver in the Additional Drivers page on a 64-bit server:

Step 1: Install the 64-bit driver on the server itself and make sure that you can print.

Step 2: On a 32-bit client (I used XP Pro) download and unpack the drivers for the desired printer (in my case it was an HP Laserjet 4600).

Step 3: Open Windows Explorer and navigate to your printer share: \\64-bit_server\ and then double-click Printers and Faxes.

Step 4: Right-click the desired printer and  select Connect. It will do it’s thing and then Uh-Oh.. where’s the driver? It will ask you to provide a driver. Browse to your local folder where you’ve stashed the .inf files for the printer and let it install. Print a test page to make sure it’s working on your computer.

Step 5: On the server, right-click the printer you just added and select Properties. Click the Sharing tab, and then click the “Additional Drivers” button. Click to check the “x86” button for 2000/XP and click OK. The server will then request the x86 versions of the files FROM your local workstation and upload them TO the server.

This is the back-asswards part that tripped me up. You’re actually uploading the driver TO the server so it’s able to them DOWNLOAD it to OTHER x86 clients that request it.

Step 6: Click ok, ok, ok, all the way back out and you should be good to go.

(This is a crosspost from the Autodesk Discussion/forum website that I was participating in)

Since I started here 15 months ago, I've been wary of messing with NLM because I didn't understand it. I still don't know all of it, but I know a lot more thanks to Travis and the rest of the contributors NLM isn't as big of a scary monster as it was before! There were Group Policy entries in my domain that were specifying an environment variable for the local license server (distributed model) by IP address, and then the next biggest office as a secondary, and third biggest as tertiary--by IP address. So for example if you logged in to a computer in site A your environment variable would be ADSK_FLEX_LICENSE=@192.168.1.2;@192.168.2.2;@192.168.3.2 It worked, it was working, so I had no motivation to change it.

While checking some things out on Travis' suggestions, I changed it to a server name, so on my test computer in site C, the environment variable was ADSK_FLEX_LICENSE=@SiteC_server;@SiteA_Server;@SiteB_Server and it worked. I then changed all my environment variables to computer (NetBIOS) names.

That sorted out 4 of my 5 offices, just the 3rd one, Site C users were still grabbing licenses from sites other than their own. Further investigation showed that two of the users who were using the wrong license server hadn't logged out and back in for some time. (this prompted a quick meeting with the CAD Manager and the Sustainability Committee to make changes to inactivity timers and lock computers after one hour, log users off after 2 and go to system standby after 3 hours outside of regular business hours). When one of the problem users logged back in and started up AutoCAD, they did not get a no license error, but rather Autocad seemed to hang for a good 60-90 seconds with an hourglass... after that AutoCAD started up normally and she was on the correct license server. I did the same thing to the the other user and got similar results.

So in the end, there was some sort of networking issue (which is still undiagnosed) that was causing clients to skip over their own license server, but changing environment variables from IP address to NetBIOS names fixed the problem.

Later in 2010 we may implement other changes recommended here and move to a single/redundant license server instead of the distributed model.