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.
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.
Hi @AJPinto
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)?
Hi @AJPinto
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)?
@AJPinto
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:
<key>AppleCurrentKeyboardLayoutInputSourceID</key>
And so it seems like this is the property list that is respopnsible for setting the keyboard input initially when you select the region for the computer on set-up. If you select United States for example, your computer is populated with the U.S. English keyboard input. The root library property list also uses this key to distinguish that input:
<key>AppleSelectedInputSources</key>
and then provides the key-value pairs for the input bundle for the given language (U.S. in my case).
The same bundles of key-value pairs that define the inputs in the user's HIToolbox.plist have a different primary key:
<key>AppleEnabledInputSources</key>
Then it lists all of the arrays of bundled key-value pairs indicating the various keyboard input languages in the same manner.
It is my guess that the difference in those keys keeps the changes on the user's personal choices separate from the default for users created on the computer after initial set up and regional selection.
I'm guessing that the root Library property list for this is not intended to be altered. I think I could pretty easily write in the additional inputs that I want, and, as you say, it's not SIP protected.
Alternatively if I chose to only package the /$USERNAME/Library property list, and I made the package via composer, how would I go about making it so the /$USERNAME folder can take any username? If I package it with my personal computer, the package would have /MY_PERSONAL_USERNAME/Library/Preferences/ etc...
Is there a way to package it so that it takes on whatever username, such as a variable $USERNAME?
Thanks!
