Tag: munki

Considerations when upgrading CrashPlan with Munki

I had a great workflow for installing CrashPlan with Munki for older versions of CrashPlan (we were on versions 3 and 4 before).

We recently made the jump to CrashPlan 6.5, though, and that workflow no longer applies. Now you have to use a deploy.properties file instead of custom.properties and userInfo.sh files.

We had some added complications to our "upgrade" process, because our new CrashPlan server is a completely different server, and we weren't migrating everyone at once, so we couldn't just change the DNS to point to the new server. I'm not sure a jump from 4 to 6.5 would have been possible as just an installation upgrade anyhow.

So what were those complications?

  • We couldn't use an installs array any more to tell Munki whether CrashPlan was installed or not. Keeping the installs array would (without managed_updates) prompt users to upgrade to CrashPlan 6.5 or, worse, just upgrade them automatically (with managed_updates). So I changed CrashPlan 4 and 6.5 to use an installcheck_script instead.
  • Since CrashPlan 6.5 isn't just an update but an actual upgrade for us (think Microsoft Office 2016 vs. Microsoft Office 2011), it's a separate item in Munki altogether, which means we also had to remove the old version from the client's SelfServeManifest before installing the new version (otherwise, the old version would just reinstall).
  • Likewise, as part of the preinstall_script for 6.5, we had to invoke the /Library/Application Support/CrashPlan/Uninstall.app/Contents/Resources/uninstall.sh script to remove 4 first.
  • Lastly, we had to have a temporary place to hold the deploy.properties file before copying it to /Library/Application Support/CrashPlan—otherwise, the old installation of CrashPlan would somehow make it disappear or be unusable by the new installer. Not sure exactly what was happening, but it wasn't being recognized when just being delivered there directly as a payload. We also tried including the deploy.properties file in the .dmg itself, but that didn't work either (prompted for server and registration key).
  • Annoyingly, if you choose not to use SSO, you can't fully automate user account creation or sign-in, so some user interaction for the upgrade is required.

Ours may be a very niche scenario (upgrading from CrashPlan 4 to CrashPlan 6.5 and not using single sign-on), but in case anyone else is in that same situation and using Munki, maybe this blog entry can save you some time in planning your rollout.

Create a .mobileconfig profile for a certificate

If you want to create .mobileconfig profile from a certificate (for example, to import into Munki), you can use Apple Configurator 2 to do so.

If you have your certificate already in your keychain, launch up Keychain Access.app and find the certificate you want to make into a .mobileconfig profile.

Right-click the certificate and select Export NAMEOFTHECERTIFICATE (export it as a .cer).

Then launch up Apple Configuration 2.app.

Select File and then New Profile


Select Certificates and then Configure.

Find and select the certificate you exported earlier.

Select File and then Save.


Pick a filename for your .mobileconfig, which you can deploy however you want (as I previously mentioned, you can import this into a Munki repo).

If munkiimport doesn’t generate an installer_item_hash in the pkginfo file

If you notice that running munkiimport on a .dmg doesn't result in an installer_item_hash generating, you might want to also run makepkginfo on that .dmg to double-check it's read-only:

makepkginfo /PATH/TO/REPO/pkgs/PROBLEMITEM.dmg
WARNING: /PATH/TO/REPO/pkgs/PROBLEMITEM.dmg is a writable disk image. Checksum verification is not supported.
WARNING: Consider converting /PATH/TO/REPO/pkgs/PROBLEMITEM.dmg to a read-only diskimage.

Failing Adobe Acrobat DC updates

Usually when new Acrobat updates come out, I can have clients pull them off the Munki server and install those updates automatically. Randomly, some clients will error out:

installer: The upgrade failed (The Installer encountered an error that caused the installation to fail. Contact the software manufacturer for assistance.)
installer:%42.031690
installer:PHASE:Preparing for installation…
installer: Package name is Adobe Acrobat DC (18.011.20038)
installer:PHASE:Validating packages…
------------------------------------------------------------------------------
installer: Upgrading at base path /
installer:%97.750000
installer:PHASE:Configuring the installation…
installer:%72.402678
installer:PHASE:Writing files…
installer:PHASE:Running package scripts…
installer:PHASE:Preparing Adobe Acrobat DC (18.011.20038)…
installer:%4.485919
installer:PHASE:Waiting for other installations to complete…
installer:STATUS:
installer:PHASE:Preparing the disk…
At first I thought maybe having the update require a logout might fix that issue, but it doesn't. The only working solution I've found is to delete the Acrobat folder, run
sudo managedsoftwareupdate --auto
and then Munki will see that Acrobat is missing and install both Acrobat and the update just fine.

Not sure if there's a less involved way to fix that. And it seems to happen only for a few clients randomly.

Using Munki’s force_install_after_date key to force items to install

Keeping machines up to date can be a challenge. Munki tries to make this as seamless as possible, especially if you mark certain items as unattended installs (Munki will try to install those items in the background and not even bother the user).

But some updates require a logout or a reboot, and users generally don't like to log out or reboot often, particularly if they have laptops (as opposed to desktops). So pending updates can sit there for days, weeks, months, even over a year, unless you force the user to install the items.

