Windows 7 Pro - Cannot connect to printer 0x00000006
Hello experts...here's the scenario:
We have a mixed Windows 2008/2003 domain and a new print server on 2008.
We have several Kyocera printers shared on the new 2008 print server (both 32-bit and 64-bit drivers). The drivers are correct.
We have multiple windows 7 Pro systems in the building - most are 32-bit and some are 64-bit.
Recently, about 4 Windows 7 Pro systems (three 32-bit units and one 64-bit unit) have had difficulty printing to the shared Kyocera (FS-C5100DN and FS-C5250DN).
The odd thing is it works for a day or two and then fails with error "Cannot connect to printer 0x00000006". No reboot, print spooler restart, etc. fixes it. I've been able to get it working again quickly by adding the users to the domain "Print Operators" group, logging them out and logging them back in again. I then remove them from the Print Operators group and they can print for a couple of days before it starts again.
This is only happening on about 4 machines as noted earlier and the users are Local Admins on the machines.
The only other workaround which has been successful is throwing in the towel on running these users through the print server and instead printing direct to the printers via TCP/IP printer port. I don't want to keep doing this because it is going to be a problem down the road from a manageability perspective.
Please help!
Windows-7-Print-Error.png
We have a mixed Windows 2008/2003 domain and a new print server on 2008.
We have several Kyocera printers shared on the new 2008 print server (both 32-bit and 64-bit drivers). The drivers are correct.
We have multiple windows 7 Pro systems in the building - most are 32-bit and some are 64-bit.
Recently, about 4 Windows 7 Pro systems (three 32-bit units and one 64-bit unit) have had difficulty printing to the shared Kyocera (FS-C5100DN and FS-C5250DN).
The odd thing is it works for a day or two and then fails with error "Cannot connect to printer 0x00000006". No reboot, print spooler restart, etc. fixes it. I've been able to get it working again quickly by adding the users to the domain "Print Operators" group, logging them out and logging them back in again. I then remove them from the Print Operators group and they can print for a couple of days before it starts again.
This is only happening on about 4 machines as noted earlier and the users are Local Admins on the machines.
The only other workaround which has been successful is throwing in the towel on running these users through the print server and instead printing direct to the printers via TCP/IP printer port. I don't want to keep doing this because it is going to be a problem down the road from a manageability perspective.
Please help!
Windows-7-Print-Error.png
jcimarron
dpmoney--What happened when you opened the print troubleshooter offered in the popup?
The issue can be caused for several reason, user authentication time out, network collisions, network card on power save mode, memory issues, etc.
I don't understand your point on having the users printing directly to the printers if they have that posibility. I mean if they have a network card and you have the drivers I don't see any problem besides the fact that you need to install the printers on the clients pc.
I don't understand your point on having the users printing directly to the printers if they have that posibility. I mean if they have a network card and you have the drivers I don't see any problem besides the fact that you need to install the printers on the clients pc.
I can suggest another workaround that still allows you to utilize the Windows print server(s) but will also eliminate any domain authentication issues.
However, as with using a Standard TCP/IP printer on the workstation, this is still a "local printer" installation from a Windows perspective. Meaning that you will have to install the print driver on the workstation once. After that one install, it's available for any user that logs into that workstation. Instead of using a Standard TCP/IP port for the printer, I recommend using an LPR port. The added plus here is that no domain authentication is required to print.
To Enable LPD on the Windows 2008 server
Under the Print and Document Services Role, make sure that LPD Service is installed
To Enable LPR on the Windows 7 workstation
Under Control Panel | Programs | Programs and Features | Turn Windows features on and off | Print and Document Services, make sure that LPR Port Monitor is installed
To Setup a printer to use LPR on the Windows 7 workstation:
a- GoTo Start | Devices and Printers
b- Add a Printer
c- Add a Local Printer
d- Select Create a new Port
e- Select LPR Port from the drop down menu
f- Click Next
g- In the top field (Name or address of server providing LPD), enter the DNS name OR the TCP/IP address of the Windows print server that holds the desired printer
h- In the bottom field (Name of printer or print queue on that server), enter the name of the desired Windows printer
i- Click OK
j- Continue onward with a normal Windows printer setup by picking the desired print driver and naming the printer until finished
k- Open the newly created printer's properties
l- GoTo the Ports tab
m- Uncheck Enable Bidirectional support if it's enabled
n- Click Apply
o- GoTo the General tab and send a test print
This should solve the problem with printing and authentication from those workstations. You can still leave the other workstations alone that are working correctly with those printers. Adding the LPD service just gives you another option on how to get a print job into the Windows server print queue.
However, as with using a Standard TCP/IP printer on the workstation, this is still a "local printer" installation from a Windows perspective. Meaning that you will have to install the print driver on the workstation once. After that one install, it's available for any user that logs into that workstation. Instead of using a Standard TCP/IP port for the printer, I recommend using an LPR port. The added plus here is that no domain authentication is required to print.
To Enable LPD on the Windows 2008 server
Under the Print and Document Services Role, make sure that LPD Service is installed
To Enable LPR on the Windows 7 workstation
Under Control Panel | Programs | Programs and Features | Turn Windows features on and off | Print and Document Services, make sure that LPR Port Monitor is installed
To Setup a printer to use LPR on the Windows 7 workstation:
a- GoTo Start | Devices and Printers
b- Add a Printer
c- Add a Local Printer
d- Select Create a new Port
e- Select LPR Port from the drop down menu
f- Click Next
g- In the top field (Name or address of server providing LPD), enter the DNS name OR the TCP/IP address of the Windows print server that holds the desired printer
h- In the bottom field (Name of printer or print queue on that server), enter the name of the desired Windows printer
i- Click OK
j- Continue onward with a normal Windows printer setup by picking the desired print driver and naming the printer until finished
k- Open the newly created printer's properties
l- GoTo the Ports tab
m- Uncheck Enable Bidirectional support if it's enabled
n- Click Apply
o- GoTo the General tab and send a test print
This should solve the problem with printing and authentication from those workstations. You can still leave the other workstations alone that are working correctly with those printers. Adding the LPD service just gives you another option on how to get a print job into the Windows server print queue.
ASKER
Thanks for all the input. None of these actually solves the problem of why this is occurring.
@jcimarron - The network troubleshooter give me some useless resolution of how the printer was not set as default. It sets it as default and that's it. The problem still exists.
@hecgomrec - I have 100 users and though I can walk around to 100 desktops and install the printer manually that way, it is much more efficient for to dynamically control printer mappings via logon script and/or group policy
@eerwalters - Thanks for the idea, but I'd like to stay with the traditional print services.
For everyone, I can tell you that I have narrowed this down a bit. I noticed that many of the other Windows 7 computers are still going through the old 2003 print server. As a result, EVERYONE connecting to printers on this new 2008 R2 print server is having the issue. The 2008 R2 print server is a domain controller and print server - that's it. This definitely seems like some kind of a permission issue of some sort. Just does not make any sense since printing is such a straightforward thing. I actually checked on one of my Windows 7 64-bit Pro workstations earlier today and it ALSO had the issue of not being able to connect to the shared printer on the 2008 R2 print server anymore. It is almost like it loses it authentication or access token after a while. I'm a Domain Admin too so that makes me think maybe it is not necessarily a permissions issue. I noticed I don't have any of these shared printers on the 2008 R2 print server listed in the Active Directory so I did that to one of them as a test. That may be the issue.
I hope this info gives some more direction. I'll report back with more info.
@jcimarron - The network troubleshooter give me some useless resolution of how the printer was not set as default. It sets it as default and that's it. The problem still exists.
@hecgomrec - I have 100 users and though I can walk around to 100 desktops and install the printer manually that way, it is much more efficient for to dynamically control printer mappings via logon script and/or group policy
@eerwalters - Thanks for the idea, but I'd like to stay with the traditional print services.
For everyone, I can tell you that I have narrowed this down a bit. I noticed that many of the other Windows 7 computers are still going through the old 2003 print server. As a result, EVERYONE connecting to printers on this new 2008 R2 print server is having the issue. The 2008 R2 print server is a domain controller and print server - that's it. This definitely seems like some kind of a permission issue of some sort. Just does not make any sense since printing is such a straightforward thing. I actually checked on one of my Windows 7 64-bit Pro workstations earlier today and it ALSO had the issue of not being able to connect to the shared printer on the 2008 R2 print server anymore. It is almost like it loses it authentication or access token after a while. I'm a Domain Admin too so that makes me think maybe it is not necessarily a permissions issue. I noticed I don't have any of these shared printers on the 2008 R2 print server listed in the Active Directory so I did that to one of them as a test. That may be the issue.
I hope this info gives some more direction. I'll report back with more info.
ASKER
Additional info for anyone following along. Today, I received a call from a user who had been printing to the this shared printer for over a week with no issues. Suddenly, this morning, she can no longer connect to the printer. I did a reboot of the print server, a reboot of her machine and she still cannot connect. I even removed the mapping to the printer on her workstation and re-mapped it - still no luck. The dreaded "Cannot connect to printer 0x00000006" when I try to print a test page keeps coming back. Ironically, I walked around to another Windows 7 user who is mapped to the same printer and he can print fine. This is very challenging problem to solve. Every time I think I have it narrowed down to a particular cause, I have a condition which refutes my theory. It does seem to be permission related.
Any ideas?
Any ideas?
If you switch to LPR, then domain authentication is removed from the printing scenario and you can still use the print servers.
If you would at least try it for troubleshooting, it would confirm if there is a permissions issue or not. Thus, you could have more information in tracking down the root cause.
If you would at least try it for troubleshooting, it would confirm if there is a permissions issue or not. Thus, you could have more information in tracking down the root cause.
ASKER
@eerwalters, thanks for your input, but I think I have this narrowed down further without the LPR stuff.
After a lot of research and troubleshooting, this appears to definitely be a security/permissions issue. The one thing I didn't note above is the print server is a Windows 2008 R2 domain controller. It seems the Domain Controller wants to communicate with Windows 7 clients using SMB 2.1 vs. SMB 1.0 and there is some sort of access restriction that is taking place. To test this, I tried setting up a new local port for printing on my affected Windows 7 client and I tried to put the port as "\\servername\sharedprinte
DOES ANYONE KNOW IF THERE ARE SPECIAL CONSIDERATIONS THAT MUST BE TAKEN WITH RESPECT TO SECURITY CONFIG WHEN A WINDOWS 2008 R2 DC IS SETUP WITH PRINT SERVER ROLE? I HAVE IT SETUP AT ANOTHER LOCATION IN A SIMILAR MANNER WITHOUT ISSUES. IT ONLY SEEMS TO AFFECT MY KYOCERA PRINTERS SO MAYBE THE COMBINATION OF THE KYOCERA IMPLEMENTATION AND A DC'S HIGHER SECURITY REQUIREMENTS ARE CAUSING THESE SYSMPTOMS. SORRY FOR CAPS - I JUST WANT THIS PART TO STAND OUT.
I'M RENAMING THE QUESTION TITLE TOO.
After a lot of research and troubleshooting, this appears to definitely be a security/permissions issue. The one thing I didn't note above is the print server is a Windows 2008 R2 domain controller. It seems the Domain Controller wants to communicate with Windows 7 clients using SMB 2.1 vs. SMB 1.0 and there is some sort of access restriction that is taking place. To test this, I tried setting up a new local port for printing on my affected Windows 7 client and I tried to put the port as "\\servername\sharedprinte
DOES ANYONE KNOW IF THERE ARE SPECIAL CONSIDERATIONS THAT MUST BE TAKEN WITH RESPECT TO SECURITY CONFIG WHEN A WINDOWS 2008 R2 DC IS SETUP WITH PRINT SERVER ROLE? I HAVE IT SETUP AT ANOTHER LOCATION IN A SIMILAR MANNER WITHOUT ISSUES. IT ONLY SEEMS TO AFFECT MY KYOCERA PRINTERS SO MAYBE THE COMBINATION OF THE KYOCERA IMPLEMENTATION AND A DC'S HIGHER SECURITY REQUIREMENTS ARE CAUSING THESE SYSMPTOMS. SORRY FOR CAPS - I JUST WANT THIS PART TO STAND OUT.
I'M RENAMING THE QUESTION TITLE TOO.
ASKER
For anyone still following along, as a follow-up to my post above, I ended up building a new dedicated print server (non domain controller) and imported in all my print queues (including the problematic Kyocera queues).
The machine that was getting the Access Denied when trying to connect to the shared Kyocera printer on both of my domain controller / print server boxes immediately connected into this stand-alone (non domain controller) print server.
Now it is a wait and see game to determine whether or not the issue surfaces again. If it doesn't, there must be something about the combination of Domain Controller / Print Server and these Kyocera drivers (which are Win 7/2008 certified) on a Windows 2008 R2 server.
The machine that was getting the Access Denied when trying to connect to the shared Kyocera printer on both of my domain controller / print server boxes immediately connected into this stand-alone (non domain controller) print server.
Now it is a wait and see game to determine whether or not the issue surfaces again. If it doesn't, there must be something about the combination of Domain Controller / Print Server and these Kyocera drivers (which are Win 7/2008 certified) on a Windows 2008 R2 server.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I was able to figure out the problem and a solution/workaround on my own through an extensive process of elimination.
@dpmoney,
What was your solution/workaround? We have a similar (possibly identical) endemic problem, and once the error occcurs to be limited to specific network printer connections within specific Windows 7 user profiles.
CTP
CTP@ZiffrenLaw.com
What was your solution/workaround? We have a similar (possibly identical) endemic problem, and once the error occcurs to be limited to specific network printer connections within specific Windows 7 user profiles.
CTP
CTP@ZiffrenLaw.com
I installed the newest KX Driver from 20.08.2013 over the driver panel in the printer and now its works
Gotcha, thanks. The latest (as of today 20.08.2103) KX driver posted when restricting a driver search to the "legacy product" Kyocera printer FS-C5030N is dated 03.05.2013, KX version 6.0.2726. I'll try that first.
CTP
CTP