How can I run a command on a remote machine

try run cmd as admistrator then type: C:\>psexec \\BTOP-1028 -u administrator -p 12345678 CMD

with cmd

Hi
Why you need the CMD? Run the command directly using the psexec command.

Are the admin shares on the remote machine enabled?

Try -u remotepc\user, or -u domain\user....

But if you cannot browse \\btop-1028\c$, passed will NOT work..... So if this is the case, enable the admin shares first....

I was already at an administrator command prompt

Oh, and of the. Account on your local machine where you are running psexec FROM has admin rights on the remote one, you don't need the explicit user\password credentials unless you are trying to run a file from the network on that target PC....

Admin$ share and C$ share are already enabled on the remote machines. Also, I am not using active directory, just workgroup peer to peer enviroment. To answer mgonullu's question, I just chose cmd for testing purposes. I fully intend to run other programs and scriipts using psexec.

johnb6767, the machine I am running on is Windows 7 64bit and I am logged on as an administrator

Up to my knowledge CMD doesn't work with psexec.

can you try something like ipconfig instead of cmd.exe

tried it. same result. Interestingly enough I cannot browse to \\btop-1028\c$

Could that be the problem, and how do I resolve this?

C:\>psexec \\BTOP-1028 -u administrator -p 12345678 ipconfig /all

PsExec v1.98 - Execute processes remotely
Copyright (C) 2001-2010 Mark Russinovich
Sysinternals - www.sysinternals.com

Could not start PsExec service on BTOP-1028:
Access is denied.

C:\>

ok I know it is odd, but try to change the password of your local machine and make it same a the remote one, also login using the same admin user name there and see what happens.

I am logged into both machines as administrator. both passwords are identical

ok then try without the -u and -p and see the result

same result

Are the $ shares my problem??

even tried this:


C:\Users\Administrator>psexec \\BTOP-1028 -u administrator -p 12345678 "c:\windo
ws\system32\CALC.EXE"

PsExec v1.98 - Execute processes remotely
Copyright (C) 2001-2010 Mark Russinovich
Sysinternals - www.sysinternals.com

Couldn't access BTOP-1028:
Access is denied.

FYI, cmd works fine with psexec ....

Have you tried " -u remotepc\administrator"

And you are logged on to bot machines as the built in "Administrator" account?

Meaning you went to a cmd line and enabled them?

On both machines...

Net user administrator

Should return both statuses as "active"

Otherwise, test with another admin level user on the boxes, at least for testing....

Can you also share files back and forth between the machines ok via Explorer?

"Are the $ shares my problem"

Not if you can browse them via explorer.... Remote chance your local security policy option "deny access to this PC from the network" includes "administrator", but that's rules out if other file sharing works....

i use remote command prompt in a tool called dameware nt untilities. works for me every time

Hi guys, I am going home right now, but I will start back the conversation in about half an hour

http://www.dameware.com/support/kb/article.aspx?ID=300002

try manage engine desktop tools. its free.

manage engine desktop tools are not free. The trials eventually run out. My previous employer had a horrible experience with them

u will have both free and trial editions.

that manage engine realy sucks !!!!

What's OS the remote machine running?
I assume it also running win 7 or 2008 server.

C:\>psexec \\BTOP-1028 -u administrator -p 12345678 ipconfig /all

PsExec v1.98 - Execute processes remotely
Copyright (C) 2001-2010 Mark Russinovich
Sysinternals - www.sysinternals.com

Could not start PsExec service on BTOP-1028:
Access is denied.

C:\>

Select allOpen in new window

Check the error message carefully, it said "Could not start PsExec service", as we know, in Win 7(with UAC) we can't using a command to start service(like "net start spooler"), we need root rights to start service.

In summary.

Both machines are Windows 7 64bit
Both machine are logged on with the default local admin accounts:
      Net user adminstrator /active:yes
Both have Admin$ and C$ shares, but I cant browse those admin shares.
I have creae other shares with absolutely no problems.
I have tried  -u remotepc\administrator"
anybody have any other ideas before I try dameware, because I agree with coolfiger, manage engine sucks.

I need to make sure: You are not able to browse admin$ remotely? Are you able to do that from BTOP-1028? Did you try to remove and readd admin$ yet?

BTW, DameWare is cool, but the remote command does not allow to automate, as psexec does. And DW needs the admin$ share to remote-install the necessary services, though you can also install them manually on the remote machine itself.

Did you try wit the ip instead of the computername?

I think that you have run into a roadblock that requires the famous LocalAccountTokenFilterPolicy registry fix:

“Access Denied” Error Messages When Accessing Administrative Shares in Windows 7

