04-11-2019 09:46 AM
Hi everyone,
Excited about the new Custom Apple Profiles features, such as variables. We are using custom profiles all the time.
Recently though we ran into an issue with <data> payloads. It seems Meraki parses those payloads as strings and adding line breaks (\n) and tabs (\t) to the payload. To give you an example, I have prepared a testing profile 'TestingData.mobileconfig'. It contains a Base64 encoded data payload of 'SGVsbG8sIFdvcmxkCg==' that decodes to 'Hello, World'.
<?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>TestBase64AsData</key> <data>SGVsbG8sIFdvcmxkCg==</data> <key>TestBase64AsString</key> <string>Hello, World</string> <key>PayloadDescription</key> <string>Testing Base64 Parsing / Coding</string> <key>PayloadDisplayName</key> <string>Test Base64</string> <key>PayloadIdentifier</key> <string>com.example.9A4C94F2-65FC-42E4-9EB2-BBE7B34950F9</string> <key>PayloadType</key> <string>com.example.testingdata</string> <key>PayloadUUID</key> <string>9A4C94F2-65FC-42E4-9EB2-BBE7B34950F9</string> <key>PayloadVersion</key> <integer>1</integer> </dict> </array> <key>PayloadDisplayName</key> <string>Testing Data Payload</string> <key>PayloadIdentifier</key> <string>com.example.testingdata</string> <key>PayloadRemovalDisallowed</key> <false/> <key>PayloadType</key> <string>Configuration</string> <key>PayloadScope</key> <string>System</string> <key>PayloadUUID</key> <string>03ADDA1A-DB8F-4957-B359-E813FC52EA4D</string> <key>PayloadVersion</key> <integer>1</integer> </dict> </plist>
If you install this profile directly, i.e. locally on a Mac by double clicking on it, its 'TestBase64AsData' payload is correctly recognised as data. If you then install the same profile via Meraki Systems Manager its data payload gets displayed as:
(
"Hello, World\n\t\t\t\t"
)Profile installed locally
Profile installed via Meraki Systems Manager
This leads to problems when working with <data> payloads in scripts and external programs. As an example, to reproduce the output mentioned above you can use the following Swift code and put into a file named 'print-example.swift'. Then run 'swift print-example.swift' from the command line:
#!/usr/bin/swift
import Foundation
import CoreFoundation
let appID = "com.example.testingdata"
let key = "TestBase64AsData"
if let value = CFPreferencesCopyAppValue(key as CFString, appID as CFString) {
print(value)
print("Type: \(type(of: value))")
}<data> is a valid payload as mentioned in Apple's Configuration Profile Reference:
"Configuration profiles are written in property list format, with Data values stored in Base64 encoding. The .plist format can be read and written by any XML library."
All testing was done on macOS 10.14.4. Has anybody else run into this issue?
Solved! Go to Solution.
04-12-2019 10:02 AM
We have updated the way custom .mobileconfig profiles are parsed and believe this issue is now resolved.
I just tried this example and see the profile install from Systems Manager as expected like this:
@PaulG3 can you try again?
04-11-2019 12:19 PM
04-11-2019 03:14 PM
We have. Last few days my custom 802.11x wifi profiles have stopped working for both iOS and macOS, where they both used to work flawlessly. https://community.meraki.com/t5/Endpoint-Management-Systems/Custom-Apple-Profiles-not-working-anymore/m-p/43312#M4436
04-11-2019 05:18 PM
It is great to see all the excitement for .mobileconfig variable support -- such a powerful enterprise feature!
Thank you all for the feedback and use case examples here.
I wanted to let everyone know that we are aware of the issue, and currently working to resolve it. We will keep everyone posted on this thread when the issue is resolved.
04-12-2019 10:02 AM
We have updated the way custom .mobileconfig profiles are parsed and believe this issue is now resolved.
I just tried this example and see the profile install from Systems Manager as expected like this:
@PaulG3 can you try again?
04-16-2019 01:34 AM
Thanks for your super quick resolution here, @matmorg2. I can confirm, the issue has been resolved on my side as well. In my testing, <data> payloads are now being parsed correctly. 🙌👍
04-16-2019 11:13 AM
No problem @PaulG3 and thank you for the resolution confirmation on your side!
FYI this brief base64 decrypting issue happened after we added $VARIABLE support for custom uploaded .mobileconfig files. You can now make your custom .mobileconfig files even more robust by using variables of Meraki Dashboard values.
Learn more about this powerful new feature and all the supported .mobileconfig variables here:
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide