ZENworks Asset Management – Managing your FNI

Software Applications
These are applications that ZAM has prior knowledge about. The ZAM agent intelligently scans devices looking for known footprints of applications or suites of applications. Novell offer an monthly update to this footprint data via a Product Recognition Update (PRU) system. However, there will always be applications installed on devices that ZAM has no prior knowledge of. A good example of this is applications that have been developed in-house by your own developers. To manage these types of applications, ZAM provides a second option.

Software Files
ZAM can be configured to scan on a purely file-by-file basis looking for files with a “.exe” extension, in-fact any extension can be specified. ZAM will read everything it can about the file, such as Vendor, Version, Size and Date/Time stamp. This information is uploaded to the ZAM database in a Files Not Identified (FNI) list. Administrators can then choose to ignore entries in the FNI list or categorise the entries as Local Products.

A quick word of warning. Setting the option to collect information about all “.exe” files on all devices at once can lead to an extremely cumbersome FNI list. I’ve seen FNI lists as big as 500,000. If you’re thinking about using FNI, this is a simple approach that should make life easier.

Identify areas of the business where devices will have different product sets installed, for example:

Departments
Home workers
Laptop Users
VPN users
Administrative Users

Create a separate option set to collect FNI data and apply it to a handful of devices in each of these areas

Manage your FNI list by ignoring files and folders that are of no interest to your business

Categorise the remaining FNI entries as Local Products

Repeat steps 1-4 gradually expanding the target device list

Finally, if you want a specific application to be added to the next Product Recognition update, follow these steps.

Do you use FNI lists? What types of files do you track?

(0 votes, average: 0.00 out of 5)You need to be a registered member to rate this post.

Disclaimer: This content is not supported by Micro Focus. It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test it thoroughly before using it in a production environment.

2 Comments

One of the reasons we’re deploying ZenAM is in worm remediation. We had a worm recently that dropped a specific file. Having a way to globally gather a list of all workstations with the infected file (this was before AV had a signature for it) would be quite valuable in targeting systems for remediation. We haven’t gotten the system out the door yet, as we’re still testing DB growth to see if we have things sized right.

What are the downsides to having a LARGE FNI list? If things deploy the way it is planned, we may get up that big.

Software applications are sent back in deltas for each scan, the colletion server checks the devices out of the DB and compares it to the record that is sent from the device. However, each time a FNI list is gathered from a device, all FNI items are deleted from the DB and each item is inserted into the database, there is no delta process. This process can add a huge load to the database, especially if every device is doing this.

Another problem with having a large FNI list is that it becomes extremely hard to manage it in the ZAM Manager. If you are after one particular file, then perform a Software Files scan on a machine you know that it exists and then create a local product based on the recognition data. At least then reports will show the product.

If you are searching for .EXE files you will find stuff in temporary folders, internet cache etc which may be the installers as opposed to the applications themselves, most people I work with want to ignore these.