How can I troubleshoot simple psExec problems?

Question

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)?

Answer 1

TL;DR : complete solution with minimal downside, follow steps 1 & 2, done. verified on local Win11 22H2 & target WinSer22 21H2.

Note : This solution assumes you are using recent Win releases, latest PSExec, & known admin accts with passwords on local & target PCs. You can specify different acct to use on target PC, than on your local PC. Also, ignore any weird errors from PSExec, it doesn't play nice with many other console apps, especially when capturing its output...yes, calc is running just fine & waiting patiently for you, it didn't close itself after opening, silly PSExec.

1. Pre-Setup - Here is all you need to allow PSExec to come in remotely. Run these on target PC, in this order:

PowerShell - Admin:

Get-NetConnectionProfile | Set-NetConnectionProfile -NetworkCategory Private

CMD - Admin:

winrm qc -force
netsh AdvFirewall firewall add rule name=PSExec dir=In action=allow protocol=TCP localport=RPC profile=domain,private program=""%WinDir%\system32\services.exe"" service=any
netsh AdvFirewall firewall set rule group="Remote Service Management" new enable=yes

You may need to reboot for all changes to take effect.

2. Work - Run these on local PC, in this order:

CMD - Admin:

start /wait "pse" cmd /c "C:\PSTools\psexec64 -accepteula -i -h \\win-4j1l0slsnda -u WIN-4J1L0SLSNDA\administrator -p @dm1N -c -f quser > act_cons.tmp"
type act_cons.tmp | findstr console > qu.tmp

PowerShell - Admin:

$quid = gc qu.tmp | % {$_.substring(1)} | % {$_ -Split " "} | Out-String -Stream | ? {$_.Trim().Length -gt 0}
$quidn = $quid[2]
(-join (echo "C:\PSTools\psexec64 -accepteula -i " $quidn " \\win-4j1l0slsnda -u WIN-4J1L0SLSNDA\administrator -p @dm1N -c -f calc")) | sc -Force pse.tmp
gc pse.tmp | cmd

---

Notes for Step 1 : private network is important since we are modifying firewall rules & server needs it enabled, I assume. all CMDs might not be needed, but you're welcome to try just the third or 2 of them; I didn't have time to test all cases.

Notes for Step 2 : powershell has trouble with certain console apps & capturing output, & sadly psexec is 1 of them, so that's why we need to use start.com in cmd (with it's own quirks) to finesse it. second CMD could instead be done in powershell, but I like findstr for its simplicity. we need to use quser to find out the session id of the console, never assume it is 1...we could use pstools to find it as well, but we want to avoid the disappearing/double accepteula issue. once we have the id, let's add the var value to our psexec cmdline, then pass that on to cmd to run, since psexec might have trouble escaping powershell vars inside its cmd args.

Note for PSExec order of args : the place & order of every arg counts, or else PSExec will usually fail with no helpful info. if you need to add other args, experiment with their order, as you can't trust the order in the builtin help output.

More info on 1st psexec cmdline quirks :

• accepteula is always first in line
• -i -h is after that & before server name, so we can use all our interactive logon & admin rights with -i & -h, or else we get psexec error:

Logon failure: the user has not been granted the requested logon type at this computer.

• -u : always after server name & we put domain in caps & acct/username in proper case
• -p : if your password has a space, change it & take it out...PSExec might not work with single or double quotes when expecting just the password
• -c -f is always at the end before our cmd, so we forcibly copy latest PSExec to target PC, whether already there, or older version, or first time copied & ran

More info on 2nd psexec cmdline, besides above :

• -i SessionID : PSExec builtin help lies, it does not auto default to the console session to interactively show apps...it only runs app hidden in the console session, so we must pass the console SessionID as found by quser, to force our apps to show on console desktop
• also - we don't use -h here since calc doesn't request admin rights at any point during its launch or usage, but if your app does, then pass -h also...however it might not actually show admin requesting apps on desktop, I didn't test that since calc doesn't need that

Answer 2

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 \\199.245.27.107 -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.