Update to an older blog entry...

http://www1.myitforum.com/2012/06/13/gather-some-adobe-software-serial-numbers-using-configmgr-dcm-and-hardware- inventory/ :

Because this thread: http://social.technet.microsoft.com/Forums/en-US/configmgrinventory/thread/7243fac9-36c4- 4d1f-9b2b-eb1b2f53ed87, got me thinking about it, I went to the adobe blog entry they referenced, here: http://blogs.adobe.com/oobe/2009/11/software_tagging_in_adobe_prod_1.html

Searched our lab for a couple of clients with full Adobe products, and low and behold… found the .swtag files mentioned. Interestingly, that blog was a little misleading–it didn’t seem to cover some of the tags that are really in the .swtag files for serial number, version, etc… so I doubt the script (attached) will actually find everything. but it’s a start; so I thought I’d throw this out into the wild (blog it) and see what others can make of it.

Attached is a script, which you’d run similar to the "all members of all local groups" type of thing–run it on clients (either as a recurring advertisement or as a DCM ConfigItem, with no validation), and the sms_def.mof edit to pull the info back into your DB. Some of what it returns you’ll already have from ARP (name, version), but the golden nuggets of info are the SerialNumber, and whether it’s part of a Suite (according to that blog, anyway). There’s also something about "licensedState", but one of my test boxes had a serial number, but said it was unlicensed. Not sure what that is really about–that the human didn’t click on something after launching to register online? Not sure. But hey, that field is there if it means anything. You could always set that to FALSE in the mof if that LicenseState information is pointless.

What was nice about the above routine was that in the "partofasuite" returned results, it would say "Std" or "Pro" right in there, so that when the licensing folk would come knocking and ask for your pro vs std counts, it was relatively easy to run a report, and show them exactly what you had out there, based on Adobe's own information. With the "DC" version, they've apparently decided to make it even MORE difficult to tell the difference between Pro vs. Std.

Here's a new link to their swid tag information: http://www.adobe.com/devnet-docs/acrobatetk/tools/AdminGuide/identify.html

Fortunately, the Script + Mof edit will pull back all of the information necessary to tell the difference, it just makes reports more, uh... "fun"


and basically you'll see that that std, the serial numbers start with 9101 and for pro, the serial numbers start with 9707

Here's a sample report, once you've created the ConfigItem and Baseline, deployed it, and imported the mof snippet into inventory, and start getting back results:

This sample report is ONLY for Acrobat, there are other Adobe products returned with the AdobeInfo routine, so this is just a sample report, it's not meant to showcase everything returned.

;with cte as (
Select distinct resourceid, Case when a.SerialNumber0 like '9101%' then 'Std'
when a.SerialNumber like '9707%' then 'Pro' end as 'Type',
Case when a.PartOfASuite0 like 'v7%' then 'DC'
when a.PartOfASuite0 like 'v6%' then '11'
when a.PartOfASuite0 like 'Acrobat%' then '10' end as 'Version'
from v_gs_AdobeInfo0
where a.PartOfASuite0 like 'v%{}Acrobat%' or a.PartOfASuite0 like 'Acrobat%'
select cte.version as [Acrobat Version] , cte.type as [Acrobat Type] ,count(*) as 'Count'
from cte group by [version], [type]
order by [version], [type]
would result in something sorta like this (#'s have been changed from my production environment to fake #'s)
Acrobat Version Acrobat Type Count
10                    Pro                20
10                    Std                15
11                    Pro                300
11                     Std               210
DC                   Pro                700
DC                   Std                800
Of course, the best part of this routine is *if* Adobe comes knocking, you can show them that the information about pro vs. std originates from their SWID tag files, and you can point to their web site about how to tell the difference, so they should be satisfied and quickly leave you alone (unless, of course... you did deploy Pro to all of your environment, and you thought you were deploying Standard... well, then... pay up...)

--> Link --< to get the mof file for importing for ConfigMgr Inventory, and the script to add to a Configuration Item (or you could deploy it as a recurring Advertisement, if you are adverse to Configuration Baselines).  Basically, the client, on a recurring basis, needs to run the script to populate--or wipe and re-populate--the custom WMI location with the Adobe swid tag information.

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.

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:

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


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.

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.