Microsoft

Windows shell scripting can expedite network admin tasks

Windows has a basic built-in command structure you can use to create useful scripts that streamline various administrative processes. Find out how to get started harnessing the power of Windows shell scripts.


Some of the more common Windows scripting languages and platforms include Windows shell scripting, Visual Basic Scripting (VBS), and JScript, as I discussed in a previous article. Now we're going to take an in-depth look at Windows shell scripting as it relates to network administration. For the purposes of this discussion, I’m going to assume that you understand the basics of using the Windows command line, including the use of parameters and switches, such as the following:
del  myfile.txt /f

Here, "del" is the command, "myfile.txt" is the parameter (which provides required information to the del command—in this case, which file to delete), and "/f" is the switch, which modifies the behavior of the command so that it forces the deleting of read-only files.

Logon scripts
Probably the most common use for shell scripting is logon scripts. A logon script is used to configure the Windows environment for a user at the time of logon and is usually specific to a group of users. For instance, members of the Finance group may automatically map network drives to the finance network share folder, while the Marketing group may automatically map their network drives to the marketing network share.

To make this work, a script is created for each user or group of users and then copied to the appropriate server location (based on the version of Windows). In Windows NT, the script file is normally placed in C:\Winnt\System 32\Repl\Export\Scripts (or Import, depending on how you have configured replication). You then point to that file in the User Account Properties dialog box.

When using Active Directory, you deploy the logon script via a Group Policy. First, copy the script file to the Sysvol subfolder. Figure A shows where to access this subfolder.

Figure A
Finding the Scripts folders in Sysvol


Note that you also have the choice of scripts for logoff, startup, and shutdown. You can then directly edit the Group Policy object for a given container to include that script, as shown in Figure B.

Figure B
Edit the script in a specific container in Active Directory.


Commands in logon scripts
One of the most useful commands to use in a logon script is NET USE. It's just one subset of many available NET commands.

The NET USE command allows you to establish drive mappings. When used in a logon script, it can tailor the drive mapping to a specific user or group of users. For instance, let’s say that the marketing department requires a drive mapping to the marketing folder on Server3, another drive mapping to the admin folder on Server2, and another drive mapping to the individual user’s home folder found in the "home folder" share on Server1. Here is an example of how you would script that:
NET USE F: \\server3\marketing PERSIST:NO
NET USE G: \\server2\admin PERSIST:NO
NET USE H: "\\server1\home folder\%username%" PERSIST:NO

The keyword PERSIST at the end of each line addresses whether to reconnect the drive mapping at the next startup. Most often, you do not want this to happen because another user may require different drive mappings.

You also should note a couple of things in the third line of code. First, there are quotation marks around the path. This is required because there is a space within the pathname. Second, I used the environmental variable %username%. When a user logs on, that username is stored temporarily in the registry and is available within the Windows shell. (To verify this, type echo %username% at the command line and you should see your own logon name provided as output.) If each user has a folder that is named the same as that person's logon name, you can use that to automatically map a drive to the home folder.

The %username% variable is one of several environment variables that are created automatically by Windows and that can be used similarly in your scripts. To see a complete list, you can type set at the command prompt. You can also create your own variables with this command. To find out how, type set /? at the command prompt.

Windows commands
To see a complete list of the commands and information on how to use them, refer to Windows Help. If you are using Windows 2000, click on Start | Help. In the Search tab, type command reference. Under Select Topic To Display, double-click on Command Reference Main Page. In Windows NT, click on Start | Help and type command in the Find tab. Then, under Pick A Topic, select Commands Index and click the Display button.

Another useful logon script command is NET TIME, which is used to synchronize time on a network to a time server. You can use a number of switches with this command. Again, you can check the command reference in Windows Help. The simplest use of NET TIME might look something like this:
NET TIME \\timesvr8 /SET /YES

This tells the computer to synchronize its time with that on the server named timesvr8. The /YES switch tells it to force the synchronization even if the named server is not a time source server.

