Forum Discussion
MicrosoftApplication filter in the activity explorer no longer populated correctly?
To distinguish between discovery findings in a setup that has both endpoint DLP and the Information Protection Scanner deployed, typically the "Application" filter in the activity explorer is used:
It seems that recently the filter behavior changed and the list of applications the filter can use is built incorrectly. 'Microsoft Purview Information Protection Scanner' is no longer listed although documents with that property are present:
The filter options are typically populated by the properties from documents within range and I have verified documents discovered by the MIP scanner exist:
I am wondering if more people are seeing this and if a possible workaround is available.
2 Replies
Application filter in Activity Explorer no longer correctly lists the entry for the Microsoft Purview Information Protection Scanner, and it is still an open service-side issue. The change originated from an internal schema update that consolidated telemetry from endpoint DLP, service DLP, and on-premises Information Protection Scanners into a unified signal pipeline within Microsoft Purview.
In this updated schema, the field that populates the “Application” dropdown in Activity Explorer now only displays executable-level telemetry captured from endpoint sources such as explorer.exe, winword.exe, and msedge.exe. The scanner, which used to report its activities under the friendly name “Microsoft Purview Information Protection Scanner,” now logs its activity under the system agent identifier ScannerJobAgent or MIPScannerService. These identifiers are processed in the back end but no longer appear in the Application filter’s user interface. This means that even though your scanner continues to scan and label content correctly, its discovery activity is not represented in the Application filter view. In the meantime, the current workaround is to use the Advanced filter or export your Activity Explorer data using the Purview Audit (Advanced) or Data Classification Export API. When you export the data, search for events where the Source, Actor, or Service field contains ScannerJobAgent, MIPScanner, or InformationProtectionScanner. These values identify events triggered by the on-premises scanner. Another option is to filter by repository type, as scanner discoveries typically appear under UNC paths or SharePoint document libraries, making them easier to distinguish from endpoint-based file activities.
Hit Like if you like the solution.
François van HemertThank you for the detailed explanation, it confirms my suspicion a product update/change has created this issue.
With respect to the suggested workaround "Advanced filter". As I understand the advanced filtering is based on exporting the results to a CSV file and applying filters in for example Excel to filter out the entries created by the MIPscanner. This workaround will work and is quite easy because the Application property is populated correctly with "Microsoft Purview Information Protection Scanner"
However, this approach introduces multiple additional steps and requires manually creating graphs in Excel, which somewhat diminishes the intended value of Activity Explorer
For now, I will recommend using either Device name or User as a filter in Activity Explorer.
If the MIP Scanner was installed with a unique service account, the User filter alone should be sufficient to generate accurate results. However, if the same service account is shared across multiple scanners, adding the Device name filter will ensure proper differentiation.
This leaves one unresolved issue: every file discovered by the MIP Scanner appears twice in Activity Explorer. The problem is that the two records are completely identical except for the Record identity, making it impossible to filter for a single entry per discovery. As a result, Activity Explorer always displays double the actual number of discovered files.
