Network Troubleshooter
Articles and Tips: article
Novell Support Forum SysOp
01 Dec 2001
Getting the Most Out of Your Novell Support Forum Experience
Server problems? Having trouble with a GroupWise MTA? Directory Services problems keeping you awake at night? Pack up your troubles and bring them on over to the Novell Support Forums on the internet!
In this month's Network Troubleshooter column, we're going to talk about the Novell Support Forums and how to get the most out of your support experience in the forums.
Where Are the Forums and What Are They?
The Novell Support forums are on the internet and are available through both a web-based interface and a news (NNTP) interface. To access these forums go to http://support.novell.com.
The Novell Support Forums are a collection of newsgroups hosted on servers at Novell that are staffed by volunteer SysOps from around the world. These SysOps come from all walks of IT life - system administrators, network engineers, independent consultants, and even a few software developers, CNIs, and authors.
There are currently about 35 SysOps servicing the 118 forums on the Novell-provided news server. Like well-rounded IT professionals, they do not strictly focus on one specific technology, but instead work with a range of technologies in their everyday jobs. They also have a good understanding of how networks are put together, starting from the basics of physical network design and topologies on up through operating a workstation or installing software on a client workstation.
What you will find, however, is that the SysOps tend to have expertise in the areas that they work in the most; some focus solely on GroupWise issues, while others focus on issues in eDirectory. Even well-rounded professionals have to have a niche within their business.
"Help! I Have a Server Down and I Need Immediate Assistance! Can Someone Help Me?"
It's very important to understand how the forums work when asking a question of the nature stated above. Discussion groups like the forums are not necessarily on an "immediate-response" basis. The SysOps volunteer their time in the forums when they have time, and the support given is always on a "best educated guess" basis.
The SysOps who answer in the forums are not dedicated support personnel who are waiting to jump on the next issue posted. For most of us SysOps, forum work is after hours (wherever we live in the world at that time) or during our lunch breaks as we earn a living at our normal jobs.
There is nothing wrong with posting a critical problem in the support forums and hoping for an immediate response. However, if you don't get one, it's not because you're being ignored. There are many reasons you might not receive an immediate reply.
One of the most common reason is that none of the group who work the forum you are posting in happens to be online at the time. This is bound to happen and does happen every day. Some people might see a response posted within a minute or two, while others might take several hours or days, depending on the nature of the problem and SysOp availability.
In your critically high situations, you (as an IT professional) and your management have to make a decision: Is the cost of the system being down higher than the cost of opening an incident with Novell Technical Support directly? In most cases, the answer to this will be "Yes." If the problem is not pressing, then you might be in a better position to work through the issue in a more leisurely manner - sometimes over a period of several days - before you receive a resolution.
Why, Then, Would I Use the Forums If Responses and Resolutions Can Take Days?
In some cases, a longer resolution time is not an issue. If, for example, you have a problem with obituaries not purging in your NDS or eDirectory environment, you might have the luxury of taking some time to understand the problem rather than paying for a Novell technician to dial-in and resolve the issue.
A decision like this can frequently be made on strictly economic grounds. A standard incident costs money, but if the system is functioning and your business is functioning, then spending money to resolve this issue at this particular point might not make sense.
However, the real advantage in posting a question in the forums is that expertise comes from all over the world. The forums are provided on a peer-to-peer support basis. You can read other people's problems and they can read yours, and you can interact with other end-users to help solve each other's problems.
Another advantage is that if you post a problem and the problem is resolved, the information is left on the news server, so the next person with the problem (if they take the time to search the messages) might find their resolution without even having to ask a question. The many-to-many relationship of users with problems and people with solutions means that in many cases, resolutions are found quickly.
Providing the Necessary Detail
When posting questions on the forums, it's important to provide as much detail as possible about your configuration and your problem. Too many times the entire content of a message is "my server crashed," or "I get an error in the client." We even had one question several years ago giving the entire text as "my thing's broke!"
These types of questions tend to leave the SysOps (and probably a large number of other readers) scratching their heads with no place to start troubleshooting. Your message should include some very specific information, such as:
Specific error messages from the client or server.
Steps you have already tried, so we don't suggest them again.
An abend.log entry if the issue is a server crash.
If the problem is reproducible at will, what steps you take to reproduce it.
Network configuration information (switched/hubs, routers that might be involved, protocols, number of users per segment and in total, and so on).
Server configuration information (make/model of server, amount of memory, CPU speed and type, network card configs. (Output from CONFIG.NLM is really good for this information.)
Client configuration information (client platform, Novell client version, software installed that might be interacting with the client).
Also include anything that might have some bearing on the diagnosis of the problem.
Remember, the more relevant information you provide, the better we are going to be able to help you without asking for additional information and the faster your resolution is likely to be.
Occasionally, we'll get questions from people who have an intermittent problem that isn't easy to reproduce. These happen once in a while. When such a problem happens, take down as much information as you can about the incident. Being proactive in cases like this (saving console logs, abend logs, and system configuration information) means that when we ask for information about your problem, you can provide it rather than responding with "well, I didn't save the error messages and I don't remember what they were." Without specific information, it's virtually impossible to help you resolve the problem.
Note: The error messages you get tell us exactly what happened at the time of the problem in the system occurs. There is actually very little beyond system-provided information and error messages that can help you towards a speedy resolution.
Organization Is Key to Good Messages
A well organized message is also important. Describe the problem clearly and succinctly. Put some thought into how you are going to express yourself and describe the problem in a clear and understandable manner.
If English is not your native language, do not despair! A number of our SysOps speak multiple languages and chances are we can help you in your native language. (In fact, several SysOps do not have English as their first language, and in some cases English is a second or third language to them).
But keep in mind that in most cases, this means that another SysOp will have to translate for us or that we might use a translation program, and as a result, responses may take longer to write. You may want to try explaining the problem in English as best you can, and then include a more thorough description in your native tongue with the hopes that we can get the general idea about the problem from the English text and deduce more of the details from your more thorough description.
Take a Look at the Available Forums
Take a few minutes to look over the list of forums that are available, then try to pick the best possible forum to post to. You can save yourself some time by trying to place your question in the most appropriate forum. A significant number of users' issues take longer to resolve because the forum they select is not related to the question they are asking.
For example, asking a question about how to protect your GroupWise system from the latest MAPI-exploiting virus in the novell.support.other.alexander-spk forum will most likely get you a "redirection" response, asking you to post your question in one of the GroupWise forums instead. (The novell.support.other.alexander-spk forum is dedicated to supporting the Alexander LAN Server Protection Kit---a server abend analysis and prevention product)
If you are unable to determine which forum is the best forum for your question, go with your instinct. If you guess wrong, you'll still be redirected to the proper place. But if you had asked that GroupWise question in one of the GroupWise forums, chances are you'd guess closer and might get your question to the right people without being redirected.
Rather than post to all of the forums that cover GroupWise, pick just one that seems best suited to the problem. Cross-posting or posting multiple copies of the same message create more work for the volunteers, and duplication of effort is something that reduces the SysOps' effectiveness.
In some cases, a SysOp might end up responding to your post in multiple locations, thereby taking time away from other issues. In other cases, multiple SysOps might be working on the same problem and not even know it, which also is a duplication of effort that impacts the effectiveness of the system.
Remember, there are 117 support forums on the site, and very few volunteers who staff them read every single forum.
How Can I Help?
Occasionally, someone who is interested asks how to become a member of the SysOp team. The SysOps are selected through a fairly rigorous peer-review process, and new SysOps are added on an as-needed basis and by invitation only.
This does not, however, preclude anyone from helping out in the forums themselves. If you have the time, inclination, and expertise, feel free to help others out with their problems--that's how peer-to-peer support works.
Also, if you have a problem that you've posted and you found a solution, post an update telling how you resolved the problem. Your information may help someone else who is struggling with the same problem. Taking the time to follow-up does help others, and someday, someone else's follow-up might help you.
Don't be afraid to jump in and provide advice on someone else's problem, but if you're guessing, please tell the person that you're guessing. Remember that this is someone else's network that you are potentially putting at risk, and providing unsound advice or a "best guess" means that if you're wrong, they could end up in a worse position than when they started.
How Can I Help the SysOps Help Me with My Problem?
Eric S. Raymond wrote a very good guide about how to ask questions in a way that is likely to get you a satisfactory answer. You can get a PDF version of this document (his guide is the preface to another larger document) at http://www.smoothwall.org/download/ pdf/docs/0.9.9/doc.faq.pdf
Be warned, this document is written with an "attitude" and discusses such items as what drives people to volunteer their time to help others and why they like doing this so much. It also contains some guidelines for keeping volunteers interested in their search for solutions by the way you increase the interest level in your questions.
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.