I’ve spent the last several weeks fighting problem after problem at Key, so I’ve decided to blog about them (in reverse order) as a form of therapy. This is kind of long, but I don’t give a crap.
Today’s problem started first thing (gotta love that). Last night (mistake #1) I migrated all of our printer shares to a new server (well, VM), did some testing against the printer in my office (mistake #2), and finally modified the logon script to point all of the users (mistake #3) to the new server. I knew something was up when my Blackberry went nuts around 7:45 this morning while on Rt 2. Sure enough, almost no one could print. Once I got in the office, I swung everyone back to the old print server and spent most of the rest of the day troubleshooting what the hell was happening.
When a Windows client connects to a printer shared off another Windows computer, typically Windows Server, the spooler service on the client initates an automatic download of that printer’s driver off the server. This typically goes off without a hitch, but occasionally problems can arise when the driver being downloaded is a third-party driver or is a kernel-mode driver. Through some trial and error, I determined that printer drivers were not being installed when connecting to the new server, but I couldn’t figure out why. These same drivers (so I assumed) were being installed off the old server, so why wasn’t this server working? I’ve had the typical group policy settings required for this to work set for years.
I have yet to find a solid answer for what was going on, but I have two theories and one resolution.
Theory one: I found this in a Microsoft newsgroup posting from last year.
The default state, unconfigured, allows workstations to add a printer connection to any print server in the same AD forest. This policy applies to XP SP1 and later (I believe). In order for the desktop to comply with this policy, it must confirm that the print server is indeed in the same forest as the workstation. Apparently, it can only do this if it can find the print server via its machine object in AD.
This new print server is a domain controller running under VMware ESX. We’re a one site, one domain, one forest shop, so it stands to reason that the client should see the DC in the forest no problem. However, virtual machines have a way of complicating things, particularly with time syncronization (which I did address per VMware’s docs). Kerberos is typically used to verify a machine exists in the same forest, and of course if the time between the client and the server is off by more than 5 minutes, Kerberos authentication will fail. I’m not convinced that this was the problem, in fact I’m pretty sure it wasn’t. However, to be on the safe side, I followed step 3 in MS KB888046 to disable the forest check for “Point and Print”.
Theory two: The driver wasn’t being installed because of a version conflict or other permissions issue.
Remeber how I said I assumed the new server used the same driver version as the old? Yeah, that wasn’t the case. I had downloaded the most recent driver version off the Kyocera website for these printers and used that on the new server, assuming it was used on the old server. Turns out there’s actually a newer version on the CD that came with most of the printers, and that’s what was used to install these new printers a few weeks ago (no, I didn’t do the installs). Since the new server was using an older version of the same driver, its entirelly possible that during the connection attempt, the driver wasn’t downloading because it refused to overwrite a newer version that was already installed. Alternatively, it’s possible the client never bothered to download the driver from the server, since it already had it, but the versions were incompatible and thus didn’t work. In either case, it seems like this was the true issue.
Resolution: Pre-install the printer driver.
Windows 2000 introduced a great little file called printui.dll. This file, when run via rundll32.exe, allows you to script various printer tasks that normally would require a GUI. One of those tasks is installing a printer driver without a printer. This, combined with an Altiris Software Delivery Job, saved my day. I updated the driver on the new server with this most recent CD version, copied said CD version to my DFS netinstall share, and set up an Altiris job to copy down the driver and install it using printui.dll on all of my client machines. Presto, all connections to the new print server worked like a champ.
Remember those three mistakes I pointed out above? Let’s address them one at a time.
Mistake #1: Last night…
Never, ever, ever, make a change as wide-reaching and client facing as a printer server move late at night when you’re tired, working in your PJs at home, and have had several glasses of wine.
Mistake #2: …did some testing against (my) printer…
My printer is one of the only Dell’s left on campus. Practically everyone else is using a Kyocera printer, which are all brand new and all use the same basic driver. So why the hell wouldn’t I AT LEAST test against ONE of the Kyocera printers? See mistake #1.
Mistake #3: …point(ed) all of the users…
If there’s one thing I can never seem to learn, its to test against a control group. I was so eager to get this long-standing project off my plate I went ahead and pulled the trigger, moving THE ENTIRE CAMPUS to the new print server immediately after putting it into production with minimal testing and maximum inebriation. Dumbass.
So, now that I think I’ve solved the problem, I’ve pointed a few departments (all my non-screamers) at the new server and we’ll see how it goes. I’m also going to keep a very close eye on this server’s DC duties, just in case theory one proves true. The last thing I want is a Kerberos issue on a DC. And, for those of you in the back of the room shaking your head at the thought of a DC acting as a print server, get over it. My DC’s are low-volume machines that are wasted not doing something else. Yes, it’s a VM, but Windows licenses aren’t exactly free either.