Reader to Reader - November 1997

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:

1. Create D:\SMSUtil and copy pcmdump.exe and dumpsend.exe from SMS-CD-ROM\Support\Debug\x86.BIN\. (Replace the x86 with the appropriate platform if your system is not Intel-based.)
2. Add D:\SMS\Site.srv\x86.BIN to the path statement.
3. Create pcmdump batch file (D:\SMSUTIL\PCMD.BAT) with the following contents:
   D:\SMSUtil\PCMDUMP /d %1 > %TEMP%
   \pcmdump.txt
   NOTEPAD %TEMP%\pcmdump.txt
   ERASE %TEMP%\pcmdump.txt
   
4. Create dumpsend batch file (SMS
   UTIL\SENDD.BAT) with the following:
   D:\SMSUtil\DUMPSEND %1 > %TEMP%
   \dumpsend.txt
   NOTEPAD %TEMP%\dumpsend.txt
   ERASE %TEMP%\dumpsend.txt
   
5. Create the shortcuts of pcmd.bat and sendd.bat in the administrator's SendTo folder. (This folder is usually under %systemroot%\Profiles.)
6. Rename the shortcuts to View PCM Instruction File and View Send Request File, respectively.

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.

—Jong Lee, JLee@aris.com

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:

• The pathname
• The user account or group name surrounded by double quotes
• The desired access level

For XCACLS commands, each ACL data file contains four columns of data:

• The pathname
• The user account or group name surrounded by double quotes
• The file and subdirectory settings
• The parent directory permission settings

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.

—Keith T. Hall
kthall@sprintmail.com

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