In today’s lesson in our Geek School series covering SysInternals, we’re going to show you how to use the PsTools set of utilities to perform all sorts of administration tasks both locally, and on remote computers as well.
If you’ve ever wanted to connect to another computer and run a command, quickly get information about processes running and optionally kill them, or even stop a service on another PC, you can use the PsTools utilities to do all of these things and even more.
Obviously you can use Remote Desktop or a similar service to connect to any Windows computer and actually see the desktop and do anything that you would do locally, but the PsTools utilities allow you to do many tasks from the command line — or better yet, from a script that you can re-use later.
These are the type of utilities that work best in a corporate environment, and mastering these tools will definitely make you much better at your system administration job, save you time, and let you do things in a much smarter way. Doing things smarter and faster is a critical skill for being a great sysadmin.
There are twelve tools in the PsTools set, and while some of them are extremely useful, others have been superseded with tools built into more recent versions of Windows, and there are a few others which aren’t useful for most people. We’ll go through all of them so you understand how they work and why you might want to use each one.
- PsExec – executes processes on a remote computer
- PsFile – shows files that are opened on the remote computer through the network
- PsGetSid – displays the security identifier for a computer or user
- PsInfo – lists information about a system
- PsKill – kills processes by name or ID
- PsList – list information about processes on the command line
- PsLoggedOn – list accounts that are logged on either on the machine or connecting remotely
- PsLogList – pull the event log on the command line
- PsPasswd – change the password for users
- PsPing – a fairly simple ping utility with some additional features
- PsService – list and make changes to Windows services
- PsShutdown – shut down, log off, or suspend a computer
- PsSuspend – suspend and resume processes (rather than killing them)
It’s worth noting that you can use a tool like PsExec to execute all sorts of command-line utilities on remote computers… including really useful ones like the Autoruns command line tool and many more. The possibilities are endless once you’ve embraced the power of PsTools.
All of these tools can be used on local computers, but they are mostly useful for connecting to remote computers and performing commands on them.
Connecting to Remote Computers ( Syntax for All Utilities)
All of the utilites can be run on either the local or remote computer, so they all have the same first argument for computer name if needed. Note that you could use the IP address if you wanted instead. If you omit this argument, the command will operate on your local computer.
You can also list multiple computers like psinfo \\computer1, computer2, computer3, or you could put all of the names into a file and reference that like psinfo @computerlist.txt. The final syntax is psinfo \\* which operates on all computers in the domain, which probably isn’t something you’ll use every day.
If you need to connect with alternate credentials because your local computer’s account has a different username and password than the other computer, you can use the -u and -p options, though we’d note that you might not want to use -p on the command line with a password in the command for security reasons. Update: as of the latest release of PsExec, no tool passes passwords as clear text anymore, so the only worry is if somebody can read your script files and see the password there.
psinfo \\computername -u “user” -p “Password”
The “user” part of the command would change to “DOMAIN\user” if you are in a domain environment and need to change from the currently running user.
Note: you will generally need to connect to the remote computers with an administrator account.
Configuring Remote Administration Access
If you are in a domain environment, which most people that need to use PsTools will be, you can ignore this section entirely as everything should work just fine. For anybody running Windows 7, 8, or Vista in a home environment or using a couple of computers in an office without a domain, you will need to tweak User Account Control on the remote computer to allow PsTools to properly run.
The problem is described well by Microsoft:
When a user who is a member of the local administrators group on the target remote computer establishes a remote administrative connection by using the net use * \\remotecomputer\Share$ command, for example, they will not connect as a full administrator. The user has no elevation potential on the remote computer, and the user cannot perform administrative tasks.
To explain it in a different way, when you try to connect to another computer and run something that requires administrator access, there is no way to trigger the UAC prompt and accept it from your computer, so it won’t connect as administrator.
And this isn’t a bad thing. You shouldn’t change this setting without fully understanding that you will be allowing an opening for malware to spread from one computer to another — assuming that malware has your local username and password, and that password is the same as the other computer, and the malware is that tricky, which most isn’t. But it still isn’t something to be taken lightly.
And again, if you are in a domain environment, this problem doesn’t exist and doesn’t need to be changed. And if you are just testing with a bunch of virtual machines, you don’t have much to worry about.
To tweak UAC to enable PsTools to run you’ll want to open up the Registry Editor and navigate to the following key:
Once you are there, create a new 32-bit DWORD on the right-hand side, give it the name LocalAccountTokenFilterPolicy and the value of 1. You don’t have to restart the computer to make the setting take effect.
Note: just to clarify, this setting needs to happen on the remote computer that you are connecting to.
PsExec is probably the most powerful tool in the kit, as you can execute any command in your local command prompt just like executing it on the remote computer. That includes anything that can be run on the command line — you can change registry values, run scripts and utilities, or connect from that PC to another one. The output of the commands will be shown on your local PC, rather than on the remote one.
The syntax is simple:
psexec \\computername <options> apptorun.exe <arguments>
Realistically, though, you would want to also include the username and password on the command line. For example, to connect to another PC and check the network connections list, you would use something like this:
psexec \\computername -u User -p Password ipconfig
That command would produce output similar to the following:
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.
This utility lists accounts that are logged on either on the machine or connecting remotely. It’s pretty simple, and largely useful in a system administrator type of environment.
This utility displays a local or remote event log on the command line, and there are a number of options that can be used for filtering the data.
psloglist \\computer System
There are also the -h, -d, and -m options, which let you narrow down the list of events to just the last x hours, days, or minutes. The -n option displays the list x records, while the -r switch reverses the order so the latest records will be at the bottom of the output. The last option, which we set to “System” in this example, is not actually necessary — if you omit it, the System log will always be pulled, but you could change it to Application or Security to pull those logs instead.
It’s worth noting that if you have administrator access to the other computer, you can simply open Event Viewer and choose Connect from the Action menu. Enter the computer name in the list, change the credentials if you need to, and access the event logs that way.
The only scenario where we can really see PsLogList being really useful is if you wanted to script out something to perform an action in case of certain messages in the event log.
This utility allows you to change the passwords for users, both local and remote. The syntax is the same as everything else:
pspasswd \\computer -u User -p Password <AccountToChange> <NewPassword>
The benefit to this utility over just using NET USER from the regular command prompt is that you can change passwords for multiple computers at once, and it works in a domain environment as well.
This utility pings, checks ports, and does latency and bandwidth testing. Pretty simple.
Or you can check connectivity to a port by adding the port number like this:
There are a ton of advanced options to this command that you will probably want to check out should you ned to do some network troubleshooting.
This utility allows you to deal with Windows Services from the command prompt. It’s really quite easy to use — the syntax works like this:
psservice \\computername <command> <arguments>
The list of commands can be found by looking at the help /? options, but there are a few options that you’ll find yourself using more than the rest.
- query – Queries the status of a service
- config – Queries the configuration
- setconfig – Sets the configuration
- start – Starts a service
- stop – Stops a service
- restart – Stops and then restarts a service
- pause – Pauses a service
- cont – Continues a paused service
- depend – Enumerates the services that depend on the one specified
- find – Searches for an instance of a service on the network
- security – Reports the security permissions assigned to a service
In particular, the start | stop | pause | restart | cont options are really simple and easy to understand. For instance in the following command you could replace “start” with any of those other commands.
psservice \\computername start <servicename>
The other options can be used to query more information about a service, or change the configuration.
Note: the built-in sc.exe utility has a ton of useful features that overlap with this utility. The main difference is that PsService is a little more user-friendly.
This utility allows you to shut down, log off, or even put a computer into sleep mode. The problem is that it isn’t better than the built-in shutdown.exe utility, and was actually designed for Windows XP, so it’s recommended to use the built-in utility instead in most cases.
The one option that PsShutdown provides that you can’t get otherwise is the switch (-d) to put the computer into sleep mode, which can be handy.
psshutdown \\computername -d
You can also use the -h option to put the computer into hibernate mode instead.
This utility is very similar to PsKill, but it does something that the built-in Taskkill utility just can’t — you can suspend processes rather than kill them, which can be very handy if you want to temporarily stop a CPU-intensive process from running while you complete a sysadmin task.
Suspending a process is extremely easy:
pssuspend \\computer <PID or Name>
And resuming that process is just as easy — all you have to do is add the -r switch.
pssuspend \\computer -r <PID or Name>
When the Utilities Won’t Connect Because of Remote Registry
Some of these utilities, including PsInfo, PsList, PsLogList, and PsLoggedOn require the remote registry service to be enabled on the remote computer, and it isn’t enabled by default on modern versions of Windows.
The good news is that this problem is easily fixable, and you don’t have to leave Remote Registry enabled. Just run this command using PsService to start the service:
psservice \\computername start RemoteRegistry
And then when you are done with whatever you are doing with PsInfo or PsList, you can stop the service again using this command:
psservice \\computername stop RemoteRegistry
Simple solutions are the best, aren’t they?
Make sure to join us tomorrow, when we cover file and disk utilities, and some more interesting things.