This document provides a detailed walk through on the flow of inventory scan in a Windows Managed device and Server through Satellite Server, along with some tips to debug certain failures.

Note to the Reader: ZENworks Asset inventory is a vast feature with multiple components and workflows, which are already available in the Micro Focus documentation . This document mainly covers the workflow of the inventory scan, which forms the core part of the Asset Inventory. Hopefully, this document will help to have an in-depth understanding of the scan workflow and will be useful in debugging issues.

Contents:

• Introduction
• Software Fingerprinting Process and Product Recognition Update (PRU)
• Scan Configuration Workflow
• Workflow in Managed Agent
• Inventory Scan Workflow from Agent to Server
• Debugging Possible Failure Cases

Introduction:

Asset Inventory allows you to scan and collect information such as hardware, software, software usage, demographic data etc. from a ZENworks Managed or Inventoried Device.

Hardware Data: The hardware data includes information about keyboard, video adapter, bus adapter, monitor, CD/DVD, LAN adapter etc.

Software Data: The software data includes the software products that are installed ZENworks Managed or inventoried devices.

Usage Data: Includes the information on the usage of particular softwares on client devices.

Demographic Data: Includes details of the users like Name, Email, Phone, Site, Department, etc.

Software Fingerprinting Process and Product Recognition Update (PRU):

The following diagram shows the workflow of the software fingerprinting process:

• Fingerprinting is a process of recognizing new software in our knowledge base.
• In PRU, we fingerprint all the new software released in the market, by updating our Knowledge base every month with new software.
• The Knowledge base is updated by using a tool called “IDSYSTEM”. This is an internal tool, which is used for fingerprinting the new software.
• In general, to fingerprint a software, we use executables files and registry key entries for that specific software. These registry key and executables are updated in the Knowledge Base or the KB file.
• These files are bundled together and provided as a System Update.
• After applying PRU and KB merge are completed, the server creates system bundles consisting of KB files and assigns the bundle to all windows Agent devices.
• This is published to the market through the Micro Focus download website or the NCC server on monthly basis.
• Once PRU is deployed, at the end of KB merge system bundles will be prepared by server, where the content will be KB files and KBchecksum.properties file.
• By default, it will be assigned to all windows devices and on refresh, it will flow to %ZENWORKS_HOME%/ bin folder.
• Note: It is recommended that you deploy PRU update every month to achieving better software recognition.

Scan Configuration Workflow:

• To configure a scan log into ZCC and browse to Configuration > Inventory > Inventory and then select the settings to determine the nature of first scan. Scan Now, Recurring Scan and then click Apply.
• Similarly, for scheduling a scan browse to Configuration > Inventory > Inventory Schedule. Here, you can specify the frequency of scan like Date specific scan or Recurring Scan.
• When the Agent is refreshed, according to the setting a corresponding XML file is updated.

Example:

a) Options.xml: This file contains details like type of scan, software/Hardware/MSI collection etc. is enabled or not, directory skipped from being inventoried etc. This file is available in the following location:

On Windows: %ZENworks_Home%/bin

On Linux: /opt/novell/zenworks/bin

b) InventoryScanSchedule.xml: This file contains the details of the scan schedule. The file is available in the following location:

On Windows: %ZENworks_Home%/cache/ zmd /settings/

On Linux: /var/opt/novell/zenworks/zmd/cache/settings/

In the above-mentioned location, some of the other inventory related XML’s that gets updated are: inventoryFirstScan.xml, inventoryAutoReconcile.xml, inventoryRecurringScan.xml, inventorySW.xml, inventoryScanNow.xml, inventoryHW.xml, inventorySWFiles.xml

During debugging these XML files can be verified to see if the settings have flown down from server to the agent and are updated accordingly.

Workflow in the Managed Agent:

In an Agent, the Inventory module governs all inventory related activities. The following block diagram shows the workflow in the Managed Agent:

Following are the systematic series of events:

• In ZENworks Agent, the Inventory module consists of Inventory Handler and Inventory Manager.
• When a scan time is set in the ZCC, it will be registered to agent scheduler by Tess module, and the event will be triggered at the scheduled time. The Inventory Handler class already registered with this event will invoke the Inventory Manager.

• The Inventory Manager will call the inventory.runscan method, which first checks if any other scan is running, determines the nature of scan by parsing the different XML files present in the agent, and then check if there are any changes in the scan settings etc.
• Finally, the inventorycollector.runscan method is invoked, which invokes the ZENCollector. The ZENcollector runs as part of the ZENworks Agent service and collects the information like Hardware, Software, MSI, Hotfixes, Demographic data, Software Usage etc. All these collection tasks will run on parallel threads and finally the scan information is dumped into an XML file.
• The inventory manager does the delta computation between the current.xml, Last.xml and creates the Delta.xml.
• This Delta.xml is zipped and uploaded to the server.

Delta.xml Creation Logic:

• On a scan all the data will be dumped into a temp xml file. This file will be first compared with the already existing “last.xml” of the agent, located in %ZENworks_Home%/work/inventory on Windows and /var/opt/novell/ZENworks/work/inventory on Linux, the difference in the data will be dumped into delta.xml.
• The Last.xml will be freshly created with the contents of temp file, and the entire content of temp file will be appended to the existing full.xml.
• The Existing last.xml will be backed up as last.xml.bk.

