Some valuable advice for administrators new to command shell scripting
I recently exchanged several emails with a long-time UNIX administrator who was new to writing command shell scripts. I realized that many new Windows administrators would benefit from a simple command shell scriptwriting Q&A. The following information will help administrators set up their scripting environment.
I'd like to learn how to write Windows scripts, but I'm not sure which language to use (e.g., command shell scripting, VBScript, Perl). Is there a preferable language?
Although many scripting languages are available, command shell scripting is a great place to start. Administrators need to be familiar with command shell scripting because they sometimes need to modify or update legacy command shell scripts in their environment. In addition, some applications use scripts to start services or perform other operations that administrators need to troubleshoot. Being able to examine command shell code and quickly determine a script's operation is often useful. Even if shell scripting isn't your primary scripting language, you need to be familiar with command shell scripting because it's useful to call some utilities and commands from scripts written in other languages (e.g., VBScript, Perl).
I've heard that .bat files' functionality is limited. Is this statement accurate?
Many people associate .bat files with the command shell in Windows 9x, Windows 3.x, or MS-DOS. Admittedly, these OSs' command shells have limited functionality. However, the command shell in Windows NT and later is enhanced and offers more built-in commands and other tools. A well-written command shell script has extensive functionality.
How do I know which commands to use for particular tasks?
You can use three types of commands in your command shell scripts: built-in commands and commands from resource kit tools and third-party tools. To obtain a command's help information, enter
where command is the name of the command you want to learn about.
Windows Server 2003 and Windows XP have approximately 200 built-in commands. You can use the online help to learn about these commands' usage. Select Run from the Start menu, or open a command shell window, and enter
The Windows Server 2003 Resource Kit Tools include more than 200 additional tools that aren't installed by default. Some of these tools are GUI based but many are command shell oriented. To download the resource kit installation file (rktools.exe), go to http://www.microsoft.com/downloads/details.aspx?familyid=9d467a69-57ff-4ae7-96ee-b18c4790cffd&displaylang=en. (Note that the resource kit I discuss here is the freely down-loadable software and tools, not the set of Microsoft reference books that you must purchase, which includes the resource kit software and tools on CD-ROM.) Consider not accepting the default installation location, which contains spaces in the pathname. Some command shell tools are sensitive to spaces in the path when used inside a For loop. The support tools installation file (suptools.msi) is available in your Windows OS's installation CD-ROM's \SUPPORT\TOOLS folder.
Third-party tools are tools that developers create to solve specific problems in their own environments, then make available for others to use. Many third-party tools are available as freeware. Most of the third-party tools I use are from the following four sources:
- Sysinternals' PsTools (http://www.sysinternals.com/utilities/pstools.html)
- Joeware.net's Windows 2003 tools (http://www.joeware.net/win/free/k3.htm)
- SystemTools Software's free utilities
- Beyond Logic's software solutions
Between the built-in tools, resource kit tools, and third-party solutions, you have 400 to 500 tools available. The number of tools continues to increase, giving you many resources for accomplishing scripting tasks.
I installed the Windows Server 2003 Resource Kit Tools, but when I enter a command at a command prompt, I receive the message ' Command' is not recognized as an internal or external command, operable program or batch file. What am I doing wrong?
When you install resource kit tools, the installation program puts an entry in the path variable during installation. If you later rename the destination folder and change the tools' location, you must also change the path variable to reflect the new location. Also, if you copy the Resource Kit Tools folder from one machine to another, you must change the path variable to reflect the new location.
I've tried running several commands that I've seen in command shell scripting articles, but I receive error messages. What could be causing the problem?
First, ensure that you're using the same version of the tool as the article discusses. Developers generally add switches and options as they create later versions of tools. (For this reason, using the latest version of a tool is best.) Then, if the version on your machine differs from the version being discussed in the article, use your tool's online help to compare the two versions' switches and options. Not only do new switches and options get added but occasionally existing switches and options get changed. For example, an existing switch's delimiter might change from a front slash (/) to a hyphen (-). You need to modify your code to accommodate such changes.
I'm interested in command shell scripting because I've heard it can help me monitor security in my environment. How can I use shell scripts to enhance security?
You can use scripts in combination with command-line tools to increase security. I've used scripts for the following security-related needs:
- To create a log that contains the membership of the local Administrators group on a list of servers or an entire organizational unit (OU) of servers
- To create a report that lists all the permissions on a shared resource
- To create a log that identifies all the groups and users in a particular OU
- To compile a list of the last users logged on to each server and workstation
- To locate all the servers in my environment that have vulnerabilities, such as missing hotfixes or hidden payload files
- To create a log that details any membership changes to the Administrators group or other special-privilege groups in the domain
- To determine when PCs that normally stay on 24 X 7 are being are shut down. I once encountered a situation in which thieves were shutting down machines and removing memory. I wrote a script that helped pinpoint the times and locations of these unauthorized shutdowns.
Which Windows command shell scripting books are useful?
The gold standard text for command shell scriptwriters is Timothy Hill's Windows NT Shell Scripting. Although the book is somewhat dated, it's still an excellent resource. Hill was the first author to introduce many administrators to the power of command shell scripting. Several recently published texts also provide information about command shell scripting. William R. Stanek's Microsoft Windows Command-Line Administrator's Pocket Consultant is one of the best. Stanek arranges the chapters by task, so you can quickly and easily determine which tool and code to use to accomplish a task.
I want to set up one machine on which to develop and test scripts and set up another machine in my production environment to run the scripts. What hardware and software are necessary?
I use a XP PC for script development and testing. I schedule production scripts to run on a Windows 2003 machine. This production server is a multiprocessor on a 1 GB network, which gives me enough power and network speed to run scripts simultaneously. At one time, I had about 2000 script instances running each day on my production server. If you're just getting started, you probably don't need that much computing horsepower. You can probably run scripts on your development machine. Another approach is to use a file server to do double duty as your production script server.
I use a matching folder structure for scripts on my development and production machines. I store each script and its input and output files in a folder labeled with a descriptive name. The Windows Server 2003 Resource Kit Tools are installed on both the development and production machines in a matching folder location. I store third-party tools in folders according to their source. For example, I store all the tools from Sysinternals in one folder and all the tools from Joeware.net in another folder. The matching folder structure lets me easily copy a script from the development PC to the production server—I don't have to change any tool, input-file, or output-file path in the script.
I use a script to replicate the folder structure from the production server to a second server so that I can run scripts from the backup server if the primary server fails. This backup step proved necessary after a disk controller failed on the production server and I quickly experienced fallout from other administrators and end users who use the output from the scripts that I run. The old adage held true that you don't know how much you miss something until it's gone.
If you're in a configuration-controlled environment, you might not be able to install resource kit tools or third-party tools locally on the production machine. To accommodate this type of situation, you can create a shared folder on your network that contains the tools, then grant the Authenticated Users group read-only access to that folder. You can then simply point to the tools' shared folder in your scripts. As long as your production machine has network connectivity, the scripts can access the shared folder.
Do I need to obtain or purchase a script editor to edit my scripts?
No. I use an editor for my Perl scripts but haven't found a benefit to using it for my command shell scripts. Notepad works fine for editing shell scripts and never inserts additional characters. I especially like Notepad because it's available on every machine I work on. Therefore, I'm not dependent on an editor application if I need to quickly write a short script on another machine. Microsoft Word doesn't work well for writing and editing scripts. Unlike Notepad, Word sometimes inserts unrecognized characters into saved script files.
I have several Windows OSs in my environment. How can I easily test my newly developed scripts across all the OSs?
Consider using a virtual machine (VM) solution such as VMware or Microsoft Virtual PC. I use VMware to host several OSs for script testing. I can use just one physical machine to test scripts on several OSs, which saves money because I don't need a lab full of test machines. In addition, I can recreate OSs quickly or easily add new OSs if necessary.
To prevent your VMs from exposing your network to vulnerability or infection, be sure to update them with the proper hotfixes and anti-virus definitions. Performing this vital step is easy to forget because you might boot into the VMs only periodically.
Scripts are usually backward compatible. That is, scripts that you write for Windows 2003 and XP typically work on earlier OSs such as Windows 2000 and NT. However, always test your scripts to ensure backward compatibility.