I'm sure there are a dozen if not hundreds of blogs posts out there with this exact same information; just posting it mostly for myself.  If it helps someone else, great.  As of late July 2016, these are the versions (and their Marketing or public names) for the ConfigMgr Client.  It doesn't go back to SMS 1.0, or even cm07--so not as useful for "everything ever". 

But if you get "unknown" versions when you run it, you can fill in your own blanks.

SELECT COUNT(resourceID) [Count],
    Client_Version0 [Version]
, case
when client_version0 = '5.00.7711.0000' then 'ConfigMgr 2012 RTM'
when client_version0 = '5.00.7804.1000' then 'ConfigMgr 2012 SP1'
when client_version0 = '5.00.7804.1202' then 'ConfigMgr 2012 SP1 CU1'
when client_version0 = '5.00.7804.1300' then 'ConfigMgr 2012 SP1 CU2'
when client_version0 = '5.00.7804.1400' then 'ConfigMgr 2012 SP1 CU3'
when client_version0 = '5.00.7804.1500' then 'ConfigMgr 2012 SP1 CU4'
when client_version0 = '5.00.7804.1600' then 'ConfigMgr 2012 SP1 CU5'
when client_version0 = '5.00.7958.1000' then 'ConfigMgr 2012 R2'
when client_version0 = '5.00.7958.1060' then 'ConfigMgr 2012 R2 for Linux'
when client_version0 = '5.00.7958.1203' then 'ConfigMgr 2012 R2 CU1'
when client_version0 = '5.00.7958.1254' then 'ConfigMgr 2012 R2 CU1 for Linux'
when client_version0 = '5.00.7958.1303' then 'ConfigMgr 2012 R2 CU2'
when client_version0 = '5.00.7958.1401' then 'ConfigMgr 2012 R2 CU3'
when client_version0 = '5.00.7958.1501' then 'ConfigMgr 2012 R2 CU4'
when client_version0 = '5.00.7958.1604' then 'ConfigMgr 2012 R2 CU5'
when client_version0 = '5.00.8239.1000' then 'ConfigMgr 2012 R2 SP1'
when client_version0 = '5.00.8239.1203' then 'ConfigMgr 2012 R2 SP1 CU1'
when client_version0 = '5.00.8239.1301' then 'ConfigMgr 2012 R2 SP1 CU2'
when client_version0 = '5.00.8239.1403' then 'ConfigMgr 2012 R2 SP1 CU3'
when client_version0 = '5.00.8325.1000' then 'ConfigMgr 1511'
when client_version0 = '5.00.8355.1000' then 'ConfigMgr 1602'
when client_version0 = '5.00.8355.1001' then 'ConfigMgr 1602 with policyagentendpoint.dll update'
when client_version0 = '5.00.8355.1306' then 'ConfigMgr 1602 with KB3155482'
when client_version0 = '5.00.8355.1307' then 'ConfigMgr 1602 with KB3174008'
when client_version0 = '5.00.8412.1000' then 'ConfigMgr 1606 TAP'
when client_version0 = '5.00.8412.1006' then 'ConfigMgr 1606'
when client_version0 = '5.00.8412.1007' then 'ConfigMgr 1606 with KB3180992'
else 'unknown' end as [Marketing Version]
  FROM dbo.v_R_System_Valid
  GROUP BY
    Client_Version0
  ORDER BY [Version] desc

there's also this way...if you don't want to deal with all those pesky cumulative updates, or hotfixes

;with cte as (select resourceid, substring(client_version0,6,4) as [Ver] from v_r_system_valid)

select Ver,
Case
when Ver = '7711' then 'ConfigMgr 2012 RTM'
when Ver = '7958' then 'ConfigMgr 2012'
when Ver = '8239' then 'ConfigMgr 2012 R2'
when Ver = '8325' then 'ConfigMgr 1511'
when Ver = '8355' then 'ConfigMgr 1602'
when Ver = '8412' then 'ConfigMgr 1606'
else 'unknown'
 end as [Version]
,Count(resourceid) [Count]
from cte
group by ver
order by ver

In attempting to do some Powershell (WinRM) remote actions, specifically using  Roger Zander's Collection Commander, I came across this blog entry and thought "Awesome, already done for me!".  http://www.verboon.info/2014/12/installing-software-using-collection-commander/

And then I kept getting errors during testing, "Exception calling "Install" : ""  But it would work fine in the home lab... After much head scratching, at work we have a GPO to set Powershell ExecutionPolicy as RemoteSigned--which is good, of course.  But it threw this particular script for a loop.  In the home lab--since it is a home lab--I had set executionpolicy to unrestricted on the test box.

What I ended up doing was I found this blog post about different ways to get around a remote-signed execution policy (in a good way, not trying to do evil things):  https://blog.netspi.com/15-ways-to-bypass-the-powershell-execution-policy/

The one which was the easiest to implement for these specific needs was the "Bypassing in Script" one detailed here:
http://www.nivot.org/blog/post/2012/02/10/Bypassing-Restricted-Execution-Policy-in-Code-or-in-Script

