Novell Home

Deploying an Effective Enterprise Inventory Management System Using ManageWise 2.6

Articles and Tips: article

BILL MAXEY
Senior Consultant
Novell Consulting

01 Nov 1999


ManageWise has some great features for managing your hardware and software inventory. Get expert help on setting up a workable system for large enterprise networks.

Introduction

ManageWise's desktop inventory management, a subset of the desktop management package, provides for tracking of software and hardware assets. Today, companies are compelled to track their assets for such reasons as licensing compliance, asset depreciation, help desk support analysis, and auditing of software resources to keep their ISO9000 status. ManageWise provides this functionality in a scalable, efficient system of tools.

This AppNote discusses:

  • Inventory management issues in a global setting

  • Database performance

  • Fault tolerance

  • Interoperability with third-party packages

Readers of this AppNote should have some familiarity with ManageWise operations and a general understanding of enterprise system deployment strategies. This AppNote should be used as a resource for designing and deploying large enterprise inventory management systems.

Some of these deployment strategies could be used for ZENworks 2.0 inventory database deployment, but that will not be discussed here.

Inventory Management Issues

Inventory management consists of the ability to retrieve, store, and report hardware and software information for assets within an organization. This information can be as detailed as tracking a specific DLL file for all users of an application or summarizing the number of CPUs that have processor speeds in excess of 300 Mhz.

Small LAN Deployment

Traditionally, companies have deployed inventory management systems where a single master database communicates with all input resources. Figure 1 shows a typical installation for smaller networks (less than 1000 users), along with the flow of data in and out of the inventory system.

Figure 1: WAN infrastructure for traditional inventory system deployment.

In this scenario, there is a single inventory database located centrally at headquarters. The inventory scan processing occurs across the WAN.

The advantages of this configuration are:

  • Suitable for small LAN environments

  • Can be deployed in large organizations with high-capacity WAN links

The disadvantages of this configuration are:

  • Limited scalability

  • Slow scan times

  • Large databases (resulting in long report processing times)

  • Limited fault tolerance

Here are some performance numbers typical of this configuration:

  • Normal (over the LAN) scan times of 30 seconds to 1 minute; could increase to 3-5 minutes depending on link speeds

  • Typical scan data over the WAN link averages 228 KB per machine for an initial scan

Large-Scale Deployment

An inherent problem that large organizations possess (but smaller companies do not) is how to capture this information in a consolidated manner with minimal effect on network and end-user resources. The following issues are typical concerns in a large-scale inventory environment:

  • WAN link utilization

  • End-user scan time

  • Database capacity and performance

  • Fault tolerance

  • Format and usefulness of collected data

The following sections of this AppNote will address these concerns in detail and will suggest different approaches for technical implementation and operational administration of the inventory management system. In addition, these scenarios will show the advantages and disadvantages of each to help design engineers customize a solution for their specific environment.

Implementation Scenarios

WAN Links

In today's enterprise networks, companies have deployed a wide array of communication links between branch office sites and the main headquarters. In some cases, these links were installed to manage a capacity of "daily user traffic" such as electronic mail, workflow applications, and minimal client-server database access. Whenever an additional application is added to the network that is outside the scope of this "daily user traffic," it is considered to be of a lower priority and hence is expected to function with little or no impact on end-user activities.

To minimize the impact of the inventory management system, you must install multiple inventory databases located strategically in the branch offices. All updates to the database occur locally, thus eliminating traffic over the WAN backbone for database interaction. It is also suggested to use a centralized server for database collection of all remote branch office databases. This will reduce reporting activity in environments where organizations have a need to report enterprise-wide information. To accomplish this, each branch office database is copied to a separate subdirectory on the centralized database server. From there it can be "merged" to the main database on the local segment.

Here is an example of the main server data structure that collects information from multiple regional databases

DATA:INV/

   |&NEWYORK/MACHINE.DAT;

   |&LA/MACHINE.DAT;

   |&DALLAS/MACHINE.DAT;

   |&CHICAGO/MACHINE.DAT;

   |___CENTRALIZED/MACHINE.DAT

In the scenario depicted in Figure 2, a centralized inventory is dedicated for storage and processing of all inventory databases. The field office databases are batch-scheduled to be copied on a regular basis to the centralized server. (Just about any scheduling software can be used. Make sure copy operations are performed after hours when the impact of inventory scans on workstations is minimal.)

The operational personnel use the ManageWise LANdesk "Merge" operation to consolidate all copied databases. Operational reports are generated and distributed via ManageWise LANdesk reports or through SyncComplete, a third-party add-on that gathers data from the ManageWise alarm and topology database, NDS, multiple ManageWise inventory servers, and multiple NetWare file servers into a unified database. For more information, see:

http://www.kansmen.com/

Figure 2: Inventory deployment with distributed databases copied and merged into a centralized database.

