Why does it need to be stopped after completion? What is the use case?
You can set the expiration of the action, which is 2 days by default. It will automatically be stopped at the end of that time period.
As long as the action is not set to reapply, it will only run once.
Hi @jgstew
Thanks for your response. I understand that action automatically expire after 2 days and I can also set the execution plan as well. But the use case is not all but some specific actions should be stop automatically after the completion rather that get expires.
You can fairly easily do this with the REST API – compare the target computer list with the action results list and as long as they all say completed you can stop the action via the REST API.
The issue is this will only work if you are selecting devices – it won’t work if you are dynamically targeting by property because you don’t have a target list of computers to compare against.
This being said – it seems like a lot of work for something that seems to be solved by an action that is set with an expiration and the option to not re-apply if relevant again.
The primary reason for stopping and deleting actions is for console performance reasons and some mild infrastructure performance reasons. It is more of a long term thing of keeping things in good order, but it isn’t something that has to be addressed quickly.
I get what your trying to do. The platform doesn’t work that way. The action is simply an advertisement for an endpoint(s) to do something. If/when the endpoint get it is dictated by the execution criteria. It “Expires” when the you wanted it to no longer be available any more.
BES is basically holding up a build board for a time frame to do something to center end points. “Expired” basically means the build board was taken down.
Yes the primary reason for that is the performance of console. Wondering that there should be an option to stops actions as soon as they’re completed.
How many actions do you have?
Do you have slow console performance now? How slow?
Definitely I’m facing slow console problems. And in normal operation there are around 250 actions issue on daily basis.
I hope you got my pain area.
Have you looked at the server itself to identify and resource constraints? Have you looked at reducing the default console refresh rate?
You might want to consider contacting a professional services group (IBM has one, my company has one, and there are a lot of BigFix consultants out there) to see if they can’t help improve the performance of your server given your organization’s usage of the tool.
There are many potential sources of console performance issues. It is possible that stopping actions this aggressively will not address your issues, and that there may be a much better way to address it.
Hi @jgstew
I can understand that you’re trying to say that there are multiple factors on which console performance depends upon. The answer to your queries are:
Based on your usage there is something wrong with your BigFix server setup. Console performance should be lightening fast with 2 operators and 500 endpoints.
Who setup your BigFix environment? How is your server specced?
It’s interesting that you are building up 250 new actions per day with only 500 machines.
With an expiration of 2 days, you should have well under 1000 open actions.
However, once an action expires, it still exists, and this can impact console performance. There is a cost of keeping stopped actions in your history. At this rate, there would be building up thousands of stopped actions per month. Deleting those actions could help performance. It will also lose historical information which you may want.
I agree with @strawgate; it might make sense to engage an expert in tuning BigFix.
I agree with @strawgate
Given your number of console operators and endpoints, I suspect an issue with the hardware of your BigFix root server / infrastructure. There could also be network latency issues between your console sessions and the root server. Generally you want the network connection between the console and the root server to be as fast and as low latency as possible.
What are the specs of the root server, in particular the storage backing the BFEnterprise DB and FillDB ?
With that few endpoints and operators, I find it highly unlikely that anything to do with open actions is the cause of slowness.
What behaviors are you experiencing in the console that are a problem? Can you describe it?
Also, I wouldn’t recommend doing this all of the time, but you can install the console on the root server itself and open it there. If you have the same console performance issues there, then the issue is not network related. ( though there can still be timeout issues )
Hi,
Thanks all for their valuable suggestions. I’ll try find out more issues.
Hi @jgstew @strawgate @AgentGuy
When I close the console I saw a dialog box showing thousands of actionsite records (screenshot attached below). I remember I didn’t see that dialog box after few days of BigFix installation. This is just started appearing from past month. Can you guys please identify, what kind of record this dialog box referenced to.
Thanks in advance.
These are not actions, instead this is the console doing cleanup when it closes.
The more things you have in your environment the longer this process takes. When you first started using the product you didn’t see it because it was essentially instantaneous.
Also, if you disable the cache, then you won’t see this at all, but then it will be a tad slower to open the console after you login. If you have a very fast network connection between the console and the root server, then disabling the cache might be fine, particularly with only 2 console operators.
Is this the behaviour that you were trying to mitigate, or is there more than this?
Thanks for information. @jgstew no this is exactly not what i’m trying to mitigate I just thought this was the issue but I was wrong.
I’m looking to mitigate the slow console performance behavior.
Thanks
