Compliance scope

Help ID: compliance.tab.scope

The Scope tab picks which servers and databases the run touches. It's a two-pane checkbox picker: servers on the left, that server's DBs on the right.

[Image omitted: Scope tab with Gold SLA selected and DB list on the right]

Filter by SLA first

The top strip has a Service Level dropdown sourced from GUI.SLAList — typically (All), Bronze, Silver, Gold. Choosing an SLA filters the servers pane to just the servers whose dbo.Servers.ServiceLevel matches.

Picking (All) shows every managed server.

The dropdown is the fastest way to scope a run — most compliance profiles are tier-scoped ("CIS baseline for Gold production", "loose Bronze dev check"), so the SLA alone often does what you want without touching the checkboxes.

Servers pane (left)

[Image omitted: Server list with mixed checked/unchecked]

Every server matching the current SLA filter, one per row. Each row has:

A checkbox — controls whether the server is in scope.
The server name.
A subtle SLA badge on the right for the server's own tier (useful sanity check when SLA = (All)).

Above the list is a Select all master checkbox. It toggles every visible server in one click.

Every server starts checked — the default assumption is "run against everything the SLA filter shows". Uncheck to exclude a specific server from this run.

Clicking a row focuses it (highlights it) and loads its DB list on the right pane.

Databases pane (right)

[Image omitted: Database list with system DBs unchecked]

The databases collected on the currently-focused server, from the newest snapshot in Collector.DBProperties. Each row has:

A checkbox.
The database name in mono font.
A small system chip on system DBs (see below).

Above the list is a Select all master checkbox that toggles every DB on this server.

System vs user DBs

By convention the following names are treated as system DBs and start unchecked:

master
model
msdb
tempdb
distribution
ReportServer
ReportServerTempDB
SSISDB

Every other DB starts checked.

The reason: compliance profiles almost always grade user data. Checking a metric against tempdb or msdb produces noise — either the metric doesn't apply (encryption on tempdb), or the answer is a fixed system value (msdb's owner is always sa). Check them individually if you have a specific reason to grade a system DB (e.g. Trustworthy = 1 on MSDB is expected and gets modeled via a threshold — see Compliance thresholds recipe).

What gets passed to the run

When you click Run now on the Run & History tab, the VM computes what to send HealthCheck.ReportMaster from the current Scope state:

@SLA — the dropdown value, unless it's (All).
@Include — a comma-separated list of InstanceIDs. Only sent when a subset of visible servers is checked. If every visible server is checked, @Include stays NULL and the SLA filter alone does the work.
@Exclude — currently unused by the UI; @Include inversion covers the same ground.
@IncludeDB / @ExcludeDB — DB-level scope isn't wired through to ReportMaster yet because the SP takes global DB lists, not per-server. The DB checkboxes are stored client-side and will be forwarded once the SP supports per-server DB filters. Today, all databases on each in-scope server are graded (subject to system-DB defaults).

Encoding examples

Scope state	`@SLA`	`@Include`
SLA = Gold, every Gold server checked	`Gold`	NULL
SLA = Gold, 3 of 5 Gold servers checked	`Gold`	`12,17,23`
SLA = (All), every server checked	NULL	NULL
SLA = (All), 4 of 30 servers checked	NULL	`4,7,12,20`
SLA = Bronze, every server unchecked	`Bronze`	(nothing runs)

Persistence caveat

Scope choices live in memory only while the Compliance page is open. Reopening the app resets them to the defaults (SLA = (All), all visible servers checked, user DBs checked, system DBs unchecked).

This is intentional for v1 — there's no per-profile ReportScope table yet. If you need saved scope-per-profile, either:

Run under a dbo.Servers.ServiceLevel group that already represents the scope you want.
Wait for a future release that adds persistence.

The Scope values do get captured in HealthCheck.ReportLog.Include / Exclude / IncludeDB / ExcludeDB at run time, so you can always see what a past run actually graded — see Compliance run & history.

Example configurations

Example 1 — Every Gold server, exclude one known-bad host

SLA = Gold
Servers: all checked except Legacy-DB-05 (known-bad; being decommissioned)
DBs: user DBs checked, system DBs unchecked (defaults)

Run sends @SLA='Gold' and @Include='<comma-sep-InstanceIDs of the 27 checked Gold servers>'.

Example 2 — Ad-hoc pair for reproducing a specific failure

SLA = (All)
Servers: only Prod-DB-01 and Prod-DB-07 checked
DBs: on each, one specific app DB checked (visual — not enforced by RunReport yet)

Run sends @SLA=NULL and @Include='<InstanceID of -01>,<InstanceID of -07>'.

Example 3 — Every Bronze except system-y stuff

SLA = Bronze
Servers: all checked (defaults)
DBs: defaults (system DBs off, user DBs on)

Run sends @SLA='Bronze', @Include=NULL.

Common gotchas

"Select all" reflects only visible rows. If you have SLA = Gold selected, "Select all servers" toggles Gold servers, not the whole fleet. This is the intended behavior.
A server's DB list is a snapshot. It comes from Collector.DBProperties — the newest row per (instance, DB). A DB created since the last collector run won't appear. Force a collector refresh if you need up-to-the-minute DB scope.
DB checkboxes are informational only right now. They save your intent but don't restrict the run. This is a v1 limitation.
Focusing a server DOES NOT check it. Selecting a row (highlighting it) just shows its DBs on the right. Toggle the checkbox separately if you want to include/exclude.