A new week begins and the Tools, Tips and Tricks series continues. Today I shall talk about using PsExec (part of the PsTools package) to collect data from a remote box through PsExec. PsExec lets you execute processes on other systems without having to manually install client software.
The scenario that I will discuss today is collection of a Process Monitor trace on a server without logging onto the machine. This is quite useful if you need to collect a Process Monitor trace from one of the passive nodes while running SQL Server 2005 setup.
The .cmd file that I am using in this case has the following commands:
set PM=D:\ProcMon\procmon.exe start %PM% /quiet /minimized /AcceptEULA /backingfile D:\ProcMon\notepad.pml %PM% /waitforidle ping 127.0.0.1 -n 10 -w 100 %PM% /terminate
I am running the .cmd file to spawn Process Monitor on a different server and capture a trace using a local file as the backing file. The reason why we would have to run Process Monitor from command line is because while running setup, it’s recommended that you do not log into the passive nodes using Terminal Services or Console Mode.
The command that I used to execute the commands present in the .cmd file is
PsExec \\<server name> -c RemoteProcMon.cmd
If you do not prefer the ping method to simulate waits, you can use the SLEEP utility available with Windows 2003 Resource Kit. This utility takes a parameter for milli-seconds to wait. If you need to set filters for Process Monitor, then run the Process Monitor tool in GUI mode and set the Filters and save it. After that Exit Process Monitor and run the above command from Command Line. Or you could alternatively create a configuration file and use the /LoadConfig command line switch for Process Monitor.
Again the possibilities are endless and you can extend this by using the command line options for PsExec and Process Monitor.
Use the options mentioned in Tools Tips and Tricks #1: Process Monitor so that the filters are correctly set and the page file doesn’t get overwhelmed if you are capturing data for long periods or on servers where there is high amount of activity.
TroubleshootingSQL 
Pingback: Tools Tips and Tricks: Round-up « TroubleshootingSQL
Awesome tip.
BTW I have a couple of questions.
a. By using the -c switch we are essentially copying the .cmd file to the second machine and executing there (am I right?). If so shouldn’t we specify the UNC path in the script?
b. Will the page file grow indefinitely on the first machine and will I run out of virtual memory on it?
Thanks a bunch!
LikeLike
argh! my bad. We can rule out the second question here. How did I forget we are saving to a file.pml and not the page file. Uh… Sorry about that.
LikeLike
-c option copies the specified program/file to the remote system for execution. If you omit this option then the application must be in the system’s path on the remote system. This doesn’t require a UNC path. In case you are accessing remote resources in the .cmd file, then you need to use UNC path or ensure that the resources are available in the system path or a path specified in the system path environment variable on the remote system.
LikeLike
Thanks Amit.
But when it reaches this step
C:\Windows\system32>start H:\Procmon\procmon.exe /quiet /minimized /AcceptEULA /LoadConfig ProcmonConfig.pmc /backingfile H:\Procmon\Procmon_test.pml
It hangs in there forever (the pml file is never created); it works when executed on the local machine though.
Also PSEXECVC is running on the remote machine and the .cmd file is created there.
LikeLike
What are you monitoring. It depends on the filters that you have specified in the procmon configuration file. You need to terminate the procmon collection using /Terminate switch. Also, check if the account being used has permissions on the H: drive.
LikeLike