\[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 (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 bought a Jaton Video Card to use on Windows NT Workstation 4.0. The back of the box says the card is compatible with NT 4.0, but after I installed the card and the driver, the video card didn't work.
I then consulted my NT hardware compatibility list and found that the Trident chip (which is part of the video board) I was using was one digit off from being compatible. When I borrowed a card that had the right Trident chip, I got my video up and running. The chip in question was a Trident Providia 9685; the one that works is Trident Providia 9680.
Use SMS to Centralize NT Event Monitoring
If you've installed the SMS client on your Windows NT servers, you can use SMS to monitor significant events across NT servers and workstations and report those events to a dynamic Web page. This Web page lets you quickly and easily keep track of all major server events. You can set up this monitoring and reporting system in four steps:
- Configure Simple Network Management Protocol (SNMP) on each SMS client that you want to monitor. Open Network in the Control Panel and install SNMP as a service. Open the properties for SNMP. Under Traps, enter SMS as the community name and add the SMS server IP address or NetBIOS name as the Trap Destination. Stop and then restart the SNMP service.
- Configure the SNMP Traps. In the Sites window in SMS Administrator, select the SMS client that you just installed SNMP on. Double-click to open Personal Computer Properties, and click the Windows NT Administrative icon. Select Event to Trap Translator. Click Custom, then Edit to open a dialog box that lists the NT Events you can monitor on that machine. After you select those events you want to monitor, click OK to save the configuration.
- Enable SNMP trap filtering. In SMS Administrator, open Site Properties and click the SNMP Traps icon. To add an SNMP trap filter, select Create and fill in the Description field. Click OK to configure SMS so that it starts looking for SNMP traps. Click OK again to update the SMS site. SMS will start monitoring NT event traps and reporting them to the SNMP Traps window in SMS Administrator.
- Run a SQL script to generate the Web page. SMS stores all trap information in the SNMP_Traps table in the SMS database. You can use SQL Server's ISQL/w tool to generate a script to dump this information to a Web page. You can even generate multiple Web pages by creating multiple scripts that filter different types of events or that filter events from different servers.
Listing 1 contains a script that uses a template HTML file (dbresult.htm) to dump all event information to the Web page snmp.htm. This script updates the table in the Web page every 4 minutes. The template file can be any style or format, as long as you include '<%insert_data_here%>' somewhere in the template as a WebBot. This field is where the SQL script creates the SNMP table.
After you have created your script, open the ISQL/w tool. In the Query window, input the script and click the green arrow to run it. After a few seconds, look in the Results window. If you receive the message Did not return any data and did not return any rows, the script executed successfully.
You can find more information about this procedure in sp_makewebtask in SQL Server's online documentation. However, here are two tips. First, if you're generating multiple Web pages, their directory path must be on the same server. Make sure that your Web server includes this path as a virtual directory to enable browsing. Second, in the SNMP Events window in SMS Administrator, regularly delete all events that are, say, a day old to keep the table small. This task will be the only regular maintenance required.
Don't Let Old Files Lie
Internet Information Server (IIS) generates log files in the form INyymmdd.log. Because I use a monthly log schedule on my intranet server, IIS creates a new log file every month.
Although I use the current month's file for debugging and troubleshooting, the rest of the log files just take up space in the log directory. So I wrote a script that cleans out the log directory by deleting log files that are a certain number of months old. I use the AT command to schedule the script's execution.
To use this script, extract the batches in Listings 2, 3, and 4 into the same directory. After you change the hard-coded directories to match the values in your system, schedule the script to run with the AT command. For example, to run the script the first of every month, I use the command
AT 04:00 /Every:1 "cmd /c e:admin\iislogmanager_start.bat >e:\admin\iislogmanager.log"
This script works with not only monthly, but also daily, logs. In addition, you can easily customize the script so that it manipulates logs in other ways. For example, you can adapt the script so that it archives old logs instead of deleting them. Because this script uses an Italian locale, you might need to adapt the script where it extracts the current date. REMs precede the affected line.
—Alessandro Iacopetti
[email protected]
SP3 Needed for Full Color
I recently discovered information about Intel's Accelerated Graphics Port (AGP) and Windows NT. To get more than basic VGA (16 colors) out of your ATI@work AGP video adapter, you must install Service Pack 3 (SP3). Only then will the Rage Pro drivers work to give you the color depth you expect from a 4MB or 8MB adapter.
I've also discovered that if you install the ATI drivers without SP3 during setup, NT will offer a minimum of 256 colors at any resolution. In addition, clicking Test blacks the screen and locks up the machine. Until you install SP3, you must use basic VGA.
—J. D. Ray
[email protected]
Modify the Boot File
Mirroring (or duplexing) your system and boot partitions is a great way to provide fault tolerance for your operating system (OS), but mirroring often causes inexperienced administrators to get confused when the primary drive fails. The system fails to reboot properly because the Advanced RISC Computing (ARC) path in the boot.ini file points to the failed partition.
The usual workaround for this problem is to use an alternative boot floppy that has the boot.ini pointing to the mirrored drive partition. But inexperienced administrators often don't prepare these floppies in advance. Plus, these floppies can get lost, erased, or mislabeled.
I have devised another workaround for this problem: I include the path to the mirrored partition in the boot.ini file. As Listing 5 shows, you can use Notepad or another text editor to add the ARC path of the mirrored drive and partition to the OS section of the standard boot.ini file. This alternative drive must have a master boot record from a previous Windows NT installation to work.
Now if the primary drive fails, you'll have 30 seconds to choose the Mirrored Boot after restarting the server. You'll still have to replace the failed drive and reestablish the mirror as soon as possible, but at least you can quickly and easily get your system running.
Same Theory, Different Procedure for Automation
After reading Dmitrii Lezine's "Automate for Easy Installation" in December 1997 Reader to Reader, I found myself wondering if the same procedure would work for an out-of-the-box Digital Equipment PC preloaded with Windows NT Workstation 4.0. I found that the theory is sound, but the procedure is different.
Digital uses the file c:\winnt\system32\$winnt$.inf for its installation settings. With the help of NT's Setup Manager (in the Microsoft Windows NT Workstation 4.0 Resource Kit) and Guide to Automating Setup (at http://www.microsoft.com/ntworkstation/info/deployguide.htm), I modified the file to fit my needs (as Listing 6 shows).
A coworker and I then created a batch file that replaced the original $winnt$.inf with the modified $winnt$.inf file and appended the computer-name parameter to the end of the file. Listing 7 contains this batch file, which I put on a bootable disk.
I booted off the disk, typed
SETUP WKSTN_1
ejected the disk, and restarted the machine. When the machine booted into setup mode, I agreed to the Licensing Agreement and walked away. When I returned, the machine was completely setup with the correct protocols. It had even created a computer account for itself in the domain. All I had to do was log on.
Remove Your NT Server from the Browser Election
If you use a Windows NT server for research and development and you're rebuilding it often, consider installing that server as a standalone. Here's why: When your NT server is a Primary Domain Controller (PDC) or Backup Domain Controller (BDC), it participates in a browser election each time you bring the server back online. If you continually take your server offline and then bring it back online, the server and clients can get an empty browser list. If you install the NT server as a standalone, however, that server will not be a part of the browser election. Your network will then run smoothly.
Corrections to this Article:
- Listing 2 in Reader to Reader: "Don't Let Old Files Lie" contained the following incorrect statement: set SHORTDATE=%DATE: 12,2%%DATE: 7,2% The correct syntax is set SHORTDATE=%DATE:~12,2%%DATE:~7,2%
