Rem - 01 Jan 1999

Do you have a scripting-related question or problem? You can send your question or problem to [email protected].

What scripting language offers the most versatility for writing logon scripts and enterprise administration scripts?

Your choice depends primarily on your environment, what you want the script to do, and what you're comfortable with from a scripting perspective. Scripting languages range from simple command- and shell-based languages, such as Windows NT's command language (batch files) and KornShell, to much more flexible and versatile languages, such as Windows Scripting Host (WSH), Perl, Python, Rexx, Advanced Systems Concepts' XLNT, and FastLane Technologies' FINAL.

WSH or Perl is a good scripting language to learn first, but don't limit yourself to learning only one language. If you know several languages, you can select the tool that best matches the task. For example, Perl isn't a good choice for logon scripts if you don't have a Perl interpreter on the client. Similarly, WSH is notisn't a good tool to use to glue together command-line utilities.

What books or other resources can I use to learn to write batch files, WSH, and Perl scripts?

You can learn about Windows NT's batch files in Tim Hill's Windows NT Shell Scripting (Macmillan Technical Publishing, 1998)., http://www.mcp.com/publishers/macmillan_technical_publishing). To learn about WSH, which uses JScript or Visual Basic Script (VBScript), you can download WSH white papers and language references from Microsoft's scripting Web site at http://msdn.microsoft.com/scripting. You can also find complete JScript and VBScript language references in the Microsoft Visual InterDev 6.0 Web Technologies Reference (Microsoft Press, 1998, http://mspress.microsoft.com). In addition, Microsoft Press is scheduled to release Dan Gookin's WSH book Introducing Windows Scripting Host for Microsoft Windows 98 in December.

You might also want to check out the NT-related scripting Web sites at http://wsh.glazier.co.nz and http://cwashington.netreach.net/home.htm.

In Windows NT Magazine, you can read Keith Pleas' "Windows Scripting Host in Action" (February 1998, or enter instaNT Doc number 3091 at http://www.winntmag.com). To see an example of how to use WSH with Active Directory Service Interfaces (ADSI), check out Bob Wells' Scripting Solutions column, "NT Gains Scripting Muscle" (April 1998, or enter instaNT Doc number 3026).

