More Power (Toys) to You Rick Cogley's November 1997 Reader to Reader tip, "Open a CMD View of Explorer Folders," discussed how to use the Send To menu to open a CMD prompt in a current directory of Windows NT Explorer. Although his solution works, I know of a more efficient method.

Shortly after the release of Windows 95, the Windows Shell Development Team developed PowerToys, a series of programs that enhance the functionality of the Win95 shell. These programs offer a few bells and whistles that the official release of Win95 left out.

Although Microsoft doesn't support PowerToys, they are free add-ons you can download from http://www.microsoft.com/windows95/info/powertoys.htm. Microsoft has updated about half the PowerToys to run on NT 4.0.

One invaluable PowerToy is Command Prompt Here 1.1. This .inf file creates an Explorer association for directories and adds that association to their context menu.

Specifically, the file creates the Registry key HKEY_CLASSES_ROOT\Directory\shell\DosHere\command, which has a default value of %SYSTEMROOT%\SYSTEM32\CMD.EXE /k cd "%1". (This file modifies several keys, but this key gets the job done.)

Command Prompt Here opens a CMD prompt in the selected directory, but it doesn't provide all the functionality that Cogley's batch file offers. You can get the best of both worlds by following these steps:

Install the Command Prompt Here 1.1 PowerToy.

Open Explorer.

Select Options from the View menu.

Click the File Types tab.

Select File Folder from the Registered File Types list box. (Be sure not to select Folder, because it has a different meaning to the shell.)

Click Edit.

Select Command Prompt Here in the Actions list box.

Click Edit.

Enter .bat or .cmd file to execute.

Make certain that the .bat or .cmd file has START /D%1 /B as its last line. If the file has this last line, you can customize the CMD prompt environment in any way that you see fit. You simply right-click to open a fully customized CMD prompt.

—Jon Boggs jon.boggs@metamor.com

Two Easy Ways to Search for Filenames My network clients occasionally ask me who is accessing a certain file. For example, someone might try to open a file but is denied access because another user has that file open.

The most common method to retrieve this information is to double-click \\SERVER in Windows NT's Server Manager and then click In Use. Unfortunately, you can sort through the files only by user. If you work in an environment with thousands of users and files, you can quickly become frustrated scrolling through page after page of files, trying to find the file in question. And you can easily miss the filename you want.

I know of two ways to avoid this frustration. If your system has a file manager, you can run winfile.exe, click the appropriate filename, and press ALT+ENTER. You will get a screen that shows the file's properties and gives you access to the Open By button. You can learn who has the file open by clicking that button.

If your system doesn't have a file manager, you can use the FINDSTR command to get the same information. First, you must create a batch file. Here is my batch file, whatopen.bat:

@ECHO OFF NET FILES > WHATOPEN.TXT FINDSTR /I %1 WHATOPEN.TXT|MORE

Next, you must make sure that the filename of the file in question is in a directory contained in the PATH variable. Finally, you must go to a command prompt and type

WHATOPEN <filename>

NT will reveal the usernames of people who are accessing that file via the network. You can also use the FINDSTR command to display the files that user has opened by typing

WHATOPEN <username>

You can get more creative with the FINDSTR command. For example, you can find files that are open in the write mode by entering:

WHATOPEN <username> in <directory>

These are a few examples of the many uses for the FINDSTR command.

—John Ross johnr@wordlink.com

Use Policies to Control NT's Password Warning Message Windows NT's Password Warning Message appears 14 days before a network password expires. My company requires that employees change their password after 30 days, so half of every month I'm pestered with the question of whether I want to change my password. Wouldn't it be nice to have this message only appear a few days before expiration?

In October 1997 "Tricks & Traps," Bob Chronister discussed how to change the length of the new password warning period in NT. But with his solution, you must edit the HKEY_LOCAL_MACHINE Registry hive on every machine. Instead of using regedt32 to make this change manually on every workstation, I use system policies.

Listing 1 contains a policy template that you can use to change when the warning message appears. Although this template gives you the option for 1 day to 14 days, you can change the template so that you can get warnings any number of days (e.g., 15, 30, or even 90) before password expiration. Screen 1 shows what the template file will look like when loaded in the Policy Editor. (For more information about system policies, see Douglas S. Frisk, "Using System Policy Templates," October 1997.)

