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:
Table of Contents
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.
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:
' StartProcessLocal.vbs ' Free example VBScript to start a process (not interactive) ' Author Guy Thomas http://computerperformance.co.uk/ ' 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_( _ "Create").InParameters.SpawnInstance_ 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 WSCript.Quit ' End of free example of a Process VBScript
Why would I go to all the VBscript code hassle when I could just use
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