Systems administrators' lives just got easier--thanks to improved scripting languages for Windows NT
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.