Server Automation Baseline actions

Has functionality changed in SA in relation to how the console lists baseline actions under the main Action tab? Previously I would get a single line item for an SA baseline listing the status of the action. We could then drill into the action to see the individual patches/tasks and status.
Now I am getting a single line item for each step/patch in the baseline listing under Actions. 1 each for every download/patch/etc step and it blew up my action list. Very hard to read.
I have not updated the SA job this year. Can anyone confirm if they are seeing the same thing?

If this is the new new, I may stop using SA

I had this happen last week, please review that it actually honored the relevance of all of the tasks.

My normal 9 step plan managed to generate 340 actions, and ignored all of the target relevance of the fixlets and tasks… aka installing SQL vs updating only when exists.

I have a case open with support, and still investigating.

I noticed that i get popup errors in the BES console when i try to review a few steps, may mean there is corruption in the job definition.

Yep. I just blew up one of my NP environments (700 servers) disk space due to ignored relevance. SQL patches went out to all servers when relevance should only have hit like 30.
I am stopping ALL SA jobs at this time.

@mesee2 & @Meydey - what version of SA are you running?

Not sure how to tell. I know there is an update pending but I was hesitant as SA broke the last time I upgraded.
Have not made any Bigfix version updates in awhile, and SA ran fine last month.

Edit: 9.5.0
Bigfix Core: 10.0.0

Last updated May 2019. Tried last year but had to roll back

Thanks for the update. There were issues with the previous version.

The newest version is 64-bit, and promises improved performance, but haven’t tried it yet.

[Edited] FYI - The full version is in the Enterprise Server Folder under Applications\PlanEngine\config\metadata.xml.

Thanks. v9.5.52
Do we know what the current version is?

The current version is 9.5.58.

I have an SA job running tomorrow morning that I am going to let run as its already cached. Will stop other jobs after that and upgrade version to see if the issue resolves.
Will report back if it works or borks. Not trusting to run the current version against my prod environment.

1 Like

Was running 9.5.57 when this occurred.

  • it was reporting an update available, but had not taken it.

I have since taken the update and am at 9.5.58
– Still at same Bigfix release of 10.0.3, but scheduled to update to 10.0.4 next week.

Even at the newer engine, I am unable to open all of the steps for the workflow that had the issue installing SQL.

Other workflows appear to be able to be opened and are running ok. So I expect to have to delete and rebuilt the corrupt flow and things should work… But waiting to sync up with support for a final review.

1 Like

I do not believe that this has been corrected.
The issue I see is that using a baseline directly causes each patch in the baseline to action as a separate step.

  1. Using the “Dynamically run baselines from site” step which basically looks for a baseline in a site. (this is how it should look)
    image
    image

  2. And using the action that attaches directly to a baseline (which was recommended to me and how most of my Sa jobs are built)
    image
    image

When the 2nd SA job is run, it creates an action step for each baseline patch in the action listing, instead of a single action for the whole baseline. I do not know if the relevance is still affected, but last month this cause the relevance to break and send each patch in the baseline to each server in the action. ie 2019 patches were cached on 2016 along with the relevant 2016 patches, and sql updates were pushed to non-sql server (causing space issues).

If this is a new feature in Server Automation when directly using baselines in an action, then it is unusable in my context and breaks my SA jobs.

Edit: v9.5.58 dated 19/07/2021

Edit: Meh, I ended up rebuilding the bad SA jobs using step 137 (Dynamically run Baselines from a site), seems to work like old that way.