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.

Deferral Limit as "net %days" or "%n times"

Current Deferral Limit settings for policies are a fixed date/time. For ongoing policies this is a pain because, once the date passes, you either lose a deferral period entirely, or you have to extend the deferral date indefinitely, which means the policy may never be applied. I would like to be able to set a deferral limit of %n number of days since first deferral or %n number of times from first deferral, allowing a set grace period before policy enforcement regardless of specific calendar dates.

Posted: by beth.lindner

The problem posted in this Feature Request is about how we have some very important policies, such as software updates, that really need to be run on macOS devices in a timely fashion. However, our end users do important work so we want them to control when they're interrupted by computer reboots. Because the current implementation has a deferral date deadline, whenever users are offsite because of holidays or leave events, they come back to work and cannot be immediately productive because policies need to run based on the expired deferral date. This leads to end user irritation and ruins the Apple seamless experience. This can also lead to data loss and work productivity impacts. Please let me know if I have misunderstood anything from the comments.

A solution idea presented here is to make the deferral for a certain number of days after each time a Policy is triggered, so that this deferral is specific to a user/device instead of specific to the Policy. Thank you to everyone who is sharing workaround ideas in the comments!

Right now we are investigating how enhancements surrounding this end user experience may correlate to our current Jamf Pro initiatives. We don't have any features specifically planned for upcoming releases, but we are leaving this as Under Review because we are continuing to ideate on how we can help solve this problem. If we discover this does not map with any of our roadmap initiatives for Jamf Pro, we'll reevaluate the status at that time.

Comment
Order by:

Posted: by mm2270

In complete agreement with this. I was a bit disappointed to see how deferrals work in version 9 because setting a drop dead date for when the policy must run doesn't always work in our case. In fact I'd say they almost never work for us, so we won't really be able to make use of this feature as it is.
If I could vote this up more than once I would.

For now, we'll continue to use our custom scripted workarounds which allow us to get the above functionality.

Like

Posted: by MARL

With 35,000 Macs Users the way this is implemented in version 9 is completely useless. We have had to once again create our own workaround for this shortcoming. The way it is implemented now unfortunately shows not much thinking into large scale global deployments but rather smaller local ones.

Like

Posted: by Over9000

This is critical for us as well. I have to set a reminder in my calendar to update this date every so often.

Like

Posted: by chuck3000

I also agree that we need a way to set a policy to allow a user to run through Self Service first, for a defined period of time (x Days or by date x) and if it doesn't get run manually, it THEN gets installed automatically based on the policy trigger settings (startup, login, logout, recurring, etc.).

We currently have to run two simultaneous identical policies, one that allows self service, but ends by a specific date and the second which starts after the other policy's end date, but installs using the policy's trigger.

This wastes time and space and requires management and monitoring of multiple policies and smart groups.

Like

Posted: by SeanA

My company would benefit from this feature request.

@chuck3000 Regarding your two identical policies, why not create a single policy, start it off as Self Service, then at the end date, disable Self Service and enable the policy's trigger? Your policy would keep the same scope and logs for the both the Self Service and push versions of this policy. Or what am I missing here?

Like

Posted: by spraguga

I totally agree with all of you! I'm curious as to why this hasn't been implemented yet. I'm a developer and this should be very easy to update. Hopefully this is next on JAMFs list!

Like

Posted: by gachowski

Fishing for votes, I created the duplicate, this morning : )

https://jamfnation.jamfsoftware.com/featureRequest.html?id=3378

Like

Posted: by timbiddle

@mm2270 Would you mind sharing your custom scripts with us? (or me?) I'm interested in what your workaround is because I'm needing a similar solution. Thanks.

Like

Posted: by mm2270

@tbiddle-wiley So, before actually posting anything here or elsewhere, I'd encourage you to look through this older but very useful thread for examples on how some of us have accomplished adding "timers" or "deferral counters" to our scripts.
Its a long thread, but its one of the ones that really kickstarted a great discussion and subsequent postings of a number of very good custom scripts still in use out there. Hopefully that will get you in the right direction.

Like

Posted: by benducklow

It would be nice to have this feature 'built-in'. We currently use a custom workaround like some of the others stated in the discussions above, but it would be great to have seamless functionality within the product. We currently have a "start now" along with 1 hour increments with a maximum of 4 hours.

Like

Posted: by gachowski

Bumping up for votes : )

C

Like

Posted: by dmw3

+1 Bumping up for votes : )

Like

Posted: by ekkehard

