Client Locking Questions

We are running BF 9.5.9.62 and utilizing the Maintenance Window Dashboard to auto lock our clients (Enforce Maintenance Window with Client Locking" This works well for the clients that have recurring actions take place (ex. patching) as we can define the maint. window to that (Second Friday of month, etc) and then know the client will be unlocked at the time we schedule patching or another task. A few pain points I have with the maintenance window functionality listed below. If someone can provide alternatives to remediate or provide suggestions it would be most appreciated:

  1. Can only set maint. windows according to client time. We can certainly separate into different groups according to time zone and set maint. window for each group per their time zone, but that can get messy within the maintenance window dashboard quickly. Allowing to set in UTC would be ideal like you can with fixlets when executing. Any ideas here?

  2. Can only set one maintenance window per client. If we could define multiple maintenance windows per client or group that would allow us to schedule/execute and not have to worry if the client is going to be unlocked or not . Example: We setup client patching windows so the clients will be unlocked, but if we have an ad-hoc request or task we need to perform we are either forced to create another maintenance window and execute it against the clients so they are defined, however this overrides the first maintenance window that was set and I can see operators in BF forgetting to rerun the original maint. window that was set for the client to adhere to.

    • Our thoughts on approaching this today would be to leave the initial client defined maintenance window, manually unlock the clients to run an ad-hoc task, run the ad-hoc task, and the rerun the “Enforced Maintenance Window with Client Locking” task to ensure clients are locked unless in the defined maint window. Anyone else have a better approach? I even had thoughts on leaving “Enforced Maintenance Window with Client Locking” in an open action targeting all servers in BF based on relevance if they are unlocked for more than X hours and don’t have an open action against them to run the “Enforced Maintenance Window with Client Locking” task. This would ensure all servers after a period of time are adhering to being locked unless in a maint window even if they are manually unlocked to perform an ad-hoc task. Any thoughts on this approach? If it seems like a good approach can someone provide guidance on creating a relevance as such?

Please see if the following might help with the 2nd bullet above:

Thanks for the update. We have utilized this in the past and per IBM this is the backwards method of utilizing the maintenance windows and that maintenance windows should specifically be leveraged to adhere client locking. We thought of having our baselines we provision targeted globally with the constraint you mentioned that it wouldn’t apply to any endpoints unless their maintenance window = true. My worry here is what does that look like in terms of performance degradation of having 10 or more baselines targeted globally with that constraint set for specific groups?

My priority is identifying a relevance to use on the “Enforced Maintenance Window with Client Locking” task to leave that an a open state targeting endpoints that become relevant. The relevance would be something like “If endpoint has been unlocked for X hours and is NOT included an a open action the “Enforced Maintenance Window with Client Locking” would run to lock the endpoint to adhere to it’s defined maintenance window” This would allow us to ensure even if endpoints are manually unlocked they get put back into the enforcement locking with maintenance windows. Can someone expand on what type of relevance we can set there to achieve this?

Does anyone have any insight on the specific relevance we can set to achieve the above?