Delta State: Is the one that determines whether a software is installed, uninstalled etc. On observing a WIF, the tag <DeltaState>1</DeltaState> indicates the state.

Following are the different delta states:

• Any newly added software = 1
• Any deleted software = -1
• Modified/ updated software = 2
• Unmodified software = 0

Note:

• If Software Usage tracking option is enabled in the server, a module called TSusage will run in the agent and collects the software usage. This will be initially stored in a temp file and the same will be appended to the WIF file during scan.
• For an Inventory Only Agent (IOA), only the inventory module will be installed. In a Windows IOA, there is a module called ZENUMIA (ZENworks Unmanaged Inventory Only Agent). On a scan schedule this ZENUMIA will be invoked which in-turn invokes the ZENcollector. After the scan, the entire scan XML will be uploaded to the server. Hence, in a Windows IOA every scan is a full scan and there is no concept of delta scan.

Inventory Scan workflow from Agent to Server:

• The Administrator sets an inventory scan schedule in the ZCC web console.
• When the managed agent is refreshed, the new scan setting set in the previous step will be applied on the agent. Different XML files will be updated in the agent and prominently the below files will be updated, which contains the scan time and scan nature.

Inventoryscanschedule.xml: %ZENworks_Home%\cache\zmd\settings and

options.xml: % ZENworks_Home%\bin

• Once the scan is completed, the delta.zip is securely uploaded to the Primary Server through https by the upload utility of the agent collection framework.
• If a collection Satellite Server is configured, then the WIF is first uploaded to the Satellite Server, and then finally sent to the Primary Server.
• In the Primary Server, the ZENserver will receive the file from agent and moves it into the following directories.

On Windows: %ZENworks_Home%\collection\inventory folder

On Linux: /var/opt/novell/zenworks/collection/inventory

• In the Primary Server, the inventorystorer that runs as part of ZENworks loader will be polling the collection/inventory directory regularly for any inventory file.
• Once delta.zip is available, it will unzip and parse the file to check the device details such as GUID, sequence number etc. and compares with the last delta sequence present in the database.
• Once the details are verified, the WIF is processed and moved to the following success directory:

On Windows server: %ZENworks_Home%\collection\Inventory\Success.

On Linux server: /var/opt/Novell/ZENworks/collection/inventory\Success.

• If there is a mismatch in the WIF sequence number /Guid/Serial number etc., then the WIF will be processed to failure folder.
• The information is then persisted to respective tables in Database using hibernate calls.

Note: All the file paths mentioned in this document are only applicable to ZENworks 2020 Update-1 and prior releases.

Debugging Possible Failures:

Following are some of the corner cases of failures that were encountered either in Product Testing or in a customer environment.

1. Satellite Server down: As per the WIF sequencing logic, when an out of sequence WIF arrives to the server, then that WIF is not processed and it is moved to a waiting folder where it is made to wait.

Example:

In the above example, an agent has generated the sequences 0-001, 0-002, 0-003 in 3 consecutive scans. Now 0-001 is processed in the Primary Server. However, the 0-002 is lost or still stuck in the Satellite Server. In this case, when 0-003 arrives to Primary Server, it is made to wait until 0-002 arrives.

Hence, ensure that the Satellite Server is up and running. In some of the WIF processing failure cases, the Satellite Server might be down. Hence the WIF that has already arrived at the Satellite Server will not be able to proceed to the Primary Server.

2. Existence of some special characters: Inventory scan fails because of special/invalid characters in WIF file. These invalid characters come from either Manufacturer, serial number or any other parameter. This can happen for both Software and Hardware components.

Example 1: Following screenshot shows the blob in the WIF of a system that was obtained by scanning a removable media/drive (USB flash) attached to a Managed ZENworks agent. The serial number consists of special characters, Hence, the WIF upload failed.

Example 2: In this case, a removable HP HD Camera is attached to a ZENworks agent device at the time of scan and the serial number consists of special characters. Hence, the scan file upload will fail.

3. Changes in external tools/Operating System: For hardware collection, we primarily use tools such as HW info (Linux), WMI query (windows), which is used as collection sources for hardware data. Sometimes, when these tools are upgraded as part of periodic update or a system update of the Operating System, then the behaviour of these tools vary, thus resulting in inconsistencies. In some scenarios, the way the newer versions of operating system response to these tools also cause issues.

4. Database update/driver update: Another reason can be due to a database updates or a driver update, which will cause either a query to malfunction or the way the data is stored/retrieved.

5. Software reconciliation: Sometimes there can be issues in PRU, leading to wrong reconciliation, and hence a duplicate representation of a same software product can happen in the detail inventory report. As in the following example:

This can be fixed either by finger printing in the PRU or by creating Local Software Products, or by using the manual reconciliation option in ZENworks Asset Management.

6. Loader service unresponsive: In some unique cases, the loader service in the Primary Server might be unresponsive, due to which the WIF files get piled up in the collection/inventory folder. A quick solution to this would be to restart the loader server and check if it solves the problem.

Note: Most of these mentioned issues were unique and are addressed. However, there can be a possibility of such occurrences based on respective environments.