At Windows NT Magazine's Professionals Conference 98 in Orlando, Florida, I learned about an interesting Windows NT command and scripting environment. Advanced Systems Concepts, Inc. (ASCI) has developed eXtended Language for Windows NT (XLNT) 1.1, which consists of three components: a shell or command processor, a collection of XLNT-based commands, and a scripting language.
XLNT is similar to the popular UNIX-like toolkits for NT, except that XLNT's roots are in Digital Equipment's OpenVMS. As a result, XLNT's command syntax and scripting language look and feel like Digital Command Language (DCL). XLNT supports NT 3.51 or later and Windows 95.
What I find most interesting about the software is its collection of commands. I'm not talking about simple ports of useful VMS commands, but full-featured utilities that outperform many of NT's built-in and resource kit utilities. For example, XLNT's SECURITY command provides almost every option available in User Manager for Domains. This option-packed command and XLNT's robust scripting language make this software a potentially powerful NT automation environment. Let's take a closer look at XLNT's SECURITY command and how you can use it in an XLNT script.
Understanding the SECURITY Command
You use the SECURITY command to control and maintain NT users, groups, and policies. The command supports four modes of operation: CREATE, DELETE, MODIFY, and SHOW. The SECURITY command accepts additional arguments, or qualifiers, based on the mode in which you use the command. Table 1, page 216, lists the SECURITY command's modes and associated qualifiers.
The SECURITY command provides a rich set of user management capabilities. For example, with one command, you can create a user account, set its properties, and specify all the groups the user is to be a member of with the /GLOBAL and /LOCAL qualifiers. You can also use the /RIGHTS qualifier to specify any special user rights the account needs. The SECURITY command supports remote domains with the /DOMAIN\[=domain-name\] switch, a feature missing from NT's NET USER command.
Screen 1, page 216, shows an XLNT session that I invoked with the SECURITY CREATE USER command. I executed this XLNT command from the XLNT shell, or console, which XLNT refers to as local interactive mode. You can also use two other methods: a Telnet-like facility that supports remote console interaction or NT's native command processor, cmd.exe, to invoke an XLNT command. To invoke a command, you preface it with XLNT. For example, typing the SECURITY CREATE USER command
c:\> xlnt security create user ...
at the NT command prompt invokes the XLNT command processor and gives the processor the SECURITY CREATE USER command. The directory containing the xlnt.exe command processor (C:\asci\xlnt, by default) must be in your path environment variable.
If you dissect the SECURITY CREATE USER command in Screen 1, you will see how XLNT works. XLNT creates a global user account, "tmtowtdi," in the LAB domain and configures standard user account properties (e.g., full name, description of the user, password, home directory, user profile path, and logon script name). XLNT uses the /PASSWORD_ EXPIRES qualifier to set the User Must Change Password at Next Logon flag. Next, XLNT explicitly grants the user account the right to back up files and directories. Finally, XLNT adds the account to the Users and Administrators local groups and to the Domain Admins global group. (These groups are in addition to the default global group, Domain Users.)
In the command in Screen 1, many strings are in quotes. By default, XLNT converts all strings to uppercase. To inhibit this behavior, you must enclose strings in quotes. For example, if you don't put quotes around zpx1ba in the /PASSWORD= qualifier, XLNT would assign ZPX1BA as the user's password.
Screen 2 shows the results (including the updated User Rights Policy) of executing the SECURITY CREATE USER command in Screen 1. Although effective, this command has one limitation. The /HOME_DIRECTORY= qualifier doesn't let you specify drive letters for server-based home directories. In all my tests, the qualifier automatically assigned Z as the drive letter. ASCI states that it will correct this problem in version 2.0, which the company plans to release mid-1998.
Using the Command in an XLNT Script
Now that you understand the SECURITY command's capabilities, let's look at how you can use it in an XLNT script. Listing 1 contains addusers.xcp, a simple XLNT script that creates NT user accounts in batch mode based on the comma-delimited input file, users.txt, in Listing 2. Addusers.xcp is an adaptation of a similar script available on ASCI's Web site (http://www.advsyscon.com). You can find several sample administration scripts and utilities in ASCI's online software library.
Before you use the SECURITY command in an XLNT script, you need to know a few script basics. XLNT scripts (ASCI refers to these scripts as command procedures) are a collection of XLNT statements, commands, and functions that you group and submit interactively or in batch. You can create XLNT scripts with your favorite text editor and save them with an .xcp extension. You must begin each line in a script with a dollar sign character ($). You preface any comments with the exclamation character (!), as the first line of the script in Listing 1 shows. To submit or run a script, you preface the script name with the @ character at the XLNT prompt. For example, to run addusers.xcp, you would type
$ @addusers.xcp
Now let's examine addusers.xcp. This script begins by using XLNT's OPEN command to open the users.txt file. The OPEN command requires at least two qualifiers: the file-symbol and the filename. By default, XLNT opens files with read-only permission. If the OPEN function succeeds, XLNT returns a handle to the file in the file-symbol; in Listing 1, the file-symbol is inputfile.
The script contains a primary outer loop at callout A in Listing 1. In this loop, XLNT reads a line from the input file, extracts the user data, creates the user account, adds the account to the groups defined in the input file, and then begins again.
The READ command fetches a line from the input file. Like the OPEN command, the READ command requires at least two qualifiers. The first qualifier is the file-symbol previously obtained with the OPEN command (i.e., inputfile). The second qualifier is the symbol-name that XLNT will associate with the data that it reads; in Listing 1, this symbol-name is line. The READ command fetches a line at a time by default. The READ command in this script also contains the /end_of_file=END qualifier. When the READ command reaches the end of file (EOF) marker in the file, this qualifier instructs the READ command to go to the END: label.
The code at B uses XLNT's F$ELEMENT lexical command five times to extract the individual data fields from the line read from the users.txt input file. Lexical commands are functions that return values. The F$ELEMENT lexical command requires three qualifiers: the element number to retrieve, the character used as the delimiter, and the source string. If successful, this command returns the specified element as a string.
The SECURITY CREATE USER command uses the variables, or symbols, that store the individual data fields. Notice that two apostrophes precede the quoted symbols, but a single apostrophe follows the quoted symbols. This setup forces symbol substitution within the quoted character strings.
The code at C forms the inner loop. In this loop, the script adds newly created users to the groups obtained from the users.txt input file. (The script extracted this field in the last line of the code at B and stored the information in the symbol groups. As Listing 2 shows, the users.txt input file includes multiple groups, separated by vertical bars.)
Before entering the inner loop, the script sets a control symbol, x, to 0. The script then uses x and the F$ELEMENT lexical command to extract a group and assign it to the symbol tmpgrp. If the F$ELEMENT lexical command returns something other than a vertical bar, the script invokes the SECURITY command again, but this time it uses MODIFY mode with the entity-type GROUP and the values that tmpgrp and user represent. The script repeats the process for any additional groups. When no more groups exist, the inner loop ends and the script proceeds to the next line in the input file. This cycle continues until the READ command encounters the EOF marker, which tells the READ command to go to the END: label, close inputfile, and exit.
In addition to the commands discussed in this example, XLNT includes commands to manage file systems, access control lists (ACLs), shares, scheduler, and services. XLNT's SHOW command provides a wide variety of system information, such as devices, memory, processes, and sessions. XLNT also has additional lexical commands that provide access to the NT Registry and event logs.
Getting XLNT Might Make Sense
If you have DCL experience and you're migrating from VMS to NT or integrating NT into a VMS environment, choosing XLNT is a no brainer. If you're looking for a way to extend NT's command line with a powerful set of utilities and a scripting language to boot, XLNT might be worth a look. Version 2.0 will include support for Windows Scripting Host (WSH), an integrated development environment, and native URL support. You can download an evaluation copy of XLNT 1.1 from ASCI's Web site. An evaluation copy of XLNT 2.0 will also be available when ASCI releases this version.
