3

Here's kind of a parallel question to this one about my printer server saga...

Is it possible that AD can be corrupted or have something odd going on that affects printer configurations on these systems?

The initial reason we needed to look at rebuilding the print server was because during they year we'd have scattered reports about users unable to print. they try to add a printer, and it would tell them they didn't have permission to do so. Sometimes they didn't report it because the next day or the next reboot it would allow the printer to be added.

Policy refreshes on the computer wouldn't seem to matter.

The printer permissions were set for everyone to allow use to it, plus the problem seemed to "go away" only to reappear, same user, same computer.

Administrator-level users could sometimes log into the system, add the printer, then log off and the user could add the printer without problem. Other times it didn't seem to matter.

After we added the new print server as explained in the link, we instantly had two people unable to print (the two printers were not auto-migrated with the consultant's printer migration tool, I don't know if it was a resource kit util or third party). My boss added the printer to the new server and it still didn't work, with print jobs being stuck in the queue or going right through but nothing would print...again, outlined in the link.

I took a machine that was a clean install of XP and tried adding the printer, still didn't work.

Yesterday another consultant came in and rebuilt the server, 32 bit, from the ground up. Fresh install with each printer driver installed and configured from downloaded drivers, no migration or anything. We went back to the person who had the initial issue (we had to point her to the "printers-old" server), pointed it to the new "printers" server, and voila! It didn't work. The print jobs were stuck in the queue again.

I ended up having to delete the printer, reboot, on her local machine I deleted the driver from the print server settings (right click on the window for printers and faxes and in the drivers tab remove the printer driver), reboot, and as an admin re-add the printer from the printers-old server again, reboot and let her log in with her account and re-add the printer under her account. Then she could print again.

I'm trying to nail down the common links here. Two people on two machines (and more afterwards from reports) could not print immediately after the new print server was installed. That would tell me it's the print server. But we replaced the print server with a fresh install, fresh drivers, etc. version, and it still wouldn't work. Completely removing the driver from the client was required before the client machine could print to that printer at all...corrupted drivers from a print server? but I tried a client computer that had never had the driver installed before, and it too failed. Printer failure? But we had, in the initial report, two printers in that room, two different models (one a 1020 and the other a 2600 if memory serves) that refused to print. The 2600 had firmware updated and that didn't fix the problem, and while troubleshooting the issue I tried direct printing to the printer from the local client and it refused to work until I completely removed the driver from Windows and rebooted to a "clean slate".

So the only other thing I can think of at this point, short of finding a guru that eats assembler for breakfast and reads debugger output like the comic section of the paper, is that active directory is doing something strange. We are running AD 2003, and are supposed to be upgrading to AD 2008 in the near future (meaning "soon"), and our current installation was upgraded from AD 2000 a few years ago. I don't know of any issues with our AD configuration (errors in logs, etc.) but that doesn't mean there isn't something going on.

Can AD be causing something like this with printer configurations on our network? Anyone even HEAR of anything vaguely like this in your network or other people's networks?

Community
  • 1
Bart Silverstrim
  • 31,092
  • 9
  • 65
  • 87

1 Answers1

1

There's too little specific information to go on. Do you have a problem that can be consistently reproduced?

At the risk of being needlessly pedantic, I'd caution you not to talk about it like "AD", because Active Directory, by itself, is just a multimaster loose-convergence database engine that doesn't have anything to do with printing at all. You're really looking for features in the operating system that, acting as a client to the AD, might be causing unexpected behavior in the print spooler service.

In Windows XP and Windows Server 2003 there's very little interaction with the print spooler and the AD client functionality built into the OS. Group Policy can force out a few printing-related registry settings, and shared print queues are "published" into the AD, but that's really about it.

You can "bolt on" the ability to add per-computer or per-user printer "connections" to Windows XP using Group Policy (starting, I believe, with W2K3 Server R2). That functionality is built-in to Windows Vista and newer versions of Windows..

Take a clean Windows client that's never been joined to your domain and has no printer drivers installed, create an IPC onnection to the print server computer using NET USE \\print-server\ipc$ /user:DOMAIN\user password, then "Browse" to a printer on the server using "My Network Places" and "Connect" to a printer. That should give you a good test of whether or not the print server can function properly.

This all screams "dodgy print driver" to me, but I can't put my finger on it from here.

Evan Anderson
  • 141,071
  • 19
  • 191
  • 328
  • Combined with the previous post, the problem with the "you don't have permission to add the printer" thing was random and transient. The problem I described in the printer saga is pretty consistent. The thing is that we had to completely wipe the driver off the system before re-adding the printer, from the old print server, before she could print again. Same with another workstation; completely wipe the drivers and install the driver from the old server...(next comment) – Bart Silverstrim Aug 03 '10 at 14:45
  • Aha! It's a corrupted driver on the new print server! So I downloaded the driver from HP and installed that one. No dice, same symptoms (I installed the printer driver from HP and tried adding the printer directly, and it wouldn't work.) I also had noticed that if I try printing to the new server and get the hung-up job, delete the print job from the queue so it's empty, then try removing the driver from the client, the client computer says the driver is "in use". I need to reboot to clear it. – Bart Silverstrim Aug 03 '10 at 14:47
  • Yesterday yet ANOTHER print server was configured. Drivers were downloaded from HP, each printer added one by one and no utilities were used to migrate anything. The system was done from ground up. And once again, print difficulties were encountered. Corrupted drivers? Possible, but...weird that it happened on two systems like this. Unless there's some kind of interaction between printer drivers on the server that is killing it, or HP has a crap driver in there that's affecting clients. Still didn't explain the random issues we had before where users couldn't add printers depending on weather. – Bart Silverstrim Aug 03 '10 at 14:50
  • Up until now we've been using a batch file at login running Adprintx which looks like an executable that wraps regular windows print share calls. Old freeware, looks like it's an upgraded version of a resource kit utility from back in Win9x/win2k days. worked more reliably than other methods to just stick it in the startup folder. When we ran into problems with the permissions, though, we find that the user still can't add the printer through browsing shares the "regular" way. – Bart Silverstrim Aug 03 '10 at 14:54
  • Also, most of these workstations are using Deep Freeze, so it helped discount client corruption because we'd get a call from someone saying they had the "no permission to add printer" error, they'd reboot or come in the next day, the computer could add the printer all of a sudden. The client config doesn't change. And when it happens to students, they don't even have profiles to account for the weirdness. That's what started the "need to rebuild printer server" project. – Bart Silverstrim Aug 03 '10 at 14:56
  • The new print server seemed to have just unleashed a new level of weirdness. :-/ – Bart Silverstrim Aug 03 '10 at 14:56
  • Oh, and another weirdness, the print server machine could print to that printer without issue. the client would either have the print job get stuck (yesterday, and that was the first symptom reported to my supervisor when the first rebuilt print server was created) or the print job would queue and disappear without an error notification popping up and the print job never printed (noted in other post), only error is logged in the system log. Client couldn't print. Server could print to it fine. XP vs. Win2003 server. Different drivers? – Bart Silverstrim Aug 03 '10 at 15:00
  • Active Directory handles both Security ACLs and Group Policy, both of which can have an effect on printers. I would recommend reviewing Microsoft's Technet articles related to printer installation, configuration, and management for your version of Windows Server, and make sure that you are following best practice. – Byron Jones Nov 10 '15 at 20:02