ManageWise 2.5 Configuration and Usage Tips
Articles and Tips: article
Senior Consultant
Novell Consulting, Asia Pacific
01 Jul 1998
Thanks to Peter Kaim, Jothin Vallathol, Christo Van Rensburg, Brent Vernon, Steve Quinne, and Raphael Kochuvaried for their input.
Want to really get under the hood of ManageWise and rev it up for large networks, help desk environments, and software licensing purposes? This AppNote shows you how.
- Introduction
- Controlling ManageWise Traffic on Very Large Networks
- Defining a TRAP Forwarding Strategy
- TRAP Handling Process
- Help Desk Environments
- Miscellaneous Information
- Conclusion
Introduction
ManageWise 2.5 is the latest release of Novell's award-winning management product. There are some significant new pieces of functionality included in ManageWise 2.5. Novell Consulting field experience shows that there is much which can be achieved with ManageWise if you understand how to configure the product properly.
This AppNote discusses how to use ManageWise in a number of different scenarios:
Controlling ManageWise traffic on very large networks
SNMP trap consolidation
Help Desk environments
Using Inventory for software licensing agreements
Miscellaneous information
This AppNote assumes readers are familiar with ManageWise and have ManageWise installed in their organisations. For additional information, refer to "Extending ManageWise for the Challenges of the Enterprise" in the July 1996 issue and "ManageWise 2.1 Configuration and Usage Tips" in the January 1997 issue of Novell AppNotes.
Note: All of the material in this AppNote is applicable to ManageWise 2.6, due for release in mid-1998. An upcoming AppNote will discuss the additional functionality and deployment of ManageWise 2.6.
Since this AppNote was written in Australia, it retains the original British spelling used by the author.
Controlling ManageWise Traffic on Very Large Networks
Administrators in very large networks are quite sensitive to the amount of management traffic which can be generated due to "noisy" servers and agents. Two areas which can be controlled in a Novell network are Service Advertising Protocol (SAP) packets and SNMP TRAP packets.
Controlling SAP Packets
There are many different services which are advertised by servers, some of which can be eliminated. SAPs are broadcast on a regular interval and a maximum of seven services can be advertised in a single SAP packet. In a NetWare 4 network, SAP 026B is broadcast by all servers in a Time Provider Group. This can be eliminated by the use of TimeSync Configured Lists. (Refer to the AppNote "Time Synchronization in NetWare 4.x" in the November 1993 Novell AppNotes for more detail.)
The ManageWise Agents are also responsible for a number of SAPs being generated. For each service loaded on a server, a SAP will be generated. The following list indicates SAPs which might be seen when ManageWise is loaded on servers in a network:
|
0x004 |
NetWare File Servers |
|
0x04B |
Btrieve Server |
|
0x007 |
Print Servers |
|
0x047 |
Print Servers |
|
0x102 |
ManageWise 2.1 Virus Protect/ Intel LANDesk Virus Protect |
|
0x107 |
Remote Console (RConsole) |
|
0x233 |
NetWare Management Agent 1.6 (ManageWise 1.0) |
|
0x237 |
NetExplorer Server |
|
0x238 |
NetWare Management Agent |
|
0x239 |
HMI-compliant Hubs |
|
0x23A |
NetWare LANalyzer Agent (NLA) |
|
0x26A |
ManageWise Console |
|
0x27B |
Netware Management Agent 2.1 (ManageWise 2.0, 2.1 and 2.5) |
Many of these SAPs are used by ManageWise to determine which services are loaded on servers in the network.
Novell Consulting has developed several tools to help in working with SAP packets: SLIST.EXE and SAPSNOOP.EXE. Both are available for download from the NetWare Tools Page on the Novell Consulting Web Site at http://www.novell.com/programs/ncs/toolkit/iw_tools.html.
Novell Consulting SAP Spoofing Utility
Novell Consulting has written some code to spoof these SAPs so they can be filtered at the server. The SAP Spoofing Utility is available for download from the Novell Consulting ManageWise Tools Page.
SAPs can be filtered outbound from a server via the INETCFG and FILTCFG NetWare Loadable Modules (NLMs). The ManageWise console requires an additional piece of code to list the services that require spoofing. The next time the ManageWise console is launched, it writes the list of selected services to the ManageWise console database so that these services appear against each nominated server. When the user selects a service, it will try to retrieve information from the server for that service. If the service does not exist on the server, it will time out. This is preferable to the traffic caused by SAP packets for these servers. Obviously if all servers have NetWare Management Agents loaded, the chance of timeouts because agents are not loaded will be minimal.
Windows RConsole without SAP 0x107
Usually RConsole requires SAP 0x107 to be present on a server before the server is listed in the list of servers which can be remotely controlled. Novell Consulting has developed a Windows-based version of RConsole, similar in appearance to the RConsole in ManageWise, which no longer requires SAP 0x107. REMOTE.NLM and RSPX.NLM still need to be loaded on the server; however, SAP 0x107 may be filtered at the server. This version uses SAP 0x004. If REMOTE.NLM is not loaded at the server, RConsole will eventually time out.
Inventory without SAP 0x102
ManageWise Inventory usually requires SAP 0x102 to be broadcast in order for the inventory scanner to determine the nearest Inventory Server. The LDINV.NLM broadcasts SAP 0x102. The WLDISCAN and LDISCNNT programs both support inventory transfer via IP. (LDISCAN does not support Inventory transfer via IP.)
SAP 0x102 may be filtered at the server if all workstations nominate the IP address of the Inventory servers. SAP 0x04B is also broadcast by servers with the BTrieve database loaded. SAP 0x04B can also be filtered.
ManageWise Consoles Broadcast SAP
By default each ManageWise Console broadcasts SAP 0x26A. This SAP is used with the FINDNMS.NLM on a NetWare Management Agent; the LANZCTL.NLM with NetWare LANalyzer Agent and the Find ManageWise Console Service with the ManageWise Agent for Windows NT Server. If one of these processes detects a SAP 0x26A, it adds the Network:MAC address combination to a list of addresses to send SNMP Traps to. Trap targets should be statically defined in a server's SYS:\ETC\TRAPTARG.CFG file, or on a Windows NT Server, in the Control Panel | Network | SNMP Services | Trap Targets list.
Disabling SAP 0x26A
SAP 0x26A should be disabled at the ManageWise Console via the pull-down menu Configure | Global Preferences | Receive NetWare Server Alarms. Make sure this option is not checked.
Edit the SYS:\SYSTEM\NMA2.NCF file and remove the LOAD FINDNMS statement. Edit the SYS:\SYSTEM\UNNMA2.NCF file and remove the UNLOAD FINDNMS statement. Edit the SYS:\SYSTEM\LANZ.NCF file and modify LOAD LANZCTL TRAPREG=1.
On a Windows NT Server, modify the Control Panel | Services | Find ManageWise Console service to disable the service.
Defining a TRAP Forwarding Strategy
In a large network it is necessary to control the flow of TRAPs to where the administrators are located. By default, every ManageWise Console will broadcast SAP 0x26A (unless it is disabled), and excessive numbers of TRAPs will be forwarded around the network as a result.
There are two tasks which need to be completed. First, determine which TRAPs are critical to the organisation's server and network management needs and ensure these TRAPs are received. Second, determine which administrators need to know information about which servers and devices in the network.
Figure 1 illustrates an example where an organisation forwards all TRAPs to a central location.
Figure 1: Support Group consoles design.
In this example there are four specialist groups: Network Operations, Server Support, Desktop Support, and GroupWise Support. In this case, TRAPs are forwarded from remote servers to a Trap forwarding console. This console forwards TRAPs to the relevant support group depending on the TRAP-- GroupWise TRAPs to the GroupWise Support group, and so on. A ManageWise Console could be dedicated for receiving TRAPs in each support group (hence ManageWise "Monitor"). Engineers "control" devices using their own workstations with ManageWise "Control".
Determining TRAPs
In a NetWare Management Agent, it is possible to control the TRAPs which are transmitted by NWTRAP.NLM. These TRAPs are exposed in the SYS:\ETC\NWTRAP.CFG file. NWTRAP.NLM reads the NWTRAP.CFG file at load time to determine which TRAPs should be sent. By default, all TRAPs will be transmitted. To stop TRAPs from being transmitted, the hash character (#) should be removed from the beginning of the line defining the TRAP Number, as shown in the following extract:
# "System: NLM unloaded" !!!! MASKED 226
An edited version of this file is available on the Novell Consulting Web site. It is advisable to document which TRAPs have been masked as illustrated above. It is hard to identify which TRAPs have been masked by just scanning down the file listing, unless some comments have been added.
It is also possible to set a time interval in seconds between the transmission of two instances of the same TRAP. This should be set to 600 seconds (10 minutes). This is achieved by setting the Interval parameter in SYS:\ETC\NTRAP.CFG file.
Removing Unwanted TRAPs
Only TRAPs originating from NWTRAP.NLM can be blocked at a server. All other TRAPs are broadcast, so an alternate mechanism must be developed to block non-critical TRAPs. One strategy is to pass all TRAPs in a geographic region through a trap-forwarding device, which only forwards those TRAPs which are critical. All other TRAPs are dropped at the trap forwarder, simply by not forwarding the TRAPs (see Figure 2).
Each server, or network device, would have the address of the nearest Trap Forwarding Console defined in its Trap Target file: in the case of a NetWare server, SYS:\ETC\TRAPTARG.CFG, and for a Windows NT Server, in Control Panel | Network.
Figure 2: Any TRAPs that are not forwarded by the Trap Forwarding Console are effectively dropped.
Determining Who Needs TRAPs
Not every administrator needs all TRAPs. Draw up a matrix of the information needs of each group of administrators and the source servers they are responsible for. A larger organisation may have more than one administrator and it makes sense to give administrators a ManageWise console to control the servers they are responsible for. This strategy can cater for multiple tiers of management, whereby first level support may be performed at a regional support centre and second tier support may be undertaken at the central site.
Below is an example of a table defining which administrator needs what TRAPs.
|
Server Type |
TRAP Forwarder |
TRAP Receivers |
|
NetWare Servers |
Trap Forwarder Console(e.g. 164.99.32.10) |
Server Support's ManageWise Console |
|
Backup Servers |
Trap Forwarder Console(e.g. 164.99.32.10) |
Backup Administrator's ManageWise Console |
|
Messaging Servers |
Trap Forwarder Console(e.g. 164.99.32.10) |
Messaging Group's ManageWise Console |
|
NT Servers |
Trap Forwarder Console(e.g. 164.99.32.10) |
NT Applications Admin's ManageWise Console |
There are several third-party solutions for trap forwarding including:
Genevasoft AlertPage Enterprise - www.genevasoft.com
Compu-Shack Trap Console - www.cscare.com
Gecko SNMP Forwarder - www.gecko.de (take the English option)
Note: Trap forwarding can only be undertaken with SNMP TRAPs over IP. The IETF specification for SNMP over IPX does not define a method to place the originating trap device's IPX address into the Agent Address field of a trap packet. As such it will be necessary to define an IP address for each server and define an IP address for the trap forwarding console in each server's SYS:ETC\TRAPTARG.CFG file.
Editing TRAPs
SNMP TRAP packets are a transmitted by an SNMP Agent, when a particular incident or threshold is reached on that device. The Agent transmits the TRAPs to the devices (SNMP Managers) listed in the Agent device's Trap Target file. The Manager is able to interpret the information sent by the Agent if it has the relevant MIB (Management Information Base) file. This is a text file in ASN.1 (Abstract Syntax Notation) format. The text follows a well defined structure and typically consists of Identification, defining Objects for MIB Browsing, and finally, the TRAPs able to be sent by the Agent. The MIB tells the Manager how to react to a given trap, what data type it might be, what severity level the trap is, and what operational state the Agent will be in after the Trap has been sent.
Generally, an MIB Compiler will compile all MIBs and create a binary file which is read at the time the management console is started up. The information in the MIB file at the time the MIB is compiled will determine how the SNMP Manager Console will treat a given trap. Editing severity levels, or removing certain TRAPs, will effect how the trap is dealt with.
ManageWise Specifics for Editing TRAPs. ManageWise deals with TRAPs in a similar manner as described above. TRAPs to be compiled are stored in the c:\mw\nms\snmpmibs\current directory. It is wise to take a copy of all MIBs in this directory before editing them.
Typically TRAPs are located toward the end of the MIB file. Using a text editor, search for TRAP-TYPE. Each instance defines a new Trap. To delete a particular trap, delete all lines from one instance of TRAP-TYPE, up to but not including the next instance of TRAP-TYPE.
The SUMMARY lines indicate the message which will be displayed at the console when the Trap is received.
SEVERITY and STATE are the Severity Level and Operational State which will be displayed for the device which transmitted the Trap. These can be upgraded/downgraded using the levels defined in the following table.
volDismountedDueToDriveDeact TRAP-TYPE --1.6.1.7.35/1.2.5.7.27
ENTERPRISE nwalarm-mib
VARIABLES {
serverName,trapTime,volumeName
}
DESCRIPTION
"The volume dismounted due to driver
unload, disk failure, or OS-initiated
driver unload."
--#TYPE "FileSys: Vol dismounted, drive deactivation"
--#SUMMARY "Volume %s dismounted due to drive "
--#SUMMARY "deactivation on server %s."
--#ARGUMENTS {2,0}
--#SEVERITY CRITICAL
--#TIMEINDEX 1
--#HELP "nwalarm.hlp"
--#HELPTAG 144
--#STATE DEGRADED
::= 144
Note: A number of third-party devices' MIBs have been edited by the Novell DeveloperNet team and are available at:
http://developer.novell.com/support/sample.htm
These can be searched for at the Sample Code and Issues Web site. Seach for MIBs in the ManageWise section. This is a service provided to customers; the MIBs may not necessarily be the latest ones released by the third-party vendors.
Altering Severity Levels or Operational States. Sometimes a SEVERITY level or operational STATE may be incongruous or wrongly defined in the MIB. This can be altered by editing the MIB value to one of the following:
|
Severity |
State |
|
|
Most Severe |
Critical |
|
|
Major |
Nonoperational |
|
|
Minor |
Degraded |
|
|
Informational |
Operational |
|
|
Least Severe |
Unknown |
Unknown |
Compiling ManageWise MIBs. The ManageWise MIB Compiler can be accessed under the Tools | MIB Compiler option, or it can be run as C:\MW\NMS\BIN\MIBC.EXE. When the MIB Compiler is run, it creates a new version of the SNMPMIBS.BIN file which is read as the ManageWise Console is launched. The MIB Compiler also updates the Alarm Disposition table, C:\MW\NMS\NMSDB\TRAP.BTV. If some of the TRAPs are removed from the source MIB files, they may still appear in the Alarm Disposition Table. To clear out unwanted TRAPs, copy the TRAP.BTV file from the C:\MW\NMS\EMPTYDB directory to the C:\MW\NMS\NMSDB directory and then run the MIB Compiler program.
Note: If you are copying the EMPTYDB\ TRAP.BTV file over the NMSDB\TRAP.BTV file, any programs which might have been launched from a trap, will have to be re-input.
Extending Help and Problem Resolution Files. HELP and HELPTAG statements define the file containing the Trap description, and any problem resolution procedures, in an MS Help Workshop file format. These files are stored in the C:\mw\nms\help directory. Most compilers have a Help File editor which convert RTF files into HLP files, and reference should be made to the compiler documentation for specific information on Help File creation.
Typically it is not possible to convert an HLP file back to an RTF format for extending the original file. However, it is feasible to add additional problem resolution procedures by creating another Help file and referencing it from the HELP and HELPTAG commands in a Trap definition.
In the example Trap above, an alternate HLP file could be referenced by the HELP statement, and the actual Tag within the help file could be defined in the HELPTAG statement. Ensure that the new Help file is copied into the C:\mw\nms\help directory. If the file is not present, an error will occur if help is requested for that Trap.
Launching Applications from the Alarm Disposition Table
ManageWise's Alarm Disposition Table allows for the launching of programs when an alarm (Trap) is received (see Figure 3).
There are several third-party applications which can be incorporated into this area. This could be for solutions as diverse as Alarm vocalisers, pager gateways, digital cellular phones' Short Messaging Services (www.connectotel.com), and e-mail. Such solutions can be found at the ManageWise Partners page:
http://www.novell.com/products/managewise/partners/
Recording details against each alarm or Trap can be a cumbersome process. Novell Consulting has developed an application which allows bulk updates of alarms and the setting of minimum severity levels. It also includes additional program parameters which can be passed when the program is launched. This utility can be obtained at the Novell Consulting Web site:
http://www.novell.com/programs/ncs/toolkit/mw_tools.html
MIB files are read by the MIB Compiler and a new SNMPMIBS.BIN file is created. The Compiler also updates the Alarm Disposition Table, TRAP.BTV. Alarm Disposition maintenance is then used to customise alarms in this table (see Figure 3).
Figure 3: MIB compilation and Alarm Disposition Table update.
TRAP Handling Process
When a ManageWise Console is started, it reads the SNMPMIBS.BIN binary file into memory. This is used for high-speed analysis of inbound TRAPs. When a trap is received by the SNMP Server, it compares the inbound TRAP with the list of TRAPs defined in its SNMPMIBS.BIN file. If the trap is defined, it will be acted upon. If it is not defined, it is an unknown alarm and it will be dropped. The trap is recorded in the Alarms database and the TRAP.BTV database is accessed to see how the TRAP should be handled. If there is an action to store the alarm in the database, it will be recorded against the object which represents the device which transmitted the TRAP.
Figure 4 is a simplistic representation of the steps undertaken when a TRAP is received by a ManageWise Console. Unknown TRAPs occur when ManageWise does not have a valid and compiled MIB for the device sending the TRAP. Valid MIBs are displayed in the Alarm Disposition table.
Figure 4: Procedure undertaken when ManageWise receives a TRAP.
As an example, if the action was to "Tickertape" the alarm, details of the alarm will be displayed in the tickertape window at the bottom of the ManageWise Console. If the action was to launch a program and pass startup parameters to the program, details will be retrieved from the TRAP.BTV file and the program will be launched.
Moving Toward Pure IP
With the imminent release of NetWare 5, Novell is providing a greater number of solutions using TCP/IP. Many organisations are looking to rationalise their protocols on both the LAN and WAN. IPX has been simple to install and configure, but the advertising of services and routing information can add significant overhead on WAN links. SAP is used to advertise many of the services in ManageWise.
Irrespective of the service advertising strategy in use--SAP, Domain SAP Services(DSS) in NetWare/IP or Service Location Protocol (SLP) used with Pure IP, it is ideal to minimise the number of SAPs wherever possible. If there is a regional management group within an organisation, SAPs for that region should be confined to the region and not be allowed to propagate all over the organisation.
There are several ManageWise components which can operate without the need for SAP. These are detailed in the following sections.
ManageWise Inventory Collection. ManageWise Inventory uses a number of different programs for scanning workstations depending on the operating system in use. Some support inventory transfer via IP. This eliminates the need for the Inventory SAP 0x102 for these operating systems.
|
Operating System |
Program |
IP Support |
|
MS-DOS |
LDISCAN.EXE |
No |
|
MS-Windows, Windows 95 |
WLDISCAN.EXE |
Yes |
|
MS-Windows NT |
LDISCNNT.EXE |
Yes |
|
NetWare Server |
LDISCAN.NLM |
Yes |
Windows Inventory Scans can be performed using IP transfer as follows:
SYS:\PUBLIC\LDT\WLDISCAN.EXE /F /S=Server /P=IP
Windows NT Workstations and Servers can perform an IP transfer as follows:
SYS:\PUBLIC\LDT\LDISCNNT.EXE /NTT:192.9.200.10
NetWare Servers can undertake an IP transfer as follows:
LOAD LDISCAN /S:192.9.200.10 /File=SYS:\PUBLIC\LDT\ SCANNOW
Note that these programs are being launched from the LDT directory under SYS:\PUBLIC. This is not the default location (this will be discussed shortly).
Workstation Remote Control. Workstation remote control is possible via IP for Windows, Windows 95, and Windows NT. Windows and Windows 95 can be controlled as follows:
SYS:\PUBLIC\LDT\WUSER /Protocol=IP
Windows NT remote control is a service and can be started as follows:
NET START SYS:\PUBLIC\LDT\WUSERNT
Server Remote Control. NetWare has had the ability to remotely control a server via IP for at least 7 years. XCONSOLE.NLM comes with every NetWare server, and once loaded, can be controlled from a Telnet or X-11 session. It is necessary to give the authority for the NetWare server to display onto the Unix host machine. This is done by using the xhost command on the Unix workstation:
xhost +
This command will remove all security and will allow any host to display onto the Unix display.
NetWare 5 will include a Java-based Remote Control, RconsoleJ, which will allow a Browser to take remote control of a server.
Novell Consulting recommends that USER.NLM not be loaded on servers as it presents a security risk. Users with access to the Desktop Manager are able to also access servers running USER.NLM. USER.NLM is normally loaded through the MW_AUTO.NCF file and should be edited out.
LANalyzer Agent Access via TCP/IP. The NetWare LANalyzer Agent is able to be accessed by IP but an issue with the ManageWise Console required IPX to also be present for certain information to be passed back to a ManageWise console. By editing the c:\Windows\NMS.INI file it is possible to force a ManageWise Console to communicate with the NetWare LANalyzer Agent via IP. Search for a section [rmon] then add the server name and its IP Address as illustrated in the following lines:
AgentTalkProtocol=ip ;<agent server name<=<ip-address< NC-CBR=164.99.32.23 NC-SYD=164.99.35.64 HELPDESK=164.99.50.25 INVENTORY=164.99.50.26
NetWare Management Agent Access via TCP/IP. Currently with ManageWise 2.5 there has been an issue with communicating with the NetWare Management Agent over IP only. When obtaining details from an instrumented server via IP, the NetWare Services Manager window is displayed. However, detailed information about NLMs, volumes, users, disks, protocols, and so on, has not been returned. At present, the console submits this request for detailed information as an SNMP GET over IPX (not IP), even if the initial request is via IP.
This problem is being fixed in ManageWise 2.6. A patch exists for ManageWise 2.5 which requires the IP address of the server to be defined. It is possible to obtain detailed information on a server over IP using the MIB Browser, but this is tedious and the information is not as rich. Any SNMP management console can access the NetWare server via SNMP, given that the SNMP GET Community string is valid and the console has the NetWare MIBs compiled.
ManageWise Agent for Windows NT Server and Remote Control. As mentioned earlier, ManageWise supports remote control and Inventory scanning of a Windows NT Workstation or Server, over IP. If the server or workstation does not even connect to a NetWare server, it is still possible to undertake remote control. This is particularly useful in the case of member servers running as Application Servers. As long as LDISCNNT.EXE and supporting files are stored on the server, it will be possible to perform an inventory scan of the server. If WUSERNT.EXE and supporting modules are stored on the server, it will be possible to take remote control of the server over IP.
The ManageWise Agent for Windows NT support management of NT Servers via IP. The IP address of the NT server is known and the server can then be accessed and the MIB information returned in a graphical form to the NT Services Manager.
Help Desk Environments
Many large organisations have formal Help Desks within their IT support structure. ManageWise is a useful tool in a Help Desk environment, the console being capable of identifying issues from the desktop to the LAN, to the server and back again. ManageWise can also be used in a WAN environment with the addition of the Novell Consulting-developed CiscoWorks snap-in module, but WAN management is typically not the responsibility of the Help Desk. Help Desks can range from simple to very sophisticated environments; from password resets to remote workstation control, file downloads, and software rebuilds using the Novell Application Launcher. The following sections describe some ways in which ManageWise can be adapted for Help Desk environments.
Running Desktop Manager without ManageWise
Some large Help Desks may like to use the Inventory Desktop Manager for the graphical environment for their Help Desk staff. Rather than staff having to launch ManageWise to access workstations, it is possible to configure ManageWise so that the Desktop Manager is loaded in isolation. Search for the Windows Pre-launch batch file C:\WINDOWS\WINSTART.BAT. If one does not exist on the ManageWise console, create one and ensure the following line is added:
C:\MW\LDT\BREQUEST.EXE
Create a Desktop Manager shortcut and define the target as follows:
C:\MW\LDT\WSIGHT.EXE
Define the Start in Directory as C:\MW\LDT.
Minimising Polling by the Desktop Manager
The Inventory Desktop Manager polls all records in the Inventory database on a regular basis to see if the workstations or servers have the WUSER, WUSERNT or USER.NLM loaded. For those entries with Remote Control loaded, a small magnifying glass will be displayed over the workstation or server object. The more records stored in the database the more traffic which will be generated in each polling cycle, from each workstation running the Desktop Manager software.
To eliminate this traffic, it is necessary to Edit C:\WINDOWS\ NETMAP.INI on the ManageWise console. In the [Default] section, change the USERCHECKER variable to OFF. If the entry does not exist, add it as follows:
USERCHECKER = OFF
Save the file and exit the editor. Restart Desktop Manager.
When Desktop Manager is first loaded on each workstation, it will poll once and then will only poll again if the <F5< function key is pressed.
Minimise the Number of Records in the Inventory Database
If Inventory is being used for remote control purposes in a Help Desk, an effort should be made to minimise the number of records in the Help Desk Inventory database to only currently open calls. Once a problem has been resolved, the record should be deleted from the database. This reduces the number of workstations which will be polled to see if Remote Control is enabled. Even if the records are deleted, an audit trail of all remote controls is stored in the SYS:SYSTEM\DTVIEWER.LOG file.
ManageWise Licensing and Maximum Number of ManageWise Consoles
Licensing for ManageWise 2.5 is a node-based licensing model, so there are no limits placed on the number of ManageWise consoles which can be created. A node is deemed to be a workstation, notebook, laptop, or dedicated workstation-based print server. ManageWise is licensed for the total number of Node devices on the network. Check with the local Novell Sales Office if there are any doubts about licensing.
If there is an excessive number of ManageWise consoles(over 20) trying to access one ManageWise Inventory Server, there may be some SPX issues. These can generally be resolved by modifying SPX parameters at the ManageWise Console first and then at the ManageWise server with the Inventory database loaded.
In the Control Panel | Network | IPX 32-bit Protocol for the Novell intraNetWare Client, adjust the following parameters.
On the SPX page set the following values:
|
SPX connections |
60 |
|
SPX verify timeout |
216 |
|
SPX listen timeout |
270 |
|
SPX abort timeout |
2160 |
|
Allow connection watchdogging |
Check this box |
On the IPX page set the following value:
|
IPX retry count |
40 |
Load the Btrieve Monitor BTRMON.NLM and check the Resource Usage screen. Check Files, Handles, Locks, Transactions, Clients, and Threads for Peak and Maximum values. If any of these Peak values are reaching the Maximum value then it will be necessary to increase the Maximum values. These values can be adjusted in the SYS:\SYSTEM\BSTART.NCF file. Take particular notice of Handles and Clients (remote Sessions).
Refer to the Novell Technical Support Technical Information Document (TID) 2932850 "Recommended Btrieve Settings for Managewise" for further information.
Using Centralised Inventory for Remote Control
The Inventory database needs to be accessed in order to take remote control of a workstation. If ManageWise agents are installed by default, each server would have an Inventory database loaded. By default, users who are members of the local ManageWise Group would transfer their Inventory records to the local Inventory server. The Help Desk staff then need to authenticate to the remote server, map a drive to the Inventory directory, and access the database, all before being able to take remote control. This is not really efficient in a Help Desk environment and less so over slow WAN links.
Novell Consulting recommends having an inventory database wherever the Help Desks are located and having the users direct their inventory scan to that database.
Figure 5 illustrates a situation where users have scanned and transferred their inventory records to the HelpDesk server. Now when the Help Desk staff need to take remote control of a remote user, that user's record is stored locally at the HelpDesk server and remote control can be undertaken without the need to authenticate to any other server.
It is more efficient to have an Inventory server set up in the Help Desk group --a server all Help Desk staff are able to access. Instead, the remote users effectively come to the Help Desk, simplifying the remote control task for the Help Desk staff. The remote users can then load the Remote control software, WUSER.EXE or WUSERNT.EXE. This could be done by a batch file or NAL Application object.
Figure 5: Default vs. recommended inventory installation.
Transferring Inventory Records
Normally, for remote control, it is not necessary to transfer information about all the applications loaded on the workstation, so a quick and simplified Application List file can be created for use with remote control. Remote users can transfer their data either via IPX or IP to the Help Desk server as follows:
SYS:\PUBLIC\LDT\WLDISCAN.EXE /F /S=164.99.50.25 /I=LDAPPL.HW /P=IP
This example would transfer data to the HELPDESK server (IP address 164.99.50.25) via IP. It would use the LDAPPL.HW file, a file which can be obtained from the Novell Consulting Web site:
http://www.novell.com/programs/ncs/toolkit/mw_tools.html
If the Inventory scan was to be undertaken via IPX, it might be as follows:
SYS:\PUBLIC\LDT\WLDISCAN.EXE /F /S=HELPDESK /I=LDAPPL.HW
where HELPDESK is the server where the Inventory database is stored.
For Windows NT workstations or servers communicating via IP, they should run the following statement (all on one line):
\\Server\SYS\PUBLIC\LDT\LDISCNNT /NTT164.99.50.25 /S="HELPDESK" /V /I=\\Server\SYS\PUBLIC\LDT\LDAPPL.HW
where Server is the server where the software is loaded and 164.99.50.25 and HELPDESK are the server where the Inventory database is stored.
For Windows NT workstations or servers communicating via IPX, they should run the following statement (all on one line):
\\Server\SYS\PUBLIC\LDT\LDISCNNT /NTI 0101D578:000000000001 /S="HELPDESK" /V /I=\\Server\SYS\PUBLIC\LDT\LDAPPL.HW
where 0101D578:000000000001 is the Network address for the Inventory server, HELPDESK.
DOS Workstations can only communicate data to the inventory server via IPX as follows:
SYS:\PUBLIC\LDT\LDISCAN.EXE /F /S=HELPDESK /I=LDAPPL.HW
These statements could be set up as NAL Application Objects or as Batch files which could be run on demand or included in a login script.
Automatic Workstation Configuration
When a workstation is run for the first time, after becoming a member of the ManageWiseGroup, an automatic workstation configuration program will be run as follows:
|
Operating System |
Automatic Workstation Configuration Program |
Configuration File |
|
DOS |
DOSCFG.EXE |
None |
|
Windows 3x |
CCDRIVER.EXE |
CLNTCFG.INI |
|
Windows 95 |
CCDRIVER.EXE |
CLNTCFG.INI |
|
Windows NT |
NTSTACFG.EXE |
NTSTACFG.INI |
The default configuration files are not always the most optimal configuration. For instance, it is not desirable to automatically invoke the WUSER.EXE or WUSERNT.EXE program at workstation boot time as this presents a potential security breech. WUSER is loaded from WIN.INI and WUSERNT is loaded as a service from the Registry. Likewise if it is not desired to allow a Chat or File Transfer facility, these can be removed from the Configuration file.
By modifying these configuration files it is possible to remove these files and disable automatic loading of the remote control functionality. Inventory scan with Windows NT is a scheduled event and this can be disabled in the NTSTACFG.INI file. For examples see the Novell Consulting Web site:
http://www.novell.com/programs/ncs/toolkit/mw_tools.html
Eliminating the Need for ManageWiseGroup
When ManageWise is installed, it asks for an Organization Unit to add commands to the container login script. In order to access the ManageWise functionality a user must be a member of the ManageWiseGroup Group object. This is tedious and requires a significant amount of administrator effort in order to set this up in a WAN environment, to minimise tree-walking, external references, and global groups. ManageWise 2.5 is licensed on a nodal licensing model, not a per-server model. An organisation buys enough licenses for the number of nodes on the network.
Instead of the login script testing to see if a user is a member of ManageWiseGroup, it should now be automatic for each user. Moving all the ManageWise Inventory files over from SYS:\MW\LDT to SYS:\PUBLIC\LDT directory makes it easier for everyone to access. Users will have a search path or drive mapped to SYS:\PUBLIC and they can then reference the executables in the LDT directory as Z:LDT\WLDISCAN.EXE.
Rather than having complicated login scripts, it can be simplified to perform the inventory scans. Refer to Transferring Inventory Records above for syntax. The SYS:\SYSTEM\MW_AUTO.NCF file is used to start up inventory and it should look something like the following:
LOAD LDINV.NLM file=SYS:PUBLIC\LDT LOAD LDISCAN inv_serv=INVENTORY file=SYS:PUBLIC\LDT SCANNOW
or
LOAD LDISCAN inv_serv=164.99.50.26 file=SYS:PUBLIC\LDT SCANNOW
LDINV is the Inventory Database interface. It issues the 0x102 SAP and workstations communicate with this NLM when they transfer data to the database. File indicates where the Machines.dat, Types.dat, Values.dat, and Files.dat Btrieve database files are stored. These could be stored on another volume in order to save space on the SYS volume.
LDISCAN is the inventory scan of the NetWare server. This directs the output to the named Inventory Server, which could be itself if the server is running the LDINV.NLM or a central server such as INVENTORY. File indicates where the files are stored on the local server, including the Application List LDAPPL.INI file. If the inventory scan is being transferred at another server, then that server's LDINV command line will determine where the data is stored.
If transmitting the Inventory scan via IP, place an entry for the inventory server in the local server's SYS:ETC\HOSTS file, as per the examples:
164.99.32.20 NC-CBR # Canberra Server 164.99.50.25 HELPDESK # Central Help Desk Server 164.99.50.26 INVENTORY # Central Inventory Server
How Often Should Inventory Scans Be Performed?
If inventory is used for the two separate functions of traditional Inventory analysis and for Help Desk remote control, then there will be two different frequencies of scanning needed. One must ask how often is it necessary to scan workstations for traditional inventory analysis. For most, once per quarter is probably sufficient for auditing Novell Volume License Agreements or Microsoft Select Agreements. Inventory scans for remote control by a Help Desk need to be undertaken at the time a call is placed with the Help Desk. This inventory scan needs to be output to the Help Desk Inventory server.
Scanning all workstations every day for inventory is time consuming and makes the login process longer. An alternative is to set up Inventory scans using NAL Application Objects to be run once, at the time when the administrator determines. So once per quarter, an administrator can automatically force run Inventory scanning and direct output to a different server than that used for the Help Desk Inventory. Finance or Contracts Administration could set up Inventory on a server under their control, and all workstation inventory could be output there simply by changing the /S=servername information in the scan program. Refer to the syntax in Transferring Inventory records above.
Once all records have been transferred for Audit or licensing purposes, the NAL Application Object could be disabled and the LDINV.NLM Inventory database can be unloaded when all reporting has been completed. Do not bother to reload the Inventory database until the next time an audit is required. When the database is unloaded it will no longer appear on the Desktop Manager | Options | Inventory Database list.
Maximum Records in an Inventory Database
At the time this AppNote goes to press, the recommended maximum number of records in an Inventory database was set at 700 objects. Novell has just released a field test patch FMWDT19C.EXE which essentially makes the number or records limitless. It is not known what will actually be an upper limit as we do not have a lab with more than 1500 workstations to test this with. Contact Novell Technical Support and log a call if you require this patch. If there are thousands of objects, it may be necessary to have multiple inventory databases and all devices will have to be arbitrarily divided up to transfer records to the different databases.
Duplicate entries can occur in an Inventory database if a hidden file on the root of the workstation is removed. The file C:\LDISCAN.CFG contains a random number generated the first time the Inventory scan is run at the workstation. If the file is deleted a new random number is created and a duplicate record will be created for that workstation.
Resetting the Inventory Database
From time to time the ManageWise Inventory database may get too large or may end up with inconsistent information. The following steps will destroy all the data in the inventory database.
Rebuild the inventory database by following these steps:
Ensure all users running Desktop Manager have exited the application.
At the ManageWise Inventory Server console, enter UNLOAD LDISCAN UNLOAD LDINV
Enter LOAD LDINV REMOVE.
Enter BSTOP. This unloads BSPXCOM.NLM and BTRIEVE.NLM.
At a workstation, delete the MACHINES.DAT, TYPES.DAT, FILES.DAT, and VALUES.DAT files in the administrator's network files directory (SYS:\PUBLIC\ LDT - the Novell Consulting recommendation or on a data volume if specified there).
Delete or rename LDINV.ERR and any MACHINES.PRE, TYPES. PRE, FILES.PRE, and VALUES.PRE files in the administrator's network files directory.
In SYS:SYSTEM, delete or rename BTRIEVE.TRN (if it exists).
To eradicate the deleted .DAT and .PRE files, enter PURGE.
At the ManageWise Server console, enter LOAD LDINV FILE=SYS:\PUBLIC\LDT(or alternate location)
Enter LOAD LDISCAN INV_SERV=servername FILE=SYS:\PUBLIC\LDT (substitute the path name as necessary).
Audit Trail of Desktop Remote Control
Inventory also includes an audit trail file which details all desktop remote control sessions. This information should be preserved as it serves a vital role in determining which workstation took remote control of which remote desktop. This file is SYS:SYSTEM\DTVIEWER.LOG. Each Inventory server will have a separate Audit file, so for remote control purposes it is best to have the users scan their information into the same Inventory database so that a single consistent audit trail can be maintained. The DTVIEWER.LOG files are not merged if Inventory databases are merged, and it is difficult to chronologically order records if multiple inventory databases are used.
Miscellaneous Information
Trending Differences Between ManageWise 2.1 and ManageWise 2.5
If a server has previously been loaded with the ManageWise 1.6 Agent, the trend files should be deleted as they are known to cause abends when read by ManageWise 2.5 consoles. ManageWise 2.1 Agents created a directory SYS:\NTREND for storing trend files. By default, ManageWise 2.5 Agent creates a \NTREND directory under the directory where NTREND.NLM is loaded unless it is overridden with another directory. The following should be edited in the SYS:\SYSTEM\NMA2.NCF:
LOAD NTREND.NLM DIRECTORY=SYS:\NTREND
This forces NTREND to store trend files to the same location as the earlier agent.
Novell Consulting recommends changing the location of the trend files off the SYS volume to some other volume; perhaps DATA which can be backed up but will not impact SYS: volume. This will require changing the location in the NTREND load line in NMA2 and copying all existing trend files to that new location.
Incorrect Volume Information with NetWare Management Agent
The current NetWare Management Agent has a problem with correctly identifying the size of volumes over 4 gigabytes in size. Check with the Novell Technical Support Web Site for the latest patches for ManageWise as there is a fix which requires the replacement of two NLMs and associated message files to each server. This effects the information being displayed for Volume information for servers and also distorts the Server Health Meters Health formulas in the TrendComplete module of ManageWise. This patch will be rolled into ManageWise 2.6.
Excluding Workstation Discovery from ManageWise
In a large network it takes a long time to discover all workstations and the information may only be accurate for a short period of time. As workstations move from one segment to another they will be "rediscovered" by the ManageWise NetExplorer process. This leads to duplicate records in the ManageWise database.
IPX workstations are discovered through the NXPIPX discovery mechanism on the ManageWise NetExplorer server. To stop the discovery of workstations it is necessary to first create the file SYS:\NMDISK\NXPIPX.INI. This file should have the following line inserted in it:
gAutoDiscovery=3
Information relating to workstations can then be obtained from the Inventory database. However, if it is desired to merge information from Inventory, Novell Directory Services, and ManageWise via the SyncComplete module then it will be necessary to discover all workstations. After, you can reasonably expect that all workstations have been discovered in their correct location then, the NXPIPX module could be disabled through the NetXplorer Console and NXPIPX .NLM could be unloaded.
Merging Inventory Databases
An option exists in the Desktop Manager database, to merge the database. Remembering from earlier that the current maximum number of records in one ManageWise inventory database is 700, means that merging still only works till 700 records is reached. Do not try merging database if the sum total of records in the two databases is over 700 records. Contact Novell Technical Support if you want to try this new patch to increase the size of the Inventory database.
The alternative is to consolidate the information via SyncComplete and store the data in the ManageWise database on the ManageWise console. The amount of data can be calculated by adding up the sizes of the MACHINES, FILES, TYPES, and VALUES.DAT files on each server. These files can get extremely large and will take a very long time to merge. The merge is a workstation process and uses Btrieve calls to the database. Make sure the ManageWise console has a very fast processor.
Merging Inventory Across the WAN
Inventory merges are very slow and even slower across a WAN. An alternative is to Zip up the remote site data files and then copy them to a scratch server at the site where the ManageWise console is running, then unzip them. Load the LDINV.NLM on the scratch server and point it to the location of the inventory files. Perform the merge or SyncComplete process against this server at LAN speed instead of WAN speeds and it will be much quicker.
Using Inventory for Software License Agreement Audits
Many organisations have to go through the tedious task of determining their installed base of applications to pay greedy software vendors for maintenance or upgrade protection. (This approach can also be used for as part of a Year 2000 audit of workstations and the software installed on the workstations.) The application list file SYS:\PUBLIC\LDT\LDAPPL.INI defines all the applications and their current size, description and version. The typical format for a record is:
<I<,POWERPNT.EXE,3492112,Microsoft PowerPoint 97,97
The <I< indicates that there must be an exact match of the filename and file size. It will create an entry for the description and version number and indicate it exists on this workstation.
With patches and service packs, the executable can sometimes change or may in fact be something more specific. If the file size changed by one byte, there would be no entry for this application. This could mean a loss to the software vendor and leave the organisation in violation of its software license agreement. An alternative is to define each application as follows:
<F<,POWERPNT.EXE,001,Microsoft Powerpoint,X <F<,WINWORD.EXE,001,Microsoft Word for Windows,X
The <F< indicates to take the file description from the program's version resource information inside the executable. The file size is ignored and the description is transferred along with the contents of the file description from the version resource information. Using this approach, it is possible to get the exact version number of each executable. This can be used for determining software quantities for upgrade purposes.
To perform an audit for a Microsoft Select agreement or agreements from Novell, Lotus, or Corel, it is necessary only to name the main executables in the application list. For the Select Agreement only name the MS-Word, Excel, PowerPoint, and Access executables (plus any other applications under the agreement) in LDAPPL list. Save this list as say LDAPPL.MS in the SYS:\PUBLIC\LDT directory. When it is necessary to do the audit, clear the Inventory database and perform Inventory Scans for all workstations but indicate the LDAPPL.MS application list instead. This can be done on the WLDISCAN or LDISCNNT line with the /I switch.
Some example files are stored on the Novell Consulting Web site. An example is as follows:
SYS:\PUBLIC\LDT\WLDISCAN /F /S=INVENTORY /I=SYS:\PUBLIC\LDT\LDAPPL.MS
Or for Windows NT, the following line (all on one line):
\\Server\SYS\PUBLIC\LDT\LDISCNNT /NTT164.99.50.26 /S="INVENTORY" /V /I=\\Server\SYS\PUBLIC\LDT\LDAPPL.MS
Using ManageWise through Firewalls
At some organisations it may be necessary to manage servers or workstations through a firewall. Only authorised ManageWise consoles and the NetXplorer server should have their IP addresses defined to be allowed through the firewall.
|
Device / Purpose |
Port |
Direction |
|
ManageWise NetXplorerServer - Network Discovery |
UDP Port 161 SNMP |
Both Directions |
|
ManageWise Console -SNMP TRAPs |
UDP Port 162 SNMP-Traps |
Inbound to theFireWall from Outside |
|
ManageWise Console -Managing devices & servers |
UDP Port 161 SNMP |
Both Directions |
Figure 6 indicates the UDP Ports required to remotely manage servers and the directions the access is required to be configured for.
Figure 6: Firewall configuration for server management using ManageWise.
Conclusion
This AppNote is not an exhaustive coverage of all the features of ManageWise 2.5; many areas have barely been addressed. Some topics have been covered in previous AppNotes by the author. The Novell Application Launcher has been covered in a number of AppNotes in the past, and reference should be made to those AppNotes for additional NAL information.
At the time this AppNote is going to press, ManageWise 2.6 is in Beta release and ZENworks has been formally announced. Amongst other things, ManageWise 2.6 will feature a Windows NT workstation console. New agents will support NetWare 5 and include ABEND notification and Novell Directory Services instrumentation. All the information in this AppNote is relevant to the new ManageWise 2.6 product; all topics discussed in the AppNote have been tested on ManageWise 2.6 Beta and found to be working as described. Another AppNote will be forthcoming with more detailed configuration information and tips on ManageWise 2.6.
* 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.