Trouble printing in a workgroup

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Here is an interesting problem. I set up a workgroup in my home. All
computers are running Windows XP SP2 with all the latest patches. One
machine (I’ll call it X) has two printers connected to it and is running XP
PRO.

Machine X has two accounts. Account C is an administrator. Account R is a
“limited accountâ€.

I set up machine X as described in KB article 870903 including setting
“Classic - local users authenticate as themselvesâ€.

Here’s the problem. When signed onto another machine (I’ll call it Y) as
user R, I need to print remotely to the printers on machine X. Before I
changed to “Classic - local users authenticate as themselves†printing
worked. After I changed to “Classic - local users authenticate as
themselvesâ€, I could no longer print.

When printing fails, everything appears to be normal on machine Y. There is
simply no output. On machine X, the only hint of failure is an eventlog
message: Source=Print Event=6161 with a description of

The description for Event ID ( 6161 ) in Source ( Print ) cannot be found.
The local computer may not have the necessary registry information or message
DLL files to display messages from a remote computer. You may be able to use
the /AUXSOURCE= flag to retrieve this description; see Help and Support for
details. The following information is part of the event: Untitled - Notepad,
R, Old Printer, NT EMF 1.008, 948, 0, 1, 0, \\Y, 5 (0x5), .

Sometimes the description is

The description for Event ID ( 6161 ) in Source ( Print ) cannot be found.
The local computer may not have the necessary registry information or message
DLL files to display messages from a remote computer. You may be able to use
the /AUXSOURCE= flag to retrieve this description; see Help and Support for
details. The following information is part of the event: Untitled - Notepad,
R, Old Printer, NT EMF 1.008, 948, 0, 1, 0, \\Y, 1392 (0x570), .

I tried turning on auditing and there were no failure audits.

I tried changing user R into an administrator and printing started working.
Hmmm!

I changed user R back to a “limited account†because I really don’t want
this user to be an admin. :-)

Since printing for R worked before I changed to “Classic - local users
authenticate as themselvesâ€, I now realized that printing works for either
members of the “Administrators†local group or the “Guests†local group.
However, printing doesn’t work for members of the “Users†local group. So, I
typed the following at the command line:

net localgroup guests r /add

Once I made user R a member of the “guests†local group, I could now
successfully print again.

I suspect there is some security descriptor along the print path that allows
“Guests†and “Administratorsâ€, but doesn’t allow “Users†access.

Here’s some other info:

There are two printers connected to machine X. Both behave the same way.
The first is an HP Photosmart 8250 (Driver version 8.1.0.16 from HP.com).
The second is an HP Deskjet 895Cxi running the driver that ships with Windows
XP.

The problem is the same when logged on as R from either machine Y as
described above or machine Z (another Windows XP SP2 client).

I just thought you’d want to know in case someone else sees this problem.
 
Thanks man... I asked the same question some time back, in
microsoft.public.windows.group_policy .
Now I know how to get rid of the password dialog box.

Regarding the printing problem, did you try reconnecting the printer? on the
client machine?
 
Here is the solution to your problem:

1. Type secpol.msc in start -> run in the server computer.
2. Click Security Options node on the right hand side.
3. In the server computer, enable the guest account by setting the
"Accounts: Guest Account status" to "Enabled"
4. Click the User Rights Assignment node in the right hand side.
5. Double click "Access this computer from the network"
6. Click Add User or Group
7. Type "Guest" and click ok.

Thats pretty much it.

I have tested this, and it works. Even in the domain model.

You can do it with the group policy object editor too (in the domain model)
but you have to be very careful in the domain model.

But for the workgroup model, this should work.

Thanks for the hint man. This really helped me. The fact that the computer
prompts you for a password when it doesn't know the credentials supplied to
it (mentioned at the microsoft.public.windows.group_policy news group by a
guy named Roger) also helped me. Thanks guys. :)
 
In short, you have to enable the guest account, and then allow the guest
account to access your computer through the network. Be sure NOT to make
guest account a member of Administrators group.
 
Yes, in the case where you don't set "“Classic - local users authenticate as
themselvesâ€, then you need to make sure the Guest account is enabled as you
describe.

I needed to set "“Classic - local users authenticate as themselves†for
unrelated reasons. Once I did that, my problem happened.

Cheers,
Cliff
 
When local users authenticate as themselves, you need to have user accounts
with the same credentials on the client as well as the server machine. I
have tested that too. It works when the user is logged on to a user account,
which is with the same credentials as the server machine.
 
Back
Top