A copy of the .adm file in Listing 1 is available from the Windows NT Magazine Web site at http://www.winntmag.com. This .adm file is plain text, so you can open it with any text editor.

—Larry Dragich dragich@mich.com

Workaround for Mac Printing on NT Problem I've identified a problem when running Print Services for Macintosh on Windows NT 4.0. The problem occurs when you attach more than 127 printers to an NT print server. If you have more than 127 printers, Mac clients can no longer print through the Appletalk zone advertised by NT. (Mac clients can still print directly to the printer via Appletalk.)

A Microsoft developer has confirmed this glitch. He claimed that, because this glitch results from a shortcoming in Apple's Printer Access Protocol, Microsoft won't provide a fix. You can, however, use this workaround:

Open the Services applet in Control Panel, and access Print Services for Macintosh. Set this service to log on using the Macuser account rather than a system account.

Open the Permissions box for the non-Mac printers identified in step 1. Add the Macuser account to the Permissions list, and grant it No Access. This step prevents non-Mac printers from being advertised through NT. This fix isn't glamorous, but it works.

—Curtis Stall cstall@chw.edu

Bill Gates: The Stories Are True I recently attended the 1998 Microsoft Technical Briefing in Seattle, Washington. This annual event, known at Microsoft as the Winter Briefing, provides technical presentations for Microsoft's systems engineers and consulting staff. In years past, this briefing was private, but this year, Microsoft invited senior technical representatives from its solution provider channel. Although I had once worked for Microsoft, I attended the 1998 Winter Briefing as a solution provider.

Microsoft offers many different sessions in this 5-day event, but the most anticipated was the general session featuring Bill Gates. Microsoft employees were just as anxious as the solution providers to hear the Microsoft story straight from the source. There wasn't an empty seat in the house.

When Gates arrived, he immediately dived into his presentation. Although he will never win an award for public speaking, he was very relaxed and direct as he shared his views on the industry's direction. Shortly after Gates started his presentation, it became evident that he was sick. He could barely string three sentences together without a coughing spasm.

Although Gates is one of the wealthiest people in the world and could have had any number of people fill in for him, he showed up for this presentation, speaking with energy and enthusiasm. He even stayed and answered attendees' questions. I had heard stories about Gates' drive and commitment, but this time I witnessed it firsthand. Perhaps this drive and commitment is the reason why one person in the audience asked if he could fulfill a dream by shaking Gates' hand--a request to which Gates graciously complied. (An indepth account of the 1998 Winter Briefing is available on the Windows NT Magazine Web site at http://www.winntmag.com.)

—Mark Eddins meddins@alpha88.com

Automate Repetitive Tasks in NT I've heard UNIX administrators suggest that administering a network of identical workstations is as easy as administering one workstation. On UNIX machines, all system settings are stored in regular files (usually text files), making mass configuration changes as easy as remote-copying a file across a local network. When I started administering Windows NT workstations, I was surprised that, except for system policies, automatic configuration of multiple machines was not part of the NT operating system's culture.

NT administrators frequently use regedit.exe or regedt32.exe to edit system Registries remotely, but they don't often discuss how to automate repetitive tasks--a procedure taken for granted in the UNIX world. However, mastering this systems administration technique is important for three reasons. First, system policies can handle only Registry changes, not files. Second, you might not have NT Server or be a domain administrator, but you still might want to manage a group of NT workstations. Finally, you might not want to write system policy templates for every change you want to make.

If you've manually implemented a Registry or .ini file change in a group of workstations, you understand the value in automating this kind of task. Fortunately, such configuration changes are easy to automate using command scripts.

You can use two short scripts to implement Registry changes or copy files automatically across NT workstations. These scripts use a feature of the command-prompt language that dates back to the old versions of DOS: the FOR command. This command applies an action over a list of elements that you specify. For example, the command

for %i in (1 2 3) echo %i

runs command echo 1, followed by echo 2, followed by echo 3. (When you include FOR commands in .bat or .cmd files, you need to specify %%i instead of %i to avoid variable interpolation.)