The advantages of this configuration are:

  • Database fault tolerance for field offices

  • Report processing occurs on local server/console

  • Reduced database size in field offices

  • Inventory scan processing occurs on local segments

The disadvantages of this configuration are:

  • Potential large copy operation over WAN links

  • Reports are not "real-time"

  • Custom reports require additional export/link to 4GL program

  • Consolidation or merge process requires operator intervention

  • Requires additional hardware for the centralized server

Here are some performance numbers typical of this scenario:

  • WAN sites with 1,000 to 5,000 users produce an average database size of 22 to 100 MB. Take this into account when doing copy operations over slower WAN links. As always, the number of scans retained per machine and the number of file revisions can increase the amount of data exponentially.

  • The time required to merge a 22 MB database over a 256 Kbps Frame Relay link with minimal line utilization averages 3 to 5 minutes.

  • The number of WAN links should be kept to a maximum of 10 - 20. (This number could increase if the copy operations were staggered to 2-4 per night.)

Scan Time

The location of the inventory database has a direct effect on scan time for an end-user machine because of the amount of time it takes to update the database. For instance, if you scan all the software objects on all machines on your network, the TYPES.DAT file will have to be updated with all the new component types. Traditional deployments (as depicted in Figure 1) would have had login scripts processing the scan data across the WAN, which is not really a good thing.

Obviously, if the database is located nearer to the workstation that is being scanned, there are fewer hops to cross and faster communication links are used instead of slower WAN links. Thus the interaction time between user and database is kept to a minimum. Such is the case for the deployment scenario depicted in Figure 2.

Scan times depend on the settings specified in the LDAPPL.INI file. For instance, if your intention is to retrieve all software for a given workstation, including what is not included in the LDAPPL.INI, you would set the scan mode parameter to "Mode=All". This setting is useful for organizations that have open desktops but are trying to maintain software accountability with regard to the number and versions of applications that are deployed.

Database Capacity and Performance

The four files of the inventory database are: FILES.DAT, MACHINES.DAT, TYPES.DAT, and VALUES.DAT. By default, these .DAT files are located in the SYS:MW/LDT directory, but they can be placed in a different location by using the following command line option in the MW_AUTO.NCF file:

load ldinv.nlm file=volume:path

The size of these files is determined by many settings chosen at installation time. The following is a list of variables that need to be accounted for in estimating the size of the database:

  • The number of machines scanned and the number of file revisions affects the size of FILES.DAT.

  • The number of components scanned per machine influences the size of MACHINES.DAT.

  • The size of TYPES.DAT is controlled by the number of component types defined and scanned.

  • The size of VALUES.DAT is controlled by the number of object IDs defined.

  • The "Mode" setting in LDAPPL.INI affects the size of FILES.DAT and TYPES.DAT dramatically.

  • The number of configuration files saved during scanning is set under Tools | Desktop Manager | Options | Software Scanning.

The table below will give you an idea of how much each DAT file can grow after one machine scan.


Filename
Base Size
Size After One Machine Scan

MACHINES.DAT

72 KB

148 KB

TYPES.DAT

64 KB

104 KB

VALUES.DAT

56 KB

168 KB

FILES.DAT

64 KB

64 KB

Fault Tolerance

Fault tolerance is built into the deployment strategy previously discussed in that databases are deployed locally, but an additional copy is stored on the centralized database at headquarters. Besides the normal disaster recovery options such as backups and hardware RAID systems, the engineer could recover from database corruption by copying the database back to the branch office.

Data Structure and Interoperability

Unless you are a seasoned programmer versed in the APIs to the Btrieve database that ManageWise uses, you will probably want to export data from the inventory database to a fourth-generation language (4GL) program such as Microsoft Access, or to a spreadsheet application such as Microsoft Excel. Figure 3 identifies the field layouts that can be imported from the comma-separated values (CSV) file through the Desktop Manager's "Print Inventory Data" feature. Notice that only components selected will be exported to the CSV file.

Figure 3: Selecting component types from the "Print Inventory Data" option.

Linking the ManageWise Database to Other Programs

If you would like to expand on or create new comprehensive reports that are not included in the report features of "SynComplete", you may want to try using Microsoft Access to link the Btrieve databases via an ODBC driver from Pervasive Software. These drivers are located at:

http://www.pervasive.com/products/download/

Download the ODBC driver and the workstation software. The ODBC driver is free. The workstation software is a trial version that can be converted to full license for $49.00 per workstation. If you already have Btrieve for Windows 95/98/NT version 6.15, download only the ODBC driver version 2.04. This provides the ability to merge those branch office databases in real time.

Note: It is advisable to use a separate console station besides your ManageWise console because the Pervasive workstation software can conflict with the Btrieve files of the ManageWise console. Also, support from Pervasive Software is good as long as you are using one of their products (not just the ODBC driver). It is advisable to have in-depth knowledge of Btrieve file format, definitions and SQL before attempting the deployment.

