Deploying previous versions of the Azure Information Protection classic client scanner
Applies to: Azure Information Protection, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Relevant for: Azure Information Protection classic client for Windows. For the scanner from the unified labeling client, see What is the AIP unified labeling scanner?.
To provide a unified and streamlined customer experience, the Azure Information Protection classic client and Label Management in the Azure Portal are deprecated as of March 31, 2021. While the classic client continues to work as configured, no further support is provided, and maintenance versions will no longer be released for the classic client.
This article is for versions of the Azure Information Protection scanner that are earlier than version 22.214.171.124 but still in support. To upgrade earlier versions to the current version, see Upgrading the Azure Information Protection scanner.
Use this information to learn about the Azure Information Protection scanner, and then how to successfully install, configure, and run it.
This scanner runs as a service on Windows Server and lets you discover, classify, and protect files on the following data stores:
UNC paths for network shares that use the Server Message Block (SMB) protocol.
Document libraries and folders for SharePoint Server 2019 through SharePoint Server 2013. SharePoint 2010 is also supported for customers who have extended support for this version of SharePoint.
To scan and label files on cloud repositories, use Cloud App Security instead of the scanner.
Overview of the Azure Information Protection scanner
When you have configured your Azure Information Protection policy for labels that apply automatic classification, files that this scanner discovers can then be labeled. Labels apply classification, and optionally, apply protection or remove protection:
The scanner can inspect any files that Windows can index, by using IFilters that are installed on the computer. Then, to determine if the files need labeling, the scanner uses the Microsoft 365 built-in data loss prevention (DLP) sensitivity information types and pattern detection, or Microsoft 365 regex patterns. Because the scanner uses the Azure Information Protection client, it can classify and protect the same file types.
You can run the scanner in discovery mode only, where you use the reports to check what would happen if the files were labeled. Or, you can run the scanner to automatically apply the labels. You can also run the scanner to discover files that contain sensitive information types, without configuring labels for conditions that apply automatic classification.
Note that the scanner does not discover and label in real time. It systematically crawls through files on data stores that you specify, and you can configure this cycle to run once, or repeatedly.
You can specify which file types to scan, or exclude from scanning. To restrict which files the scanner inspects, define a file types list by using Set-AIPScannerScannedFileTypes.
Prerequisites for the Azure Information Protection scanner
Before you install the Azure Information Protection scanner, make sure that the following requirements are in place.
|Windows Server computer to run the scanner service:
- 4 core processors
- 8 GB of RAM
- 10 GB free space (average) for temporary files
|Windows Server 2019, Windows Server 2016, or Windows Server 2012 R2.
Note: For testing or evaluation purposes in a non-production environment, you can use a Windows client operating system that is supported by the Azure Information Protection client.
This computer can be a physical or virtual computer that has a fast and reliable network connection to the data stores to be scanned.
The scanner requires sufficient disk space to create temporary files for each file that it scans, four files per core. The recommended disk space of 10 GB allows for 4 core processors scanning 16 files that each have a file size of 625 MB.
If internet connectivity is not possible because of your organization policies, see the Deploying the scanner with alternative configurations section. Otherwise, make sure that this computer has internet connectivity that allows the following URLs over HTTPS (port 443):
|Service account to run the scanner service||In addition to running the scanner service on the Windows Server computer, this Windows account authenticates to Azure AD and downloads the Azure Information Protection policy. This account must be an Active Directory account and synchronized to Azure AD. If you cannot synchronize this account because of your organization policies, see the Deploying the scanner with alternative configurations section.
This service account has the following requirements:
- Log on locally user right assignment. This right is required for the installation and configuration of the scanner, but not for operation. You must grant this right to the service account but you can remove this right after you have confirmed that the scanner can discover, classify, and protect files. If granting this right even for a short period of time is not possible because of your organization policies, see the Deploying the scanner with alternative configurations section.
- Log on as a service user right assignment. This right is automatically granted to the service account during the scanner installation and this right is required for the installation, configuration, and operation of the scanner.
- Permissions to the data repositories: For data repositories on SharePoint on-premises, always grant the Edit permission if Add and Customize Pages is selected for the site, or grant the Design permission. For other data repositories, grant Read and Write permissions for scanning the files and then applying classification and protection to the files that meet the conditions in the Azure Information Protection policy. To run the scanner in discovery mode only for these other data repositories, Read permission is sufficient.
- For labels that reprotect or remove protection: To ensure that the scanner always has access to protected files, make this account a super user for the Azure Rights Management service, and ensure that the super user feature is enabled. For more information about the account requirements for applying protection, see Preparing users and groups for Azure Information Protection. In addition, if you have implemented onboarding controls for a phased deployment, make sure that this account is included in your onboarding controls you've configured.
|SQL Server to store the scanner configuration:
- Local or remote instance
- Case insensitive collation
- Sysadmin role to install the scanner
|SQL Server 2012 is the minimum version for the following editions:
- SQL Server Enterprise
- SQL Server Standard
- SQL Server Express
If you install more than one instance of the scanner, each scanner instance requires its own SQL Server instance.
When you install the scanner and your account has the Sysadmin role, the installation process automatically creates the AzInfoProtectionScanner database and grants the required db_owner role to the service account that runs the scanner. If you cannot be granted the Sysadmin role or your organization policies require databases to be created and configured manually, see the Deploying the scanner with alternative configurations section.
The size of the configuration database will vary for each deployment but we recommend you allocate 500 MB for every 1,000,000 files that you want to scan.
|The Azure Information Protection classic client is installed on the Windows Server computer||You must install the full client for the scanner. Do not install the client with just the PowerShell module.
For client installation instructions, see the admin guide. If you have previously installed the scanner and now need to upgrade it to a later version, see Upgrading the Azure Information Protection scanner.
|Configured labels that apply automatic classification, and optionally, protection||For more information about how to configure a label for conditions and to apply protection:
- How to configure conditions for automatic and recommended classification
- How to configure a label for Rights Management protection
Tip: You can use the instructions from the tutorial to test the scanner with a label that looks for credit card numbers in a prepared Word document. However, you will need to change the label configuration so that Select how this label is applied is set to Automatic rather than Recommended. Then remove the label from the document (if it is applied) and copy the file to a data repository for the scanner.
Although you can run the scanner even if you haven't configured labels that apply automatic classification, this scenario is not covered with these instructions. More information
|For SharePoint document libraries and folders to be scanned:
- SharePoint 2019
- SharePoint 2016
- SharePoint 2013
- SharePoint 2010
|Other versions of SharePoint are not supported for the scanner.
When you use versioning, the scanner inspects and labels the last published version. If the scanner labels a file and content approval is required, that labeled file must be approved to be available for users.
For large SharePoint farms, check whether you need to increase the list view threshold (by default, 5,000) for the scanner to access all files. For more information, see the following SharePoint documentation: Manage large lists and libraries in SharePoint
|For Office documents to be scanned:
- 97-2003 file formats and Office Open XML formats for Word, Excel, and PowerPoint
|For more information about the file types that the scanner supports for these file formats, see File types supported by the Azure Information Protection client|
|For long paths:
- Maximum of 260 characters, unless the scanner is installed on Windows 2016 and the computer is configured to support long paths
|Windows 10 and Windows Server 2016 support path lengths greater than 260 characters with the following group policy setting: Local Computer Policy > Computer Configuration > Administrative Templates > All Settings > Enable Win32 long paths
For more information about supporting long file paths, see the Maximum Path Length Limitation section from the Windows 10 developer documentation.
If you can't meet all the requirements in the table because they are prohibited by your organization policies, see the next section for alternatives.
If all the requirements are met, go straight to the installation section.
Deploying the scanner with alternative configurations
The prerequisites listed in the table are the default requirements for the scanner and recommended because they are the simplest configuration for the scanner deployment. They should be suitable for initial testing, so that you can check the capabilities of the scanner. However, in a product environment, your organization policies might prohibit these default requirements because of one or more of the following restrictions:
Servers are not allowed internet connectivity
You cannot be granted Sysadmin or databases must be created and configured manually
Service accounts cannot be granted the Log on locally right
Service accounts cannot be synchronized to Azure Active Directory but servers have internet connectivity
The scanner can accommodate these restrictions but they require additional configuration.
Restriction: The scanner server cannot have internet connectivity
Follow the instructions for a disconnected computer.
Note that in this configuration, the scanner cannot apply protection (or remove protection) by using your organization's cloud-based key. Instead, the scanner is limited to using labels that apply classification only, or protection that uses HYOK.
Restriction: You cannot be granted Sysadmin or databases must be created and configured manually
If you can be granted the Sysadmin role temporarily to install the scanner, you can remove this role when the scanner installation is complete. When you use this configuration, the database is automatically created for you and the service account for the scanner is automatically granted the required permissions. However, the user account that configures the scanner requires the db_owner role for the AzInfoProtectionScanner database, and you must manually grant this role to the user account.
If you cannot be granted the Sysadmin role even temporarily, you must ask a user with Sysadmin rights to manually create a database named AzInfoProtectionScanner before you install the scanner. For this configuration, the following roles must be assigned:
|Service account for the scanner||db_owner|
|User account for scanner installation||db_owner|
|User account for scanner configuration||db_owner|
Typically, you will use the same user account to install and configure the scanner. But if you use different accounts, they both require the db_owner role for the AzInfoProtectionScanner database.
To create a user and grant db_owner rights on this database, ask the Sysadmin to run the following SQL script twice. The first time, for the service account that runs the scanner, and the second time for you to install and manage the scanner. Before running the script, replace domain\user with the domain name and user account name of the service account or user account:
if not exists(select * from master.sys.server_principals where sid = SUSER_SID('domain\user')) BEGIN declare @T nvarchar(500) Set @T = 'CREATE LOGIN ' + quotename('domain\user') + ' FROM WINDOWS ' exec(@T) END USE AzInfoProtectionScanner IF NOT EXISTS (select * from sys.database_principals where sid = SUSER_SID('domain\user')) BEGIN declare @X nvarchar(500) Set @X = 'CREATE USER ' + quotename('domain\user') + ' FROM LOGIN ' + quotename('domain\user'); exec sp_addrolemember 'db_owner', 'domain\user' exec(@X) END
You must be a local administrator on the server that will run the scanner
The service account that will run the scanner must be granted Full Control permissions to the following registry keys:
If, after configuring these permissions, you see an error when you install the scanner, the error can be ignored and you can manually start the scanner service.
Restriction: The service account for the scanner cannot be granted the Log on locally right
If your organization policies prohibit the Log on locally right for service accounts but allow the Log on as a batch job right, follow the instructions for Specify and use the Token parameter for Set-AIPAuthentication from the admin guide.
Restriction: The scanner service account cannot be synchronized to Azure Active Directory but the server has internet connectivity
You can have one account to run the scanner service and use another account to authenticate to Azure Active Directory:
For the scanner service account, you can use a local Windows account or an Active Directory account.
For the Azure Active Directory account, follow the instructions for Specify and use the Token parameter for Set-AIPAuthentication from the admin guide.
Install the scanner
Sign in to the Windows Server computer that will run the scanner. Use an account that has local administrator rights and that has permissions to write to the SQL Server master database.
Open a Windows PowerShell session with the Run as an administrator option.
Run the Install-AIPScanner cmdlet, specifying your SQL Server instance on which to create a database for the Azure Information Protection scanner:
Install-AIPScanner -SqlServerInstance <name>
For a default instance:
Install-AIPScanner -SqlServerInstance SQLSERVER1
For a named instance:
Install-AIPScanner -SqlServerInstance SQLSERVER1\AIPSCANNER
For SQL Server Express:
Install-AIPScanner -SqlServerInstance SQLSERVER1\SQLEXPRESS
When you are prompted, provide the credentials for the scanner service account (<domain\user name>) and password.
Verify that the service is now installed by using Administrative Tools > Services.
The installed service is named Azure Information Protection Scanner and is configured to run by using the scanner service account that you created.
Now that you have installed the scanner, you need to get an Azure AD token for the scanner service account to authenticate so that it can run unattended.
Get an Azure AD token for the scanner
The Azure AD token lets the scanner service account authenticate to the Azure Information Protection service.
From the same Windows Server computer, or from your desktop, sign in to the Azure portal to create two Azure AD applications that are needed to specify an access token for authentication. After an initial interactive sign-in, this token lets the scanner run non-interactively.
To create these applications, follow the instructions in How to label files non-interactively for Azure Information Protection from the admin guide.
From the Windows Server computer, if your scanner service account has been granted the Log on locally right for the installation: Sign in with this account and start a PowerShell session. Run Set-AIPAuthentication, specifying the values that you copied from the previous step:
Set-AIPAuthentication -webAppId <ID of the "Web app / API" application> -webAppKey <key value generated in the "Web app / API" application> -nativeAppId <ID of the "Native" application>
When prompted, specify the password for your service account credentials for Azure AD, and then click Accept.
If your scanner service account cannot be granted the Log on locally right for the installation: Follow the instructions in the Specify and use the Token parameter for Set-AIPAuthentication section from the admin guide.
The scanner now has a token to authenticate to Azure AD, which is valid for one year, two years, or never expires, according to your configuration of the Web app /API in Azure AD. When the token expires, you must repeat steps 1 and 2.
You're now ready to specify the data stores to scan.
Specify data stores for the scanner
Use the Add-AIPScannerRepository cmdlet to specify the data stores to be scanned by the Azure Information Protection scanner. You can specify UNC paths and SharePoint Server URLs for SharePoint document libraries and folders.
Supported versions for SharePoint: SharePoint Server 2019, SharePoint Server 2016, and SharePoint Server 2013. SharePoint Server 2010 is also supported for customers who have extended support for this version of SharePoint.
From the same Windows Server computer, in your PowerShell session, add your first data store by running the following command:
Add-AIPScannerRepository -Path <path>
Add-AIPScannerRepository -Path \\NAS\Documents
For other examples, use the PowerShell help command
Get-Help Add-AIPScannerRepository -examplesfor this cmdlet.
Repeat this command for all the data stores that you want to scan. If you need to remove a data store that you added, use the Remove-AIPScannerRepository cmdlet.
Confirm that you have specified all the data stores correctly, by running the Get-AIPScannerRepository cmdlet:
With the scanner's default configuration, you're now ready to run your first scan in discovery mode.
Run a discovery cycle and view reports for the scanner
In your PowerShell session, start the scanner by running the following command:
Alternatively, you can start the scanner from the Azure portal. From the Azure Information Protection - Nodes pane, select your scanner node, and then the Scan now option:
Wait for the scanner to complete its cycle by running the following command:
Alternatively, you can view the status from the Azure Information Protection - Nodes pane in the Azure portal, by checking the STATUS column.
Look for the status to show Idle rather than Scanning.
When the scanner has crawled through all the files in the data stores that you specified, the scanner stops although the scanner service remains running.
Check the local Windows Applications and Services event log, Azure Information Protection. This log also reports when the scanner has finished scanning, with a summary of results. Look for the informational event ID 911.
Review the reports that are stored in %localappdata%\Microsoft\MSIP\Scanner\Reports. The .txt summary files include the time taken to scan, the number of scanned files, and how many files had a match for the information types. The .csv files have more details for each file. This folder stores up to 60 reports for each scanning cycle and all but the latest report is compressed to help minimize the required disk space.
You can change the level of logging by using the ReportLevel parameter with Set-AIPScannerConfiguration, but you can't change the report folder location or name. Consider using a directory junction for the folder if you want to store the reports on a different volume or partition.
For example, using the Mklink command:
mklink /j D:\Scanner_reports C:\Users\aipscannersvc\AppData\Local\Microsoft\MSIP\Scanner\Reports
With the default setting, only files that meet the conditions you've configured for automatic classification are included in the detailed reports. If you don't see any labels applied in these reports, check your label configuration includes automatic rather than recommended classification.
Scanners send this information to Azure Information Protection every five minutes, so that you can view the results in near real-time from the Azure portal. For more information, see Reporting for Azure Information Protection.
If the results are not as you expect, you might need to fine-tune the conditions that you specified in your Azure Information Protection policy. If that's the case, repeat steps 1 through 3 until you are ready to change the configuration to apply the classification and optionally, protection.
The Azure portal displays information about the last scan only. If you need to see the results of previous scans, return to the reports that are stored on the scanner computer, in the %localappdata%\Microsoft\MSIP\Scanner\Reports folder.
When you're ready to automatically label the files that the scanner discovers, continue to the next procedure.
Configure the scanner to apply classification and protection
In its default setting, the scanner runs one time and in the reporting-only mode. To change these settings, use the Set-AIPScannerConfiguration:
On the Windows Server computer, in the PowerShell session, run the following command:
Set-AIPScannerConfiguration -Enforce On -Schedule Always
There are other configuration settings that you might want to change. For example, whether file attributes are changed and what is logged in the reports. In addition, if your Azure Information Protection policy includes the setting that requires a justification message to lower the classification level or remove protection, specify that message by using this cmdlet. Use the following PowerShell help command for more information about each configuration setting:
Get-Help Set-AIPScannerConfiguration -detailed
Make a note of the current time and start the scanner again by running the following command:
Alternatively, you can start the scanner from the Azure portal. From the Azure Information Protection - Nodes pane, select your scanner node, and then the Scan now option:
Monitor the event log for the informational type 911 again, with a time stamp later than when you started the scan in the previous step.
Then check the reports to see details of which files were labeled, what classification was applied to each file, and whether protection was applied to them. Or, use the Azure portal to more easily see this information.
Because we configured the schedule to run continuously, when the scanner has worked its way through all the files, it starts a new cycle so that any new and changed files are discovered.
How files are scanned
The scanner runs through the following processes when it scans files.
1. Determine whether files are included or excluded for scanning
The scanner automatically skips files that are excluded from classification and protection, such as executable files and system files.
You can change this behavior by defining a list of file types to scan, or exclude from scanning. When you specify this list and do not specify a data repository, the list applies to all data repositories that do not have their own list specified. To specify this list, use Set-AIPScannerScannedFileTypes.
After you have specified your file types list, you can add a new file type to the list by using Add-AIPScannerScannedFileTypes, and remove a file type from the list by using Remove-AIPScannerScannedFileTypes.
2. Inspect and label files
The scanner then uses filters to scan supported file types. These same filters are used by the operating system for Windows Search and indexing. Without any additional configuration, Windows IFilter is used to scan file types that are used by Word, Excel, PowerPoint, and for PDF documents and text files.
For a full list of file types that are supported by default, and additional information how to configure existing filters that include .zip files and .tiff files, see File types supported for inspection.
After inspection, these file types can be labeled by using the conditions that you specified for your labels. Or, if you're using discovery mode, these files can be reported to contain the conditions that you specified for your labels, or all known sensitive information types.
However, the scanner cannot label the files under the following circumstances:
If the label applies classification and not protection, and the file type does not support classification only.
If the label applies classification and protection, but the scanner does not protect the file type.
By default, the scanner protects only Office file types, and PDF files when they are protected by using the ISO standard for PDF encryption. Other file types can be protected when you edit the registry as described in a following section.
For example, after inspecting files that have a file name extension of .txt, the scanner can't apply a label that's configured for classification but not protection, because the .txt file type doesn't support classification-only. If the label is configured for classification and protection, and the registry is edited for the .txt file type, the scanner can label the file.
During this process, if the scanner stops and doesn't complete scanning a large number of the files in a repository:
You might need to increase the number of dynamic ports for the operating system hosting the files. Server hardening for SharePoint can be one reason why the scanner exceeds the number of allowed network connections, and therefore stops.
To check whether this is the cause of the scanner stopping, look to see if the following error message is logged for the scanner in %localappdata%\Microsoft\MSIP\Logs\MSIPScanner.iplog (zipped if there are multiple logs): Unable to connect to the remote server ---> System.Net.Sockets.SocketException: Only one usage of each socket address (protocol/network address/port) is normally permitted IP:port
For more information about how to view the current port range and increase the range, see Settings that can be Modified to Improve Network Performance.
For large SharePoint farms, you might need to increase the list view threshold (by default, 5,000). For more information, see the following SharePoint documentation: Manage large lists and libraries in SharePoint.
3. Label files that can't be inspected
For the file types that can't be inspected, the scanner applies the default label in the Azure Information Protection policy, or the default label that you configure for the scanner.
As in the preceding step, the scanner cannot label the files under the following circumstances:
If the label applies classification and not protection, and the file type does not support classification only.
If the label applies classification and protection, but the scanner does not protect the file type.
By default, the scanner protects only Office file types, and PDF files when they are protected by using the ISO standard for PDF encryption. Other file types can be protected when you edit the registry as described next.
Editing the registry for the scanner
To change the default scanner behavior for protecting file types other than Office files and PDFs, you must manually edit the registry and specify the additional file types that you want to be protected, and the type of protection (native or generic). In this documentation for developers, generic protection is referred to as "PFile". In addition, specific for the scanner:
The scanner has its own default behavior: Only Office file formats and PDF documents are protected by default. If the registry is not modified, any other file types will not be labeled or protected by the scanner.
If you want the same default protection behavior as the Azure Information Protection client, where all files are automatically protected with native or generic protection: Specify the
*wildcard as a registry key,
Encryptionas the value (REG_SZ), and
Defaultas the value data.
When you edit the registry, manually create the MSIPC key and FileProtection key if they do not exist, as well as a key for each file name extension.
For example, for the scanner to protect TIFF images in addition to Office files and PDFs, the registry after you have edited it, will look like the following picture. As an image file, TIFF files support native protection and the resulting file name extension is .ptiff.
For a list of text and images file types that similarly support native protection but must be specified in the registry, see Supported file types for classification and protection from the admin guide.
For files that don't support native protection, specify the file name extension as a new key, and PFile for generic protection. The resulting file name extension for the protected file is .pfile.
When files are rescanned
For the first scan cycle, the scanner inspects all files in the configured data stores and then for subsequent scans, only new or modified files are inspected.
You can force the scanner to inspect all files again by running Start-AIPScan with the Reset parameter. The scanner must be configured for a manual schedule, which requires the Schedule parameter to be set to Manual with Set-AIPScannerConfiguration.
Alternatively, you can force the scanner to inspect all files again from the Azure Information Protection - Nodes pane in the Azure portal. Select your scanner from the list, and then select the Rescan all files option:
Inspecting all files again is useful when you want the reports to include all files and this configuration choice is typically used when the scanner runs in discovery mode. When a full scan is complete, the scan type automatically changes to incremental so that for subsequent scans, only new or modified files are scanned.
In addition, all files are inspected when the scanner downloads an Azure Information Protection policy that has new or changed conditions. The scanner refreshes the policy every hour, and when the service starts and the policy is older than one hour.
If you need to refresh the policy sooner than this one hour interval, for example, during a testing period: Manually delete the policy file, Policy.msip from both %LocalAppData%\Microsoft\MSIP\Policy.msip and %LocalAppData%\Microsoft\MSIP\Scanner. Then restart the Azure Information Scanner service.
If you changed protection settings in the policy, also wait 15 minutes from when you saved the protection settings before you restart the service.
If the scanner downloaded a policy that had no automatic conditions configured, the copy of the policy file in the scanner folder does not update. In this scenario, you must delete the policy file, Policy.msip from both %LocalAppData%\Microsoft\MSIP\Policy.msip and %LocalAppData%\Microsoft\MSIP\Scanner before the scanner can use a newly downloaded policy file that has labels correctly figured for automatic conditions.
Using the scanner with alternative configurations
There are two alternative scenarios that the Azure Information Protection scanner supports where labels do not need to be configured for any conditions:
Apply a default label to all files in a data repository.
For this configuration, use the Set-AIPScannerRepository cmdlet, and set the MatchPolicy parameter to Off.
The contents of the files are not inspected and all files in the data repository are labeled according to the default label that you specify for the data repository (with the SetDefaultLabel parameter) or if this is not specify, the default label that is specified as a policy setting for the scanner account.
Identify all custom conditions and known sensitive information types.
For this configuration, use the Set-AIPScannerConfiguration cmdlet, and set the DiscoverInformationTypes parameter to All.
The scanner uses any custom conditions that you have specified for labels in the Azure Information Protection policy, and the list of information types that are available to specify for labels in the Azure Information Protection policy.
The following quickstart uses this configuration, although it's for the current version of the scanner: Quickstart: Find what sensitive information you have.
Optimizing the performance of the scanner
Use the following guidance to help you optimize the performance of the scanner. However, if your priority is the responsiveness of the scanner computer rather than the scanner performance, you can use an advanced client setting to limit the number of threads used by the scanner.
To maximize the scanner performance:
Have a high speed and reliable network connection between the scanner computer and the scanned data store
For example, place the scanner computer in the same LAN, or (preferred) in the same network segment as the scanned data store.
The quality of the network connection affects the scanner performance because to inspect the files, the scanner transfers the contents of the files to the computer running the scanner service. When you reduce (or eliminate) the number of network hops this data has to travel, you also reduce the load on your network.
Make sure the scanner computer has available processor resources
Inspecting the file contents for a match against your configured conditions, and encrypting and decrypting files are processor-intensive actions. Monitor typical scanning cycles for your specified data stores to identify whether a lack of processor resources is negatively affecting the scanner performance.
Other factors that affect the scanner performance:
The current load and response times of the data stores that contain the files to scan
Whether the scanner runs in discovery mode or enforce mode
Discovery mode typically has a higher scanning rate than enforce mode because discovery requires a single file read action, whereas enforce mode requires read and write actions.
You change the conditions in the Azure Information Protection
Your first scan cycle when the scanner must inspect every file will obviously take longer than subsequent scan cycles that by default, inspect only new and changed files. However, if you change the conditions in the Azure Information Protection policy, all files are scanned again, as described in the preceding section.
The construction of regex expressions for custom conditions
To avoid heavy memory consumption and the risk of timeouts (15 minutes per file), review your regex expressions for efficient pattern matching. For example:
Avoid greedy quantifiers
Use non-capturing groups such as
Your chosen logging level
You can choose between Debug, Info, Error and Off for the scanner reports. Off results in the best performance; Debug considerably slows down the scanner and should be used only for troubleshooting. For more information, see the ReportLevel parameter for the Set-AIPScannerConfiguration cmdlet by running
Get-Help Set-AIPScannerConfiguration -detailed.
The files themselves:
With the exception of Excel files, Office files are more quickly scanned than PDF files.
Unprotected files are quicker to scan than protected files.
Large files obviously take longer to scan than small files.
Confirm that the service account that runs the scanner has only the rights documented in the scanner prerequisites section, and then configure the advanced client setting to disable the low integrity level for the scanner.
The scanner runs more quickly when you use the alternative configuration to apply a default label to all files because the scanner does not inspect the file contents.
The scanner runs more slowly when you use the alternative configuration to identify all custom conditions and known sensitive information types.
You can decrease the scanner timeouts with advanced client settings for better scanning rates and lower memory consumption, but with the acknowledgment that some files might be skipped.
List of cmdlets for the scanner
Other cmdlets for the scanner let you change the service account and database for the scanner, get the current settings for the scanner, and uninstall the scanner service. The scanner uses the following cmdlets:
Many of these cmdlets are now deprecated in the current version of the scanner, and the online help for the scanner cmdlets reflects this change. For cmdlet help earlier than version 126.96.36.199 of the scanner, use the built-in
Get-Help <cmdlet name> command in your PowerShell session.
Event log IDs and descriptions for the scanner
Use the following sections to identify the possible event IDs and descriptions for the scanner. These events are logged on the server that runs the scanner service, in the Windows Applications and Services event log, Azure Information Protection.
Scanner cycle started.
This event is logged when the scanner service is started and begins to scan for files in the data repositories that you specified.
Scanner cycle finished.
This event is logged when the scanner has finished a manual scan, or the scanner has finished a cycle for a continuous schedule.
If the scanner was configured to run manually rather than continuously, to run a new scan, use the Start-AIPScan cmdlet. To change the schedule, use the Set-AIPScannerConfiguration cmdlet and the Schedule parameter.
Interested in how the Core Services Engineering and Operations team in Microsoft implemented this scanner? Read the technical case study: Automating data protection with Azure Information Protection scanner.
You might be wondering: What's the difference between Windows Server FCI and the Azure Information Protection scanner?
You can also use PowerShell to interactively classify and protect files from your desktop computer. For more information about this and other scenarios that use PowerShell, see Using PowerShell with the Azure Information Protection client.