Skip to main content
Jamf Nation, hosted by Jamf, is a knowledgeable community of Apple-focused admins and Jamf users. Join us in person at the ninth annual Jamf Nation User Conference (JNUC) this November for three days of learning, laughter and IT love.

Policy Execution 'Once Per Computer, If Successful'

Set policy to run once per computer when the script exit code is equivalent to a success.

For instance, if a large package fails to download successfully, and triggers the policy to fail, it should not count as the "once per computer" execution.

Comment
Order by:

Posted: by mm2270

Yeah, I find this to be an annoyance too. I get why it works as it does now, but I'd love to see at least a jamf binary verb to flush any policy errors from a client so we can schedule that for once a week. That way the policy will try to run again at the next scheduled interval. Sometimes a policy error is due to something stupid like a bad network connection and not something more serious.

As it is now, unless you go in and check your policy logs manually, you'll never know what has and hasn't worked and the Macs in scope will never get the policy run on them. (And yes I know about policy error email notifications, but these get lost in a sea of other notifications, so its not as useful as it could be)

The only real workaround to this right now that I know of is to have the policy set to Ongoing and use a Smart Group to make sure any Macs that still don't have "software title x", "package receipt y" or "extension attribute z value" as part of their inventory are in scope.

Like

Posted: by rockpapergoat

this shows the decoupled nature of how scripts and policies work. jamf ships a product that basically facilitates remote code execution, but you need to do a lot of the plumbing to make things happen. trapping exit codes and doing something with them is fine, even reasonable. but what if you have a "run once" policy set just to install something, and it fails? you get the same result: a logged failure and no retry.

compared to other (real) configuration management tools, this behavior isn't idempotent. casper is sort of configuration management, sort of orchestration, and sort of inventory. it could do all three better.

</rant over>

Like

Posted: by bentoms

I do the following, which i guess is a workaround:

  1. Scope the policy to a smart group "i.e. does not have app 1.2"
  2. Set the polciy to run once per day, & to run recon once done.
  3. Configure the JSS to email you on either the deafult (policy failure) or on smart group membership change.
Like

Posted: by brent.buckner

mm270 and bentoms,

This is what I do as well, especially when designing policies to serve as updaters for iPhoto, iMovie, iTunes, iEtc, and it can be a great workaround.

I feel the aforementioned "execution frequency" could specifically simplify deploying patches or software at user logout/logon. I don't like the idea of running recon at logout/logon because in some scenarios it can take up to 5 minutes. Yet, if recon doesn't run, and a user reboots his or her Mac again, the same patch will try to reinstall. I've seen this corrupt the house of cards we like to call Outlook 2011 when updating to 14.2.4, for example.

Like

Posted: by MARL

With 35,000 Macs we need automation, not emails. I cannot tell you how many times we have run into this wondering why oh why we cannot keep this running until success. I cannot believe this was suggested in 2012 and here it is 2014. Come on JAMF!

Like

Posted: by Chris_Hafner

It would be a great and sensible feature. I've used custome receipts, smart groups and a few other solutions for this. Perhaps the error type could be set as well. Who knows. I've had anough recon failures this year to last a lifetime. Half of the time my failures are unknown recon errors, thus, smart groups are my current answer.

Like

Posted: by grahamfw

We utilize a daily script and it would be helpful to have it run until successful or at least somehow to be able to track failures.

Like

Posted: by pbenton

Seems like the biggest issue is with network/download related failures in my opinion. Would be extremely advantageous if the jamf binary was smart enough that if the failure was a result of network/download failures it would rerun at the next trigger. maybe even make this behaviour an option.

