This is the type of warning users will see:

Not all Chrome updates are immediately critical, so use this obnoxious “you must relaunch” Chrome policy judiciously. 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. And, if you’re a Jamf user, you can use plutil -convert xml1 to use custom settings for a Jamf-created profile. You can also apparently use ProfileCreator to do so as well (using ProfileManifests), but I haven’t fully explored that yet. mobileconfig profile, which you can use mcxToProfile to do. You’d want to use that as a quick test, and then you could deploy those settings as a. Those commands probably aren’t something you want to run at scale. Using a profile instead of commands to manage the preferences The second one gives the period of time (in milliseconds) the user has before the relaunch happens. The first command forces a relaunch instead of just recommending one. 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:ĭefaults write RelaunchNotification -int 2ĭefaults write RelaunchNotificationPeriod -int 3600000 The actual preferences for Chrome relaunch notification 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. 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. Why use Chrome relaunch notification instead of Munki

Update google chrome 2019