by Marvin Huffaker
Did your network go down yesterday? And the day before? And what about before that? Does your network go down so often that it's just become part of your daily ritual?
Your Novell systems should run flawlessly for months at a time. It's not normal for them to crash regularly, and it's not necessary to reboot them weekly (like certain other systems). But many companies have become so used to dealing with downtime and system reboots that they don't realize that it is a serious problem. It affects their budget, their productivity, and their morale whether they want to admit it or not. With a lot of my new clients, I notice problems right away that my clients did not even know were serious issues.
|
|
 Marvin L Huffaker
Novell Master CNE
"If you're experiencing deja vu with system problems, call me. I can help." |
So what can you do to get a handle on downtime and create a more stable network? The key is in preventative monitoring and maintenance. It's always better to catch a small problem and fix it before it turns into a major system outage.
Pay Attention to Error Messages
If your server is beeping, don't just turn off the speaker. Find out what the beep is, why it is happening, and what you can do to fix it. A healthy, well running Novell server generally does not beep or display errors. The reason beeps or error messages occur is because something needs attention. Find out what it is and fix it before it gets worse. You should frequently monitor the following locations on a NetWare server to spot potential problems:
- Server Console - Any errors displayed here should be investigated and resolved. Note that not all system console messages are errors.
- SYS$LOG.ERR - Located at SYS:SYSTEM, system console messages are logged in this file. It should be reviewed regularly to check for any abnormal error messages.
- ABEND.LOG - If your server(s) crash often, the ABEND.LOG file should be reviewed to help determine the cause of the crash. This file is located in SYS:SYSTEM.
- VOL$LOG.ERR - On traditional volumes (Non NSS), the VOL$LOG.ERR file on each volume can provide valuable information to help determine if a server has been going up and down unexpectedly, and when. This file is located at the root of each traditional volume.
- CPQIML.NLM - On Compaq systems, the Integrated Management Log can sometimes provide valuable clues to help solve a problem. It can be accessed through an Insight Manager monitoring station or through the CPQIML.NLM module at the server.
Regular Server and NDS Health Checks
Not enough can be said about performing regular checks on a server. Minor problems can be found that may eventually lead to bigger problems and downtime if not corrected. As a minimum, a quick NDS health check should be performed weekly. I like to do a thorough health check at least once a month, but it depends on the size of the network and how dynamic the environment is. The following items should be completed regularly for a quick check:
- In DSREPAIR.NLM, run a "Time Synchronization" check and make sure that all servers are reporting YES to being synchronized.
- Check the DS versions (reported in the Time Sync check). It's important to have all servers at the same DS version, if possible.
- In DSREPAIR.NLM, run a "Report Synchronization" check and make sure that no errors are reported.
- Check system errors and abend logs (as noted above).
A completely healthy Novell tree will not have any errors when performing the items listed. Any errors found should be investigated and resolved. There are more in-depth tests that can be completed, but the items listed will generally alert you to any condition or problem that needs to be resolved immediately.
Stay up to date on patches
A lot could be said about keeping a server patched. But it's very common to walk into a company that hasn't patched their servers for the last 3 years. The mentality is "If it ain't broke, don't fix it." But in this type of situation, it's very likely that something will break as soon as anything changes. It may be minor, but years of neglect will eventually break the server. Not to mention potential security holes that are left open. Get in the habit of scheduled maintenance, and at least applying the major OS service packs. Patches are made for only two reasons: 1) to fix bugs and 2) to plug security holes.
Call in the big guns
Sometimes you may get overwhelmed with various problems, and it's difficult to step back and see what is really happening in your network. Or the nature of the problems are over your head and you don't have the time or expertise to learn how to troubleshoot the problem. In this situation, it is invaluable to have a reliable person to call that can pinpoint the problem and get things working the way they should.
Word of mouth is one of the best ways to find a good local technical resource. Ask your friends and colleagues who they use for their tough Novell problems. If that doesn't work, go to www.novell.com/partnerlocator and search for a Novell Partner in your area. If you still can't find someone capable of handling your biggest challenges, call Marvin Huffaker Consulting. We'll either help you find someone in your local area, or help you fix the problem ourselves, whatever works best for you. The contact information for Marvin Huffaker Consulting can be found here.
|
