"Access denied, unable to connect" viewing shared print queues

S

Steve M

I am having a problem where all non-administrators get an error message
"Access denied, unable to connect" when they open up their network printer
queue window. The clients are windows 2000 Pro machines and the print
servers are windows 2000 domain controllers. They can print to the shared
printers fine but they cannot see the print queue nor delete their print
jobs. Domain admins can do this fine. The printers are installed on
Windows 2000 domain controllers with SP4. This is not a problem for the
users if they install a printer on a windows 2000 member server. The users
have a group policy that restricts security. Taking the PC's out of the
group policy lockdown does fix the problem. So I am thinking there is
something in the group policy on the desktops that is causing the problem
but I haven't found out what setting is doing it. If a domain admin logs
into the locked-down PC they do not get the error. Here are the printer
configuration of the lockdown policy:

Policy Setting
Allow printers to be published Disabled
Allow pruning of published printers Enabled
Automatically publish new printers in Active Directory Disabled
Check published state Enabled
Computer location Disabled
Custom support URL in the Printers folder's left pane Disabled
Directory pruning interval Not configured
Directory pruning priority Not configured
Directory pruning retry Not configured
Disallow installation of printers using kernel-mode drivers Not
configured
Log directory pruning retry events Not configured
Pre-populate printer search location text Not configured
Printer browsing Not configured
Prune printers that are not automatically republished Not
configured
Allow Print Spooler to accept client connections Not configured
Web-based printing Disabled


Any ideas?
 
A

Alan Morris\(MSFT\)

this is an issue when the print spooler on the print server is getting
access denied contacting the spooler service on the client machines.

When the client opens the queue remotely the server connects to the client
and displays the jobs in the queue. Since the server is blocked by the
client, it post an access denied.

--
Alan Morris
Windows Printing Team
Search the Microsoft Knowledge Base here:
http://support.microsoft.com/default.aspx?scid=fh;[ln];kbhowto

This posting is provided "AS IS" with no warranties, and confers no rights.
 
S

Steve M

So then why does the problem clear up if I give the user local administrator
rights?


Alan Morris(MSFT) said:
this is an issue when the print spooler on the print server is getting
access denied contacting the spooler service on the client machines.

When the client opens the queue remotely the server connects to the client
and displays the jobs in the queue. Since the server is blocked by the
client, it post an access denied.

--
Alan Morris
Windows Printing Team
Search the Microsoft Knowledge Base here:
http://support.microsoft.com/default.aspx?scid=fh;[ln];kbhowto

This posting is provided "AS IS" with no warranties, and confers no rights.

Steve M said:
I am having a problem where all non-administrators get an error message
"Access denied, unable to connect" when they open up their network printer
queue window. The clients are windows 2000 Pro machines and the print
servers are windows 2000 domain controllers. They can print to the shared
printers fine but they cannot see the print queue nor delete their print
jobs. Domain admins can do this fine. The printers are installed on
Windows 2000 domain controllers with SP4. This is not a problem for the
users if they install a printer on a windows 2000 member server. The
users
have a group policy that restricts security. Taking the PC's out of the
group policy lockdown does fix the problem. So I am thinking there is
something in the group policy on the desktops that is causing the problem
but I haven't found out what setting is doing it. If a domain admin logs
into the locked-down PC they do not get the error. Here are the printer
configuration of the lockdown policy:

Policy Setting
Allow printers to be published Disabled
Allow pruning of published printers Enabled
Automatically publish new printers in Active Directory Disabled
Check published state Enabled
Computer location Disabled
Custom support URL in the Printers folder's left pane Disabled
Directory pruning interval Not configured
Directory pruning priority Not configured
Directory pruning retry Not configured
Disallow installation of printers using kernel-mode drivers Not
configured
Log directory pruning retry events Not configured
Pre-populate printer search location text Not configured
Printer browsing Not configured
Prune printers that are not automatically republished Not
configured
Allow Print Spooler to accept client connections Not configured
Web-based printing Disabled


Any ideas?
 
A

Alan Morris\(MSFT\)

not sure but it's a permissions issue. I'm just a spooler guy.

--
Alan Morris
Windows Printing Team
Search the Microsoft Knowledge Base here:
http://support.microsoft.com/default.aspx?scid=fh;[ln];kbhowto

This posting is provided "AS IS" with no warranties, and confers no rights.

Steve M said:
So then why does the problem clear up if I give the user local
administrator
rights?


Alan Morris(MSFT) said:
this is an issue when the print spooler on the print server is getting
access denied contacting the spooler service on the client machines.

When the client opens the queue remotely the server connects to the
client
and displays the jobs in the queue. Since the server is blocked by the
client, it post an access denied.

