Chapter 10 NetWare 6 Troubleshooting Fundamentals
This chapter covers the following testing objectives for Novell Course 3004: Novell Network Management:
Describe the Six-Step Network Troubleshooting Model
Document Your Network
Prepare for Network Problem Recurrence
Identify Support Information on the Novell Web Site
Use Novell Support Links to Troubleshoot Problems
Welcome to the final chapter of Part I: “Novell Network Management for NetWare 6.” Today’s lesson is service and support.
As a network administrator, it’s your responsibility to provide service and support for your users and your network equipment. In this context, service and support is defined as configuring and installing hardware and/or software and troubleshooting hardware and/or software problems for NetWare networks.
Service and support responsibilities include the following categories:
Installing, configuring, and upgrading hardware (such as network boards, hard disks, and drive controllers)
Installing, configuring, and upgrading server and other network software
Troubleshooting network problems
The purpose of troubleshooting is to determine the cause of a problem and to implement a timely solution. A problem isn’t considered solved until the problem is no longer negatively affecting the user and the user is satisfied with the solution. The key to troubleshooting is developing the ability to break a problem into smaller parts and to discover the interrelationships between those parts. This ability helps you to efficiently isolate and resolve network problems.
“How,” you ask? Simple: the NetWare troubleshooting model. Check it out.
Test Objectives Covered:
Describe the Six-Step Network Troubleshooting Model
Document Your Network
Prepare for Network Problem Recurrence
Novell’s NetWare troubleshooting model is a useful tool for troubleshooting and resolving network problems. In this model, step 1 involves utilizing quick-fix techniques (which often require little effort and minimal cost). If quick fixes don’t work, you can move on to step 2, where you gather more data (which might involve the use of diagnostic tools and network documentation). After you’ve gathered sufficient data, you can move on to step 3, where you develop a plan to isolate the problem and resolve it. After you have a plan in place, you can move on to step 4, where you execute the plan and test the results. If the results prove unsatisfactory, you’ll need to further analyze the situation and create a new plan. If the results are acceptable, you can move on to step 5, where you ensure user satisfaction. Finally, in step 6, you record a detailed description of the problem and its solution in your documentation log.
To summarize, the six steps of the NetWare troubleshooting model are as follows (see Figure 10.1):
Step 1: Try a quick fix
Step 2: Gather basic information
Step 3: Develop a plan to isolate the problem
Step 4: Execute the plan
Step 5: Ensure user satisfaction
Step 6: Document the solution
As you gain experience with the NetWare troubleshooting process, you’ll begin to build a repertoire of common problems and their solutions. Although the solution to some problems will be quite simple, the solution to others might be complex. In a complex case, you could find that you need to implement a temporary solution to restore service while working on a more complete solution.
The following are some quick fixes that you can try before resorting to the remaining steps in the NetWare troubleshooting model:
Get started—If hard disks are involved, be sure to back up the data and verify the backup before proceeding. Also, consider turning everything off and back on.
Eliminate user error—Next, ask yourself a simple question: “Who says it’s broken?” All troubleshooting calls must come from someone. It’s also helpful to understand the personalities and work habits of users, whenever possible. Many times, a user exaggerates or misdiagnoses a problem. The user might also leave out important details if he feels that he’s done something foolish or something that violates company policy. You should attempt to eliminate the possibility of user error by testing things yourself. When everything works fine, be sure to educate the user before you leave. This should help decrease follow-up calls.
Check the inventory—Be sure all the necessary hardware and software components are accounted for and configured correctly. For example, is the power cord plugged in and is there power at the outlet? Are all the cables plugged in to the appropriate network components? Have any parts been added or removed?
Simplify—Simplify the system by removing unnecessary elements. For example, consider freeing up workstation memory and simplifying the operating environment by preventing the loading of device drivers and terminate-and-stay-resident programs (TSRs). On DOS and Windows 3.1 machines, you can prevent execution of the workstation’s AUTOEXEC.BAT and CONFIG.SYS files by pressing F5 at startup. On Windows 95/98 workstations, you can load Windows in safe mode by pressing F8 at startup and then selecting option 3. (Safe mode starts Windows with no attached devices, no network support, and default settings.) Windows NT–based workstations present a startup menu, by default, with the following safe mode option: Windows NT Workstation Version 4.00 [VGA mode]. On a NetWare server, unload noncritical NLMs and restart the server to see whether the problem is resolved. You can also restore each unloaded NLM one at a time to determine which NLMs run without causing problems. Finally, you can remove expansion slot boards, one at a time, in an attempt to determine conflicts.
Software anomalies—When a software problem occurs, you’ll need to determine whether any error messages are present, which version of the software is installed, known compatibility issues, and the availability of updates and/or patches. The various Web-based Novell support links are good resources (check them out later in this chapter). (Note: Novell Technical Support will not handle your call if you haven’t applied all the latest patches.) Before installing a new update or new patches, you should attempt to determine whether there are any known problems associated with them. Check the accompanying software’s README file and Novell online support forums for important information. Even though installing an update or patches usually enhances performance, it might also cause new problems that didn’t exist previously.
Insufficient trustee rights—If one application runs successfully but another application does not, or if some users can run an application but others cannot—confirm that any user who is experiencing problems has been granted the appropriate trustee rights.
If quick fixes don’t work, the next step is to collect relevant data. This occurs during the data-gathering phase of troubleshooting. During this phase, you should compile the following types of information:
List of symptoms—Develop a detailed list, including symptoms and affected users. Try to determine whether the problem is unique to a single user, a particular group of users, or all network users. Also, attempt to ascertain when and under what conditions the symptoms occur.
Analyze network communications—Determine whether the problem is communications related (for example, if the problem only occurs during peak LAN utilization periods). You can use a protocol analyzer to track network bandwidth and to uncover communications-related anomalies. See Chapter 15, “Novell Troubleshooting Tools,” for more information.
Server configuration issues—If a server is abending, Config Reader can be used to analyze information stored in CONFIG.TXT and to recommend a course of action. (Note: CONFIG.TXT must first be created by CONFIG.NLM, which can be downloaded from support.novell.com.)
Check documentation—In step 6, we’ll discuss the importance of creating and maintaining good troubleshooting-related documentation. However, now, for step 2, you’ll need to utilize this documentation to help isolate the problem and determine possible solutions. You can also use network logbooks to track current LAN usage against normal baseline values. Be sure to document specific details about what users were doing at the time the problems occurred.
User groups—User groups, Usenet groups, and online forums are excellent sources of troubleshooting information. Two of the more popular network user groups are NetWare Users International (NUI) and Network Professional Association (NPA).
Diagnostic tools—Diagnostic tools provide information about your system that can help you isolate problems and solve them. Before choosing a diagnostic tool, be sure that it’s suitable for your particular network configuration. Also, be sure that it has an efficient user interface, that the tool meets your reporting requirements, and that adequate technical support is available.
After you’ve gathered all the required diagnostic data, the next task is to use the information you gathered, along with background knowledge you have of the LAN, to determine whether the problem is a result of operating system, application software, equipment, or user error.
When you’ve determined the source of the problem, your next step is to develop a troubleshooting plan of attack. The best approach typically includes a combination of intuition and methodology. First, you should use your intuition to identify the top two or three most likely causes of the problem (that is, hypotheses), as well as to determine how long it will take to fix or eliminate each cause. Potential costs to keep in mind include technician time, parts, and equipment downtime.
Then you’ll need to develop a logical plan of attack for testing each hypothesis. Different strategies include prioritizing each hypothesis based on its likeliness as a cause of the problem or first attacking any hypotheses that can be tested quickly. For example, consider a problem with three possible solutions: Hypothesis A requires 2 hours with a 70% chance of success; Hypothesis B requires 1.5 hours with a 25% chance of success; and Hypothesis C requires 15 minutes with a 5% chance of success. In this example, the best way to proceed would be C, A, and then B. Why? It’s logical, my dear Watson. First, start with the quick 15-minute fix. If that doesn’t work, spend your troubleshooting time wisely and go for the hypothesis that has the greatest chance of success. Finally, keep in mind that the percent of success is not mutually exclusive, and the numbers can total more than 100.
After you’ve developed your troubleshooting plan, the next step is to execute it. Step 4 utilizes the following scientific approach:
Break your plan (or each hypothesis) into small, easily testable components. For example, if the problem is an interruption of network traffic between two nodes (A and B), you might want to consider the following:
Network card in Node A is bad.
The cable segment to the backbone is experiencing problems carrying the signal.
The router going to the backbone is experiencing problems routing the signal.
The backbone itself is bad.
The router between the backbone and the cable segment for Node B is experiencing problems routing the signal.
The cable segment for Node B is experiencing problems carrying the signal.
The network board for Node B is faulty.
Test each component by changing only one thing at a time. Otherwise, you won’t know which change solved the problem.
After you’ve finished testing each component, document your results, return the component to its original state, and then move on to the next test.
Use only reliable test equipment, software, and procedures. If you use a faulty utility disk, for example, you might become more confused than when you started.
Use forward, backward, or binary chaining to eliminate possible network communications problems. Be sure to use reliable test equipment, diagnostics, and/or software procedures. (After all, you don’t want to exacerbate the problem during the troubleshooting process.) When using forward or backward chaining, be consistent in your approach. Don’t start at one end, test, and then move back to the other end. Be systematic and controlled as you move from the source device to the destination device (forward chaining) or from the destination device to the source device (backward chaining) until the problem is located. Alternately, you can use binary chaining, which enables you to start halfway between the source device and destination device, isolate the problem to one of the halves, divided the isolated segment in half, repeat the process with the two new halves, and so on.
Watch for blind spots (which occur when the tester doesn’t realize something that’s obvious). If you suspect a blind spot, try consulting a trusted colleague, or take a break and think of something else.
If the plan is unsuccessful, access additional resources, such as the Novell Support Resource Library Web site at support.novell.com.
Even when you find and resolve a network problem, it isn’t actually fixed until the user (and/or the user’s manager) is satisfied. Although some users will be happy just knowing the problem has been solved, others will want a detailed explanation of the problem and solution, and/or training on how the network should work versus how it’s currently working.
Also, verification that a problem has truly been fixed can be dependent on the nature of the problem. Some solutions, for example, might have to be monitored for hours (or days) to ensure success.
Documentation is a critical but often overlooked step in the NetWare troubleshooting model. Although solving a problem is important, many network problems reoccur. This means that those who don’t learn from history are destined to repeat it. Whenever you discover a solution to a problem, record the problem and solution in your problem resolution log. Conversely, whenever a problem arises, one of the first sources you should consult is the problem resolution log.
The following are the three main aspects of network documentation:
Network components—You should document where all your network hardware and software are installed and how they’re configured. This information forms the foundation of your network documentation.
History and users—Next, you should track how the network is being used and important events that have occurred.
Resources—Then, you should generate a list of resources for troubleshooting help, such as bulletin board systems (BBSs), Web sites, and technical-support phone numbers.
eDirectory—Finally, you must document the design and implementation details of eDirectory to ensure that all physical resources are represented appropriately in the logical eDirectory tree.
Now, let’s explore the first three documentation components in more detail. In Chapter 17, “Novell eDirectory Troubleshooting,” we’ll discover the magic of eDirectory troubleshooting in great depth.
Network component records form the core of your troubleshooting documentation. You should keep track of where everything is, how many components there are, how they are related, and who uses them. Consider the following three documents:
LAN diagram—Two types of useful network maps are logical maps and physical maps. Logical maps are topology overviews that focus on internetworking devices and connecting workstations. Their purpose is to establish the relationship between these devices and to show the flow of data. Physical maps, on the other hand, show a spatial representation of where various components are located. These detailed graphics should indicate the location of all servers, workstations, printers, bridges, gateways, repeaters, and wiring centers, as well as users and user groups. This information enables you to quickly locate, for example, a particular server or workstation. Refer to Chapter 19 for a sneak peek at ACME’s physical LAN and WAN maps.
LAN inventory—It’s important to maintain an up-to-date record of hardware, software, and peripherals used with your network. You might want to purchase software that maintains such records. In addition, you’ll want to document the following five network components:
Servers—Server documentation should include a detailed inventory of both production and test servers, including information such as location, manufacturer, model number, operating system, hard disks, LAN cards, and other peripherals.
Clients—Client documentation should include the number of workstations and the type of network interface cards (NICs) the workstations use. Client documentation should also include each workstation’s configuration, processor speed, RAM, and its role on the network.
Internetworking devices—Repeaters, concentrators, bridges, routers, and gateways should all be well documented, including information such as vendor, model, location, and general connections.
Cabling diagram—You’ll want to ensure that you have an accurate record of the type(s) of cabling used in your network and its physical layout. This can be invaluable when attempting to solve cabling problems.
Spares—A spares inventory is one of your most powerful troubleshooting assets. Basically, it is a collection of spare networking components. Similarly, the spares inventory catalog is one of the most critical types of network documentation. It tells you what options are available during steps 2, 3, and 4 of the NetWare troubleshooting model. Some network administrators might wonder whether a spares inventory is really needed if you a have a maintenance contract. The answer depends on what kind of contract you have and how patient your users are. Some contracts specify that the customer is responsible for maintaining the spares inventory. Also, if you have mission-critical services going through your network, it’s unlikely your users will be patient, and, thus, you might need to maintain a large spares inventory.
Chronological change log—This log documents network modifications, such as hardware additions and deletions, software upgrades, and configuration changes.
An accurate, detailed record of your LAN’s history can help you solve current problems and prevent future catastrophes. One of the most important aspects of a LAN history is a solid understanding of the business environment and the users on the LAN. This area of network documentation focuses on five main concerns:
LAN utilization—LAN utilization information documents who the customers are and what services the LAN provides to them. It also outlines where LAN utilization problems have occurred in the past.
Change order log—The basic goals of a change order log are to maintain trend information on various systems and to document equipment repairs. This log adds accountability to changes made to the network. At a minimum, you might want to maintain a record of what has occurred over the past two years, including a description of problems and solutions, the location of problems (that is, the segment on which the situations occurred), and a record of incurred downtimes. You might also want to maintain a record of ongoing performance analysis for devices such as printers and routers.
General business model—You should record the business purpose of your network, paying particular attention to how the network benefits the people who paid for it. When considering upgrades, they should be measured against this model. This is also a good place to record your company’s mission statement so that you can ensure that the network is serving the organization’s business interests as a whole.
User data—User data should include enough information to help you characterize different network users. For example, you might want to list usernames, a description of how each user utilizes the network, the servers they access, and training records. This documentation can be useful in helping you isolate problems and/or justifying equipment upgrades.
Baseline information—Maintaining baseline information can be useful for troubleshooting purposes. For example, you might want to maintain baseline statistics relating to CPU use, network traffic, bandwidth use, errors, and other information regarding how the network functions under normal conditions.
Resource documentation is usually relatively easy to maintain. The easiest way to store it is as ASCII data on a host file server, although this might not be the most useful method. For those with documentation flair, a database program or a spreadsheet can be employed for fast searching and sorting. You might also want to check out the inventory features available in the Novell ManageWise and ZENworks products. Regardless of how you store the resource list, be sure to update it carefully and to print a hard copy at least every other week (unless no changes have been made).
You’ll want to keep track of the following two types of resources:
Technology documentation—Make sure that you have access to important technical documentation before it’s needed, including information about protocols, routing, and LAN architecture.
Technical support—It’s important to maintain information relating to key technical-support contacts (including phone numbers and business hours) for the various products that you use. You’ll also want to maintain a list of useful Internet Web sites and bulletin board numbers.
TIP
You should ensure that serial numbers are included in your resource list. When you have a problem, tech support might require a serial number or license information. If the data is located on the same list as the phone numbers, the matter can often be handled more quickly and easily than if you cannot find the information.
Another good reason to document problems and their solutions is that documentation can uncover troubleshooting patterns. For example, you might find that a batch of NICs is bad or that flaky power in one part of the building is damaging equipment. Being able to identify a pattern enables you to take proactive rather than reactive measures, therefore, avoiding network problems before they occur.
Implementing proactive strategies involves attempting to avoid or prepare for recurrence. Try these proactive strategies:
Proactively check network hardware components for operability. For example, if a component keeps burning out, either install a cooling fan or keep a supply of replacement parts on hand.
Test the system on a regular basis, even if it isn’t experiencing problems. Make sure that you use only up-to-date virus scanning and network performance-monitoring software. To ensure that tests are accurate, periodically introduce problems into the network in a controlled manner prior to testing. (Note: During such tests, consider using Config Reader to analyze the information.) Make sure that all team members are aware of the importance of this testing and that they properly document it.
Maintain an up-to-date network map and floor plan to help spot potential problems.
Keep handy copies of important technical information documents (TIDs) and other vendor-supplied documentation.
That completes Novell’s NetWare troubleshooting model. Hopefully now you are a well-trained doctor of NetWare medicine. To summarize, step 1 involves utilizing quick-fix techniques, which don’t always work. In that case, step 2 provides some data gathering help and step 3 provides a plan to isolate problems and resolve them. In step 4, you execute the plan, so you can ensure user satisfaction and document your LAN in steps 5 and 6, respectively.
Now, let’s complete this final network management chapter with a look at Novell’s greatest diagnostic and troubleshooting tools. Go team!
Test Objectives Covered:
Identify Support Information on the Novell Web Site
Use Novell Support Links to Troubleshoot Problems
If the NetWare troubleshooting model seems daunting at first, it is! The good news is that you aren’t alone. Novell Support is only a click away with a variety of useful research tools in two categories:
Diagnostic software—Diagnostic software can be useful for providing information about your network, as well as for isolating and solving problems.
Novell Internet services—Novell information can be accessed via the Internet at the following sites: Novell’s home Web site, the Novell Support Resource Library Web site, and Novell’s FTP sites.
Let’s take a closer look.
Various types of shareware, freeware, and commercial diagnostic packages are available at varying price and quality levels. Some programs, however, are incompatible with specific hardware and/or software configurations.
For example, Microsoft Diagnostics (MSD) is a fairly complete system diagnostic tool that’s available for systems that use MS-DOS 6.2 and later. Similar information is available in Windows using the Device Manager tab under the System icon in the Control Panel. Windows also provides a System Information Tool that can be accessed by selecting Start @@> Programs @@> Accessories @@> System Information.
Popular commercially available, third-party software applications include CheckIT, PC Doctor, and PC Clinic. Finally, shareware diagnostic utilities can be located at the users.powernet.co.uk/sysserv/page146.html Web site or by accessing www.google.com and searching for shareware diagnostics.
Consider the following factors when evaluating diagnostic software for purchase:
Compatibility with your particular hardware configuration
Easy-to-use interface
Satisfactory reporting capabilities
Adequate and timely technical support
Some of the diagnostic tool capabilities you might require include the ability to furnish the following:
Hardware and operating system information (which is useful for record-keeping purposes)
Inventory of internal computer components, such as processor type, BIOS date, and amount of RAM
Information needed for detecting and avoiding hardware incompatibilities, such as I/O addresses, memory addresses, and IRQs (hardware interrupts)
System information relating to device drivers and TSRs (which is useful for determining software conflicts)
Compatibility information associated with hardware and peripheral devices and with expansion boards you want to install.
You might need diagnostic tools that provide the following additional capabilities:
View and edit complementary metal oxide semiconductor (CMOS) information. This type of utility can be useful for protecting a computer’s CMOS against battery loss and for restoring CMOS information to other machines with the same configuration. The latter capability is particularly useful in large networks that contain many nodes with identical configurations.
Generate system performance benchmarks, which enables you to evaluate your system and to compare your system to other systems
Run hardware diagnostic tests on components, such as hard disks, disk drives, system boards, serial and parallel ports, and RAM.
Supply performance enhancement capabilities, such as the following:
Uninstall utility—Identifies and deletes files associated with Windows applications that are no longer needed.
Cleanup utility—Removes unnecessary files.
Memory tune-up utility—Consolidates Windows memory fragments and increases the largest memory block available.
Provide compatibility with other diagnostic software.
Novell’s Internet sites provide you with the technical information, resources, and contact information you need to help you manage and troubleshoot your network effectively. For example, these sites provide access to Novell company information, product information (including the Novell Buyer’s Guide), press releases, and information about events and promotions. Other resources available include network services, technical support (including technical information documents[TIDs], as well as hardware and software bulletins from Novell Labs), downloadable files (including files, patches, and fixes), and user forums. Finally, these Web sites list information about training and services, partners and developers.
To navigate Novell’s Internet sites, you’ll need an Internet browser, such as Netscape Communicator or Microsoft Internet Explorer. You’ll also need reliable Internet access (using either a direct or dial-up modem connection) through an Internet service provider (ISP).
After you’ve installed and configured your browser, TCP/IP (if used), and communications parameters, you can access Novell Internet Services at the following sites:
Novell’s home page—www.novell.com
Novell’s Support Connection Web site—support.novell.com
Novell’s FTP sites—ftp://ftp.novell.com
The Novell Support site is an important source of Novell technical information. (Refer to the Novell Support Resource Library home page in Figure 10.2.) This page provides such important information as the following:
Online Product Support—Here you can find links to free server abend analyses as well as to other free support tools and solutions to problems reported by customers. Documented solutions can be culled from TIDs and customer forum links, which have been provided by Novell Technical Support Engineers and knowledgeable customers. Other important links include the knowledgebase (a text search utility that provides TID and product documentation results), product updates (patches and files), product support forums, product documentation, and Cool Solutions (solutions to various enterprise networking problems determined by users of Novell products).
Paid Product Support—This includes links to fee-based support programs for Novell customers.
Novell Technical Subscriptions—These annual subscription services provide technical resources and time-saving procedures for managing your Novell environment. If you subscribe, you’ll be entitled to evaluation software, updates to Novell software, and advanced resources, all of which is provided on CDs, DVDs, or online using portal services. None of this can be obtained through the free online support content links.
Downloads—This is a vital link. Here you have access to an extensive download library of software, including full (or limited) versions of software, support packs, client upgrades, snap-ins, and evaluation software for Novell products.
Developer Support—Using this link, you can get privileged information from a community of Novell customers who develop software independent of Novell. Developers create utilities and enhancements to Novell products for their employers or for distribution to other Novell customers.
Other Resources—A variety of miscellaneous links include support frequently asked questions (FAQs) and the support life cycle for shipping products and discontinued products. You can also use the Other Resources links to request product enhancements or report product defects.
Novell also provides anonymous access to several File Transfer Protocol (FTP) server sites at ftp://ftp.novell.com. You can use your Web browser or a dedicated FTP client to access the FTP servers. Most publicly accessible FTP servers allow anonymous access. When you log in to an anonymous FTP server, you’ll be prompted for a username and password. Proper Internet etiquette requires you to enter anonymous at the login prompt and your Internet email address at the password prompt. This allows FTP server administrators to get some idea about the type of users who access their site.
Refer to Table 10.2 for a comparison summary of the two main troubleshooting tools we have discussed in this chapter: Diagnostic Software and Novell Internet Services. Keep in mind that the same information is often available from multiple sources.
Congratulations!
You’ve survived the first leg of our exciting NetWare 6 CNE journey—Novell network management with NetWare 6. In this first part, we started with NetWare 6 installation, upgrade, and migration. Then, in Chapter 3, we shifted our focus to the NetWare 6 server and learned how to ensure that it stays fine-tuned and in peak condition. In Chapter 4, we tackled NetWare 6 client management with the help of iFolder. After we installed NetWare 6 and migrated any legacy servers, you learned how to build, prune, and maintain your new eDirectory tree.
In Chapters 6 and 7, we expanded beyond the NetWare 6 server to discover pure IP! You learned how NetWare 6 supports native access to TCP/IP networks, and the Internet, with the help of DNS/DHCP Services, IPX compatibility, network address translation (NAT), Service Location Protocol (SLP), and Novell’s Enterprise Web Server. Next, we explored server and network optimization in Chapter 8, and learned how to manage NetWare 6 advanced security using public key cryptography and the NetWare 6 Novell Certificate Server.
And that brings us full circle to this final chapter of Part I. In Chapter 10, you learned how to troubleshoot hardware and/or software problems for NetWare networks using both the NetWare troubleshooting model and some great troubleshooting tools.
Wow, that was quite an exhausting warm up. Now it is prime time: Advanced Novell Network Management for NetWare 6. Strap on your shock-absorbing running shoes because this is going to be a great trip.
Novell’s Internet Services include the Novell corporate Web site, the Novell Support Resource Library Web site, and the Novell FTP site. In this exercise, we’ll examine four real-world cases for using Novell’s Internet Services. Therefore, to perform this exercise, you’ll need Internet access to various Novell Web sites.
Your (English-speaking) next-door neighbor just purchased a new Windows 95/98 workstation and needs the latest version of the Novell Client. Walk him through the steps for finding and downloading the appropriate file via the Internet so that he won’t have to call you the next time he needs an updated copy of a file.
Rumors are circulating at the office about possible layoffs. You’ve checked the help wanted ads in the newspaper and noticed that many positions require a CNE. Access the Novell Training site on Novell’s home page to get information on CNE certification requirements.
Your boss has asked whether Novell offers pay-as-you-go technical support, and if so, whether the billing method is per minute or per incident. Access the Internet to find this information.