Chapter 35 Troubleshooting ZENworks 7
ZENworks is a powerful tool that saves network administrators much needed time. However, because of the complexity of network environments, problems can occur that prevent ZENworks from doing its job. This chapter covers how to troubleshoot and solve problems with the ZENworks suite.
The first area of troubleshooting we cover is desktop management. Desktop management is difficult to troubleshoot because several network components are involved including the server, clients, eDirectory, and LAN.
The following sections discuss the most common areas to review when you are troubleshooting desktop management issues.
When troubleshooting desktop management issues, if LAN traffic is unacceptable after you create and associate policy packages with objects, you may need to reduce it. One effective way you can reduce LAN traffic is by limiting how the system searches the tree for associations between policy packages and objects discussed in earlier chapters. Limiting the searches should reduce LAN traffic.
To reduce LAN traffic by limiting how the system searches the tree for associations between policy packages and objects, use the following steps in ConsoleOne:
1. Create a container policy package, right-click on it, and select Properties from the drop-down menu.
2. Enable the Search Policy on the Policies tab.
3. Highlight the Search Policy and click the Properties button.
4. On the Search Level tab, set the Search For Policies Up To field to Partition and then click OK to close the Search Policy properties window. This limits how many directory levels are searched for associations between policy packages and objects.
5. Select the Associations tab, and associate this container policy package to the container where you want to make the search policy effective. Remember that the search policy affects all containers below the associated container because the workstation manager looks for the container package.
After you change the search options, the amount of LAN traffic should change to reflect how you set up the search policy.
When troubleshooting desktop management issues, if an attempt to import a workstation is unsuccessful, you may need to troubleshoot import by using the following methods.
NOTE
A workstation does not synchronize with eDirectory until after it has been imported and the Workstation Registration program is run again.
The first step in troubleshooting workstation import issues is to verify that the correct client is installed on the workstation. This client can be installed from the ZENworks Desktop Management CD, or you can download the latest client from Novell’s website.
The next step in troubleshooting workstation import issues is to validate the workstation import policy. First verify that the workstation import policy is enabled for the server that the user is logging in to by using the following steps:
1. From ConsoleOne, right-click the server that the user, not registering his workstation, is logging in to and select Properties.
2. Select the ZENworks→Effective Policies tab.
3. Select the correct platform for the server that the user is logging in to and then click Effective Policies.
4. A policy package should be listed for the workstation import policy. If not, you need to enable the workstation import policy in a server policy package and associate it with the server.
For more information on the import policy, see Chapter 16, “Setting Up Handheld Policies.”
Next check the Registry keys for Workstation Manager to make sure that the workstation is not already imported using the following steps:
1. Launch REGEDIT.EXE.
2. Browse to the following Registry key:
HKEY_LOCAL_MACHINESOFTWARENovellWorkstation
ManagerIdentification
3. Workstation registration may be in three states (No WS Import Policy, Registration, or Imported).
4. Check whether the workstation is in the No WS Import Policy state. If it is, the Registered In, Registration Object, and Workstation Object values either will be NULL or will not exist.
5. Check whether the workstation is in the Registration state. If so, the Registered In and Registration Object values will be populated, but the Workstation Object value will not exist.
6. Check whether the workstation is in the Imported state. If so, the Registered In, Registration Object, and Workstation Object values will be populated.
After you verify the Registry keys, make sure that the Workstation Manager Trusted Tree is set to the correct tree name by using the following steps:
1. Launch REGEDIT.EXE, if you have not already done so.
2. Browse to the following Registry key:
HKEY_LOCAL_MACHINESOFTWARENovellWorkstation Manager
Identification
3. The Tree value must match the tree name the user is logging in to exactly. ZENworks is enabled for one tree at a time, and this tree name is listed here. If the tree you are logging in to does not match this Registry value, all of ZENworks is disabled (including the workstation import policy).
Verify that the Automatic Workstation Import service is running on your server and that an import policy is associated with that server.
Also check to make sure that the workstation is pointed to the import service by having the string of ImportServer=<DNS of the import service server> or ImportServer=<IP address of the import service server > in the following Registry key:
HKEY_LOCAL_MACHINESoftwareNovellENworkszenwsreg
When troubleshooting workstation import issues you can also view the WSREG32.LOG log file at the root of the C: drive. Look for errors and then continue troubleshooting from there.
As a final option you can re-register the workstation by running the register utility from the following location:
C:Program FilesNovellENworkszwsreg.exe
You need to run the register utility twice: Once with the –unreg parameter to unregister the workstation, and a second time with no parameters to re-register the workstation.
The next area of troubleshooting ZENworks Desktop Management we cover is distributed applications. If users encounter problems using distributed applications, after you create application objects and set up application distribution for them, you can use the following procedures to help diagnose and debug the issues.
The first place to start when troubleshooting distributed applications is the Application Explorer. The following sections describe how you can obtain information from Application Explorer to help you troubleshoot problems that your users may encounter.
You can see the applications and their states within a debug window to allow you to know, from the workstation’s perspective, what applications are available and why or why not. This can be opened by launching the Application Window or Explorer. Then select the About box from the menu. Press and hold down the F2 key and click on the More button. This brings up the debug window and provides all the information about the application and its state.
The first issue to consider when troubleshooting the Application Window is getting information about the state of currently running applications. This helps you determine whether any resource conflicts or incompatibilities exist between different applications.
To get information about the state of applications currently running on a workstation, select Start→ZENworks Desktop Management→Application Window and check the status of any running applications.
You can remove the c:
alcache directory from the workstation to get rid of any application distributions that may have become corrupt. This removes all distributed information about the applications from the workstation. The cache will be re-created and repopulated the next time you boot or run the Application Window.
After you have information about files and running applications, look at eDirectory tree-specific information about the tree the workstation is logged in to. Select Help→About Application Explorer and click the More button to view the login information and verify that the workstation is logged in to the appropriate location to receive the application.
After you have looked at Application Explorer, you should view and edit user or container Application Window configurations. This helps you troubleshoot issues caused by problems with the setup of distributed applications in the user and/or container objects. To review the Application Window configuration for user or container objects use the following procedures.
The first step is reviewing the Application Window configuration tab on the properties page for user or container objects in ConsoleOne. Review the following information:
The effective Application Window configurations for a user, organizational unit, organization, or country object
The Application Window configuration inheritance tree (where the current object gets configurations from objects higher in the tree)
Define custom Application Window configurations for the currently selected container object
After you review the preceding information from the main Application Window page in ConsoleOne, you should view the effective Application Window configurations. Effective settings include custom configurations applied to the current object as well as configurations inherited from parent container(s). You can control how a container object inherits Application Window configurations by using the Use as Top of Inheritance Tree option.
To view the custom Application Window configurations from within ConsoleOne use the following steps:
After you review the custom Application Window configurations, you should review the Application Window configuration inheritance tree for the user or container object by using the following steps:
After you review the Application Window configuration inheritance tree, you should review the container’s custom Application Window configurations for the container object by using the following steps:
1. Right-click a user, organizational unit, organization, or country object and click Properties.
2. Click the ZENworks tab; then select the Launcher Configuration tab.
3. Choose View/Edit Object’s Custom Configuration from the Mode drop-down list. If no settings display in the list, no custom settings have been defined for this user or container object.
4. Click the Edit button to customize the settings for this object.
The next step in troubleshooting distributed Application Window problems is to look at the applications inherited by user objects. You may find that the user inherits two applications that are incompatible or that combined take up too much of the client’s resources, and so on.
Use the Show Inherited Applications option on the Tools→Application Window Tools menu to see the application objects associated with the user object, including all applications either associated with or inherited by the user object. The applications are listed by mode of delivery, such as Force Run, App Launcher, Desktop, Start Menu, and System Tray. These categories come from the Applications property page, which is available for user, group, organization, and organizational unit objects.
Use the following steps to list the applications that the user has rights to use:
A useful setting when troubleshooting distributed applications is the Set Refresh Frequency option, which lets you specify the refresh frequency in seconds. For example, if you set the refresh to 300 seconds, Application Window or Application Explorer updates applications from the network automatically every five minutes and might even run some applications depending on how you have set them up.
Although a short timed refresh interval is useful in situations where you want changes to refresh quickly, a short timed refresh interval usually causes higher network traffic.
Another useful step in troubleshooting distributed applications is to make sure that the workstation was properly rebooted with the appropriate files. Occasionally the workstation might not be rebooted or a file might be in use when the application is distributed, preventing it from being distributed properly.
When Application Window distributes applications, it might change workstation configuration files (for example, config.sys, autoexec.bat, or win.ini) depending on the settings in the application object. The changes to these files do not take effect until after the workstation is rebooted. Application Window detects whether such changes are made and prompts the user with a message stating that the workstation must be rebooted before the changes can take place.
Similarly, when application files are copied, the files they are replacing might be in use and cannot be deleted or replaced. Application Window usually handles this situation. Generally, the new files are copied to a temporary area and then copied to their correct locations when Windows is restarted. However, if a problem exists with the temporary area or the workstation was not rebooted, the correct files will not be properly installed.
The next step in troubleshooting distributed applications in ZENworks Desktop Management is to make sure that network resources are being properly cleaned up.
The process of “cleaning up” means that the license for a particular network connection is removed. This prevents users from using a network connection when they don’t need it. When the Clean Up Network Resources option is selected, drive mappings and printer ports associated with Application Window-delivered applications are removed.
NOTE
If the resource (a connection, map, or capture) is already in use when Application Window or Application Explorer is started, Application Window or Application Explorer uses it and does not clean it up. Otherwise, the resource is created and cleaned up when all other Application Window or Application Explorer applications are finished using it. The connection to the server containing the resource is removed as well. If the applications that Application Window or Application Explorer launched are still running when Application Window or Application Explorer is terminated, the allocated resources remain intact.
When an application is launched, Application Window or Application Explorer monitors the executable of the application. When the executable terminates, the process of cleaning up network resources begins. However, it’s possible that the executable filename is actually a wrapper that sets up environments, runs other executables, and then terminates. If Application Window or Application Explorer monitors the wrapper executable, it might prematurely start cleaning up network resources before the application has terminated.
To prevent Application Window and Explorer from prematurely cleaning up an application’s resources, consult your application documentation about whether the application uses a wrapper executable. If it does use a wrapper executable, find out the name of the module that remains running and then type this name, excluding the extension, in the text box provided in the Environment tab located on the Run Options tab of the application object’s properties window in Console One.
As a network administrator, it is particularly useful to keep records for use later. When troubleshooting issues with distributed applications, use the Administrator Notes property page to create a section of notes that only you, as the administrator, can view and edit.
For example, you might want to remind yourself about some special settings for a particular application. This is true especially if several administrators manage your system. You could use the Administrator Notes property page to provide a history of application upgrades and file changes so that work is not duplicated.
To write administrator notes for an application object use the following steps:
When troubleshooting application distribution, be aware that if ZENworks Desktop Management encounters an error during distribution, it rolls back or reverses all the changes made before the error and resets the workstation to the state it was in before the distribution began.
When you roll out or distribute a complex application using Application Window, changes are made to the targeted workstation. These changes might include text files (such as config.sys and autoexec.bat), Windows Registry entries, and .INI files. In addition, application files can be copied or deleted at the target workstation.
The method Application Window uses to roll back changes is simple. First, it creates temporary files and directories to store files and other rollback information on the workstation. If the distribution is successful, those files and directories are deleted. If the distribution encounters an error, Application Window uses the rollback information to restore the workstation to its original state. After that is completed, the rollback information is deleted.
Problems rolling back can occur if a file is in use, the application is set to overwrite an existing application, and so on, when the roll back occurs. Application Window cannot roll back a file that is in use or does not exist.
A useful tool in troubleshooting application objects is the Search and Replace Entire Application Objects option in ConsoleOne. You can use the Search and Replace dialog box to search or search and replace the entire application object for text strings.
For example, if a directory name is changed and the application object no longer functions, you could use this feature to correct the directory name every place it occurs in the application object.
To search and replace text strings in all property pages of an application object, use the following steps:
1. Highlight the application object that you want to search.
2. Choose Tools→ZENworks Utilities→Application Window Tools→Search and Replace.
3. Choose Options and then choose the type of application object settings you want to search.
4. Choose Match Case to make the search case sensitive.
5. Type the text you want to search for in the Search For text box and then click Find Next.
6. If you want to replace that text with other text, type it in the Replace With text box and then click Find Next. Then click Replace or Replace All.
This process can be repeated each time you need to search and replace text strings in the property pages of an application object.
A useful tool in troubleshooting application objects is the Search Specific Application Object property page in ConsoleOne. You can use the Find dialog box to search the current Registry Settings, INI Settings, or Application Files property page.
For example, if a specific Registry setting was causing the application distribution to experience problems, you could use this feature to find the Registry setting in the application object.
To find specific application object settings, use the following steps:
1. Right-click the Application object and click Properties.
2. Click the Registry Settings, INI Settings, or Application Files option pages from the distribution tab.
3. Choose the Find option (in most cases this might appear on the File button).
4. Type the text that you want to find and then click OK.
When troubleshooting application distribution, make sure that the application was terminated properly. You can use the Termination property page in ConsoleOne to view and modify how Application Window handles the termination of an application. If termination is improperly set up, users may experience problems when the application runs.
Use the following steps to view and modify termination of the application:
1. Right-click the Application object and click Properties.
2. Click the Termination property page from the Availability tab.
3. Select and modify the appropriate termination behaviors from the drop-down list.
If users should close the application, use the Send Message to Close Application option. For example, if you set an interval of 20 minutes, Application Window sends a message (if one is active) to the user every 20 minutes until the application is closed.
Use the Send Message to Close Then Prompt to Save Data option if the application must be terminated; however, user data loss may occur. This option prompts users, for a specified period of time, to close the application on their own (this action is optional). When that period of time expires, the Application Window attempts to close the application. If users have not saved data, they are prompted to save it.
Use the Send Message to Close, Prompt to Save, Then Force Close option when the application must be terminated, regardless of user data loss. This option prompts users, for a specified period of time, to close the application on their own. When that period of time expires, you can close the application prompting users, at specified intervals, to save their work. If users have still not closed within a specified period of time, the application is forced to close.
Use the Send Message to Close Then Force Close with Explanation option when the application must absolutely be terminated, and user data loss is not a concern. This option prompts users, for a specified period of time, to close the application on their own. When that period of time expires, the application is forced to close.
Another area that you should be familiar with troubleshooting is the policy packages. No formal method exists for troubleshooting the workstation policy package; however, the following sections discuss some steps you can take to identify problems and resolutions to issues.
In the case of a workstation policy package, make sure that a valid eDirectory workstation object has been created and is linked to workstations that use the policy package. This can be checked by viewing the value of HKEY_LOCAL_MACHINESOFTWARENovellWorkstation ManagerIdentification in the workstation’s Registry.
Registered In : .OU=ZEN.OU=Site.O=Company
Registration Object : UserName, IPX_Network_Address,
IP_Network_Address,
Station_Name, and so on.
Workstation Object :
CN=StationName123456789012.OU=ZEN.OU=Site.O=Company
When looking at this, you are specifically looking for the workstation object value. It identifies which eDirectory workstation object the workstation is using when it is logged in. All workstation policy packages need to be associated with this eDirectory workstation object or to a workstation group that has this eDirectory workstation object as one of its members.
If a workstation policy package is not associated with the eDirectory workstation object listed in the workstation object Registry value or a group it belongs to, no workstation policy packages are downloaded and applied. You can also check for effective policies on the Effective Policies page of a container object’s properties page.
Make sure that the appropriate type of policy package has been created. For example, if the workstation is running Windows 2000/XP/2003, make sure that you have created the corresponding Windows workstation policy package.
In the case of a workstation policy package, make sure that eDirectory workstation objects have an association to the policy package. This can be verified by looking at the details of the policy package within ConsoleOne by clicking on the Associations tab.
Make sure that all the workstations that use the eDirectory workstation object are listed there, are a member of a workstation group listed, or exist in a container listed.
TIP
Make sure to look for potential problems with a container policy package if you are only using the container to associate the eDirectory workstation object. If you are not sure, it is a good idea to associate the eDirectory workstation object directly (as a troubleshooting step, not as an implementation design).
Make sure that at least one policy is enabled to download. If no policies are enabled, the user will not be able to detect any change to the user/workstation environment and may question whether it is working properly.
Make sure that workstations have the active tree listed as a trusted tree. The Workstation Manager component of ZENworks uses the concept of trusted trees, and Windows workstations attempt to search for a ZENworks policy package only if the tree is listed as a trusted tree. This feature gives greater administrative flexibility as to what workstations are controlled by ZENworks.
You can set the trusted tree by selecting the custom installation of the Novell Client for Windows. If Typical Installation is selected, it automatically sets the tree that you first log in to as the trusted tree.
To view the Trusted Tree property on a Windows workstation, view the Registry key directly at the following location:
HKEY_LOCAL_MACHINESOFTWARENOVELLWorkstation Manger
Identification
It’s important that you know how to troubleshoot policy and distribution services. Common types of issues that you need to troubleshoot are covered in the next few sections.
Make sure that the server is associated with the policies that you expect. You can determine the policies that the server is using by going to the server object, choosing the ZENworks tab, and then looking at the Effective Policies page. On this page you can click the Effective Policies button, and ConsoleOne then displays all the policies associated either directly or indirectly with the server.
To see the effective policies for the TED objects, you can go to the TED object and look on the General tab pages. This page displays the effective policy DN.
TIP
Make sure to look for potential problems with a container policy package if you are using only the container to associate the NDS or eDirectory server object. If you are not sure, it’s a good idea to associate the NDS or eDirectory server object directly (as a troubleshooting step, not as an implementation design).
You can also check the policies that the agents are using by entering the policy list command on the ZENworks Server Management (ZFS agent that ZFS.NCF loads) console. This displays the effective policies that the agent on that server is using. Additionally, you can enter policy status to display the order being used, as specified in the container policy. By doing these tasks, you can track down which policy the agents are using.
The connection timeout for the subscriber (administered in the General property page of the subscriber object) determines how long the subscriber waits to receive a package from the distributor. When sending a distribution with patching turned on, the distributor connects with the subscriber, figures out the details of the patch, and then builds the patch on the distributor server. The building of the patch may take longer than the administered connection timeout of the subscriber, causing the subscriber to timeout waiting for the distributor (while it is still building the patch). The distributor then notices that the subscriber has timed out the connection and stops building the patch, putting the distribution back into its queue for the next distribution cycle. This may continue to happen because each time the patch is building the subscriber times out, causing the distribution to never be sent to the subscriber.
The current default timeout for the subscriber and distributor is 3,600 seconds. You may need to increase this in the property pages of the distributor and subscriber.
The system may distribute only to the number of maximum concurrent distributions in the distributor object. So, for example, if the maximum connections were set to 10, only the first 10 subscribers receiving distributions directly from the distributor will receive the distributions.
Set the number of maximum concurrent distributions in the distributor object to the value of 0. The zero value signals the distributor to have no limit.
Alternatively, you may use a combination of parent subscribers to make sure that the distributor never attempts to distribute to more subscribers than set in the maximum concurrent distributions. Remember that the number of subscribers receiving from the distributor is the list of subscribers in each channel where a distribution is placed. But if a subscriber were pulling a distribution from a parent subscriber, it would not make a connection to the distributor and would not take up a connection number on that object. It would take up a connection to the parent subscriber object.
You can also use the priority settings for distributions to ensure that the highest priority distributions will be sent first in the channel. The priority of a distribution can be set at High, Medium, or Low. Medium is the default setting when a distribution is created.
The policy engine and the distributor may report that there was no database specified, or that it was specified incorrectly, when you have installed a ZENworks Server Management database on the network.
The problem is that both of these agents look for a database location policy in a service location package to find where the database is located. If this policy is not defined and associated with the agent objects or the server, the agents will not find the database.
When the subscriber performs an extraction on a distribution that is done with the file agent, each new distribution is only a delta from the previous distribution. To perform the extraction, both the delta and the previous version of the distribution must be accessible to the agent.
When the maximum number of revisions is reached, the file agent builds a new baseline of the distribution that includes a complete copy of all the files. In some cases, when the deltas are large enough and the distribution is rebuilt frequently, the new baseline may arrive when the subscriber is still processing the previous delta.
The new baseline, when it arrives, deletes all previous delta files on the subscriber upon extraction. If a previous delta distribution of the same package is still being processed, the previous delta file will be gone because the baseline extraction has removed the files. This causes the subscriber to fail the delta extraction because the file was not found.
Either you need to set the maximum revisions so far out that you avoid this problem for a while, or you need to space the sending and extraction of the distribution apart sufficiently so that the subscriber has time to perform the extraction before the next distribution is sent.
The ZENworks Server Management traffic analysis system can be a useful tool when debugging LAN-related issues. But there is a possibility for problems with the traffic analysis system itself. The following sections discuss steps to take if you are experiencing problems with the traffic analysis system.
The first step you should take is to check the servers and other devices that have LAN traffic analysis agents on them. Make sure that the agents are loaded (NetWare servers) or started (Windows 2000/2003 servers) properly.
After you verify that the traffic analysis agents are loaded properly, you should check the RMON agent’s settings for the device in ConsoleOne. Verify that the RMON agent is enabled for the nodes you are trying to analyze. Also verify that you have the correct preferred agent set.
After you verify the RMON agent, verify that the settings in the LANZ.NCF files for your NetWare servers are correct. You can also enable the LANZ control screen that can help you understand the current state of the agents.
After you verify the settings in the LANZ.NCF files for your NetWare servers, verify that the settings in the LANZCON utility for your Windows 2000/2003 servers are correct.
The following sections discuss some possible problems in the traffic analysis system and agents and how to resolve them.
A promiscuous mode driver receives all packets and errors on the network. This is required for the ZENworks Server Management traffic analysis agents. The driver currently loaded does not support promiscuous mode; therefore, you need to update your driver for the traffic analysis agents to work.
No SNMP service is currently started on the Windows 2000/2003 server, or the agent is not configured to receive SNMP requests. Start the SNMP server on the Windows server and verify that the IP address of the selected host is included in the trap destination address list. This could also be caused if you have some community string settings wrong or SNMP parameters set wrong on the servers.
Adapter monitoring is not enabled in the LANZCON utility, or the RMON tables have been deleted. Enable adapter monitoring in the LANZCON utility.
The DHCPRELEASE packet from the client has not reached the server, resulting in a false duplicate IP address. Use the LANZCON utility to disable the generation of duplicate IP address alarms.
The most common cause is that adapter monitoring is not enabled. Use the LANZCON utility in Windows 2000/2003 or the LANZ configuration utility in NetWare to enable adapter monitoring.
MIB-2 refers to the information base that the RMON agents are located in. You should reload the agent on the device.
The monitoring agent is not running on the segment, the interface cannot be monitored because the driver is not supported or is disabled, or the statistics entry has been deleted. You should enable monitoring on the agent, update the driver to a promiscuous mode driver, and/or reload the agent.
The segment does not have a supported topology, the RMON agent is not configured or installed correctly, or insufficient memory is on the management server to run the RMON agent. You should first verify that your topology is supported. Second, install or configure the RMON agent. Third, verify that the server has plenty of memory and then unload and reload the RMON agent.
The management console cannot find the interface on the server to contact the monitoring agent.
The LAN adapter may not be loaded on the server. Load the LAN driver for the adapter on the server.
The network card for the server was removed and replaced with a new one. Simply wait until NetExplorer discovers the new card and removes the old one.
You installed or reinstalled a new server on the network but used an IP or IPX address that has been previously assigned. Change the address and run NetExplorer.
The server is down, out of memory, or has a communication problem. If you’re experiencing this sort of problem, first verify that the server is up and running. Next verify that the server has plenty of memory. Then check the connectivity status of all services to the management server by using the connectivity test utility.
The ZENworks Server Management alarm management system can be a useful tool when debugging LAN- and server-related issues through the use of a number of alarm events. But if a problem exists in the alarm management system itself, you may not be notified. The following sections discuss steps to take if you are experiencing problems with the alarm management system.
The first step when troubleshooting the alarm management system is to verify that the SNMP agents are loaded on the servers. The agents are responsible for capturing events as they occur. If the agent is not loaded, events will not be captured. Therefore, check your servers and any other devices, such as a bridge, that may have SNMP agents loaded.
Next check the status of the Alarm Manager database on your NetWare management server. To do this, first make sure that the database is loaded. Then make sure that the server itself is not having problems and that there are no error messages relating to the database.
After you verify that the Alarm Manager database is up, you need to verify connectivity to the devices. Use the connectivity test utility to test the SNMP connectivity between the management console and all devices that you are not receiving alarms from.
After you verify that the SNMP service on the devices in question can communicate with the management console, verify the alarm thresholds for the alarms that you are not receiving. If the alarm threshold is too great, or too little for falling thresholds, it may never be reached and may trigger the alarm.
If you are receiving the alarm, but it shows up as an unknown alarm, there is no alarm template available in the MIB pool. It is likely that the alarm is being triggered by a third-party device or software. If you need to use an alarm that is showing up as unknown, obtain an MIB from the device or software vendor and add it to the MIB pool.
Most issues involving inability to use the ZENworks Server Management servers are results of traffic analysis agent or alarm management issues. The first step when troubleshooting issues involving server management components is to test the traffic analysis and alarm systems. The following sections discuss some additional things you can do to troubleshoot server management problems.
One of the first things you should do when you are having trouble accessing the server management components is to verify that the management console can actually connect to the server itself. Use the ping or connectivity tests to verify that the console can communicate over IP or IPX to the server in question.
Another thing you should do when troubleshooting server management issues is to check whether the remote management agent is properly loaded and running on the server.
You may also want to verify that the port number and password you are using for the RCONSOLEJ utility match the settings on the server you are attempting to remotely manage.
ZENworks Server Management keeps a detailed log file that includes the status of the inventory agents. This log file allows you to troubleshoot server inventory issues effectively. The ZENworks Server Management inventory agents report their current status including any errors they encounter in the SYS:ETCINVAGENT.LOG log file on NetWare servers. The log file is located in the Windows temp directory on Windows 2000/2003 inventory servers.
Another server inventory log file you can use to troubleshoot inventory issues is the INVAGENTPOLICYENFORCER.LOG log file. This file maintains the status of the current invocation of the policy engine allowing you to see the time, type, description, and severity of any errors that occur in the policy enforcer.
When troubleshooting ZENworks Server Management, always be aware of any NetWare error messages that are occurring. ZENworks Server Management is heavily tied into the NetWare operating system, eDirectory, and file system. Therefore, any error occurring in NetWare possibly affects ZENworks Server Management as well.
When ZENworks Server Management is having problems distributing on the server, always look for errors in the NetWare or NT file system. These errors often help you narrow down the problem to a specific cause and resolution.
Another area you should always review when troubleshooting ZENworks Server Management is the eDirectory error messages. ZENworks Server Management uses eDirectory not only for normal authentication and access but also as a service for controlling ZENworks Server Management objects.
eDirectory errors can be categorized as discussed in the following sections.
Some eDirectory background processes require the functionality provided by the NetWare operating system. These processes, such as communication and transaction servers, can return operating system–specific error codes to eDirectory. These error codes are then passed on to the eDirectory background process that initiated a request.
Usually, operating system error codes generated by eDirectory have a negative numerical representation, whereas normal operating system error codes have a positive numerical representation. The numerical range for operating system error codes generated by eDirectory is –1 through –255; inversely, the numerical range for operating system error codes is 1 through 255.
NOTE
eDirectory returns the positive numerical error code rather than the negative error code normally used by eDirectory to return to the application to prevent any incompatibility. Therefore, any occurrence of an error code within the range of 1 through 255 or –1 through –255 should be treated as the same error.
The next class of eDirectory error codes is the client error codes. Some eDirectory background processes require the functionality provided by other eDirectory servers. Use of these functions, such as bindery services, requires that an eDirectory server act as an eDirectory client to the server providing the functionality. Therefore, these functions often result in client-specific error codes being returned to the eDirectory background processes and operations.
eDirectory client error codes are generated by the eDirectory client built into eDirectory. The eDirectory client error codes fall in the range of codes numbered –301 through –399.
Another class of eDirectory error codes is the eDirectory agent error codes. eDirectory agent error codes represent errors that originated in the eDirectory agent software in the server that are returned through eDirectory. These codes are numbered –601 through –799 (or FDA7 through F9FE).
Some eDirectory background processes require the functionality provided by other NLM programs, such as timesync.nlm or unicode.nlm. If any of these modules encounter an error, it can be passed on to the ds.nlm. unicode.nlm and other errors in this category range from –400 through –599.
To effectively troubleshoot eDirectory errors that affect ZENworks Server Management, you should be familiar with the tools available to troubleshoot eDirectory problems. The following tools are provided to monitor and repair error conditions with eDirectory.
The DSREPAIR utility enables you to work from the server console to monitor and repair problems with the eDirectory database on a single-server basis. It does not correct problems on other servers from a single, centralized location. It must be run on each server that you want to correct eDirectory database errors on.
The DSTRACE utility enables you to work from the server console to diagnose eDirectory errors. These errors might appear when you are manipulating eDirectory objects with the administration utilities. eDirectory errors also show up on the DSTRACE screen.
