Please confirm:
Problem Statement
When you deploy a management profile via an MDM the settings are written to /Library/Managed Preferences/ to whatever Apple key is specified or custom key created by the developer for their software (Screenshots above). And yes they are written in XML format
That said, there are definitely developers in the Macadmins community that have made apps that also can read settings deployed other places, usually those get deployed to the /Library/Preferences folder which is a common location to store settings and is not locked to only the MDM being able to deploy settings there.
If you're doing the latter you have quite a bit more flexibility in how you want to store your settings. Nudge is an open-source community app that is a good example of something that can read settings from an MDM profile, OR read them from a JSON file stored locally (technically, they've made the app flexible enough to also specify a configuration profile location hosted online as well).
Here's a couple of examples in their Wiki explaining the 'setup' portion:
MDM Profile:
https://github.com/macadmins/nudge/wiki/Getting-Started#configuration
JSON Support (MDM Profile takes precedence over this):
https://github.com/macadmins/nudge/wiki#json-support
Attached above is also a decent post from a forum where someone is working to build a method of deploying settings via MDM.
Honestly, since this is an extension for Chrome and Edge, and not necessarily a standalone app I don't know if there's any interaction that has to be considered. It seems like there's potentially some interaction with Chrome and Edge that may require consideration.
That said, as an example of something that will already force Check onto Edge and Chrome see this last attached .mobileconfig test file. The PayloadType key is what designates the name of the plist file that gets created in /library/managed preferences
Here's an example .mobileconfig file. For reference, I am deploying this as a Custom Profile within Kandji.
Example .mobileconfig file:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>PayloadContent</key>
<array>
<dict>
<key>ExtensionInstallForcelist</key>
<array>
<string>benimdeioplgkhanklclahllklceahbe</string>
</array>
<key>PayloadDisplayName</key>
<string>Google Chrome</string>
<key>PayloadIdentifier</key>
<string>com.google.Chrome.23E5DDCF-1EB2-4869-9510-5E47D6640A85</string>
<key>PayloadType</key>
<string>com.google.Chrome</string>
<key>PayloadUUID</key>
<string>23E5DDCF-1EB2-4869-9510-5E47D6640A85</string>
<key>PayloadVersion</key>
<integer>1</integer>
</dict>
<dict>
<key>ExtensionInstallForcelist</key>
<array>
<string>knepjpocdagponkonnbggpcnhnaikajg</string>
</array>
<key>PayloadDisplayName</key>
<string>Microsoft Edge</string>
<key>PayloadIdentifier</key>
<string>com.microsoft.Edge.DD4A940A-B216-4D5E-8B2C-1EF2CAFF7F38</string>
<key>PayloadType</key>
<string>com.microsoft.Edge</string>
<key>PayloadUUID</key>
<string>DD4A940A-B216-4D5E-8B2C-1EF2CAFF7F38</string>
<key>PayloadVersion</key>
<integer>1</integer>
</dict>
<dict>
<key>CheckCustomSettings</key>
<array>
<key>companyName</key>
<string>Contoso</string>
<key>productName</key>
<string>Check - Phishing Protection</string>
<key>supportEmail</key>
<string>help@contoso.com</string>
<key>supportUrl</key>
<string>mailTo:help@contoso.com</string>
<key>primaryColor</key>
<string>#0D498C</string>
<key>logoUrl</key>
<string>https://logo.url.com</string>
<key>enableCippReporting</key>
<integer>1</integer>
<key>cippServerUrl</key>
<string>https://cipp.contoso.com</string>
</array>
<key>PayloadDisplayName</key>
<string>Check by Cyberdrain</string>
<key>PayloadIdentifier</key>
<string>com.cyberdrain.check.BB4A940A-B216-4D5E-8B2C-1EC2CAFE7F38</string>
<key>PayloadType</key>
<string>com.cyberdrain.check</string>
<key>PayloadUUID</key>
<string>BB4A940A-B216-4D5E-8B2C-1EC2CAFE7F38</string>
<key>PayloadVersion</key>
<integer>1</integer>
</dict>
</array>
<key>PayloadDescription</key>
<string>This profile installs and enforces the 'Check' browser extension from CyberDrain on Google Chrome and Microsoft Edge web browsers.</string>
<key>PayloadDisplayName</key>
<string>Check CyberDrain</string>
<key>PayloadIdentifier</key>
<string>010D4Z7E-7F1A-4723-99CB-1826F8BAF4B5</string>
<key>PayloadOrganization</key>
<string>Enable Resource Group</string>
<key>PayloadScope</key>
<string>System</string>
<key>PayloadType</key>
<string>Configuration</string>
<key>PayloadUUID</key>
<string>010D4Z7E-7F1A-4723-99CB-1826F8BAF4B5</string>
<key>PayloadVersion</key>
<integer>1</integer>
<key>RemovalDate</key>
<date>2044-05-19T21:46:44Z</date>
<key>TargetDeviceType</key>
<integer>5</integer>
</dict>
</plist>
For another simpler example of a tool that was created that can a policy passed via MDM configuration profile there's a tool that's simply written in bash where they are just looking the dictionaries passed in the /Library/Managed Preferences/ of the file that's named based on the tool.
https://github.com/SecondSonConsulting/Baseline/blob/main/Baseline.sh
He's written it so that it will pull the expected filename from /library/managed preferences/ OR you can custom set the filepath of your custom config file.
Honestly though, something as simplye as JSON in /Library/Preferences or a plist file which in XML format in that same location is something that you could write your extension to look at for setting values would fine. It would be 'visible' by an end-user technically, and editable if they're an admin...but this is not an uncommon method of creating a tool where you can deploy customizable settings with a 'configuration file' of some kind. Users never look there anyway!
It would also allow you to push one 'config file' that works for every browser you support down the line, and making changes becomes easy.
Benefits for MSPs
This would allow MSPs to maintain parity for deployment to both Macs and PCs. There are MSPs that support a healthy enough mix of both that this can end up
Value or Importance
I wouldn't say this is critical as in every MSP needs this feature, but I can say that it will prevent our MSP from being able to utilize it because we have to maintain a level of parity in functionality and branding between our Macs and PCs since Macs are around 35% of our fleet.
Please confirm:
Problem Statement
When you deploy a management profile via an MDM the settings are written to /Library/Managed Preferences/ to whatever Apple key is specified or custom key created by the developer for their software (Screenshots above). And yes they are written in XML format
That said, there are definitely developers in the Macadmins community that have made apps that also can read settings deployed other places, usually those get deployed to the /Library/Preferences folder which is a common location to store settings and is not locked to only the MDM being able to deploy settings there.
If you're doing the latter you have quite a bit more flexibility in how you want to store your settings. Nudge is an open-source community app that is a good example of something that can read settings from an MDM profile, OR read them from a JSON file stored locally (technically, they've made the app flexible enough to also specify a configuration profile location hosted online as well).
Here's a couple of examples in their Wiki explaining the 'setup' portion:
MDM Profile:
https://github.com/macadmins/nudge/wiki/Getting-Started#configuration
JSON Support (MDM Profile takes precedence over this):
https://github.com/macadmins/nudge/wiki#json-support
Attached above is also a decent post from a forum where someone is working to build a method of deploying settings via MDM.
Honestly, since this is an extension for Chrome and Edge, and not necessarily a standalone app I don't know if there's any interaction that has to be considered. It seems like there's potentially some interaction with Chrome and Edge that may require consideration.
That said, as an example of something that will already force Check onto Edge and Chrome see this last attached .mobileconfig test file. The PayloadType key is what designates the name of the plist file that gets created in /library/managed preferences
Here's an example .mobileconfig file. For reference, I am deploying this as a Custom Profile within Kandji.
Example .mobileconfig file:
For another simpler example of a tool that was created that can a policy passed via MDM configuration profile there's a tool that's simply written in bash where they are just looking the dictionaries passed in the /Library/Managed Preferences/ of the file that's named based on the tool.
https://github.com/SecondSonConsulting/Baseline/blob/main/Baseline.sh
He's written it so that it will pull the expected filename from /library/managed preferences/ OR you can custom set the filepath of your custom config file.
Honestly though, something as simplye as JSON in /Library/Preferences or a plist file which in XML format in that same location is something that you could write your extension to look at for setting values would fine. It would be 'visible' by an end-user technically, and editable if they're an admin...but this is not an uncommon method of creating a tool where you can deploy customizable settings with a 'configuration file' of some kind. Users never look there anyway!
It would also allow you to push one 'config file' that works for every browser you support down the line, and making changes becomes easy.
Benefits for MSPs
This would allow MSPs to maintain parity for deployment to both Macs and PCs. There are MSPs that support a healthy enough mix of both that this can end up
Value or Importance
I wouldn't say this is critical as in every MSP needs this feature, but I can say that it will prevent our MSP from being able to utilize it because we have to maintain a level of parity in functionality and branding between our Macs and PCs since Macs are around 35% of our fleet.