If you want to pass the output of a command into another command, or you wanted to redirect the output into a file, you would normally just do something like command.exe > output.txt, and the same thing happens with PsExec. So a command like the following will save the output of netstat -an into a file on your Local computer’s root directory.
psexec \\computername netstat -an > C:\connections.txt
If you want to pass the > or | character across the PsExec connection to the remote computer, you are going to need to use the ^ character, which is a little-known escape character in the Windows command shell. That, of course, means that we will actually need to use the command shell on the remote computer, and not just run the process, so we can do the redirect or pipe in the first place. So that makes our command like this (changing the path to the home directory where we have write access).
psexec \\computername cmd /c netstat -an ^> C:\users\geek\connections.txt
This example would place the list of open connections generated by netstat into the home directory of the user on the remote computer, in a file named connections.txt.
Copying Programs to the Remote PC
You aren’t limited to just the applications on the remote PC when using PsExec, and in fact, you can run anything that you have locally. For instance, if you wanted to do an Autoruns command-line scan of the remote system, but you only had autorunsc.exe on your local computer, you can use the -c switch to copy the application over. PsExec will remove the tool from the remote system once the command is finished.
This is an important time to mention the -accepteula option of most of the SysInternals tools, which will make sure that the EULA has been accepted on the computer where the command has been run. We’ll need to add this onto the autorunsc.exe command or else it will fail on the remote computer.
psexec \\computername -c autorunsc.exe -accepteula
There are a few other options that specify whether the application is always copied, or if it should be copied if the local application is a higher version than the remote one. You can just run psexec from the prompt to see those options.
Note: If a command is only available in the command prompt, you need to add cmd /c before it. This includes pipes and redirects like | and >.
Interacting with the Logged On User on the Remote PC
You can use the -i switch to make the application launch and allow the remote user to actually interact with the application. You would probably want to combine this with the -d switch, which doesn’t wait for the remote process to end before PsExec returns control to you. For instance, this command would open a Notepad window on a remote computer:
psexec \\computername -d -i notepad
You can also choose to run as the SYSTEM user with the -s option, which can be very dangerous. For example, if you wanted to open the Registry Editor on your own computer, but with SYSTEM user-level permissions, you could run this command.
psexec -i -d -s regedit.exe
In case you are wondering, yes, this will give you access to a lot of things that you normally wouldn’t have access to edit in the registry. And yes, it’s a really bad idea.
Running a Full Command Prompt through PsExec
Yes, we just showed you all of those examples of how to run a single command through PsExec… and it turns out that you can run a full shell on your local computer that is actually running on the remote computer. It’s just like you were on the console of that server (for the most part). And luckily, the syntax for this one is really easy (add the username if you need to).
psexec \\computername cmd.exe
Once you’ve done this, you’ll have a command prompt that is now running on the remote PC.
The command prompt will work almost like normal, except tab completion isn’t going to operate at all, but that’s just fine with us.
It’s worth noting that if you want to run PowerShell commands remotely on another computer, you can do that natively with some tweaks to the configuration. Unfortunately PowerShell doesn’t work very nicely with PsExec unless you use a bunch of weird workarounds that aren’t worthwhile.
The psexec command has a ton of other really useful options that you can use — each of these would be used in the space right after \\computername and before any of the other commands. So think psexec \\computername -option <remote command>.
If you just run the psexec command from the prompt without any extra switches, you’ll see all of them.
This command shows files that are currently opened over the network on a local PC or a remote PC, and it operates similarly to the Windows “net file” command. The syntax is just like any other command in the kit.
Yeah, this one isn’t as fun as the last one.
If you want to close one of the files and disconnect the person from the resource, you can close the connection by using the -c option, though that might result in a loss of data since the file wasn’t closed properly.
psfile \\computername <path> -c
This displays the security identifier for a computer or user, and takes the standard arguments. This utility is probably only useful in very particular scenarios, of which we haven’t personally encountered any. So try it once and forget about it until you need to use it someday.
This command lists lots of useful information about a system, including the uptime, which is lots of fun. You can run this one locally to test it out by simply typing psinfo at the command prompt, assuming your SysInternals tools are in the path.
If you want to get a lot more information out of PsInfo, and I know you do, then you can use the following switches to add disk information (-d) and hotfixes (-h) and a list of installed applications and their versions (-s).
psinfo -d -h -s
This results in a lot more information, even on a nearly blank virtual machine:
You can also run PsInfo remotely by adding the computer name and possibly the username switches… but there is one big problem: it won’t work unless the Remote Registry service is enabled. Head to the end of the article where we talk about how to enable it on the remote computer.
This command is really simple — it kills processes, by either name or ID, and you can use the -t switch to optionally kill the entire process tree.
pskill \\computername <PID or Name>
The problem with PsKill is that the latest versions of Windows have a very powerful task killing utility built right in called Taskkill that has a lot more features.
This utility is extremely simple, but fairly handy for quickly looking at a computer and seeing if something is using too much CPU or memory. You can specify the name or part of the name on the command line to narrow down the list to just a problem application, and you can see almost all information including threads.
Note: To make this utility work on a remote computer, you’ll need to have the remote registry service enabled. Make sure to read to the end of the lesson, as we explain how to deal with that later on.