Make it so!

Like

Posted: by infosecnoob

+1 so I don't need to update the policy date every week!

Like

Posted: by bpavlov

Could really use this. I don't make use of deferrals because a hard date is not very practical in most situations.

Like

Posted: by jason.bracy

Why has this not been implemented yet? Can JAMF please weigh in?

Like

Posted: by donmontalvo

We are coming up on a fairly large migration project, and this feature would be most welcome.

Imagine moving a client from an old JSS, to a new JSS, and having the user hit with a dozen of security patches, some that require the computer to reboot.

We really need Push With Deferral (or whatever its called) to offer Push With Deferral For N Days.

So the first time you respond to the prompt, you can pick 10 days, etc.

I'll open a ticket with JAMF to inquire on status of this feature request.

Thanks,
Don

Like

Posted: by bpavlov

With patch management features ramping up, this feature request becomes pretty important one would think. Giving people the ability to defer is critical so that people can do the updates on their own time. Yet this is still under review.

Like

Posted: by Taylor.Armstrong

Bump. Just posted a discussion regarding this without realizing there was already a FR on it. Fairly vital for our .org, now I'm looking for ways to come up with a work-around. I really need something that simply lets me run on a normal schedule (let's say every Monday night, and "allow deferral for 24 hours", without having to manually change the date every single week on the policy. Just trying to avoid interrupting my users any more than necessary.

Like

Posted: by gachowski

I asked for this before 9 was released and the answer was something like.....

9 would give them the new base at add this feature at a later date. They were very clear that they know it was needed and there was no easy way to add it even with the first versions of 9.

I am not worried, I expect it will get implemented when Jamf can : )

C

Like

Posted: by bpavlov

@gachowski You asked for it before version 9 was released and now they are close to releasing version 10 and you're not worried they will implement this?

Like

Posted: by gachowski

I am not even remotely concerned. In my dealing with many other "software vendors" Jamf is the gold standard and most other vendors fall seriously short.

The Jamf team are pros, Apple, MS, Adobe, .... are all bush league, Jamf has reset the standard and disrupted how software companies should be evaluated and measured.

I kinda of think that most of us forget how hard it is to do what Jamf does. The decisions and trade offs Jamf has to make are not easy. I know that they have some very very smart people making those decisions and doing the work.

I have complete confidence that they will get to all of our important feature requests when it's best for Jamf which in turn is best for the product and me.

C

Like

Posted: by daydreamer

@donmontalvo did you open that ticket after all? Is there any official word about it?

It'd be great if at least JAMF came up with an explanation as to why this is so difficult to introduce.

Like

Posted: by gkotlinski

Excellent! We definitely need this.

Like

Posted: by donmontalvo

@daydreamer a member of our team opened a ticket and was told to vote up the FR.

Like

Posted: by beth.lindner

Thanks to everyone posting on this Feature Request! Can we gather some use cases for clarity? I want to be sure the problems we are experiencing today with end users and policies are fully understood.

What is in the policies that we allow our end users to defer versus the policies we do not allow deferral for? With the example of an ongoing policy, do we want our users to be able to defer it indefinitely? Is this Feature Request more about offering the end user specific options that we can customize, such as allow end user to defer for 1 hour or 2 hours and at the expiration of that time immediately have the policy run? Thank you for helping us gather the workflows that are struggles today!

Like

Posted: by Over9000

@beth.lindner My use case is for a policy we have set to run Apple Software Updates. Certain Macs on our campus are running on an older version of an OS and we want to target these machines to have them updated but don't want to intrude if there are users actively working on them so we'd like to provide them the option to defer, up to a certain point similar to Windows Updates. We'd like to have them defer for a few hours, a day maybe but we don't want to have the user be prompted with an option of a specific random date in the future that i'd have to go into the policy to extend or manage which is how it is now. I'd like to say "allow x amount of deferrals" or have the option to allow them to defer each time with no amount of times they can defer.

I hope that helps and thanks for looking into this!

Like

Posted: by blinvisible

Current deferrals structure:

Deferral Limit Date/time at which to prohibit further deferral. The policy runs at this date/time if it has not run yet [MM] [DD] [YYYY] at [HH] [MM] [am/pm]

Let's say I create a policy that runs once per computer, and will force a reboot or cause other potential work disruption. I want to give people up to a month to defer it so they can a) have ample warning it's coming, and b) plan for a good time for the disruption to occur. But, I don't want people to defer indefinitely as it is important this policy gets run.

