After you've been writing scripts for a while, you'll probably find that they comprise two basic types of scope: wide and narrow. A wide-scope script performs a broad query or action, such as determining the OS, service pack level, and all hotfixes on a group of servers. A narrow-scope script focuses, like a microscope, on a limited subject area. Narrow-scope scripts are those typically written to address common emergency requests such as "I need to know right now how many nodes are missing the XYZ hotfix!" or "For our upcoming security audit, I need to know how many user accounts have local Administrator account membership on each of our servers." I've put together 11 "mini" scripts that perform a variety of focused tasks related to system security and stability. I also introduce you to two helpful coding techniques that these scripts use in the Web-exclusive sidebar "Error-Handling Techniques," http://www.windowsitpro.com/windowsscripting, InstantDoc ID 49077.
The big joke I tell all my script-writing disciples is that I really have only one script that I modify to do different things. Now this might be an oversimplification,but after you check out these 11 scripts, you'll begin to see exactly what I mean: All the scripts share some similar code elements. If you're new to scriptwriting, you might be a bit intimidated at first. Keep in mind, though, that all scripts do, essentially, is accept input, perform processing, and provide output.
I've divided the 11 scripts into three categories: registry-query scripts, internal-command scripts, and external-tool scripts. Because of space limitations, we can't print all the scripts, so you'll find one sample script for each category. You can get all 11 scripts from the Windows Scripting Solutions Web site. Go to http://www.windowsitpro.com/windowsscripting, enter 49078 in the InstantDoc ID text box, then click the 49078.zip hotlink to download all the scripts.
The registry, of course, contains a wealth of configuration information. The three sample registry-query scripts—GetBiosDate, GetDatFileVer, and GetLastUserFromReg—use the Windows reg.exe tool to gather valuable registry information: the BIOS date, the date of virus-definition files, and the last logged-on user. These three scripts, as well as the other eight, all accept as an input list a text file containing the nodes you want to run the script against and output the returned data to a log file.
GetBiosDate. On machines running Windows 2000 and later, you can determine the BIOS date, which is stored in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Biosinfo registry subkey's SystemBios Date entry. The GetBiosDate script in Listing 1 runs reg.exe, as the code at callout B shows, to obtain the BIOS date for a list of specified nodes. The script also includes error-handling code at callout A. (For more information about this code, see "Error-Handling Techniques.")
GetDatFileVer. The GetDatFileVer script automates an important task: It ensures that automated updates for virus-definition files are working correctly and that virus-definition files are up-to-date. The script queries the registry to obtain the names and dates of virus-definition files on each specified node.
GetLastUserFromReg. If you have problems with users logging on by using service accounts or the Administrator account, the GetLastUserFromReg script will help you to identify those logons. Even if you've configured the last-logged-on user to be hidden, the registry maintains last-logged-on user information.
Sometimes you don't need to use an external tool or a registry query in a script to retrieve the information you want; a simple Dir command or an If Exist statement will suffice. The GetHostsFileSize script provides a good example by using a Dir command to obtain file sizes. The other internal-command script, GetTargetFileExistence, uses an If Exist statement to identify a particular file's existence.
GetHostsFileSize. A common ploy that spyware uses to manipulate unsuspecting users is to write entries to the HOSTS file that redirect users to sites posing as the real site they requested. GetHostsFileSize helps quickly spot machines that might have unusual HOSTS file entries. The script uses a Dir command, as the code at callout A in Listing 2 shows, to check the number of bytes in the HOSTS files across your environment. By scanning the script's output, you can identify nodes that have suspicious HOSTS file sizes and correct those files. After you've identified these nodes, you must still scan them for spyware or virus infections. Even so, having a list of affected nodes can give you a heads-up before user complaints about strange Web-browsing symptoms start pouring in.
GetTargetFileExistence. Occasionally, you'll receive alerts that a particular virus or spyware exploit leaves a certain file signature on the system, which can be a clue that the machine is infected. The GetTargetFileExistence script quickly surveys and logs file-existence information on a large number of nodes and can be a helpful tool for identifying specific file signatures.
As a Windows IT pro, you're fortunate to have an abundant selection of external tools to use for querying systems. Many of these tools are part of the Windows resource kits or Windows Support Tools, but a number of third-party tools are available as well. The six scripts in this category use a diverse group of external tools to perform an equally diverse assortment of tasks: checking a file version, verifying that a hotfix was installed, identifying the number of blue screens a system has had, obtaining the number of members in the local Administrators group, retrieving the number of shared folders on a PC, and logging system-uptime information.
GetFileVers. Occasionally I need to check whether the version of a file is the correct one on all our nodes. Most often this is an .exe or a .dll file that has to be at a certain version level. The GetFileVers script uses the Windows Server 2003 Support Tools Filever tool, as the code at callout A in Listing 3 shows, to display version and build information about executable files.
GetHotFix. Given the continual flow of hotfixes emitting from Microsoft, you'd probably like to be able to search your environment for a specific installed hotfix and verify that your automated or pushed updates are working correctly. The GetHotFix script does just that by executing PsInfo, a freeware command-line tool available from Sysinternals (http://www.sysinternals.com/utilities/pstools.html). PsInfo, which is part of Sysinternals' PsTools suite, provides a variety of system information. GetHotFix invokes PsInfo to display a list of hotfixes installed on the systems specified in the input file.
GetNumberOfBlueScreens. At my company, a server frequently had system errors that produced blue screens; when the blue screen appeared, the server automatically rebooted without indicating that anything unusual had happened. If the server rebooted at just the opportune moment and our paging script missed the few minutes the node was offline, we didn't know that the problem had occurred. I wrote the GetNumberOfBlueScreens script to identify the number of recent blue screens a machine has experienced. The script uses the Uptime (uptime.exe) tool that's included in early Windows resource kits. You can also download Uptime at http://www.microsoft.com/ntserver/nts/downloads/management/uptime.
GetNumberOfLocalAdmins. Most of the servers and PCs in our environment have a limited number of local Administrator group accounts. These generally consist of a few local domain groups along with the local Administrator account. Our policy allows only groups—not individuals—to be local Administrators. The GetNumberOf-LocalAdmins script periodically checks the number of members (groups or users) in the Administrators group, letting us identify nodes that violate our local Administrator policies. The script invokes the Windows Server 2003 Resource Kit Local tool (local.exe), which displays members of local groups on remote servers or domains.
GetNumberOfShares. On our user PCs, we're trying to reduce the number of shared folders that users create to share potentially proprietary corporate data. We don't want to block users completely, but we do want to monitor how many shares they have beyond the default number of shares that Windows allots. The GetNumberOfShares script uses the Rmtshare tool (rmtshar.exe) to display information about shares. Rmtshare was in earlier Windows resource kits and is still available from the Microsoft FTP site at ftp://ftp.microsoft.com/bussys/winnt/winnt-public/reskit/nt40/i386/rmtshar.exe. When you download the executable file, you might notice that it's named rmtshar.exe (not rmtshare.exe). Don't be confused; the executable was originally called rmtshare.exe in the resource kits, but now is called rmtshar.exe. Be sure to modify your script or rename the file to match the actual name of your executable.
GetUptime. System-uptime information can help you determine whether a node has been rebooted since the most recent hotfix was applied. Additionally, keeping an uptime log can help you spot the use of hacking utilities that intruders could employ to modify event logs on nodes. Such utilities might restart the system to cleanse the event log of entries and cover the hacker's tracks. The GetUptime script helps you keep an eye on uptime by using PsInfo to capture the uptime for a list of nodes.
Getting the Scripts Working in Your Environment
I tested the 11 scripts on a Windows XP SP2 system. Remember to carefully test your scripts in a nonproduction environment before rolling them out into production. To get the scripts working in your environment, follow these steps:
- Download the script code from the Windows Scripting Solutions Web site. Place all the files in one dedicated directory.
- Obtain the Filever, PsInfo, Uptime, Local, and Rmtshare tools.
- Configure each script file with the tool locations and configuration options.
- Create an input file containing a handful of nodes you want to test the script against. Put one node name on each line. Name the file InputList.txt and place it in the dedicated directory where your scripts reside.
- When you run each script, it creates an output file named similarly to the .bat file in your dedicated folder. For example, the GetBiosDate script creates an output file called GetBiosDate-LOG.txt.
- After you've tested all 11 scripts and verified the settings, you can add more nodes to the InputList.txt input file.
Small Is Beautiful
I've given you 11 practical, focused mini scripts and a couple new techniques for handing errors. You can use the scripts as-is or easily modify them to monitor different aspects of system stability and security. Keep these small scripts handy for emergency situations. You'll be surprised just how often you can use them!