Limited Users Can't Print on Network Printer, 2003 Windows Domain

sdotbrucato

[H]ard|Gawd
Joined
Oct 7, 2005
Messages
1,722
Okay so here it goes,

I'm having issues with the Limited User accounts being able to print to shared network printers. Admin and power users have no issues. The printers are all mapped and mounted fine on the limited accounts, but when they go to print, it adds the job to the print queue errors out and sits there, then it blocks up the printer for Admins and PowerUsers. I'm guessing it has to do with spooler access but I don't know. Is there a GPO or some setting I'm missing?

The printers in question are an HP OfficeJet 7410 and an HP OfficeJet 6310.
I'm sharing these all off of a Windows SBS 2003 R2 Std Box.
Clients are all Windows XP Pro SP3, never been local machines, only been part of a domain.
 
Tried that. Do I need to reinstall the printer after i enable this?

Anything else I might be missing? The people in the office are throwing fits. lol
 
I have them all as Domain Admins right now, (The only account settings that are allowing us to print) with the fear of their jobs if they mess anything up. I still want to get this fixed, it just doesn't make sense.
 
I have them all as Domain Admins right now, (The only account settings that are allowing us to print) with the fear of their jobs if they mess anything up. I still want to get this fixed, it just doesn't make sense.

Did you try, making them LOCAL admins before defaulting to domain admins?
 
Wow, you made all your users domain admins


That's not such a good idea from a ton of different perspectives...
 
How did you add the printer to the users workstation? Did you go to \\server\printername and connect the printer from there? I'm guessing its a driver permission issue. Normal users can't install drivers so you probably added the driver as an admin, but its having trouble using it. Since everyone is an admin anyway, delete the printer and re-add it while the user has elevated privledges and then demote them. (Might as well check the printers share permissions as well - I think the default is ok, but you should make sure)

If that doesn't work try adding the printer as a local, TCP\IP printer. Go to add pritner, local printer, and new tcip/ip port with the printers IP. This will make the printer local so its not per user.
 
The printers are all mapped and mounted fine on the limited accounts, but when they go to print, it adds the job to the print queue errors out and sits there, then it blocks up the printer for Admins and PowerUsers.

What errors are you seeing? Any messages in the event logs on the print server?

What did you change for rights? By default, "everyone" should have Print rights. "Creator Owner" should get them rights to manage their print jobs. Did you change this?

Can you watch the job go into the print spooler directory? How big is it? If it's bigger than 0 bytes, then it should be rendering the print job using the driver. If it's 0 bytes, then you might have a driver issue.

You've restarted the spooler service, correct? Tried a different driver (like a generic HP something or other)? It's not printing at all correct? I've seen problems where documents printed, but they spooler couldn't error remove it from the queue.

Try to create another instance of the printer on the server. Once you have that, share it. Now add it to a workstation. If you haven't changed any rights, they should be able to print. If they can't print, I'd start looking at your GPOs.


I'm guessing its a driver permission issue. Normal users can't install drivers so you probably added the driver as an admin, but its having trouble using it

By default, a normal user should be able to install a networked printer. I don't believe they can install a local printer, and that includes adding a TCP/IP port to print directly to it.






And do yourself a favor -- never add users to Domain Administrators. It may work, but you're really causing problems down the road if you do that. It's a bad, bad mistake.
 
I have them all as Domain Admins right now, (The only account settings that are allowing us to print) with the fear of their jobs if they mess anything up. I still want to get this fixed, it just doesn't make sense.


<--Speechless...Almost....You have much larger issues then users being able to print
 
By default, a normal user should be able to install a networked printer. I don't believe they can install a local printer, and that includes adding a TCP/IP port to print directly to it.

I thought it would only let a normal user if the driver is already installed on the machine? Maybe it will allow a windows shared printer because the driver doesn't really get installed on the workstation?

