PSExec vs Task Scheduler

  • Thread starter Thread starter Steve
  • Start date Start date
S

Steve

Can someone explain/clarify any differences between launching processes on
a remote machine using psexec with/without specific user credentials?

The machine I use to perform the remote actions is logged in as the same
admin id that is on every other machine in the network. This machine is XP
SP2. Remote machines are NT4 SP6.

If I stage the installation file to the remote machine (a Wise created .exe
file of a wrapped .MSI installation) using robocopy then launch the file
using psexec -d \\remote "filename.exe" on the remote machine the
installation fails every time.

If I launch the same file using psexec -d \\remote -u UserID -p Password
"filename.exe" it works every time.

I tried it without the Wise wrapped file using a .bat file with the MSI
installation commands and also used logging (the /lv! option) but it shows
only that Windows installer failed to start (error 1631) and to contact
your product support.

Previously, I'd found in another .MSI install from another vendor that the
"tmp" and "temp" environment variables weren't set/recognized by the
installation when I used psexec to start the installation but if I used a
"set tmp=c:\temp" and "set temp=c:\temp" up front in a .bat file, the .msi
installed properly.

What's the difference between using and not using the -u -p options since
I'm already logged into my local machine using the same admin account as on
the other remote machine?
 
Can someone explain/clarify any differences between launching processes on
a remote machine using psexec with/without specific user credentials?
Click to expand...

So, are you logged on as LocalAdmin on computerA, connecting to
ComputerB, or is this a domain account?
The machine I use to perform the remote actions is logged in as the same
admin id that is on every other machine in the network. This machine is XP
SP2. Remote machines are NT4 SP6.
Click to expand...

Clay Calvert
(e-mail address removed)
Replace "W" with "L"
 
So, are you logged on as LocalAdmin on computerA, connecting to
ComputerB, or is this a domain account?


Clay Calvert
(e-mail address removed)
Replace "W" with "L"
Click to expand...

No domain account involved. I'm logged into A as local admin and launch
the install on B using:

psexec -d \\remote path\command

The install fails every time.

If I use:

psexec -d \\remote -u UseName -p Password path\command

it works every time.

I also found that if I use:

psexec -d -s \\remote path\command

it works every time.

Just not sure what difference it makes passing the user/password to the
remote when I'm logged into the local machine as the same admin that's on
the remote.
 
||
|> On Mon, 13 Dec 2004 18:00:00 -0800, Steve <s_limke@[email protected]>
|> wrote:
|>
|>>Can someone explain/clarify any differences between launching
|>>processes on a remote machine using psexec with/without specific user
|>>credentials?
|>
|> So, are you logged on as LocalAdmin on computerA, connecting to
|> ComputerB, or is this a domain account?
|>
|>>The machine I use to perform the remote actions is logged in as the
|>>same admin id that is on every other machine in the network. This
|>>machine is XP SP2. Remote machines are NT4 SP6.
|>
|> Clay Calvert
|> (e-mail address removed)
|> Replace "W" with "L"
|>
|
|No domain account involved. I'm logged into A as local admin and launch
|the install on B using:
|
|psexec -d \\remote path\command
|
|The install fails every time.
|
|If I use:
|
|psexec -d \\remote -u UseName -p Password path\command
|
|it works every time.
|
|I also found that if I use:
|
|psexec -d -s \\remote path\command
|
|it works every time.
|
|Just not sure what difference it makes passing the user/password to the
|remote when I'm logged into the local machine as the same admin that's on
|the remote.
|
But you are NOT logged on as the same user if it is a local user. Each user
has an SID that includes a portion that is unique to each computer. It is the
SID that "defines" the user - the name is just used to look up the SID. So,
if someone creates a user on their machine that has the same name as a user on
your machine, this does not give them any rights to your machine.

Domain accounts use the SID of the domain, not the local client computers.

If you send the username and password, it does the lookup on the remote
machine, and finds the SID of the user there, so you are using the credentials
of that user on the remote machine. If you do not specify these, it uses your
SID on the local machine that you are logged on to, and this does not match
the one on the remote machine, so you get no permissions.

When you use -s, it does a new login on the remote computer, since it is
switching to a new account (SYSTEM) - apparently this results in it sending
your current name/password, and doing a lookup for the SID on the remote.

Note that you can prefix the domain to the username as DOMAIN\USERNAME, so
that you are sure which user you are specifying (DOMAIN can be a "domain"
account, or it can be the name of the remote computer that you are connecting
to - each local computer is a domain unto itself).

I am not sure, but it could be that if your passwords are the same on both

machines, just specifying the username could be enough.
 
Back
Top