We are trying to execute a rule X that is specific for a particular set of servers of the same beacon.
So we have created a subnet Xs with these IPs and assigned to the beacon Xb.
The rule X is responsible of the adoption of the targets Xs.
The problem is that the rule X, or the beacon Xb, are using a wrong subnet Ys (another subnet that I have) that we never attached to the rule X.
We also deleted the subnet Ys, but the result is that the rule X is still performing the same action on the wrong subnet Ys (now we see the taget IPs instead of hostnames).
Is there a way to flush the cache of the beacon and the manager? It this happened to someone of you?
I hope i've been clear, it is an hard question 😮
Mar 30, 2020 11:31 AM
As soon as beacon get new policy it should flush and reload the new policy into the local cache, pretty standard process in case you like to try you can restart the beacon engine service.
You can also check the rule execution discovery and adoption log file to see is it really happening through that rule.
Default location for logs C:\ProgramData\Flexera Software\Compliance\Logging\InventoryRule
Discovery log is best starting point to check if beacon is getting the correct authorised list and target list.
Authorizing IP range 'XX.YY.ZZ.YZ/AB' >> mean beacon is authorised to target device within this range
...
...
...
Including IP range 'XX.YY.ZZ.24' >> List of device that are targeted by this rule.
Adoption log will list of target device beacon finally going to adopt.
HTH
Aamer
Mar 30, 2020 04:38 PM
we gave a look in the beacon log
the log file have timestamp of today, to log inside have timestamp of 4 days ago.
Still wrong IPs of the subnet Ys are reported.
Mar 31, 2020 04:34 AM
Hi,
Assigning a Beacon to a specific subnet is not enough.
Each rule consists of an action and a target. In the target, you have specify the name or IP addresses (or subnets) that the action will be executed on.
Asking the obvious: Can you confirm that you did update the target used in the adoption rule to contain the correct target computer names or IP addresses?
Apr 01, 2020 12:12 PM
Apr 02, 2020 03:53 AM
Apr 02, 2020 06:42 AM
We found out the the log was driving us completely out of the road.
The problem has been found and was that the target env had the ping disabled so we added in the registry of the beacon DefaultPingSweepOptions with -PS and it worked.
So now I don't know if there were a bug in the log that was describing me a different situation, or if there is another log to see this type of errors
Apr 03, 2020 03:52 AM