(Most of my experience here is from working in a terminal server/citrix environment where you REALLY don't want users to be able to install new print drivers.) I just know that if you go to a local workstation and as an admin create a new local tcp/ip printer with the right drivers it will (should) work. :)

And by the way - while I agree that giving admin rights certainly isn't the right thing to do, I understand the need at times. If the OP can't fix the problem the right way in a reasonable amount of time, you must do whatever is necessary to band-aid the problem until you can fix it right. In this case if it means giving admin rights, so be it as long as it is a temporary solution. I would also note though that this problem should have been detected and fixed in the testing phase so you wouldn't need such a drastic fix. (Sorry, I'm getting down from my soap box now).
 
guys its not that big of a deal that they are Domain Admins. if you follow the forums you would know that d3c1us is probably talking about the small office setup he setup for one of his family members. i doubt the place cares about the users having admin access.

d3c1us - if you used SBS 2003, you should have went through the wizards for adding users. and if you joined the machines with the sbs wizard, the machines should have been as local admins.

try adding them to local admins. log onto or connect to the machine through management console, add the user to the local administrators group. try that.
 
did you gpupdate all machines and the server and then reboot?
Sure did, I do this after every GPO Update.

Wow, you made all your users domain admins
That's not such a good idea from a ton of different perspectives...

How did you add the printer to the users workstation? Did you go to \\server\printername and connect the printer from there?.

That's exactly what I did,

What errors are you seeing? Any messages in the event logs on the print server?

What did you change for rights? By default, "everyone" should have Print rights. "Creator Owner" should get them rights to manage their print jobs. Did you change this?

Can you watch the job go into the print spooler directory? How big is it? If it's bigger than 0 bytes, then it should be rendering the print job using the driver. If it's 0 bytes, then you might have a driver issue.

You've restarted the spooler service, correct? Tried a different driver (like a generic HP something or other)? It's not printing at all correct? I've seen problems where documents printed, but they spooler couldn't error remove it from the queue.

The only error I'm getting is in the Spooler and it just says "error printing".
The print job goes directly to the spooler and errors out with a normal print size, not 0kb. So this means it's not a driver issue correct?

And by the way - while I agree that giving admin rights certainly isn't the right thing to do, I understand the need at times. If the OP can't fix the problem the right way in a reasonable amount of time, you must do whatever is necessary to band-aid the problem until you can fix it right. In this case if it means giving admin rights, so be it as long as it is a temporary solution. I would also note though that this problem should have been detected and fixed in the testing phase so you wouldn't need such a drastic fix. (Sorry, I'm getting down from my soap box now).

Thank you, I was getting over reading all the "ZOMG DOMAIN ADMIN, YOU'RE DUMB comments, I know what I did, I know what COULD happen, but as Marley said, this is a small office, maybe 10 users, and most are family, its family owned and run, so I really have little to worry about, especially if it's just a band-aid.


But on to the working resolution, like a few of you had mentioned and I thank you for reminding me of, I just added the printer as a local printer via TCP/IP, and all is well. I thank you all for your help!

I'd really like to know why I wasn't able to just have the networked printers working, but my Server experience is low, and I'm sure I'll run into more things that I just don't understand, but thats where real job experience comes into play.

d3c1us - if you used SBS 2003, you should have went through the wizards for adding users. and if you joined the machines with the sbs wizard, the machines should have been as local admins. try that.

Also, I did use the Add User wizard, but I never had to use the SBS Wizard to add the machines, I got the server up and formatted and then I reimaged all the machines with XP SP3, so they joined the domain from setup. I've seen the ConnectComputer Wizard mentioned in another one of my threads, and I never had to use it... But it seems like me doing the fresh installs is kicking me in the ass...
 
Also, I did use the Add User wizard, but I never had to use the SBS Wizard to add the machines, I got the server up and formatted and then I reimaged all the machines with XP SP3, so they joined the domain from setup. I've seen the ConnectComputer Wizard mentioned in another one of my threads, and I never had to use it... But it seems like me doing the fresh installs is kicking me in the ass...

Try removing a test machine from the domain and adding via connectcomputer. This set a number of registry settings and such. Maybe your fix is in the initial setup of the client machines.
 