Using the current Deferral Limit settings, I set the deferral limit to one month into the future -- in this example, January 1 of 2017 at 12am. Computers that check in and execute this policy in between the policy creation date and the deferral date have no issue, and users can defer until the specified date.

Then: Happy New Year! It's now January 3rd, 2017. New computers that check in for the first time see there's this policy that has never been run, but it is now past the deferral limit date, so no deferral is allowed. Users are upset because they never got a chance to defer and their work is postponed or interrupted while the policy executes. Boss tells me I need to extend the deferral limit another month so productivity isn't impacted. Now everyone who hasn't yet run the policy can defer for another month. The same issue happens again the next month, and the next, and the next. My only choices at this point are to stop extending deferral, and force everyone to run it immediately, or to continue extending deferral indefinitely, which means the policy may never run at all.

My Feature request wants to change Deferral Limit from a hard calendar date to a value based on "number of times machine deferred" and/or "time interval allowed to defer" For example:

Deferral Limits Number of times to allow deferral. The policy will run if this number is exceeded. [integer]

or

Deferral Limits Amount of time to defer policy execution. The policy will run if this time is exceeded. [integer] [minutes/hours/days/weeks]

With something like that, I can define a deferral interval independent of hard calendar dates, and I don't have to choose between having no deferral at all or indefinitely expanding the deferral limit to accommodate new computers.

Like

Posted: by mm2270

Well stated @blimvisible This is the core issue. Its simply unrealistic to assume that all Macs in a given environment would be checking in and would get at least 1 deferral in (for the user) before the policy ends up being enforced. The way this was set up makes me think it was designed in a perfect world bubble, where every Mac is happily checking in on a regular basis. In the real world, especially in environments with 1000s or 10s of 1000s of Macs, sometimes scattered all over the globe, it just isn't going to happen. People take vacations, go out on medical leave, take maternal/paternal leave, or sometimes are out of the office traveling on business (and you may not have an externally facing JSS) And then there are some Macs that lose their connection to the JSS (hardware repairs, users messing with the system, etc) plus new Macs that may get imaged or integrated into the JSS that are going to get hit immediately with an enforcement.
This is simply how things are. Having a drop dead date when it must execute doesn't align with our reality. It really needs to be based on a set number of deferrals. Or at least that needs to be an option in addition to what we have now.

I know JAMF has asked for more specifics on which workflows we may use this on, but to me that's kind of beside the point, since there could be many different reasons and examples for needing this. Your example of the forced reboot is a good one though, and I imagine a lot of other people are facing the same issue. We want to enforce, but not piss off our users. I hope JAMF listens and comes up with a solution here.

Like

Posted: by gachowski

Thanks for asking Beth !!!

My use case is software update too...

We have an ongoing policy that never stops running forcing software updated every 7 days. I don't think I can use the current defer rules as it would stop the policy from running the next 7 days. I could do it now if I flushed the logs every time there was an Apple update but that is really automation. :)

We would like the users to be able to defer the policy X number of hours or minutes. However what would be really cool would be for me to able to set a limit of max defer time number of hours or minutes and then let the user enter how long they need the defer up to my max set time.

They would get a pop up message say "hey run this policy" with two check boxes 1. run now 2. defer. When they selected defer it would give the a box to enter the number of X number of hours or minutes that they need to defer.

The policy would run at my max defer no matter what : )

Thanks

C

Like

Posted: by dmw3

As others have stated, not all the Macs are online at one time, we could have any number away for extended periods at research sites, if the deferral limit is reached while these are away, when the reattach to the network the policy would activate sometimes before vital research data is transferred to servers.
Also policies at deferral limit may actually activate during presentations leaving a lecturer rather red faced.

My preference would be deferral for a set number of times with a set time period between deferrals. We are actually using a script with this functionality for software updates, but would love to see this functionality as part of JAMF Pro core.

Discussion of the deferral script:
https://www.jamf.com/jamf-nation/discussions/5404/jamfhelper-software-update-trigger

Like

Posted: by donmontalvo

Hi Beth,

In our case....

If I'm a user who just came back from vacation, I want be able to defer a policy by N days. What happens instead is I may have one deferral option, or worse no option at all because I missed the deadline.

If I'm on a deadline, and I can't afford a reboot, I want to defer a policy by N days. What happens instead is im disrupted and I have to endure a reboot at the worst possible time.

In either case, if there is a deadline and I can't defer by N days, I'm disrupted, and I will not only escalate, but I will blame Casper for my missed deadline.

