AdeyinkaA
Summary
Recently a major concern was raised with Adobe where both Adobe Reader and Acrobat DC leave the same footprint in Add/Remove programs in the form of installer evidence. This causes multiple false positives to be flagged in customer environments, leading to incorrect consumption/recognition.
Flexera has made multiple adjustments to address several issues related to the way Acrobat is deployed, that have caused variations in customers’ application installation counts. Each change is announced or discussed in community posts, and here we hope to provide our summarized view of the issue. We also provide alternatives/workarounds to help resolve this issue with Adobe.
Context
Adobe has recently made changes to its evidence footprint in such a way that Acrobat Reader and Acrobat DC share the same installer evidence. This means that the current evidence gathered for the two products is not enough to determine whether the installed product is freeware or commercial.
Flexera Community post on this topic [1] - https://community.flexera.com/t5/FlexNet-Manager-Knowledge-Base/Adobe-Acrobat-Reader-DC-Freeware-vs-Commercial-Edition/ta-p/226650
Flexera has implemented enhancements to the Flexera Agent to help retrieve Swidtag information represented as WMI evidence (of the FLX_Adobe class) to differentiate the two products.
In our recent ARL release (End Q1, 22), we have unlinked and remapped Acrobat DC installer evidence to Acrobat Reader. We then use the WMI evidence to differentiate Acrobat DC installs.
Community discussion on this topic [2] - https://community.flexera.com/t5/FlexNet-Manager-Forum/Acrobat-Reader-DC-detected-as-Acrobat-DC/td-p/227992
Consequences
- When Acrobat DC is installed Acrobat Reader may be recognized. This should not fundamentally be an issue as Acrobat Reader is freeware and will not affect consumption.
- For customers not using the Agent (typically SCCM inventory), Acrobat DC will no longer be recognized. This will mitigate incorrect recognition of the application.
Unfortunately, we do not currently have a workaround to differentiate the two products on a system that does not deploy the Flexera Agent because systems like SCCM do not collect Swidtag information (only File and Installer evidence). We would welcome any knowledge shared on how to extend SCCM collection (swidtags, registry keys as is the case with SQL Server editions) and are working to acquire more data on this process that we can publish as a KB article in extending SCCM capabilities. - An issue raised by some customers is that depending on the packaging, Acrobat DC installer evidence may still be different from the Acrobat Reader installer evidence.
Flexera community discussion on this topic [3]- https://community.flexera.com/t5/FlexNet-Manager-Forum/Evidence-for-Adobe-Acrobat-DC-and-Adobe-Acrobat-Reader-DC/td-p/237567
As a result of these changes, there might be a skew in the number of recognized applications in customer environments.
Next Steps / Workaround
- For those customers who want to recognize Adobe Acrobat DC with this evidence, they can link the evidence linked to Acrobat Reader to Acrobat DC. There will be an “overlapping evidence” warning that can be ignored… and the Acrobat DC recognition will be re-activated.
Go To Acrobat DC 2021 Application detail, on Evidence / Installer, filter on Acrobat DC 21., Ignored = No, Publisher = Adobe, don’t include the evidence with editions.
You need to do this from Acrobat DC (2022) too.
Click on “Add Evidence”.
However, those customers who do not need the changes can keep the status as “Ignored” and no further action is required.
Please note that the new ARL import/update will not ‘overwrite’ the Ignored status if the changes were made locally.
- There is an ongoing investigation on using swidtags for Adobe Acrobat recognition. Swidtags are not always reliable because of the possibility of false positives after removal for instance. Flexera is investigating different options to capture registry keys (collected as WMI evidence) that may have a more reliable footprint. Please refer to the article listed here. [4] https://www.adobe.com/devnet-docs/acrobatetk/tools/AdminGuide/identify.html
Customers who are using SCCM as an inventory tool can “re activate” the Acrobat DC installer evidence if their packaging leads to differentiated installer evidence.
For a more detailed explanation of the Adobe issue so far, here is an article posted by our product manager Nicolas Rossueau who is working closely on this topic -
[5] https://community.flexera.com/t5/FlexNet-Manager-Knowledge-Base/Challenges-identifying-installations-of-Adobe-Acrobat-and-how/ta-p/241207
We appreciate any feedback and input from customers which can help in expanding Adobe Acrobat and Reader recognition capabilities.
[4] https://www.adobe.com/devnet-docs/acrobatetk/tools/AdminGuide/identify.html
