I re-deployed a printer via group policy after updating the printer drivers on the print server.
On some Windows 7 workstations the drivers could be updated on a printer by right-clicking it --> Update Driver. However most workstations do not offer this function, therefore are stuck with the printer's old driver & printing preferences. All domain users have local Admin rights to their workstations.
Trying to right-click --> Remove Device the printer displays error: Access is denied, unable to remove device.
Is there an easy way to re-deploy this network printer with the correct drivers?
You want to change the driver pushed out by GPO. My guess would be that's why you can't update the drivers on most workstations, and "some" of the workstations aren't getting the new GPO applied - those ones are the one on which you can edit the settings/update the drivers. Correct it by correcting your GPO, rather than screwing around on each individual machine... which would seem to me to largely defeat the purpose of having GPOs.
(And yes, this is the "easy way" to redeploy this network printer. Change the installed printer settings in the GPO.)
Settings applied by GPO supersede local admin rights, which would be why you're getting access denied, even with administrator rights. (Which, by the way, is a really icky thing to give to all domain users. Nothing but trouble comes from it, trust me.)
There's an old trick to make connected clients immediately update their print driver. Unshare the printer and then immediately reshare it under the same name. This will cause the printer to momentarily disconnect from the clients. Upon reconnecting, the clients will check the driver version as part of the process and download the latest drivers.
Okay, here's something fairly weird. I'll try to outline the story in a way that makes sense.
We had an old print server (windows 2003 based). We had some issues with people not being able to add printers, and as we added Win7 systems (64 bit) we were going to need other printer drivers added, so we decided we'd do a new printer server to see if that would solve some of the permission errors we were seeing and hopefully clean up some of the issues we were seeing, maybe un-munge some of the drivers.
We called in some guys from a contracting group to rebuild it for us. They built a new virtual machine, installed and updated Windows 2003 server, and used a utility that basically took the configuration of the printers on the old server and migrated them over to the new one. Renamed the old printer server "printers-old" and put the new one in place with the same IP and name as the old printer server.
We get a call from a department saying "we can't print to our 2600n color laserjet."
Boss looks at it, sees that it's not on the server. Odd, it didn't migrate over apparently when the group worked on the servr. He added it to the print server, sends a test sheet from the server, prints fine. Has the client try printing. Nothing comes out.
The print job looks like everything works. Appears in the queue, disappears, Windows says everything went fine (Windows XP, all updates). No errors pop up.
It's not just user A's machine, though. There are apparently two other people that can't print to it either.
In the course of troubleshooting (hope I remember all I've tried here...), I've:
A) deleted and re-added the printer off the network share.
B) Deleted and re-added the "local" network port (HP jetdirect IP port)
C) Deleted all instances of the 2600n from the computer. Re-added. Won't print.
D) Deleted the driver from the local system and re-installed drivers from HP.
E) Added the printer as both a network shared printer off the server and as a local IP printer. Neither works.
F) Added the printer to my workstation for testing (Ubuntu), printing direct to the IP. Printed a test sheet!
G) Picked up a newly imaged machine and updated XP on it. Added the printer from the printer server share. Send test sheet. Nothing came out. This system never had an actual printer installed on it before, and was just added to the domain, so it wasn't "contaminated" with driver/dll issues.
H)Changed the driver to generic text. Didn't work. Changed the driver to a one-off, the 2500 series, nothing printed. In the process of changing these drivers, the spooler actually crashed on the client. @#%!
I) checked connectivity. Client machine can ping the printer fine.
J) updated printer firmware. Latest from HP for the 2600N is from 2007. It restarted (the printer) and came up fine, but still Windows machines won't work.
K) test pages from the server itself work.
L) reinstalling drivers from HP, of course. The 2600N apparently doesn't have options like PCL versions or PS. Just one version. Is the 2600 like some hybrid win-printer?
M) Turned on "printers-old" server, on the "blank slate" testbed I deleted \printers\2600n share, added printer "\printers-old\2600n". Tried printing to it...NOTHING.
N) changed printer settings (turned off bidirectional printing, change print processor settings, etc.)
Errors-nothing pops up. If you didn't check the logs, all seems fine except that nothing ever comes out! BUT if you look at the logs, here's what I had:
event ID 6161
The document Test Page owned by Your_Name failed to print on printer <2600n>. Data type: RAW. Size of the spool file in bytes: 0. Number of bytes printed: 0. Total number of pages in the document: 1. Number of pages printed: 0. Client machine:. Win32 error code returned by the print processor: 0. The operation completed successfully.
The error shows up on the print server if I'm printing to \share, and on the local client if I added the printer as a "local" printer and tried sending to that.
Ordinarily I'd think it was something corrupted on the client, but it happened RIGHT after the new print server was added and printers were migrated, and it immediately affected multiple clients. More than that, this isn't the only printer; we know of one other, a 1022 I believe, that also stopped working with similar symptoms, but I've been focusing on this printer with this particular client (and testbed machine) to keep from losing complete track of what I'm doing to try fixing the issue. I also noticed that these two printers did NOT automigrate over with their utility to the new printer server, and find it odd that the old print server, whose only settings that I know of being changed were the name and IP address, can't be used by the testbed system to add the printer and print like it used to.
The next step we're pursuing is to connect it physically to this person's machine with a USB cable to see if it'll print with that. Other than this, I'm stumped. The consultants have no clue what could have happened or why it's doing this. Anyone have any ideas? Ever run into something like this before?
EDIT- Okay, more info. Another user's system wasn't printing there, and the user told me that User B never had that particular 2600 installed. Turned out she was the only one that never did, everyone in the office other than User B had it. So on a lark, I remoted to B's system, navigated to the printers-old server, and added the 2600. It worked.
I then went back to User A's system, and logged in as an administrative user, deleted the driver from the local computer (printer server settings from the printers configuration window), and deleted all instances of local/shared 2600 printers. Then I navigated to printers-old, added the printer from there. Test sheet printed!
So...something weird with the new printer server's drivers that is screwing it up? Again, this started with the migration and the fact that this printer and the 1022/1020 series printers never migrated with their utility...hmm...
Obviously this is a workaround issue for now since we want to retire the printers-old server. But this is still strange to me as to why the printer on User A's system wouldn't print with the printer installed as a local IP printer nor would it print to the printers old system until I purged the driver AND went directly to the old server. Looks like a printer driver corruption issue that spreads from the new server and doesn't go away just by deleting the printers on the client; the client gets tainted by trying anything with the new printer server?
I remember back in the days when I was having trouble with Laserjets, I would revert back to the good old Laserjet 5 driver. Always seemed to be able to print using that.
Would be interesting to see if changing to that driver on the new print server helped your issue...