I cobbled together a VERY rough approximation of a powershell script + mof edit that MIGHT work to gather the bare minimum information.
Download the files in the --> Attached Zip File <-- In the .zip file are two files
TestScript1.ps1 -- this is a powershell script you will need to have every ConfigMgr client you have run, presumably the ones with Google Chrome installed. You can either deploy it as a recurring advertisement, or my favorite is to create a "Configuration Item", and deploy the script that way on a recurring basis.
ToBeImported.mof -- Once you've had test workstations run that powershell script, AND you've confirmed that data appears on those test workstations' root\cimv2\cm_chromeExtensions, AND that data appears to be stuff you find interesting, THEN in your CM Console, Administration, Client Settings, Default Client Settings, Hardware Inventory, Import... this file.
"let the buyer beware": Read the .ps1 file--especially the top section. the part where the author (ok, it was me) said that this was all cobbled together and is probably useless.
1) 1 thing I noticed even with only 15 minutes worth of testing...I uninstalled Google Chrome from the test workstation. That does NOT clear out the user profile appdata folders where "chrome extensions" are listed. So everything was still reported. So it is highly likely, in fact probably guaranteed, that this will in no way EVER be indicative of "Google Chrome is actually installed and working". It's indicative of "Google Chrome was installed once and launched once for this user--sometime during the life of the computer". It could have been installed and uninstalled within 30 minutes and never used again--but the user profile information about chrome extensions will be there. Forever. Welcome to user-centric nightmares (if you weren't already aware of them). Also by the way, chrome apparently comes pre-packaged with multiple extensions so no matter what you'll have entries if any user ever launched Chrome on that workstation--even if it was immediately uninstalled. It won't matter.
so my recommendation is *if* you think in your weeks of testing that this might be useful in some way--in reporting you will need to be extremely careful to tie the reports about chrome extensions to machines which clearly indicate that chrome is actually installed. Or, of course--feel free to re-write this chrome extensions script to detect that before recording anything.
2) There were some extensions in the user profile folder for chrome extensions for which I couldn't figure out any way to clearly identify what it was. Those will be labeled unknown. You are certainly welcome to edit the script if you know how to identify those.
3) No promises of usefulness or compatibility or even functionality are implied. I'm just tossing this out there in the hopes that someone else can make it work better. If in fact anyone even cares about Chrome extensions. Ever.
fyi, in testing, I got this type of information on the test box:
|0||Google Docs||0.9||c:\users\fakeuser||3/28/2016 4:55:13 PM|
|1||Google Drive||14.1||c:\users\fakeuser||3/28/2016 4:55:13 PM|
|2||YouTube||4.2.8||c:\users\fakeuser||3/28/2016 4:55:13 PM|
|...||<more data>||3/28/2016 4:55:13 PM|
|14||iHeartRadio||1.1.0||c:\users\anotheruser||3/28/2016 4:55:14 PM|
In the above example, "fakeuser" used Chrome and never added any CUSTOM or additional extensions. "anotheruser" using the same computer did add a custom extension for iHeartRadio.
As mentioned, only tested in a distracted way in a test environment on 1 test workstation in a lab. This is probably horrible code, a horrible idea, and will need to be re-written from scratch. Or.... it just might work fine. <shrug>