Figure 4 illustrates a linked database deployment strategy. In this scenario, distributed inventory databases are located in each field office. A Microsoft Access database is set up with ODBC links to all Btrieve databases (any ODBC-compliant database can be used). The reports are then customized through Access.

Figure 4: Database deployment strategy with a 4GL program.

The advantages of this configuration are:

  • Centralized "real-time" custom reporting

  • No operational procedures for nightly copy/merge operations

  • Reduced size of databases in field offices

  • Inventory scan processing occurs on local segments

The disadvantages of this configuration are:

  • Report processing occurs over WAN links

  • Requires 4GL experience in creating reports and maintaining database links

  • Requires additional hardware for the centralized server

  • Requires optional DataBase Administrator to administer SQL, Oracle, or other SQL-based database

Here are some typical performance numbers for this scenario:

  • Fine tuning of SQL/ODBC parameters such as QueryTime=. The default is 60; increase in increments of 10 for large WAN environments or slow WAN links. Using the Registry Editor, change the following DWORD value to the desired setting:

    HKEY_LOCAL_MACHINE_\Software\Microsoft\Jet\4.0\Engines\ODBC

  • Scales to 1000 - 5000 machines per WAN site

  • Allows a virtually unlimited number of WAN links

In this database model, your design has the option of leaving the databases remotely at the branch offices and linking or importing the Btrieve databases with Microsoft Access. Obviously, creating a link over slow WAN lines may cause ODBC timeouts and may be too slow for large production reports. In these cases, it may be necessary to import the data from the Btrieve database directly into Access. In large enterprise environments, notice should be taken of the size of the MDB file. The design engineer may decide to create multiple MDB files for reporting needs.

Note: For another approach to complex reports, see the AppNote entitled "Using Seagate's Crystal Reports 6.0 with ManageWise Inventory Database" in the May 1999 issue.

Figure 5 shows the relationships between the four Btrieve files when linked/imported to Microsoft Access. This relationship could be expanded to link in regions of data using the same model.

Figure 5: Inventory relationships defined in Microsoft Access.

The tables below show the data definition files (DDFs) used to link the inventory files with Microsoft Access. Note that these DDFs are different in that the variable length record of FILES.DAT was ajdusted to work in an Access memo field with a size of 32,608 bytes.

FILES.DAT


Field
Type
Offset
Length

machineID

integer

0

4

revisionNo

unsigned

4

4

dateTimeStamp

integer

8

4

size

unsigned

12

4

fileName

zstring

16

13

filePath

zstring

29

128

fileContents

note

157

32608


Index #
Name
Case
Dup
Mod
Null
Sort

0

machineID

N/A

No

No

No

Ascend

0

fileName

Yes

No

No

No

Ascend

0

filePath

Yes

No

No

No

Ascend

0

revisionNo

N/A

No

No

No

Ascend

MACHINES.DAT


Field
Type
Offset
Length

machineID

integer

0

4

componentID

integer

4

4

componentType

integer

8

4

attributeID

integer

12

4

attributeType

integer

16

4


Index #
Name
Case
Dup
Mod
Null
Sort

0

machineID

N/A

Yes

Yes

No

Ascend

1

machineID

N/A

Yes

Yes

No

Ascend

1

componentID

N/A

Yes

Yes

No

Ascend

2

machineID

N/A

Yes

Yes

No

Ascend

2

attributeType

N/A

Yes

Yes

No

Ascend

3

machineID

N/A

No

Yes

No

Ascend

3

componentID

N/A

No

Yes

No

Ascend

3

attributeID

N/A

No

Yes

No

Ascend

4

attributeID

N/A

Yes

Yes

No

Ascend

5

machineID

N/A

Yes

Yes

No

Ascend

5

componentType

N/A

Yes

Yes

No

Ascend

VALUES.DAT


Field
Type
Offset
Length

objectID

autoinc

0

4

typeID

integer

4

4

desc

zstring

8

80


Index #
Name
Case
Dup
Mod
Null
Sort

0

objectID

N/A

No

No

No

Ascend

1

typeID

N/A

Yes

Yes

No

Ascend

2

desc

Yes

Yes

Yes

No

Ascend

TYPES.DAT


Field
Type
Offset
Length

TypeID

autoinc

0

4

TypeOfType

unsigned

4

4

Description

zstring

8

40


Index #
Name
Case
Dup
Mod
Null
Sort

0

TypeID

N/A

No

No

No

Ascend

1

Description

Yes

No

Yes

No

Ascend

Conclusion

The examples presented in this AppNote have attempted to demonstrate a different approach to inventory management. In the earlier versions of ManageWise, there was a tendency to think centralized or LAN specific. In fact, ManageWise was originally designed to be a LAN management tool. With later versions such as 2.6 and K2, the components have been enhanced to allow for decentralization. New design strategies are needed to address today's growing enterprise environments. We must find new approaches and be innovative in how we deploy network management tools.

Additional Resources

For additional information, refer to these resources:

* 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.

© 2014 Novell