What if you could offer your Help desk technicians one-stop shopping in computer configuration information that included group memberships, installed software, hot fixes, disk space, uptime information, and blue screen instances? If you collected such data before dispatching a technician, you'd give the tech a detailed picture that could help him or her find hidden problems more quickly. In many cases, problems could be identified and resolved without an onsite tech visit. Another benefit would be that you could identify potential problems and resolve them before they become headaches. No single tool that I know of will produce a report with all the details of user permissions and PC configuration, but the good news is that you can build your own reporting tool by using command shell scripting utilities. If you're new to scripting, the DesktopDiag.bat script that I've developed will introduce you to the world of command shell scripting. As a bonus, the script can do double duty on servers. Having a detailed list of installed server software, services, and various configuration options can be an asset in server configuration control, disaster recovery planning, and server virtualization migrations.
Why Build Your Own Configuration Reporting Solution?
In many IT departments, the push is toward using Commercial Off-the-Shelf (COTS) tools and away from developing custom solutions. However, the main disadvantages of using a custom solution—development costs, maintenance costs, and breakage risk—don't apply to a scripted solution such as DesktopDiag.bat because such tools are simple to create, easy to maintain, and run only in an acquisition mode without making any configuration changes. In addition, your environment might require unique information that wouldn't be of interest to other companies with dissimilar environments. Having your own tool gives you the flexibility to add and remove items from the report. And, if you discover a new resource kit or third-party utility that has useful output for your report, you can easily incorporate it in the tool. Another advantage to a home-grown tool is cost. Because most scripting utilities are freeware, the cost of putting your own scripted solution together is minimal. Finally, if you decide to go shopping for a COTS solution in the future, you'll have developed an accurate requirements list.
Compiling the Output Wish List
When I developed DesktopDiag.bat, I first listed the information I wanted to capture. The list divides naturally into the categories of user and computer settings.
User settings (for logged on user or a specified user account)
Logged on username(s)
Username data such as user domain, friendly user name, user ID
User details such as home drive, home path, logon script, account expiration, logon hours, password age, password last reset
Level of authority the logged on user has
Local groups the logged on user is a member of
User profiles on the PC
User local and global group memberships
Computer settings
OS and service pack level
List of installed hotfixes
Network setting, including IP address information and MAC address
List of automatically starting programs
Processor type, speed, and installed memory
Resultant Set of Policies (RSoP)
OU location
List of Installed programs
Services and their status
List of shared folders
Details on logical drives, including drive letter, space-free and space-used statistics
Physical drives details
Video card details
Installed printers
Local computer group memberships
Bluescreen and uptime information
Local Administrator group members
Local groups the computer is a member of
Identifying Tools to Obtain the Data
Choosing utilities that will extract the data you want to see is a simple matter of listing the information you want, then locating the utilities that deliver that output. In many situations, a utility can give you more information than you require. You can either filter the output to just what you need or dump and sort through all the information that a particular tool supplies. The disadvantage to relying on a lot of filtering is that doing so adds overhead and increases script runtime. In some cases, you'll need to chain commands together; for example, you'll pull an initial piece of information such as the logged on username, then use that information to get group memberships. DesktopDiag.bat minimizes filtering. You'll likely see runtimes of well under 1 minute if the script is run locally, or from 1 to 1.5 minutes if run remotely. It would take much longer to retrieve the same information by running the tools individually or by using the Windows GUI.
DesktopDiag.bat uses 14 utilities and many built-in commands to capture report information. Table 1 lists these utilities. I've also developed a utility matrix that offers more detail about the tools and commands that DesktopDiag.bat depends on. To download the matrix and DesktopDiag.bat, magazine subscribers and registered Web site users can go to http://www.windowsitpro.com, enter 46268 in the InstantDoc ID text box, then click the 46268.zip hotlink. Because it's unusual for the resource kit and third-party tools to be installed on a local machine, I recommend that you create a shared folder to house the utilities on a server. Your script can point to this location. Keep in mind that limitations exist on what a given utility can accomplish. Some of the best tools for capturing information, such as the Ipconfig command, don't work remotely unless you use a remote command tool such as Sysinternals' PsExec or Beyond Logic's BeyondExec to launch them.
Identifying Capture Scenarios
In any solution you create, certain capture scenarios and tool limitations will affect what you can accomplish. In a PC configuration report, for example, if you plan for the report to show user information, what will happen if the user isn't logged on when you are querying his or her machine remotely? I identified four capture scenarios for DesktopDiag.bat that are representative of most troubleshooting situations.
Capture data on a local machine while a user or administrator is logged on locally.
Capture data on a remote machine while a user is logged on locally.
Capture data on a remote machine and allow the forcing of a specified user account.
Capture data on a remote machine while multiple users are logged on locally, both by local logon and Windows 2000 Server Terminal Services.
Order Your Fundamentals CD Today! Register today for your in-depth copy of one of three Fundamental CDs on the following topics – Exchange, SQL, and SharePoint.
Previous
middledd April 28, 2008 (Article Rating: