Being a Windows NT enthusiast, I enjoy getting as much mileage out of native commands and utilities as I can, especially at the command line. I hate hearing that I can't carry out a command that the UNIX world considers stock-in-trade.

This passion came in handy recently. An administrator was making rounds at midnight to reboot machines so that a backup could catch files that were still open. I was helping close files after hours, and I came up with an idea: A scheduled batch file could automatically close open files. Much to the administrator's surprise (this person had a UNIX background), I put the following command in a batch file:

for /f "skip=4 eol=T" %%i in ('net file') do net file %%i /close

The /f option parses output, and for this example, passes the first white-spaced token on to the rest of the line. (Other tokens can pass.) The eol=T keeps the command from generating an annoying message when fed an empty line. You need the double percent signs for shell variables inside batch files.

You can then use an at command to schedule when the batch file will run:

at 01:00 /every:m,t,w,th,f d:\users\davidk\kill_open_files.bat

An alternative way to perform this process is through Control Panel, Server, but you can't schedule the process if you use this method. So try a "for /?" sometime and get familiar with its options. It's a useful, robust command.

—David Krider
dunkirk@sprynet.com

Use Your Dial-Up Monitor Icon Effectively
When the Microsoft Internet Mail program starts a dial-up connection, the Dial-Up Monitor icon does not show up in the tray bar. If you need the icon, start any dial-up connection that uses the same port. It won't dial, alerting you that the port is in use. Clicking Cancel will stop the dialing, but the Dial-Up Monitor will surface in the tray bar.

You can also use a shortcut to quickly hang up a connection. Usually, you right-click the Dial-Up Monitor icon in the tray bar, choose Hang-Up, choose the connection, and click OK. But if you double-right-click the icon and click OK, you shut down all the connections at once.

—Andre Gurgel
andre@tecfil.com.br

Automate for Easy Installation
I recently installed a large NT 4.0 network with out-of-the-box Dell computers. The computers came preinstalled with NT Workstation 4.0. But when I turned on the power, I found that they required a lot of data input and protocol changes to suit my environment.

I came up with an easy solution to automate installation. I found the NT unattended configuration file, winnt.sif, in the hidden subdirectory $win_nt$.~bt on the c: drive. I modified this file to meet my needs (you can find documentation on all parameters at Microsoft's Web site, http://www.microsoft.com/exchange) and saved it to multiple subdirectories on a bootable floppy. Then, in each file, I changed ComputerName to a unique name. Finally, I created a batch file to copy the appropriate file to c:\$win_nt$.~bt.

This solution made installation easy. After hooking each new PC to the network, I booted it with my floppy, typed INSTALL "workstation name" to copy my winnt.sif file over the Dell file, removed the floppy, and rebooted the PC. I was in business!

—Dmitrii Lezine
dmitrii.lezine@stepconsulting.com

The Solution Might Be Right in Front of You
How many times has a solution for a problem come along at just the right time (and at the right price--free)? Although this timing doesn't happen often, the solution might be right before your eyes this time. I had initially missed this solution, even though I had looked through the Microsoft Windows NT Server Resource Kit a hundred times. It had been in the kit's \KIX95 subdirectory all along. It is KiXtart.

KiXtart is a 32-bit freeware application that performs logon-script and enhanced batch-file processing. You can find it in the Resource Kit or on The KiXtart Archive Web site at http://netnet.net/~swilson/kix/. With KiXtart, you can connect to network drives, set variables, and read and write to the NT Registry. If you require custom functionality but lack strong programming skills, KiXtart is a simple, but powerful tool for network management.

I used KiXtart to solve a problem that involved using FTP with a script file to copy files for the current date. I used the FTP command, MGET, to transfer on wild card filenames (e.g., mget *970725*). Initially I had planned to use a batch scheduler to run this command every day. But I realized that this approach would require me to edit the script file daily to correct the date or copy all files, which would consume bandwidth. There had to be a better way. That's when I discovered KiXtart.

I configured KiXtart to take the current date, reformat the date to correspond to the required file syntax, write the new format to the FTP script file (ftpscr.txt), and execute the FTP command from within the script file. Listing 1 contains the FTP script file. After testing the KiXtart script (when working with the NT Registry, you must test any script before implementing it), I ran it. It worked so well that I used KiXtart to solve several problems with dates:

* The wild card requires a two-digit month to copy the filenames. But the output for July was 7 instead of 07. So I used the IF-ELSE-ENDIF command to add "0" if @MONTHNO was less than 10. (KiXtart uses handy common macros such as @MONTHNO.)

* The @DATE macro output was yyyymmdd, but the wild card accepts only a two-digit year. So I used the SUBSTR and LEN functions to send only the last two digits to the script file.

* The REDIRECTOUTPUT function requires an IF-ELSE-ENDIF command to prevent writing a successful 0 result code as text on the first line of the ftp scr.txt file

I used the syntax \\server\sharename\kix32.exe makefile.scr for these solutions. Listing 2, page 38, contains the script.

In the rush to bring up the site, I inadvertently installed several NT 3.51 workstations with the wrong time zone configured. Software distribution applications were hard to run because of this mistake. So I used KiXtart to determine which workstations had the wrong configuration. The script, which is shown in Listing 3, performs three steps:

1. Scan the Registry for the time zone.

2. Log the machine name and the time zone setting if incorrect.

3. Log all machine names to a file that will ensure that incorrect machines are logged only once.

Since fixing the time zone problem, I have successfully used KiXtart for various other projects. KiXtart is a very useful tool for administering NT networks.

—Marty Scher
mscher@advanta.com

Save Effort­Use a Tab
I found a neat shortcut for people who often use the command prompt. In the Registry, go to HKEY_CURRENT_USER\Software\Microsoft\Command Processor and add or modify the value CompletionChar of data type REG_DWORD with a data value of 9. The data value (9) is the ASCII value for the Tab key (but you can easily change it to any other key on the keyboard).

Now, when you enter a command, you just need to type in part of the file or directory name and then press the Tab key. Windows NT will automatically complete the file or directory name. For example, if you enter CD C:\ Prog and then press Tab, NT will complete the case directory name to CD C:\Program Files.

If more than one file or directory matches the partial name, you can browse the retrieved list by pressing Tab several times. For example, suppose you type in back and the filename C:\backup appears, but you want the file C:\backup1 instead. Just keep pressing Tab until that filename appears. This procedure is especially useful for long filenames and filenames with spaces.

—Sascha Frassini
sascha_frassini@ccmail.gb.swissbank.com

Don't Lose the Online Election
I'm impressed with the way NT 4.0 handles WANs. Marine Forces Pacific and its subordinate headquarters chose NT 4.0 as the network operating system for a recent joint exercise with the Republic

of South Korea. I was part of the team that built and then tore down the large network.

The WAN topology for this two-week exercise consisted of 20 Cisco Systems routers spanning the South Korean peninsula. About 20 class-C IP networks connected the routers. With the assistance of the LMHOSTS file and Windows Internet Name Service (WINS), the team connected six NT domains and established trusts among them. Liaison officers in two remote sites were able to connect to the domain and read their Microsoft Exchange email five routers away.

But then the trouble began. The initial symptoms appeared when I was trying to access the User Manager for Domains program from my Primary Domain Controller (PDC). The error read "Cannot access this domain, unable to locate domain controller." My first reaction was immediate panic. I shut the system down and then brought it back up again. When I logged on as the administrator, I noticed that some services didn't start. The severity of my problems became clear when I looked at the Server Manager program. In a single online election, my PDC had been demoted to a workstation.

I found the reason for the crisis in the Event Viewer: Another computer had the same name as my PDC. A computer hundreds of miles away on the other side of four routers was seriously affecting my PDC.

Fortunately, earlier in the week, I had convinced a fellow technician to stand his machine up as a classified Backup Domain Controller (BDC) and to load the last copy of Exchange onto it. With that BDC, the team managed to bring up the PDC's Microsoft Exchange System Attendant and Information Store services. The team then used these services to migrate the mailboxes from the bridgehead server to the backup server. With the mailboxes intact, the team promoted the BDC to the PDC.

To bring the downed server back up, the team needed to rename it and reload the operating system to stand up another BDC. The Help desk immediately mobilized the client workstations for a quick reconfiguring of the Exchange server's new location. With the machine renamed, the team reloaded WINS and added several other WINS servers. The team then began Exchange Directory Service replication. All was well.

The team's experience illustrates that details matter when planning the architecture of multidomain WAN systems. The team failed to plan naming conventions down to the node. The team now knows that a site-unique computer name must also be WAN-unique.

—Jeffrey Fukushima
fukushimaj@mfp.usmc.mil