Custom Configuration Profile for Keyboard Inputs

[iamYaje]

Hello,

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.

Thanks kindly!

[AJPinto]

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. 

[iamYaje]

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)?

[iamYaje]

@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>

<string>com.apple.keylayout.US</string>

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!