Hello everbody,
We just have a discussion about how the Inventory Group Settings work under certain conditions.
Initial situation
In a company there are several network segments (A, B, C, ...) which are already mapped in Flexera via corresponding subnets. The Inventory Group Settings function is now used to ensure that all agents from the IP range A will only communicate with the beacons in this segment and do not try to communicate with every known beacons from other segments as before.
Note: This option is only active for subnet A and therefore all agents that fall within this IP range. There is also a network segmentation which blocks the communication between segment A and the other segments
Use Case
A FlexNet agent device from one of the other segments (B, C, ...) is in segment A for a certain time and thus also receives an IP address from this range. According to the Flexera documentation, this agent receives the information with the next policy update that it may only communicate with the beacon from segment A.
Thereafter, when an inventory device checks for updated policy (which happens daily at a random time between 5 a.m. and 6 a.m. local time for operational agents), affected platforms receive the changed policy. Once FlexNet inventory agent has the new policy update, it communicates with the inventory beacons in accordance with the policy file.
Our question
What happens to the agent and its settings if it comes back to one of the other segments (B, C, ...) and thus receives a different IP address and is no longer subject to the restrictions of segment A. Communication from the other segments to segment A and its beacon is no longer possible.
So how does the agent know that he should now be directed to the other beacons again if he cannot obtain a new policy update after the segment change. Or, does every Flexera agent possibly know all Inventory Group Settings and can therefore decide with every update/scan/upload to which beacon it may send its information and where not?
Thanks and Best,
Dennis
‎Mar 04, 2020 03:46 PM - edited ‎Mar 04, 2020 03:48 PM
Hi Dennis,
If device goes out of restricted agent beacon communication group, it will fall back into global pool and communicate with possible beacon/s it can communicate as soon as it get new policy, when they comes to restricted group, beacon group restriction applies after next policy update.
This is to make sure, restrictions does not cause any inventory agent to go into orphan state where it cannot talk to any beacon anymore but provide options to restrict device to communicate to specific group by moving them from global pool to restricted group.
HTH
Aamer
‎Mar 04, 2020 06:04 PM
Hi Dennis,
If device goes out of restricted agent beacon communication group, it will fall back into global pool and communicate with possible beacon/s it can communicate as soon as it get new policy, when they comes to restricted group, beacon group restriction applies after next policy update.
This is to make sure, restrictions does not cause any inventory agent to go into orphan state where it cannot talk to any beacon anymore but provide options to restrict device to communicate to specific group by moving them from global pool to restricted group.
HTH
Aamer
‎Mar 04, 2020 06:04 PM
@AamerSharif thanks for your detaild answer.
Can you tell us more detailes about the functionalities, how does the agent recognize that he is no longer in a "restricted agent beacon communication group" and therefore may communicate with all beacons again. Is there any documentation on this?
But how does the agent behave, if he is in a "restricted agent beacon communication group", but cannot reach any of the assigned beacons - does the above mentioned option take effect at this point and he communicates with the other beacons? (as fallback?)
Perhaps this information can be added in the documentation on the topic "restricted agent beacon communication group". I can imagine that not everyone is aware of this behaviour
Best, Dennis
‎Mar 05, 2020 02:45 AM
I guess the agent knows the "borders" of the communication group and when it moved out of it. That not only solves issues with devices "moving around", but also with changing groups for existing devices (in the sense of an agent belonging to another group after the change).
‎Mar 05, 2020 06:10 AM
Inventory beacon decision based on policy settings, who (device running inventory agent) get what settings.
As inventory agent already have a location/s it can talk to get policy, when restriction/s are removed it can talk any location that is reachable.
‎Mar 15, 2020 09:02 PM
how does an agent behave if it can no longer reach the beacon assigned by the Inventory Group Settings, e.g. because it is offline. Is there also a fall-back solution for such a case or are these agents then lost, because they cannot get a new policy anymore.
Thanks and Best,
Dennis
‎Apr 09, 2020 04:13 PM
‎Apr 20, 2020 07:07 AM
HI @AamerSharif
Thank you. Could you please elaborate on one of your first postings, what do you mean by "fall back into global pool"? Is this your recommended setting, that at least 2 or more beacons should be specified when using this function, so that the agent has the possibility to reach more. We just want to make sure that we understand the features and their limitations
If device goes out of restricted agent beacon communication group, it will fall back into global pool and communicate with possible beacon/s it can communicate as soon as it get new policy, when they comes to restricted group, beacon group restriction applies after next policy update.
This is to make sure, restrictions does not cause any inventory agent to go into orphan state where it cannot talk to any beacon anymore but provide options to restrict device to communicate to specific group by moving them from global pool to restricted group.
‎Apr 20, 2020 02:48 PM