Um … yeah, if you could go ahead and create some macOS custom XML preferences … that’d be great.
In the cult-classic film “Office Space,” Peter, the protagonist, finds himself backed into a
corner cubicle. Bill Lumbergh, his boss and archnemesis, confronts Peter for ignoring a company-wide memo and submitting a TPS report in the wrong format. The TPS-report fiasco tackles the mundane drudgery of corporate America with sardonic wit. However, when it comes to creating custom XML preferences, the FORMAT IS EVERYTHING.
Prepare for a deep dive into the underbelly of macOS preferences and unrelenting use of “Office Space” movie references.
Did You Get the Memo—on Custom XML Preferences?
I’ll admit, I spent an entire
hour evening brainstorming ways to make this blog post funny. However, XML preferences are about as exciting as cover sheet memos and TPS reports. So, in keeping with the theme, I pulled a “Lumbergh” and formatted parts of this post as a memo.
If you could take a moment to read about macOS X custom XML preferences … that’d be great.
Have You Seen My Custom XML?
I believe you have my stapler … or rather my Custom XML!
1. Discover the .plist file, and the setting that defines the specific preference to manage, using one of the following methods:
[learn_more caption=”Method One: Sort in Common Preferences Folder”]
- Open the common preferences folders in Finder.
- Sort by Date Modified.
- Perform the change.
- The preference file modifies and sorts to the top of the list.
Apps typically name plist files with a reverse DNS name, such as com.apple.screensaver.plist, and store preferences in one of these places:
[/learn_more][learn_more caption=”Method Two: Use a Search Engine”]Use a search engine to hunt the following:
defaults write <setting you wish to manage>
Again, Apps typically name plist files with a reverse DNS name, such as com.apple.screensaver.plist, and store preferences in one of these places:
2. In the Terminal app, validate the desired settings are in the plist by running: [box]
defaults read <setting you wish to manage>[/box] Note that you may not see a value for the setting if that setting is the default set by the app. In this case you may need to modify the setting in the application or OS graphical interface in order to see the setting populated in the plist file.
3. Copy the preference plist file to the downloads folder: [box]
cp ~/Library/Preferences/<preference domain>.plist ~/Downloads[/box]
4. Convert the plist file from binary to XML in place: [box]
plutil -convert xml1 ~/Downloads/<preference domain>.plist[/box]
5. View the converted plist file in a text editor and note (or generate) the values necessary to create the Custom XML payload:[box]
- PREFERENCE DOMAIN: The reverse-DNS-like name the app uses to find preferences (such as com.apple.applicationaccess).
- UUID: A universally unique identifier (such as 0206B78C-8768-4FDD-BC25-4DA4AF668F3D). This can be generated on the fly on macOS by typing uuidgen in terminal.
- DISPLAY NAME: A descriptive name for the Custom XML payload.
- SETTING KEY: The name of the preference you wish to set/manage.
- SETTING VALUE: The value you wish to set/manage for the particular preference.
- TYPE: Describes the value type, such as integer (<integer></integer>), string (<string></string>), or Boolean (note: Boolean values simply use <false /> and <true /> as a combined type/value field).[/box]
6. Paste the specific attribute information into the Custom XML template: [box]
<dict> <key>PayloadType</key> <string>PREFERENCE DOMAIN</string> <key>PayloadVersion</key> <integer>1</integer> <key>PayloadIdentifier</key> <string>PREFERENCE DOMAIN.UUID</string> <key>PayloadEnabled</key> <TYPE> <key>PayloadUUID</key> <string>UUID</string> <key>PayloadDisplayName</key> <string>DISPLAY NAME</string> <key>SETTING KEY</key> <TYPE>SETTING VALUE</TYPE> </dict>
7. Log into the AirWatch Console and configure a custom settings profile payload for macOS.
8. Paste the formatted code into the Custom XML text box in AirWatch.
Example Custom XML Payload
As an example, if I were attempting to restrict macOS devices from using Apple Watch to auto-unlock, I end up with a Custom XML template as such:
<dict> <key>PayloadType</key> <string>com.apple.applicationaccess</string> <key>PayloadVersion</key> <integer>1</integer> <key>PayloadIdentifier</key> <string>com.apple.applicationaccess.11e159b0-71f5-0134-6b2b-44b301c1afb3</string> <key>PayloadEnabled</key> <true /> <key>PayloadUUID</key> <string>11e159b0-71f5-0134-6b2b-44b301c1afb3</string> <key>PayloadDisplayName</key> <string>Restrict Watch Unlock</string> <key>allowAutoUnlock</key> <false /> </dict>
This template then gets pasted into the Custom Settings field in a macOS profile payload as shown below:
This Isn’t so Bad, Huh?
You’ve got that one right, Peter! As shown above, VMware AirWatch can be extended to manage more than just what you see in the Console. By discovering property lists and preferences used to manage settings in macOS, administrators can craft a Custom Settings XML payload that can be deployed by AirWatch.
Because you liked this post: