AND iw.PropertyName = 'SWIDTAG_Product_Version' LEFT JOIN ImportedWMIEvidence iw on iw.ExternalEvidenceID = iiw.ExternalEvidenceID EXISTS (SELECT * from importedInstalledWMIEvidence iiw INNER JOIN ImportedWMIEvidence iwm WITH (NOLOCK) on iwm.ExternalEvidenceID = iiwm.ExternalEvidenceIDĪND iwm.ComplianceConnectionID = iiwm.ComplianceConnectionID LEFT JOIN ImportedInstalledWMIEvidence iiwm WITH (NOLOCK) on iiwm.ExternalComputerID = ic.ExternalIDĪND iiwm.ComplianceConnectionID = ic.ComplianceConnectionID SELECT ic.ComputerName, iwm.*, ic.ComplianceComputerID, ic.ExternalID FROM ImportedComputer ic WITH (NOLOCK) The issue is that you can't make WMI evidences clever (for instance 21.%.20%), unless inserting them in the database. So, you could theoretically ignore the add / remove evidence and add the WMI. You are right Acrobat reader as a common add / remove program evidence, but no WMI. Can you confirm this? I can verify this with other customers.

You can run the query below (you can uncomment to get only the computers where 2021 Continuous Pro exists but performance is poor) and hopefully will see many records.

Hello The agent collects WMI evidences, even if there are not mapped to applications by the ARL. The first test look encouraging on our side. I would prefer we use the existing WMI evidences collected from the SWIDTags than change the agent to collect a new registry entry (by the way, thanks for your investigation, I had found the IsAcrInstalledInRdrMode in the same node but the key you provide looks good!).ĭo you see the WMI patterns I show below. Our plan is to stop using the ambiguous add/remove program evidence from Acrobat DC, add it to Acrobat Reader, and enhance the WMI evidences we use for Acrobat DC (Created from the SWIDTags that have not been systematically managed in the last versions), with the patterns below. Indeed, having Acrobat Reader and writer sharing the same add / remove is just a pain.

Reader dc