If you create a task specifying ‘Run Command As Current User (Windows Only)’ during publishing/creation, it looks like the task only becomes relevant on machines with a logged-in user at the point in time when the task was created. In order for the task to become relevant on other machines, you either have to:
a) Make a change to the task (for instance remove some relevance statement, save the task, and insert the same relevance statement again), OR
b) Perform ‘Take action’ (marking the ‘Run when at least one…’ button on the User tab)
Futhermore, it looks like a policy set up for a task created as decribed above, will never become relevant on new machines, no matter how many times you restart or log in on the machine.
Can anybody shed some light on this? Is this working as designed?
Did some more testing, and it looks like the determining factor is whether a user is logged in when the BigFix agent starts:
A policy for a ‘Run Command As Current User (Windows Only)’ task will only be executed on machines with a logged-in user, and, when the user was logged in when the BigFix agent on the machine started. If the user logs in after the BigFix agent starts, the task will never be executed, no matter how many restarts/logins performed! In this case the task is not even mentioned in the agent log.
I think you need to give us more information here - what are your relevance statements and how long do you let your testing run?
Personally, I would not create a fixlet or task with relevance for a logged on user, but instead set the conditions in the ‘Users’ tab when creating an action for the fixlet/task.
Hi!
Well, I am still scratching my head over this. It looks like another ‘determining factor’ is that the machine was unkown to BigFix (no BigFix agent installed) when the policy was created.
The following relevance statement is automatically created when you publish and specify ‘Run Command As Current User (Windows Only)’:
(if(name of operating system as lowercase starts with “win”) then exists logged on users else true)
In addition to the above, I have a relevance checking for a footprint file:
not exists file (“C:\Users” & (name of logged on user whose (active of it = True)) & “\AppData\Local\BigFix\FootPrint.txt”)
And finally, I also check the condition requiring a user to be logged on in the ‘Users’ tab.
I have not let the tests run for more than maybe 30 minutes, but the tests have been run in a controlled VM based environment. I have also seen this problem in a production environment (policy not executed on machines that were built after policy created).
I believe the behavior you are seeing is that after the action has first evaluated to False, you may have to wait longer before it is re-evaluated again as part of the normal client loop. It should, eventually, run after a user logs on but after the first evaluation it is no longer “new/priority”.
Depending on how long your client evaluation loop is, it might take a while before the action runs.
A better option as @trn points out is to let the Fixlet/action be Relevant, but constrained with the “Only run when a user is logged on” option in the Action Settings. A Constraint is evaluated at a higher priority than action relevance, so that should make it run sooner after a user login.