This ask came up recently, so I did a bit of research.  It is NOT, I repeat NOT perfect, and NOT complete.  I did NOT include all of the possible "Team" editions for Visual Studio 2005 or Visual Studio 2008. But for Visual Studio 2010, 2012, 2013, and (I think) 2015, the editions should be reported correctly. If you want to (need to) add in all of the potential "team" editions for Visual Studio 2005/2008, you can use this as a guide and add in all the additional columns for those.

If you're familiar with the "DotNetFrameworks" mof edits, it's similar to that type of MOF edit.  --> attached <--, are what you would add to the bottom of your configuration.mof file in <installed location>\inboxes\clifiles.src\hinv, and the snippet you would import into your "Default Client Settings", hardware inventory, and then enable, or create a custom client agent setting to enable it only to a specific collection of machines.

Using a sql query like this, you can then pull out the "highest" Edition.

select
sys1.netbios_name0 as 'computername',
vised.version0 as 'Visual Studio Version',
case when vised.ultimate0 = 1 then 'Ultimate'
  when vised.Enterprise0 = 1 then 'Enterprise'
  when vised.Premium0 = 1 then 'Premium'
  when vised.Professional0 = 1 then 'Professional'
  when vised.Community0 = 1 then 'Community' end as 'Highest Edition Installed'
from v_gs_visualstudioeditions0 vised
join v_r_system sys1 on sys1.resourceid=vised.resourceid
where ( vised.professional0 is not null or vised.premium0 is not null or
        vised.ultimate0 is not null or vised.standard0 is not null or
        vised.community0 is not null or vised.enterprise0 is not null
)
and vised.version0 in ('2005','2008','2010','2012','2013','2015')
order by sys1.computername, vised.version0

which could help you make a report like that could look like this. Computer names have been changed, but note that Computer3 and Computer5 have two versions of Visual Studio, and then their editions:
VisualStudioEditions

Sources for where I got these regkeys:

for Visual Studio 2005: http://blogs.msdn.com/b/heaths/archive/2006/12/17/detecting-visual-studio-2005-service-pack-1.aspx
  There may be more subkeys for Team System, but I didn't grab them..
for Visual Studio 2008: http://blogs.msdn.com/b/heaths/archive/2009/05/29/detecting-visual-studio-2008-service-pack-1.aspx
   There's a WHOLE bunch of VSDB, VSTA, VSTD, VSTS, VSTT for all the team System 2008 editions
for Visual Studio 2010: http://blogs.msdn.com/b/heaths/archive/2010/05/04/detection-keys-for-net-framework-4-0-and-visual-studio-2010.aspx
    Note, Ultimate replaces Team Suite
for Visual Studio 2012: http://blogs.msdn.com/b/heaths/archive/2012/08/03/detection-keys-for-visual-studio-2012.aspx
for Visual Studio 2013: Couldn't find a direct link, but found a note that there's Professional, Premium, and Ultimate, so guessing it's these. And data comes back from clients, so appears to work.
for Visual Studio 2015: http://blogs.msdn.com/b/heaths/archive/2015/04/13/detection-keys-for-visual-studio-2015.aspx
   Note, Enterprise replaces premium and ultimate

 

Issue:  After upgrading Configmgr 2012 R2 CU4 clients to ConfigMgr 2012 R2 SP1 clients, some, but not all, clients started having issues downloading content.  It seemed to only happen on clients which just so happened to be our Management Points, or our Software Update Points, so likely this particular error won't be seen much.  But in looking for the keywords of "error creating CTM job", where the error code was 0x80070003, there wasn't anything I could find via any popular search engine. 

Symptoms:  In those clients' local ContentTransferManager.log if you didn't have debuglogging enabled, it was simply this error, repeated every time a download request was attempted:

Error creating CTM job (0x80070003)

If one turned on debuglogging, you got a little bit more information, but not much:

In CContentTransferManager::DownloadContentEx7 Directory::Exists(szDestPath), HRESULT=80070003 (e:\nts_sccm_release\sms\framework\ccmctm\ctmanager.cpp,390) Error creating CTM job (0x80070003)

In those clients' local CAS.log, you'd see this error:

CcmContentTransferManager:DownloadContent failed with error 0x80070003

Diagnosis:  80070003, that error, is supposed to mean something like "the system cannot find the path specified".  We wondered if it was because many of these clients happened to be Management Points, so their installed location for the CM Client wasn't %windir%\ccm, but was <drive letter>:\SMS_CCM.  But that didn't make sense, only some of them were like that, others were in %windir%\ccm.  What it ended up being was a confused (or corrupt) ccmcache folder.

Fix:  Since this is about downloading into cache, and 8007003 is supposed to mean "can't find the path", we moved the location of ccmcache, temporarily (using the Control Panel applet).  What is "supposed" to happen is that when you do that, the former location should be automatically deleted.  That did NOT happen--so clearly something was messed up with it.  Deleted the old location manually, and then put the cache location RIGHT BACK to the normal cache location.  And then content can download.

Symptoms: Clients reinstall the ConfigMgr Client on a daily basis, and it doesn't appear that any automated push, automated deployment, or technician is reinstallng the client. In the %windir%\ccmsetup log, the reinstall is successful (exit code of 0) but yet the client reinstalls over and over again, seemingly automatically.

Cause: At some point in time in the client's past, a scheduled task called "Configuration Manager Client Retry Task", was created on purpose to retry a failed client install. However, once the client was successfully installed, that scheduled task was not (for some reason), and is not, being removed. No matter how many times the client reinstalls successfully.

Fix: Manually, go look at scheduled tasks, and delete that task. Automatically, you can import the attached Configuration Item --> Here <--, and deploy it (by adding it to a Baseline, and deploying that Baseline with the checkbox to allow remediation) to find and remove the scheduled task.