Run5k, I already tried that

Just woke up guys, heres another Summary:

             




Run5k,

Your link to: http://www.petri.co.il/windows-7-access-denied.htm, was a great little gem , and I thought it would work, but I am still prompted for credentials trying to access the TM's $ shares. Any other thoughts???

Try this...


 

cpau.exe -u administrator -p password -ex "psexec.exe \\COMPUTERNAME -u administrator -p password -i 0 -d %windir%\calc.exe > NUL" -profile -c -hide

Select allOpen in new window

You can download cpau at http://www.joeware.net/freetools/tools/cpau/

http://forum.sysinternals.com/psexec-access-denied-when-using-explicit-logon_topic17497.html

This is the error I get when trying to access the Target Machine's (TM's) c$ share    
New-Picture--1-.bmp

turnturn73 ,

I tried:

C:\Users\Administrator>cpau.exe -u administrator -p 12345678 -ex "psexec.exe \\wks-wnxp-01905 -u administrator -p 12345678 -i 0 -d %windir%\calc.exe > NUL" -profile -c -hide

and it completed succesfully, yet calc.exe didnt run on the Target Machine

Getting desparate...... any other input???

How are you checking to see that it ran?  It won't popup on the desktop like a typical application, it will be in task manager as a process.  Perhaps you could provide a better explanation of what your trying to accomplish?

tumtum73,

I am simply trying to run some hypothetical scripts on remote machines. BTW I tried running a vbscript from your example, a simple mapped drive, but the script didnt map a drive on the target machines.

C:\Users\Administrator>cpau.exe -u administrator -p 12345678 -ex "psexec.exe \\wks-wnxp-01905 -u administrator -p 12345678 -i 0 -d \\REAPERSGALE\scripts\MappingADrive.vbs > NUL" -profile -c
-hide

CPAU V01.11.00cpp Joe Richards (joe@joeware.net) November 2005

Current Security Context: REAPERSGALE\Administrator
Process Created...

The command completed successfully.

Frustrating...

-i will popup on the desktop with all the programs I've done this with in the past. Never tried calc but pretty sure it will popup too.

I'm not sure you understand how this works.  I believe that the vbscript worked and mapped the drive for the administrator account that ran the command then logged off and the mapped drive is lost when the script is finished.  It will not map a drive that would be available permanently for everyone who logs into that remote pc.  

For that mapped drive to happen regularly you would need to copy that vbscript to the remote PC and edit the registry to ensure it ran upon logon.

I believe the solution I provided resolved your original question which was "How I can run a command on a remote machine?".

To prove this, instead of running the vbscript or calc.exe, run "reg /add HKLM\Software\Test" and on the remote pc if you see this registry key, you know it worked. This key is benign and can be safely deleted after you prove this.

Http:#36404834

On boTh machines, let's clear out all stored credentials....

Net use * /del

Then retry....

I agree to tumtum73. For testing you should perform something persistent, like    cmd /c copy nul c:\temp\tst.flag, which will generate a file you can delete (I would prefer that over fiddling with the registry).

tumtum73,

Yes you are correct in your assessment that I dont know how this works, ergo the reason I come to you guys for help? I will try your suggestion and get back to you guys

Tried your suggestion tumtum73


C:\Users\Administrator>cpau.exe -u administrator -p 12345678 -ex "psexec.exe \\wks-wnxp-01905 -u administrator -p 12345678 -i 0 -d reg /add HKLM\Software\test > NUL" -profile -c -hide

CPAU V01.11.00cpp Joe Richards (joe@joeware.net) November 2005

Current Security Context: REAPERSGALE\Administrator
Process Created...

The command completed successfully.
***************************************************************************

But no registry key exist on the remote machine. Look at my command above and see if Ii've missed anything

Try without -i

no effect

What if we resimplify and remove the cpau stuff.

thats what I am going to do , because it has made a difficult problem worse

Let's simply concentrate on psexec: heres a very very simple script I want to run on the remote machine:


C:\Users\Administrator>psexec  \\wks-wnxp-01905 -u administrator -p 12345678 C:\scripts\HelloWorld.vbs

PsExec v1.98 - Execute processes remotely
Copyright (C) 2001-2010 Mark Russinovich
Sysinternals - www.sysinternals.com

Couldn't access wks-wnxp-01905:
Access is denied.


Again I get access denied. After reviewing all previous comments, what can I do to make this work?!

Starting from the beginning, I would perform

net use * /del
net use \\wks-wnxp-01905 /u:wks-wnxp-01905\administrator 12345678
dir  \\wks-wnxp-01905\admin$

