![]() This means there is no guarantee it’ll complete when you need it. However it is possible that this might be missed if the device doesn’t have network/Internet access very shortly after boot. This is not a bad option, as devices can’t install an OS update without a reboot*. ![]() TL DR – Don’t do this Option 2: Have an Inventory submission at every start up ![]() The inventory submissions do collect a fair amount of data (again, this can vary depending on what Extension Attributes you have written) and so having these run so frequent will grow and bloat the database, causing performance and stability issues.Having this happen every 15 minutes would make for a poor experience for your users The inventory submissions are not hugely intensive (depending on what Extension Attributes you have written) but they will take up some extra resource as they run.This is considered a very bad practice for many reasons, including: So one solution would be to have all of your devices submit an inventory update on the recurring policy check-in – by default this is every 15 minutes. This isn’t great for many enterprises…but there are a few possible options to get around this: Option 1: Submit an Inventory on the recurring check-in So you could be waiting anything from almost 24 hours, to almost a week for this profiles to be deployed (depending on your configuration). Most Jamf Pro customers have their Jamf inventory submission (or “recons”) set to once per day, or once per week. These profiles could manage a variety of items including some to suppress and affect the user experience, and others that are required for security tools to operate. This meant the device would need to be updated / upgraded, then submit an inventory whenever the next trigger was hit before it received the profiles. Until very recently, Jamf Pro only used OS version data collected by their jamf agent for version comparison in smart groups. Rinse and repeat for any other OS-specific payloads. For example, to deploy a PrivacyPreferencesPolic圜ontrol payload to only macOS 10.14 or newer devices, I would set a target smart group that selected those devices. It seemed this was an issue with an easy answer: scope the deployment of OS-specific profiles to smart groups of devices that meet that OS. In this post, I’ll share a short script I used to achieve this with Jamf Pro. What was needed was something to flag and trigger the installs as soon as the device was updated. Mac Admins soon realised that if these settings were deployed on an OS that doesn’t support them, they’ll often not take affect if the device was updated until they were redeployed. Each of these had a minimum OS required for them to work. Over the years, Apple have released a number of new and helpful profile payloads such as PPPC, System Extensions and the like. Migrating macOS Devi… on Migrating macOS Devices from o…ĭazwallace on Moving devices from Adobe Shar… Richard Glaser on Changes to Docker Desktop for… Stephan Peterson on Submit Jamf inventory update o… Recommended workflow to deploy Adobe software with Jamf Proĭeploying Docker Des… on Changes to Docker Desktop for…. ![]() Submit Jamf inventory update on OS changes.Speaking at London Apple Admins for Beginners.Re-homing your Mac Admin – MacAD.UK 2023. ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |