Picture this: You're a Windows NT systems administrator, and you want to change the home directory path for a couple hundred users in a Security Accounts Manager (SAM) database. The database contains thousands of user accounts. If you work on a similar problem in a UNIX environment and the system doesn't have an adequate tool for the task, you'll probably write a custom tool in a scripting language. In UNIX shops, administrators have long used task-oriented languages such as the UNIX Shell (sh), Practical Extraction and Report Language (Perl), and Tool Command Language/Tool Kit (Tcl/Tk) to carry out enterprisewide operations.
In an NT environment, however, administrators have had fewer options. Until recently, crude batch files provided the only practical way for administrators to automate tasks; you could view the process as using NT's functionally challenged command language to glue together feature-inhibited command-line tools.
The introduction of GUI management tools for administering systems improved the situation. But for tasks such as the one I described at the beginning of this article, GUI management tools such as User Manager for Domains often break down very quickly. If the GUI doesn't offer an appropriate tool, you have to purchase a third-party product or use the Win32 API to develop the tool. And the latter option isn't a walk in the park.
Although GUI tools make small tasks less intimidating for new systems administrators, the tools don't work well for enterprise and batch-oriented tasks. For example, retrieving a specific Registry value from hundreds of servers is not a trivial undertaking. And searching an event log for a specific security event on hundreds or even dozens of servers can take days.
GUIs also have a subtle shortcoming: They rely on human interaction. I hate to be the bearer of bad news, but to believe that you can repeatedly complete many dialogs without error isn't realistic. The result of human error is costly rework. Thus, as NT becomes more prominent in enterprise networks, administrators must find smarter ways to work. Scripts are one solution.
Scripts Defined
A command-line script is a series of commands in a text file. The name of the text file tells the operating system that the file is executable. For example, if the filename is myscript.bat, the .bat extension tells NT to execute the contents of myscript.bat sequentially. The system component that interprets and executes the batch file is the NT command interpreter (cmd.exe).
Scripting languages extend scripting capabilities by providing additional language constructs such as variables, conditional statements, and functions. Scripting languages include an interpreter. For example, Perl for Win32's interpreter is perl.exe. A Perl script typically has a .pl extension. To invoke a Perl script, you pass it to the Perl interpreter using a command similar to
c:\>perl myscript.pl
The Perl interpreter interprets and executes the contents of myscript.pl. Of course, myscript.pl must contain valid Perl statements.
Scripting languages complement system programming languages such as C, C++, and Java because they glue together utility programs to automate solutions to specific problems. For example, ActiveWare Internet Corporation developed Perl for Win32 to fill the need for a strong scripting language on the Windows 95 and NT platforms. Perl has become the de facto scripting language for UNIX systems administration and a widely used Web Common Gateway Interface (CGI) development language.
Many good scripting languages are now available for NT. These utility languages offer features ranging from enhanced logon script processing to complete enterprise systems administration. The sidebar "Scripting Languages for NT," page 187, suggests some criteria to consider when you select a package and lists some scripting languages for the NT platform.
To illustrate how scripting makes life easier, I'll show you how to perform a task using a command-line script (batch file) and scripts written in two powerful NT scripting languages: Perl for Win32 5.0, Build 310 (ActiveState Tool, formerly ActiveWare Internet) and Final for NT Server 6.01 (FastLane Technologies).
The Command-Line Script
Listing 1 is a simple script that uses the NT command line to retrieve a Registry value from multiple servers and print the results to a file. The script in Listing 1 requires the Registry key and the Registry value as command-line arguments. It also depends on the regread.exe utility on the Microsoft Windows NT Server Resource Kit CD-ROM. Notice that I include the target server names (server1, server2, server3) in the batch file so that I can retrieve Registry information from several servers with one command. When I run the script, it produces an output file, getregval.txt, which contains the results. Screen 1, page 183, shows the output file for this script.
This script is useful but limited. For instance, you must edit the script every time you want to add a new server. If you have several scripts that work similarly, you must update all of them. A more efficient tactic is to maintain a list of servers in a text file and input the text file. Perhaps you also want to improve the script's output format. Unfortunately, you can't make either enhancement using NT's batch language.
The Perl Script
Let's rewrite the batch file in Listing 1 to demonstrate Perl's capabilities. First, you need to install Perl for Win32 on your workstation. Download pw32i310.exe from the ActiveState Tool Web site (http://www.activestate.com). Place this self-extracting file into the Perl installation directory (e.g., c:\Perl), and invoke pw32i310.exe to fire up the installation.
At A in Listing 2, page 184, the script declares three variables: $RegKey, $RegValue, and @Servers. $RegKey holds the Registry key, $RegValue holds the Registry value, and @Servers is an array that holds the list of servers.
The script then prompts the user for the key and value, and stores the user's input in $RegKey and $RegValue. The chop function is a Perl function that removes the last character from a string. In Listing 1, chop removes the new line character that results from the user pressing the Enter key after typing the Registry key and value.
At B in Listing 2, the script opens the file that contains the list of servers and reads the list into the @Servers array. In this example, the script expects the servers.txt input file to be an ASCII file with one server name per line.
Next, the script opens the getregval.txt output file and writes some header information into it. At C in Listing 2, page 185, the script loops through the @Servers array, calling the Perl for Win32 Registry functions to connect to the Registry, retrieve the Registry value, and write the returned value to the output file. Screen 2, page 183, displays the executing script and the contents of the output file.
Unlike with the command-line script, you don't have to edit the Perl script to support additional servers. You simply add them to the servers.txt input file. In this example, I also enhanced the output file format to make it more readable.
The Final Script
Listing 3, page 185, presents the Final version of the Registry script. Before you can run the script, you must install Final for NT Server on your workstation. A Final source file has an .fc extension, which you must compile to an .fbi file before you execute it. I compiled this script in the Final IDE, and then passed it to the Final runtime using the command line
c:\>finalrun getregval.fbi
Final can also generate standalone executable files, but you must buy this feature as an add-on product option.
The Final script differs from the Perl script primarily in that Final offers a GUI. Perl for Win32 has no GUI support today, although ActiveState Tool is working on a GUI. However, you can use an HTML form and a browser as an alternative interface for the Perl script. Screen 3, page 183, shows the opening dialog box in the Final script.
Scripting Power
To get an idea of just how powerful some of these scripting languages are, browse the function libraries that come with the software. I'm sure you'll find that you can offload to a script some of the day-to-day tasks listed in Figure 1.
To obtain demonstration copies of the scripting tools mentioned in the sidebar "Scripting Languages for NT," browse the companies' Web sites. Most sites include example programs to get you up to speed quickly. FastLane's Final includes an example script for each of the NT functions it supports.
Scripting will continue to evolve. You must look no further than Microsoft's recent scripting initiatives to see that scripts can play an important role in enterprise systems management. So try your hand at automating your work with scripts--you might surprise yourself!
You can download the listings in this article from the magazine's Web site, http://www.winntmag.com.
| Figure 1: Example Tasks for Scripting |
| Managing access control list (ACL) Configuring applications Auditing systems and reporting audits Managing files and shares Managing OS patches and upgrades Managing the registry Automating repetitive tasks Configuring servers Controlling and configuring services Tracking system availability Adding, changing, and deleting users |