I wouldn't recommend using the force_install_after_date option very often, but it can be very handy, particularly if there are critical updates that need to get to users.

And even though Munki itself will attempt to notify users of forced updates, you may want to accompany those built-in warnings with warnings of your own (via email, in person, etc.).

At the final countdown, the screenshots below are examples of what your users will see. Every time there's an OK button in the Managed Software Center, your user has the option to close Managed Software Center for a short time, but then MSC will just pop back up again soon. At the very last dialogue, the user will have no choice but to install the pending install item.

Once again, use sparingly, but you may need to use it, so it's good to know roughly what your users will see...

Troubleshooting Munki failing to install Apple updates

Problem

If you see Apple updates (that require a reboot) not installing properly via Munki, it may be because the downloaded update is stale somehow. Not really 100% sure on how this works, since I've seen this fail even on a "stale" update downloaded the same day (not weeks ago).

Symptoms

When you log out to update, you'll see Munki's progress bar over the login screen window, and it will look for a split second as if it's trying to install the pending Apple update but then move on almost immediately to requiring a reboot.

Then, if you check the logs at /Library/Managed Installs/Logs/Install.log, you'll see something like

Apple Software Update install of Security Update 2017-001-10.12.6: FAILED for unknown reason

Workarounds

You could create a script (run from its own Launch Daemon or as part of a Munki run) to clear old updates from the /Library/Updates folder periodically (though, again, I saw this happen even with a recently downloaded update).

I've found that if you run

softwareupdate -d -a
the newly downloaded update will install just fine via Managed Software Center.

This is tricky, because it's not technically a Munki issue (Munki just uses Apple's built-in softwareupdate to install Apple software updates), but clearly there's some flaw in invoking the software update mechanism.

Deploying Munki with Mosyle MDM

Acknowledgements: This is a slightly modified workflow based on one proposed by Taz on MacAdmins Slack. Thanks, Taz!

You can use Mosyle to install Munki.


Switch to the macOS platform (if you're not already in there).


Then, click on Management.


Scroll down to and then click on Custom Commands.


Click Add new profile.


Name it whatever you want (e.g., Install Munki), and then put in a modified version of this code:

#!/bin/bash

# Name of .pkg
munkitools='munkitools-3.1.0.3430.pkg'

# Desired hash output
desired_hash='MD5 (munkitools-3.1.0.3430.pkg) = 0afbe2fbe7cb81ff531834cba82f3a75'

# Go to the /tmp directory
/usr/bin/cd /tmp

# Download the latest Munki tools .pkg
/usr/bin/curl -L -O https://github.com/munki/munki/releases/download/v3.1.0/"$munkitools"

# Make sure the hosting server hasn't been compromised and/or the download isn't corrupted
md5_test=$(/sbin/md5 $munkitools)

if [[ "$md5_test" == "$desired_hash" ]]; then

# Install the Munki tools .pkg
/usr/sbin/installer -allowUntrusted -pkg /tmp/munkitools-3.1.0.3430.pkg -target /

# Add in basic auth info
/usr/bin/defaults write "$3"/private/var/root/Library/Preferences/ManagedInstalls AdditionalHttpHeaders -array "Authorization: Basic BASICAUTHCODE"

fi

Assign this profile to whatever devices or groups you want, and then click Save.

Any other Munki preferences (e.g., SoftwareRepoURL) you'll want to deploy in a .mobileconfig profile. More details in Importing custom .mobileconfig profiles into Mosyle MDM.

P.S. I haven't done extensive testing on this, but you may be able to deploy Munki as a .pkg and not as a custom command that downloads the .pkg. You'll have to host it somewhere yourself (and Mosyle does not like the redirect URLs, so you'll legit have to host it), but you may want to try Management > Management Profiles > Install App > Add new profile. Then, under Installation source, pick Enterprise app, and then put in the URL of the hosted Munki installer .pkg.

To change the icon, just get a .png of whatever icon you want. Here's an example of how to generate that:

sips -s format png /Applications/Managed\ Software\ Center.app/Contents/Resources/Managed\ Software\ Center.icns --out MSC.png

Only caveat is that that won't work for scripting basic authentication.

Troubleshooting faded-looking icons in Managed Software Center on 10.13 clients

Update: Apparently, a real fix for this is on the way.

Acknowledgements: thanks to elios and bochoven on MacAdmins Slack for figuring out what was going on.

If the icons in your Munki repo looked fine on your 10.12 and 10.11 clients, and then a few of them suddenly look sort of faded (for example, Word and Excel in this screenshot) in 10.13 clients, it's apparently because of a change in the way 10.13's Safari webkit displays .png files missing the ColorSync profile in the Get Info context menu (you'll still see the ColorSync profile if you open the .png with the ColorSync Utility).

The simple fix is to do the following:

  1. Mount the Munki repo share using a Mac running macOS 10.13.
  2. Delete the offending icons from /PATH/TO/MUNKI/REPO/icons/
  3. Regenerate new icons with
    /usr/local/munki/iconimporter /PATH/TO/MUNKI/REPO

Note: Icons generated using MunkiAdmin or sips will be fine, too, even if generated using a machine running macOS 10.12.

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.