You may need to enable kernel mode drivers via GPO.

Worst idea ever. Kernel mode drivers are not support in server 2003. They will cause you nothing but headaches.

How did you add the printer to the users workstation? Did you go to \\server\printername and connect the printer from there? I'm guessing its a driver permission issue. Normal users can't install drivers so you probably added the driver as an admin, but its having trouble using it. Since everyone is an admin anyway, delete the printer and re-add it while the user has elevated privledges and then demote them. (Might as well check the printers share permissions as well - I think the default is ok, but you should make sure)

If that doesn't work try adding the printer as a local, TCP\IP printer. Go to add pritner, local printer, and new tcip/ip port with the printers IP. This will make the printer local so its not per user.

Wrong. By default normal users can install drivers from a print server as long as the print server is in the same AD forrest. It's call point and print. If this fails you will get an error message when adding the queue say "There is a policy in effect on the system prinventing....."

But on to the working resolution, like a few of you had mentioned and I thank you for reminding me of, I just added the printer as a local printer via TCP/IP, and all is well. I thank you all for your help!

This doesn't really solve your problem. you just work around it ? What do the event logs say ? This is not a permssions problem on the server otherwise you wouldn't even be able to add the queue to the client system. Print is the lowest prossible permssions you can give on a print queue.
 
This doesn't really solve your problem. you just work around it ? What do the event logs say ? This is not a permssions problem on the server otherwise you wouldn't even be able to add the queue to the client system. Print is the lowest prossible permssions you can give on a print queue.

I took another look at the Event Logs, it appears I'm getting a 6161 Event.

"The document Untitled - Notepad owned by SBoates failed to print on printer PRINTER01. Data type: NT EMF 1.008. Size of the spool file in bytes: 976. Number of bytes printed: 0. Total number of pages in the document: 1. Number of pages printed: 2. Client machine: \\192.168.1.105. Win32 error code returned by the print processor: 67. The network name cannot be found."

Maybe this will help... =|
 
Just dug a little deeper, and I found something that is telling me to grant full permission to "C:\WINDOWS\System32\spool\" and then restart the Server.

Is this such a good idea? I had a feeling from the beginning it had to do with the Spooler, and the thread from EventID.net kind of makes it all make sense....

But I figured I'd ask here first, because I have a trust thing here. lol
 
Worst idea ever. Kernel mode drivers are not support in server 2003. They will cause you nothing but headaches.

Please know a little more of what you are talking about before making statements like this. By default, they are disabled. That does not mean they are not supported. Whether or not you need to enable this option depends on the drivers. Most newer drivers are user mode, but from time to time you run into a pesky ones. If you have headaches, it is not from this feature, it is from crappy drivers.
 
You should use all the wizards in SBS, or else little shit will drive you nuts. If you joined them with the connect2wizard it would have made em local admin which probably would have fixed it.

I dont see any problem giving em access to spool directory, cant do much with that.
 
You should use all the wizards in SBS, or else little shit will drive you nuts. If you joined them with the connect2wizard it would have made em local admin which probably would have fixed it.

I dont see any problem giving em access to spool directory, cant do much with that.

I made them all local admins before the jump to Domain Admin, didnt help me.. Im going to try the Spool access thing later tonight... hope it works..
 
I made them all local admins before the jump to Domain Admin, didnt help me.. Im going to try the Spool access thing later tonight... hope it works..

Local admins on their machines and/or local admins on the print server?

In any event, the spooler directory perms sounds like a good next step.
 
Local admins on their machines and/or local admins on the print server?

In any event, the spooler directory perms sounds like a good next step.


I don't see how this could possibly be the issue if it makes it to the server then the user has rights to print. From there it would run under the local system.

What is this "limited users" group ? Is this an SBS thing ?

By deafult Administrators get FC as does SYSTEM, Power users get manage printers, users get print and creator owner gets print and manage documents. So a domain user should have full rights to print.

What does the event log say ? If its permssion you should see fail access logs to the security log.
 