Select allOpen in new window

again and in exactly that sequence. That will show if you still have issues with the admin share and the admin account.

A little thought has occurred to me, doesn't psexec need the remote registry service running?

where is it and how do I enable it to make my life great again

It should be called exactly like that ("Remote Registry"), and is a service running on the target machine - so you will find it in the Service Applet.

Remote Registry is running on both machines now and this is the result:

C:\Users\Administrator>psexec  \\wks-wnxp-01905 -u administrator -p 12345678 C:\scripts\HelloWorld.vbs

PsExec v1.98 - Execute processes remotely
Copyright (C) 2001-2010 Mark Russinovich
Sysinternals - www.sysinternals.com

Couldn't access wks-wnxp-01905:
Access is denied.

C:\Users\Administrator>

other inputs??

I believe this is a UAC problem that cpau is used to work around by changing the security context...  that is the proper solution.  There was an error in the reg command I posted.  there is no /add option it's just add.  Try this =- the add has no slash:


C:\Users\Administrator>cpau.exe -u administrator -p 12345678 -ex "psexec.exe \\wks-wnxp-01905 -u administrator -p 12345678 -i 0 -d reg add HKLM\Software\test > NUL" -profile -c -hide

Regishyde,

To ensure that we are being thorough, in addition to the LocalAccountTokenFilterPolicy registry update did you also double-check the steps on Daniel Petri's troubleshooting checklist found within that same article?

If you did and the problem still persists, for testing purposes it might be wise to try a method that worked in another workgroup-related problem we discussed last month:

How do I install an msi from my EMCO Remote INstaller

Enable the built-in master administrator account on each machine, ensure that they both have the same userid/password combination, and then try your PSExec commands.

Good morning Run5k,

In that previous workgroup related issue, I was trying to install software via EMCO Remote installer. The aha moment for me their was the security policy to enable audited objects, but I have this setting enabled on both the source and target machines. Also, the machines have the built in master admin accounts enables with same passwords. I am going to try the PsExec commands again , just in case I missed some component that is necessary for remote installs to happen.

Sounds like a good plan.  As I mentioned before, Daniel Petri's troubleshooting checklist provides an ideal baseline to work with.  I thought that the recommendation to "specify the remote machine's name as the domain" might be particularly helpful:

• Both computers are members of a workgroup.
• The workgroup's name is "Workgroup".
• From one of the computers, you try to access an administrative share that is located on the other computer.
• When you are prompted for your user credentials, you provide the user credentials of an administrative user account on the destination computer.
• This also happens when you have the same exact user name and password combinations on both machines. For example, you use DPETRI as the user name on both machines, and the password is identical. Note that this is not a must, but then you will need to enter the correct user name and password as the connection credentials. When using the NET USE command, you must also provide the correct user name and password.
• Although you can specify a remote domain name, since both machines are not members of any domain, you need to specify the remote machine's name as the domain. For example, if the machine's name is ZEUS and the username is DPETRI, you enter ZEUS\DPETRI as the credentials.
• We assume that there are no connectivity issues between the computers (can you PING by computer name? Can you PING by IP address?)
• We assume that the Windows Firewall is either disabled on both machines, or that an appropriate rule is used to open the relevant ports.
• We assume that both computers' network settings are set to "Work" or "Home", and not "Public".

Everything you mentioned above has been tried except prefacing the computer name as the domain name. I will give it a try and let you know.

interesting...

when I ping the remote machine , I get the following:



C:\Users\Administrator>ping wks-wnxp-01905

Pinging WKS-WNXP-01905 [fe80::607f:96b9:1c2b:cf0%11] with 32 bytes of data:
Reply from fe80::607f:96b9:1c2b:cf0%11: time<1ms
Reply from fe80::607f:96b9:1c2b:cf0%11: time<1ms
Reply from fe80::607f:96b9:1c2b:cf0%11: time<1ms
Reply from fe80::607f:96b9:1c2b:cf0%11: time<1ms

Ping statistics for fe80::607f:96b9:1c2b:cf0%11:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms


I was expecting an IP address

Also interesting...

I went to the remote machine and retrieved the ipaddress in the status windows of the Network Connections and I performed this command:


C:\Users\Administrator>psexec \\192.168.1.133 -s system -u administrator -p 12345678 "c:\windows\system32\calc.exe"

PsExec v1.98 - Execute processes remotely
Copyright (C) 2001-2010 Mark Russinovich
Sysinternals - www.sysinternals.com


Error establishing communication with PsExec service on 192.168.1.133:
All pipe instances are busy.

