cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Evidence for Adobe Acrobat DC and Adobe Acrobat Reader DC

Due to changes FlexNet/Flexera One has no way of telling Adobe Acrobat DC (subscription) and Adobe Acrobat Reader DC (freeware) a part when the information comes in from the discovery tool. Reference the ticket submitted to Flexera below:

______________________________________________________________________________________________

Hello Jim,

Please find below a comment from our Product team on this case.

Thanks for submitting this ticket and sorry for the inconvenience…

The recent change in ARL should lead an SCCM customer to not recognize any Acrobat DC 2021 and 2022, as the installer evidences are now only mapped to Acrobat Reader (Freeware).

There is, unfortunately, no solution today for an SCCM customer for differentiating today Acrobat Reader and Acrobat DC… and this is not a Flexera recognition issue but more an Adobe packaging issue. Or maybe, if you find how differentiation can happen from file or installer evidences (only ones collected by SCCM), we can tweak our recognition.

At this stage, the only way customers can recognize Acrobat is to use swidtags… or registry keys… and SCCM cannot do this. If you know that SCCM collects this type of information and stores it in specific tables, we may extend our data collection… but we see no solution at this stage.

______________________________________________________________________________________________

Does anyone out there have an alternate solution(s) to track Adobe Acrobat DC applications from Adobe Acrobat Reader DC applications?

 

Thanks,

Jim

(5) Replies

You can blame Adobe for their lack of following standard packaging conventions.

Adobe has created a "universal" 64-bit install package for Acrobat, that includes both Acrobat Reader and full Acrobat.  When you look at an Add/Remove Program Name or the main EXE, there is now no difference in what you see.  For example, previously an install of Acrobat Reader would have a primary EXE Name of ACRORD32.EXE, and would have an Add/Remove Program Name similar to "Adobe Acrobat Reader DC"

With the new 64-bit universal installer, you will now see the following evidence when Acrobat Reader 64-bit is installed:
1) Main exe file name is ACROBAT.EXE
2) Add/Remove Program Name is "Adobe Acrobat DC"

mfranz
By Level 17 Champion
Level 17 Champion

If SCCM is used for deployment, have a look at your collection data. There should be multiple collections for different applications. This info could be used to create a new evidence (rather complex) or be the basis for a business import doing allocations (less complext).

In essence, this solution can be utilized only if the Adobe products are deployed using SCCM?
Or am i missing something here?

Also further, assuming we would get the required data from SCCM, how do we map them to the version on evidence side in FNMS, they would still be showing mix of evidence for all acrobat versions in the current setup?  

The only way we solved this problem was to push out the Flexera agent. It was actually a huge driver in us finally getting the agent approved to be installed. Thanks to Adobe we now have the agent out there collecting this information for us. 

Erick Hacking, CSAM, CHAMP
IT Software Asset Manager, Lead Sr.
ChrisG
By Community Manager Community Manager
Community Manager

I'm adding a note here to ensure people see the following post for some current further discussion related to this topic: Content Change Notification: Change in the recognition rules for Adobe Acrobat DC

(Did my reply solve the question? Click "ACCEPT AS SOLUTION" to help others find answers faster. Liked something? Click "KUDO". Anything expressed here is my own view and not necessarily that of my employer, Flexera.)