I don't see how this could possibly be the issue if it makes it to the server then the user has rights to print. From there it would run under the local system.

Because making them domain admins allowed them to print and the OP said he made them local admins before jumping to domain admins. If the were local admins on the desktops, the only conceivable difference becoming domain admins would make is that they're now admins on the print server. If the problem does come down to permissions on the spooler directory, this would fit nicely.
 
I don't see how this could possibly be the issue if it makes it to the server then the user has rights to print. From there it would run under the local system.

What is this "limited users" group ? Is this an SBS thing ?

I've seen the permissions thing said a few times when googling for Event 6161, thats why I was asking.

Sorry it's just the "Users" Group, but I wanted to make sure I made it clear it wasn't Power Users and Admins.
 
I made them all local admins before the jump to Domain Admin, didnt help me.. Im going to try the Spool access thing later tonight... hope it works..

Well user should have Read & Execute inherted from the root on the spool directory. They should have special permssion on the printers folder in the spool directory which should be set as below....

Traverse Folder/ Execute file
Read Attributes
Read Extended Attributes
Create Files/Write Data
Create Folders/Append Data

Unless someone was in there mucking with permssions with is how it is by deafult for the "users" group.
 
Well user should have Read & Execute inherted from the root on the spool directory. They should have special permssion on the printers folder in the spool directory which should be set as below....

Traverse Folder/ Execute file
Read Attributes
Read Extended Attributes
Create Files/Write Data
Create Folders/Append Data

Unless someone was in there mucking with permssions with is how it is by deafult for the "users" group.

This SBS box is barely a week old, I am the only one who has touched it, so permissions were not touched, I really don't understand this, and all the research I've done, the Event6161 seems to be more common with terminal services and RWW... I have a few more things I need to try and look at (such as default port# on the printer, and quadruple check permissions on the printer)
 
This SBS box is barely a week old, I am the only one who has touched it, so permissions were not touched, I really don't understand this, and all the research I've done, the Event6161 seems to be more common with terminal services and RWW... I have a few more things I need to try and look at (such as default port# on the printer, and quadruple check permissions on the printer)

Try disabling advanced printing features on the the shared printer. Whenever I have had a similar problem, it was always because of poorly written drivers. Have you tried updating to the latest drivers for the printer? When you do, you have to update the print share and/I] every client.
 
Actually, that is a very good point. What type of printers are we talking about here? Good ol' standard Laserjet 4000's or some cheapy Lexmark that someone bought at Walmart for $30?

Some drivers work "more better" than others. :)
 
Okay, well this just goes to show, don't use the HP Setup, and to attach the printers as local not networked to the server.

I'm not sure if this is a fix or a band-aid still but I dont have to add the printers to the machines, and I can mount the printers to the specific users that use the specific printers.
 
Okay, well this just goes to show, don't use the HP Setup, and to attach the printers as local not networked to the server.

I'm not sure if this is a fix or a band-aid still but I dont have to add the printers to the machines, and I can mount the printers to the specific users that use the specific printers.


90% of print problems come from 3rd party print processors. In your case most officejet MFP's don't get very good eneterprise level driver support. Host based printers don't work well from print servers. I don't allow SOHO devices. You're having fun with 2 differnet drivers. I have over 700 HP devices(over 50 differnt models).
 
Have you checked the permissions on the printer properties? Everyone should be set to print.
 
The office is growing and eventually we will be getting more business friendly devices in the office, but until then we really are just a SOHO...

I got everything to work with the generic OfficeJet drivers, attached locally to the server, so Im happy for now. Im sure Ill be on the forums shortly with another issue though =)
 
The office is growing and eventually we will be getting more business friendly devices in the office, but until then we really are just a SOHO...

I got everything to work with the generic OfficeJet drivers, attached locally to the server, so Im happy for now. Im sure Ill be on the forums shortly with another issue though =)

I already looked those two model up. Unfortuantly they are support by the Hp Universal Print Driver. I have been very happy with the UPD and have had very few issues even though I have over 700 devices between two print servers.
 
Back
Top