I keep bumping into an odd situation with baseline actions where they will inaccurately show ‘complete’ when they aren’t. (Our environment is on 9.5.14.)
I have a baseline of about 20 steps. Sometimes one of the early tasks in the baseline will hang (during uninstall of old software). The action window expires. The baseline action status now shows ‘Complete’, not ‘Failed’ or ‘Expired’ as I would expect. This leads to embarrassing situations were I believe that baselines are done when they aren’t.
I’ve not heard that one before. Is there anything to the relevance that could have toggled it to non-relevant later? Are the baseline components marked with “include in baseline relevance’”?
You should probably open a support ticket so we can review the statuses with you.
I did a deeper dive on into this and discovered that for some unknown reason the client was attempting to re-register and re-set its identify following a mid-baseline reboot! I’ve used Bigfix for many years, but never seen this mid-action before.
I got some good advice from my SE. To determine frequency of the reset bug/defect, I created an analysis for this:
(number of (lines whose(it as lowercase contains “scheduling client reset”) of files whose( (exists lines of it) AND (name of it as lowercase ends with “.log” OR name of it as lowercase ends with “.bkg”) AND modification time of it > now - 30 * day) of folders “__Global/Logs” of ((data folder of client)|(folder “/var/opt/BESClient/__BESData”)|(folder “/Library/Application Support/BigFix/BES Agent/__BESData”)|(folder “__BESData” of parent folder of client))))
I was surprised to find 66 computers in our mid-sized environment had reset themselves within the past month. I have a case open with HCL to understand if there is a bug in the reset mechanism on 9.5.14.
The HCL case for this issue is on-going. We currently see 85 clients with ID resets in their logs. I estimate that 15% of those are from legitimate computer rebuild reasons.
The commonality between these clients is they were running a baseline action that includes at least one mid-baseline reboot. The specific baseline or content of the baseline doesn’t appear to matter.
I’m curious if anyone else has created the analysis I did in the prior post. If so, are you seeing ID resets that are unexpected? If you are, is the last action to the old client ID an action that contains a restart?
We are having an issue with our Citrix Provisioning Services environment where the client ID is getting reset. We see the following message in the client log: Scheduling client reset; Computer id changed to 551744474
Citrix PVS boots off a master image. We restart these servers every night. In order to maintain the same Bigfix client ID, we have created a persistent partition called the W: drive. We also save the Bigfix registry hive at shutdown and then restore it at startup. This all seems to work. The restart is at 11 PM.
The odd thing is that we are seeing the Scheduling client reset; Computer id changed to xxxxxxxxxx way later in the morning, like 6 AM.