Mid-Baseline Action Client ID Reset

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.

Anyone else run into this? Any advice?

1 Like

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.

At 02:09:42 -0400 -
Unrestricted mode
Scheduling client reset; Computer id changed to 123456789
Configuring listener without wake-on-lan
Registered with url ‘
Registration Server version , Relay version
Relay does not require authentication.
At 02:10:13 -0400 -
Failed automatic client authentication key exchange with server message: Unable to forward key-exchange: HTTP Error 28: Timeout was reached
Client has an AuthenticationCertificate
Using localhost. Parent Relay selected: relay.corp.com. at: on: IPV4 (Using setting IPV4ThenIPV6)
Client resetting
At 02:10:28 -0400 -
Unrestricted mode
Created mailboxsite and marking to gather

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?

1 Like

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.