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=<stdin>);

 

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.

End of Article

Prev. page     1 [2]     next page -->



You must log on before posting a comment.

If you don't have a username & password, please register now.

Reader Comments

Thanks for Sean Daily’s Reader to Reader: “Unsolved Mystery” (August). I decided to change the TX FIFO buffer to 16, per the author’s recommendation. I noticed some improvement in my U.S. Robotics 56Kbps V.90’s performance. However, I decided to experiment and change the RX FIFO buffer to 16. The result was a marked improvement in downloading pages. The last time I saw this kind of performance was when I was operating on the company network, which has a T1 connection. I changed both my systems (which have 56Kbps modems), and the results were the same. The only question I have is whether any risk is associated with changing the buffer values. With the performance I’ve achieved, I’m prepared to leave my systems as they are until I find some negative aspect that forces me to revert. Thanks for the great tip.<br> –Jack Terwiel<br><br>

<i>The only potential problem that exists in changing the COM port TX or RX buffer values is loss of performance or functionality, which is evidently not the case for you. If you aren’t experiencing any loss of functionality or performance after making the changes (and are reaping a performance benefit), it’s safe to keep the values at whatever optimal setting you discovered during your experimentation.<br> Hardware doesn’t limit the buffer values, but Windows NT imposes soft limits on them. However, these limits are based on the actual buffers on most modern COM ports. Microsoft’s documented limit for the TX FIFO Registry value is 14 (with possible incremental values of 1, 4, 8, and 14), and the documented limit for the RX FIFO value is 16. (For more information about these Registry entries and their potential values, see Microsoft Windows NT Server Resource Kit’s regentry.hlp file.) These limits are based on the recommended maximum values for a National Semiconductor 16550-style UART, the chip driving most modern COM ports.<br> --Sean Daily</i>

Jack Terwiel

 
 

ADS BY GOOGLE