erwinlindemann
Level 8

Questions on the FlexNet inventory agent unique identifier (AgentID) property

Jump to solution

Hi Experts,

With the FNMS 2019 R2 release, an unique identifier called "AgentID" is being created by all flavors of the Flexera agent, for all types of Inventory devices.

The AgentID is used for matching. For any data collected by a Flexera agent, a matching AgentID value takes precedence over the "Matcher" process described in the "Gathering FlexNet Inventory" document in the "Identifying Related Inventory" chapter (page #177).

How is the AgentID identifier calculated though?

  • Does the AgentID change in case the OS is upgraded on the same hardware (like when doing a migration from Windows Server 2012 to Windows Server 2016)?
  • Is there any impact on the value of the AgentID in case relevant hardware properties (Manufacturer, Hardware Serial Number, MAC Address) change?

Any information on the algorithms used for calculating the AgentID would be appreciated.

1 Solution

At a high level, agent ID is generated using the following:

Physical Machines: SHA256(HostName + BIOS_Serial_Number + History_Iteration)

Virtual Machines: SHA256(VMID + GenerationID + History_Iteration) (where generation ID is available only for certain hypervisors running certain versions of Windows guests)

The agent ID is regenerated if enough conditions have changed, at which point the history iteration is incremented also:

Physical Machines: HostName and BIOS_Serial_Number both changed

Virtual machines are rather complicated to distinguish VMs that have been moved or cloned (copied). To account for a broad array of scenarios the following is used:

- If generation ID is present and changed, and all physical MAC addresses have changed, regenerate ID

- If VMID is present and changed, regenerate ID

- If all physical MAC addresses have changed, regenerate ID

The agent ID, the properties used to generate it, and all historical IDs and properties are sent in an NDI created with ndtrack.

Please note that these are implementation details that are subject to change across versions of the FNMS agent to account for future scenarios. Also note that while the agent ID helps to uniquely identify a machine it may not be used if other evidence is present. This is also an implementation detail that is subject to change across FNMS versions.

View solution in original post

11 Replies
mfranz
Level 15

Hi Erwin,

I guess it is randomly generated. It is stored in the registry and I believe it could withstand an in-place-migration. With a new agent installation it would be newly generated. If it was generated live from hardware properties, it wouldn't need to be in the registry.

I think this is done to overcome new ExternalIDs being created if a machine changed domains and other changes.

I stand corrected, see Erwins comment.

Best regards,

Markward

Softline Group is Europe's leading independent expert in Software Asset Management.

Hi Markward,

“Stored in the Registry” is correct. On Windows, after running the Flexera Agent, you can find the AgentID value in the following location:

HKEY_USERS > <SID> > Software > Classes > VirtualStore > Machine > Software > WOW6432Node > ManageSoft Corp > ManageSoft > AgentUniqueID

However, I don’t think the value is „randomly generated“:

  • When deleting the key/value from the Registry and re-running the agent, the identical value is created
  • According to the documentation, an identical value for AgentID is generated, independently if the Flexera agent is installed locally, executed remotely from a Beacon (aka “Zero Touch”), or if ndtrack.exe is being copied to the target system and executed manually.

It looks as if the value for AgentID is based on properties of the device/VM where the agent is run.

WHICH properties is the question ...

Hi Erwin,

So identical copies of a VM should independently create the same AgentID?

Best regards,

Markward

Softline Group is Europe's leading independent expert in Software Asset Management.

There isalso a discussion about the AgentId in the Release Blog.

"While I am not sure of the exact calculation I understand that it uses all of the available MAC addresses, so if all of the MAC's change for a given computer then the AgentID will also change. The IP address is not taken into account when creating the AgentID."

https://community.flexera.com/t5/FlexNet-Manager-Release-Blog/FlexNet-Manager-Suite-2019-R1-2/bc-p/1...

Unfortunately it doesn't describe the complete algorithm.

I am also interested in the compete alogirthm

I can confirm that the calculated AgentID value is indentical if you physically copy a Virtual Machine.

If you follow these steps:

  • Do a file based copy of a folder containing a VMware Workstation Virtual Machine (VM) (I have been using running a clean Windows 10 VM)
  • Launch both the original VM and the cloned VM sequentially in VMware Workstation. Select "I moved it" when prompted if you did copy or move the VM. This will make sure that the UUID value of the original VM is preserved in the .vmx file.
  • Copy the FNMS 2019 R2 Flexera Agent to both VMs and run the ndtrack.exe from a command line

Inspecting the NDI files that are generated shows that the AgentID value is identical.
If you select "I copied it" after launching one of these VMs before creating the NDI file, the AgentID is different.

Obviously, for a VM, the UUID value is being used for calculating the AgentID value. It would be interesting to learn about the other properties.

Hi, good work on testing, Erwin.

Renaming the machine or chaning IP address do not alter the AgentID.

Could Flexera elaborate what factors are considered for AgentID. We have customers that may clone VMs or do some other actions that may or may not generate unique AgentID.

 

0 Kudos

At a high level, agent ID is generated using the following:

Physical Machines: SHA256(HostName + BIOS_Serial_Number + History_Iteration)

Virtual Machines: SHA256(VMID + GenerationID + History_Iteration) (where generation ID is available only for certain hypervisors running certain versions of Windows guests)

The agent ID is regenerated if enough conditions have changed, at which point the history iteration is incremented also:

Physical Machines: HostName and BIOS_Serial_Number both changed

Virtual machines are rather complicated to distinguish VMs that have been moved or cloned (copied). To account for a broad array of scenarios the following is used:

- If generation ID is present and changed, and all physical MAC addresses have changed, regenerate ID

- If VMID is present and changed, regenerate ID

- If all physical MAC addresses have changed, regenerate ID

The agent ID, the properties used to generate it, and all historical IDs and properties are sent in an NDI created with ndtrack.

Please note that these are implementation details that are subject to change across versions of the FNMS agent to account for future scenarios. Also note that while the agent ID helps to uniquely identify a machine it may not be used if other evidence is present. This is also an implementation detail that is subject to change across FNMS versions.

View solution in original post

Thank you very much, Josh!
0 Kudos

Hi Josh,

i have a few additional questions about the generated Agent IDs.

As already described by you, the AgentIDs for VMs are composed of VMID, GenerationID and History_Itheration.

The VMID is the UUID of the VM which can also be found in the NDI, right? I found the GenerationID in the vCenter and can be read out in the *.vmx file there. But I could not find the GenerationID in the *.ndi file.

Now to my questions:

1./ How to get the GenerationID to create the AgentID if it is not available in *.ndi. Is it read from the registry / a WMI?

2./ What is the "History_Itheration" and where does your algorithm get this information from? Is this the information from  REG:[...]ManageSoft\AgentUniqueID\History?

3./ Is there a more detailed documentation for generating the AgentID?
- which data (partly known)
- are from which sources (not known)

I'm asking because we have an enormous amount of duplicate AgentIDs in one environment, which means we are missing a lot of VMs in the interface. I want to show the customer exactly where the problem lies in their infrastructure.

Thanks for your feedback.

 

Here is a short summary about AgentID.

The AgentID is formed from the following information:

physical machines:
SHA256 (HostName + BIOS_Serial_Number + History_Iteration)

virtual machines:
SHA256 (VMID + GenerationID + History_Iteration) (where generation ID is available only for certain hypervisors running certain versions of Windows guests)

As far as we know, an insufficiently mature process in the creation of VMs (e.g. simple copying) can lead to agents on different devices generating the same AgentID.
The reason for this is that the same VMIDs (UUID) and MAC addresses exist on the open devices.
The consequence is that the import into the FNMS inventory table is only done from one of the devices, because the UniqueAgentIdentifier is supposed to prevent the import of multiple objects with the same value.

According to the statements of the Flexera support staff, the following measures can be taken to prevent the creation of AgentID duplicates.

1./ Changing the VMID (UUID) using script or manual correction on the machine itself
      (was successfully tested at my customer's site)

2./ Change of one or more MAC addresses on the machine.
       This should also result in a change of the History Itheration, because here changes of the AgentID are included, which are based on changes of the MAC address.
Statement of the Flexera Support:

"The History_Iteration section is part of the AgentIDHistory section to keep track of AgentID changes. This is calculated with MAC address changes."

I could not confirm this yet, but I will add an update here as soon as I have tested it.

I had our customer make changes to the UUIDs.

Now we can also see VMs in the interface that were previously not loaded into the database by the AgentID duplicates.

Regards,

Cap