I am using PSTools to remotely running the application in Windows machine using the command
PsExec.exe \Machine-i 1 -u Username -p Password -d /accepteula
C:\Test\PsexecConsole.exe
My question is what is the 1 means in the command?
As stated in the documentation of the PsExec.exe application the -i switch is used to identify the session on the remote system:
-i Run the program so that it interacts with the desktop of the specified session on the remote system. If no session is specified the process runs in the console session.
Related
I am having a virtual machine which i am using it as a server. I have my local machine as a client.
I have a windows batch file in the virtual machine, a.k.a the server which has a series of command.
I try to run the batch file from the client through psexec. I can access the file and execute the file. But not all the commands are executed. They need administrative privileges.
The command that i use is
psexec \virtualmachinename -s -u domainname\username -p PASSWORD c:\foldername\batchfile.bat
NOTE 1: I cannot select the option of "Run as Administrator" in the properties of the batch file. The check box is grayed, that means i cannot select/deselect anything.
NOTE 2: I have given the user of my virtual machine full administrative privileges.
Any insight or possible solutions will be of great help.
If the account you are logging into with is an Administrator then your code should be working.
However the first thing I would try would be to add runas /user:administrator ie:
psexec \\virtualmachinename -u domainname\username -p PASSWORD cmd && runas /user:administrator && c:\foldername\batchfile.bat
I have a problem, and the Internet doesn't seem to have a solution, so maybe someone here can help.
I'm trying to start a command-line prompt on a remote machine using PsExec, but I keep getting an "Access is Denied" error. Both my local and the remote machine are running Windows 7 Enterprise (local: x64, remote x86) and I'm using PsExec 1.98. I use the following command:
psexec \\remote -u domain\user -p password -i -d cmd.exe
I have also tried other commands (such as using -s, -h, etc.), it doesn't seem to make a difference. I have access to the admin$ share of the remote machine from my local one. The Event Viewer tells me that a logon (and logoff) occurs on the remote machine.
Also, PsExec creates the PSEXESVC.EXE in the windows directory, but does not delete it!
Interestingly, the same command works just fine on a Win-7-Professional (x64) and it also works perfectly fine in reverse (i.e. when executed from the remote machine to start cmd on the local one). Deactivating anti-virus and firewall on the remote machine did not make a difference. I cannot deactivate it on the local one, but I have my doubts that the error is caused there.
Does anyone have any ideas?
Bit late, I know, but I've just been trying to solve this too. Turns out it has to do with security levels / user access levels.
I was trying to run psexec from a command prompt on a local PC and had started the command prompt by right clicking and choosing "Run as administrator". Then I'd run the psexec command targetting a remote server and specify a domain admin account for the -u parameter.
However, my local account only had administrative privileges on the local machine, not the remote one and choosing "run as administrator" doesn't actually mean "run as domain administrator"! (Obviously, duh!).
So, in effect, what was happening was that it was trying to run my main command as a domain admin on the remote but the psexec part was being run as my (non-admin) domain user account - which didn't have the appropriate permissions on the server.
Solution: Instead of starting a command prompt as above use the runas command.
eg: Start -> Run -> runas /user:domain\administrator cmd
then run your psexec command and you won't need the -u flag
or, from inside a normal command prompt you could do this instead:
runas /user:domain\administrator "psexec \\remote cmd"
after trying everything and still not getting any good results I figured what was the issue at least in my case. I had a machine with logged in domain account(not domain admin but at least local to the machine admin) and few other machines that had local accounts with admin rights. Psexec worked on all of them but was not working on my machine using domain account with local admin rights. On the machine that psexec worked with the local admin account I logged in with my domain account with local admin rights - and to no surprise it did not work.
So bottom line is that you should start the psexec call to the remote server with admin account local to the machine that you are sending the call from.
Better yet just insert this before your psexec string which will go now in double quotes
runas /user: ""
this way psexec will run but using the local admin account and no need to actually log in with the local admin account
The only way which works for me was to set the network credentials:
cmdkey /list:%DOMAIN% | find "%DOMAIN_USER%" >NUL || cmdkey /add:%DOMAIN% /user:%DOMAIN%\%DOMAIN_USER% /pass:%DOMAIN_USER_PWD% >>%LOGFILE% 2>>&1
Runas was not possible with local shares and other permissions.
I know this is really late, however as it's the first search in Google I am going to reply.
Through much research I found that you need to have the username and password BEFORE the system name, so instead of:
psexec \\remote -u domain\user -p password -i -d cmd.exe
Do it this way:
psexec -u domain\user -p password -i -d \\remote cmd.exe
I wanted to install a program from a server share (the PC I'm working on, I was logged in as domain administrator) remotely on "RemotePC".
PsExec worked on RemotePC with "local" programs (local to "RemotePC") like cmd.exe:
PsExec.exe \\RemotePC cmd.exe
Initially, my full command looked like this:
PsExec.exe \\RemotePC "\\server\sharename\path to program\setup.exe" /s /v"/qn IP_SERVER=192.168.1.10 PORT=112 INSTALLDIR=\"%ProgramFiles(x86)%\path\ \" "
But the setup from the server share didn't start.
Error message:
PsExec could not start \\server\sharename\path to program\setup.exe on RemotePC
Access is denied
I tried much of the solutions I found here and on other websites like adding PsExec -u administrator -p password and using cmd.exe /c, but it didn't work.
Finally I found a working command (the /s with extra quotes around the commandline did the trick):
PsExec.exe \\RemotePC -u administrator -p AdminPassword cmd.exe /s /c " commandline "
The full working command looks like this:
PsExec.exe \\RemotePC -u administrator -p AdminPassword cmd.exe /s /c " "\\server\sharename\path to program\setup.exe" /s /v"/qn IP_SERVER=192.168.1.10 PORT=112 INSTALLDIR=\"%ProgramFiles(x86)%\path\ \" " "
I am trying to execute following command
psexec \\x.x.x.x -d -c -f cmd.exe /c d:\test\hello.bat
It runs fine and gives output
cmd.exe started on x.x.x.x with process ID 106084.
But when I login on x.x.x.x I can find the process ID but no visible batch file is launched. It runs in background.
Batch file
echo "Hello"
pause
Please tell me how to see the command window launched on x.x.x.x
Thanks in advance
I think you can look at the Session Id for your current user and pass it as parameter with -i For example:
PsExec.exe -s -d -i 2 c:\temp\MyServer MyConsoleApp.exe
To look at the current Session Id you can run query session
Sometimes the Session Id is 2 for the active user you want to start process for, so try looking for your correct Session Id and use it with -i parameter.
Try one of those:
psexec \\server -u xxx-p xxxx /accepteula -i 1 -d cmd.exe /K "cd d:\test && call hello.bat"
psexec \\server -u xxx -p xxxx /accepteula -i 1 -d d:\test\hello.bat
Alex K. is correct. Specifically, remove the "-d", which tells PsExec "Don't wait for process to terminate (non-interactive)". In fact, if you run the sample batch file above, which includes "pause", the cmd process will continue to run on the remote host (invisible to the remote host's GUI, since it's done via PSExec) until you kill that process.
PsExec.exe -s -i 2 C:\path_to_exe.exe
This need to check with the session ID variable (-s & -i)
I am trying run below command
psexec \\remotemachine -u username -p password notepad
As per my understanding, above command should launch notepad on remotemachine,
but it doesn't happen.
Strangely notepad.exe process gets created(I saw the tskmgr of remotemachine) every time i execute above command but notepad doesn't show up.
Am I missing anything in the command
By the way I am using 64 bit machines and both machines are on same domain
Have you tried the -i switch?:
psexec \\\remotemachine -u username -p password -i notepad
The -i switch is described as follows:
Run the program so that it interacts
with the desktop of the specified
session on the remote system. If no
session is specified the process runs
in the console session.
The console session is what you would see on the physical screen attached to the machine. If you are using a Remote Desktop session and would like it to appear there, then first you need to determine the ID of the session in which you want the UI to appear, which you can see using Task Manager on the remote system (ID column of Users tab). Then you pass the ID after the '-i' switch as follows:
psexec \\\remotemachine -u username -p password -i 1 notepad
Omitting the session ID is the equivalent of specifying a session ID of 0.
Other switches are documented here: http://technet.microsoft.com/en-us/sysinternals/bb897553
I have two XP machines and I have the following situation.
I am running psexec from comp1
comp2 does not have any password
My bat file command
psexec -i -d -c \\comp2 c:\xyz.exe
The error message I get is
Couldn't access comp2: Access Denied
I also added new user 'test' with password 'abcd' on comp2 and logged in then from comp1. I gave command
psexec -i -d -c \\comp2 -u test -p abcd c:\xyz.exe
but the error remains the same. Please help.
Are you using XP Home by chance? According to the Sysinternals Forums here, one of requirements for psexec is check the target machine to make sure it's not running Windows XP Home because it lacks the network functionality required by (most) PSTools commands. The issue with XP Home was also investigated in detail in this thread from the same forum.