PsTools Part 3: PsList and PsKill

If you are familiar with the Linux command-line world, PsList and PsKill will have some similarities in function to ps and kill but not syntax. Personally I think PsList and PsKill are far more intuitive, and they are extremely helpful when managing Windows Server Core installations.

PsList will list all processes on either local or remote hosts. In Linux you could ps -ax | grep [name] to find a process with a specific name, and with PsList you can simply pslist \\remotehost processname. Using the very helpful -t flag, you will list the processes and their descendants. Using the -d, -m, and -x are helpful when troubleshooting the performance of a specific process such as the notorious sqlservr.
Perhaps the most important capability of PsList is it's "task manager" mode which gives you live streaming metrics when you use the -s flag.


PsKill kills a targeted process. It's very important that you specify the correct process on the correct host before executing a PsKill. That's why I strongly recommend you use process IDs (PIDs) when targeting a process to kill. Similarly with PsList, the -t will kill the targeted process and its descendants.



Note: As always you need to have administrative credentials and port 135 (WMI) open for remote hosts. In any PsTools application, you can specify a username (-u) and a password (-p). If the remote host is not on a common domain, you should specify the domain within the username (domain\username or username@domain). When using local credentials to the remote host, you will specify the remote host as the domain (remotehost\username or username@remotehost). With both PsList and PsKill you cannot specify multiple hosts in the same command.

Read more...

PsTools Part 2: PsExec

PsExec is application within the PsTools suite will allow to locally and remotely execute other applications. As always, you must have the WMI/RPC port (135) open on remote hosts.

The ability to execute the same application on many computers simultaneously has it's advantages in network administration and classroom computer lab administration.

Here is the usage from the Microsoft website:

psexec [\\computer[,computer2[,...] | @file][-u user [-p psswd]][-n s][-l][-s|-e][-x][-i [session]][-c [-f|-v]][-w directory][-d][-][-a n,n,...] cmd [arguments]

From this usage we do something simple send a reboot command to a computer:

psexec \\myfileserver shutdown -r -t 0

Notice that the arguments after the shutdown command apply only to the shutdown command on the remote computer and not to psexec. To send this command to a long list of servers, it could look like this:

psexec @serverlist.txt shutdown -r -t 0

Now using the -i flag, we can have our remotely launched application interact with the desktop. In a server administration setting, this is rarely useful for more than pulling pranks on your coworkers; however in a classroom lab environment, it might be useful to open a web page on every computer in the lab:

psexec @mylabPCs.txt -i iexplore http://netadmin4noobs.blogspot.com

But... there's a problem with that. Because the iexplore application won't end until someone at the work station closes it, you must at the -d so psexec does not wait for the application to end:

psexec @mylabPCs.txt -i -d iexplore http://netadmin4noobs.blogspot.com

The flags -c, -f, and -v I can only see being used for either rare occasions or for custom scripts which are regularly updated. In that case you must use the -v flag. Use your common sense.

With PsExec, as well as the other application in the PsTools suite, you can specify the username and password within the command (-u for username and -p for password), but I think you are adding an avoidable security risk. It would be best to run the PsExec with an account that has administrative access on the remote machine. If you are in a situation where you must specify username and password (i.e. a host which is not attached to an Active Directory domain so you're using a local account), it's a good idea to precede the username with the machine name. For a scenario where the username is administrator and the remote host is pc12345, it would look like this:

psexec \\pc12345 -u pc12345\administrator -p password

This way you are telling the computer where to look to authenticate the credentials.

The rest of the flags are either pretty self-explanatory or ones you shouldn't use. But if you have questions, feel free to comment and I will respond.

Read more...

PsTools Part 1: Introduction

PsTools is small suite of command-line of applications within the greater Windows Systinternals suite.

Any network admin of more than just a handful of Windows servers should be very familiar with PsTools. If there is any process where you must repeatedly RDP (Yes, I use it as a verb.) into a server, you could probably save yourself some serious time by automating the process in a batch file which refers to one of the utilities within the PsTools suite.

There is no installation for PsTools. You only need to download the ZIP file from Microsoft, and extract the contents into an easy-to-find location such as C:\pstools (my choice). If there is a server or workstation which you wish to use as your base of operations, you should consider adding the path to your PsTools directory into Path Environmental Variable:

(Windows 7) From the start menu, right-click on Computer and choose Properties. Click on Advanced System Settings in the upper-left part of the window that just opened up. Click Environmental Variables. In the bottom section labeled System Variables, scroll down, highlight Path, and click Edit. Click in the box labeled Variable value, and press the End key on your keyboard. Add a semicolon and immediately follow that (no space) with the path to your PsTools applications (i.e. ;C:\PsTools).

Note: To run a command using a PsTools application on a remote computer, you must have the WMI/RPC port (135) open on the remote host.

Read more...

Salutations!

If you've reached this blog, it's most likely because you are searching for the answer to a problem. This blog is my first tech blog, and I believe it will serve me as much as it serves you. I plan to use this as an open compendium of tools, tips, and tricks for network administration in Windows, Linux, and VMware environments.

I hope you find what you are looking for, and feel free to comment when you have anything to add.

Thank you.

Read more...