What happens if software vendor releases bad patch via Mac Apps? Is there a way to stop a bad patch if set to automatically patch devices that fall in the smart device? Users are receiving notifications that the app is ready to be applied, forcing the app to quit. We then found out that the update is breaking part of our environment. I have turned off the deploy button in Mac Apps for that app, but isn't the download already cached on the device and ready to deploy as soon as the application force quits? Any way to stop this?
Question
Can You Stop Bad Patch from Vendor via Jamf Mac Apps
+2
+17All Mac Apps are QC'd by JAMF.. so its odd one has gone rogue.. whats the App and whats the issue with the update?
+26The only issue I have seen is when a vendor (like google) released a 0-day patch that chrome self-installed, and confused Jamfs reporting seeing a version of Chrome that did not match what the patching definition was looking for as most current. When I opened a ticket on this, Jamf said it takes 24hrs to update their definitions for new application releases. In our case, the workflow to force quit the application was happening but there were no updates to install as a newer version was already installed and the package would just error out.
It is rare that this happens, but when we see it, we just disable the auto patching for a couple of days. This is also an issue for Patch Management, it takes time for definitions to update.
+20The only issue I have seen is when a vendor (like google) released a 0-day patch that chrome self-installed, and confused Jamfs reporting seeing a version of Chrome that did not match what the patching definition was looking for as most current. When I opened a ticket on this, Jamf said it takes 24hrs to update their definitions for new application releases. In our case, the workflow to force quit the application was happening but there were no updates to install as a newer version was already installed and the package would just error out.
It is rare that this happens, but when we see it, we just disable the auto patching for a couple of days. This is also an issue for Patch Management, it takes time for definitions to update.
From what I recall, there was a recent update to Jamf Mac Apps where you could test the patches (or use an older patch version) before it finally does a full deployment. I can't remember all the details, workflow, and setup.
+17From what I recall, there was a recent update to Jamf Mac Apps where you could test the patches (or use an older patch version) before it finally does a full deployment. I can't remember all the details, workflow, and setup.
exactly what we do for core apps / complex apps.
Live is scoped to the required smart group, a second is then scoped to a subset. Both are set for manual update. New version of Foo.app comes out.. Disable live. Enabled subset with auto install.
Once subset has updated without issue. Disable subset, enable live.
+20exactly what we do for core apps / complex apps.
Live is scoped to the required smart group, a second is then scoped to a subset. Both are set for manual update. New version of Foo.app comes out.. Disable live. Enabled subset with auto install.
Once subset has updated without issue. Disable subset, enable live.
I see. Is it still a manual process then? Where you toggle and have to watch out for newly released updates?
+17I see. Is it still a manual process then? Where you toggle and have to watch out for newly released updates?
All the JAMF Mac Apps are tracked via Patch Management, so we get a ping when the update is out.. Yes you have to click a toggle but.. its not much of an overhead.. compared to how it was.. You could set it up with a smart group of pilots that get the update automatically, but I'd rather check the release notes first. If its just some fluffy update thats not flagged as a CVE / Security update, I can ignore it and get back to.. other things .
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.