To learn about Perl, start with Learning Perl on Win32 Systems by Randal L. Schwartz, Erik Olson, and Tom Christiansen (O'Reilly, 1997, http://www.oreilly.com). Then try the Perl Resource Kit - Win32 Edition by Dick Hardt, Erik Olson, David Futato, and Brian Jepson (O'Reilly, 1998). You might also want to look at AEleen Frisch's Essential Windows NT System Administration (O'Reilly, 1998) and Ashley J. Meggitt and Timothy D. Ritchey's Windows NT User Administration (O'Reilly, 1997), which include examples using Perl to automate NT tasks. After you learn a few Perl basics, check out Effective Perl Programming by Joseph Hall and Randal L. Schwartz (Addison Wesley Longman, 1998, http://www.effectiveperl.com).

Where can I get VBScript and Perl?

You can download VBScript from Microsoft's scripting Web site at http://msdn.microsoft.com/scripting. Select VBScript from the navigation menu on the left. On the screen that appears, click Downloads. To download Perl, go to the ActiveState Web site (http://www.activestate.com). Select ActivePerl from the navigation menu on the left. Both downloads are free.

How do I launch VBScript from the command line?

To use VBScript outside of Internet Explorer (IE) or Internet Information Server (IIS), you must install WSH. Then you can run both VBScript (.vbs) or JScript (.js) files from cmd.exe (or click Start, Run) using any of the following notations:

You can also run your script without specifying a specific host. For example, the default script host will run the script if you type either of these two notations:

the default script host will run the script. Following the installation of WSH, the Windows-based host is the default host, but you can change this host to the console-based host by issuing the command

Cc:> wscript //H:cscript

In all of these scenarios, the host simply passes your script to the appropriate scripting language engine (e.g., jscript.dll, vbscript.dll). The wscript and cscript hosts determine the appropriate script engine based on the script extension, which the script engine registers in the HKEY_CLASSES_ROOT Registry hive.

Does the Wscript.Quit method in WSH pass return code back to the command line? If so, how do I access the return code from a variable?

You can't run your script from the Windows-based host (wscript.exe), because wscript.exe doesn't set ERRORLEVEL. (ERRORLEVEL is a special console-based environment variable that contains the return code of the command you most recently ran.) Instead, you must run your script from the console-based host (cscript.exe). To test whether ERRORLEVEL is working, follow these steps:

You can change the default host to cscript.exe by issuing the command

c:>wscript //H:CScript

How do I obtain the username, operating system (OS) type, and machine name when I'm running an NT logon script (.bat file)?

You can use NT's environment variables USERNAME, OS, and COMPUTERNAME. To access the value of an environment variable within a batch file, simply enclose the environment variable name inside percent signs. For example, you put %USERNAME% to obtain the username, %OS% to obtain the OS type, and %COMPUTERNAME% to obtain the machine name.

How do I write a script that first identifies all the shares on a server and then lists share-level permission and NTFS permissions?

This scripting project is interesting because NT handles share-level permissions and NTFS file and directory permissions differently. NT maintains share-level permissions in the Registry under HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesLanmanServerShares. NT maintains file and directory permissions in the file system. Thus, you need to initially separate the project into three tasks: listing NTFS permissions, listing shares, and listing share permissions.

Of the three tasks, listing NTFS permissions is the easiest. Many tools are available to accomplish this task, such as NT's cacls.exe command-line utility, showacls.exe in the Microsoft Windows NT Server Resource Kit, and ActivePerl's FileSecurity module. Obtaining the list of shares is also relatively simple via the Registry key HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesLanmanServerSharesI just mentioned.

Obtaining a list of share permissions is the most difficult task. VBScript's FileSystemObject and the ADSI FileShare Object don't support setting or retrieving share-level permissions. One possibility is usingsolution is to use ActivePerl's NetResource module. This module supports all aspects of working with shares, including permissions. This course of action is the best, most comprehensive, leastlowest-cost solution. You already likely have the NT Server Resource resource Kitkit, and you can download ActivePerl free from ActiveState's Tool's Web site. at http://www.activestate.com. The download includes HTML documentation that has FileSecurity and NetResource examples. If you don't mind purchasing a third-party solution, both Advanced Systems Concepts' XLNT 2.0 (http://www.advsyscon.com) and FastLane Technologies' FINAL 6.2 (http://www.fastlanetech.com) provide the functionality required for your scripting project.

Do any Perl scripts automate various NT processes, such as archiving event logs?

Philippe Le Berre's PerlRing Web site has a code snippet of the Win32::EventLog Clear function that you can easily modify to address your needs. Go to http://www.inforoute.cgs.fr/leberre1/index.html, and select A 'How To' Guide to Win32::Packages. This Web site also has links to a variety of script archives. You can access the links by clicking More Links on Perl for Win32.

In addition, you might want to subscribe to one of ActiveState's Tool's Perl for Win32 mailing lists (http://www.activestate.com/support/mailing_lists.htm). Try the Perl-Win32-Admin, Perl-Win32-Announce, and Perl-Win32-Users lists because they frequently discuss topics of this nature.

In one domain, I have about 3000 users who run NT 4.0, Service Pack 3 (SP3). Most of these users are power users, not local administrators. Because of an error during NT deployment, I have no easy way to record who is a local administrator. I currently use the NET LOCALGROUP command to obtain this information and then pipe it into a file. However, I end up with 3000 files, each of which needs editing to determine relevance. Although I use ifmember.exe to determine whether the user is a member of the administrator group, I still get hundreds of files.

I want to write a Perl script that first determines whether a user is a local administrator and then searches an existing file on a server to see whether the file contains that administrator's username and machine name. If the file already lists this administrator, the scripts exits; if not, the script appends the file to include the username and machine name. I want to write a Perl script that first determines whether a user is a local administrator and then searches an existing file on a server to see whether the file contains that administrator's username and machine name. If the file doesn't contain this information, the script appends the file to include the username and machine name. However, I haven't loaded Perl on all the NT workstations. I want to avoid the tedium of installing Perl on all 3000 clients. What is the best approach?

Although installing Perl on 3000 clients might seem like a daunting task, it's relatively painless. You just need to copy the distribution list and update the path. If you still want to avoid installing Perl, you can use Mercury Systems' Perl2Exe utility (http://www.demobuilder.com), which packages Perl scripts into standalone executables. The utility combines a script, the Perl interpreter, and any external modules into one .exe package. The only caveat is that the resulting .exe file is about 700KB because of the embedded Perl interpreter. If the size isn't a problem, you can repackage your script into an .exe file that clients can run without having Perl installed on the machine.

An alternative is to work with the 3000 files that NET LOCALGROUP generates. Continue using ifmember.exe, but use a unique name to redirect its output to a local file on the client. Have the same batch file or logon script copy, or move the local file to a central share on the network. After you collect all the files, write a script to parse and munge them. If you need to take action on the client based on the results, you can create a dummy domain-based group, add the user accounts for which you need to take action, and use ifmember.exe a second time to test for dummy group membership. If the user is a member, you can arrange for a different action to take place.