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