--
Alan Morris
Windows Printing Team
Search the Microsoft Knowledge Base here:
http://support.microsoft.com/default.aspx?scid=fh;[ln];kbhowto

This posting is provided "AS IS" with no warranties, and confers no rights.

Steve M said:
I am having a problem where all non-administrators get an error message
"Access denied, unable to connect" when they open up their network printer
queue window. The clients are windows 2000 Pro machines and the print
servers are windows 2000 domain controllers. They can print to the shared
printers fine but they cannot see the print queue nor delete their
print
jobs. Domain admins can do this fine. The printers are installed on
Windows 2000 domain controllers with SP4. This is not a problem for
the
users if they install a printer on a windows 2000 member server. The
users
have a group policy that restricts security. Taking the PC's out of
the
group policy lockdown does fix the problem. So I am thinking there is
something in the group policy on the desktops that is causing the problem
but I haven't found out what setting is doing it. If a domain admin logs
into the locked-down PC they do not get the error. Here are the
printer
configuration of the lockdown policy:

Policy Setting
Allow printers to be published Disabled
Allow pruning of published printers Enabled
Automatically publish new printers in Active Directory
Disabled
Check published state Enabled
Computer location Disabled
Custom support URL in the Printers folder's left pane Disabled
Directory pruning interval Not configured
Directory pruning priority Not configured
Directory pruning retry Not configured
Disallow installation of printers using kernel-mode drivers
Not
configured
Log directory pruning retry events Not configured
Pre-populate printer search location text Not configured
Printer browsing Not configured
Prune printers that are not automatically republished Not
configured
Allow Print Spooler to accept client connections Not
configured
Web-based printing Disabled


Any ideas?
 
S

Steve M

I think I found it. The desktop group policy has "Access this computer from
the network" set to only Administrators. When I added Users it worked. So
the User needs to be able to access his own PC over the network. Who would
think.

Thanks for your help!


Alan Morris(MSFT) said:
not sure but it's a permissions issue. I'm just a spooler guy.

--
Alan Morris
Windows Printing Team
Search the Microsoft Knowledge Base here:
http://support.microsoft.com/default.aspx?scid=fh;[ln];kbhowto

This posting is provided "AS IS" with no warranties, and confers no rights.

Steve M said:
So then why does the problem clear up if I give the user local
administrator
rights?


Alan Morris(MSFT) said:
this is an issue when the print spooler on the print server is getting
access denied contacting the spooler service on the client machines.

When the client opens the queue remotely the server connects to the
client
and displays the jobs in the queue. Since the server is blocked by the
client, it post an access denied.

--
Alan Morris
Windows Printing Team
Search the Microsoft Knowledge Base here:
http://support.microsoft.com/default.aspx?scid=fh;[ln];kbhowto

This posting is provided "AS IS" with no warranties, and confers no rights.

I am having a problem where all non-administrators get an error message
"Access denied, unable to connect" when they open up their network printer
queue window. The clients are windows 2000 Pro machines and the print
servers are windows 2000 domain controllers. They can print to the shared
printers fine but they cannot see the print queue nor delete their
print
jobs. Domain admins can do this fine. The printers are installed on
Windows 2000 domain controllers with SP4. This is not a problem for
the
users if they install a printer on a windows 2000 member server. The
users
have a group policy that restricts security. Taking the PC's out of
the
group policy lockdown does fix the problem. So I am thinking there is
something in the group policy on the desktops that is causing the problem
but I haven't found out what setting is doing it. If a domain admin logs
into the locked-down PC they do not get the error. Here are the
printer
configuration of the lockdown policy:

Policy Setting
Allow printers to be published Disabled
Allow pruning of published printers Enabled
Automatically publish new printers in Active Directory
Disabled
Check published state Enabled
Computer location Disabled
Custom support URL in the Printers folder's left pane Disabled
Directory pruning interval Not configured
Directory pruning priority Not configured
Directory pruning retry Not configured
Disallow installation of printers using kernel-mode drivers
Not
configured
Log directory pruning retry events Not configured
Pre-populate printer search location text Not configured
Printer browsing Not configured
Prune printers that are not automatically republished Not
configured
Allow Print Spooler to accept client connections Not
configured
Web-based printing Disabled


Any ideas?
 
A

Alan Morris\(MSFT\)

Actually it is the spooler service on the print server that must access the
spooler service on the client. When the user is logged on, network access
is blocked inbound to the machine.

Thanks for letting us know the solution, it will help someone in the future.

--
Alan Morris
Windows Printing Team
Search the Microsoft Knowledge Base here:
http://support.microsoft.com/default.aspx?scid=fh;[ln];kbhowto

This posting is provided "AS IS" with no warranties, and confers no rights.

