Since version 6, where the console has no longer the dialog components to define the date at which a specific lock will be turned off, we ran into troubles with local administrators locking their whole site indefinite.
Because I (as the global admin) do not want to override these settings (do not know, what production processes will be disturbed or interrupted with this), I cannot patch those systems anymore.
It is politically in my company not very easy to force them following the (existing) security guidelines.
I would like to have an option in the next version:
to control, how long a regular admin (not a global admin) can lock a specific system under his/her control
I have a task defined to lock a system for 4 weeks (because the language components still exists, only the gui part was removed), but this is used only very rare, because it is much easier to right click on specific systems and check “lock”. As an alternative, it would help to disable the lock-functionality in the Console, because than the local admins have to use the existing fixlets/task to lock. They do not have the rights to create custom content.
Automatically unlock any computer that has been locked for 4 weeks (regardless of how it was locked).
Require that people use the custom “Lock Task” you wrote, and if they do not, there is a policy that automatically unlocks their computers.
Create a report of computers that were locked without using your custom Lock Task.
yes, this is technically spoken useful, but very hard to implement because of some social parameters. Need at least some months(!) to prepare and a definite commitment from our global security group. We have a high risk that this will brake some production processes when the BESClient will start installing all missing patches (but we will have this problem sooner or later anyway with these systems).
I understand that my wish will not be easy to implement, but it was easier to handle this as long as he had the feature in the console to set an end date for the lock - this (for me important feature) was stripped in the v6-Console. Until that, it was easy to discuss with the people, saying that an end date for the lock is needed all the time. I needed some weeks and a hint from a regional manager missing that feature that something has changed after upgrading to v6 (and I still do not understand why this was removed).
I will discuss your proposal with our global security group - to problem to implement the technical part of it.
Late in the BES 6.0 release cycle, we had discovered a bug in the “Lock Until” setting that caused it to have a serious error where it would unlock at the wrong time. This behavior was in all versions of BES and we had to make a decision about the best way to fix it. Since we had never heard of any customer reporting the error, we checked with many customers and we could not find anyone who actually used this feature. Based on the fact there was an error and we were reluctant to change things so late in the release cycle, we chose to remove the feature because we figured that if anyone needed this functionality, it would be possible to implement it with a custom task.
We are very reluctant to remove features from the product and I am sorry to hear that we caused you these issues.
Let me know if we can help with a custom report or custom Fixlet that helps your issue or at least shows you a report or property about how long computers were locked for.
thanks for offering your help, I think I have all needed procedures in place to have an overview.
Here is the property to analyse the lock duration:
if (locked of action lock state) then if exists value “effective date” of key “HKEY_LOCAL_MACHINE\Software\BigFix\EnterpriseClient\Settings\Client__LockState” of Registry then (now - (value “effective date” of key “HKEY_LOCAL_MACHINE\Software\BigFix\EnterpriseClient\Settings\Client__LockState” of Registry as time)) as string else “<Lock Date unknown >” else “<unlocked >”
(I know, this will work only for Windows, if you know about a built in method to analyse the occurance of the lock…)
Here is a fixlet task to lock a system for 4 weeks:
action lock until “{now + (4*week)}” “{now}”
But I cannot force the usage of the task as long as there is such an easy way simply with a right click on a computer name or selection. I have a very uncooperative group of local administrators in a single region and they do not want to understand why to patch and they and their users feel very annoyed each time if we try to push anything onto their systems. They to everything not to get interrupted. And they have a very high regional management attention…
{if ((first 2 of following text of position 17 of (now as string) as integer) < 18 and (first 2 of following text of position 17 of (now as string) as integer) > 8) then “true” else “false”}
Yes that would work. If you’re on 6.0 though, I prefer to use some new inspectors for time/date because I find it much easier to read and understand the policy. Here’s an example:
(if ((disjunction of (it = Monday; it = Tuesday; it = Wednesday; it = Thursday; it = Friday) of current day_of_week AND (hour_of_day of time (local time zone) of now) >= 7 AND (hour_of_day of time (local time zone) of now) < 18) OR (current day_of_week = Saturday AND (hour_of_day of time (local time zone) of now) >= 7 AND (hour_of_day of time (local time zone) of now) < 14)) then “True” else “False” )
It’s pretty easy to see that the policy locks computers M-F, 7am - 6pm and Sat, 7am - 2pm.
Essentially, add the setting through the edit settings dialog and an action will be issued. As soon as clients gather the action they will begin to obey the new locking behavior.
Can you post the relevance you’re using for your setting and the behavior you expect?
if ((first 2 of following text of position 17 of (now as string) as integer) < 20 and (first 2 of following text of position 17 of (now as string) as integer) > 7) then “true” else “false”
Please test this very carefully and roll it out to only a few machines first. Be aware that any clients that receive this setting will not take any actions between the hours of 7 a.m. and 8 p.m. (client local time).
If the action is stopped/deleted, machines that took the action before it was stopped will continue to enforce the locking behavior until the __LockState setting is set to a new value.
You can stop the action when you are comfortable that all machines you want to enforce the policy have run the action once. If you will have new machines coming online that you want to receive the locking policy, you should leave it open.
>” else “<unlocked 
>”