The first script, dist.cmd, lets you copy a file to multiple workstations (e.g., W1, W2, and W3). For example, say you want to copy a new version of an .ini file for third-party programs, such as HostExplorer, that still use .ini files. You might use the following batch file:

for %%i in (W1 W2 W3 ...) do copy %1 \\%%i\c$%2

You use this file in DIST file path (e.g., DIST HOSTEX.INI "\Winnt\HOSTEX.INI"). The first argument, "file," is the full path to the original version of the file you want to copy across your network. The second argument is the full path (starting with \, the root directory) of the file that will end up on your machines.

The second script, regdist.cmd, lets you implement a Registry change across multiple workstations. For example, you might use it to change the name of the registered organization or even network settings. You must use rregchg.exe, which comes with the Microsoft Windows NT Server 4.0 Resource Kit. The batch file adds or modifies the Registry value you specify. This script can modify only Registry values in HKEY_LOCAL_MACHINE:

for %%i in (W1 W2 W3 ...) do rregchg \\%%i %1 %2 %3 %4

You use this script in REGDIST path value_name type value_data (e.g., REGDIST "Software\Microsoft\WindowsNT\CurrentVersion" RegisteredOrganization REG_SZ "Windows NT Magazine"). In both scripts, you need to replace W1 W2 W3 ... with the names of the computers you want to apply your changes to. You can use these two scripts (and variations thereof--e.g., using CACLS in a similar script) to install new applications to a network of workstations without leaving your desk.

—Shawn Bayern shawn.bayern@yale.edu

The Next Best Alternative in Multimedia Training Providing multimedia training that incorporates full-motion Moving Pictures Experts Group (MPEG) files directly on desktops is on the wish list of many training staffs. But efforts to reduce costs often force training staffs to use a networked multimedia system instead.

This scenario holds true for the State of Wisconsin Department of Natural Resources (DNR). The DNR uses a networked multimedia system to provide training in computer software (including MS Office, Networking, and Oracle) at its Madison, Wisconsin, headquarters. Relying on Windows NT environments at the server, network, and desktop levels, the DNR initially designed this system to run on an isolated, high-speed LAN segment in only one location. However, a second server was eventually installed in a regional office in Milwaukee, Wisconsin.

The Madison office has a Digital Equipment 233 MHz Alpha server with dual CPUs, 128MB of RAM, and a Mylex 3-Channel controller. Starting with NT Server 3.51 and 48GB of RAID-5 storage, the DNR upgraded to NT 4.0 and 100GB of storage. The DNR stores all multimedia files in a SQL Server 6.5 database. The regional Milwaukee office has a Digital Equipment Prioris server with dual CPUs (200MHz Pentium Pros) and 128MB of RAM, but only 32GB of RAID-5 off an Adaptec two-channel, wide SCSI controller. The standard multimedia client is a Pentium PC with a 133MHz CPU (minimum), Internet Explorer (IE) 3.02 or later, 32MB of RAM, a Matrox Millennium graphics card, a SoundBlaster (or compatible) audio card, and ActiveMovie.

Because this PC setup is standard, employees just plug in their headphones to use multimedia at their desks. Employees use the IE front-end to access the appropriate training courseware. They enter a logon ID and password to verify their status as an employee and their training privileges. The system tracks the course modules they use and the start and stop times for each module. The DNR collects this data for reporting purposes (e.g., reports on training histories, billings, and program evaluations) and stores it in a SQL Server database.

For reasons unrelated to training, the DNR has recently upgraded the cabling at its major offices to fiber optic backbones servicing switched Ethernet to desks, with only 10 to 15 employees per segment. This upgrade dramatically altered the probability of network contention. Instead of hundreds of employees sharing a 10Mb pipe, now a maximum of 15 employees share it. The likelihood that three or four of those 15 employees would be viewing MPEG streams simultaneously is low. Thus, desktop delivery is being offered.

In addition, because the basic infrastructure for multimedia courseware is in place, the DNR is investigating several software additions to its network. Some of the possible additions include NetMeeting, which would provide whiteboarding and data conferencing; CU-SeeMe, which works with NetMeeting and would let employees see with whom they are interacting; and NetShow, which would reduce bandwidth requirements.