Steve M said:
I think I found it. The desktop group policy has "Access this computer
from
the network" set to only Administrators. When I added Users it worked.
So
the User needs to be able to access his own PC over the network. Who
would
think.

Thanks for your help!


Alan Morris(MSFT) said:
not sure but it's a permissions issue. I'm just a spooler guy.

--
Alan Morris
Windows Printing Team
Search the Microsoft Knowledge Base here:
http://support.microsoft.com/default.aspx?scid=fh;[ln];kbhowto

This posting is provided "AS IS" with no warranties, and confers no rights.

Steve M said:
So then why does the problem clear up if I give the user local
administrator
rights?


this is an issue when the print spooler on the print server is
getting
access denied contacting the spooler service on the client machines.

When the client opens the queue remotely the server connects to the
client
and displays the jobs in the queue. Since the server is blocked by
the
client, it post an access denied.

--
Alan Morris
Windows Printing Team
Search the Microsoft Knowledge Base here:
http://support.microsoft.com/default.aspx?scid=fh;[ln];kbhowto

This posting is provided "AS IS" with no warranties, and confers no
rights.

I am having a problem where all non-administrators get an error message
"Access denied, unable to connect" when they open up their network
printer
queue window. The clients are windows 2000 Pro machines and the print
servers are windows 2000 domain controllers. They can print to the
shared
printers fine but they cannot see the print queue nor delete their
print
jobs. Domain admins can do this fine. The printers are installed
on
Windows 2000 domain controllers with SP4. This is not a problem for
the
users if they install a printer on a windows 2000 member server.
The
users
have a group policy that restricts security. Taking the PC's out of
the
group policy lockdown does fix the problem. So I am thinking there is
something in the group policy on the desktops that is causing the
problem
but I haven't found out what setting is doing it. If a domain admin
logs
into the locked-down PC they do not get the error. Here are the
printer
configuration of the lockdown policy:

Policy Setting
Allow printers to be published Disabled
Allow pruning of published printers Enabled
Automatically publish new printers in Active Directory
Disabled
Check published state Enabled
Computer location Disabled
Custom support URL in the Printers folder's left pane Disabled
Directory pruning interval Not configured
Directory pruning priority Not configured
Directory pruning retry Not configured
Disallow installation of printers using kernel-mode drivers
Not
configured
Log directory pruning retry events Not configured
Pre-populate printer search location text Not configured
Printer browsing Not configured
Prune printers that are not automatically republished Not
configured
Allow Print Spooler to accept client connections Not
configured
Web-based printing Disabled


Any ideas?
 
S

Steve M

Are you aware of any workaround to this besides giving them admin rights or
letting users access desktops over the network? These 2 workarounds are
against security standards. It's like I just want to give the locally
logged in user access to his own PC over the network. I tried 'creator
owner' and 'interactive' but that didn't work.


Alan Morris(MSFT) said:
Actually it is the spooler service on the print server that must access the
spooler service on the client. When the user is logged on, network access
is blocked inbound to the machine.

Thanks for letting us know the solution, it will help someone in the future.

--
Alan Morris
Windows Printing Team
Search the Microsoft Knowledge Base here:
http://support.microsoft.com/default.aspx?scid=fh;[ln];kbhowto

This posting is provided "AS IS" with no warranties, and confers no rights.

Steve M said:
I think I found it. The desktop group policy has "Access this computer
from
the network" set to only Administrators. When I added Users it worked.
So
the User needs to be able to access his own PC over the network. Who
would
think.

Thanks for your help!


Alan Morris(MSFT) said:
not sure but it's a permissions issue. I'm just a spooler guy.

--
Alan Morris
Windows Printing Team
Search the Microsoft Knowledge Base here:
http://support.microsoft.com/default.aspx?scid=fh;[ln];kbhowto

This posting is provided "AS IS" with no warranties, and confers no rights.

So then why does the problem clear up if I give the user local
administrator
rights?


this is an issue when the print spooler on the print server is
getting
access denied contacting the spooler service on the client machines.

When the client opens the queue remotely the server connects to the
client
and displays the jobs in the queue. Since the server is blocked by
the
client, it post an access denied.

--
Alan Morris
Windows Printing Team
Search the Microsoft Knowledge Base here:
http://support.microsoft.com/default.aspx?scid=fh;[ln];kbhowto

This posting is provided "AS IS" with no warranties, and confers no
rights.

