Automating NT Administration with Scripts

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 ScriptListing 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 ScriptListing 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.