cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Wrong subnet used in a rule.

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 😮

(6) Replies

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

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.

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?

totally, the list of IPs in the subnet is the same of IPs in the target
Next thing to do, is share beacon policy and rule execution log. Otherwise it’s not easy to help. I am struggling if beacon is getting latest policy from server how come it is using subnet that’s not assigned, bit strange.

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