profiles – St. Ignatius College Prep Tech Blog

Using Munki to manage Mac preferences with .mobileconfig profiles

You may sometimes script preferences using defaults write commands (don't edit the .plist files with a text editor directly). For example, you might change Munki client preferences using a command like:

sudo defaults write /Library/Preferences/ManagedInstalls SoftwareRepoURL "https://subdomain.yourserver.com/munki_repo"

That's fine to do, but if you're actually managing Munki client preferences (not just for Munki-related settings but for other third-party or macOS settings), why not use Munki's built-in support for .mobileconfig profiles?

There are several methods to get or generate .mobileconfig profiles. I'm listing them below in order of preference from top recs to not-to-top recs.

Just finding existing profiles

Chances are if you want to manage a setting, someone else has also wanted at some point to manage that setting. site:github.com mobileconfig is a great Google search for finding those.

Using mcxToProfile to generate a profile

You can create .mobileconfig profiles from existing .plist preference files you already have on a sample client machine. Just download Tim Sutton's mcxToProfile.

Then you can run something like

./mcxToProfile --plist /Library/Preferences/ManagedInstalls.plist --identifier MunkiPrefs

and then you can hand-edit the resulting .mobileconfig file to get out anything extraneous (for example, if all you want to set is the SoftwareRepoURL).

Generating Profiles with Apple Configurator

Apple Configurator is another option.

Just click File and select New Profile.

Once you've selected everything you want to configure, click Save.

The code it produces is (like mcxToProfile's) clean and easy to edit. And, yes, you usually want to edit down .mobileconfig profiles to be only the things you actually want to manage. Omit (i.e., delete) anything that you want your users to be able to manage themselves.

Generating profiles with Profile Manager

If you're using Server.app, there's a built-in way to generate profiles.

I usually create a test device group with no actual devices in it.

Then, under Settings, select Edit.

Find the type of setting you want to edit (there are some generic settings and then others specific to iOS or macOS). and click Configure and check off all the stuff you want configured.

Then once you've closed out of the editing settings space, click Save for the whole device group. This will allow you to download the settings.

Click the Download button and select macOS.

Now we're getting to why I seldom use Profile Manager. It adds in a bunch of binary gobbledygook and shoves all of the tags together so it's not easy to read. So, yeah, you can use it... but not fun.

Update: Apparently, you can tidy up the XML fairly easily if you want. Thanks to Ian Vonesh for the tip.

Whichever method you use, though, you can just import the .mobileconfig directly into Munki and push it out to your clients (be sure to test for unexpected behavior first before moving to production).

Can’t change Safari homepage in Sierra, even with no profiles managing homepage

So I came across something weird that's affected only my 10.12.4 clients (none of my 10.11.6 clients seem to be affected by this). Even though I have only one Safari profile enabled, which is set-once and doesn't manage the homepage, my 10.12.4 clients are unable to change the homepage in Safari manually. Whatever the homepage was is stuck like that. If you enter a new homepage in the Safari preferences, it will just not take and revert back to the old homepage once you hit Enter or click out of the address entry field.

The only workaround I've found for this is to delete all profiles (again, even though I don't have any profiles managing the Safari homepage):

sudo profiles -D
Are you sure you want to delete all configuration profiles? [y/n]:y

reboot the computer, and then reinstall (via Munki) all the previously installed profiles (yes, including the set-once profile for Safari that was installed before)... and then I'm able to change the homepage on the client manually. Very bizarre.

Also, after testing on a couple of other clients, there do seem to be situations in which the Safari profile was never set at all, and you still can't modify the homepage, even after deleting any other profiles and rebooting, and it's not account-specific either (freshly created account experiences it, too). It's a real head-scratcher.

Set ShoreTel Communicator server name with a profile

When you install ShoreTel Communicator's Mac app, it launches up and asks you for a server name, username, and password. The username and password will be specific to each user, but the server name will likely be the same for everyone, at least at a small- or medium-sized organization.

So if you have Mac clients and some way to distribute profiles to them, you can use a .mobileconfig profile to pre-fill-in the server information. I've posted an example on GitHub, so you can just modify that to fit your organization's needs.

Once that's deployed, when people install ShoreTel Communicator for the first time, the server address will be in already, and they'll just have to fill in their usernames and passwords.

Using a profile to re-enable Safari plugins

Recently (not sure the exact date), Apple started disabling certain Safari plugins by default. That's great for security, but it's not that great for usability, especially if users actually want to use those plugins.

If you want your users to enable plugins themselves manually, they can follow Apple's instructions at How to use Internet plug-ins in Safari for Mac.

If you'd like to deploy a .mobileconfig profile, though, I've posted a sample one on GitHub that enables Flash, Java, and Silverlight (ask first, not just on all the time).

Rod Christiansen has a more comprehensive sample up (more plugins).

In addition to the plugins being generally enabled or disabled (with 0 or 1 / false or true), there is also a first-visit policy to look at.

This is the default setting (blocking):

PlugInFirstVisitPolicy = PlugInPolicyBlock;

This is the setting in the profiles I linked to:

PlugInFirstVisitPolicy = PlugInPolicyAsk;

And this is if you want it on (not asking):

PlugInFirstVisitPolicy = PlugInPolicyAllowWithSecurityRestrictions;

Missing Updates tab in Apps part of iTunes

This is a bit of an esoteric problem and fix, but I didn't see this documented anywhere else.

I originally deployed this profile to disable the iTunes welcome screen and check for updates, because I didn't want to bother the user with prompts for updating the iTunes app.

What I didn't realize is that also disables the Updates tab in the Apps part of iTunes. So I had to actually update the profile to keep the welcome screen off but bring the check for updates back.

Once I did that, the Updates tab reappeared.

Forcing a Chrome homepage on Macs

Nick McSpadden has a great (and thorough) write-up on Deploying and Managing Google Chrome: The Rough Guide, and his recommendation is to have some initial Master Preferences that set a default, which can be overriden.

In some cases, though (for example, we have some machines that will be used for Hour of Code next week that will be set to code.org/learn as the homepage), you may want to force the homepage, in which case a profile may be the way to do it. There's a great template for a Chrome profile on JAMF Nation. Just paste that into a text file, edit it, and then save it with a .mobileconfig extension, and then you can distribute the .mobileconfig using Munki or ARD.

Preparing SonicWALL Mobile Connect for Munki

I've found NetExtender (Packaging NetExtender for Munki) to be a little less buggy than SonicWALL Mobile Connect, but NetExtender is pretty much non-functioning in El Capitan, so I'm looking at possibly deploying SonicWALL Mobile Connect in the future.

The import process into Munki for the .app is fairly straightforward. You install SonicWALL Mobile Connect from the Mac App Store and then import the .app using munkiimport.

If you want to then deploy as an update a profile so you don't have to tell users a server name, you can create a profile using Apple Configurator (thanks to Greg Neagle for this tip). Profile Manager in OS X Server is another option.

Even though Apple Configurator is for iOS devices, you can still make a profile that's useful for laptops. Launch up Apple Configurator and then go to File and select New Profile.

Scroll through the list of profiles until you get to VPN.

Once you've selected VPN, click Configure to configure the profile.

Fill in what you can. The Connection Name is mandatory, and you can call it whatever you want. For the connection type, select SonicWALL Mobile Connect. Obviously, fill in your VPN server for Server.

It's okay to leave the username and password blank.

Once you're done with the profile, click File and then select Save.

Call it whatever you want, as long as you keep the .mobileconfig extension.

You may get a warning that there's an error in your profile (perhaps it's looking for the username and password). I have tested the "error"-giving profile with all the mandatory fields filled in, and it seems to still work.

Once that's done, you can use munkiimport to import the profile and make it an update for the SonicWALL Mobile Connect app.