In response to this forum post:
https://social.technet.microsoft.com/Forums/systemcenter/en-US/55b1d256-f3fb-4296-a9e6-2241cc8d4d0d/sccm-report-google-chrome-extensions

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.

Caveats: 
"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:

 

 Counter   Name Version ProfilePath ScriptLastRan
 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>

Apparently the original article on this from years ago has disappeared; so here's the old info.  This was originally for Config2007; so it may be this won't work, or will have unknown results.  YOU will need to test it and confirm it does what you think you want it to do in your environment.

Reporting on the permissions applied to non-admin shares can also be queried using the attached. Using --> This Zip File <-- , that's a vbscript.  Either deploy it as a traditional old skool package/program/recurring advertisement, or leverage a Configuration Item to deploy that script . Set a recurring schedule for what makes sense in your environment.

To Be Imported into Default Client Settings, Hardware Inventory:

// <:[-<>>>>>>>>>>>Start>>-Share Permissions-<<Start<<<<<<<<<<<>=]:>

#pragma namespace("\\\\.\\root\\cimv2\\sms")
[SMS_Report(TRUE), SMS_Group_Name("Share Permissions"), SMS_Class_ID("SMS_SharePerms")]
class SMS_SharePerms : SMS_Class_Template
{
[SMS_Report(FALSE), Key] uint32 Counter;
[SMS_Report(TRUE)] boolean Allowed;
[SMS_Report(TRUE)] string ShareName;
[SMS_Report(TRUE)] string Type;
[SMS_Report(TRUE)] string Domain;
[SMS_Report(TRUE)] string TrusteeName;
};
// <:[-<>>>>>>>>>>>End>>-Share Permissions-<<END<<<<<<<<<<<<<>=]:>

Notes:
Allowed = True means the Domain/TrusteeName is granted access of Type to the ShareName
Allowed = False means the Domain/TrusteeName is denied access of Type to the ShareName

You'd write reports against the new v_gs_share_permissions0

Currently, the vbscript is limited to 500 share instances. That could be increased by editing line 78, the DIM statements.

By design, share permissions for default shares will not be reported.

Just to be clear, this routine is for Share Permissions: Read, Change, Full. This is not for NTFS permissions on files/folders contained in those shares.

Note that this routine has only had a very brief life so far in a lab environment. There may be unforeseen problems with the script.

This is an update to this older blog: http://mnscug.org/blogs/sherry-kissinger/422-dot-net-frameworks-mof-edit

Nash Pherson, Enterprise Client Management MVP, pointed out that for versions 4.5x and higher Microsoft is recommending using the dword registry key called "release" to better pinpoint what version of .net is installed. Because "buildNumber" in the registry will say something like "4.5.51209"--but what it MEANS is that's version 4.5.2 (don't ask me why, I don't get it either).

Unfortunately, "Release" also isn't in nice, plain English. I couldn't find anything "easy" to make using BuildNumber any more or less useful than using "Release" number. But if you want to do exactly what Microsoft tells you to use, attached are updated mof edits for reporting on .net versions. The only thing added to this is "release"; which is only applicable to .net 4.5 and higher (well, up to 4.6.1 as far as I can tell; maybe it'll still be there in newer versions as those are released, but for now, that's all I can see)

If you already have the DotNetFramework edits, you replace your existing snippet for DotNetFrameworks in your configuration.mof with the configuration.mof edit in --> This Zip File <--   If you've never edited your \inboxes\clifiles.src\hinv\configuration.mof for dotNetFrameworks yet, you will add that attached snippet to the bottom of that file. Monitor your 'dataldr.log' to confirm all is well.

Once configuration.mof is edited, you take the attached "to-be-imported-dot-net.mof" and in your CM console, Administration, Client Settings, right-click on "Default Client Settings", Properties, Hardware Inventory, "Set Classes..." then Import that to-be-imported-dot-net.mof file. If you already have one from previously, not to worry. It'll just accept the new one and modify your tables and views. Just monitor your dataldr.log to confirm all is well.
Then, of course, it's the typical waiting that one does in ConfigMgr. Just wait a while; how long depends upon how often you have hardware inventory configured to run; the # of clients you have, and other factors unique to your environment. But in a couple hours or by the next day, try running one of the reports in the attached .zip file.

Regardless of whether you have the "old" DotNetFrameworks mof edit (which doesn't have release) or are using this new one, attached in the .zip file are also some sample reports. With versions of .net 4.0-4.5.1 no longer under support, your organization may be under hightened awareness of finding and upgrading anyone with those older versions to the supported versions. For example, below is what a report might look like, using 2 of the SQL queries attached. The top one is the results of the 'SQLtoCountDotNetVersions', and bottom one would be the 'SQLToShowVersionsInYourDatabase' -- what values you have in your database will vary from company to company.

 dotnetSampleReport

Geek notes: the "how to tell what .net is installed", came from two different Microsoft articles.
As I write this blog, this covers from .net 1.0 through .net 4.6.1
For V1-4: http://social.technet.microsoft.com/wiki/contents/articles/15601.how-to-determine-the-net-framework-installed-versions.aspx
For v4-4.61: https://msdn.microsoft.com/en-us/library/hh925568(v=vs.110).aspx