I am having a problem where all non-administrators get an error message
"Access denied, unable to connect" when they open up their network
printer
queue window. The clients are windows 2000 Pro machines and the print
servers are windows 2000 domain controllers. They can print to the
shared
printers fine but they cannot see the print queue nor delete their
print
jobs. Domain admins can do this fine. The printers are installed
on
Windows 2000 domain controllers with SP4. This is not a problem for
the
users if they install a printer on a windows 2000 member server.
The
users
have a group policy that restricts security. Taking the PC's out of
the
group policy lockdown does fix the problem. So I am thinking
there
is
something in the group policy on the desktops that is causing the
problem
but I haven't found out what setting is doing it. If a domain admin
logs
into the locked-down PC they do not get the error. Here are the
printer
configuration of the lockdown policy:

Policy Setting
Allow printers to be published Disabled
Allow pruning of published printers Enabled
Automatically publish new printers in Active Directory
Disabled
Check published state Enabled
Computer location Disabled
Custom support URL in the Printers folder's left pane Disabled
Directory pruning interval Not configured
Directory pruning priority Not configured
Directory pruning retry Not configured
Disallow installation of printers using kernel-mode drivers
Not
configured
Log directory pruning retry events Not configured
Pre-populate printer search location text Not configured
Printer browsing Not configured
Prune printers that are not automatically republished Not
configured
Allow Print Spooler to accept client connections Not
configured
Web-based printing Disabled


Any ideas?
 
G

Guest

I too have encountered the problem you described. Based on the information in
the posts between you and Alan, I narrowed the issue to a missing
NullSessionPipe, SPOOLSS. Security best practices suggest removal of all null
session pipes and shares on client machines. I am not certain if we can have
our cake and eat it too, but adding SPOOLSS to the NullSessionPipe value in
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters
on the client machine cleared the problem immediately.

--
Sean Woodward



Steve M said:
Are you aware of any workaround to this besides giving them admin rights or
letting users access desktops over the network? These 2 workarounds are
against security standards. It's like I just want to give the locally
logged in user access to his own PC over the network. I tried 'creator
owner' and 'interactive' but that didn't work.


Alan Morris(MSFT) said:
Actually it is the spooler service on the print server that must access the
spooler service on the client. When the user is logged on, network access
is blocked inbound to the machine.

Thanks for letting us know the solution, it will help someone in the future.

--
Alan Morris
Windows Printing Team
Search the Microsoft Knowledge Base here:
http://support.microsoft.com/default.aspx?scid=fh;[ln];kbhowto

This posting is provided "AS IS" with no warranties, and confers no rights.

Steve M said:
I think I found it. The desktop group policy has "Access this computer
from
the network" set to only Administrators. When I added Users it worked.
So
the User needs to be able to access his own PC over the network. Who
would
think.

Thanks for your help!


not sure but it's a permissions issue. I'm just a spooler guy.

--
Alan Morris
Windows Printing Team
Search the Microsoft Knowledge Base here:
http://support.microsoft.com/default.aspx?scid=fh;[ln];kbhowto

This posting is provided "AS IS" with no warranties, and confers no
rights.

So then why does the problem clear up if I give the user local
administrator
rights?


this is an issue when the print spooler on the print server is
getting
access denied contacting the spooler service on the client machines.

When the client opens the queue remotely the server connects to the
client
and displays the jobs in the queue. Since the server is blocked by
the
client, it post an access denied.

--
Alan Morris
Windows Printing Team
Search the Microsoft Knowledge Base here:
http://support.microsoft.com/default.aspx?scid=fh;[ln];kbhowto

This posting is provided "AS IS" with no warranties, and confers no
rights.

I am having a problem where all non-administrators get an error
message
"Access denied, unable to connect" when they open up their network
printer
queue window. The clients are windows 2000 Pro machines and the
print
servers are windows 2000 domain controllers. They can print to the
shared
printers fine but they cannot see the print queue nor delete their
print
jobs. Domain admins can do this fine. The printers are installed
on
Windows 2000 domain controllers with SP4. This is not a problem for
the
users if they install a printer on a windows 2000 member server.
The
users
have a group policy that restricts security. Taking the PC's out of
the
group policy lockdown does fix the problem. So I am thinking there
is
something in the group policy on the desktops that is causing the
problem
but I haven't found out what setting is doing it. If a domain admin
logs
into the locked-down PC they do not get the error. Here are the
printer
configuration of the lockdown policy:

Policy Setting
Allow printers to be published Disabled
Allow pruning of published printers Enabled
Automatically publish new printers in Active Directory
Disabled
Check published state Enabled
Computer location Disabled
Custom support URL in the Printers folder's left pane
Disabled
Directory pruning interval Not configured
Directory pruning priority Not configured
Directory pruning retry Not configured
Disallow installation of printers using kernel-mode drivers
Not
configured
Log directory pruning retry events Not configured
Pre-populate printer search location text Not configured
Printer browsing Not configured
Prune printers that are not automatically republished Not
configured
Allow Print Spooler to accept client connections Not
configured
Web-based printing Disabled


Any ideas?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top