| Downloads |
|---|
| 38060.zip |
Remotely diagnosing user and PC problems can be one of the most frustrating tech-support tasks administrators face. Often, it's like playing the parlor game "20 Questions" in which you try to figure out the secret that explains why the PC is acting in a certain way or why the user doesn't have the necessary permissions to work. Even when you use a remote control product to diagnose the problem, you still need to type in commands and run various tools on the ailing PC until you discover the root problem. I've created a script, Diag.bat—which you can download from http://www.winscriptingsolutions.com, InstantDoc ID 38060—that lets you run a set of commands on a user PC to quickly capture the necessary diagnostic information. You can customize the script to collect the information you want to use in your troubleshooting scenario.
To begin, you must determine all the information you want to capture and use in a typical troubleshooting situation. Some built-in commands or resource kit utilities run only locally; others can run against remote computers. Diag.bat contains local and remote code modules that run the appropriate tools for these two situations. The same principles apply if you want to create a script that you run against the PC from a remote node, but the number of commands that will work against a remote PC is limited.
As you compile your wish list of information and the utilities you'll use to collect the data, you need to specify whether the utilities are already installed on the local PC or whether you need to locate them on a shared location. You must install the Microsoft Windows 2000 Server Resource Kit or Win2K Support Tool utilities such as Reg (reg.exe), Findgrp (findgrp.exe), and Srvinfo (srvinfo.exe) locally on every computer or locate the tools on a publicly shared location. You also need to consider who needs to run the utilities. If you run the script while sitting at a user's PC, will you log on to the machine with your Administrator account or will the script run while the user is logged on? In most cases, running the utilities as an Administrator will give you more detailed PC information but little of the information that you need to diagnose User group or permissions problems. Also, consider the user context that each tool needs for it to be able to run correctly. Running Reg to query a registry key doesn't make sense if users don't have permissions to run registry tools or can't query the registry subkey for which you need the data. Table 1 lists the diagnostic information I want to collect as well as the utilities that will let me capture that data. Use this list as a starting point, then start adding the utilities you need to customize Diag.bat for your environment.
You have several options for displaying the diagnostic results. Diag.bat opens Microsoft Internet Explorer (IE) to display the output, but you can modify the script so that it opens Notepad or another application. After the script creates and displays the output file, the file remains in the user's Temp folder—you can move or copy the file to an administrative location for retention or further analysis or delete it. The code at callout B in Listing 1, page 10, shows all these options.
Identifying Administrators, Power Users, and Users
Because of Win2K's capability to nest groups, users often have local permissions that aren't immediately obvious when you open up the Administrators or Power Users groups in Computer Management (go to Start, Programs, Administrative Tools, Computer Management). A more accurate method for determining the level of authority that users have is to look at what tasks they can perform. To test whether a user can perform a task that only an Administrator can do, Diag.bat runs a Dir command against the ADMIN$ share, as the code at callout A shows. If that task fails, the script tries a second task that a Power User can typically perform; if that task fails, you know the user is a member of the User group. Diag.bat uses the Net Session command as the Power User test task. Notice at callout A that the double pipe (||) symbol runs the next command if the previous command fails.
Redirecting the Output
You can use a single greater than (>) symbol or double greater than (>>) symbols to redirect the output of a command. The > symbol creates an output file if none exists or overwrites the contents of an existing output file. The >> symbols create an output file if none exists or append the data to an existing output file.
Notice that Diag.bat uses > for the first ECHO command, which overwrites any output file that still resides in the Temp folder from an earlier run. Then the script uses >> to append all the diagnostic information from each of the utilities to the output file. If you want to create a blank line in the output file to separate logical groupings of information, use the syntax
ECHO.>C:\yourfile.txt
Diag.bat redirects all output to NUL to prevent display of success or error messages. For example, look at the Dir command against the ADMIN$ share at callout A. If this command succeeds, you don't want the script to enumerate the folders that the Dir command outputs. If the command fails, you don't want the error output to be visible either. You need to know only whether the command succeeds or fails. In this case, the redirection syntax is
Dir /B /AD \\%computername %\ADMIN$ 1>NUL 2>NUL
To see the effects of this command, try running the script after removing "1>NUL"; then try it after removing "2>NUL".
Removing blank lines from command output might come in handy. The Ipconfig command produces several blank lines of output. You can use the Findstr command with a class of characters to discard the blank lines:
Ipconfig /all
| Findstr /I "\[A-Z0-9\]"
In the section of the code that runs commands on a remote PC, I have used Sysinternals PsExec utility. This utility lets you run the Ipconfig command from a remote machine to get detailed network information. The PsExec tool adds some extraneous command output, such as the utility's name and some blank lines, to the top and bottom of the output from the Ipconfig command; you'll probably want to filter out that output. The skip switch in the For command lets you specify the number of lines to remove from the top of the output, and the chained Find commands filter out some of the final lines of output that contain unneeded information. The syntax is as follows:
For /f "tokens=* skip=4" %%i in
('Psexec.exe \\%1 Ipconfig
/all^|Findstr /I "\[A-Z0-9\]"^|find
/I /V "service"^|find /I /V
"exited"') do echo %%i
When Diag.bat uses the Reg command to query a registry key, the script needs to capture only the last line of command output, using the Echo command. The machines in my environment often have been members of several organizational units (OUs), but I'm interested only in the current OU, which the script obtains by using the command syntax
For /F "tokens=1,2,3 delims=/
" %%i in ('reg.exe query
"HKLM\SOFTWAREMicrosoft\WindowsCurrentVersionGroup Policy\History" /s
^|findstr "LDAP://OU"')
do set OU=%%j
ECHO PC OU: %OU%
Notice that this For command doesn't directly echo the output to the file but instead sets a variable, whose value is the last OU listed in the registry and thus the most recent one the PC has been a member of. In a separate line, we echo the value of that variable.
Deploying Diag.bat
You have several options for deploying Diag.bat. You can use Group Policy to distribute the script or, even better, create on each PC in your environment a shortcut that points to a server-located version of the script. You can place the script in the All Users profile or put it in a less obtrusive location in which IT support staff know where to look for it. Support staff or end users could run the script while they're logged on locally to the user's computer, or support staff could run the script from a remote PC. You can also create a 3.5" disk or a mini CD-ROM that contains the script and the resource kit and support tools it uses so that you can diagnose PCs that aren't on the network. To configure Diag.bat for your environment, perform the following steps:
- Download the PsLoggedOn and PsExec utilities from the Sysinternals Web site (http://www.sysinternals.com/ntw2k/freeware/psloggedon.shtml and http://www.sysinternals.com/ntw2k/freeware/psexec.shtml, respectively). These utilities are part of the PsTools package; you can also download them separately.
- Configure the path to the Reg tool (Win2K Support Tools) and the Findgrp and Srvinfo tools (Win2K resource kit). Note that reg.exe is already installed on Windows XP machines (see my comments in the Diag.bat script about the syntax difference for the XP version of Reg).
- Test Diag.bat on a few PCs, then customize the script with any additional utilities you need for your environment.
- To run the script on a local machine, type
Diag.bat
with no argument. Alternatively, you can run the script on a remote computer by using the syntax
Diag.bat <PC_Name>.
The Diag.bat script should give you and your support team a head start on getting the necessary information to quickly diagnose PC problems. The techniques it uses to process command output will give you some additional scripting tools that you can use in the future.
