Over the past couple of weeks I have been scouring the internet to figure out a problem I have been having of simply getting "calculator" to open on a remote computer using psExec. Eventually I asked a question on here too. I still don't have an answer to that question, but getting help with that question turned into a lot of back-and-forth answers and comments on different ways to troubleshoot psExec. I'm grateful for the help I received, so I was looking over the list of troubleshooting ideas I got and thought - wouldn't it be nice if I could just search "troubleshoot psExec" and get this list all in one place, rather than digging for little helpful nuggets on tons of different websites?

So, with that in mind, and in the spirit of the Answering Your Own Questions post, I'm going to list all of the troubleshooting methods I've found out about, then I'll ask my question. I can't add many links yet because I'm new to this site, so I apologize for the minimal inclusion of credit and links to sources.

  • In the \\targetmachine part of the command, try using either the computer name or the ip address. Sometimes one doesn't work when the other will.
  • Use the -i switch to make the program interactive on the remote machine.
  • Use the -d switch so cmd doesn't hang while the program you are executing is still running.
  • Attempt to run simple programs other than the program you're trying to run (ex. calc, cmd, or make a simple .bat file to test), to check if your syntax is wrong.
  • Target a different computer with a similar command to see if the command works.
  • If you've tried the -d switch already, run your program and let it hang for a while to see if the system is running slowly. Sometimes some programs will take a bit of time.
  • Run other psTools like psList or psService to check if you have access to the remote machine
  • Another way to check if the target computer is accessible to the local machine is to open a windows explorer window and type in the address bar: \\targetcomputername\c$. This should give you access to the folders in the target's C: drive.
  • Run cmd as an administrator
  • Use the username and password switches (-u and -p). Try with your regular account then try with your admin account (if you have one).
  • accepteula can be written both as -accepteula and /accepteula - apparently one way works with some systems, one way works with others.
  • Insert -accepteula twice in your command, because the first one just gets 'swallowed' sometimes and doesn't get executed (from this post).
  • Go to the target machine via remote connection or physically working on it, and run psExec in a command prompt so you can manually accept the License Agreement that pops up. (accepteula is supposed to do this, but apparently it doesn't work sometimes)
  • Manually run psExec on the target computer to see if your machine is the problem.
  • Check that the admin$ share is turned on, on the target computer
  • Follow whatever directions are appropriate for your version of Windows from karlchen's post in the Sysinternals forums here, then run the 3 lines of code suggested.
  • Check that the target's firewall or antivirus allows psExec.
  • If you are able, turn off the firewall and try the command again.
  • Try the command with another target that has the same antivirus and firewall setup to see if firewall/antivirus are the problem.
  • Try setting UAC (User Account Controls) to "never notify"/off on the target computer.
  • Try caching your credentials if you need different credentials from your own (from this post)

The psExec download page and the Sysinternals psExec FAQ and forums are great resources.

None of these troubleshooting ideas I have written here solved my problem, so that means there are more ideas out there. How else could someone troubleshoot psExec for simple problems like mine (just opening a simple program like calculator)?

  • Please explain why you need to use psexec. Can't you just schedule a scheduled task to run, a login script, take control of the remote computer, etc... as for me your question look more of a blog post than an actual question. Edited: +1 for the info your post give btw – yagmoth555 Mar 8 '16 at 18:38
  • I'm trying to open a command prompt on the target computer so I can run a specific command on a program running on it. It's part of an automation of a tedious multi-server reboot procedure. Every other part of it works, except I can't connect to this one server with psexec. The other question I referred to is here. It has the details of my specific problem. Thanks for the +1. I know it looks like a blog post... I didn't know how else to write it. – Alamb Mar 8 '16 at 18:42
  • Your question is amazing I don't understand the blog post criticism at all. I realize you've tried cmd, etc. so this probably isn't helpful but does calc even show up on the target computer when working properly?? "interact with the desktop" isn't enough for it to actually open on their screen, has to be a child process of explorer.exe, not a service, as I found out here: goo.gl/eqkFPd calc "hanging" from your psexec command line and not visible on target computer actually sounds... possibly correct? But cmd should work. :( Hmm. Maybe I can peek in my group policy objects. – Christopher Galpin Mar 10 '16 at 2:16
  • Thanks, @Christopher. that "child process of explorer.exe" sounds like something I should look into. Something I did try with a different target server though, was the command psexec -i -d \\target calc. It opens calc on that target. It's a weird result in that the whole calculator doesn't show up (only the title bar of the window shows up, and a button on the taskbar), but at least I know it's connecting. – Alamb Mar 10 '16 at 15:15

A) \{targetmachine}. In 2015, we changed all our *.bat batch files to use IPAddress for {targetmachine} instead of using ComputerName, and this got rid of the "hanging" when invoking PsExec. In 2018, with all the new virus security in place, we have figured out that using the IPAddress is NOW causing PsExec to hang for as long as 3 minutes. So we have switched the batch files back to using ComputerName.

B) -p {password}. There are 6 of us that regularly use the batch files that use PsExec, and our batch files are customized to use our UserName and PassWord. After our last mandatory 3-month password update, we realized that the users with NO special characters in their password (e.g. @ ! ^ $) were no longer experiencing ANY hang time, whereas those with special characters are regularly experiencing the 20-second hang. (This is difficult to troubleshoot, because users with special characters only experience the 20-second hang time if the batch files have not been invoked within the last 3 minutes. If they have been recently run, the hang-time goes away.)

C) Using @ in any *.bat batch file. Similarly, we have found the hang time to go away (regardless of how long it has been since the batch files have been run) if we removed the "@" character from any batch file that calls, or is called by PsExec. For those not familiar with *.bat file programming, the @ character suppresses "echoing" to the screen, even if echo is set to "on" within the batch file.

D) In Summary: 2015 CODE

@echo off
@psexec \\ -u DomainName\UserName -p MyP@$$W*rd  cmd.exe /k c:\local_PsExec_commands.bat "%cd%" %1 %2

2018 CODE

echo off
psexec \\TargetComputer -u DomainName\UserName -p MyPassWord  cmd.exe /k c:\local_PsExec_commands.bat "%cd%" %1 %2

We also removed the "@" character from all the "local_PsExec_commands.bat" files on the target computers.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.