Our institution is using Jamf | Pro. One of the requirements for computers in our labs is that we ensure we have the same keyboard input options (with many different languages available as inputs) across all of our Macs, while maintaining the standard U.S. keyboard as the default input.
I understand there are many ways of producing the .mobileconfig files for delivering a custom payload as a configuration profile. I'm beginning to learn the options provided by iMazing profile editor, for example; however, I haven't found any configurations within it for managing keyboard inputs.
So, I used a test computer and made the keyboard input preferences on it that we want (via System Settings, Ventura). I then pulled the com.apple.HIToolBox.plist containing those preferences. If I were to attempt using that .plist as a method, I then need to get the file into the .mobileconfig format for Jamf | Pro's payload. I'm not quite sure how to go about this.
Jamf has documentation available online that covers using JSON Schema to customize applications and that might be the way to go. On the other hand, there is the iMazing Profile editor (among others), and the AppleConfigurator app (which is only for iOS to the best of my knowledge).
So, I'm reaching out to ask about what current practices are for custom configuration profiles, making a .mobileconfig out of a .plist, and also to see what recommendations this community might have on creating a custom configuration for keyboard inputs so that every Mac in our fleet always retains the same input options.
Not all preferences can be managed with a Configuration Profile. By design MDM's place configuration profiles in /Library/Managed Preferences, not all functions read preferences from that directory. You may want to try using JAMF Composer to package your plist, and deploy it to another device in the same directory (/Library/Preferences). This is technically not "managing" a setting as a user can change it right back, but its not SIP protected so its worth a shot.
You may need to bounce a service or reboot for the changes to take hold. If it works you could make an extension attribute to check for a value and reinstall the plist if it ever changes.
Thanks kindly for this response. I'll be honest that I did not comprehend your answer fully when I first received it, and have since have passed the Jamf 200 course and tried many ways to get this .plist to go through, that led me back to Jamf Nation to ask again. Well, I did manage to deploy the .plist that I wanted via a custom configuration profile, and finally found it using a snapshot via Composer. Wouldn't you know it, I finally found the /Library/Managed Preferences folder you told me about, and found that the .plist was indeed there. In this process, I also started to consider ways of packaging it with Jamf Composer to get it the location I want it in, and, lo-and-behold you had actually suggested this. I'm sure your messages were locked somewhere in my brain!
Long story short, I'm ready to try to deploy it via /Library/Preferences with a package. Would you suggest trying to do this via a Policy and maybe also include it in the PreStage Enrollment (provided it works in a test)?
I have read carefully through the root /Library/Preferences/HIToolbox.plist and I found that it has some significant keys that differer from the same .plist in the /$USERNAME/Library/Preferences/HIToolbox.plist.
Namely, it calls upon: