Thanks for posting to the Community.
Were you able to resolve this issue? Please share anything you deem useful with the Community, you might help someone with a similar question.
If I'm not mistaken, you may have to pull a "Custom vulnerability" trick here. Last I remember, it involved invoking some (machine local) commands around Adobe Acrobat / plowing through local config files and then having a case of "if it's THIS, it's PRO - if it's THAT - it's not" ... research on the Adobe pages would be needed.
This is (much to my chagrin) becoming a more and more common recourse that's necessary as software packages become even more of a mess of install & local licensing nonsense than they should be,
"Sure - we put down the exact same files & let your license file decide what it is." ... great - that makes keeping track of "who has what" so much more painful ... .
My knowledge on Adobe is a bit hazy, but if memory serves, that's how a fellow colleague had to attack that nonsense most recently at one of his accounts.
The "Vulscan ++ Custom Definitions" combo is the best way to pick up such local nonsense & then you have a choice of how you want to return that data (additional custom data fields, "just" vulscan data, etc.).
1 of 1 people found this helpful
The only way to determine which edition of Acrobat is installed (standard vs pro), is to check a SWID file. You can do this automatically if you have Data Analytics or you have to do it manually.
Here is a link that explains where to find this SWID file and how to identify which edition is installed: Identifying Existing Installs — Enterprise Administration Guide .
Hope this helps!