JSON Schema Review Requested: Secondary Right-Click

Definitely remove “.plist” from the domain name. The plist file contains the domain name, but it’s not the domain name.

Otherwise, all else looks correct.

I deploy a script

# Finds current username and defines a variable

currentuser=`stat -f "%Su" /dev/console`

# Sets apple mouse to right click enable

su "$currentuser" -c "defaults write com.apple.AppleMultitouchMouse MouseButtonMode -string TwoButton"
su "$currentuser" -c "defaults write com.apple.driver.AppleBluetoothMultitouch.mouse MouseButtonMode -string TwoButton"

Thanks for giving it a look-over! I removed the .plist, redistributed, and tested it on my laptop at home (I'm not in the office with the other devices. It hasn't been successful, even after a restart.

Actually, I haven't been able to get any JSON Schema that I've tested to work. There doesn't seem to be any conflicting configurations in the build. Everything is scoped and verifiably installed, but the .plist remains unchanged.

As @dmccluskey just shared, `defaults` scripts have worked more effectively for me for changing user-level preferences. But.. it's a bit frustrating to me because I far prefer the concept of managing it with a configuration profile and JSON Schema so that it can be immediately deployed. 

Is it the case that some of these user-level System Settings preferences can't be configured with JSON schema? It's been a challenge to figure out what can and can't be done.

Thanks for sharing! So far these kinds of scripts are the only thing that has been successful for me in managing many user-level preferences (outside of making the .plist file a literal .pkg and delivering it with a policy). Did you ever try to configure this setting with a configuration profile or is that futile?

I didnt do it as a config profile plist so as to give the user choice to change it back, in case they are one of those weird people the like a one button mouse. 😀

Well aren't you kind 😜 - I struggle with the appeal of one-click too, but to each their own.

I can appreciate giving the user an option. Honestly for the mouse feature, deploying a script works just fine for our environment. So, thanks for providing your script.

There are other System Settings features we need to manage for Remote Desktop to work. One being the feature in Keyboard > Keyboard Shortcuts > Function Keys through which you can enable/disable needing to press the "fn" key along with the F keys ... Because we use some osascripts that deploy virtual keystrokes for various purposes via Remote Desktop, but to the best of my knowledge you can't simulate virtual key presses for low-level functions like `fn` and `eject` 🙊. So, I use a `defaults write` script to automate that change too. 

I haven't had any success controlling that or many other user-level settings with a configuration profile. It's frustrating because I don't know whether it's possible, or whether it's something I'm doing incorrectly.

FS Monitor will help find those files being altered when you make a change.

FSMonitor

Have you tried deploying the profile as User Level instead of Computer Level? Some preferences can't be applied at the computer level to work correctly. I haven't done anything with this, so I don't know if this is the reason, but I would try it if you haven't done so already.

@mm2270 I have not tested that because to my understanding that's useful for network accounts (AD, etc.) but not for standard user accounts (which is what our system is using at the moment). Please correct me if I'm wrong! Thanks.

@dmccluskey 

Thanks for sharing — I've been using Jamf Composer before/after Snapshots to gather info on file system changes. Does FSMonitor track file changes in real time? I could see the advantage to that. Any other reason you like to use it?

User Level profiles can work fine with local standard user accounts. However, only one local account per device can have the MDM capability assigned to it, whereas any number of directory based accounts, like cached AD mobile accounts, can have that capability assigned to them. If you plan it right, and your Macs are single user systems, meaning you aren't going to have multiple different users signing into them at various times, then it could work. But you would have to check if the user accounts you're targeting are set to be MDM capable. You can view this in the computer details in Jamf Pro.

If a test machine has the local account set this way, I would at least try it to see if it works. If it does, then you know that's the issue. If it doesn't, then I would suspect it may be one of those preferences that simply can't be applied via a config profile. Those do exist unfortunately.

Wow!! Thank you for clarifying that point. It's been a while since I looked into the feature for MDM Enabled user accounts since I've had the PreStage set up for some time now.

These devices have one admin account and one standard user account. The standard user account is the one I would want to have MDM capable.

One potential issue that I immediately see is that we will be periodically deleting and recreating this user account to ensure any cached user data is removed. The good thing is, in the PreStage I do not set up the admin account as MDM Enabled. I also have it set to skip account creation for the standard user account during Startup Assistant as I have that profile set to be created with policies. So, there should be room to enable the standard user. 

That means that neither account is set as MDM Capable. According the Jamf Admin Guide: MDM-Enabled Local User Accounts

you can use: 

To set the currently logged in user to MDM enabled.

I'll definitely give this a try. I'll have to test deleting and creating the account anew to see whether MDM Enabled persists. If not, I could add this command to the process for recreating the account.

I was mistaken. That command works only for 10.15.07 and earlier. In MacOS11 or later the computer must be completely unenrolled and then reenrolled with one of these two methods:

• Computers with a removable MDM profile—Execute the sudo jamf removeframework command. After the computer is unenrolled, you can re-enroll it using a PreStage enrollment or user-initiated enrollment.

• Computers with an unremovable MDM profile—Execute the sudo jamf removeframework command and then send the Remove MDM Profile remote command using Jamf Pro. After the computer is unenrolled, you can re-enroll it using a PreStage enrollment or user-initiated enrollment.

Given that we delete and recreate the account, this could be a challenge.