Multiply by 10,000 Mac users all over the world, and you get an idea why this is important...and urgent. :)

HTH,
Don

Like

Posted: by jason.bracy

Nothing really to add. My use case is similar to others. Specifically we have a Software Update policy that runs daily. If Updates require a restart I allow deferral until Friday at 6pm EST. On Monday Morning I reschedule the deferral for the following Friday. Obviously this adds a lot of annoyance if I forget to update the limit, but also means that if an update comes out when the user is offline, and depending on their work hours, they could theoretically never apply the update because they keep being offered a later deferral time.

Like

Posted: by CasperSally

I'm really hoping something like this is coming with patch policies.

Like

Posted: by daydreamer

Providing my take of the same issues others beautifully covered:

Requirements:
a. We want users to apply software updates
b. We want to allow for reasonable flexibility as to when users choose to install said updates
c. We want a. and b. to be a permanent, ongoing policy

Given the above, we should be able configure a policy once, enforcing the following condition:
"If a software update exists, notify the user but allow them to defer it for an X amount of times"
Rinse, repeat for subsequent software updates.

Right now we only have the following ability:

"If software updates exist, notify the user and allow them to defer it up to a certain date", which means we have to revisit the policy periodically and push back the date in the future, thereby risking the following:
1. Annoying users (see examples voiced by others as to why)
2. Allowing for too much flexibility (in order to avoid 1.), and either relaxing dangerously the company security policy in the process, or even cancelling it altogether.

Like

Posted: by pcrandom

I think many people have provided good use cases. My request is a little different, and I don't know if it'd be worth creating another Feature Request to track it, but I'd like to decouple the deferral period from the deferral increment. While it might be nice to customize the 1 hour, 2 hours, 4 hours, 1 day increments, I don't need to micromanage it to that extent. However, I'd prefer the prompt not to offer the end of the deferral period as the maximum option. If I want a policy to run for 3 months or a year, I don't want someone to defer for that long (on purpose or accidentally). If there was a separate deferral increment cap, or something so that someone could only defer for 4 hours or 1 day or a week max, even if the deferral period doesn't end for months, that would be great!

Like

Posted: by jason.bracy

@pcrandom I agree 100% Having a maximum deferral period regardless of the end date would be exactly what I want as well.

Like

Posted: by bpavlov

Bumpity bump. How great would it be to have this feature?

Like

Posted: by llitz123

Needed feature.

Like

Posted: by chris.kemp

Our use case is similar as well. When we implement deferral counters it's usually for the same reasons, to allow the user to choose when a more intrusive policy must be run. Usually this is something like Symantec Endpoint Protection, which requires a reboot (or sometimes two, for removal & reinstallation). We script a counter, as well as a pop-up window that the user must acknowledge - usually this has two buttons, Install and Defer. Install triggers the policy, Defer increments the counter and exits the policy. Once you've used up your deferrals, then the Defer button is removed and you must proceed - but we keep the window so the user has a moment to save & quit their work.

I can appreciate that this is a significant addition - however, it does seem that most of us need a version of what I stated above.

Like

Posted: by cjatsbm

+1 ...

Like

Posted: by bpavlov

With JSS v10 out, it would be nice to see this implemented.

Like

Posted: by sw_g

+500. For a great example of how to do this right, take a look at the approach in PowerShell Application Deployment Toolkit.

Like

Posted: by mbezzo

Yes, was REALLY REALLY hoping to see this in v10. Can we have it now please? :)

Like

Posted: by scheb

Can't believe this didn't make it into v10?

Like

Posted: by unknown_err

I'm pretty sure out of every open feature request, this one would be the most useful. And I mean fully implemented and usable, not just a toe dipped in the water like the Patch Policies deferral feature.

Like

Posted: by gforsyth

This is a really big need and is an ask from our upper management. Any movement on this?

Adoption would be immediate across the board.

Like

Posted: by sjuanes

Was just looking at this myself, searched the forums, and found out this isn't a feature. Would like to see this implemented soon!

Like

Posted: by mmd2468

There are many use cases for this. This feature would greatly help us at our organization.

Like

Posted: by damienbarrett

Why doesn't this exist yet? I'm tired of using a script + jamfhelper to invoke undimissable dialogue boxes to force my users to run their updates. This should be built into the deferral mechanism already in Jamf.

Like

Posted: by howie_isaacks

This is "under review", but for how long? This was requested over four and a half years ago, and it's not acceptable that this has gone unresolved this long. In fact, this should have been implemented from the beginning.

