SQL Server¶

With the Microsoft SQL Server integration, Clarity Transform inventories SQL Server instances and databases: version, edition, clustering and high-availability configuration, database size and last backup date.

Where to find it¶

Go to Discover → Integrations, then select the SQL Server card. The card's category label is Database. The integration's page has the Endpoints and History tabs; Integrations describes the page, its grid and its row actions.

Why we do this¶

Databases are usually the hardest part of a migration and the part planned last. Their versions constrain what they can move to, their high-availability configuration constrains how they can be cut over, and their size constrains how long it takes.

Collecting that early changes the plan rather than confirming it. An instance on an unsupported version, or in an availability group nobody documented, is the kind of finding that moves a wave rather than adding a line to a report.

What we collect¶

Instances, with version, edition and configuration
Databases, with their size in MB
Clustering and high-availability configuration: availability groups and replicas
Last backup date, and readiness on the SQL Server (NDB) tab of Migration Readiness

Instances are found by the Discovery Method, not from an endpoint

This integration does not connect to one named server. The endpoint's Discovery Method sets how SQL Server instances are found: inventorySignals, browserEnumeration, ipRangeScan or manualTargets. Only inventorySignals works through the SQL Server instances already discovered in the device inventory. The practical consequence is below.

What it adds¶

The database layer, seen from inside the instance. A hypervisor knows a virtual machine's disk size; only the instance knows how much of it is database and whether a second machine is holding a replica of it.

One credential is used against every discovered instance

Because one endpoint covers every instance it discovers, the credential supplied has to be valid on all of them. An instance where it is not simply returns nothing, so a partial result is more likely to be a credential that does not cover that instance than an instance with no data.

What is deliberately not inferred¶

No database contents. Metadata, configuration and sizes only. No table data is read.
No schema definitions or stored procedure bodies.
Nothing is written. No database, login or configuration is created or changed, and no backup is taken.
With the inventorySignals Discovery Method, instances not in the device inventory are not discovered. Coverage follows discovery, so an instance on a host Clarity has not found is invisible to that method.

What we require¶

A SQL login on each in-scope instance with read access to server-level metadata. sysadmin is not required.

Interface: the SQL Server protocol, conventionally TCP 1433
Connectivity: from Clarity to each instance
Permissions: VIEW ANY DATABASE and VIEW SERVER STATE at server level, and read on msdb where backup history is wanted
Account: one login, valid on every instance in scope, since one credential is used against every discovered instance

VIEW ANY DATABASE is the one to be explicit about. Without it the login sees only the databases it owns, so sys.databases returns a short list rather than an error, and the result reads as a small estate.

Verification before handover¶

Run these as the system owner before handing the credential over, so a failed discovery run is never the first time anyone finds out.

Confirm the login works on more than one instance. The same credential is used against every discovered instance, so testing it on one proves less than it appears to. Test it on a representative sample, including any instance on a different domain or in a different environment.
Confirm every database is visible. Query sys.databases as the login and compare the count with what an administrator sees. A short list rather than an error is the signature of a missing VIEW ANY DATABASE.
Confirm the availability group views read. Query the availability group and replica state views. These need VIEW SERVER STATE, and without it the high-availability picture is missing rather than wrong, which is harder to notice.

Configuring the endpoint¶

On the integration's Endpoints tab, select the add icon (Create New Integration Endpoints). The Create new entry form opens with these fields, in this order:

Field	Value
Name	A name for the endpoint
Discovery Method	How instances are found: inventorySignals, browserEnumeration, ipRangeScan or manualTargets. It starts as inventorySignals. Choosing ipRangeScan or manualTargets adds an End Point field to the form.
Credential	The stored credential for the SQL login
Job Schedule	A five-field cron expression, for example `0 2 * * 0` (weekly). Instance configuration changes slowly; database sizes are worth more often on a sizing exercise
Enabled	Ticked. The box is unticked when the form opens

The help texts: Discovery Method "Select how SQL Server instances should be discovered for this endpoint configuration."; Credential "Credentials can be configured under Settings/Identity and Access Management/Credentials."; Job Schedule "Cron schedule – Use five fields: 〈mm〉〈hh〉〈day-of-month〉〈month〉〈weekday〉".

The Credential list offers the credentials stored under Settings → Identity & Access Management → Credentials, so create the credential there first.

The endpoint form has no End Point field unless Discovery Method is ipRangeScan or manualTargets, although the Endpoints grid has an End Point column.

No field is marked as required. Technology is set by the card and is hidden in the form. Select Save to create the endpoint, or Cancel to close the form. The edit icon opens the same fields as Edit entry.

Removing the access¶

Drop the login on the in-scope instances. Nothing was written, so there is nothing to undo. Then, in Clarity, remove the endpoint (select its row on the Endpoints tab, then Remove selected) or clear its Enabled box, and remove the credential under Settings → Identity & Access Management → Credentials.

Troubleshooting¶

Symptom	Cause
Fewer databases than expected, with no error	The login lacks `VIEW ANY DATABASE`, so it sees only the databases it owns.
No availability group information on a clustered instance	The login lacks `VIEW SERVER STATE`. The high-availability views return nothing rather than failing.
Some instances return nothing at all	The credential is not valid on those instances. One credential is used against every discovered instance.
No instances discovered	With the `inventorySignals` Discovery Method, none are in the device inventory yet. Run the integration that discovers their hosts first, or choose another Discovery Method.
No backup history	The login has no read access on `msdb`. Nothing else is affected.