Categories
Mac admin'ing

The limits of password-protecting a .mobileconfig profile

Three years ago, Rich Trouton wrote Adding password protection to manually installed management profiles, which gives step-by-step instructions for how to make a manually-installed profile prompt for a custom password (in addition to the local admin password) when being removed.

I’ve tested this on Catalina, and it still works!

That said, it worked only from the GUI (via System Preferences). If you remove the sample profile (sudo profiles remove -identifier 9f9a0b1f-7b17-4656-92aa-b7046ad88d00), it will just remove immediately with no custom password provided.

Your best bet for making a profile non-removable is to install it via MDM.

Categories
Mac admin'ing

Things to keep in mind if using a profile to delay macOS updates

Now that Apple has removed the --ignore flag from softwareupdate, it’s recommending you use the forceDelayedSoftwareUpdates and enforcedSoftwareUpdateDelay flags (more details in Device Management Profile: Restrictions), which are supposed to, in theory, delay an updates user visibility a certain number of days after the update’s release.

The number of days delayed may not be precise

The number of days delayed is imperfect at best. I tested a 7-day delay and even 6 days after the release of the update, it was suddenly available. And here’s an example of someone last year who didn’t see an update released 10 days before, even with only a 7-day delay.

System Preferences and softwareupdate may not be in sync

In my own testing, if you delay an update but a Mac is two or more updates behind, softwareupdate -d -a or softwareupdate -l will still show an update available to download, but System Preferences > Software Update will show Your Mac is running the latest software update allowed by your administrator.

That can be a problem if you rely on a program like Nudge, which uses softwareupdate to determine whether an update is available but points users to System Preferences to do the actual update.

At this time, unless Apple makes significant changes, I wouldn’t recommend using the delay update profile settings if you have any utilities that use softwareupdate to check whether updates are available or not.

Categories
Mac admin'ing

Forcing updates to Google Chrome using Chrome preferences / a Chrome profile

Why use Chrome relaunch notification instead of Munki

I’m a huge fan of using Munki to patch software on macOS, but Munki is generally polite—it usually won’t kill an application while the user is using it. There is an option in Munki to force an install after a certain date, but that will log the user out of her computer completely in order to install whatever item you set as a forced install.

The actual preferences for Chrome relaunch notification

If you want to just have Chrome update to the latest version without logging out the user, but you want to force that to happen (say, if there’s a fairly serious zero-day security vulnerability), you can use Chrome preferences to do so:

defaults write com.google.Chrome RelaunchNotification -int 2

defaults write com.google.Chrome RelaunchNotificationPeriod -int 3600000

The first command forces a relaunch instead of just recommending one. The second one gives the period of time (in milliseconds) the user has before the relaunch happens.

Using a profile instead of commands to manage the preferences

Those commands probably aren’t something you want to run at scale. You’d want to use that as a quick test, and then you could deploy those settings as a .mobileconfig profile, which you can use mcxToProfile to do. You can also apparently use ProfileCreator to do so as well (using ProfileManifests), but I haven’t fully explored that yet. And, if you’re a Jamf user, you can use plutil -convert xml1 to use custom settings for a Jamf-created profile.

Deploy (and undeploy) thoughtfully

I’m going to give a major caveat that, unless you want to perpetually annoy your users, you probably don’t want to have this profile installed all the time, because it means every single time there’s a Chrome update (and Google does update Chrome quite frequently), your users will have only an hour (or whatever time period you set for RelaunchNotificationPeriod) to relaunch Chrome. Not all Chrome updates are immediately critical, so use this obnoxious “you must relaunch” Chrome policy judiciously.

What your users will see

This is the type of warning users will see:

Will users lose their open tabs?

I can’t say definitively, because the functionality may change in the future, but as of the writing of this blog post (late November, 2019), even if users have not set Continue where you left off, this forced relaunch will, in fact, re-open the tabs that were open before:

Um, test for yourself, obviously. You don’t want to have a bunch of angry users. You could, alternatively, have your .mobileconfig profile manage the RestoreOnStartup preference.

What’s the actual user experience like for the restart?

In my testing, it seems the 6-minute warning is the last one you can dismiss, and then when it’s ready to relaunch to install the update, Chrome gives absolutely no notification that the relaunch is happening when it happens. Chrome just closes out and then relaunches.

Further reading

More details at Google’s Notify users to restart to apply pending updates.

Even more technical details at Chrome Enterprise policy list.