In a future article, I will discuss certain programming constructs you will find useful in scripting, including conditional processing. Here's a look at one form of conditional processing.

Administrators in Novell NetWare have long appreciated the ability to tell the logon script to do something if the user is a member of a certain group by using the statement IF MEMBER OF. Although no such statement is available in Windows scripting, there are two possible workarounds, depending on whether you are administering a Windows NT domain or a Windows 2000 domain with Active Directory.

The Windows NT Resource Kit includes a utility named IFMEMBER.EXE, which can be used for the same purpose as the NetWare IF MEMBER OF. Unfortunately, its use is rather convoluted, requiring yet another construct called ERRORLEVEL. Here’s how it works. Lets say that if the user logging on is a member of the both the Marketing group and the Managers group, you want to map a drive to a share that only marketing managers have access to. First, you would include the line:
IFMEMBER marketing managers

The IFMEMBER utility, assuming that it is in a search path, will check for membership in all groups listed and then exit and store the number of groups the user is a member of in a special variable called ERRORLEVEL. In this case, that number should be 2. So the entire process would look like this:
IFMEMBER marketing managers
IF NOT ERRORLEVEL 2 EXIT
NET USE J: \\SERVER4\MKTGMGR  /PERSIST: NO 

If the user is a member of both groups, the value stored in ERRORLEVEL will be 2. If the value is not 2, the script will end. But if the value is 2, it will execute the next statement.

The IFMEMBER.EXE utility may also be used in a Windows 2000 domain, but if you are using Active Directory, you have another option. Rather than reference groups in logon scripts, you can design your Organizational Units along the same lines as those groups. That way, you can create Group Policy Objects linked to each OU, with a specific logon script for that OU, without having to use the IFMEMBER utility.

Using shell scripting for other purposes
As I mentioned, a logon script is designed to be invoked every time a user logs on to the network. There are times, however, when you will find that a script can be useful even if it is used only once. For example, suppose that your organization has just completed work on a Geographic Information System (GIS) that displays maps. Any GIS involves a large number of “shape” files and images, often in a complex directory structure. They will run best if installed locally on the workstation, so you decide that you want to copy these files, with directory structures intact, from a network share to the local hard drive of each workstation.

You could, of course, sit down at each computer, open the command prompt, and manually type each line one at time. But obviously, it would greatly simplify things to write one script that contains every command that must be issued, each on its own line, and simply run that script at each workstation.

Using the COPY command or the more versatile XCOPY command, you could create a script that would accomplish the job, copy it to a removable medium such as a floppy disk, and run the script at each station by typing a single command. The advantages are twofold:
  • It will save you time, since you don’t have to type every command at every workstation.
  • It will help prevent the inevitable errors caused by mistyping a command or a pathname.

Best practices
When you write Windows shell scripts, you should keep these best practices in mind:
  • Always test your scripts before you use them in a production environment.
  • Always document your scripts, even if they appear very simple. When a script encounters the keyword REM (for "remark"), it will ignore that entire line. You can therefore use that keyword to add remarks to your script for documentation. At the very least, you should include the purpose of the script, with the date and the name of the person who created it. Remember that what may seem obvious to you at the time may not be obvious to someone else. For that matter, it may not even be obvious to you a year from now.
  • Remember that each command line in your script will be displayed onscreen when it is run, unless you turn that feature off with the command @ECHO OFF.

Moving on
To really become proficient at creating Windows shell scripts, you need to understand the available commands and their syntax. Study the command reference in Windows Help. Take a look at each command and see which ones might help you accomplish the tasks you need done. Each command has a Related Topics link. Most of those include two additional useful links: one that provides examples of that command in use and one that has further notes on the command.

In addition, you should practice and try out various commands and options as much as possible until you become proficient. Don’t be afraid to make mistakes (provided you are practicing in a test environment). That's the best way to learn about the variables involved in this process.

Editor's Picks

Free Newsletters, In your Inbox