\[Editor's note: Share your NT discoveries, comments, experiences with products, problems, and solutions and reach out to other Windows NT Magazine readers (including Microsoft). Email your contributions (under 400 words) to Karen Forster at karen@winntmag.com. Please include your phone number. We will edit submissions for style, grammar, and length. If we print your letter, you'll get $100.\]
I use the command prompt for many admin tasks in NT. However, instead of opening a prompt and repeatedly using the CD command, I use the SendTo folder to open the command prompt to the same directory as a given Explorer folder.
Create a batch file (.bat or .cmd extension), such as newcmd.cmd in your Winnt folder (or another folder in the path), with the following contents:
@echo off
prompt $p$s$+$m$s$g
color 0a
title "CMD Started at %1 from batch %0"
start /D%1 /B
Right-click Start and choose Explore to open your profile folder. Find and open the SendTo folder. Create a shortcut to the newcmd.cmd batch file in the SendTo folder. You can test this batch file by opening Explorer, right-clicking any folder, and choosing NEWCMD in the SendTo menu.
The START command's /B switch inherits the environment from the prompt, color, and title commands in the batch file. START generates a command prompt by default if you don't specify another .exe to run, opening the new command in the directory that the /D switch identifies. The /D switch gets its path from the first argument you enter after the batch file name--in this case, the folder piped in when you select from the SendTo menu.
Note that the START command has a switch to set the title of any new command prompt. But if you want to inherit the environment from the starting batch file, you must set the title before the start command, as shown in the example.
Someone at Microsoft must be listening, because NT 4.0's cmd.exe is greatly improved over previous versions. Enter
/?
at the prompt to get more information about commands such as FOR, PROMPT,
IF, CALL, COLOR, and TITLE.
Make SMS Utilities More Administrator Friendly
Systems Management Server's (SMS's) CD-ROM has two command-line utilities
that can help administrators troubleshoot package distribution and send status.
The first utility, pcmdump.exe, lets administrators view the instruction file
(.ins) in the site server (SMS\SITE.SRV\MAINCFG.BOX\PCMDOM.BOX\domain.000\smsid.INS)
and in the logon server (SMS\LOGON.SRV\PCMINS.BOX\smsid.INS). The second utility,
dumpsend.exe, lets administrators view the
send request and status file in the site server (SMS\SITE.SRV\SENDER.BOX\REQUEST\sender.000\*.SRQ
and *.SRS).
As you can see from the utilities' paths, you must type a lot of characters to get these files. Hypothetically, if you type slowly enough, a file can disappear before you get to the directory because the system dynamically modifies files. In addition, the command's output usually fills more than one screen, so you need to modify the property of the command prompt and scroll back and forth.
You can use the old-but-still-useful batch file technique to make these files easier to retrieve. Using drive D as the installation path for SMS and the utilities, follow these steps:
Once you create these shortcuts, here's how to use them. To view .ins, .srq, or .srs, open NT Explorer, go to the appropriate directory, and right-click the desired file. From the Shortcut Menu, click SendTo and select the appropriate item (View PCM Instruction File for .ins files or View Send Request File for .srq or .srs files) to view the file.
This procedure will create a file in the temporary directory. Use Notepad to open the file. When you are finished viewing the temporary file, close Notepad to erase it.
One drawback exists when you use these shortcuts, however. Because the batch file creates a temporary file and then removes it when you close Notepad, you can view only one file type at a time.
Modify Directory and File Permissions with
Scripts
The script in Richard Tengdin's "More on Creating User Accounts"
(Reader to Reader, December 1996) came in handy during a recent project. I
needed to create a generic, universal script that users could easily run without extensive Windows NT training. Because of contract requirements, I also needed precise permissions set on specified directories and files to meet C2 compliance requirements. Specifically, I needed a script to modify file and directory permissions from a text file source.
To meet these needs, I wrote a script that reads one or more input files, combines the directory and file structure within the data, sorts the data, and executes the desired permission set. Users can run this script by inserting a floppy in their machine or by accessing it via the network as long as they have administrator rights. The script replaces access control lists (ACLs) with specified permissions.
I wrote this script by first deciding which command to use. You can set up scripts to use either the CACLS or XCACLS command to perform batch job directory or file ACL changes. The CACLS command comes with NT 3.51 and NT 4.0, and the XCACLS command comes with the NT 4.0 Resource Kit Supplement 1 CD-ROM. I set up my script to use XCACLS because that command offers a greater variety of permission settings.
Next, I determined which permissions to change and specified all desired user rights (which is important because the specified permissions replace the ACLs). My script changed permissions for either directories (pathname only) or the first level of files and subdirectories (pathname and *.*).
But you have many other options. For example, the -T option changes permissions on all subdirectories and file levels under the parent directory, the -P option replaces access rights, and the -G option grants specific user rights. (For a full list of options, you can access the Help screen accompanying the CACLS or XCACLS command by running the command from the system prompt without any options.)
Listings 1 through 4 contain the script I created. Listings 1 and 2 contain sample ACL data files. Multiple data files can exist for different machine configurations. For example, all machines might have a common.acl file for default permission sets that all servers and workstations share, and a Primary Domain Controller (PDC) might have a pdc.acl file to configure special directories of software not found on the clients. (You can store this information in an Excel spreadsheet and convert the data for use in a particular deployment configuration.)
For CACLS commands, each ACL data file contains three columns of data:
For XCACLS commands, each ACL data file contains four columns of data:
XCALCS's permission standards are usually R (read), C (change), and F (full), but you can also specify special permissions and differentiation between file and directory permission settings. For example, the TR setting in Listing 2 (page 42) gives the parent directory a List permission and the subordinate files a Read permission.
Listing 3 (page 42) is a batch file to combine the files into an acl.lst file. You can also use the batch file to mix functions. Separating the ACL files in the batch file and applying modified acl.pl files lets you use one command to on one set of pathnames and inclusive permission changes on another set. This procedure also works well when you need to make permission changes on single files.
Listing 4 (page 42) contains the Perl source code. Perl is not elegant, but it works. The first section of code merely combines all the input files into a single data source. The second section parses the data into two arrays and ensures that only one command executes for each pathname, by combining duplicate pathname permission sets. The third section executes the command by running through the stored array information.
If you use a CACLS command, you need to add an answer file (answer.dat) as an input file. This file, which contains a "y" followed by a carriage return, ensures the confirmation for the command execution does not halt the continuous execution of the script.
This script is one of many ways to modify directory and file permissions. So be creative and ad lib this script or develop a new one.
The complete source and executable code is available for downloading from Windows NT Magazine's Web site at http://www.winntmag.com.