Psexec is Dead

Adam Bertram

Adam Bertram

Read more posts by this author.

I’ve used Sysinternals’ psexec utility for a really long time. I can’t recall how long it’s been. It used to be one of those goto tools in my software utility tool belt. That is, until PowerShell came along.

PowerShell is an enormously helpful product. Replacing psexec is just a single, tiny piece of what it has done for me. So, why am I not using psexec anymore? Here’s why:

Using psexec requires an external dependency

It’s an external file that must exist somewhere. I can’t count how many times I went to use it and I forget where I put it so I either have to search or download it again. I’ve written scripts years ago and depend on it that I’ve long forgotten about. I run them now and the script fails because the path I had specified to �psexec �is long gone. Any extra dependency in your scripts is eventually doomed to fail at some time.

PowerShell Remoting

This should be all I have to say. Powershell is installed from XP on up and as of even version 2, it has had remoting capabilities. Remoting is much more powerful than psexec ever was and is built right into Powershell so I can use it all day and never have to worry about where I put a file. There’s a caveat for me as I currently don’t have remoting enabled on all of my clients. Sometimes it works and sometimes it doesn’t. I’m planning to change that but even if you don’t have remoting enabled, there’s still the next option I’m about to explain.


I know, I know. I could have used this method in the VBscript days but honestly, I used to use psexec so much that I never did any digging to find that I could use RPC and WMI to kick off remote processes. Using Powershell and the WMICLASS accelerator makes this a snap. Compare this:


to this:

' StartProcessLocal.vbs
' Free example VBScript to start a process (not interactive)
' Author Guy Thomas
' Version 1.8 - December 2010
' -------------------------------------------------------' 
Option Explicit
Dim objWMIService, objProcess, objCalc
Dim strShell, objProgram, strComputer, strExe 

strComputer = "."
strExe = "Calc.exe"
' Connect to WMI
set objWMIService = getobject("winmgmts://"_
& strComputer & "/root/cimv2") 

' Obtain the Win32_Process class of object.
Set objProcess = objWMIService.Get("Win32_Process")
Set objProgram = objProcess.Methods_( _
objProgram.CommandLine = strExe 

'Execute the program now at the command line.
Set strShell = objWMIService.ExecMethod( _
"Win32_Process", "Create", objProgram) 

WScript.echo "Created: " & strExe & " on " & strComputer

' End of free example of a Process VBScript

Why would I go to all the VBscript code hassle when I could just use psexec?

Seeing these reasons, why would anyone still use psexec? Perhaps there’s some obscure reason out there that I’m not aware of but for me, I’m retiring putting psexec out to pasture.

If you’re still using psexec for some reason, comment on this post. I’m curious how it’s still being used out there.

UPDATE 11/29/14: OK, fine. I’ll give you the argument that the -i switch for psexec is unparalleled in the Powershell world and maybe the -s switch

Subscribe to Adam the Automator

Get the latest posts delivered right to your inbox

Looks like you're offline!