You can customize the Process Farm system scripts to meet your needs. For example, you can adapt the parent process script to provide feedback immediately or to start the child processes immediately. You can also adapt the child process script by adding subroutines. For example, you can add a more robust ping subroutine or a subroutine that determines whether users are logged on to a machine.
A More Complicated Parent Process
The parent process script PingParent.pl doesn't output any information until the job finishes. Because you'll probably watch the script execute, you might as well get the data as soon as the script obtains it. The trick is to output the data in sorted order as it becomes available. By adapting the post-processing loop in PingParent.pl, you can obtain immediate feedback. Listing 1 contains this adapted script, PingFeedback.pl.
An Even More Complicated Parent Process
PingPersistent.pl in Listing 2 builds on the changes in Ping
Feedback.pl. PingPersistent.pl starts the child processes immediately and then lets you ping as many ranges as you want. With this script, you only have to wait for the child processes to start up once if you're going to be pinging a lot of ranges.
A More Useful Child Process
You can add value to the child process script PingChild.pl by adding subroutines. For example, LoggedInChild.pl in Listing 3 includes not only a more robust ping subroutine but also two additional subroutines (nslookup and loggedin).
The more robust ping subroutine pings a remote host and returns the value of 1 if successful or the value of 0 if unsuccessful. Unlike PingChild.pl, this subroutine attempts three pings and uses a 2-second timeout.
The nslookup subroutine asks the DNS server for the IP address corresponding to the passed host name. If you run DNS and WINS on the same server and use DNS to find IP addresses for workstations using DHCP, you can use this subroutine to help determine whether a machine is booted or has a known dial-up IP address.
The loggedin subroutine determines whether a user is logged on to a machine. This subroutine is simplistic and breaks down, for instance, in the presence of services that log on using an explicit account name rather than the system account. To make this subroutine more robust, you have two options. If every machine you access has those services, you need to increase the test regarding the number of keys in HKEY_USERS. If every machine you access doesn't have those services, you need to build code that looks at the SID associated with each key and determines whether it's a user or a service account.
Here's how you might use these three subroutines in a parent process that relies on LoggedInChild.pl. First, the parent process builds a list of machine names and then creates an appropriately sized MyRpcPool of LoggedInChild.pl processes. The parent process then has the child processes execute the nslookup subroutine on those machine names. Then, the script walks through the return data and builds a pool of ping jobs, skipping those machines that lack IP addresses or have known dial-up addresses. After the ping jobs execute, the script builds a pool of loggedin jobs containing those machines that responded to the ping. The script then executes the loggedin jobs and prints out a list of booted machines that don't have anyone logged on to them.
These three examples demonstrate a variety of techniques that you can use with the Process Farm system. You can find Listings 1, 2, and 3 in the .zip file under the Files/Code heading in the Article Info box. The scripts are also in the Demos directory in Process Farm.zip.