I’m looking for a way to reset the action history on a client such that it forgets previous executions of the action, and re-executes the previous actions (that may have succeeded, failed, retried up to the max retry count, etc.)
The use case is with system reimaging. Suppose I have an open patch baseline to execute patches on the client, this action has a retry count of 1, the action retries, and at least one component fails twice.
Then I reimage the client to a new OS image.
The Reimaging tasks preserve the client ID and history from the “old” identity of the client. When the client comes up with a “new” identity, it does not attempt to execute the previously-scheduled patch action because it remembers that action had already failed up to the retry count (under the “old” identity of the client).
Is there a way to make the client forget its previous executions of the action and begin anew? I’d prefer not to perform a full client reset, as I reimage frequently and don’t want a lot of duplicate computers; and I’d rather not re-issue the patch baseline either, as there are multiple operators involved in reimaging & patching and I want to avoid having to coordinate them.
I’m attempting now with deleting ActionHistory.db from the __BESData\Global folder. I don’t know yet whether this will be effective to re-execute old actions, or whether there’s a better way to handle it. Any suggestions?
Maybe if I force unsubscribe/resubscribe to the Content Sites, or to the Operators, or something else ???
The client remembers states based off site membership but that includes action sites. The only clean way would be to delete the entire __BESData directory which will force it to re-gather everything and report on everything again but unless you are 9.5.0 or later you have to be careful as you need to have the client send a full report (which the 9.5.0 or later client will do automatically when it starts up with a deleted actionsite) to make sure the database contains the state as expected by the client. This could be done by an earlier client with a force refresh UDP or action command
Your question - and Alan’s answer make me think I misunderstand something crucial about setting up a “policy” (i.e., no end date) - and relevance to trigger running a fixlet.
My assumption is that I can setup an action to run as a recurring “policy” so that, e.g. a fixlet may repeat, if it becomes relevant again (and can delay the new run by XX time, e.g., 1 hour, 1 day, etc.). All from one action.
What I may be reading into this is that if an action runs - but “fails” - will never re-run because it has cannot trigger itself again. I was assuming the policy settings will reset if the “action” loses relevance and then regains relevance.
In other words - I would have thought there could be an analysis that could note that the action has failed, and in so doing change a condition so that the action loses relevance. Then it is merely a matter of restoring (i.e., removing a relevance blocker) and the action becomes relevant again - just as I would expect it to be if the action was successful, no longer relevant, and then due to changes becomes relevant again.
In short - can’t this be resolved with some extra relevance to make sure the action can “reset” and make it’s previous history of errors - “irrelevant”?
To some extent, yes; but that requires some extra work on setting up the fixlet/baseline relevance.
In my case, I create a monthly baseline of all Windows patches - including both Windows 7 and Windows 10. While I expect the baseline to run to completion, I frequently find at least one patch fails consistently. Whether a false-positive in relevance, or some state of the endpoint that causes the installation to fail, whatever.
To ensure I don’t end up with the action retrying the patch on every restart, I limit it to “retry 3 times” and “reapply whenever it becomes relevant again, limited to 3 reapplications”.
For the most part, that works fine. End of the month I start sorting out which machines failed which patches and clean them up.
The problem came up this month, that a dozen or so Windows 7 clients applied the patch baselines, but one of the actions repeatedly failed on them. So they did the “retry 3 times” then gave up on the action.
A few days after the patch baseline was actioned, we upgraded about 50 clients from Win7 to Win10 using the OSD Reimaging function. I expected that after the upgrade, these would apply the latest baseline, this time applying the Win10 version of the components rather than the Win7 patches. Instead, the client “remembered” that it had already tried & failed the baseline three times, and did not apply the patch baseline (nor any of my other custom configurations that were part of the same baseline rollout).