Reader to Reader - November 1997

[Editor's note: Share your NT discoveries, comments, experiences withproducts, problems, and solutions and reach out to other Windows NT Magazine readers (including Microsoft). Email your contributions (under 400 words) to Karen Forster at [email protected]. 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 ofopening a prompt and repeatedly using the CD command, I use the SendTo folder toopen 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 yourWinnt folder (or another folder in the path), with the following contents:

Right-click Start and choose Explore to open your profile folder. Find andopen the SendTo folder. Create a shortcut to the newcmd.cmd batch file in theSendTo folder. You can test this batch file by opening Explorer, right-clickingany 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 bydefault if you don't specify another .exe to run, opening the new command in thedirectory that the /D switch identifies. The /D switch gets its path from thefirst argument you enter after the batch file name--in this case, the folderpiped in when you select from the SendTo menu.

Note that the START command has a switch to set the title of any newcommand prompt. But if you want to inherit the environment from the startingbatch file, you must set the title before the start command, as shown in theexample.

Someone at Microsoft must be listening, because NT 4.0's cmd.exe is greatlyimproved over previous versions. Enter

at the prompt to get more information about commands such as FOR, PROMPT,
IF, CALL, COLOR, and TITLE.

—Rick Cogley, [email protected]

Make SMS Utilities More Administrator Friendly
Systems Management Server's (SMS's) CD-ROM has two command-line utilitiesthat 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 (SMSSITE.SRVMAINCFG.BOXPCMDOM.BOXdomain.000smsid.INS)and in the logon server (SMSLOGON.SRVPCMINS.BOXsmsid.INS). The second utility,dumpsend.exe, lets administrators view thesend request and status file in the site server (SMSSITE.SRVSENDER.BOXREQUESTsender.000*.SRQand *.SRS).

As you can see from the utilities' paths, you must type a lot of charactersto get these files. Hypothetically, if you type slowly enough, a file candisappear before you get to the directory because the system dynamicallymodifies files. In addition, the command's output usually fills more than onescreen, so you need to modify the property of the command prompt and scroll backand forth.

You can use the old-but-still-useful batch file technique to make thesefiles easier to retrieve. Using drive D as the installation path for SMS and theutilities, 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, andright-click the desired file. From the Shortcut Menu, click SendTo and selectthe appropriate item (View PCM Instruction File for .ins files or View SendRequest File for .srq or .srs files) to view the file.

This procedure will create a file in the temporary directory. Use Notepadto open the file. When you are finished viewing the temporary file, closeNotepad to erase it.

One drawback exists when you use these shortcuts, however. Because thebatch file creates a temporary file and then removes it when you close Notepad,you can view only one file type at a time.

—Jong Lee, [email protected]

Modify Directory and File Permissions withScripts
The script in Richard Tengdin's "More on Creating User Accounts"(Reader to Reader, December 1996) came in handy during a recent project. Ineeded 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 desireduser rights (which is important because the specified permissions replace theACLs). My script changed permissions for either directories (pathname only) orthe first level of files and subdirectories (pathname and *.*).

But you have many other options. For example, the -T option changespermissions on all subdirectories and file levels under the parent directory,the -P option replaces access rights, and the -G option grants specific userrights. (For a full list of options, you can access the Help screen accompanyingthe CACLS or XCACLS command by running the command from the system promptwithout any options.)

Listings 1 through 4 contain the script I created. Listings 1 and 2 containsample ACL data files. Multiple data files can exist for different machineconfigurations. For example, all machines might have a common.acl file fordefault permission sets that all servers and workstations share, and a PrimaryDomain Controller (PDC) might have a pdc.acl file to configure specialdirectories of software not found on the clients. (You can store thisinformation in an Excel spreadsheet and convert the data for use in a particulardeployment 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 runningthrough the stored array information.

If you use a CACLS command, you need to add an answer file (answer.dat) asan input file. This file, which contains a "y" followed by a carriagereturn, ensures the confirmation for the command execution does not halt thecontinuous 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.

—Keith T. Hall
[email protected]

The complete source and executable code is available for downloading from Windows NT Magazine's Web site at http://www.winntmag.com.