Setting Up the Microsoft Purview Information Protection Scanner

Sensitivity labels do nothing for the data they never touch. Every hybrid organization I've worked with has a file share or a SharePoint Server farm sitting quietly outside the reach of cloud-native labeling — and that's exactly what the Microsoft Purview Information Protection scanner is built to close.

Use Case

A client had a mature sensitivity label taxonomy across Microsoft 365, but a decade of finance, HR, and legal documents were still parked on an on-premises file server that nobody in security had properly inventoried. They needed to find out what was sitting there, classify it, and eventually protect it — without a manual file-by-file review.

Solution

The Purview Information Protection scanner (formerly the Azure Information Protection unified labeling scanner) runs as a Windows service that crawls SMB file shares and SharePoint Server document libraries, inspects file content against your sensitivity labels' auto-labeling conditions, and can apply classification and protection automatically. Critically, it has a discovery mode that reports on what would happen before you let it touch a single file — that's where every rollout should start.

Prerequisites

• A dedicated Windows Server (2016 or later) to run the scanner service — don't share it with unrelated workloads.
• A SQL Server instance (SQL Express is fine for small deployments) to host the scanner's configuration and operational database.
• A service account that is synchronized to Microsoft Entra ID, with read access to every repository you'll scan, and modify access wherever you want labels actually applied. For SharePoint Server, that means Full Control on the target site.
• That service account should not be granted "Log on locally," and if you need it to scan already-encrypted files, it must be configured as a Rights Management super user.
• At least one sensitivity label published with auto-labeling conditions — the scanner has nothing to act on otherwise.
• An Entra app registration (App ID + secret) so the scanner can authenticate non-interactively via Set-Authentication.

Implementation

1) Install the client and the scanner service

Install the full Microsoft Purview Information Protection client on the scanner server — not just the PowerShell module, the scanner needs the complete client. Then install the scanner service itself:

Install-Scanner -SqlServerInstance SCANNER01\SQLEXPRESS -Cluster "EU-Scanner"

This creates a Windows service named Information Protection Scanner and provisions a database on your SQL Server instance to store the scanner's configuration.

2) Authenticate the scanner

Before the scanner can do anything, it needs to sign in as the delegated service account, using your app registration values:

$cred = Get-Credential  // sign in as the scanner service account
Set-Authentication -AppId <app-id> -AppSecret <app-secret> -TenantId <tenant-id> -OnBehalfOf $cred

This downloads the labeling policy assigned to that account and stores the token the scanner will use going forward.

3) Configure a content scan job

1. In the Microsoft Purview portal, go to Information protection scanner → Content scan jobs and create a new job under your cluster.
2. Add your repositories — UNC paths for file shares, or site URLs for SharePoint Server.
3. Set Info types to be discovered to All, so the scanner has full visibility during the first pass.
4. Leave Enforce set to Off. This is the whole point of discovery mode — the scanner reports on classification without changing a single file.

4) Run discovery and read the reports

1. Start the first scan from the portal (Scan now) or with Start-Scan in PowerShell.
2. Monitor progress with Get-ScanStatus, or refresh the Content scan jobs pane until you see a completion time.
3. Review the generated reports under %localappdata%\Microsoft\MSIP\Scanner\Reports — a summary, a detailed CSV of every file, the sensitive info types found, and the label each file would receive.
4. Use those reports to sanity-check your label conditions before you trust the scanner with write access. It's common to find a noisy sensitive-information-type match on the first pass — tune the condition, don't just accept it.

Mode	What happens	When to use it
Discovery (Enforce: Off)	Reports what would be labeled — no files are changed	Every new repository, always first
Enforce: On	Applies the matching label, and protection if configured	Once discovery reports look correct

5) Flip to enforce mode

Once the discovery reports match your expectations, edit the content scan job and set Enforce to On, then run the scan again. The first cycle inspects every file in the repository; after that, the scanner runs an incremental delta scan and only re-inspects new or changed files — which is why the initial full pass is worth doing carefully.

Bonus: DLP on the same scanner

If you also want Purview DLP policies to evaluate on-premises content, the scanner doubles as the DLP enforcement point for these repositories. Enable DLP rules on the same content scan job (again, start with Enforce off), and matches will show up in Activity explorer alongside your cloud DLP data — one place to review exposure across both environments.

Related reading

Once your on-prem estate is labeled, it feeds the same posture picture covered in Microsoft Purview DSPM, and pairs naturally with closing the same kind of gap in SharePoint Online covered in auto-labeling data at rest.