This Configuration Item may not be the best answer for your environment; it's up to you to determine if this Configuration Item is required, and to which collection of machines you want to target.  One suggestion could be to create a collection of "clients with the latest version in your environment (whatever that is)". The theory being that if those clients have the latest version, if they are a healthy enough client to find the policy for this baseline deployment, and they are already the latest client version--why retry reinstalling the CM Client? It's clearly installed and working... so... the SchTask clearly isn't actually needed, if it's there.  Of course, YOU will need to remember to change the collection's query whenever your client version increments; so that you are targeting the correct clients; for your environment.

Have you ever noticed, and been confused by, why sometimes, for some new client installations of the ConfigMgr 12 client, it seems like Hardware Inventory, the very first one, takes forever to trigger naturally?  That's by design.

There's something called "Inventory Max Random Delay", which is a setting you can modify--just not via the console.  My understanding of what it is for is to randomize when, for example, someone uses client push to say... their entire, newly discovered, every single system discovered in AD.  It's so that there isn't a flood of full inventory within 10 minutes in those cases.  Of course, if you're a mature installation--it's unlikely that you'll have that.  By default it is 240 minutes (4 hours)--at my company we've changed ours to 60.  To see what it is set to, here's the SQL you'd run in SQL Server Management Studio against your cm_sitecode database, just to see what yours it set at: (view only, it changes nothing.)  Each primary will have it set. (If you are unlucky to have a CAS, it will have it as well; but a CAS has no clients so it's not really relevant; but for consistency may want to change it)

SELECT SD.SiteCode, SCC.ClientComponentName, SCP.Name, SCP.Value1, SCP.Value2, SCP.Value3 FROM SC_ClientComponent SCC JOIN SC_SiteDefinition SD ON SD.SiteNumber = SCC.SiteNumber JOIN SC_ClientComponent_Property SCP ON SCP.ClientComponentID = SCC.ID WHERE SCP.Name like '%Inventory Max Random Delay%'

  To adjust the Max Random Delay, you run the below as a vbscript, after modifying the SiteCode to match the one you are changing

You run it as cscript whatever.vbs YourPrimaryServerName The3CharSiteCode  (after changing the desiredvalue and sitecode inside).  For example, if my primary site server name was "CMPRIMARY" and it's site code was PR1, I'd confirm that the sitecode in the script said "PR1" (it does, how convenient for me!), and I'd run  cscript.exe whatever.vbs cmprimary pr1

If you have multiple primaries, you need to run it on each one--it's per sitecode.

'***********vbscript below******************
'NOTE! Be careful if in displaying this on a blog, the ' or " are converted to "smart quotes" !
'*******************************************

On Error Resume Next

'*** Define string variables for device, device Resource ID and user of interest

Class_Name = "SMS_SCI_ClientComp"
Class_ItemName = "Hardware Inventory Agent" ' "Software Inventory Agent" for SINV
Class_ItemType = "Client Component"
Property_Name = "Hardware Inventory Max Random Delay Minutes" ' "Software Inventory Max Random Delay Minutes" for SINV
Property_SiteCode = "PR1" ' Replace Site Code for Primary Site here
DesiredValue = 60 ' Desired Value in Minutes

'*** Check parameters - we need the provider server name and the site code

set args=wscript.arguments

If args.Count = 2 then
SMSProviderServer = UCASE(Wscript.Arguments(0))
SiteCode = UCASE(Wscript.Arguments(1))
Else
wscript.Echo "Incorrect command line arguments." & vbCrLf & "Usage: cscript /nologo ModifySCFProperty.vbs <smsproviderserver> <sitecode>" & vbCrLf & "Example: cscript /nologo ModifySCFProperty.vbs SERVER1 S01" & vbCrLf
WScript.Quit(1)
End If

'*** Connect to the provider - report the error and terminate on failure

SMSProviderServer = "\\" + SMSProviderServer + "\"
Set ObjSvc = GetObject("winmgmts:" & "{impersonationLevel=Impersonate,authenticationLevel=Pkt}!" & SMSProviderServer & "root\sms\site_" & SiteCode)

If Err.Number <> 0 Then
wscript.Echo "Failed to connect to provider server with code: " & Err.Number & ". Aborting!"
WScript.Quit(2)
End If

'*** Get the desired instance of the class

Set objInst = ObjSvc.Get(Class_Name & ".ItemName='" & Class_ItemName & "',ItemType='" & Class_ItemType & "',SiteCode='" & Property_SiteCode &"'")

If Err.Number <> 0 Then
WScript.Echo "Failed to open desired object with error code " & Err.Number & " (" & Err.Description & "). Aborting!"
WScript.Quit(3)
End If

'*** Loop through the Properties until we find a match or run out

bFoundProperty = False

For Each objProp in objInst.Props
If objProp.PropertyName = Property_Name Then
bFoundProperty = True
Exit For
End If
Next

If bFoundProperty = False Then
WScript.Echo "Desired object was found but property was not found. Exiting without making any changes."
WScript.Quit(4)
End If

'*** Property found so check to see if existing value matches desired, changing it as appropriate

If objProp.Value = DesiredValue Then
WScript.Echo "Property '" & Property_Name & "' found with desired value '" & DesiredValue & "'. Not making any changes."
WScript.Quit(0)
Else
OriginalValue = objProp.Value
objProp.Value = DesiredValue
objProp.Put_
objInst.Put_

If Err.Number <> 0 Then
wscript.Echo "Failed to save the desired change with code: " & Err.Number & ". Aborting!"
WScript.Quit(5)
Else
WScript.Echo "Property '" & Property_Name & "' successfully changed from '" & OriginalValue & "' to '" & DesiredValue & "'."
End If
End If