You did get an IP address, but it is an IPv6 address instead of IPv4.

tumtum73,

Okaaaaaay, I tried the example above and it created the test underneath the Software hive. Interesting....

I think you have something here. However, I am going to bed now, but will continue in the morning. I have a good feeling about this. Thx.

oh my goodness. it worked for calc.exe and notepad.exe . I was wondering though if they could just run instead of getting this message:

Ive done this with uac off, no cpau, to trigger an svn update client, and I didn't get that message, I think it's cpau/uac related.

Yes, I have been thinking that it is UAC-related, also. That's why I asked about the built-in master admin account... it automatically bypasses UAC.

This screen will appear on Vista, W2008 and W7 whenever a service tries to access the display. All windows are redirected to a "Service Desktop", separated from your own one. If you confirm the prompt, another desktop is displayed, showing all service windows (if any).
If UxSms ("Session Manager for Desktop Windows" or similar, don't have an US system at hand atm) does not run, you do not get any notification - windows just do not appear.

Yea, great comments guys, but I cant determine what you want me to do to get rid of the message. Run5k, I have both of the built in master admin accounts enabled. As you can see from my previous examples, I am using those credentials. What are my steps to just have notepad, calc or a script to simply run???????

Haven't got no clue not, sorry. In my domain env I do just not have that effect with PsExec. Windows pop up fine, as long as I provide valid credentials.

The original question was "How I can run a command on a remote machine?" and in my opinion that has been answered.  

If you have a more detailed question, I think you need to submit a new specific question with that level of detail in it.

Mine too. Maybe because I have uac off. Win 7 32 an 64 tested.

On our largest domain at work, we will occasionally run a PsShutdown script to reboot a large number of machines and if a person is already logged into the domain, they will see a similar message window appear.  In other words, that message window isn't strictly a symptom of being in a workgroup environment.

Two things come to mind.  First of all, you mentioned that you were going to try to "specify the remote machine's name as the domain," but I don't remember you mentioning if you actually did or not.  I would be curious if that has any impact.

Last but not least, determining you ultimate goal for using PsExec may end up solving this last little problem for you.  I would imagine it's safe to assume that you won't actually be trying to make Notepad or Calculator appear on an end user's screen.  Most of the time, administrators use PsExec to install applications or their associated updates and when they do there is typically a switch like /qn they utilize that allow for a silent install, preventing any type of message or window from appearing.  Food for thought.

Regishyde, you can do us a small favor.

In order to maintain the accuracy of the Experts Exchance solutions database/archive, it would be ideal if you marked the Tumtum73's specific post(s) that provided you with the technical input for the Accepted Solution, rather than just a comment stating that it has been answered.  This question is really a classic example of the importance of doing that!  If another EE community member encounters a similar problem and reads this PAQ, they would need to sort through over 70 comments to find the real solutions that Tumtum73 is referring to.

If you click on the Request Attention link on the upper-right section of the thread, you can ask the moderators to re-open the question so that you can give the proper credit to Tumtum73's real answer.  Thanks for your help!

Based upon what I have seen, if Tumtum73's answer was ultimately the solution then I would think that his comment containing the final format for the CPAU command (http:#36407596) would be the best choice.

That being said,your follow-up question revealed that you didn't properly configure the registry update in order to successfully access administrative "$" shares within a workgroup:

https://www.experts-exchange.com/questions/27269965/How-do-I-access-the-shares-of-Windows-7-64-bit-machines.html

As a result, if the registry update had been successfully implemented from the very beginning based upon my original comment (http:#36404534) I would be very curious as to whether or not you would still need to use the CPAU application.

Actually in the true sense of the original question, Tumtum73's cpau solution answered my general question only in general. It just reminds me that I must make my future request very specific , because I wanted a solution using psexec, but was given one that encapsulated cpau around psexec. Not exactly what I wanted, but in the spirit of the question, he gets the points. To your point Run5k, since you are active in my next question, you will have read that I did indeed configure the registry after you noted it to me. I was only half way successful in that request. I am going back to the other question to see what responses I have received. Also, you are right , I need to give the points to the specific solution. I will do that now.

Thanks for the help

Regis, after such a lengthy discussion I am certainly glad that you were able to find a viable solution.  That's what really counts!

For those of you who may reference this thread in the future, my original comment (http:#36404534) that requires a one-line registry update on each computer will work without the need to enclose the PSexec command within the CPAU utility.  I tested this on my workgroup and was able to successfully implement the native PSexec command that Tumtum73 suggested without the CPAU syntax:

psexec.exe \\computername -i 0 -d reg add HKLM\Software\test > NUL