Acess denied error with psexec

You got Access Denied error message with below two scenarios.
Scenario one:
You ran the below command logged in with your Domain\UserName onto localmachineA
psexec \\remoteserverA -i c:\windows\system32\cmd /k dir \\remoteserverB\share

Scenario two:
Firstly you ran the below commdn to open a "cmd" command prompt from remote machine:
psexec \\remoteserverA CMD
After that, you ran "net view \\remoteserverB" and you got access denied.

The reason behind this is that by logging in implicitly you will loose the network resources on \\target that you would have if you had logged on explicitly.


What is "implicit login" and what is "explicit login"?

There is an important difference between using implicit versus explicit logon:

"psexec \\target some_command" uses implicit logon to \\target.
I.e. the user logged in locally will be used to logon to \\target. But logging in implicitly he will loose the network resources on \\target that he would have if he had logged on explicitly.
As -e was not specified his environment will be that of the ".default" user on \\target. Check e.g. the variable %userprofile%.

"psexec \\target -u user - p passw some_command" uses explicit logon to \\target.
psexec is told to explicitly identify as user "user" on \\target (even if he is the same user "user" logged in locally). So network resources assigned to user "user" on \\target may be available.
As -e was not specified his environment will be that of the ".default" user on \\target. Check e.g. the variable %userprofile%.

psexec \\target -u user -p passw -e some_command uses explicit logon to \\target and loads the environment of user "user".
Same as above plus:
As -e was specified the environment on \\target will be that of user "user", not the one of user ".default".

NOTE:
Starting with psexec v1.80 the default behaviour changed! The default now is to load the correct user environment. Specifying -e will keep psexec from loading the user's environment and use the .default environment instead.


To find out more details:
http://forum.sysinternals.com/forum_posts.asp?TID=5072&PN=1