\[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 (400 words or less) to Karen Bemowski at kbemowski@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.\]

After reading "Optimizing NT RAS" (May 1998), Taed Nelson asked me why the Windows NT 4.0 serial.sys driver installs with the default first in, first out (FIFO) values of 8 for the receive buffer (RX) and 1 for the transmit buffer (TX). I decided to investigate the matter in the Microsoft Windows NT Server 4.0 Resource Kit.

The resource kit's Registry documentation refers you to a nonexistent Knowledge Base article (Q112559), making the mystery even stranger. You can't help but wonder why Microsoft removed this article. And you are still left wondering why Microsoft selected the NT 4.0 default values of 8 for RX FIFO and 1 for TX FIFO, especially when Windows 95 uses the default values of 8 and 16, respectively.

You can improve modem performance by increasing the TX FIFO value to 16. In regedit, change the TX FIFO value in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Serial subkey to 16. However, before you experiment with this modification, make sure you have backed up your Registry. In addition, be aware that modifying the TX FIFO value is a global change that affects all serial ports on the system. As a result, this change might cause problems for other types of devices (such as plotters, mouse devices, and digitizing tablets) attached to serial ports. After you change the TX FIFO value, verify whether all the serial-based devices are working properly.

If you encounter any problems with particular devices on other component object model (COM) ports, you can make the following change, which is specific to a particular serial port. In the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Serial subkey, create an additional Registry subkey for a specific serial port number by adding a Serialn key (where n is the number of the COM ports connected to the dial-up adapter) under this key's Parameters subkey.

For example, a specific entry for COM1 is HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Serial\Parameters\Serial. Inside this newly created key, create the same REG_DWORD value for TX FIFO as that found in the Serial subkey and set it to the desired value for that port (e.g., 16 decimal). You can also create custom values to this port for other entries, such as RX FIFO.

Try Before You Buy
I have been testing Symantec's pcANYWHERE32 8.0 for Windows NT 4.0, NT 3.51, and Windows 95 in a development lab to determine its compatibility and functionality with my company's legacy systems. In particular, I wanted to test pcANYWHERE32's ability to upload and download files to and from distributors' bulletin board systems (BBSs) using Pulsar Systems' ZMODEM.

My company has been running pcANYWHERE32 on UNIX servers in its US systems. For several years, I have used a script to automate the ZMODEM transfers. However, my company plans to replace the UNIX boxes with NT. Initially, I believed that I could still use pcANYWHERE32 with NT to maintain the BBS file transfers to the distributors. But when I tested pcANYWHERE32 for NT and Win95, I discovered that Symantec has not incorporated the functionality of the earlier versions into version 8.0. This version doesn't support script-based file transfers to legacy BBSs.

Calls to Symantec have been fruitless. No one seems concerned that this feature doesn't work with NT. (It works with other platforms, however.) And no one appears to know whether this feature will ever be functional. So buyer beware. Before you part with your hard-to-come-by IS budget and purchase a product, make sure it works.

Remotely Change the LMHOSTS Table
Suppose you have a network of Windows NT workstations at local and remote sites (some of which are far away). You don't have either fixed IP addresses or Windows Internet Naming Service (WINS), so whenever you install a new computer, you must change the LMHOSTS table. You can perform this task remotely by using the .reg file in Listing 1 to change the Registry keys.

In Listing 1, Elnk31 and AMDPCN1 are network adapters that might exist in a computer. Although this file contains entries for several adapters, NT will use only the appropriate one.

To install the changes in the Registry, use the .bat file in Listing 2, put in the logon script, and reboot. The script in Listing 3 will not only implement the Registry changes but also implement the WINS and Domain Name System (DNS) policy. Before you use this listing, change the IP and domain names to the ones in your network.

Perl Script Helps You Review Event Logs
As an administrator, you probably look at the server logs routinely. If you are responsible for many servers, you might be interested in the Perl script in Listing 4, page 58. This script automatically opens the event logs in Notepad and displays only the errors and warnings for that particular day.

