![]() 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… Submit Jamf inventory update on OS changesĭeploying Docker Des… on Changes to Docker Desktop for….Speaking at London Apple Admins for Beginners.Re-homing your Mac Admin – MacAD.UK 2023. ![]() Granted - I didn't document what security updates this had so your mileage may vary. Rebooted and logged in with the new user (which matched the old home directory name) and new password I set and was able to get to the files. I set the UID to the same as the account I removed - then pointed it to the existing home directory - the key here is that when you create the new account - the username of the account has to be identical to the home directory name. I then created a new account - and right-clicked on it to Advanced Options. I copied the UID of the user account - I then deleted their account and selected to KEEP HOME FOLDER AS-IS I still couldn't change the password under the recovery partition so as the last attempt - I logged into the local admin account. I had to issue a decrypt File Vault from Jamf. It's possible it could have been as simple as his note above - however, _
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |