@jamf_sam @alexbauer This is great news! I really appreciate having Chrome available as an officially signed and notarized PKG installer. This will save me quite a few steps in my packaging and testing workflow for Chrome.

@jamf_sam I am not sure if Jamf plans on reaching out to other companies like this but if you can convince Adobe to create standard flat PKGs, for all of their Creative Cloud products, that are properly signed and notarized for easier use with Enterprise/Education deployment you will be considered a miracle worker. Mac IT admins around the world will sing your praise!

Thanks @jamf_sam @alexbauer . I noticed this few days ago & already deployed the pkg installer on few Macs for testing, wasn't aware Jamf was behind this. This is really great & saves a lot of time for us.

This sounds like a great start! Are you still adding the updater application to the user libraries? That is my biggest issue as Security has instructed us not to allow any application launches from within User Space.

Awesome!!! Here's a script to automatically download and install it.

#!/bin/sh

pkgfile="GoogleChrome.pkg"

logfile="/Library/Logs/GoogleChromeInstallScript.log"

url='https://dl.google.com/chrome/mac/stable/gcem/GoogleChrome.pkg'



/bin/echo "--" >> ${logfile}

/bin/echo "`date`: Downloading latest version." >> ${logfile}

/usr/bin/curl -s -o /tmp/${pkgfile} ${url}

/bin/echo "`date`: Installing..." >> ${logfile}

cd /tmp

/usr/sbin/installer -pkg GoogleChrome.pkg -target /

/bin/sleep 5

/bin/echo "`date`: Deleting package installer." >> ${logfile}

/bin/rm /tmp/"${pkgfile}"



exit 0

Sorry for the late reply. @tomt, I ran a test and the PKG installs the updater files here (see screenshot below). It will put some update stuff in the user library as well, but I believe that is used to stage updates etc. The updater itself should not be in the user library I believe.

@ooshnoo hey can you explain what the 4th line below does? specifically the /${pkgfile} ${url} whats it doing with these 2 variables on that line? is it just renameing the downloaded .pkg to GoogleChrome.pkg? (i see that in the installer -pkg line)

pkgfile="GoogleChrome.pkg"
logfile="/Library/Logs/GoogleChromeInstallScript.log"
url='https://dl.google.com/chrome/mac/stable/gcem/GoogleChrome.pkg'

/usr/bin/curl -s -o /tmp/${pkgfile} ${url}

No .apps in ~/Library/Google/GoogleSoftwareUpdate? If so, that's great! I'll give this .pkg a test as soon as I have some time.

I've had to resort to using a locked file that Chrome could not replace since every time Chrome was launched it would recreate the updater app inside the user's library.

Thanks

@tomt, one of the reasons why we did the PKG was that with the DMG, updates were not applying consistently on mac deployments. We've heard from customers that the way Jamf Composer and other tools were picking up the "delta" to build the PKG was missing sometimes some of the updater files which in turn would break auto update for some users.

By the way, if anyone would like a more thorough demo related to CBCM, let me know. We can have a quick 30 minute call to go over what it is, capabilities, etc.

Can someone throw out a clue as to why when I install Google Chrome with the pkg at the link below and then throw it in the trash to test installing again that the pkg then errors out and doesn't install thereafter?

https://cloud.google.com/chrome-enterprise/browser/download/

It literally worked the first time I ran it. Threw Google Chrome in the trash and tried both testing through Self Service and double-clicking the package and got same results where it errored out.

one of the reasons why we did the PKG was that with the DMG, updates were not applying consistently on mac deployments. We've heard from customers that the way Jamf Composer and other tools were picking up the "delta" to build the PKG was missing sometimes some of the updater files which in turn would break auto update for some users.

@alexbauer In our case, we want to completely disable auto updates and any helpers, reminders or pop-ups about them. Unfortunately we have quite a few legacy portals and have to vet each update before releasing them.

@tomt you can do that through policy. disable auto update and pin to certain versions. only updates when you change the pinned version.
@jhuls, go to https://bugs.chromium.org/p/chromium/issues/list and open a new bug there and let me know the bug number and I will send it to our engineering team. make sure to add as much detail as you can

@alexbauer Thanks. It's 1065730.