I used the DUMPEL.EXE command in the Microsoft Windows NT Server 4.0 Resource Kit and Perl parsing techniques to retrieve the errors and warnings from the three event logs (System, Security, and Application) in all the machines specified in the @machine array in Section B in Listing 4. In your script, you must replace ("SERVER01","SERVER2") with the names of your servers in quotation marks. You can include an unlimited number of machines. However, the account running this program must have administrator privileges on all the machines. You must also have DUMPEL.EXE in the same directory from which this program is run.

The line system ("dumpel -f tmp -l $source -s $machine -c"); in Section B uses DUMPEL.EXE to dump all the events from the Event Viewer into the tmp file. The script then parses the events to get the errors (Event 1) and warnings (Event 2) for that particular date. The script writes these filtered events to a temporary file that has the name of the log (e.g., security.log), and Notepad opens this file. So for each system, the script opens three Notepad sessions. The line print outfile ("Event log for $machine $source\n"); at Section B ensures that each session has the appropriate heading.

The script moves through all the events of one machine before it moves to another. You can save the events displayed in Notepad or close the Notepad session. The script deletes the tmp and other log files created at the end of the program.

If you need to review the logs from a past date, you can replace Section A in Listing 4 with the following lines:

 

Print (_&\nEnter the date for the Event Logs _&);

chop($date=);

 

Section A in Listing 4 gives the date in the exact format required for event logs. Thus, when you are entering a past date, you must be careful to follow the same format.

Is Microsoft Shooting Itself in the Foot?
Although Microsoft has always published the policy that, after a year, MCSEs can no longer participate in Microsoft's beta evaluation program, it did not enforce that policy­until now. I doubt whether Microsoft has begun enforcing its policy because of expense, considering that you can purchase a blank CD-ROM for less than a dollar nowadays.

Who is better to beta test software than MCSEs? Without MCSEs implementing and troubleshooting software and solutions, Microsoft might not be where it is today.

Calling All Windows NT Supporters
I'm looking for suggestions and assistance in coming up with a special gift (e.g., a giant email card with notes from everyone) to thank David Cutler and his crew for developing Windows NT. They have persevered and sacrificed much to make NT a reality. So why not say thanks? Also, if you have any Dave Cutler stories you want to share with others, send them (including pictures) my way. You can email your suggestions and stories to me at shannonh@wt.net. For general information, go to the Dave Cutler Fan Club Web site at http://web.wt.net/~shannonh/dave_fan_club/index.htm.

Remove Your NT Workstations from the Browser Election
In "Remove Your NT Server from the Browser Election" (Reader to Reader, May 1998), Tommy Gustafsson explains how to remove a Windows NT server from browser elections in a research and development (R&D) environment so that your network can run smoothly. You can also remove your NT workstations from browser elections in an R&D environment. Their removal will significantly reduce the traffic on your network, and you won't lose functionality. Because the Primary Domain Controller (PDC) and Backup Domain Controller (BDC) always win browser elections, stopping NT workstations' participation in elections will have no effect, except less network traffic.

To stop a workstation running NT 4.0 from participating in browser elections, log on as Administrator. Go to Control Panel, Services. Click Computer Browser, Stop to disable the browser service in the current election. To disable the browser service in future elections, click Startup, Disable, OK.

To stop a workstation running NT 3.51 from participating in browser elections, you need to edit the Registry. Launch regedit. Add this key and value: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Browser\Parameters\MaintainServerList = No. As always, be careful when modifying the Registry.

Correction
Troy Woodfield's Reader to Reader tip "Have More Time to Send New Messages" (June 1998) described how to set up a shortcut on your desktop that takes you directly to the New Message Screen of the Microsoft Windows Messaging email client. Step 3 of the seven-step process instructed you to specify the following command line:

 

c:\program files\windows nt\windows messaging\exchng32.exe /n

 

However, you must enclose paths that have long file names in double quotes. The command line should have read:

 

"c:\program files\windows nt\windows messaging\exchng32.exe" /n

 

Thanks goes to Tredd Barton for pointing out this error. We apologize for any inconvenience this error might have caused.