10.25.1 Changes?

[llitz123]

We just updated to 10.25.1 and I noticed some changes. There are some discussions about the changes I have found yet I can't find any deep dives into the features such as use-cases and exactly how the features work.
Is this how all these are supposed to look?

What would I use retrying for - should I just use retry for all my policies? And it looks like I have to recreate any policies I need to use retry?

I use the JAMF deferral for updates in my environment and come in every week and push out the end deferral so it doesnt force all our clients to update during business hours...
I see there are new deferral options yet can't find exactly how they work...

I read there are some limitations such as if the duration option is used where it can cause issues with weekends or vacations forcing users to update....
Any help is greatly appreciated.

[sdagley]

@llitz123 Looks like you need to flush your browser cache to get those display labels to read correctly. Look back through the release notes for details on the functionality.

[llitz123]

Clearing the cache for sure cleared up the GUI issues. Thanks @sdagley In case anyone else needs them heres the retry info.
I still don't know use-case. Do I enable it for all policies that I can? It seems like it would be a good idea. Why wouldn't I?
Here is the deferral info.
And for deferral how are people using it? Like I said I read about some issues - are there workarounds or do I still have to manually touch the deferral every week?
Thanks

[mschroder]

I would have a use case for retries, but it requires that retries are made possible for policies that have an execution frequency of 'Once per day'. We make software installations available in the Self-Service. Installers are only shown to devices that do not yet have the app in question. Unfortunately the update of view of the available items is quite slow, and there is a bug that displays a wrong label when a policy was already run once, it that case the label is 'Run', instead of 'Install' or 'Remove'. So we see cases where users install an app, remove an app, install an app, remove an app, ... ad infinitum since they get confused by the slow view updates and the wrong labels. If we would set the execution frequency to 'once per day', the view would update a bit quicker in the sense that the icon of the policy just executed would disappear immediately after execution - but if something goes wrong the user would have to wait 24 hours before he can retry. This also confuses users. If we could allow a retry in case of errors that would be really cool and avoid a lot of confusion. I think I made a feature request for it.

[snowfox]

@llitz123 When deploying software in policies people typically used - at check-in, once per computer. If the application fails to install (as I have sometimes seen when deploying to multiple computers at the same time for example in a school computer lab) the server will simply move on to the next application in the list and not retry to install the app that failed. This new option - retry until successful ensures that failed app installs will retry x amount of times 'until successful' and then stop trying. It was a feature request people here on the forum were asking Jamf for.

I too had the problem with the super giant blocky text. Had to clear my browser cache and then it displayed correctly.

[llitz123]

Has anyone been using the JAMF deferral options for updates? If so, any helpful pointers on how best to implement? Any pitfalls?
Of course I will test yet if possible I'd like to hear other admin experiences...
Thanks for any further assistance...

[snowfox]

@llitz123 Funny you should ask. This is on my todo list to implement. I highly recomend you watch this patch management strategy video by Bill Smith at this years JNUC 2020:
Planning your patch management strategy JNUC 2020

I would also point you to this example from NC State University and why it's not a good idea to immediately force updates on end users without warning them first.
Jamf Pro Policy Cheat Sheet NC State University

Jamf has a technical whitepaper on patch management
Best Practice Workflows Managing macOS Updates

Jamf Blog Article - Not forcing updates, Kinda (this one had me in tears ^^ lol)
Not forcing updates kinda

Don't forget there are Jamf training videos in the training catalogue that cover deploying updates and upgrades.

My plan is to implement something like Bill suggests that tries to get the end user to do it themselves at a time that suits them via self service and then if they don't after repeated prompts and nudging, we'll do it for them.

[llitz123]

@snowfox That all makes good sense.
I was just curious how admins were managing their own Apple System updates. I'll take a look at the JNUC and other resources you suggest. Self service is great and we'll likely use it for moving from 10.14 to 10.15 soon yet with SS the "we'll do it for them" is a grey area of planning timing with staff as work can't be interrupted...