@jhuls thanks! i forwarded the CRbug to our engineering team

An update on the issue I mentioned earlier...it turns out that the Google Chrome package provided by Google does not like it when there is a Google Chrome.app anywhere else in addition to or in place of /Applications on my system. The installer simply fails. I was unable to test on other systems since I'm doing the work from home thing now. Oddly enough it obviously worked the first time but after that is when it failed continously during the time that another Google Chrome.app was on my machine.

I don't see this as a big issue in my environment and I only learned of this because I have autopkg installed on my system creating packages to deploy...one of them is Google Chrome where it has Google Chrome.app located in their cache directory. The logs of the Chrome installer thinks that Google Chrome.app was relocated there. The same occurs if someone were to deploy this Google's package to a system that has the Google Chrome.app in ~/Applications or if a user were to have copied the app to ~/Desktop or ~/Downloads from the dmg still available to the general public.

At least on my machine it behaves this way. In another thread here I saw someone mentioning what sounds like a similar issue that they're experiencing.

Like I said this isn't a big deal for my environment and the solution is to remove the other Google Chrome.app applications on the system. In a looser setting where users have copied this to anywhere other than /Applications this looks to be a problem though.

I should add also that when running the installer package manually that it would on occasion show the "Destination Select" page rather than skip over it. Google's intention is for that to not be presented but it would show up on occasion while testing this. I don't have the technical kung-fu to know why the installer fails like it does or why it presents the "Destination Select" page at times. The page being shown seems harmless to me but it was strange seeing that show up every now and then.

Basically the person I chatted with seems to be marking this as a no-fix and seemed perplexed by what was going on. If it's an issue for others, they should probably speak up.

https://bugs.chromium.org/p/chromium/issues/detail?id=1065730

Now it looks like things are getting figured out with a fix on the way.

The issue is fixed in CRbug: https://bugs.chromium.org/p/chromium/issues/detail?id=1067275
Should roll out in the next PKG

Officially tagged for Chrome v83 for now, so it should come out May 19th.

@alexbauer Thanks for the fix and responsiveness.

My pleasure! Let me know if you guys run into any other issues and I will try to help from my side.

@alexbauer Hi, if you want to do a call, I'd join.

@dswitmer - send me an email alexbauer@google.com and we can set something up

This is good news indeed. Up until now, we have been scripting the download of the stable release .DMG and we keep seeing issues where the Chrome app only shows as partially installed. I've noticed it doesn't always seem to copy the full app from the tmp mount point and leaves a broken chrome.

@jamf_sam @alexbauer Are there any future thoughts of having Patch Management just carry the whole burden (perhaps with partnership with the various companies that make the apps followed in patch management) of downloading and installing said updates if the feature is turned on? The whole idea of packaging and adding updates constantly has always been a load of work, but it seems like JAMF is trying to take some of this off our plates.

The final push would be for Jamf to have an automatic solution (for these specific apps of course) to keep the community from having to script or package their own solutions and just have Patch Management get updates directly from those companies that we can turn on or not.

Gabe Shackney
Princeton Public Schools

@alexbauer @jamf_sam I have a request from my Security team to block certain Chrome extensions. I've used the "ExtensionInstallBlacklist" setting to block the extensions from installing. However, in my testing that setting doesn't disable and/or remove the extension if it's already installed. Do either of you know how to do this? I'm currently deploying all my Chrome settings via Configuration Profile through Jamf Pro. For the life of me I'm not able to find a way to disable and/or remove extensions that might already be installed.

My example: I was testing with trying to block Adblock Plus extension (cfhdojbkjhnklbpkdaibdccddilifddb). I found that when I add (cfhdojbkjhnklbpkdaibdccddilifddb) to the "ExtensionInstallBlacklist" setting, I was unable to install it. However, if I remove it from "ExtensionInstallBlacklist", install Adblock Plus extension, then, re-add the "ExtensionInstallBlacklist". Adblock Plus functions without any issues. I'm trying to find the setting to disable/remove already installed Chrome extensions. Any help is greatly appreciated!

So does this package now take care of the heavy lifting and update chrome as well or is this still a manual or scripted processes I currently have a script that checks for the latest version of the .DMG and then updates it if available.