Like

Posted: by benducklow

@howie_isaacks - I've brought up this concern in my last business review interaction with Jamf. Its crazy to think a lot of these feature requests are still out here... (even the voting feature is not perfect and ideal in my mind, but thats just opinion). I relayed a list of feature requests to them that are critical for our continued success with the product... a lot of those are old just like this one if not older!

Like

Posted: by howie_isaacks

@benducklow I don't want to be too much of a pest on this, but I think I'm going to nag Jamf until this is implemented. Their developers do great work, and there will inevitably be flaws in the software. That's just part of the software business. This is a really obvious thing that Jamf should have built in from the start. I have better things to do with my time than login and make a change on a policy once every week or so, and I really would like to shorten the deferral time to only a couple of days. That would require me to adjust the policy about every day. That's not reasonable.

Like

Posted: by howie_isaacks

@MARL What's your workaround for this? Because I don't want deferral times to be more than 2 days, I will need to login to Jamf Pro on two servers and adjust the policy daily. As we add more Jamf Pro servers for new clients we bring on, this will become a very annoying occupation. If you have a workaround, I would love to know what you did.

Like

Posted: by chris.kemp

@howie_isaacks I assume you're talking a 2-day deferral limit from first deferral?

You could implement something similar to what we do, which is (x) number of deferrals logged into either a file on the client or an EA. Rather than using a simple X+1 counter, though, you could run a date command on the client, convert it into epoch time, and set that number in your file/EA. Then, upon checkin, you run date again, convert it, and do the math. If the result is greater than 172800 (2 days expressed in seconds), no more deferral.