without this feature caching large installers via policies is nothing but infuriating. Complicated by cache files re-downloading even if they are already present. (I realize this has it's purpose) but repeating policies are out of the question.

Like

Posted: by atrivas

I would like to see this feature as well. Frequency should be "run until successful completion". This need's to be automated and I should not have to troll policy logs and flush failures. I don't want an email and then have to respond with more work. Automation is what we need.

Like

Posted: by PeterClarke

There does need to be some safeguard..

EG: If a Policy were to try installing something.. and this was already the 20th time it's tried \- and it's still failing..
Then it really is rather likely that something is genuinely wrong..

There's a difference here, between: "Wont install" on some particular machines
Vs "Won't install on ANY Machines"

For instance we somethings get policy failures due to "Machine does not meet requirements"
\- this is a different, expected type of failure.

Perhaps something like say: Three-Tries, then report Failure.. ?

Really we ideally want to know WHY a Policy is failing -- in as much detail as is available.
eg: Download persistently failed to complete... Computer has insufficient space available... (That's something that can be pre-trapped, by a smart list) Computer does not meet OS X version requirement.. Distribution server could not be contacted..

Too many machines trying to contact / download from a distribution server may attempt to exceed it's bandwidth..
and that could cause policy failure on some machines.
-- Though JAMF may have automatic connection throttling limits to restrain that ??

LARGE Packages require special handling. (e.g. install from mounted DMG)
Some types of Policy-triggers, can be problematic, when used with some packages.
\- In those cases a different trigger should be used.

In earlier versions of Casper some 'false-failures' would occur, where software was successfully installed, but would be reported as failing, due to an 'error' or other text in the output.
Later versions of Casper (Casper 9.x) changed that criteria.

A blanket "Keep Retrying Regardless" would be Incorrect..

It's important to identify and understand the underlying issue of why a policy failure is occurring.
-- and it's not always obvious..

Like

Posted: by mm2270

I would agree that simply asking the jamf binary to keep trying to run a policy blindlessly doesn't make sense. There are legit reasons why something is failing and so there would have to be some logic to it. Or, a simple flag to set the maximum number of retries before it finally stops trying. That would be acceptable in my opinion.
Think of it similar to package receipts, but instead have it be policy receipts, that capture the number of times it has attempted to run on that Mac. Or better yet, just have the JSS handle that since it already knows what ran (or attempted to run) on what, and stop re-running once it hits that maximum. This would only apply to "run once" policies of course.

The last thing I think anyone wants is to condemn the jamf binary to be some kind of digital Sisyphus trying over and over again even though it will never be able to do its task.

Like

Posted: by atrivas

I agree with PeterClarke & mm2270

Maybe not Retrying Regardless but a 3 strike rule. I've seen times where a device can not mount the distro point and that causes a failure. Once flushed it will complete successfully. Hence a second try or third try resolves the issue without having to flush failures. This will put a little buffer between chasing (simply did not mount properly) or a genuine issue that needs investigation.

Like

Posted: by Look

Personally I'd like retry time out option on each policy something like.
Retry failed deployments after: XXXXXX : HOURS/DAYS
Although a JAMF argument like FlushFailures would do it as well, then you could have it set to run on startup as more than likely it will take a reboot for a lot of the failed policies to be able to deploy successfully.

Like

Posted: by NightFlight

Just like to point out this is currently the most popular request, and it was proposed 3 years ago. Carrying out logic based on the exit code status of a child process has to be one of the first things any coder encounters when they learn how system calls work.

I just up-voted this today because I need to implement a once-only type policy, but failure may occur in many cases. I need to populate a blank field and creating a smart group on a blank quantity is not currently possible - another feature request which I have opened.

This is a minor change, but with a big workflow/workload impact for many admins.

Like

Posted: by pbenton

Totally agree with Chris.

Like

Posted: by dan.berman

Can we at least get an update to whether this is something that can be built? It's crazy that this hasn't been implemented yet.

Like

Posted: by NightFlight

They have the technology. ;-)

However simple on the surface, you do have to take into consideration what it might affect and deadlock conditions that may be generated by this sort of logic and what sort of call driver that would be for their support team. Implementation is never as simple as 'I want this', especially considering how many machines are in the scope.

On the flip side, I am a customer and I want this. I've thrown in all my cards with Casper, especially when I know I can code, distribute and maintain this sort of thing outside of Casper very easily. I am mostly only convinced of the usefulness of Casper as a tool to my IT team as a whole. If I were going it alone, I would just develop my own tools - but in terms of interface and ease of use... its hard to beat.

Like

Posted: by mking529

Our deployment is 90% laptop and it never fails that they close their laptops while a Flash or Java update is trying to run or spotty wifi prevents policy completion after hours. Clearing the errors out adds up. This would save me a good amount of time with just our inventory of ~1000 machines, can't imagine how awesome it would be for you guys with five digit inventory counts!

Like

Posted: by milesleacy

My concern is what happens for failures due to something other than a missing package or interrupted download?

This feature request seems to be begging for an infinite loop (original meaning - a bad thing, not an address).

Like

Posted: by _derOliver

I think as an Administrator, you should be able to estimate the possible effects of running a policy twice. This should be a alternative to "run once", not a replacement.

Like

Posted: by NightFlight

Posted: Yesterday at 2:33 AM by crispy I think as an Administrator, you should be able to estimate the possible effects of running a policy twice. This should be a alternative to "run once", not a replacement.

Er yes. However, who here has not triggered unexpected results? Things tend to cascade when you make changes. The solution is obvious. MAX_COUNT limiter.

Like

Posted: by mm2270

So, I think most of us here are in agreement that simply having any policy run over and over in an endless loop is not a good idea, so I don't think anyone is really requesting that here (maybe the OP was, but the request wasn't presented that way, so I don't think so)
But, there should be some level of configurability with this. Right now, the way that the Casper Suite handles once per <device> policies is just too black and white. If it fails and it was set to once per, it just stops. Not even one retry. I think we're just asking for at least a couple of attempts before failing into the "failed" bucket, which helps weed out the "just bad timing" failures versus the "real problem" failures. Too many of us are babysitting policies to ensure they end up running on all targeted devices, which kind of defeats some of the purpose of policies in the first place. They are supposed to be things that save us time, by configuring it, letting it fly and then only fixing the problem systems later. Instead we are needing to look through policy logs to determine why it failed per device and decide if there was really an issue or if it should be attempted again on that same device (flush policy log)

If instead, I could only see "Failed" for ones that failed after 3 consecutive tries, that would save me a bit of time since I wouldn't even need to look at the policy logs (except to determine how to resolve that client system) I would know immediately there must be something wrong with it, instead of it failing just because the user closed their lid or they were in a bad location and the request timed out or whatever. That's really all that's being asked here.
As has been mentioned, the only real workaround right now is to configure policies to run on an Ongoing basis and use Smart Groups designed to detect if the policy ran or not, so devices fall into or out of scope. While this is OK, unfortunately, it isn't always possible or reasonable. Some policies do things that can be difficult to detect later with a Smart Group, and I don't want to have to spend all my time trying to craft Extension Attributes and/or Smart Group criteria just to work around a policy limitation. EAs in particular can be wasteful if their only purpose is to detect if something happened or not on the target device for use with a single policy. It eats up resources at recon time and space in the db.

Like

Posted: by milesleacy

The existing tools allow administrators to deploy software and settings as needed. One may need to "think different" to get there (couldn't resist). The way I approach policies is as follows...

  1. Define the desired state for the computers in question. For example: Computers in the Art department must have Photoshop installed.
  2. Use Smart Groups (and extension attributes, if necessary) to identify computers that are not in the desired state. In this example: Department is Art and Software Title does not have Photoshop
  3. Create a policy that is triggered by the Recurring Check-in with an Ongoing Execution Frequency, scoped to the Smart Group described above.

In this way, a computer in the art department that doesn't have Photoshop will have it installed. The policy will never run again on that computer until and unless Photoshop goes missing.

As I see it, "Install Photoshop on this set of computers" is an inferior process to "define which computers need Photoshop and make sure it's present".

Like

Posted: by NightFlight

@milesleacy See post above by mm2270

Everyone, I think... is aware of smart group handling an on-going condition. I for one would like to stop that sort of senseless beating against the wall. Given that on-error a smart group will keep trying indefinitely - which puts a load on the repositories. That puts us back to babysitting policies.

I think we want proper error handling.

Like

Posted: by milesleacy

@NightFlight I suppose you and @mm2270 think differently about computer management than I do.

What you see as "senseless beating against the wall," I see as the correct way to alter a computer. That is...

  1. Identify computers in the undesired state.
  2. Put them into the desired state.

If a computer fails to complete #2 successfully, then either the computer or my process is broken and I need to adjust my approach. If the failure will happen sometimes and not others, which is the scenario that would benefit from a "try x times" model, then my process is still flawed - I have failed to account for all of the variables that may affect the process. "Try x times" seems to me to be a way of saying "I can't be bothered with figuring out why my process sometimes fails, so I'm just going to keep," to borrow your phrase, "senseless beating against the wall [sic]."

Isn't "proper error handling" reporting the fact that an error occurred, along with as much detail as possible about what caused the error? Doesn't the Casper Suite do that already?

Like

Posted: by mking529

Personally, I think good policy testing would negate the risk of a policy failing numerous times due to a package or configuration issue. Maybe I'm just too careful, but when we're talking about a policy being pushed out to an entirely deployment or a large part of it, I always find the time to execute the policy on a test machine to make sure the right things happen. There was one time I didn't, and a package gone awry dumped a bunch of random junk on the root of the HD. Never again!

SMART groups are nice but to me that feels like working around the missing feature.

Like

Posted: by milesleacy

@mking529 ^^^ That too.

Like

Posted: by NightFlight

No, trying X times is a better way to do things since no installation across thousands of machines works seamlessly. Read from the start of the thread.

Every time I think of every contingency - someone invents a new one. ie, you can't outthink stupid.

Like

Posted: by Look

@milesleacy while checking for a desired state and deploying if it doesn't exist is lovely in theory (and in fact I use it fairly often where appropriate), sometimes in practice it often results in exactly the same thing or it becomes very complicated to implement, or even has a worse result (i.e. pretty much infinite looping).
A classic example is if you want to update the version of an existing app.
If you detect for the app it already exists.
If you detect for a specific version you downgrade any already updated version, again and again and again every time the user or machine updates it.
If you want to do a version comparison you then have some quite complicated scripting ahead of you to create the extension attributes just so you can that comparison.
Then if your policy has more than one package and only some of them fail i.e.the user pulled the laptop halfway through, how do you detect that.
Sometimes I'd rather it just tried once a day for 3 days before giving up... Or on any other optional tries and schedules I could easily configure in the policy, it's simple, it vastly increases the chances of all machines succeeding, its not really adding significant load as it's only one extra run per day on a small fraction of the fleet, eventually it does give up and the fraction of a fraction of machines left you know have a real issue and you send a tech out.

Like

Posted: by MattyB

+1 !

Like

Posted: by nigelg

This would be awesome.

Like

Posted: by bbot

+!

Like

Posted: by donmontalvo

We're having a deployment issue where we'd benefit from a specific failed policy re-running again, if it fails the first time. I guess the trick would be for the jamf binary to be able to know if a policy failed before any changes was made to the computer or not...else re-starting a failed policy might not be a good thing. Fingers crossed.

Like

Posted: by galo

+1

Like

Posted: by wakco

I was reading this thread again, and I'm realising what is needed is for jamf Pro to have a soft failure definition. i.e. failed downloads, server too busy/unavailable would be a soft failure requiring a try again later sensibility for policies set to things like once per computer. Most other errors will then count as a hard failure and then be treated by once per computer policies as they are now, policy has been executed.

Like

Posted: by bkp

+∞

Like

Posted: by NoahRJ

+∞+1

Like

Posted: by Sonic84

any update?

Like

Posted: by drventure

2018 is the year guys

Like

Posted: by KSchroeder

over 5 1/2 years seems like a reasonable period to wait for a feature that every other Systems Management tool I've ever used has had for years...maybe we do need to reinvestigate using SCCM or Symantec for Mac management!

Like

Posted: by signetmac

remove_from_scope() {
  # Solves the problem of "How do I run a policy at a continuous interval until first successful completion?"
  # This function writes the epoch date of script's SUCCESSFUL execution to an ext attrib on JSS defined as an
  # Integer value. If you define a Smart Group whose members are computers with a value higher than the epoch 
  # of the moment you enable a policy, then you can exclude members of this group from a policy's scope, such
  # that the policy will continue to run at whatever frequency until successful, and then drop out of scope.

  # Globals are in ALL_CAPS and need to be defined either in this function or in the script's globals.
  epoch=$(date +%s)
  udid=$(system_profiler SPHardwareDataType \
        | grep UUID \ 
        | awk '{print $3}')

  curl -k -s -X "PUT" "$JSSURL/JSSResource/computers/udid/$udid/subset/extension_attributes" \
    -H "Content-Type: application/xml" \
    -H "Authorization: $API_AUTH" \
    -H "Accept: application/xml" \
    -d "<computer><extension_attributes><extension_attribute><id>$EPOCH_EXT_ATTRIB_ID</id><name>$EPOCH_EXT_ATTRIB_NAME</name><type>String</type><value>$epoch</value></extension_attribute></extension_attributes></computer>" \
    & > /dev/null 2>&1
}
Like

Posted: by nathan.perkins

seriously, this is almost 7 years old.

what a joke

Like

Posted: by diradmin

UNDER REVIEW

Like

Posted: by landon_Starr

Maybe we'll see this in Jamf v11.0 :p

Like