Merk
Tilgang til denne siden krever autorisasjon. Du kan prøve å logge på eller endre kataloger.
Tilgang til denne siden krever autorisasjon. Du kan prøve å endre kataloger.
This article describes how scanner administrators can enable, disable, and configure supported Microsoft Purview Information Protection scanner features at the cluster level by using PowerShell.
Admin-controlled feature configuration is available with Microsoft Purview Information Protection client and scanner version 3.2.89.0 or later.
How feature control works
Scanner features are configured once per scanner cluster. The settings are stored in a dedicated dbo.Features table in the shared scanner cluster database. Every node in the cluster reads from the same table, which means:
- An administrator runs a configuration cmdlet once from any node in the cluster, and all nodes pick up the change on the next scan cycle.
- No service restart is required.
- Nodes can't get into mismatched feature states.
- Disabling a feature stops the action that the feature performs (for example, writing to a new database table or producing a new file). Existing data isn't deleted, so the feature can be re-enabled later without data loss.
- Features that aren't explicitly configured don't have a row in the
dbo.Featurestable and use the code default (typically Off). Rows are added only when an administrator explicitly sets a feature.
Each row in dbo.Features records the feature Name, the Setting (a string such as On or Off), and the Source that wrote the value (PowerShell or Portal).
Custom Reporting is the first feature delivered through admin-controlled feature configuration. For details about that feature, see Custom Reporting (preview).
Evolution of control: PowerShell and the Microsoft Purview portal
Admin-controlled feature configuration is designed to evolve over time. Today, supported features are configured by using PowerShell. As features become available in the Microsoft Purview portal, the portal becomes the source of truth for those features.
The following rules apply when both surfaces are available for a feature:
- PowerShell first. Until a feature is exposed in the Microsoft Purview portal, administrators configure it from PowerShell on any node in the cluster. Each PowerShell write sets the row's
Sourcecolumn toPowerShell. - Portal takes precedence. When a feature has been configured from the Microsoft Purview portal, its row in
dbo.FeaturescarriesSource = 'Portal'. The next time an administrator runsSet-ScannerConfiguration -FeatureSettingsfor that same feature, the cmdlet emits a warning of the form "Feature '<name>' is managed by the Purview portal and cannot be changed via PowerShell. Skipping." and leaves the cluster state unchanged. Other features in the same-FeatureSettingshashtable that aren't portal-managed are still applied. - No synchronization. Settings aren't synchronized between PowerShell and the portal. Not every scanner feature will end up being configurable from the portal. When a feature is available in the portal and has been configured there, that portal-configured setting takes precedence and prevents updates from PowerShell. There's a single source of truth (the row in
dbo.Features) at any time. - Get always reflects state. Regardless of where a feature was configured, Get-ScannerConfiguration returns the current state of every configured feature, including the
SettingandSourcevalues. Administrators can audit the cluster from PowerShell at any time.
This model means scanner administrators can adopt new features through PowerShell as soon as they reach public preview, and switch to portal-based management at their own pace as features become available there.
Supported cmdlets and the -FeatureSettings parameter
The following cmdlets accept the -FeatureSettings parameter:
| Cmdlet | Purpose |
|---|---|
| Install-Scanner | Configure features as part of a new scanner node installation. |
| Set-ScannerConfiguration | Configure features on an existing scanner cluster. The change applies to every node in the cluster. |
| Get-ScannerConfiguration | Return the current Setting and Source for every configured feature, including features that were configured from the Microsoft Purview portal. |
-FeatureSettings accepts a PowerShell hashtable of feature name and setting pairs, using the same pattern as -AdvancedSettings:
- The hashtable key is the feature
Name(for example,CustomReporting). - The hashtable value is the
Settingand is stored as-is in the databaseSettingcolumn (VARCHAR(MAX)). For Custom Reporting, the supported values are"On"and"Off".
Feature names are validated against the scanner's list of supported features before any change is written. An unknown feature name causes the cmdlet to terminate with an error that lists the supported features; no entries from the hashtable are applied in that call.
For background on the -AdvancedSettings pattern, including PowerShell quoting and hashtable tips, see PowerShell tips for specifying the advanced settings and the -AdvancedSettings parameter on Set-Label.
Example: Enable Custom Reporting on an existing cluster
Run the following from any node in the scanner cluster:
Set-ScannerConfiguration -FeatureSettings @{CustomReporting="On"}
All nodes in the cluster pick up the change on their next scan cycle.
Example: Enable Custom Reporting at install time
Install-Scanner -SqlServerInstance SQLSERVER1 -Cluster Europe -FeatureSettings @{CustomReporting="On"}
Example: Configure feature settings in one call
Use the FeatureSettings hashtable to pass feature names and values. Currently, this page documents only CustomReporting:
Set-ScannerConfiguration -FeatureSettings @{CustomReporting="On"}
Example: Review the current feature state
$cfg = Get-ScannerConfiguration
$cfg.Features # hashtable of all configured features
$cfg.Features.CustomReporting # @{Source=PowerShell; Setting=On}
The Features property is a hashtable. Default list-view rendering inlines it as {[<feature>, @{Source=<source>; Setting=<setting>}]}. Each value exposes the current Setting and the Source (PowerShell or Portal) that wrote it. Features that have never been configured don't appear and take their code default.
Disable a feature
Set the value to "Off". Existing data that the feature wrote isn't deleted; the scanner stops performing the feature's action on the next scan cycle.
Set-ScannerConfiguration -FeatureSettings @{CustomReporting="Off"}
Currently supported features
| Feature name | Default | Description |
|---|---|---|
CustomReporting |
Off |
Populates the Custom Reporting tables and columns in the scanner cluster database. See Custom Reporting (preview). |
Additional features will be added over time and listed in the release notes.