7.3 Bulk Classification with the Information Protection Scanner

What the scanner is—and what it is not

The Microsoft Purview Information Protection scanner is the on-premises crawl engine that ships in the same Windows client package as File Labeler. It runs as a Windows service on Windows Server, walks repositories you define, inspects files with IFilters, and can apply the same sensitivity labels the client would apply. Microsoft is explicit: the scanner does not discover and label in real time. It systematically crawls, on a cycle you set to run once or repeatedly.

Place it on UNC file shares and NAS that speak SMB, on NFS (preview), and on SharePoint Server document libraries and folders still in extended support (SharePoint Server Subscription Edition under Microsoft's current servicing policy). It is not Microsoft Defender for Cloud Apps (SaaS), not Purview Data Map (Azure data estate), and not SharePoint Online auto-labeling.

OneDrive locations, WebDav, and wildcard paths are not supported as repositories. A local path such as C:\Folder is valid for disks on the scanner server. A NAS should be added as \\Server\Folder. SharePoint examples use library URLs such as http://sharepoint.contoso.com/Shared%20Documents/Folder. Specifying only the farm FQDN can discover sites and subsites if the scanner account has Site Collector Auditor rights at farm level.

The scanner classifies and protects the same file types as the client. Files that cannot be inspected can still receive the default label from the label policy or from the scanner job. The scanner will not apply a classification-only label to types that do not support labels without encryption. By default it encrypts Office files plus PDF files that use ISO PDF encryption; add .txt and other types under Change which file types to protect when the scenario needs them.

SharePoint details that show up in operations: the scanner inspects the last published version. If content approval is required, the labeled file must be approved before users see it. Large libraries may need the list view threshold raised from SharePoint's default of 5,000. Paths longer than 260 characters need long-path support on the scanner operating system. Logs are under %localappdata%\Microsoft\MSIP\Logs\ (for example MSIPScanner.iplog). If SharePoint hardening exhausts ephemeral ports, scans can stop with a socket-reuse error; Microsoft also notes increasing dynamic ports in that case.

Clusters, SQL, nodes, and the service account

In the Microsoft Purview portal: Settings → Information Protection → Information protection scanner.

1. Create a cluster. The name identifies the configuration (for example Europe). You pass that name to Install-Scanner.
2. Create a content scan job and add repositories.
3. On each Windows Server node, install the full client, then install the scanner.

Install-Scanner -SqlServerInstance SQLSERVER1 -Cluster Europe

Named instance: SQLSERVER1\SCANNER. SQL Express: SQLSERVER1\SQLEXPRESS. At the credential prompt, enter the service account as DOMAIN\username, not a UPN. The installer uses that form to resolve the SID, grant Log on as a service, set the service Run As account, and grant SQL permissions. A UPN can produce identity-resolution or service-startup failures later.

The Windows service is named Microsoft Purview Information Protection Scanner. Install-Scanner creates a configuration database (documented name pattern AIPScannerUL_<cluster name>) and grants the service account db_owner. The account that runs install needs local administrator on the scanner server and Sysadmin on SQL unless you follow Microsoft's alternative procedure that creates the database manually.

You must have at least one sensitivity label configured for the scanner account—the account you pass as DelegatedUser to Set-Authentication. If labels have no auto-labeling conditions, Microsoft documents alternative job settings (default label on all files, or discovery of known information types) rather than pretending conditions exist.

SQL Server requirements:

• Local or remote instance. Microsoft recommends hosting SQL on a different machine from the scanner except in small deployments, and prefers a dedicated instance.
• Minimum SQL Server 2016 Enterprise, Standard, or Express.
• Express is recommended for test environments only.
• Collation must be case-insensitive.
• Multiple configuration databases on one SQL server are supported when each cluster has its own cluster name.

Microsoft's capacity starting point includes an example: about 2 GB of database disk to track 1 million files with ~250-byte names, plus a formula you are expected to test rather than treat as a hard cap. For the SQL host: up to 10 scanners → 4 cores and 8 GB RAM recommended; more than 10 scanners (maximum 40) → 8 cores and 16 GB RAM recommended. Treat 40 as Microsoft's published node-count guidance in that SQL sizing table, not as a secret file-count limit.

Scanner node hardware on the prereqs page: 4 cores, 8 GB RAM, about 10 GB free disk for temporary files (the scanner creates temporary files per scanned file, four files per core; 10 GB is framed as enough for 4 cores scanning 16 files of 625 MB each). Deploy multiple nodes with the same cluster name and the same database to scale out. A node belongs to one cluster. Installing the same machine into a second cluster name is how operators accidentally lose Scan now on the first job.

Service account requirements:

The account must be an Active Directory account synchronized to Microsoft Entra ID, unless you use Microsoft's documented alternative (offline) configurations. After install, get an Entra token with Set-Authentication (app ID, tenant, delegated user = scanner account). Microsoft documents token lifetime as one year, two years, or never, according to the Entra app registration's client secret. Certificate-based authentication exists as a public preview on 3.2.x clients—keep it labeled preview unless an item says otherwise.

Offline scanner servers use Set-ScannerConfiguration -OnlineConfiguration Off and PowerShell-only job cmdlets (Set-ScannerContentScan, Add-ScannerRepository). That is the alternative path, not the default.

Content scan jobs: discovery versus enforce

Microsoft's initial portal settings are deliberately safe:

Discovery / reporting-only is how you learn what would be labeled. The scanner still crawls; it writes reports. Nodes send status to the portal about every five minutes. The portal shows the last scan. Historical detail lives on the node in %localappdata%\Microsoft\MSIP\Scanner\Reports: summary .txt files (duration, file counts, information-type matches) and per-file .csv files. The folder stores up to 60 reports per scanning cycle; older reports are compressed. You cannot rename that folder; Microsoft's documented relocation method is a directory junction.

Start-Scan, Stop-Scan, and Get-ScanStatus are the PowerShell equivalents of Scan now and Stop scan. Scan now appears only when a node for that content scan job is online.

The first cycle inspects all files. Later cycles are incremental (new and modified files) unless you choose Rescan all files. After a full rescan completes, the job returns to incremental. If recommended labels never appear as applied, remember the scanner applies automatic classification; Microsoft tells you to use automatic (not merely recommended) conditions, or enable Treat recommended labeling as automatic where that scanner setting exists.

To move from report-only to protection: set Enforce sensitivity labeling policy to On, set schedule to Always, confirm a node is online, then Scan now. When the crawl finishes, it starts another cycle so new and changed files are picked up. That is still not real-time labeling.

Custom Reporting and cluster-level -FeatureSettings on Install-Scanner / Set-ScannerConfiguration are preview capabilities on 3.2.x. The Microsoft Purview portal takes precedence when the same feature is exposed there.

DLP on-premises repositories depend on this scanner

Microsoft Purview DLP On-premises repositories is not a second agent. DLP relies on a full implementation of the Information Protection scanner. If the scanner is not implemented, you cannot use that DLP location. Enable DLP rules on the content scan job. Turning that switch on when no DLP policy exists causes scanner errors. Set a repository owner when you want make-private style reductions to land on a named owner. Policy tips are not available for on-premises repositories. Activity appears in activity explorer.

DLP looks for sensitive information types, sensitivity labels, file extensions, and—on Office files—custom document properties. When a file matches, documented actions include:

• Block everyone — NTFS/SharePoint ACL reduced to the content owner, last modifier (SharePoint only), repository owner, administrator, plus FC for the scanner account.
• Block the broad SIDs Everyone, NT AUTHORITY\Authenticated Users, and Domain Users, leaving only explicitly granted users and groups.
• Inherit parent folder permissions (by default only if the parent is more restrictive, unless you choose inherit even when the parent is less restrictive).
• Remove the file to a quarantine folder and leave a .txt stub.

If you combine a DLP make private action with scanner auto-labeling, Microsoft recommends the client's UseCopyAndPreserveNTFSOwner advanced setting so original owners keep access. Everyone who contributes files to the scanned location needs an appropriate license, not only the scanner account.

Deployment sequence to memorize

Prereqs (Windows Server, SQL, Entra-synced service account, full client, at least one label for the scanner account) → cluster in Purview → content scan job plus repositories → Install-Scanner → Set-Authentication → manual discovery scan and report review → Enforce On plus Schedule Always → optional DLP rules. Scale by adding nodes with the same -Cluster value and the same SQL database.