Not from the information you have provided. In order to eligible when the device is scanned it needs to have failed 7 consecutive scans and been over 10 days since the success. Just going past the 10 days within a scanning will not have it removed.
Running the report gives me a string describing the reason in removal eligibility rather than FALSE.
In our case, on the report in the UI, some of the 'Removal Eligibility' reasons show "No" which turns into a "False" when you export the report into a CSV. I don't understand why some hosts would not be eligible given both the 'Last Successful Scan' (over 10 days) and 'Consecutive Scan Failures' (failed 7 consecutive scans) conditions are met. One thing I noticed is that each of these hosts appear to have duplicate host records but the record that's approaching its removal threshold does not have any Discovery Access information. Maybe these records need to be destroyed manually?
One thing I have faced in my environment is:
We were facing some issues due to which we were not able to run discovery for a long time ultimately discovery access for some hosts have been aged out according to the DDD Removal Policy but host node remains in the datastore because it didn't meet aged out policy yet.
Once we back in production we started running discovery but that time duplicate host got created for some host. Because when you will run discovery, identification algorithm will first try to search in a data store for existing node with IP. If yes it will update if no it will create a new node. At this point of time, your old node will never get deleted because Discovery will never try to attempt on that old node as the IP is pointing to new Host node now.
At this point of time, your old node will never get deleted because Discovery will never try to attempt on that old node as the IP is pointing to new Host node now.
You have to delete these old nodes manually if you have the same situation.
The last DA for an endpoint is not aged out (except if it is marked as darkspace).
That is not correct. All recent (10.1 and later) use Endpoint nodes not DiscoveryAccess chains, for ageing. Hence it does not matter is a change of identity has cause the Host to end up without an associated DA chain.
Thanks for the clarification Andrew,
But can you please tell me that is there any way of checking whether the endpoint is marked as darkspace or not?