PsExec to localhost: Logon failure

Good evening, David.

I have two machines, Machine A and Machine B. Both are running Windows XP Pro SP2, and are members of the same Windows domain. [...] On Machine A, I've verified that:[...]

Wow, you have definitely done your homework and gone through the PRBP and the FAQs.
No chance for the "Documentation Police" to arrest you.

=====

OK, a general note before addressing each of the issues you are experiencing:

Both are running Windows XP Pro SP2, and are members of the same Windows domain. [...] The user used for all commands below is a domain user with a non-empty password and local admin rights on both Machine A and Machine B.

Very precise. Yet one unaswered question, though:
Does this mean the admin user has got the same password on both machines?
Inside an ADS domain, a domain admin user exists just once (on the ADS Domain Controller), but can logon to any ADS client machine, same loginname/same password.
But your admin user might as well be a local admin user on MachineA and on MachineB, having the same username and the same privileges, but having different passwords on each machine.
I am asking because you get

unknown user name or bad password.

error messages which suggest that as the user exists on both machines the password might be different.

=====

Anyway, let us tackle the issues one by one, top down:

===== psexec as a prefix =====

Running command on Machine A with PsExec w/o specifying machine: D:\>psexec D:\glancepd\pdw.exe [...] PsExec could not start D:\glancepd\pdw.exe: Logon failure: unknown user name or bad password.

In order to understand why this psexec command line does not work, please read PsExec could not start (local machine w2k.
In this thread I try to list what psexec can do and what it cannot.

Essence for your particular command:

Sorry, no offense meant, but it does not make too much sense, because even if it worked it would have the same effect as simply launching

D:\glancepd\pdw.exe

So simply prefixing "psexec " to this command is meaningless. Does not work for me either.


===== psexec \\bulldog =====

Running command on Machine A with PsExec specifying machine name: D:\>psexec \\bulldog D:\glancepd\pdw.exe [...] PsExec could not start D:\glancepd\pdw.exe: Logon failure: unknown user name or bad password.

This definitely indicates an authentication issue on the target machine \\bulldog (Having read your complete post, it is clear that there is more than just 1 MachineB, I counted 3).

As you use psexec without the -u username -p password arguments, psexec will try an implicit login to \\bulldog using your local username and password on MachineA. Obviously this fails.

In order to get more information about the differences between implicit and explicit network authentication, please read psexec - remote share problem.


===== psexec \\10.10.10.200 =====

Running command on Machine A with PsExec specifying IP address: D:\>psexec \\10.10.10.200 D:\glancepd\pdw.exe [...] Could not start PsExec service on 10.10.10.200: The system cannot find the path specified.

As you get a different error message, this seems to suggest that \\bulldog and \\10.10.10.200 are not the same machine. So there seems to be more than just 1 MachineB?!
The error message seems to indicate that psexec could not locate/access Admin$ on 10.10.10.200, because psexec stated it could not launch the service.
Again the reason might be omitting the -u username -p password arguments.


===== psexec as runas replacement =====

Running command on Machine A with PsExec specifying username (command executes, but output not captured): D:\>psexec -u NEXUS\dcarr D:\glancepd\pdw.exe [...] Password: D:\glancepd\pdw.exe exited with error code 0.

I am not sure why you cannot see any output, because your next example (see below) seems to indicate that there is no general problem which prevents psexec.exe and pdw.exe from co-operating.

You might try to add the -i switch to your psexec command line, try again and let us know if it helped in this scenario.

psexec -i -u NEXUS\dcarr D:\glancepd\pdw.exe

.
I will not bet it will though.


===== psexec \\baboon =====

Running command on Machine B with PsExec specifying machine name (works): D:\>psexec \\baboon D:\glancepd\pdw.exe

So \\baboon is the only machine of all the machines which you tested where implicit network authentication works, i.e. username/password on MachineA == username/password on \\baboon.

The fact that you could see the output of pdw.exe on MachineA seems to indicate that there is no general problem when using psexec to launch pdw.exe, but only different tricky issues on different machines.

=====

Although I certainly did not give a satisfying answer to each of your differnet issues, hopefully you got at least some useful information which helps solve your problems.

Kind regards,
Karl



Edited by Karlchen - 19 April 2006 at 1:54pm

Hi, David.

Ok, I see, you were referring to 2 machines by using three different names for each machines.

This means I will have to revise the different commandlines keeping this in mind.

My final statement about simply prefixing psexec to a local commandline:

psexec D:\glancepd\pdw.exe Agreed, this isn't a particularly useful command. However, I'm pretty sure it worked on my system before upgrading from Windows 2000 Pro to Windows XP Pro SP2, and it's the simplest command that demostrates the failure.

Disagree:
This usage has never ever worked for me: neither on WinXP SP1, nor on WinXP Sp2, nor on Win2k, nor or Win2003.
In this commandline "psexec" can be simply dropped. psexec will not work in this situation.
This gives you no clue whatsoever on how psexec will behave in different situations.
So this commandline does not prove more than that psexec will not work if used in this particular way.

Please read PsExec could not start (local machine w2k.
The list on what psexec can do and what it cannot is not based on my personal beliefs, but on my experience, and on other users' reports which you might find in the PSTools forums.

Kind regards,
Karl

Hi