NT and Microsoft's Web environment have proven to be both robust and flexible for networked multimedia training. In addition, NT components drastically change the economics of such training. Not only are NT's components among the least expensive available, but you can also leverage NT's built-in standards to support general desktop applications.

—Patrick Powers powerp@mail01.dnr.state.wi.us

Use NT's Default User Profile to Configure Printers My company recently upgraded from Windows for Workgroups (WFW) to Windows NT Workstation 4.0. This upgrade proved challenging when it came to setting up the printers. With WFW, each workstation printed to a specific printer, regardless of who logged on to the machine. The department managers wanted to keep this printing setup after the company upgraded to NT Workstation.

Although this printing setup was easy to configure with WFW (I simply configured Print Manager to reconnect at startup), it was more challenging to configure with NT Workstation. Because NT uses profiles, the printers are user-dependent rather than workstation-dependent.

I met this challenge by configuring each workstation's Default User profile to specify the default printer. Now when new users log on, NT creates a profile for them and tells them which printer they can print to. Here's how you can change the profile:

Create a domain user called TEMPUSER.

Log on to an NT workstation as TEMPUSER and configure all the default settings, including default printer.

Log off and log on as a domain administrator.

Copy the ntuser.dat file that is in \profiles\TEMPUSER\ to a directory named after the default printer.

Copy the ntuser.dat file to the Default User profile on each workstation using that default printer. You can use Systems Management Server (SMS) to automate the file's distribution.

Repeat steps 1 through 5 for every default printer you want to configure. If you get confused about what printer ntuser.dat is configured for, you can use regedt32.exe and load the ntuser.dat file as a hive in HKEY_USERS to view the configuration.

If you are using roaming profiles, this approach will work only if the profile has not yet been defined on the network. If you want to change a user's roaming profile (suppose a user moves to a different part of the building), you just delete that person's roaming profile on the network. When the user logs on to a new workstation, the Default User profile will re-create a profile for that user. When the user logs off, that profile will be copied to the server. You can set a system policy to delete the cached roaming profile on the workstation when the user logs off so that the only profile configured is the one on the network.

If you are not using roaming profiles, you can still have the Default User profile create a new profile for your users. You can use delprof.exe in the Microsoft Windows NT Server 4.0 Resource Kit to delete the profiles on local machines.

—Larry Dragich dragich@mich.com

Another Way to Fix File Associations In the October 1997 Reader to Reader, Daniel Rodriguez discussed "Problems with File Associations." Specifically, he removed a stubborn association between a .1ST file and Notepad with the following command:

ASSOC .1ST=

Here is another way to remove this association. ASSOC does file association and FTYPE connects the association with the program. So for .exe to associate *.txt with Notepad, you type

Discuss this Article 2

Stephen DeGabriele (not verified)

on Aug 11, 1999

Although Larry Dragich’s April Reader to Reader solution (“Use NT’s Default User Profile to Configure Printers”) to Windows NT’s printing problem works, it’s still administrator intensive. If users move without you knowing, they will experience problems. And, every time users move, their settings will be lost. An easier solution is to set up the printers as printers for that machine only (instead of using a printer server to control the printers).
You can train users to select a new default printer (because their other default printer won’t be on the new machine), or you can change the Registry key that sets the default printer. Then, you’d make the computer set the default printer when a user logs on (in the machine’s startup folder, place a batch file that runs something like regedit.exe setdefprn.prn).
Another option is to give the printers the same names on each computer. The default printer won’t need to change, and you can print to the same printer name even though it will print to a different printer.
--Stephen DeGabriele

My company didn’t want to train users how to set their default printer or select new printers from the browse list. Management wants workstations to print to a specific printer regardless of who logs on. Roaming profiles are not in use, and we have to define all print queues on the server.
A user who moves without me knowing is OK because the default Ntuser.dat is set for a specific printer. Because we don’t use roaming profiles, when a user logs on to a Windows NT workstation for the first time, the user gets the setting defined in the default profile. I added the roaming profiles scenario to explain how the solution would work if roaming profiles were in use.
--Larry Dragich