All of the documentation I’ve been able to find in the Inspectors Guides and the Inspector Search dealing with the “systen constraint” property of Actions is incorrect. It references three-digit numbers in the 201, 202, etc. range; but in practice I’ve found that the value 6 actually means pending restart; 9 is also pending restart, but might mean “failed and will retry” but I’m uncertain.
Does anyone have a list of the actual System Constraint values, or know where I could find them?
Can you provide links to the documentation you are referring to? Provide some examples?
System constraint of action returns an integer, one of:
0 = As yet undetermined by system
201 = Missing Fixlet Context
202 = Missing Origin Site
203 = Action Lock
204 = Action Empty
205 = Invalid Action Type
206 = Requires User Present
207 = Unlicensed
208 = Waiting For Distribution
209 = Waiting For Download
210 = Action Syntax Error
211 = Constraint Pending Restart
212 = Constraint Pending Login.
(This list is Not Correct)
If this is possible, I would try adding system constraints of actions or whatever to an analysis property and then use session relevance to get all the unique values of the results and see what all possibilities can be detected to try to find those not in the documentation. I’ll have to give this a try.
Unfortunately there’s not an “actions” property; we have to use action(#) or actions (#;#;#). Where I’m looking up all actions, I check
actions (ids of fixlets of sites)
which is quite slow and has to run in Local Client Evaluator context in the debugger.
The larger context for this is “Maintenance Windows on Steroids”. I set up maybe 20 patch baseline actions to run on All Computers, and constrain them by a custom property “PatchWindowState”. As each machine becomes available for patching, I push an action to change the “PatchWindowState” value on that machine. This allows my constrained patch baseline actions to begin running. None of the patch baseline actions include a post-action reboot.
I have another action polling every half hour to check whether all of the patch baseline actions are complete. When all of them are complete, or pending restart, I reboot the client. This reduces the total number of reboots that occur with the overlapping patch baselines (one reboot to finish them all). The difficulty I’m having is in determining when all of the patch baseline actions are actually finished (or cannot progress until after a reboot).
The “status of action” doesn’t always give me correct values (or, at least not the same values as the status in the console). I’ve resorted to using “constaint” and “system constraint” to try to get more detailed status from the client.
If a patch baseline action fails, but has a “retry on failure after a reboot”, it reports status “Pending Restart” only if one of the actions has an “action requires restart”. If it’s failed, and is waiting for a reboot to retry, but nothing flagged “action requires restart”, instead it reports a status of “Waiting”; but I’ve seen it set “constraint” to 6 and/or “system constraint” to 28.
I believe I’ve also encountered a “constraint” value of 9 when the action is “Pending Downloads”, even where “status of action” returns “Waiting”.
I’m trying to get a real list of “constraint” and “system constraint” values so I can correctly determine when my client is finished with actions and ready to restart.
Is this for patching servers or workstations?
My approach to patching workstations is very different.
First of all, all of my systems have had SSDs for many years, so I never need to worry about user impact of a running action.
I have patches run anytime with no restart set. Then I would use the “Restart Needed - Triggered by a BES Action” task set to reapply while relevant waiting 7 days between reapplications with a deadline of 3 days to reboot. This would mean the system would reboot at least once every 10 days if needed. I’d then tell users that they should reboot their computers at the end of the day at least once a week to prevent being bugged by the reboot notification.
What if you rebooted the machine at the beginning of the window instead of the end of the window?
The action that changes the “PatchWindowState” would only change it if there is not a pending restart & it is in the window. If there is a pending restart, it reboots the system and then it will change the “PatchWindowState” after the reboot.
This is in a 24x7 critical system (manned spaceflight). Our biggest use-case is where the end operator knows “I have 4 machines that do function X, and I want to control when they patch, reboot, verify, move on to the next”, while my main concern is having everything up to date.
I have an Offer allowing them to “Opt-In” to the Patch Window when they want, usually for a week, followed by another action to force the Patch Window open for all systems to enforce a deadline. It really reduced the time we spent scheduling uodates by delegating the timing to the end-users. And I no longer have to track which 4 systems do X function to stagger the action start times.
Where I get hung is where my Polling action cannot definitively Reboot or Close the Patch Window because I’m having trouble determing the “real” action states. The “status of action” on the client doesn’t always match the console. I’m pretty certain that “constraint of action” and “system constraint of action” tell me what I need, but I don’t have a list of all of the values.
Bump, anyone? Anyone know how to get a list of valid “constraint of action” and “system constraint of action” values and their meanings?
I don’t think you’ll be able to use these values for what you’re trying to achieve. You may have noticed in the doc link you referenced that this is an internal inspector. What that generally means is that it is used for specific purposes within the client’s logic, but likely won’t work as other inspectors do. Specifically, I think you’ll find using this inspector for fixlet relevance will not give intended results.
What I would suggest instead is to put a task at the end of each patch baseline that sets/updates a setting to indicate patching has been completed and mark your baselines to not continue on error. You could even include logic that makes it run through each baseline a few times in case patch installation affects relevance of other patches in the baseline. Then have your reboot action check that all baseline completion settings have been set.
That’s rather disappointing to hear. I have the whole system working in such a way that I’m pretty happy now, but I want to be sure I’be covered all of the edge cases.
Using a task to apply a Client Setting isn’t sufficient, because I have an unknown number of baselines to execute that vary by client. Such a task could let me know that a given baseline is complete, but it would never be set if the baseline wasn’t relevant to begin with.
You could configure the setting task to be part of the baseline applicability so it would always run at least once to set the setting. That way you will always check for settings from all baselines.
If you want to stick with what you have, I wouldn’t try to cover all edge cases, but think of the situations you want to reboot for and try to cover those. All waiting/pending states for the client will return “Waiting” for “status of action” and provide the detail in the system constraint, as you’ve seen. For the key statuses of interest, though, you might be able to use some of the boolean results from the following relevance stmts:
q: properties whose (it as string contains “action”)
A: active count of : integer
A: constrained of : boolean
A: pending of : boolean
A: waiting for download of : boolean
A: pending restart of : boolean
A: pending login of : boolean
A: offer accepted of : boolean
A: complete time of : time
A: download failure of : integer
A: exit code of : integer
A: status of : string