Adobe was one of the first vendors adopting swidtags and appeared a “best practice” company for application recognition… Acrobat is however one of the most challenging applications to recognize and Flexera has made a number of adjustments to address a number of issues related to the way Acrobat is deployed that turned into big variations in your installation applications counts.
Each change was announced or discussed in community posts, but here is the summarized view so that you understand the full picture.
Context: Flexera uses all possible means to recognize application, particularly when they are complex and hard to track
- Acrobat is high in the category:
- Two editions (standard, pro),
- Two distributions (continuous, classic)
- Multiple ways of being installed (download (that can be upgraded from 2021 from reader (free) to full (“Acrobat DC”) just by paying an online subscription
- Not all customers use the same inventory tools
- Desktops are often covered by SCCM that natively will collect only installer and file evidence. Any knowledge sharing is welcome on how to extend SCCM collection (swidtags, registry keys as this is the case with SQL Server editions). Flexera will be happy to publish a KB article on how to extend SCCM capabilities and extend its integration to collect additional data for enhanced recognition
- The FlexNet agent can collect swidtags (as file names) but also parses the swidtag files to create WMI evidence (“FLX_Adobe” class)
- As a consequence ARL mixes the following approaches
- Installer evidence (when they provide enough information)
- File evidence
- Executables: acrobat.exe for usage (Limited information on the application)
- V6{}AcrobatPro-AS2-Win-GM%.swidtag for Acrobat XI Pro
- WMI evidences: obtained by parsing the swidtag file. Combined values are required
- For instance, for Acrobat DC Continuous Pro 2022: FLX_Adobe SWIDTAG_Product_Version = 22.%.20% + FLX_Adobe SWIDTAG_Product_Title = Adobe Acrobat + FLX_Adobe SWIDTAG_Serial_Number = 9707% + FLX_Adobe SWIDTAG_Activation_Status = activated
A number of challenges have been faced recently
- First challenge Acrobat Reader showing as Acrobat DC for downloaded versions (Acrobat DC 2020 onwards)
- Thousands of Acrobat DC have started to report for customers who are using Acrobat Reader from downloads
- ARL has remapped Acrobat DC installer evidence to Acrobat readers (In May)
- This means you need swidtags to recognize correctly
- Second challenge: The way an application is deployed influences the add / remove program evidence.
- If you package the Acrobat DC, the evidence will look exactly like what they were in 2020 and will be different between Acrobat Reader and Acrobat DC. This is your situation.
- If you download Acrobat Reader (this is the case on my computer, like I showed)
- Add/Remove program name is named “Acrobat DC”.
- The 50 000 Acrobat Reader (without the change in the ARL being performed) in a company will be reported as Acrobat DC. Hence a numerous escalation.
- Acrobat Reader will probably be over recognized with the fix I did (by 8000 installations), because the signatures are linked to two applications (hence the “Overlapping” evidence warning).
- The ARL is going to map back to Acrobat DC but will ignore the evidence on July 8th
- If we associate Acrobat DC back to acrobat DC applications, we will have again tens of escalations. As there is no way to anticipate how customers have packaged their Acrobat DC application, we could associate Acrobat DC evidence with the Acrobat DC application (like I did for you) and ignore the evidence.
- Customers who want to use it (like you) will in a click activate the link (set back to "ignored = No", the next ARL imports will not re-ignore the evidence)
- Others will carefully keep the evidence ignored.
- Third challenge: Some swidtag files such as: V6{}AcrobatPro-AS2-Win-GM%.swidtag are shared between versions of Acrobat.
- The ARL has combined files for recognition (May, for Acrobat XI Pro): for instance Acrobat.exe 10.% required along with V6{}AcrobatPro-AS2-Win-GM%.swidtag to recognize Acrobat XI and avoid false positives of older versions
Some enhancements / fixes have happened in parallel
- WMI coverage for Acrobat DC Pro Classic and continuous has been systematic for all versions to avoid gaps in WMI recognition (March)
- A fix has been applied quickly after a file has been set as “at least one” for Acrobat DC (2021) Continuous
All this has led to changes in the number of recognized applications, and we apologize for that. Situation is under control now, but things may evolve depending on your feedbacks.
Finally, there are investigations going on:
- Swidtags are not always reliable: there would be false positives after removal for instance.
- Flexera is investigating on how to catch registry keys (collected as WMI evidence) that may be more reliable.
The following article from Adobe gives precious information on the recognition across versions.
https://www.adobe.com/devnet-docs/acrobatetk/tools/AdminGuide/identify.html
A section deserves special attention (no more LEIDs and SWID tags for the common installer from 2021 onwards):
64-bit Acrobat Pro vs. Standard
Both the LEID & SWID tag identification methods are not applicable to the Acrobat 64-bit unified installer initially released in Feb. of 2021. To distinguish between Standard and Pro installations, ID the install via the registry:
#. Go to Computer\HKEY_CURRENT_USER\Software\Adobe\Adobe Acrobat\DC\AVEntitlement\iEntitlementLevel # ID the install:
- 300: Acrobat Pro
- 200: Acrobat Standard