Some relevant snippets (not complete logic, but these were the important bits I've leveraged for stuff like this):

# set the limit
timeLimit=172800

# Get current date
epochDate=`date -j +%s`

# read in the deferral date - if it's a text file:
deferDate=`cat /my/tmp/file.txt`
# an EA would require a curl, of course...

# Do the math
timeCheck=`echo "$deferDate-$epochDate" | bc`

# test 
if [ $timeCheck -lt $timeLimit ]; then
    do stuff...
fi
Like

Posted: by howie_isaacks

Thanks @chris.kemp . I will give this a try.

Like

Posted: by CasperSally

Please also improve user interaction and restart options. It's really needed inconjunction with patch. Munki has had these options for 5+ years.

https://www.jamf.com/jamf-nation/feature-requests/7190/better-options-for-user-interaction-and-deferral-for-patch-and-all-policies

Like

Posted: by blinvisible

It's been pretty clear that Jamf's focus for the last several years -- aside from keeping up with Apple's rapid pace of changes -- has been on increasing its customer base through things like its ServiceNow and Microsoft Intune integrations, rather than enhancing existing product features for current customers. @damienbarrett @CasperSally @howie_isaacks @benducklow

Like

Posted: by howie_isaacks

@blinvisible I don't care about ServiceNow or Intune. I just rescued a client from a poorly implemented and maintained Intune deployment. I have no interest in ever working with Intune again.

Like

Posted: by ibmbancointer

One more vote for this feature!!!

Like

Posted: by mm2270

I'm glad I'm using a custom patch management process that gives me this functionality. Because waiting on Jamf to do this, I will apparently be old and gray. I really don't know why this hasn't been done yet. It can't be THAT hard to do!

Like

Posted: by richardpianka

Lending my voice to this too...as a new Jamf user, pretty surprised this functionality doesn't exist.

Like

Posted: by gachowski

@blinvisible

Just not even close to true, you are just wrong. Also it's not cool to attack Jamf for an FR that can be implement with multiple workarounds or different approaches. ( just one of the reasons Jamf Pro is so great!)

As a long time customer and the 7th person to post in this this thread(in 2015,) I am beyond happy that ServiceNow and Microsoft Intune integrations were moved ahead of this FR.

The increased user productivity with Intune/Condition Access is/will be the 2nd biggest improvement that we have had in the 10+ years of managing mac's in our environment. I am sure once everyone who is using O365 understands what Condition Access brings to the table they will drive/push to start enabling it. Also it's an easy guess that this is just the 1st step in a Jamf / Microsoft long term working relationship that will bring befits that nobody can see right now.

C

PS While do I understand how this impacts our user, through education and communication our user base isn't really bent out of shape anymore about this. As I think about more and more, now I just it's just out of dated thinking from windows land. Sure our user base isn't happy that their machine get rebooted once in awhile but everyone understands that security is 1st. In this day and age it could even be argued that even hours delay in a security update is not acceptable. I would guess that there are many orgs that don't allow any deferrals. Why allow unsecure devices in your environment!

Like

Posted: by Taylor.Armstrong

@gachowski . Since "blinvisible" has posted multiple times, you might want to specify WHICH thing you're saying isn't close to true and wrong.

I can say that from my perspective (a highly security-sensitive environment), the fact that this FR has still not been fulfilled nearly 5 years after it was created is... well.... basically ludicrous. I honestly do NOT care right now about Intune (happy it is there, but an absolute non-factor for me).. but this is a glaring omission. With 400+ supporting votes on the FR, obviously many others feel the same. Nothing about this is "out-dated thinking from windows land"... not every update I push is security-related. Sometimes apps update with feature updates or bug fixes too... and I'd really LIKE to be able to use deferrals, but in the current implementation they're basically useless to me. Despite being a security-minded organization, security is NOT "1st"... our mission is 1st, and my job is to ensure that that mission is carried out in the most secure way possible, while impacting productivity as little as I can.

Like

Posted: by howie_isaacks

I can't believe that this is still "under review". Clearly this isn't a priority at Jamf, and we just discovered a couple of months ago that if a user does not do anything with the software update notification that pops up when the policy runs, the Mac stops checking in until the user selects an option. That is a HUGE problem.

Like

Posted: by scottb

Well, things like this and the rapid development at VMWare for AirWatch mean Jamf is going to struggle keeping clients.
I've asked Jamf to look outside of the walls and see competitors on their heels. My big fear is that while these new partnerships might be great for some, basic needs of the many are left to wither. Not being a drama queen here, this is my reality and I hope Jamf take seriously these requests before we're looking elsewhere.

Like

Posted: by howie_isaacks

@scottb You're not being a "drama queen" at all. We just got notification of a price increase. The way Jamf explained it was to reiterate their zero day support for Apple's OS's, and their increased investment to address our evolving needs. Great. We have a need for this glaring issue to be resolved, and if Jamf doesn't fix this and other issues soon, we may have to start looking at Jamf's competitors more closely. The way that software update deferrals are setup currently is very dumb. This feature should not have been implemented the way it is in the first place. It's made worse by the fact that this feature request is now over 5 years old. I just opened a support request to get help with finding some kind of workaround because I cannot even use this policy right now due to the problem with users not acknowledging the prompts which stops all check-ins from happening as long as that alert window is on the screen without acknowlegement.

Like

Posted: by prl

Why not enforce native auto-updates in OS and third-party apps in 2019 and walk away? Alternatively, all of it can be scripted and run from a LaunchDaemon on custom intervals to auto install new versions of software as well, direct to the client from the source no Jamf check-in required. I learned about it in Jamf certification course - haven't had to use it yet. creating your own launch daemons and install scripts should be required macadmin skills for security conscious orgs as I've never known a vendor to meet 100% of needs. in which case I develop my own solution, or use a third-party tool. Hopefully someone wiser and much more talented than I can develop a solution and add it to the collection here: https://marketplace.jamf.com or on git

Like

Posted: by howie_isaacks

@prl That's a good idea, but Jamf built this into Jamf Pro, and it should work properly. What you describe is the same as buying a car, and finding out that the left turn signal doesn't work. The manufacturer drags their feet fixing the problem, so you decide to just install your own custom turn signal or just start using a hand signal for left turns. You get the same results. I would not stand for that myself. I would demand that they fix their faulty product. We pay thousands of dollars a year for Jamf Pro, and I have a right to demand that they make the necessary changes to make the product work right. I love creating custom solutions using Jamf Pro, but I only do that when there is no built in solution.

Like

Posted: by daydreamer

@beth.lindner Thank you for expanding on JAMF's thought process around this. I feel that there are a few important components to the problem which need to be pointed out, which were not touched upon:

  • This problem is not so much experienced, or visible, by the end user, rather than the JAMF Pro administrator:

By not having this FR implemented, JAMF Pro administrators are forced to revisit the policy periodically to make sure the deferral date is pushed back to the future. End users, do not have visibility as to how the deferral policy is really implemented. To clarify by providing a worst case example in both situations, users might end up being frustrated either because the deferral date is set in the past, or (assuming this FR was implemented) because their grace period expired sooner than they would have liked to. In both cases they are forced to an unpleasant (but ultimately necessary) disruption of their productivity. After all, not having a patched OS/software will sooner or later disrupt their productivity anyway.

In that sense, implementing this FR would not worsen their experience, which otherwise is, justifiably, a critical concern. What this FR clearly does though is saving precious time for JAMF Pro administrators from having to revisit the policy over and over again.

  • Implementing this FR can (and imo should) be implemented as an additional option; not necessarily replacing the existing deferral method. That way, enterprises are provided with a choice as to what is best for their own end users, administrators and in line with organization policies.

In light of the two points above, I think the 476 upvoters (at the time of this post) would really appreciate prioritizing this FR for an imminent Jamf Pro release.

Thank you kindly for engaging!

Like

Posted: by entrata

Another upvote for this feature.

Please Jamf!!!

Take a look at this. It is a much needed feature in many environments as stated by others on this thread. I would give a use case but I think more than enough that are similar to my situation have already been posted.

Like

Posted: by scottb

@prl - developing launchdaemons and other custom stuff is fun, but not all of us can do this in all situations.
I'm not saying we shouldn't learn, but as said above, we are paying for a service that comes up short in some areas, and this one has been dangling for years, with lots and lots of votes.

If you offer up a feature, it should be useful in the scope of the offering. Obviously, this one comes up short. Why not just fix it?
We're paying for it - and it's not getting cheaper. OTOH, other solutions are cheaper and catching up.

Like

Posted: by scottlep

If I could upvote this FR another 482 times I would. Jamf needs this! We are an MSP and we just did a demo with a Jamf competitor....starts with the letter A. They have this deferral method and it is one of the few features in their product that made me say "I wish Jamf had this".

Like

Posted: by mm2270

There's been a lot of activity on this feature request thread lately, which is good to see. Since this came up to the front again, I decided to do a little research in the hopes of spurring Jamf to take this one a bit more seriously. Here are some interesting statistics that I found. I can't guarantee everything I'm saying is 100% accurate, but I believe it's right.

  • This Feature Request currently holds the # 12 spot in the most popular ranking of Feature Requests. This is no small feat! Considering I came up with a rough estimate of around 6000 feature requests in all, being in the top dozen means this is something really wanted by the Jamf admin community!
  • More interestingly, out of the top 12 requests, this request remains the only one not implemented that has a direct impact on the end clients we manage. All other requests in that top dozen not yet implemented are primarily things that WE as admins want to see happen to make OUR lives easier, but our end users will never know the difference either way.
  • Many of the implemented requests in that top 12 were items that had at least some or full impact on the end clients' experience.

Given the 2nd and 3rd points, I'm having a hard time understanding why Jamf isn't putting more effort into this. This request has an impact on the end users. Full stop.
Where I was up until very recently, the one thing I could tell you is that, while the Mac users I managed never knew the specifics of how Jamf/Casper worked, they sure as heck knew it was Jamf managing their Macs. And when things didn't work well or the UI went awry, they were at times quick to blame the product (or me sometimes, justified or not) The point is, I thought Jamf was all about user experience, and making it the best it could be so that Mac clients would love being managed by their product. Word of mouth of good experiences counts. This begs the question of why hasn't Jamf worked on improving this deferral experience? This of course has a big impact on Jamf admins too, but it has a HUGE impact on the hundreds or thousands of Mac clients we manage! Having a poor deferral experience that ends up forcing them to restart and interrupt their work because they happened to be out of the office for a week can leave a terrible taste in their mouth. This is akin to leaving a bad experience in Self Service, and Jamf has been quick to try to make improvements to that application, so this should get the same billing in my opinion.

Please Jamf, work on making this happen! As it stands, this feature is something many of just can't use because we can't trust it not to wreak havoc on our clients and piss them off.

Like

Posted: by scottb

@mm2270 Spot on. And I can state that a competing product is doing MUCH better in this area, not to mention catching up overall.
I'm going to be stuck when I try defending this going forward. I see 2019 being a difficult one for us and being pushed in another direction.
Thanks for showing the importance of this request in the scheme of so many here. I just hope it's not too late.

Like

Posted: by mm2270

@scottb said:

And I can state that a competing product is doing MUCH better in this area, not to mention catching up overall.

I know exactly which product you mean. I have needed to look at it in the past, but always dismissed it because it had very clunky package pushing capabilities. That isn't the case anymore with recent updates, and integrating a well known software patching tool into theirs has upped their game in this area substantially. So, I hear you. I'm finding it harder as time goes on to confidently say that Jamf Pro is the best in the market. They still are in a way, but that may not last forever based on what I'm seeing out there, unless Jamf really takes things to the next level soon.

Like

Posted: by scottb

Like

Posted: by grahamrpugh

This is a feature we have declined from utilising, since the UX is bad. I'd be surprised if many people are using this feature. It's another poorly-implemented feature that's bloating Jamf Pro without being useful. Another one is the lack of "less than" / "greater than" options in Application version criteria.

It's unfortunate that there so many features in Jamf that the general consensus is "well, you could use the built-in method, but it doesn't work well, you're better off scripting it yourself." Jamf should at the very least aim to get rid of all features like this - only include something if it's the best way to do it.

Like

Posted: by bpavlov

@grahamrpugh I agree to some extent. I will say though that it's not fair to ask that Jamf get rid of the feature entirely. While you (and I) might not find it useful in its current form, there may be ways in which people are making use of it as it currently exists. And that may be enough to keep it around.

I do agree though that there are features could really use improvements.

Just out of curiosity, what are you referring to by this line: "Another one is the lack of "less than" / "greater than" options in Application version criteria." ?

Like

Posted: by scottb

@bpavlov - I would think they mean a line that allow for: Microsoft Word "version < 16.20" or Microsoft Word "version ≥ 16.1" etc.
I can see some situations where this would not work as some companies have odd versioning, but it would likely cover most.
Then again, I could be mis-reading the request...

Like

Posted: by prl

MAU on + macOS auto updates on go home early on Fridays!

Like

Posted: by willsmithcc

It's crazy to me that this hasn't been done yet. Absolutely crazy. Going on SIX YEARS under review?

Guys...

Like

Posted: by blinvisible

I've given up expecting or even hoping for this. I've nearly given up on Jamf entirely. We are actively considering alternative MDM solutions. "Zero day support" is meaningless if the product doesn't fulfill its intended purposes.

Like

Posted: by grahamrpugh

@bpavlov As described above, “Application version greater than 56.0”, “less than or equal to 3.0a”, etc.

Python has a module called LooseVersion that covers most versioning well - it’s used by Munki I believe, and I’ve used it successfully in several AutoPkg Processors - and it can’t be beyond the scripting engineers of Jamf to build this into the product.

I guess the problem at the moment is that they rely on MySQL syntax which has no equivalent logic. The Patch Reporting mechanism is designed to do this, but requires the huge and normally unnecessary additional overhead of creating a web server and prepopulating it with JSON lists of all versions of a particular application, in chronological order, so it can determine the relative position of versions in the list rather than use any interpretive logic. Why? Munki has successfully used the logic-based method forever, and it’s really the main reason why Munki is better at package deployment than Jamf.

“Jamf And” is all very well for edge case workflows, but not for core functionality that every user would benefit from.

Like

Posted: by tep

This is kind of a rhetorical musing here....As someone who has used Jamf for a while, I want to echo the sentiments in this thread. I think the worst thing Jamf can do is ignore the repeated requests their loyal customer base. The main reason for using their product, versus the myriad of free open source options, is ease and connivence. I appreciate the "Jamf and" campaign, and love the capabilities it allows, but if I'm scripting to amend the core functionality of the product, why not save the money go all open source?

Like

Posted: by RJH

C'mon JAMF dev crew (and account managers!!) - really need to get some attention and ACTION to these sorts of basic functionality Feature Requests. 6 years since first posted and no apparent action. VOTING UP.

Like

Posted: by jamlvs

Bump?

Like

Posted: by scottb

Well, we're all now well out of puberty and nothing. I'm actually embarrassed over this one and others that are so highly upvoted and yet spend years getting cobwebs.
My support landscape will be changing a lot EOY and going forward. Doesn't make me happy, but it's the reality now.

Like

Posted: by isaacnelson

We kind of have this in patch policies now (at lest the number of days to defer). Why can't we have it as an option on normal policies, too?

Like

Posted: by garybidwell

While I understand Jamf’s position not wanting to spoil or have a negative effect on user experience, it should be the choice of the customer on how this impacts there own user base.
After all, this feature request is just replicating normal operation in a Windows/SCCM environment that’s been tried & tested for many years

As for Patch Management in Jamf; that was introduced in Jamf 10 and has had no or little development in this area for over a year since it’s introduction, it still has its limitations to get around this.
(I’m still losing users data in MS office apps due to its patching mechanism)

This request is a up vote from me.

Like

Posted: by pete_c

Approaching six years. "Under Review" has lost all meaning.

Like