(imported topic written by SystemAdmin)
A new feature for checking the health of your BES Deployment and finding possible performance problems has been published to the BES Support site and should be available in the BES Console.
Find it in the Nav Bar->BES Administration->Deployment Health Checks
Please have a look at it and post any feedback you may have here.
(imported comment written by dgibson91)
Very Nice.
How do you delete Expired Hidden Actions?
Do most people fail the “Operators Using Policy Actions” check? We use policy actions to ensure all new PCs get the patches we already deployed.
(imported comment written by SystemAdmin)
You can view hidden actions by setting the following registry key on your computer. Notice that it is in the HKCurrentUser branch so it will only affect your BES Console on your computer. You’ll need to restart your BES Console to see the actions.
HKCU\Software\BigFix\Enterprise Console\Settings\ShowAllActions
DWORD
= 1
Please be very careful using the BES Console in this mode, many hidden actions are important for the normal operation of BES and stopping them or deleting them will cause your deployment problems. Management Rights actions and Site Subscription actions are especially important to not stop/delete.
In this case, the actions are already expired so it should be safe to delete them. Since these actions are typically hidden, I am curious to know what sorts of hidden actions have built up on your system. If you could please provide some data on this that would be very helpful.
Finally, please turn off the ShowAllActions settings if you aren’t using it to prevent yourself from accidently doing something bad.
I suspect that there are 2 types of Operators using Policy actions. First would be special accounts that Admins have set up specifically to issue Policy actions so that they are seperated out from other actions. Second would be Operators that don’t know best practices for deploying actions and are unknownly issuing lots of Policy actions that will live in the system forever.
This HC is intended to catch the second type so you can find them and educate them on how to set expiration dates on their actions. If it catches the first type of operators hopefully you will be well aware of why they are issuing Policy actions and you can safely ignore the Failed health check.
I couldn’t think of a great way to distinguish between the first and second operator types from a programatic standpoint. If you have any ideas please share.
(imported comment written by dgibson91)
It seems like all of the hidden expired actions were Start and End actions.
Does the “Operators Using Policy Actions” also include stopped actions? We have one operator who isn’t expiring his actions, but stops them when all clients install the patches. He is showing up on the health check, but has no open actions.
(imported comment written by SystemAdmin)
Ok, there could be a lot going on here.
In 5.1 a hidden start and end action would be attached to a multiple-action group. The start/end actions expire with the action sets. The hidden start/end actions have actions id’s one less and one more then the actions in the multiple action group.
So, there are probably two things going on here:
The middle actions for expired multiple action groups have been deleted but not the start/end actions. When you deleted expired actions the start/end actions get left behind. It is safe to delete these actions and clear them out of the console.
Your user is likely taking policy actions on multiple action groups. When he stops the multiple action group he’ll actually leave behind open policy start/end actions. You should go in and stop/delete these actions as well. The health check is only looking for open actions but there are probably open hidden start/end actions for the user.
In general, you can spot start/end actions that need to be deleted and stopped if the start action id is less then the end action id and there are no actions between the start and end actions.
Example:
Start action id is 35
End action id is 42
No actions appear with ids 36-41.
So the start and end actions are left behind and the middle actions are gone. You can safely clear out the start/end actions in this situation.
BES 6.0 doesn’t create start/end actions anymore, you’ll now see 'multiple action group’s.
(imported comment written by SystemAdmin)
The health checks dashboard has been updated. It has been moved into the Dashboards section of the navigation bar and will only be visible to master operators. The update introduces an analysis for diagnosing the BES infrastructure and additional health checks.
(imported comment written by Bjowah91)
Hi,
it also seams to be change actions on manual groups.
like: Change ‘_Group_0%group%, %user%’ Setting
Do they have to be open forever?
(imported comment written by SystemAdmin)
Hi Bjowah,
Yes, adding computers to manual computer groups creates an open hidden policy action that subscribes or removes computers from the manual group. These are created as lasting forever because we don’t know how long it will take before computers receive the action but I agree that it would be better to set some expiration date on them. Once the action runs on computers to add/remove computers it can be safely stopped and deleted. You will see hidden actions build up though and you’ll likely need to remove them at some point once there are too many of them.
Would it be helpful to have a health check that looks specifically for these actions?
It is strongly recommended that you use automatic groups rather then manual groups in 6.0 for this reason. Automatic groups avoid using actions to add/remove computer altogether and are much more efficient for the system.
(imported comment written by Bjowah91)
Okey, I see. Perhaps a 6 mounth timout would do I hardly belive any computer will respond later than that?!
Yes if you could match the completed actions and mark them as removable it would certainly be appreciated.
/Björn
PS sorry about the late reply DS
(imported comment written by rclarke)
I have just spotted an odd inconsistency with this otherwise excellent Dashboard. According to the Dashboard I have 2 Relays out of 15 that are still running with version 6.0.12.5 of the service, whereas all others are up to date with version 6.0.15.7. However, I deployed an Action back in October 2006 to upgrade all the Relays and it reported back with a status of 100% fixed. Furthermore, the “Updated BES Relay Now Available! (Version 6.0.15)” Fixlet is not reporting as relevant for these 2 Relays. Forcing the upgrade Fixlet onto the two servers results in a “Not Relevant” status, however checking the BESRelay.exe version on the actual Relays themselves returns 6.0.12.5. Does anyone have any recommendations or suggestions, such as running the BES Relay upgrade manually?
Thanks,
Rod.
(imported comment written by SystemAdmin)
Hi Rodney,
Interesting, running the upgrade manually sounds like a good idea. You could also modify the upgrade action script and remove the silent flag and then see if we get an error message when the upgrade runs:
wait __download\BESRelayUpgrade-6.0.15.7.exe
Finally, it would be worth doing a restart and then try upgrading the BES Relay again. Normally the BES Relay upgrade doesn’t require a restart but this would be worth checking on.
(imported comment written by rclarke)
Thanks Tyler. The manual upgrade works, therfore the upgrade Fixlet must be checking some parameter or other that has been changed during a failed install, hence why the Fixlet reports as being no longer relevant.
Rod.
(imported comment written by ErnieF91)
Health Check showed we had a large number of open hidden actions. I used your registry setting and saw that several hundred of them are actions to add and delete computers to manual groups. These were issued months ago, are these ok to stop and then remove?
Ernie
(imported comment written by BenKus)
Hey Ernie,
Yes. The only downside would be that if you put a computer in a group and it was off for extended amounts of time and never received the action, it would not know it was in the group. This is fairly unlikely and so it is usually safe to remove these actions. It also can significantly speed some things up in your BES Consoles.
Ben
(imported comment written by jessewk)
Hi Ernie,
Please be careful to only stop the group membership actions. There are other types of hidden actions and stopping some of them may cause major problems. If you have any doubt, please don’t stop the action and post a question here or call support.
-Jesse
(imported comment written by bdoellefeld)
@jessewk
Can you give an example of actions that should not be deleted. I see 600+ open hidden actions, most are manual group changes, but there are some that are “Assign and Revoke Management Rights For username”. I should add that none of these actions show complete…
(imported comment written by SystemAdmin)
You won’t see action results for most of the hidden actions, management rights in particular. The BES Console doesn’t bother to load the results since the actions are hidden normally and the results will just eat up space.
Here are the types of hidden actions and a brief description on when it may be appropriate to stop them:
Assign and Revoke Management Rights For… - This actions make BES Clients show up as managed for non-master console operators. Never stop these actions (I don’t know of any reason to stop these).
Subscribe to Site http://… or Unsubscribe from Site http:// - Subscription actions that make BES Clients load all of your Fixlet data. Never stop these actions (I don’t know of any reason to stop these).
Change ‘_Group_0…’ Setting - These actions tell BES Clients to join a manual computer group. You might decide to stop these actions if you believe they have already run on BES Clients or never will. Action status reports will not show up so you would need to look at the clients and compare them to the manual group to decide if the action has run or not.
start and end actions - Earlier versions of BES (5.1) had hidden start and end actions on multiple action groups. In some versions, you could delete the middle actions and unknowningly leave behind the hidden start/end actions. Its ok to stop/delete the start/end actions if you have already deleted the middle actions.
That’s all I can think of, I think that’s the complete list.
(imported comment written by Rolf.Wilhelm91)
Hi Tyler,
I know, this thread is very old, but I was just pointed to it from the Support Team, because of the high number of hidden actions reported in my Health Check Dashboard (21660).
While not seeing these 21000 entries, only some, I found a lot of unneeded action, but you wrote:
I have a reason. We have sometimes a lot of hidden actions belonging to one useraccout (e.g. creating, modification, modification, deletion). Espacially, if the deletion is a year old or longer, I think I can stop/delete all of them regarding one individual account, right ?
Also, if there are several rights assignment actions, I can stop/delete the older ones, as it seems one modifictation action always contains the complete rights definition.
Also, if you have an idea where to find these 21660 hidden actions (I can see group changes and account actions, but only around 3-400, not 21000. Looking at the complete situation, including stopped and expired actions, of course… we currently seems to have an issue with too much actions.
Thanks,
Rolf.
(imported comment written by SystemAdmin)
Hey Rolf,
I’m not sure I follow what you are seeing completely. I would probably suggest you contact support, there is a setting we can put on your computer to let you see the hidden actions and it would be best to work with someone enabling the feature and going through the actions with you. I discuss the setting in post #3 above if you want to try enabling it on your own.
If you have actions in the system from a user that has been deleted or hasn’t used there account in a year, you can certainly stop/delete their actions as long as you don’t think they are needed anymore. THe ‘assign and revoke management rights for…’ is a single action per user and I believe it is a hidden action so I don’t think you are looking at what I was referring to earlier. You probably shouldn’t delete this action still, you’ll just get one action per user.
If you use baselines a lot that could be where all the actions are. Each baseline action creates a Multiple Action Group which looks like a single action in you action list and counts but it actually multiple actions; the health check counts all the subactions separately. If you use manual computer groups you could have a lot of hidden actions creating/deleting manual computer groups.
(imported comment written by Lion014291)
My health Cheks work how ever when I attempt to send the information I get the following error Sending failed. Error: (12019)